Prywatna bramka czy publiczny rejestr — co wybrać pod MiCA
Pierwszy element to warstwa wystawcy. Niezależny podmiot sprawdza tożsamość poza łańcuchem, a następnie wystawia użytkownikowi poświadczenie — najczęściej w formie podpisanego komunikatu lub tokenu, który da się wykorzystać w obiegu zdecentralizowanym. Ważne, żeby poświadczenie było powiązane z portfelem, a nie z adresem IP czy sesją. Drugi element to kontrakt weryfikujący, który sprawdza dowód ZK i wypuszcza dalej tylko tych, którzy mają ważne poświadczenie. Trzeci to mechanizm revokacji — gdy użytkownik straci status, bramka musi to zauważyć.<br>
<br>
<br>
<br>
ERC-4337 zmienia sposób, w jaki bramka działa. Konta abstrakcyjne pozwalają na własną logikę walidacji — zamiast sprawdzać podpis w konkretnym formacie, kontrakt weryfikuje, czy operacja użytkownika zawiera ważny dowód ZK i czy nie narusza reguł zgodności. Płacenie za gaz sponsorowane przez podmiot zgodny z MiCA jest wygodne, ale wprowadza ryzyko cenzury. Dlatego warto rozdzielić role: paymaster opłaca gaz, ale nie decyduje o dostępie. Decyzję podejmuje odrębny moduł walidacji, który można wymienić bez migracji środków.<br>
<br>
<br>
<br>
Najczęstsze pułapki to przechowywanie danych osobowych w calldata, brak rotacji kluczy wystawcy i pomieszanie tożsamości z reputacją. Dane osobowe nie mogą trafiać do łańcucha nawet w formie zaszyfrowanej, jeśli klucz jest jawny. Klucz wystawcy trzeba rotować i publikować nowy, a stare poświadczenia wygaszać. Reputacja to osobny temat — nie powinna być warunkiem dostępu, bo to już nie zgodność, a ranking.<br>
<br>
<br>
<br>
Najczęstsze błędy: brak testu odtworzenia, trzymanie wszystkich udziałów Shamira u jednej osoby, timelock ustawiony na sztywną datę bez planu na wypadek twojej śmierci przed nią oraz brak informacji, gdzie w ogóle leżą udziały i jaki portfel obsługuje daną politykę. Krypto-spadkobranie to nie jednorazowy akt, lecz proces, który trzeba co jakiś czas przejrzeć i zaktualizować, gdy zmieniają się ludzie i urządzenia.<br>
<br>
<br>
<br>
Decentralizacja nie znika, jeśli bramka jest opcjonalna i modularna. Protokół może działać bez niej, a podmioty regulowane podłączają własną instancję. Kluczowe jest, by logika weryfikacji była publiczna i wymienna, a nie ukryta w zamkniętym serwisie. Wtedy ZK-KYC staje się jednym z wielu adapterów, a nie warunkiem istnienia protokołu.<br>
<br>
<br>
<br>
SUAVE to krok dalej: warstwa, w której transakcje są przetwarzane w sposób poufny i porównywane przez wielu wykonawców. Zamiast ufać jednemu RPC, oddajesz transakcję do sieci, która konkuruje o jak najlepsze wykonanie, nie znając twoich granic. W praktyce oznacza to, że twoja transakcja może zostać wykonana szybciej i taniej, a nadwyżka wraca do ciebie, a nie do przypadkowego bota. Minus jest taki, że SUAVE jest wciąż we wczesnej fazie. Interfejsy bywają surowe, a dokumentacja nie odpowiada na wszystkie pytania. Nie testuj tego na transakcjach, których nie możesz powtórzyć.<br>
<br>
<br>
<br>
Frontrunning to sytuacja, w której twoja transakcja trafia do publicznego mempoola i zanim zostanie włączona do bloku, ktoś inny kopiuje jej sens, podbija opłatę i wykonuje ją przed tobą. Traci nie tylko ten, kto chciał kupić token taniej. Tracisz także ty, gdy twoja transakcja zostaje wysłana z opóźnieniem, gdy swap wykona się po gorszej cenie albo gdy twoja likwidacja zostanie wyprzedzona. Problem nie leży w tym, że blockchain jest publiczny. Problem leży w tym, że kolejka transakcji jest publiczna, zanim staną się one nieodwracalne.<br>
<br>
<br>
<br>
Rozporządzenie MiCA nie zakazuje DeFi, ale wymusza na podmiotach, które chcą działać legalnie w Unii, identyfikację klientów. Problem w tym, że klasyczny KYC oznacza oddanie pełnych danych osobowych do protokołu, a to kłóci się z ideą niepowierniczego dostępu. Rozwiązaniem jest bramka zgodności oparta na dowodach zero-knowledge (ZK), która potwierdza uprawnienie użytkownika bez ujawniania, kim on jest. Zamiast wysyłać skan dowodu do inteligentnego kontraktu, wysyła się dowód, że taki skan istnieje i został zweryfikowany przez zaufanego wystawcę.<br>
<br>
<br>
<br>
Account abstraction to zmiana sposobu, w jaki konta w sieci Ethereum są zbudowane i obsługiwane. Klasyczne konto jest albo zewnętrznie posiadane (EOA), albo kontraktem. EOA wymaga klucza prywatnego i podpisu transakcji, co oznacza, że każda operacja musi zaczynać się od posiadacza klucza. Abstrakcja konta odwraca ten model: to kontrakt definiuje zasady, kto i jak może zainicjować transakcję. Dzięki temu portfel może działać jak aplikacja z logiką, a nie tylko jako para klucz–adres.<br>
<br>
<br>
<br>
Revokacja i ERC-4337 bez oddawania kontroli Revokacja to najczęściej pomijany element projektowania. Jeśli poświadczenie jest nieodwoływalne, podmiot nadzorowany nie spełni wymogu bieżącej kontroli. Praktyka jest taka: poświadczenie ma krótki okres ważności, a wystawca publikuje listę unieważnień — najlepiej jako drzewo Merkle'a lub akumulator. Kontrakt bramki sprawdza nie tylko ważność dowodu, ale i to, czy dany identyfikator nie znajduje się na liście unieważnień. Uwaga na typowy błąd: trzymanie całej listy na łańcuchu w postaci jawnej tablicy. To drogie i ujawnia wzorce aktywności. Lepiej publikować korzeń drzewa i pozwalać użytkownikowi dostarczyć dowód przynależności.