Pectra 7702

Streszczenie

EIP-7702 definiuje mechanizm dodawania kodu do EOA (zewnętrznie posiadanego konta). Ta propozycja pozwala EOA, starszym kontom Ethereum, na otrzymywanie krótkoterminowych ulepszeń funkcjonalności, zwiększając użyteczność aplikacji. Odbywa się to poprzez ustawienie wskaźnika do już wdrożonego kodu przy użyciu nowego typu transakcji: 4.

Ten nowy typ transakcji wprowadza listę autoryzacji. Każda krotka autoryzacji na liście jest zdefiniowana jako

[ chain_id, address, nonce, y_parity, r, s ]

address to delegowanie (już wdrożony kod bajtowy, który będzie używany przez EOA) chain_id blokuje autoryzację do określonego łańcucha (lub 0 dla wszystkich łańcuchów) nonce blokuje autoryzację do określonego nonce konta (y_parity, r, s) to podpis krotki autoryzacji, zdefiniowany jako keccak(0x05 || rlp ([chain_id ,address, nonce])) przez klucz prywatny EOA, którego dotyczy autoryzacja (zwanego również autorytetem)

Delegowanie można zresetować, delegując na adres zerowy (null address).

Klucz prywatny EOA zachowuje pełną kontrolę nad kontem po delegowaniu. Na przykład delegowanie do Safe nie sprawia, że konto staje się multisigiem, ponieważ nadal istnieje pojedynczy klucz, który może ominąć dowolną politykę podpisywania. W przyszłości programiści powinni projektować z założeniem, że każdy uczestnik systemu może być inteligentnym kontraktem. Dla programistów inteligentnych kontraktów nie jest już bezpieczne zakładanie, że tx.origin odnosi się do EOA.

Najlepsze praktyki

Abstrakcja konta: Kontrakt delegowania powinien być zgodny z szerszymi standardami abstrakcji konta (AA) Ethereum, aby zmaksymalizować kompatybilność. W szczególności powinien być idealnie zgodny lub kompatybilny z ERC-4337.

Projekt niewymagający pozwoleń i odporny na cenzurę: Ethereum ceni uczestnictwo niewymagające pozwoleń. Kontrakt delegowania NIE MOŻE na stałe kodować ani polegać na żadnym pojedynczym „zaufanym” przekaźniku (relayer) lub usłudze. Spowodowałoby to zablokowanie konta, jeśli przekaźnik przeszedłby w tryb offline. Funkcje takie jak wsadowanie (np. approve+transferFrom) mogą być używane przez samo EOA bez przekaźnika. Dla programistów aplikacji, którzy chcą korzystać z zaawansowanych funkcji umożliwianych przez EIP-7702 (abstrakcja gazu, wypłaty chroniące prywatność), potrzebny będzie przekaźnik. Chociaż istnieją różne architektury przekaźników, naszą rekomendacją jest użycie bundlerów ERC-4337 (otwiera się w nowej karcie) wskazujących co najmniej punkt wejścia (entry point) 0.8 (otwiera się w nowej karcie), ponieważ:

• Zapewniają ustandaryzowane interfejsy do przekazywania
• Zawierają wbudowane systemy paymaster
• Zapewniają kompatybilność w przód
• Mogą wspierać odporność na cenzurę poprzez publiczny mempool (otwiera się w nowej karcie)
• Mogą wymagać, aby funkcja inicjująca (init) była wywoływana tylko z EntryPoint (otwiera się w nowej karcie)

Innymi słowy, każdy powinien móc działać jako sponsor/przekaźnik transakcji, o ile dostarczy wymagany ważny podpis lub operację użytkownika (UserOperation) z konta. Zapewnia to odporność na cenzurę: jeśli nie jest wymagana żadna niestandardowa infrastruktura, transakcje użytkownika nie mogą być arbitralnie blokowane przez przekaźnik pełniący rolę strażnika (gatekeeper). Na przykład Delegation Toolkit od MetaMask (otwiera się w nowej karcie) jawnie współpracuje z dowolnym bundlerem lub paymasterem ERC-4337 na dowolnym łańcuchu, zamiast wymagać serwera specyficznego dla MetaMask.

Integracja zdecentralizowanych aplikacji (dapp) przez interfejsy portfeli:

Biorąc pod uwagę, że portfele będą umieszczać na białej liście określone kontrakty delegowania dla EIP-7702, zdecentralizowane aplikacje (dapp) nie powinny oczekiwać bezpośredniego żądania autoryzacji EIP-7702. Zamiast tego integracja powinna odbywać się poprzez ustandaryzowane interfejsy portfeli:

