Dowód Rezerw 2.0 dla małych giełd i kantorów: projekt wdrożenia w 30 dni (BTC UTXO, ERC‑20, L2, Merkle + ZK)

Czy Twój kantor lub mała giełda potrafi udowodnić rezerwy 1:1 o każdej porze dnia? Rynek premiuje transparentnych operatorów, a jednocześnie kary za błąd reputacyjny są dziś bezlitosne. Poniżej znajdziesz techniczny, ale praktyczny przewodnik, jak zaprojektować i uruchomić Dowód Rezerw (PoR) obejmujący BTC (UTXO), ETH/ERC‑20 (account-based), rollupy L2 oraz stablecoiny – bez zbędnej teorii i z gotowymi listami kontrolnymi.

Dlaczego „mali” mają trudniej – i jak to obejść

Duże giełdy mają zespoły audytowe i własne node’y dla kilkudziesięciu łańcuchów. Mniejsi operatorzy działają często na 5–10 kluczowych aktywach, mają gorące portfele w multisigu i zewnętrzny monitoring. Problemem nie jest sama technologia, lecz spójne zebranie dowodów aktywów i zobowiązań oraz ich cykliczna, publiczna publikacja w sposób odporny na manipulację.

• Aktywa (Assets): Salda na łańcuchach (BTC, ETH, L2, ERC‑20, stablecoiny), depozyty w custody/multisig, rezerwy w CEX (jeśli występują).
• Zobowiązania (Liabilities): Sumaryczne salda klientów (w tym ujemne), naliczone odsetki, bonusy, niezaksięgowane depozyty/wypłaty w toku.
• Spójność: Dowód, że Assets ≥ Liabilities dla każdego aktywa oraz ogółem.

Architektura referencyjna PoR dla małego operatora

Warstwa węzłów i danych

• BTC: Pełny węzeł Bitcoin Core (txindex=1), okresowy gettxoutsetinfo dla walidacji sum UTXO i skryptów multisig.
• ETH / ERC‑20: Lekki własny węzeł (pruned) + zaufany dostawca RPC jako fallback; snapshot bloków N-koordynowanych czasowo.
• L2 (np. Arbitrum/Optimism/Polygon PoS): Własny indexer dla adresów gorących/zimnych + eventy transferów tokenów.
• Stablecoiny: Te same zasady co ERC‑20; dodatkowo monitoruj blacklisty/freeze eventy emitenta.

Warstwa dowodów

• Assets Proof: Lista publicznych adresów custody (gorące/zimne) + podpisane komunikaty „Proof of Control” (np. wiadomość Bitcoin/Ethereum) i on-chain zdarzenie sygnujące snapshot.
• Liabilities Proof: Drzewo Merkle z zanonimizowanymi identyfikatorami klientów i saldami; opcjonalnie ZK‑dowód prawidłowej sumy i braku ujemnych pozycji.
• Anchor: Hash pakietu dowodów publikowany jako transakcja OP_RETURN (BTC) i/lub event w smart-kontrakcie (ETH/L2).

Krok po kroku: jak policzyć aktywa na różnych łańcuchach

1) Bitcoin (model UTXO)

• Zbierz listę adresów kontrolowanych (w tym zmianę) z etykietami: HOT, WARM, COLD.
• Utwórz transakcję message-sign lub krótki spend test (np. dust) z multisiga, aby potwierdzić kontrolę.
• Na bloku referencyjnym B pobierz salda UTXO tych adresów i zsumuj nominalnie i wg rodzajów skryptów (P2WSH/P2TR).

2) Ethereum i ERC‑20 (model kontowy)

• Na bloku B weź eth_getBalance dla adresów oraz balanceOf(addr) dla tokenów.
• Zapewnij atomowy snapshot – wszystkie odczyty z tego samego numeru bloku; archiwizuj ID zapytania i odpowiedzi.

3) Rollupy L2

• Zsynchronizuj numer bloku L2 z timestampem i, jeśli to możliwe, z odpowiednim zakotwiczeniem w L1.
• Ustal politykę ryzyka na wypadek reorgów L2 (krótkie okna potwierdzeń dla PoR są akceptowalne, jeśli anchor publikujesz po N blokach).

