Portfele AA na Ethereum i L2: ukryte ryzyka guardianów, cenzury sekwencerów i bezpieczny wzorzec odzyskiwania w 2025

Czy Twoje social recovery naprawdę zadziała, gdy jedno z L2 przestanie finalizować bloki lub gdy guardian straci klucze? Portfele z abstrakcją konta (ERC-4337) stały się standardem UX w DeFi, NFT i Web3. Ale wraz z wygodą przyszły nowe wektory ryzyka: zależność od sekwencerów L2, budżety Paymasterów, złożone polityki multisig guardianów i „ciche” błędy czasu. Ten artykuł pokazuje, jak te elementy składają się na realny profil ryzyka – oraz jak zbudować konfigurację, która przetrwa awarie pojedynczych warstw.

Jak działa odzyskiwanie w portfelach AA (ERC-4337) – skrót kontekstowy

W modelu AA Twoje konto to smart kontrakt, który egzekwuje własne reguły podpisu i limitów. Operacje są pakowane jako UserOperation i wysyłane do bundlera, a następnie do sieci (L1 lub L2). Odzyskiwanie zwykle polega na tymczasowym uprawnieniu grupy guardianów (EOA, multisig, TSS/MPC lub kontrakty) do zmiany klucza właściciela po upływie timelocka.

• Guardiani: podmioty uprawnione do inicjowania recovery (np. 3 z 5 podpisów).
• Timelock: czas na odwołanie recovery przez właściciela (okno bezpieczeństwa).
• Paymaster: sponsor opłat, który ułatwia transakcje bez posiadania natywnego tokena.

Mniej oczywiste ryzyka w realnych wdrożeniach

1) Cenzura lub awaria sekwencera L2 a odzyskiwanie

Wiele L2 operuje z centralnym sekwencerem i brakiem publicznego mempoola. To zwiększa ryzyko opóźnień lub selektywnej cenzury transakcji recovery, zwłaszcza gdy guardiany działają wyłącznie na tej warstwie. Jeśli timelock upływa na L2, ale nie możesz wymusić publikacji transakcji, okno bezpieczeństwa traci sens.

• Skutek: blokada możliwości odwołania recovery lub przejęcie konta przez agresora, który ma uprzywilejowany dostęp do sekwencera.
• Mitigacja: kotwica L1 – recovery inicjowane i finalizowane kontraktowo na L1, z możliwością „force inclusion” dowodu na L1 (jeśli L2 to wspiera).

2) „Guardian Sybil” i korelacja kluczy

Trzech różnych guardianów nie oznacza trzech niezależnych wektorów ryzyka, jeśli wszyscy używają tej samej infrastruktury (ten sam dostawca MPC, ta sama chmura lub to samo L2). Korelacja powoduje, że pozornie wysoki próg (np. 3/5) może w praktyce sprowadzać się do jednego punktu awarii.

• Skutek: kompromitacja wspólnego dostawcy lub regionu chmurowego unieważnia quorum.
• Mitigacja: heterogeniczny zestaw guardianów (L1 EOA na sprzęcie, multisig DAO, hardware wallet, TSS u niezależnego dostawcy, guardian kontraktowy z timelockiem).

3) Budżety i polityki Paymasterów

Gdy korzystasz z Paymastera, transakcje recovery mogą nie przejść w godzinach szczytu (limit budżetu, zmiany polityk KYC lub whitelisting metod). Recovery to zazwyczaj kosztowna sekwencja operacji – brak fallbacku do natywnego gasu blokuje proces.

• Skutek: martwy punkt – timelock mija, ale transakcja nie jest sponsorowana.
• Mitigacja: zawsze definiuj tryb awaryjny z natywnym gazem i adresami „ratunkowymi” posiadającymi minimalny depozyt na L1 i docelowych L2.

4) Dryf czasu i okna odwołania

Różne sieci mogą mieć inny zegar bloków i finalność. Jeśli timelock mierzysz według bloków L2, a publikacja stanu na L1 opóźnia się, okno może skurczyć się lub wydłużyć nieprzewidywalnie.

• Mitigacja: definiuj timelock w sekundach wg L1 (timestamp L1) oraz wymuszaj publikację dowodu/zdarzenia na L1.

Architektury guardianów – porównanie

Architektura	Opis	Zalety	Wady	Gdzie pasuje
EOA na L1 (3/5)	Klasyczne adresy EOA jako guardiany, podpis na L1	Prosta weryfikacja, minimalna zależność od L2	UX słabsze, wymagane fee na L1	Klucze główne, długoterminowe przechowywanie
Multisig (np. Safe) jako guardian	Kontrakt multisig z własnym timelockiem	Elastyczne polityki, łatwa rotacja sygnatariuszy	Złożoność i koszty transakcji	DAO, zespoły, custody instytucjonalne
TSS/MPC	Podpis progowy bez ujawniania klucza	Brak pojedynczego klucza, dobra skalowalność	Zaufanie do operatora/oprogramowania, ryzyko korelacji	Mobile/web UX, integracje z aplikacjami
Kontrakt społecznościowy	Guardiani jako lista adresów z web-of-trust	Przejrzystość on-chain, możliwość reputacji	Ekspozycja prywatności, zarządzanie listą	Twórcy, społeczności, projekty open-source
Hardware wallet jako guardian	Fizyczny podpis z urządzenia	Wysoki poziom bezpieczeństwa, offline	UX wolniejsze, ryzyko utraty urządzenia	Klucz awaryjny, cold storage

Minimalny bezpieczny wzorzec konfiguracji 2025 (portfele AA na L1 + L2)