• ERC-5792 (wallet_sendCalls): Umożliwia zdecentralizowanym aplikacjom (dapp) żądanie od portfeli wykonania wsadowanych wywołań, ułatwiając funkcjonalności takie jak wsadowanie transakcji i abstrakcja gazu.

• ERC-6900: Pozwala zdecentralizowanym aplikacjom (dapp) na wykorzystanie możliwości modułowych inteligentnych kont, takich jak klucze sesji i odzyskiwanie konta, poprzez moduły zarządzane przez portfel.

Wykorzystując te interfejsy, zdecentralizowane aplikacje (dapp) mogą uzyskać dostęp do funkcjonalności inteligentnego konta zapewnianych przez EIP-7702 bez bezpośredniego zarządzania delegowaniami, zapewniając kompatybilność i bezpieczeństwo w różnych implementacjach portfeli.

Uwaga: Nie ma ustandaryzowanej metody dla zdecentralizowanych aplikacji (dapp) do bezpośredniego żądania podpisów autoryzacji EIP-7702. Zdecentralizowane aplikacje (dapp) muszą polegać na określonych interfejsach portfeli, takich jak ERC-6900, aby skorzystać z funkcji EIP-7702.

Więcej informacji:

• Specyfikacja ERC-5792 (otwiera się w nowej karcie)
• Specyfikacja ERC-6900 (otwiera się w nowej karcie)

Unikanie uzależnienia od dostawcy (Vendor Lock-In): Zgodnie z powyższym, dobra implementacja jest neutralna dla dostawcy i interoperacyjna. Często oznacza to przestrzeganie pojawiających się standardów dla inteligentnych kont. Na przykład Modular Account od Alchemy (otwiera się w nowej karcie) wykorzystuje standard ERC-6900 dla modułowych inteligentnych kont i jest zaprojektowane z myślą o „niewymagającym pozwoleń, interoperacyjnym użyciu”.

Ochrona prywatności: Chociaż prywatność onchain jest ograniczona, kontrakt delegowania powinien dążyć do zminimalizowania ujawniania danych i możliwości ich powiązania. Można to osiągnąć poprzez wspieranie funkcji takich jak płatności za gaz w tokenach ERC-20 (dzięki czemu użytkownicy nie muszą utrzymywać publicznego salda ETH, co poprawia prywatność i UX) oraz jednorazowe klucze sesji (które zmniejszają zależność od pojedynczego klucza długoterminowego). Na przykład EIP-7702 umożliwia płacenie za gaz w tokenach poprzez sponsorowane transakcje, a dobra implementacja ułatwi integrację takich paymasterów bez wycieku większej ilości informacji niż to konieczne. Dodatkowo, pozałańcuchowe delegowanie niektórych zatwierdzeń (przy użyciu podpisów, które są weryfikowane onchain) oznacza mniej transakcji onchain z głównym kluczem użytkownika, co wspomaga prywatność. Konta, które wymagają użycia przekaźnika, zmuszają użytkowników do ujawnienia swoich adresów IP. Publiczne mempoole (PublicMempools) poprawiają to; gdy transakcja/operacja użytkownika (UserOp) propaguje się przez mempool, nie można stwierdzić, czy pochodzi z adresu IP, który ją wysłał, czy tylko została przez niego przekazana za pośrednictwem protokołu p2p.

Rozszerzalność i modułowe bezpieczeństwo: Implementacje kont powinny być rozszerzalne, aby mogły ewoluować wraz z nowymi funkcjami i ulepszeniami bezpieczeństwa. Możliwość aktualizacji jest z natury możliwa dzięki EIP-7702 (ponieważ EOA zawsze może delegować do nowego kontraktu w przyszłości, aby zaktualizować swoją logikę). Poza możliwością aktualizacji, dobry projekt pozwala na modułowość – np. moduły wtyczek dla różnych schematów podpisów lub polityk wydatków – bez konieczności całkowitego ponownego wdrażania. Account Kit od Alchemy jest doskonałym przykładem, pozwalającym programistom na instalowanie modułów walidacji (dla różnych typów podpisów, takich jak ECDSA, BLS itp.) oraz modułów wykonawczych dla niestandardowej logiki. Aby osiągnąć większą elastyczność i bezpieczeństwo na kontach z włączonym EIP-7702, zachęca się programistów do delegowania do kontraktu proxy, a nie bezpośrednio do określonej implementacji. Takie podejście pozwala na płynne aktualizacje i modułowość bez wymagania dodatkowych autoryzacji EIP-7702 dla każdej zmiany.