4) Rezerwy w CEX (jeśli używasz)

• Wymagaj od instytucji custody podpisanego oświadczenia + API do sald w punkcie czasu; minimalizuj ten element, bo osłabia PoR.

Zobowiązania: Merkle i warianty z ZK

Po stronie zobowiązań nie chcesz ujawniać pełnej listy klientów, ale chcesz, aby każdy mógł zweryfikować, że jego saldo jest ujęte, a suma wszystkich pozycji zgadza się z aktywami.

Merkle Liabilities (minimum produkcyjne)

• Dla każdego klienta generujesz węzeł: hash(salt || user_id_mask || asset_symbol || balance_atomic).
• Budujesz drzewo Merkle oddzielnie dla każdego aktywa (BTC, ETH, USDT, itp.).
• Publikujesz root + metodę, jak klient pobierze swój proof path (API lub plik do pobrania).
• Dodajesz dowód sumy: publikujesz sumę wszystkich balance_atomic (zaokrągloną w dół do jednostki atomowej) oraz hash listy wag/zaokrągleń, by uniemożliwić „kosmetykę” centów.

ZK‑Liabilities (prywatność + spójność)

• Dowód, że każda pozycja w drzewie spełnia balance ≥ 0 bez ujawniania konkretnych wartości (np. Bulletproofs zakresu lub PLONK z constraints).
• Dowód, że suma pozycji w drzewie = S (opublikowana) – bez ujawniania składu listy.
• Stack narzędzi: gnark / halo2 / Bulletproofs (biblioteki powszechnie stosowane w 2024 r.).

Publiczny „anchor” i harmonogram publikacji

• Okno publikacji: np. co 7 dni, w stałym dniu i godzinie UTC.
• Anchor BTC: transakcja z OP_RETURN zawierającym hash pakietu PoR (SHA‑256) i numer snapshotu.
• Anchor ETH/L2: event w prostym kontrakcie PorRegistry z polami: chainId, asset, blockNumber, merkleRoot, assetsSum.
• Repozytorium: spakowany artefakt (assets.json, liabilities.json, merkle_roots.txt, proofs/) z podpisem GPG i timelockiem publikacyjnym (np. 24 h po snapshotcie).

Tabela: Metody PoR – co wybrać na start

Metoda	Co dowodzi	Zalety	Ryzyka/Ograniczenia	Koszt wdrożenia
Adresy + podpisy	Kontrolę aktywów on-chain	Proste, weryfikowalne publicznie	Nie dowodzi zobowiązań	Niski
Merkle Liabilities	Ujęcie sald klientów	Każdy klient weryfikuje swój węzeł	Potencjalny wyciek metadanych, brak dowodu „≥ 0”	Niski/Średni
Merkle + Range ZK	Brak ujemnych sald, spójna suma	Silniejsza prywatność i integralność	Większa złożoność, generacja dowodów	Średni
Audit on-chain (anchor)	Niezmienialność pakietu PoR	Odporność na „window dressing”	Koszty transakcyjne, potrzeba dyscypliny	Niski

Bezpieczeństwo: jak uniknąć „window dressing” i innych sztuczek

• Okno snapshotu T publikuj z 24 h opóźnieniem i zakotwicz hash pakietu w dwóch łańcuchach (BTC + ETH) – trudniej zsynchronizować manipulację.
• Zakaz pożyczek krótkoterminowych w polityce ryzyka na 48 h przed snapshotem; log audytowy z podpisami zarządu.
• Oddzielenie skarbca firmowego (operacyjnego) od rezerw klientów na poziomie adresów i księgi.
• Multisig z różnymi HSM (np. 2 dostawców) i co najmniej jednym kluczem w air‑gap.
• Monitor opóźnień – jeżeli PoR nie pojawi się w oknie, system automatycznie publikuje alarm na stronie statusowej i mediach społecznościowych.

Regulacje & Prawo (UE/PL – wysokopoziomowo)

