Beosin: EIP-7702 a analýza bezpečnostního auditu AA peněženky nové generace

Abstrakce účtů (AA) je důležitým směrem dlouhodobého průzkumu v ekosystému Ethereum, jehož cílem je prolomit hranici mezi externími účty (EOA) a smluvními účty, aby peněženka měla silnější programovatelnost, zabezpečení a upgradovatelnost. EIP-4337 je v současné době nejběžnějším řešením pro implementaci AA a je široce používán v řadě chytrých peněženek založených na EntryPoint (jako jsou Safe, Stacks a Argent). EIP-4337 má však stále určitá omezení, pokud jde o původnost v řetězci, provozní složitost a ekologickou kompatibilitu díky zavedení nezávislého transakčního fondu a mechanismu smluv na rampě.

snížila bariéra vstupu a posílila nativní podpora abstrakcí účtů, navrhl Vitalik v roce 2024 EIP-7702 a zahrnul jej do upgradu Pectra. Základní myšlenkou EIP-7702 je umožnit původnímu EOA provést smluvní kód (contract_code) zadané adresy při zahájení transakce a použít tento kód k definování logiky provádění transakce.

EIP-7702 zavádí nový mechanismus pro "vkládání kódu na úrovni transakce", který umožňuje uživatelským účtům dynamicky specifikovat logiku provádění v každé transakci, místo aby se spoléhaly na předem nasazený kód smlouvy. To narušuje tradiční model oprávnění založený na statickém kódu, přináší větší flexibilitu a přináší nové bezpečnostní výzvy: kontrakty, které se spoléhají na logiku úsudku, jako jsou isContract a extcodehash, se mohou stát neplatnými a některé systémy, které předpokládají, že volající je čistě EOA, mohou být také obejity. Pro auditory je důležité nejen ověřit bezpečnost samotného vloženého kódu, ale také posoudit jeho potenciální dopad na další smluvní systémy v dynamickém kontextu.

V tomto článku se bezpečnostní tým Beosin zaměří na principy návrhu a klíčové funkce EIP-7702, systematicky roztřídí bezpečnostní rizika, kterým může peněženka AA postavená na jejím základě čelit při auditu, a předloží proces auditu a návrhy z praktického hlediska, které pomohou bezpečnostním výzkumníkům lépe se vypořádat s technickými výzvami v rámci tohoto nového paradigmatu.

1. Úvod do EIP-77021

. Technický

přehled EIP-7702EIP-7702 zavádí nový typ transakce, 0x 04 (SetCode), který umožňuje EOA autorizovat kód kontraktu, který je třeba provést prostřednictvím této transakce, s následující strukturou transakce:

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

2. cíl, hodnota, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Tam, kde authorization_list obsahuje více autorizačních seznamů a může také obsahovat autorizační akce netransakčních iniciátorů, je vnitřní struktura následující:

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

kde chain_id představuje řetězec, ve kterém se autorizace uživatele projeví, a jeho hodnota se musí rovnat ID řetězce provádějícího řetězce nebo 0. Pokud je chain_id 0, autorizace se projeví pro všechny řetězce EVM, které podporují EIP-7702, ale pouze v případě, že se shodují jiné parametry (například nonce). Adresa označuje cílovou adresu smlouvy autorizovanou uživatelem.

Po dokončení autorizace systém upraví pole kódu oprávněného uživatele na 0x ef 0100 || adresa, kde adresa je autorizovaná smluvní adresa. Pokud chcete zrušit autorizaci, jednoduše zahajte transakci SetCode s adresou nastavenou na 0.

Ustanovení č. 2010 Výhody EIP 7702

(1) Flexibilita a přizpůsobení

Abstraktní účtyZapsáním logiky účtu do chytrých kontraktů můžete flexibilně přizpůsobit funkce podle svých potřeb. Uživatelé mohou například konfigurovat vícenásobné podpisy, sociální obnovu a řízení kvót tak, aby vyhovovaly potřebám jednotlivců nebo podniků v různých scénářích. Tento návrh výrazně zlepšuje funkční škálovatelnost účtu a prolamuje omezení tradičních externích účtů (EOA).

(2) Enhanced