Zalety wzorca Proxy:

• Możliwość aktualizacji: Zaktualizuj logikę kontraktu, wskazując proxy na nowy kontrakt implementacji.

• Niestandardowa logika inicjalizacji: Włącz funkcje inicjalizacji w ramach proxy, aby bezpiecznie skonfigurować niezbędne zmienne stanu.

Na przykład SafeEIP7702Proxy (otwiera się w nowej karcie) pokazuje, jak można wykorzystać proxy do bezpiecznej inicjalizacji i zarządzania delegowaniami na kontach kompatybilnych z EIP-7702.

Wady wzorca Proxy:

• Poleganie na podmiotach zewnętrznych: Musisz polegać na zewnętrznym zespole, że nie zaktualizuje do niebezpiecznego kontraktu.

Kwestie bezpieczeństwa

Zabezpieczenie przed ponownym wejściem: Wraz z wprowadzeniem delegowania EIP-7702, konto użytkownika może dynamicznie przełączać się między kontem posiadanym zewnętrznie (EOA) a inteligentnym kontraktem (SC). Ta elastyczność umożliwia kontu zarówno inicjowanie transakcji, jak i bycie celem wywołań. W rezultacie scenariusze, w których konto wywołuje samo siebie i wykonuje wywołania zewnętrzne, będą miały msg.sender równe tx.origin, co podważa pewne założenia bezpieczeństwa, które wcześniej opierały się na tym, że tx.origin zawsze jest EOA.

Dla programistów inteligentnych kontraktów nie jest już bezpieczne zakładanie, że tx.origin odnosi się do EOA. Podobnie, używanie msg.sender == tx.origin jako zabezpieczenia przed atakami reentrancji nie jest już niezawodną strategią.

W przyszłości programiści powinni projektować z założeniem, że każdy uczestnik systemu może być inteligentnym kontraktem. Alternatywnie mogliby zaimplementować jawną ochronę przed reentrancją, używając zabezpieczeń przed ponownym wejściem ze wzorcami modyfikatorów nonReentrant. Zalecamy stosowanie audytowanego modyfikatora, np. Reentrancy Guard od OpenZeppelin (otwiera się w nowej karcie). Mogą również użyć zmiennej pamięci przejściowej (transient storage) (otwiera się w nowej karcie).

Kwestie bezpieczeństwa inicjalizacji

Wdrażanie kontraktów delegowania EIP-7702 wprowadza specyficzne wyzwania związane z bezpieczeństwem, w szczególności dotyczące procesu inicjalizacji. Krytyczna podatność pojawia się, gdy funkcja inicjująca (init) jest atomowo powiązana z procesem delegowania. W takich przypadkach frontrunner mógłby przechwycić podpis delegowania i wykonać funkcję init ze zmienionymi parametrami, potencjalnie przejmując kontrolę nad kontem.

Ryzyko to jest szczególnie istotne przy próbie użycia istniejących implementacji inteligentnych kont (SCA) z EIP-7702 bez modyfikowania ich mechanizmów inicjalizacji.

Rozwiązania łagodzące podatności inicjalizacji

• Zaimplementuj initWithSig
  Zastąp standardową funkcję init funkcją initWithSig, która wymaga od użytkownika podpisania parametrów inicjalizacji. Takie podejście zapewnia, że inicjalizacja może być kontynuowana tylko za wyraźną zgodą użytkownika, co łagodzi ryzyko nieautoryzowanej inicjalizacji.

• Wykorzystaj EntryPoint z ERC-4337
  Wymagaj, aby funkcja inicjująca była wywoływana wyłącznie z kontraktu EntryPoint ERC-4337. Ta metoda wykorzystuje ustandaryzowane ramy walidacji i wykonywania zapewniane przez ERC-4337, dodając dodatkową warstwę bezpieczeństwa do procesu inicjalizacji.
  (Zobacz: Dokumentacja Safe (otwiera się w nowej karcie))

Przyjmując te rozwiązania, programiści mogą zwiększyć bezpieczeństwo kontraktów delegowania EIP-7702, chroniąc przed potencjalnymi atakami typu frontrunning podczas fazy inicjalizacji.

Kolizje pamięci (Storage Collisions) Delegowanie kodu nie czyści istniejącej pamięci. Podczas migracji z jednego kontraktu delegowania do drugiego, pozostają resztkowe dane z poprzedniego kontraktu. Jeśli nowy kontrakt wykorzystuje te same sloty pamięci, ale interpretuje je inaczej, może to spowodować niezamierzone zachowanie. Na przykład, jeśli początkowe delegowanie dotyczyło kontraktu, w którym slot pamięci reprezentuje bool, a kolejne delegowanie dotyczy kontraktu, w którym ten sam slot reprezentuje uint, niedopasowanie może prowadzić do nieprzewidywalnych rezultatów.

