Beosin: EIP-7702 i analiza audytu bezpieczeństwa portfela AA nowej generacji

Abstrakcja konta (AA) to ważny kierunek długoterminowej eksploracji w ekosystemie Ethereum, mający na celu przełamanie granicy między kontami zewnętrznymi (EOA) a kontami kontraktowymi, tak aby portfel miał większą programowalność, bezpieczeństwo i możliwość aktualizacji. EIP-4337 jest obecnie najbardziej popularnym rozwiązaniem wdrożeniowym AA i jest szeroko stosowane w wielu portfelach inteligentnych kontraktów opartych na EntryPoint (takich jak Safe, Stacks i Argent). Jednak EIP-4337 nadal ma pewne ograniczenia pod względem natywności on-chain, złożoności operacyjnej i kompatybilności ekologicznej ze względu na wprowadzenie niezależnej puli transakcji i mechanizmu kontraktów on-ramp.

Aby jeszcze bardziej obniżyć barierę wejścia i zwiększyć natywną obsługę abstrakcji kont, Vitalik zaproponował EIP-7702 w 2024 roku i włączył go do aktualizacji Pectra. Podstawową ideą EIP-7702 jest umożliwienie oryginalnemu EOA wykonania kodu kontraktu (contract_code) określonego adresu podczas inicjowania transakcji i użycia tego kodu do zdefiniowania logiki wykonania transakcji.

EIP-7702 wprowadza nowy mechanizm "wstrzykiwania kodu na poziomie transakcji", który umożliwia kontom użytkowników dynamiczne określanie logiki wykonywania w każdej transakcji, zamiast polegać na wstępnie wdrożonym kodzie kontraktu. Zrywa to z tradycyjnym statycznym modelem uprawnień opartym na kodzie, zapewnia większą elastyczność i wprowadza nowe wyzwania związane z bezpieczeństwem: kontrakty, które opierają się na logice oceny, takie jak isContract i extcodehash, mogą stać się nieważne, a niektóre systemy, które zakładają, że wywołujący jest czystym EOA, mogą również zostać pominięte. Dla audytorów ważne jest nie tylko zweryfikowanie bezpieczeństwa samego wstrzykniętego kodu, ale także ocena jego potencjalnego wpływu na inne systemy kontraktowe w dynamicznym kontekście.

W tym artykule zespół ds. bezpieczeństwa Beosin skupi się na zasadach projektowania i kluczowych cechach EIP-7702, systematycznie sortuje zagrożenia bezpieczeństwa, na które może napotkać portfel AA zbudowany na jego podstawie podczas audytu, a także przedstawi proces audytu i sugestie z praktycznej perspektywy, aby pomóc badaczom bezpieczeństwa lepiej radzić sobie z wyzwaniami technicznymi w ramach tego nowego paradygmatu.

1. Wprowadzenie do EIP-77021

. EIP-7702

Przegląd technicznyEIP-7702 wprowadza nowy typ transakcji, 0x 04 (SetCode), który umożliwia EOA autoryzację kodu kontraktu, który musi zostać wykonany za pośrednictwem tej transakcji, z następującą strukturą transakcji:

1. rlp([chain_id, nonce, max_priority_fee_per_gas, max_ fee_per_gas, gas_limit,

2. miejsce docelowe, wartość, dane, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Tam, gdzie authorization_list zawiera wiele list autoryzacji i może również zawierać akcje autoryzacji podmiotów niebędących inicjatorami transakcji, struktura wewnętrzna jest następująca:

1. authorization_list = [[chain_id, adres, nonce, y_parity, r, s]].

gdzie chain_id reprezentuje łańcuch, w którym następuje autoryzacja użytkownika, a jego wartość musi być równa identyfikatorowi łańcucha wykonującego lub 0. Gdy chain_id wynosi 0, autoryzacja zaczyna obowiązywać dla wszystkich łańcuchów EVM, które obsługują EIP-7702, ale tylko wtedy, gdy inne parametry (takie jak nonce) są zgodne. Adres wskazuje docelowy adres umowy autoryzowany przez użytkownika.

Po zakończeniu autoryzacji system zmodyfikuje pole kodu autoryzowanego użytkownika na adres 0x ef 0100 ||, gdzie adres jest adresem autoryzowanej umowy. Jeśli chcesz cofnąć autoryzację, po prostu zainicjuj transakcję SetCode z adresem ustawionym na 0.

cyfra arabska. Zalety EIP 7702

(1) Elastyczność i personalizacja

Abstrakcyjne kontaPisząc logikę konta do inteligentnych kontraktów, możesz elastycznie dostosowywać funkcje do swoich potrzeb. Na przykład użytkownicy mogą konfigurować wiele podpisów, odzyskiwanie społecznościowe i kontrolę przydziałów, aby spełnić potrzeby użytkowników indywidualnych lub przedsiębiorstw w różnych scenariuszach. Taki projekt znacznie poprawia funkcjonalną skalowalność konta i przełamuje ograniczenia tradycyjnych kont zewnętrznych (EOA).

(2) Zwiększone

bezpieczeństwoKonta abstrakcyjne zapewniają wielowarstwowy mechanizm bezpieczeństwa, w tym uwierzytelnianie wieloskładnikowe, limity transakcji i odzyskiwanie społecznościowe. Nawet jeśli użytkownik utraci klucz prywatny, może odzyskać swoje konto za pomocą zaufanych kontaktów lub uwierzytelniania wieloskładnikowego, unikając trwałej utraty aktywów spowodowanej utratą klucza prywatnego na tradycyjnych kontach. Jednocześnie funkcje takie jak kontrola limitów mogą również zapobiegać złośliwej kradzieży dużych kwot środków.

(3)

Konto Zoptymalizowanego Poboru Gazu obsługuje elastyczny mechanizm poboru gazu, umożliwiając użytkownikom płacenie za gaz za pośrednictwem strony trzeciej, a nawet bezpośrednie używanie innych tokenów do uiszczania opłat transakcyjnych. Mechanizm ten nie tylko obniża koszty operacyjne użytkowników, ale także jeszcze bardziej upraszcza korzystanie z blockchaina, co jest szczególnie przydatne dla początkujących użytkowników lub złożonych wieloetapowych scenariuszy transakcji.

(4) Promuj popularyzację Web3Optymalizując

doświadczenie i bezpieczeństwo, abstrakcyjne konta ukrywają złożoność łańcucha bloków w miejscach, których użytkownicy nie widzą, zapewniając wygodne operacje bliżej Web2. Taki projekt obniża koszty nauki zwykłych użytkowników, pozwala większej liczbie osób bez barier uczestniczyć w aplikacjach Web3 i promuje popularyzację zdecentralizowanej technologii.

2. Analiza zagrożeń bezpieczeństwa w EIP-7702 w praktyce

Chociaż EIP-7702 wstrzyknął nowy impuls do ekosystemu Ethereum i rozszerzył bogactwo scenariuszy zastosowań, jednocześnie nieuchronnie wprowadził pewne nowe zagrożenia bezpieczeństwa:

1. Atak powtórzeniowy autoryzacji

W modelu EIP-7702, jeśli użytkownik autoryzuje chain_ Jeśli pole id jest ustawione na 0, autoryzacja może zostać zastosowana w wielu łańcuchach. Chociaż ten projekt "uniwersalnej autoryzacji między łańcuchami" poprawia elastyczność w niektórych scenariuszach, wprowadza również oczywiste zagrożenia bezpieczeństwa.

Ważne jest, aby pamiętać, że nawet jeśli tożsamość konta pod tym samym adresem jest taka sama w różnych łańcuchach, realizacja umowy, która za tym stoi, może być zupełnie inna. Oznacza to, że osoba atakująca może wdrożyć złośliwą wersję kontraktu w innym łańcuchu i wykonać niezamierzone działania przy użyciu autoryzacji tego samego adresu w łańcuchu, stwarzając w ten sposób ryzyko dla aktywów użytkownika.

W związku z tym, w przypadku dostawców usług portfela lub platform interakcji front-end, gdy użytkownicy wykonują takie operacje autoryzacji, powinni wyraźnie zweryfikować, czy chainId zadeklarowany w autoryzacji użytkownika jest zgodny z aktualną siecią połączeń; Jeśli zostanie wykryty, że użytkownik ustawia chainId na 0, powinno zostać wyświetlone wyraźne ostrzeżenie o ryzyku, aby przypomnieć użytkownikowi, że autoryzacja zostanie zastosowana we wszystkich łańcuchach kompatybilnych z EVM i może być nadużywana przez złośliwe kontrakty.

Ponadto dostawca usług powinien również ocenić, czy domyślnie ograniczyć lub zabronić autoryzacji za pomocą chainId 0 w warstwie interfejsu użytkownika, aby zmniejszyć ryzyko niewłaściwego działania lub ataków phishingowych.

2. Kompatybilność kontraktów

1) Kompatybilność wywołań zwrotnych kontraktów

przesyłania pieniędzy na adres kontraktu dla istniejących kontraktów tokenowych, takich jak ERC-721, ERC-777 i ERC 1155, wywołają standardowe interfejsy wywołania zwrotnego (takie jak onERC 721 Received, tokensReceived), aby zakończyć operację transferu. Jeśli adres odbiorczy nie implementuje odpowiedniego interfejsu, transfer zakończy się niepowodzeniem lub nawet spowoduje zablokowanie zasobu.

W EIP-7702 adres użytkownika może zostać przekształcony w konto kontraktowe poprzez otrzymanie kodu kontraktu za pomocą operacji "set_code". W tym przypadku:

• Adres użytkownika jest traktowany jako umowa;

• Jeśli kontrakt nie implementuje niezbędnego interfejsu wywołania zwrotnego, transfer tokenów zakończy się niepowodzeniem;

• Użytkownicy mogą nie być w stanie otrzymać tokenów głównego nurtu bez ich wiedzy.

W związku z tym programiści powinni upewnić się, że kontrakt docelowy delegowany przez użytkownika implementuje odpowiedni interfejs wywołania zwrotnego, aby zapewnić kompatybilność z tokenami głównego nurtu.

(2) Weryfikacja "tx.origin" kończy się niepowodzeniemW

tradycyjnych umowach "tx.origin" jest często używany do określenia, czy transakcja jest bezpośrednio zainicjowana przez użytkownika, i służy do zapobiegania kontrolom bezpieczeństwa, takim jak wezwania do zawarcia umowy.

Jednak w scenariuszu EIP-7702

• użytkownik podpisuje transakcję autoryzacji, a przekaźnik lub pakiet emituje ją w imieniu użytkownika. Gdy transakcja jest wykonywana, "tx.origin" jest adresem przekaźnika, a nie adresem użytkownika.

• "Msg.sender" to kontrakt portfela, który reprezentuje tożsamość użytkownika.

W związku z tym weryfikacja uprawnień na podstawie "tx.origin == msg.sender" spowoduje, że legalne operacje użytkownika zostaną odrzucone i stracą niezawodność, a te same ograniczone wywołania umowy, takie jak "tx.origin == user", również zostaną unieważnione. Zaleca się porzucenie "tx.origin" jako podstawy oceny bezpieczeństwa i zamiast tego użycie mechanizmu weryfikacji podpisu lub autoryzacji.

(3) "isContract" błędnie ocenia Wiele

kontraktów uniemożliwia kontom kontraktowym udział w niektórych operacjach, takich jak airdropy, błyskawiczne wyprzedaże itp., poprzez "isContract(address)":

require(!isContract(msg.sender), "Kontrakty niedozwolone").

W ramach mechanizmu EIP-7702 adres użytkownika może zostać zmieniony na konto kontraktowe poprzez transakcję "set_code", a "isContract" zwraca wartość true, a kontrakt błędnie zidentyfikuje prawowitego użytkownika jako konto kontraktowe i odmówi udziału w operacji, co spowoduje, że użytkownik nie będzie mógł korzystać z niektórych usług i doświadczenie zostanie zablokowane.

Wraz ze stopniową popularyzacją portfeli kontraktowych, projektowanie polegania na "isContract" w celu określenia, czy "ludzki użytkownik" nie jest już bezpieczny, i zaleca się stosowanie dokładniejszych metod identyfikacji użytkownika, takich jak weryfikacja podpisu.

3. Atak phishingowyPo

wdrożeniu mechanizmu delegowania EIP-7702, aktywa na koncie użytkownika będą w pełni kontrolowane przez delegowany smart kontrakt. Gdy użytkownik autoryzuje złośliwą umowę, atakujący może uzyskać pełną kontrolę nad aktywami konta, co spowoduje szybki przelew lub kradzież środków, co jest niezwykle ryzykowne.

W związku z tym w przypadku dostawców usług portfelowych konieczne jest jak najszybsze wsparcie mechanizmu rozwiązywania transakcji EIP-7702 i identyfikacji ryzykaZasadniczy. Gdy użytkownik podpisuje transakcję powierzenia, interfejs użytkownika powinien wyraźnie i wyraźnie wyświetlać docelowy adres umowy oraz łączyć informacje pomocnicze, takie jak informacje o źródle umowy i wdrożeniu, aby pomóc użytkownikom zidentyfikować potencjalne zachowania wyłudzające informacje lub oszukańcze, zmniejszając w ten sposób ryzyko błędnego podpisania. Co więcej, usługa portfela powinna integrować możliwości automatycznej analizy bezpieczeństwa dla kontraktu docelowego, takie jak sprawdzanie statusu kodu kontraktu na otwartym kodzie źródłowym, analiza modelu uprawnień i identyfikacja potencjalnie niebezpiecznych operacji, aby pomóc użytkownikom w podejmowaniu bezpieczniejszych osądów przed autoryzacją.

W szczególności EIP-7702 wprowadza format podpisu delegowanego, który nie jest zgodny z istniejącymi standardami podpisów EIP-191 i EIP-712. Jego podpis może łatwo ominąć oryginalne ostrzeżenie o podpisie i monit o interakcję portfela, co dodatkowo zwiększa ryzyko, że użytkownicy zostaną oszukani i podpiszą złośliwe operacje. W związku z tym wprowadzenie mechanizmu identyfikacji i przetwarzania struktury podpisu w implementacji portfela będzie kluczowym ogniwem zapewniającym bezpieczeństwo użytkowników.

4. Ryzyko związane z kontraktami portfela

( 1) Zarządzanie uprawnieniami do zawierania umów portfela

Wiele kontraktów portfela EIP-7702 przyjmuje architekturę proxy (lub wbudowane uprawnienia do zarządzania) w celu obsługi aktualizacji logicznych. Wiąże się to jednak również z większym ryzykiem związanym z zarządzaniem prawami. Jeśli uprawnienia do eskalacji nie są ściśle ograniczone, atakujący może zastąpić umowę wdrożeniową i wstrzyknąć złośliwy kod, co spowoduje naruszenie konta użytkownika lub kradzież środków.

Zalecenia dotyczące zabezpieczeń

• : Użyj mechanizmów wielu podpisów, uwierzytelniania wieloskładnikowego lub blokady czasowej, aby kontrolować uprawnienia eskalacji.

• Zmiany w kodzie i uprawnieniach podlegają rygorystycznej inspekcji i weryfikacji zabezpieczeń.

• Proces aktualizacji jest otwarty i przejrzysty, aby zapewnić użytkownikom prawo do wiedzy i uczestnictwa.

(2) Ryzyko konfliktów pamięci masowej i izolacji danych,

wersje umowy portfela lub różni dostawcy usług portfela mogą ponownie wykorzystać to samo miejsce przechowywania. Jeśli użytkownik zmieni dostawcę usług portfela lub zaktualizuje logikę portfela, ponowne użycie miejsca do przechowywania spowoduje konflikt zmiennych stanu, nadpisywanie danych, wyjątki odczytu i inne problemy. Może to nie tylko zakłócić normalne funkcjonowanie portfela, ale może również prowadzić do utraty środków lub nieprawidłowych uprawnień.

Zalecenia dotyczące zabezpieczeń:

• Użyj wyspecjalizowanego schematu izolacji magazynu, takiego jak standard EIP-1967, lub użyj unikatowej przestrzeni nazw do zarządzania miejscami magazynu.

• Podczas uaktualniania umowy upewnij się, że układ magazynu jest zgodny i unikaj nakładania się zmiennych.

• Rygorystycznie przetestuj wiarygodność przechowywanego stanu podczas procesu uaktualniania.

(3) Zarządzanie nonce'ami w portfelu

Kontrakt portfela zwykle tworzy nonce w środku i zarządza sobą, aby zapewnić kolejność wykonywania operacji użytkownika i zapobiec atakom typu replay. Jeśli identyfikator jednorazowy zostanie użyty nieprawidłowo, operacja użytkownika nie zostanie wykonana poprawnie.

Zalecenie dotyczące zabezpieczeń:

• Identyfikator jednorazowy musi być wymuszony pod kątem równoważnej wartości (lub przyrostu) i nie można go pominąć.

• Zabronione jest, aby funkcje bezpośrednio modyfikowały jednostkę jednorazową, a identyfikator jednorazowy będzie aktualizowany tylko wtedy, gdy wykonywana jest operacja użytkownika.

• Zaprojektuj mechanizmy odporności na uszkodzenia i odzyskiwania dla wyjątków jednorazowych, aby uniknąć zakleszczeń jednorazowych.

(4) Sprawdzanie uprawnień wywołującego funkcjęW

celu zapewnienia bezpieczeństwa, umowa portfela musi zapewnić, że osoba wywołująca kluczową funkcję jest właścicielem konta portfela. Dwie popularne metody obejmują:

• podpisywanie poza łańcuchem upoważnia

użytkowników do podpisania zestawu operacji za pomocą klucza prywatnego, a kontrakt portfela sprawdza, czy podpis jest legalny, wygasły i spełnia odpowiedni numer jednorazowy w łańcuchu. Ta metoda ma zastosowanie do trybu transakcji przekazywania zalecanego przez EIP-7702 (podpis offline użytkownika + przekaźnik wysyła transakcję w imieniu użytkownika).

• Ograniczenie połączenia (msg.sender == address(this))

funkcja akcji użytkownika może być wyzwalana tylko przez sam kontrakt, który jest zasadniczo mechanizmem kontroli ścieżki wywołania, który zapewnia, że zewnętrznym inicjatorem musi być samo konto. Jest to w rzeczywistości równoznaczne z wymaganiem, aby wywołujący był pierwotnym EOA, ponieważ adres kontraktu jest adresem EOA.

3. Perspektywy: Propozycja EIP-7702 i przyszłego standardu portfela AA

EIP-7702 jest nie tylko innowacją tradycyjnego modelu konta, ale także główną promocją ekosystemu abstrakcji kont. Wprowadzona przez niego możliwość wczytywania kodu kontraktu daje szerokie pole do eksploracji dla przyszłego projektowania portfela i systemu umów, a także stawia nowe wymagania dotyczące standardów audytu bezpieczeństwa.

1. Wspólna ewolucja z EIP-4337: W kierunku kompatybilności w dwóch trybachChociaż

EIP-7702 i EIP-4337 mają różne cele projektowe, pierwszy z nich rekonstruuje mechanizm ładowania kodu konta, a drugi buduje kompletny ekosystem wprowadzania i pakowania transakcji. Jednak te dwa elementy nie są ze sobą sprzeczne, ale mają silną komplementarność:

● EIP-4337 zapewnia "wspólny kanał transakcji" i "abstrakcyjny interfejs wykonywania kont";

● EIP-7702 umożliwia kontom użytkowników dynamiczne nadawanie funkcji logiki kontraktu bez zmiany adresu;

Dlatego w przyszłości portfele mogą przyjąć "architekturę wsparcia w dwóch trybach": używaj EIP-7702 jako lekkiego zamiennika w łańcuchach, które nie obsługują EIP-4337 i nadal polegaj na pełnym stosie protokołów EIP-4337 w scenariuszach, które wymagają pakowania poza łańcuchem i agregacji wielu użytkowników.

Ten podwójny mechanizm umożliwi również portfelom obsługę bardziej elastycznych modeli uprawnień do kont, mechanizmów downgrade i schematów wycofywania w warstwie jądra.

2. Wsparcie i inspiracja dla nowej logiki portfela, takiej jak MPC i ZK, oraz

mechanizm kontraktów kont zalecany przez EIP-7702 ma naturalny potencjał integracji z obecnie popularnym portfelem MPC, portfelem ZK, portfelem modułowym i innymi nowymi architekturami:

● W modelu MPC zachowanie podpisu nie opiera się już na pojedynczym kluczu prywatnym, ale jest wielostronnym wspólnym podejmowaniem decyzji. Podpisy generowane przez konwergencję EIP-7702 i MPC kontrolują dynamicznie ładowaną logikę kontraktu, umożliwiając bardziej elastyczne strategie realizacji.

● Portfel ZK weryfikuje tożsamość użytkownika lub autoryzację za pomocą dowodów zerowej wiedzy, bez ujawniania informacji o kluczu prywatnym. W połączeniu z EIP-7702, portfele ZK mogą tymczasowo wstrzykiwać określone kontrakty logiczne po zakończeniu weryfikacji, aby zrealizować wdrożenie spersonalizowanych zachowań po obliczeniach prywatności, takich jak automatyczne wykonywanie określonej logiki dopiero po spełnieniu określonych warunków prywatności.

● Portfele modułowe mogą używać EIP-7702 do demontażu logiki konta na wiele modułów i dynamicznego ładowania ich w razie potrzeby.

Dlatego EIP-7702 zapewnia bardziej natywny "kontener wykonawczy" dla wyżej wymienionych zaawansowanych portfeli: różne logiki kontraktów mogą być wstrzykiwane z tym samym adresem użytkownika, unikając problemu zależności adresu w tradycyjnym procesie wdrażania kontraktów i eliminując potrzebę wstępnego wdrożenia, znacznie poprawiając elastyczność i kombinację zachowań kont.

3. Implikacje dla wykonawców kontraktów i

spowoduje głęboką zmianę paradygmatu rozwoju. Deweloperzy kontraktów nie traktują już po prostu dzwoniącego jako tradycyjnego EOA lub konta na stałą umowę, ale muszą dostosować się do nowego mechanizmu: tożsamość dzwoniącego może być dynamicznie przełączana między EOA a statusem kontraktu podczas transakcji, a logika zachowania konta nie jest już statycznie ustalona, ale może być elastycznie zmieniana w zależności od zapotrzebowania. Wymaga to od programistów i audytorów:

• wprowadzenia bardziej rygorystycznej logiki weryfikacji dzwoniącego i oceny uprawnień;

• Sprawdź, czy na ścieżkę wywołania ma wpływ logika kontraktu dynamicznego;

• identyfikować potencjalne luki w zabezpieczeniach, które opierają się na zachowaniach takich jak msg.sender.code.length == 0, isContract() itp.;

• Wyjaśnienie "zależności kontekstowych" logiki kontraktu, takich jak kontrola granic wywołań statycznych i wywołań delegowanych;

• Na poziomie łańcucha narzędzi obsługiwana jest symulacja i analiza przywracania scenariuszy setCode.

Innymi słowy, bezpieczeństwo kodu nie jest już tylko "problemem przed wdrożeniem", ale "dynamicznym procesem, który musi być weryfikowany podczas wywołania i transakcji".

4.

wprowadza lżejszą, natywną i elastyczną implementację Abstrakcji Konta (AA), dzięki czemu zwykła EOA może przenosić logikę kontraktu i wykonywać ją w jednej transakcji. Mechanizm ten przełamuje tradycyjne statyczne założenia dotyczące zachowania konta, a deweloperzy nie mogą już po prostu polegać na stanie kodu adresu konta w celu oceny jego modelu zachowania, ale muszą zrekonstruować zrozumienie granicy tożsamości i uprawnień wywołującego.

Wraz z tym następuje zmiana paradygmatu w analityce bezpieczeństwa. Audyt nie ogranicza się już do tego, "czy adres ma uprawnienia", ale do tego, "co logika umowy zawarta w transakcji może zrobić w obecnym kontekście". Każda transakcja może być opatrzona niezależną definicją zachowania, co nadaje kontu większą funkcjonalność i stawia wyższe wymagania dotyczące audytów bezpieczeństwa.