Jak sprawdzić Proof of Reserves, zanim wpłacisz środki

From BloomWiki
Jump to navigation Jump to search

Pierwszy krok to wybór, co właściwie chcesz udowodnić. Inne wymagania ma giełda przy wypłacie, inne DAO przy głosowaniu nad budżetem, inne protokół RWA przy zapisie na listę uprawnionych. Nadmiar kryteriów podnosi koszt dowodu i zniechęca użytkowników, brak kryteriów czyni cały mechanizm teatrem. Wypisz minimalny zestaw twierdzeń, których potrzebujesz, i trzymaj się go. Typowy błąd to kopiowanie checklisty z tradycyjnego AML bez zastanowienia, czy każde pole jest naprawdę konieczne.

Zacznij od źródła dokumentu. Raport powinien pochodzić od niezależnego audytora lub firmy zajmującej się analizą blockchain, a nie być wyłącznie oświadczeniem działu marketingu giełdy. Sprawdź datę publikacji i częstotliwość aktualizacji. Pojedynczy raport sprzed roku nie mówi nic o dzisiejszym stanie rezerw. Jeśli giełda podaje tylko łączną sumę aktywów bez metody liczenia zobowiązań, traktuj to jako materiał promocyjny, nie jako dowód.

Od strony zgodności z MiCA i eIDAS 2.0 liczy się to, kto ponosi odpowiedzialność. Jeśli DeFi tylko weryfikuje dowód, a nie przechowuje danych, jego rola jest bliżej weryfikatora technicznego niż administratora danych osobowych. To nie zwalnia z obowiązku rejestracji działalności, jeśli usługa ma charakter zarobkowy i jest kierowana do klientów z UE. Praktyczna rada: przed pierwszym wdrożeniem ustal z prawnikiem, kto jest administratorem danych w łańcuchu: wystawca, portfel czy protokół. Bez tego ZK-KYC daje fałszywe poczucie bezpieczeństwa prawnego.

Intenty: zamiast zlecenia — warunek Intenty odwracają logikę. Nie mówisz „wykonaj swap na tej parze", ale „chcę mieć taki efekt, jeśli warunki są spełnione". Solverzy konkurują o realizację Twojego zamiaru, a Ty nie wystawiasz po drodze podpisu, który ktoś może przechwycić i wykorzystać. To ogranicza klasyczny frontrunning, bo nie ma jawnego zlecenia w mempoolu. Uważaj jednak na dwie rzeczy: solver może nie być neutralny, a warunek intentu musi być precyzyjny. Zbyt ogólne „wymień cokolwiek na cokolwiek" otwiera pole do realizacji po niekorzystnym kursie.

Implementację zaczyna się od rozdzielenia ról. Portfel użytkownika (np. na telefonie) przechowuje poświadczenia wystawione przez zaufanego wystawcę — bank, notariusza, licencjonowanego dostawcę tożsamości. Wystawca weryfikuje dane raz, podpisuje poświadczenie kluczem prywatnym i przekazuje je do portfela. Wystawca nie dowiaduje się, gdzie użytkownik później użyje poświadczenia. To kluczowa różnica wobec klasycznego KYC, gdzie każda platforma dostaje pełny zestaw danych i musi go zabezpieczyć.

Publiczny mempool to kolejka transakcji widoczna dla każdego, zanim trafią do bloku. To właśnie tam powstaje sandwich: bot widzi Twoje zlecenie, dokłada własne przed i po nim, przesuwa cenę i pobiera różnicę. Prywatny mempool działa inaczej — transakcja nie jest rozgłaszana całej sieci, tylko przekazywana bezpośrednio do wybranych walidatorów lub builderów. Efekt: nikt nie zdąży jej uprzedzić. To nie jest ukrywanie się przed prawem, to zmiana kolejności dostępu do informacji.

Co robić konkretnie: po pierwsze, ustawiaj widełki na tyle szeroko, by pokryć zmienność i opłaty, ale nie szerzej, niż jesteś gotów zaakceptować. Po drugie, sprawdź, czy protokół pozwala na częściowe wypełnienie i jak wtedy wygląda rozliczenie. Po trzecie, testuj na małych kwotach, zanim powierzysz większe zlecenie. Po czwarte, czytaj, kto jest solverem i czy istnieje mechanizm odwołania lub wycofania intencji przed rozliczeniem.

Praktyka wygląda tak: w portfelu lub narzędziu do handlu wybierasz endpoint RPC prowadzący do prywatnego relayu. Adres transakcji podpisujesz normalnie, ale zamiast wysyłać ją do publicznego węzła, kierujesz ją kanałem prywatnym. Uwaga na typowy błąd: prywatny mempool nie oznacza, że transakcja nie trafi do łańcucha — trafi, tylko bez wyścigu. Drugi błąd to wysyłanie tam transakcji, które i tak muszą być publiczne (np. interakcje z kontraktami wymagającymi widoczności stanu) — wtedy prywatność nic nie daje.

ePBS, czyli proposer-builder separation w wersji enshrined, przenosi aukcję bloków do protokołu. Walidator nie musi ufać zewnętrznym relayom, a builder nie może podmienić zawartości bloku po tym, jak go zbudował. Dla handlującego oznacza to mniej miejsca na ukryte reorderingi i większą przewidywalność, że transakcja zostanie uwzględniona tak, jak ją złożono. W praktyce: jeśli Twoje narzędzie wspiera ePBS, wybieraj je zamiast starych relayów, które wciąż mają luki w egzekwowaniu zobowiązań buildera.

Najprostszy zestaw na start: prywatny kanał wysyłki dla transakcji DeFi, intent tam, gdzie protokół go wspiera, i sprawdzenie, czy narzędzie rozlicza rabaty. Nie każda transakcja wymaga prywatności — drobne swapy w płynnych parach często nie są celem sandwichy. Testuj na małych kwotach, porównuj wykonanie z publicznym mempoolem i wyłączaj prywatność tam, gdzie nie daje przewagi.