SecurityAbstract Accounts poskytují vícevrstvý bezpečnostní mechanismus, včetně vícefaktorové autentizace, transakčních limitů a sociální obnovy. I když uživatel ztratí svůj soukromý klíč, může svůj účet obnovit prostřednictvím důvěryhodných kontaktů nebo vícefaktorové autentizace, čímž se vyhne trvalé ztrátě aktiv způsobené ztrátou soukromého klíče u tradičních účtů. Zároveň mohou funkce, jako je kontrola limitů, také zabránit škodlivému odcizení velkého množství finančních prostředků.

(3) Účet pro odběr optimalizovaného plynu

podporuje flexibilní mechanismus odběru plynu, který uživatelům umožňuje platit za plyn prostřednictvím třetí strany a dokonce přímo používat jiné tokeny k placení transakčních poplatků. Tento mechanismus nejen snižuje provozní náklady uživatelů, ale také dále zjednodušuje používání blockchainu, což je vhodné zejména pro začínající uživatele nebo složité vícestupňové transakční scénáře.

(4) Podporujte popularizaci Web3Optimalizací

zážitku a zabezpečení skrývají abstraktní účty složitost blockchainu na místech, která uživatelé nevidí, a poskytují pohodlné operace blíže k Web2. Tento design snižuje náklady na učení běžných uživatelů, umožňuje více lidem účastnit se aplikací Web3 bez bariér a podporuje popularizaci decentralizovaných technologií.

2. Analýza bezpečnostních rizik v EIP-7702 V praxi

Přestože EIP-7702 vnesl do ekosystému Ethereum nový impuls a rozšířil množství aplikačních scénářů, zároveň nevyhnutelně zavedl některá nová bezpečnostní rizika:

1. Útok na přehrání autorizace

Podle modelu EIP-7702, pokud uživatel autorizuje chain_ Pokud je pole id nastaveno na hodnotu 0, může se autorizace projevit na více řetězcích. Ačkoli tento návrh "cross-chain univerzální autorizace" zlepšuje flexibilitu v některých scénářích, přináší také zjevná bezpečnostní rizika.

Je důležité si uvědomit, že i když je identita účtu stejné adresy v různých řetězcích stejná, implementace smlouvy, která za ní stojí, může být zcela odlišná. To znamená, že útočník by mohl nasadit škodlivou verzi smlouvy na jiný chain a provést nezamýšlené akce pomocí autorizace stejné adresy v chainu, čímž by představoval riziko pro aktiva uživatelů.

Proto by poskytovatelé služeb peněženky nebo front-endové interakční platformy měli při provádění takových autorizačních operací jasně ověřit, zda je chainId deklarované v autorizaci uživatele konzistentní s aktuální sítí připojení; Pokud je zjištěno, že uživatel nastavuje chainId na 0, mělo by být poskytnuto jasné varování před rizikem, které uživateli připomene, že autorizace se projeví na všech řetězcích kompatibilních s EVM a může být zneužita škodlivými kontrakty.

Kromě toho by měl poskytovatel služeb také vyhodnotit, zda ve výchozím nastavení ve vrstvě uživatelského rozhraní omezit nebo zakázat autorizaci s chainId 0, aby se snížilo riziko nesprávné obsluhy nebo phishingových útoků.

2. Kompatibilita kontraktů

1) Kompatibilita zpětného volání kontraktu

převodu peněz na smluvní adresu pro stávající tokenové kontrakty, jako jsou ERC-721, ERC-777 a ERC 1155, budou tyto kontrakty volat standardní rozhraní zpětného volání (například onERC 721 Received, tokensReceived) k dokončení operace převodu. Pokud přijímající adresa neimplementuje odpovídající rozhraní, přenos se nezdaří nebo dokonce způsobí uzamčení aktiva.

V EIP-7702 lze uživatelskou adresu transformovat na smluvní účet tím, že jí bude přidělen kód smlouvy prostřednictvím operace "set_code". V tomto případě:

• Adresa uživatele je považována za smlouvu;

• Pokud kontrakt neimplementuje potřebné rozhraní pro zpětné volání, přenos tokenu se nezdaří.

• Uživatelé nemusí být schopni přijímat běžné tokeny bez jejich vědomí.