• Guardiani: 5 heterogenicznych podmiotów – 1× hardware EOA (L1), 1× multisig DAO (L1), 1× TSS/MPC niezależnego dostawcy, 1× EOA na oddzielnym L2, 1× kontrakt społecznościowy. Quorum: 3/5.
• Timelock: liczony w sekundach względem L1 i emitujący zdarzenie na L1; minimalnie 48–96 h dla środków > średniej wartości portfela.
• Kotwica L1: recovery inicjowane i finalizowane on-chain na L1; transakcje na L2 jako opcjonalna ścieżka przyspieszająca, ale nie wymagana do bezpieczeństwa.
• Paymaster: tryb hybrydowy – priorytet natywnego gazu w recovery; Paymaster tylko jako wygodny fallback. Utrzymuj rezerwę gazu na L1 i głównych L2.
• Tryb awaryjny: metoda w kontrakcie właściciela AA, która blokuje niekrytyczne funkcje i ustawia wyższy timelock, gdy wykryto próbę recovery lub nietypową aktywność.
• Telemetria: monitorowanie zdarzeń „RecoveryInitiated”, „RecoveryCanceled”, „GuardianRotated” na L1 i L2; alerty poza łańcuchem.

DIY: jak przetestować niezawodność recovery bez ryzyka dla środków

1. Załóż konto testowe AA na L2 oraz jego odpowiednik na L1. Ustal guardianów zgodnie z docelową polityką.
2. Włącz timelock na minimalną wartość (np. 1–2 h) tylko w środowisku testowym. Wpłać małe środki testowe.
3. Symuluj:
   • brak dostępności jednego guardian’a (wyłącz urządzenie),
   • niedostępność Paymastera (wyłącz sponsorowanie),
   • czasowe opóźnienia L2 (wysyłaj w porach wysokiego obciążenia).
4. Wymuś kotwicę L1: inicjuj i anuluj recovery poprzez L1; upewnij się, że finalizacja nie wymaga L2.
5. Pomiar: loguj opóźnienia, liczbę prób, użyty gaz i statusy transakcji. Sprawdź, czy „cancel” zawsze wyprzedza „finalize” przy tym samym timelocku.

Metryki, które warto śledzić

Metryka	Dlaczego ważna	Docelowa wartość
Czas od „initiate” do „finalize”	Weryfikuje realny timelock	≥ ustawiony timelock na L1
Skuteczność „cancel”	Ostatnia linia obrony	100% w oknie timelocku
Dostępność guardianów	Unikasz martwych quorum	≥ 99% w horyzoncie 30 dni
Udział transakcji bez Paymastera	Odporność na polityki sponsora	Możliwe 100% w trybie awaryjnym

Studium przypadku: portfel zespołu DeFi działający na L2

• Sytuacja: zespół zarządza płynnością na dwóch L2 i ma guardianów wyłącznie na tych warstwach; recovery bazuje na Paymasterze.
• Problem: podczas szczytu rynkowego Paymaster odrzuca transakcje recovery; jednocześnie jedno L2 ma opóźnienia publikacji stanu na L1.
• Refaktoryzacja: dodanie guardianów L1 (EOA + multisig), przeniesienie logiki timelocku i finalizacji na L1, ustanowienie bufora gazu na L1 oraz „trybu awaryjnego” w kontrakcie.
• Efekt: możliwość anulowania recovery niezależnie od stanu L2, spójność okna czasowego i mniejsze ryzyko korelacji guardianów.

Pro / Contra krótkie podsumowanie

Aspekt	Pro	Contra
AA (ERC-4337)	Lepszy UX, polityki podpisów, automatyzacja	Złożoność, nowe wektory ryzyka
Guardiani heterogeniczni	Odporność na awarie pojedynczej warstwy	Więcej operacji i koordynacji
Kotwica L1	Finalność niezależna od L2	Wyższe koszty gazu
Paymaster	UX bez posiadania natywnego tokena	Ryzyko budżetów i polityk w szczycie

Checklist bezpieczeństwa przed wdrożeniem

• Czy recovery można w pełni przeprowadzić i anulować wyłącznie na L1?
• Czy guardianów jest przynajmniej 5 i czy są heterogeniczni (sprzęt, L1/L2, różni dostawcy)?
• Czy timelock liczony jest według czasu L1 i emituje zdarzenia na L1?
• Czy istnieje rezerwa gazu na L1 i głównych L2 dla adresów awaryjnych?
• Czy kontrakt portfela ma tryb awaryjny i proceduralne „cancel” na L1?
• Czy rotacja guardianów jest możliwa bez utraty quorum i bez przestojów?
• Czy masz monitoring i alerty dla zdarzeń recovery i nietypowych wywołań metod?

FAQ – krótkie odpowiedzi

• Czy jeden guardian MPC wystarczy? Nie – zwiększa UX, ale nie zastępuje heterogenicznego quorum.
• Czy Paymaster poprawia bezpieczeństwo? Nie – poprawia UX. Bezpieczeństwo zwiększa kotwica L1 i zróżnicowani guardiani.
• Czy timelock na L2 jest bezpieczny? Może być pomocniczy, ale kluczowe decyzje powinny mieć finalność L1.

Wnioski i następne kroki

Największym wrogiem social recovery jest korelacja zależności: wspólni dostawcy, ta sama warstwa publikacji i sponsorzy opłat. Ustandaryzuj politykę, w której finalność decyzji leży na L1, guardiani są heterogeniczni, a recovery ma awaryjny tryb bez Paymastera. Przetestuj cały proces na małych środkach i mierz metryki z tabeli.

CTA: Jeśli budujesz portfel lub DAO-treasury, zrób 48‑godzinny sprint hardeningu: dodaj guardianów L1, włącz timelock w sekundach L1, przygotuj rezerwę gazu i scenariusz „cancel na L1”. To prosty zestaw zmian, który realnie zmniejsza ryzyko utraty środków.