• RODO/priv: Hashuj i solisz identyfikatory, nie publikuj surowych danych klientów; przechowuj salta oddzielnie.
• KYC/AML: PoR nie zwalnia z obowiązków AML; transakcje kotwiczące PoR nie mogą naruszać polityk sankcyjnych.
• Sprawozdawczość: PoR to dowód techniczny, nie zastępuje formalnego audytu finansowego, ale go uzupełnia.

Case study (hipotetyczny): kantor „ZetX” – 5 200 klientów, 7 aktywów

• Aktywa:
  • BTC: 96.42 BTC (P2WSH 2/3, 3 adresy COLD, 1 HOT)
  • ETH: 2 140.7 ETH (2 adresy HOT, 1 COLD)
  • USDT (ETH): 3.2 mln
  • USDC (ETH): 1.1 mln
  • ARB (Arbitrum): 820k
  • OP (Optimism): 410k
  • MATIC (Polygon PoS): 3.9 mln
• Zobowiązania (suma klientów): odpowiednio: 95.77 BTC; 2 102.9 ETH; 3.12 mln USDT; 1.08 mln USDC; 801k ARB; 392k OP; 3.81 mln MATIC.
• Marża bezpieczeństwa: 0.5–2.5% na aktywo; polityka utrzymania ≥1% bufora.
• Publikacja: co piątek 18:00 UTC; hash pakietu w BTC i event w kontrakcie PorRegistry na Ethereum i Arbitrum.
• Weryfikacja klienta: front generuje ścieżkę Merkle po zalogowaniu; opcjonalny proof-of-inclusion przez skrypt CLI.

Plan 30 dni: od zera do PoR 2.0

Najczęstsze błędy i jak je naprawić

• „Znikające centy”: Zaokrąglasz w dół? Opublikuj sumę zaokrągleń i hash listy korekt.
• Adresy mieszane firmowe/klienckie: Natychmiast rozdziel na osobne pule i migruj środki.
• Snapshot z różnych bloków: Użyj block tag we wszystkich zapytaniach; archiwizuj numer bloku.
• Brak prywatności: Sól per użytkownik + rotacja; nie używaj przewidywalnych maskowań ID.

Narzędzia & procedury (praktyczne)

• Bitcoin: bitcoin-cli gettxoutsetinfo; parser UTXO dla listy adresów; podpis wiadomości z multisiga (PSBT).
• Ethereum/L2: eth_getBalance i balanceOf z parametrem blockNumber; własny mały indexer transferów.
• Merkle: biblioteka drzew (np. z weryfikacją ścieżek), ważne: stałe sortowanie i kanoniczny encoding.
• ZK: gotowe przykłady range proof (gnark/halo2); pipeline do generacji dowodów per snapshot.
• Anchoring: prosty kontrakt „PorRegistry” + skrypt do emisji eventu; transakcja BTC z OP_RETURN.

Checklist wdrożeniowy (skrót)

• Adresy custody z podpisem kontroli – gotowe
• Snapshot aktywów na bloku B – gotowe
• Drzewa Merkle zobowiązań per aktywo – gotowe
• Range proof „balance ≥ 0” – gotowe/opcjonalnie
• Publiczny anchor (BTC + ETH/L2) – gotowe
• API weryfikacji dla klientów – gotowe
• Polityka antysztuczek + logi – gotowe

Wnioski i następny krok

Dowód Rezerw nie musi być ciężkim projektem korporacyjnym. Z architekturą opisaną wyżej mały operator jest w stanie dostarczyć realną, publiczną gwarancję 1:1 w mniej niż miesiąc – obejmując BTC, ETH, stablecoiny i popularne L2. Klucz do sukcesu to spójny snapshot, publiczny anchor i prosty interfejs dla klientów do samodzielnej weryfikacji.

CTA: Zacznij od Minimum Viable PoR: adresy + podpisy, drzewo Merkle zobowiązań i anchor on-chain. Po stabilizacji dołóż ZK‑range proof. Twoi klienci zauważą różnicę – i wynagrodzą ją zaufaniem.