Vývojáři by proto měli zajistit, aby cílový kontrakt delegovaný uživatelem implementoval příslušné rozhraní zpětného volání, aby byla zajištěna kompatibilita s hlavními tokeny.

(2) Ověření "tx.origin" se nezdaříV

tradičních kontraktech se "tx.origin" často používá k určení, zda je transakce přímo iniciována uživatelem, a používá se k zabránění bezpečnostním kontrolám, jako jsou volání kontraktů.

Ve scénáři EIP-7702 však

• uživatel podepíše autorizační transakci a zprostředkovatel nebo sdružitel ji vyšle jménem uživatele. Když je transakce provedena, "tx.origin" je adresa relayeru, nikoli adresa uživatele.

• "msg.sender" je smlouva o peněžence, která představuje identitu uživatele.

Ověření oprávnění na základě "tx.origin == msg.sender" proto způsobí, že legitimní uživatelské operace budou odmítnuty a ztratí spolehlivost a stejná omezená volání kontraktu, jako je "tx.origin == user", budou také zneplatněna. Doporučuje se opustit "tx.origin" jako základ pro posouzení bezpečnosti a místo toho použít mechanismus ověřování nebo autorizace podpisů.

(3) "isContract" chybně posuzujeMnoho

smluv brání smluvním účtům v účasti na určitých operacích, jako jsou airdropy, bleskové prodeje atd., prostřednictvím "isContract(address)":

require(!isContract(msg.sender), "Contracts not allowed"

). V rámci mechanismu EIP-7702 může být adresa uživatele změněna na smluvní účet prostřednictvím transakce "set_code" a "isContract" vrátí hodnotu true a smlouva chybně identifikuje oprávněného uživatele jako smluvní účet a odmítne se účastnit operace, což má za následek, že uživatel nebude moci používat určité služby a prostředí bude zablokováno.

S postupnou popularizací smluvních peněženek dochází k návrhu spoléhání se na "isContract" při určování, zda "lidský uživatel" již není bezpečný, a doporučuje se používat přesnější metody identifikace uživatele, jako je ověření podpisu.

3. Phishingový útokPo

implementaci mechanismu delegování EIP-7702 budou aktiva v uživatelském účtu plně kontrolována delegovaným inteligentním kontraktem. Jakmile uživatel schválí škodlivý kontrakt, může útočník získat plnou kontrolu nad aktivy účtu, což má za následek rychlý převod nebo krádež finančních prostředků, což je extrémně riskantní.

Pro poskytovatele služeb peněženky je proto nezbytné co nejdříve podpořit mechanismus řešení transakcí a identifikace rizik EIP-7702Zásadní. Když uživatel podepíše transakci pověření, front-end by měl jasně a zřetelně zobrazit cílovou adresu kontraktu a kombinovat podpůrné informace, jako je zdroj kontraktu a informace o nasazení, aby uživatelům pomohly identifikovat potenciální phishing nebo podvodné chování, čímž se sníží riziko chybného podpisu. Služba peněženky by dále měla integrovat funkce automatické analýzy zabezpečení pro cílový kontrakt, jako je kontrola stavu open source kódu kontraktu, analýza modelu oprávnění a identifikace potenciálně nebezpečných operací, aby uživatelům pomohla učinit bezpečnější úsudek před autorizací.

EIP-7702 zejména zavádí formát delegovaného podpisu, který není kompatibilní se stávajícími standardy podpisu EIP-191 a EIP-712. Jeho podpis může snadno obejít původní varování před podpisem a výzvu k interakci peněženky, což dále zvyšuje riziko, že uživatelé budou oklamáni a podepisují škodlivé operace. Zavedení mechanismu identifikace a zpracování podpisové struktury v implementaci peněženky proto bude klíčovým článkem pro zajištění bezpečnosti uživatelů.

4. Rizika smluv o peněžence

( 1) Správa smluvních oprávnění pro peněženku

Mnoho smluv peněženek EIP-7702 využívá architekturu proxy (nebo vestavěná oprávnění pro správu) pro podporu logických upgradů. To však také představuje vyšší riziko správy práv. Pokud nejsou oprávnění k eskalaci striktně omezena, může útočník nahradit implementační smlouvu a vložit škodlivý kód, což má za následek manipulaci s uživatelským účtem nebo krádež finančních prostředků.