Ryzyko phishingu Wraz z wdrożeniem delegowania EIP-7702, aktywa na koncie użytkownika mogą być całkowicie kontrolowane przez inteligentne kontrakty. Jeśli użytkownik nieświadomie deleguje swoje konto do złośliwego kontraktu, atakujący może łatwo przejąć kontrolę i ukraść środki. Podczas używania chain_id=0 delegowanie jest stosowane do wszystkich identyfikatorów łańcuchów (chain ids). Deleguj tylko do niezmiennego kontraktu (nigdy nie deleguj do proxy) i tylko do kontraktów, które zostały wdrożone przy użyciu CREATE2 (ze standardowym kodem inicjującym - bez kontraktów metamorficznych), aby wdrażający nie mógł wdrożyć czegoś innego pod tym samym adresem w innym miejscu. W przeciwnym razie Twoje delegowanie naraża Twoje konto na ryzyko na wszystkich innych łańcuchach EVM.

Gdy użytkownicy wykonują delegowane podpisy, docelowy kontrakt otrzymujący delegowanie powinien być wyraźnie i widocznie wyświetlany, aby pomóc złagodzić ryzyko phishingu.

Minimalna zaufana powierzchnia i bezpieczeństwo: Oferując elastyczność, kontrakt delegowania powinien utrzymywać swoją podstawową logikę na minimalnym poziomie i umożliwiać jej audyt. Kontrakt jest w rzeczywistości rozszerzeniem EOA użytkownika, więc każda wada może być katastrofalna. Implementacje powinny postępować zgodnie z najlepszymi praktykami społeczności zajmującej się bezpieczeństwem inteligentnych kontraktów. Na przykład funkcje konstruktora lub inicjatora muszą być starannie zabezpieczone – jak podkreśla Alchemy, w przypadku korzystania ze wzorca proxy w ramach 7702, niezabezpieczony inicjator mógłby pozwolić atakującemu na przejęcie konta. Zespoły powinny dążyć do zachowania prostoty kodu onchain: kontrakt 7702 od Ambire ma tylko ~200 linii w Solidity, celowo minimalizując złożoność w celu zmniejszenia liczby błędów. Należy znaleźć równowagę między bogatą w funkcje logiką a prostotą, która ułatwia audyt.

Znane implementacje

Ze względu na naturę EIP-7702, zaleca się, aby portfele zachowały ostrożność podczas pomagania użytkownikom w delegowaniu do kontraktu strony trzeciej. Poniżej znajduje się zbiór znanych implementacji, które zostały poddane audytowi:

Wytyczne dla portfeli sprzętowych

Portfele sprzętowe nie powinny udostępniać arbitralnego delegowania. Konsensus w przestrzeni portfeli sprzętowych polega na używaniu listy zaufanych kontraktów delegujących. Sugerujemy zezwolenie na znane implementacje wymienione powyżej i rozpatrywanie innych indywidualnie dla każdego przypadku. Ponieważ delegowanie EOA do kontraktu daje kontrolę nad wszystkimi aktywami, portfele sprzętowe powinny zachować ostrożność w sposobie implementacji 7702.

Scenariusze integracji dla aplikacji towarzyszących

Leniwa (Lazy)

Ponieważ EOA nadal działa jak zwykle, nie ma nic do zrobienia.

Uwaga: niektóre aktywa mogą zostać automatycznie odrzucone przez kod delegowania, takie jak NFT ERC-1155, a wsparcie techniczne powinno być tego świadome.

Świadoma (Aware)

Powiadom użytkownika, że dla EOA istnieje delegowanie, sprawdzając jego kod, i opcjonalnie zaoferuj usunięcie delegowania.

Powszechne delegowanie

Dostawca sprzętu umieszcza na białej liście znane kontrakty delegowania i implementuje ich obsługę w oprogramowaniu towarzyszącym. Zaleca się wybór kontraktu z pełną obsługą ERC-4337.

Konta EOA delegowane do innego kontraktu będą traktowane jako standardowe EOA.

Niestandardowe delegowanie

Dostawca sprzętu implementuje własny kontrakt delegowania i dodaje go do list oraz implementuje jego obsługę w oprogramowaniu towarzyszącym. Zaleca się zbudowanie kontraktu z pełną obsługą ERC-4337.

Konta EOA delegowane do innego kontraktu będą traktowane jako standardowe EOA.