Doporučení zabezpečení

• : K řízení oprávnění eskalace použijte mechanismy s více podpisy, vícefaktorové autentizace nebo časového zámku.

• Změny kódu a oprávnění podléhají přísnému auditu a ověření zabezpečení.

• Proces aktualizace je otevřený a transparentní, aby bylo zajištěno právo uživatelů vědět a účastnit se.

(2) Riziko konfliktů při ukládání a izolace dat,

verze smluv o peněžence nebo různí poskytovatelé služeb peněženky mohou opakovaně používat stejný slot pro úložiště. Pokud uživatel změní poskytovatele služeb peněženky nebo upgraduje logiku peněženky, opakované použití slotu úložiště způsobí konflikt stavové proměnné, přepisování dat, výjimky čtení a další problémy. Nejen, že to může narušit normální fungování peněženky, ale může to také vést ke ztrátě finančních prostředků nebo abnormálním oprávněním.

Doporučení zabezpečení:

• Použijte specializované schéma izolace úložiště, jako je standard EIP-1967, nebo využijte jedinečný obor názvů ke správě slotů úložiště.

• Při upgradu smlouvy se ujistěte, že je rozvržení úložiště kompatibilní a vyhněte se překrývání proměnných.

• Během procesu upgradu důkladně otestujte věrohodnost uloženého stavu.

(3) Správa nonce uvnitř peněženky

Kontrakt na peněženku obvykle nastavuje nonce uvnitř a řídí se sám, aby zajistil pořadí provádění uživatelských operací a zabránil útokům na přehrání. Pokud je hodnota nonce použita nesprávně, operace uživatele nebude provedena správně.

Doporučení zabezpečení:

• Nonce musí být vynuceně zkontrolována na ekvivalentní hodnotu (nebo přírůstek) a nelze ji přeskočit.

• Je zakázáno, aby funkce přímo měnily hodnotu nonce a hodnota nonce bude aktualizována pouze při provedení uživatelské operace.

• Navrhněte odolnost proti chybám a mechanismy obnovení pro výjimky nonce, abyste se vyhnuli zablokování nonce.

(4) Kontrola oprávnění volajícího funkceAby

byla zajištěna bezpečnost, musí smlouva o peněžence zajistit, aby volající klíčové funkce byl vlastníkem účtu peněženky. Mezi dvě běžné metody patří:

• off-chain podepisování opravňuje

uživatele podepisovat sadu operací prostřednictvím soukromého klíče a kontrakt peněženky ověřuje, zda je podpis legitimní, vypršela jeho platnost a splňuje odpovídající nonce v řetězci. Tato metoda je použitelná pro režim přenosové transakce doporučovaný EIP-7702 (offline podpis uživatele + relayer odešle transakci jménem uživatele).

• s omezením volání (msg.sender == address(this))

může být spuštěna pouze samotnou smlouvou, což je v podstatě mechanismus řízení cesty volání, který zajišťuje, že externím iniciátorem musí být samotný účet. To je v podstatě ekvivalentní požadavku, aby volající byl původní EOA, protože adresa kontraktu je adresa EOA.

3. Výhled: Návrh EIP-7702 a budoucího standardu AA peněženek

EIP-7702 není jen inovací tradičního modelu účtu, ale také významnou podporou ekosystému abstrakce účtu. Schopnost načítat smluvní kód, kterou zavádí, přináší široký prostor pro zkoumání budoucího návrhu peněženek a smluvního systému a také klade nové požadavky na standardy bezpečnostního auditu.

1. Koevoluce s EIP-4337: Směrem ke kompatibilitě s duálním režimemAčkoli

EIP-7702 a EIP-4337 mají různé cíle návrhu, první rekonstruuje mechanismus načítání kódu účtu a druhý vytváří kompletní ekosystém pro zadávání transakcí a balení. Tyto dva pojmy však nejsou v rozporu, ale silně se doplňují:

● EIP-4337 poskytuje "společný transakční kanál" a "abstraktní rozhraní pro provádění účtů";

● EIP-7702 umožňuje uživatelským účtům dynamicky udělovat možnosti logiky kontraktu bez změny adresy;

Proto mohou peněženky v budoucnu přijmout "architekturu podpory v duálním režimu": používat EIP-7702 jako odlehčenou náhradu v řetězcích, které nepodporují EIP-4337, a nadále se spoléhat na plný zásobník protokolů EIP-4337 ve scénářích, které vyžadují balení mimo řetězec a agregaci více uživatelů.

Tento dvourežimový mechanismus také umožní peněženkám podporovat flexibilnější modely oprávnění účtů, mechanismy downgradu a schémata vrácení zpět na vrstvě jádra.

2. Podpora a inspirace pro novou logiku peněženek, jako jsou MPC a ZK, a

mechanismus smluv o účtu, který prosazuje EIP-7702, má přirozený integrační potenciál se současnou populární peněženkou MPC, peněženkou ZK, modulární peněženkou a dalšími novými architekturami:

● V modelu MPC se chování podpisu již nespoléhá na jediný soukromý klíč, ale jedná se o společné rozhodování více stran. Podpisy generované konvergencí EIP-7702 a MPC řídí dynamicky zatíženou logiku kontraktů, což umožňuje flexibilnější strategie provádění.

● ZK peněženka ověřuje identitu nebo autorizaci uživatele prostřednictvím důkazů s nulovou znalostí, aniž by byly odhaleny informace o soukromém klíči. V kombinaci s EIP-7702 mohou peněženky ZK po dokončení ověření dočasně vkládat specifické logické kontrakty, aby bylo možné realizovat nasazení personalizovaného chování po výpočtu ochrany osobních údajů, jako je automatické spuštění určité logiky až po splnění určitých podmínek ochrany osobních údajů.

● Modulární peněženky mohou pomocí EIP-7702 rozložit logiku účtu do více modulů a v případě potřeby je dynamicky načíst.

Proto EIP-7702 poskytuje pro výše uvedené pokročilé peněženky nativního "prováděcího kontejneru": stejnou uživatelskou adresu lze vložit do různé logiky kontraktů, čímž se vyhne problému se závislostí na adrese v tradičním procesu nasazení kontraktu a eliminuje se potřeba předběžného nasazení, čímž se výrazně zlepší flexibilita a kombinace chování účtu.

3. Důsledky pro smluvní vývojáře a

povede k zásadní změně vývojového paradigmatu. Vývojáři smluv již nepovažují volajícího pouze za tradiční EOA nebo účet s pevnou smlouvou, ale musí se přizpůsobit novému mechanismu: identitu volajícího lze během transakce dynamicky přepínat mezi EOA a stavem smlouvy a logika chování účtu již není staticky upevněna, ale lze ji flexibilně měnit podle poptávky. To vyžaduje, aby vývojáři a auditoři:

• zavedli přísnější logiku ověřování volajícího a posuzování povolení;

• Zkontrolujte, zda je cesta volání ovlivněna logikou dynamického kontraktu.

• identifikovat potenciální zranitelnosti, které se spoléhají na chování, jako je msg.sender.code.length == 0, isContract() atd.;

• Vyjasněte "kontextové závislosti" logiky kontraktu, jako je řízení hranic statických volání a volání delegátů;

• Na úrovni sady nástrojů je podporována simulace a revertní analýza scénářů setCode.

Jinými slovy, bezpečnost kódu již není jen "problémem před nasazením", ale "dynamickým procesem, který musí být ověřen během vyvolání a transakce".

4.

zavádí lehčí, nativní a flexibilní implementaci abstrakce účtu (AA), takže běžná EOA může nést logiku kontraktu a provést ji v jediné transakci. Tento mechanismus narušuje tradiční statické předpoklady o chování účtu a vývojáři se již nemohou při posuzování modelu chování jednoduše spoléhat na stav kódu adresy účtu, ale potřebují rekonstruovat chápání hranice identity a oprávnění volajícího.

S tím přichází změna paradigmatu v bezpečnostní analytice. Audit se již neomezuje pouze na to, "zda má adresa oprávnění", ale na to, "co dokáže smluvní logika nesená v transakci v aktuálním kontextu". Každá transakce může mít samostatnou definici chování, která dává účtu větší funkčnost a klade vyšší požadavky na bezpečnostní audity.