Beosin: EIP-7702 och nästa generations analys av AA-plånbokssäkerhetsrevision

Account Abstraction (AA) är en viktig riktning för långsiktig utforskning i Ethereums ekosystem, som syftar till att bryta gränsen mellan externa konton (EOA) och kontraktskonton, så att plånboken har starkare programmerbarhet, säkerhet och uppgraderingsbarhet. EIP-4337 är för närvarande den mest vanliga AA-implementeringslösningen och har använts i stor utsträckning i ett antal EntryPoint-baserade smarta kontraktsplånböcker (som Safe, Stacks och Argent). EIP-4337 har dock fortfarande vissa begränsningar när det gäller infödning i kedjan, operativ komplexitet och ekologisk kompatibilitet på grund av dess införande av en oberoende transaktionspool och en mekanism för on-ramp-kontrakt.

För att ytterligare sänka inträdesbarriären och förbättra det inbyggda stödet för kontouttag föreslog Vitalik EIP-7702 2024 och inkluderade den i Pectra-uppgraderingen. Kärnidén med EIP-7702 är att tillåta en original EOA att exekvera kontraktskoden (contract_code) för en angiven adress när en transaktion initieras, och använda denna kod för att definiera transaktionens exekveringslogik.

EIP-7702 introducerar en ny mekanism för "kodinjektion på transaktionsnivå", som gör det möjligt för användarkonton att dynamiskt ange exekveringslogik i varje transaktion, i stället för att förlita sig på fördistribuerad kontraktskod. Detta bryter den traditionella statiska kodbaserade behörighetsmodellen, ger större flexibilitet och introducerar nya säkerhetsutmaningar: kontrakt som förlitar sig på bedömningslogik som isContract och extcodehash kan bli ogiltiga, och vissa system som antar att anroparen är ren EOA kan också kringgås. För revisorer är det viktigt att inte bara verifiera säkerheten för den injicerade koden i sig, utan också att bedöma dess potentiella inverkan på andra kontraktssystem i ett dynamiskt sammanhang.

I den här artikeln kommer Beosins säkerhetsteam att fokusera på designprinciperna och nyckelfunktionerna i EIP-7702, systematiskt reda ut de säkerhetsrisker som den AA-plånbok som byggts baserat på den kan utsättas för i revisionen och lägga fram revisionsprocessen och förslag ur ett praktiskt perspektiv för att hjälpa säkerhetsforskare att bättre hantera de tekniska utmaningarna under detta nya paradigm.

1. Introduktion till EIP-77021

. EIP-7702 Teknisk

översiktEIP-7702 introducerar en ny transaktionstyp, 0x 04 (SetCode), som gör det möjligt för EOA att godkänna kontraktskoden som måste utföras genom denna transaktion, med följande transaktionsstruktur:

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

2. destination, värde, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Där authorization_list innehåller flera auktoriseringslistor, och även kan innehålla auktoriseringsåtgärder för icke-transaktionsinitierare, är den interna strukturen:

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

där chain_id representerar den kedja där användarens auktorisering träder i kraft, och dess värde måste vara lika med kedje-ID:t för den körande kedjan eller 0. När chain_id är 0 träder auktoriseringen i kraft för alla EVM-kedjor som stöder EIP-7702, men endast om andra parametrar (t.ex. nonce) matchar. address anger målkontraktsadressen som auktoriserats av användaren.

När auktoriseringen är klar kommer systemet att ändra kodfältet för den auktoriserade användaren till 0x ef 0100 || adress, där adressen är den auktoriserade kontraktsadressen. Om du vill avauktorisera initierar du helt enkelt en SetCode-transaktion med adressen inställd på 0.

2. veckor Fördelar med EIP 7702

(1) Flexibilitet och Anpassning

Abstrakta kontonGenom att skriva in kontologik i smarta kontrakt kan du flexibelt anpassa funktioner efter dina behov. Användare kan till exempel konfigurera multisignaturer, social återställning och kvotkontroll för att uppfylla behoven hos individer eller företag i olika scenarier. Den här designen förbättrar avsevärt kontots funktionella skalbarhet och bryter igenom begränsningarna för traditionella externa konton (EOA).

(2) Enhanced

SecurityAbstract Accounts tillhandahåller en säkerhetsmekanism i flera lager, inklusive multifaktorautentisering, transaktionsgränser och social återställning. Även om en användare förlorar sin privata nyckel kan de återställa sitt konto genom betrodda kontakter eller multifaktorautentisering, vilket undviker permanent förlust av tillgångar som orsakas av förlust av den privata nyckeln i traditionella konton. Samtidigt kan funktioner som gränskontroll också förhindra att stora summor pengar stjäls på ett skadligt sätt.

(3) Det gasoptimerade

uttagskontot stöder en flexibel mekanism för uttag av gas, vilket gör det möjligt för användare att betala för gas via en tredje part och till och med direkt använda andra tokens för att betala transaktionsavgifter. Denna mekanism minskar inte bara driftskostnaderna för användarna, utan förenklar också användningen av blockkedjan, särskilt lämplig för nybörjare eller komplexa transaktionsscenarier i flera steg.

(4) Främja populariseringen av Web3Genom

att optimera upplevelsen och säkerheten döljer abstrakta konton blockkedjans komplexitet på platser som användarna inte kan se, vilket ger bekväma operationer närmare Web2. Denna design minskar inlärningskostnaderna för vanliga användare, gör det möjligt för fler människor att delta i Web3-applikationer utan hinder och främjar populariseringen av decentraliserad teknik.

2. Analys av säkerhetsrisker i EIP-7702 i praktiken

Även om EIP-7702 har injicerat ny kraft i Ethereums ekosystem och utökat en mängd applikationsscenarier, har det samtidigt oundvikligen introducerat några nya säkerhetsrisker:

1. Auktoriseringsuppspelningsattack

Enligt EIP-7702-modellen, om användaren godkänner chain_ Om id-fältet är inställt på 0 kan auktoriseringen börja gälla för flera kedjor. Även om den här utformningen av "universell auktorisering över kedjan" förbättrar flexibiliteten i vissa scenarier, medför den också uppenbara säkerhetsrisker.

Det är viktigt att notera att även om kontoidentiteten för samma adress är densamma i olika kedjor, kan kontraktsimplementeringen bakom den vara helt annorlunda. Detta innebär att en angripare kan distribuera en skadlig version av kontraktet i en annan kedja och utföra oavsiktliga åtgärder med hjälp av auktorisering av samma adress i kedjan, vilket utgör risker för användartillgångar.

Därför, för leverantörer av plånbokstjänster eller front-end-interaktionsplattformar, när användare utför sådana auktoriseringsoperationer, bör de tydligt verifiera om det chainId som deklareras i användarens auktorisation överensstämmer med det aktuella anslutningsnätverket; Om en användare upptäcks ställa in chainId på 0 bör en tydlig riskvarning ges för att påminna användaren om att auktoriseringen kommer att träda i kraft på alla EVM-kompatibla kedjor och kan missbrukas av skadliga kontrakt.

Dessutom bör tjänsteleverantören också utvärdera om auktorisering med chainId 0 ska begränsas eller förbjudas som standard i användargränssnittslagret för att minska risken för felaktig användning eller nätfiskeattacker.

2. Kontraktskompatibilitet

1) Kompatibilitet med återuppringning av kontrakt

de överför pengar till en kontraktsadress för befintliga tokenkontrakt som ERC-721, ERC-777 och ERC 1155, kommer de att anropa standardåteruppringningsgränssnitt (t.ex. onERC 721 Received, tokensReceived) för att slutföra överföringsoperationen. Om den mottagande adressen inte implementerar motsvarande gränssnitt kommer överföringen att misslyckas eller till och med leda till att tillgången låses.

I EIP-7702 kan en användaradress omvandlas till ett kontraktskonto genom att få en kontraktskod genom operationen "set_code". I det här fallet:

• Användaradressen betraktas som ett kontrakt;

• Om kontraktet inte implementerar det nödvändiga återanropsgränssnittet misslyckas tokenöverföringen.

• Användare kanske inte kan ta emot vanliga tokens utan deras vetskap.

Därför bör utvecklare se till att målkontraktet som delegeras av användaren implementerar det relevanta återanropsgränssnittet för att säkerställa kompatibilitet med vanliga tokens.

(2) Verifieringen av "tx.origin" misslyckasI

traditionella kontrakt används ofta "tx.origin" för att avgöra om transaktionen initieras direkt av användaren, och används för att förhindra säkerhetskontroller som t.ex. kontraktsanrop.

I EIP-7702-scenariot

• signerar dock användaren en auktoriseringstransaktion och överföraren eller bunteraren sänder den för användarens räkning. När en transaktion utförs är "tx.origin" vidarebefordreadressen, inte användaradressen.

• "msg.sender" är ett plånboksavtal som representerar användarens identitet.

Därför kommer behörighetsverifieringen baserad på "tx.origin == msg.sender" att orsaka att legitima användaråtgärder avvisas och förlorar tillförlitlighet, och samma begränsade kontraktsanrop som "tx.origin == användare" kommer också att ogiltigförklaras. Vi rekommenderar att du överger "tx.origin" som grund för säkerhetsbedömning och använder signaturverifiering eller auktoriseringsmekanism i stället.

(3) "isContract" missbedömerMånga

kontrakt hindrar kontraktskonton från att delta i vissa operationer, såsom airdrops, flash sales, etc., genom "isContract(address)":

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

). Enligt EIP-7702-mekanismen kan användarens adress ändras till ett kontraktskonto genom en "set_code"-transaktion, och "isContract" returnerar true, och kontraktet kommer felaktigt att identifiera den legitima användaren som kontraktskontot och vägra att delta i operationen, vilket resulterar i att användaren inte kan använda vissa tjänster och upplevelsen blockeras.

Med den gradvisa populariseringen av kontraktsplånböcker har utformningen av att förlita sig på "isContract" för att avgöra om "en mänsklig användare" inte längre är säker, och det rekommenderas att använda mer exakta metoder för användaridentifiering som signaturverifiering.

3.

Phishing-attackEfter implementeringen av EIP-7702:s delegeringsmekanism kommer tillgångarna på användarens konto att kontrolleras fullt ut av det delegerade smarta kontraktet. När en användare väl har godkänt ett skadligt kontrakt kan en angripare få full kontroll över kontotillgångarna, vilket resulterar i snabb överföring eller stöld av pengar, vilket är extremt riskabelt.

För leverantörer av plånbokstjänster är det därför nödvändigt att stödja EIP-7702-mekanismen för transaktionslösning och riskidentifiering så snart som möjligtAvgörande. När en användare signerar en uppdragstransaktion bör klientdelen tydligt och tydligt visa målkontraktsadressen och kombinera stödinformation som kontraktskälla och distributionsinformation för att hjälpa användarna att identifiera potentiella nätfiske eller bedrägliga beteenden, vilket minskar risken för felaktig signering. Vidare bör plånbokstjänsten integrera funktioner för automatisk säkerhetsanalys för målkontraktet, såsom statuskontroll av öppen källkod för kontraktkod, analys av behörighetsmodeller och potentiellt farlig operationsidentifiering, för att hjälpa användare att göra säkrare bedömningar före auktorisering.

I synnerhet introducerar EIP-7702 ett delegerat signaturformat som inte är kompatibelt med de befintliga signaturstandarderna EIP-191 och EIP-712. Dess signatur kan enkelt kringgå den ursprungliga signaturvarningen och interaktionsprompten i plånboken, vilket ytterligare ökar risken för att användare luras att signera skadliga operationer. Därför kommer införandet av identifierings- och bearbetningsmekanismen för signaturstrukturen i implementeringen av plånboken att vara en viktig länk för att säkerställa användarnas säkerhet.

4. Risker med plånbokskontrakt

( 1) Hantering av plånbokskontrakt Auktoritet

Många EIP-7702 plånbokskontrakt använder en proxyarkitektur (eller inbyggda hanteringsbehörigheter) för att stödja logiska uppgraderingar. Detta innebär dock också en högre risk för rättighetshantering. Om eskaleringsbehörigheterna inte är strikt begränsade kan en angripare ersätta implementeringskontraktet och injicera skadlig kod, vilket resulterar i att användarens konto manipuleras eller att pengar blir stulna.

Säkerhetsrekommendationer

• : Använd mekanismer för multisignatur, multifaktorautentisering eller timelock för att kontrollera eskaleringsprivilegier.

• Kod- och behörighetsändringar är föremål för rigorös granskning och säkerhetsvalidering.

• Uppgraderingsprocessen är öppen och transparent för att säkerställa användarnas rätt att känna till och delta.

(2) Risk för lagringskonflikter och dataisolering, versioner av

plånboksavtal eller att olika leverantörer av plånbokstjänster kan återanvända samma lagringsplats. Om användaren byter plånbokstjänsteleverantör eller uppgraderar plånbokslogiken kommer återanvändningen av lagringsfacket att orsaka konflikter med tillståndsvariabeln, överskrivning av data, läsundantag och andra problem. Detta kan inte bara störa plånbokens normala funktion, utan det kan också leda till förlust av pengar eller onormala behörigheter.

Säkerhetsrekommendationer:

• Använd ett specialiserat schema för lagringsisolering, till exempel EIP-1967-standarden, eller använd ett unikt namnområde för att hantera lagringsplatser.

• När du uppgraderar kontraktet ska du se till att lagringslayouten är kompatibel och undvika överlappande variabler.

• Testa noggrant rimligheten för det lagrade tillståndet under uppgraderingsprocessen.

(3) Nonce-hanteringen inuti plånboken

Plånbokskontraktet sätter vanligtvis upp en nonce inuti och hanterar sig själv för att säkerställa exekveringsordningen för användaroperationer och förhindra reprisattacker. Om nonce används felaktigt kommer användaråtgärden inte att utföras korrekt.

Säkerhetsrekommendation:

• nonce måste kontrolleras med tvång för ett motsvarande värde (eller ökning) och kan inte hoppas över.

• Det är förbjudet för funktioner att direkt ändra nonce, och nonce uppdateras bara när användaråtgärden körs.

• Utforma mekanismer för feltolerans och återställning för nonce-undantag för att undvika nonce-dödlägen.

(4) Kontroll av tillstånd för funktionsanropareFör

att garantera säkerheten måste plånboksavtalet säkerställa att den som ringer av nyckelfunktionen är plånbokens ägarkonto. De två vanliga metoderna inkluderar:

• signering utanför kedjan ger användare rätt

att signera en uppsättning operationer via den privata nyckeln, och plånbokskontraktet verifierar om signaturen är legitim, har löpt ut och uppfyller motsvarande nonce i kedjan. Denna metod är tillämplig på det relätransaktionsläge som förespråkas av EIP-7702 (användarens offlinesignatur + vidarebefordrare skickar transaktion för användarens räkning).

• Användaråtgärdsfunktionen för samtalsbegränsning (msg.sender == address(this))

får endast utlösas av själva kontraktet, vilket i huvudsak är en mekanism för kontroll av samtalsvägar som säkerställer att den externa initieraren måste vara själva kontot. Detta är i praktiken likvärdigt med att kräva att den som ringer är den ursprungliga EOA:n, eftersom avtalsadressen är EOA-adressen.

3. Utsikter: Förslaget om EIP-7702 och den framtida AA-plånboksstandarden

EIP-7702 är inte bara en innovation av den traditionella kontomodellen, utan också en stor främjande av ekosystemet för kontoabstraktion. Möjligheten att ladda kontraktskod som introduceras av den ger ett brett utrymme för utforskning av framtida plånboksdesign och kontraktssystem, och ställer också nya krav på standarder för säkerhetsrevision.

1. Samutveckling med EIP-4337: Mot dual-mode-kompatibilitetÄven om

EIP-7702 och EIP-4337 har olika designmål, rekonstruerar den förstnämnda kontots kodladdningsmekanism, och den senare bygger ett komplett ekosystem för transaktionsinmatning och paketering. De två står dock inte i konflikt med varandra, men har stark komplementaritet:

● EIP-4337 tillhandahåller en "gemensam transaktionskanal" och ett "abstrakt gränssnitt för kontoexekvering";

● EIP-7702 gör det möjligt för användarkonton att dynamiskt bevilja kontraktslogikfunktioner utan att ändra adressen;

Därför kan plånböcker i framtiden anta en "dual-mode-supportarkitektur": använda EIP-7702 som en lättviktsersättning på kedjor som inte stöder EIP-4337, och fortsätta att förlita sig på hela protokollstacken för EIP-4337 i scenarier som kräver off-chain-paketering och aggregering av flera användare.

Denna dual-mode-mekanism kommer också att göra det möjligt för plånböcker att stödja mer flexibla modeller för kontobehörighet, nedgraderingsmekanismer och återställningsscheman i kärnlagret.

2. Stöd och inspiration för ny plånbokslogik som MPC och ZK, och den

kontokontraktsmekanism som förespråkas av EIP-7702 har naturlig integrationspotential med den nuvarande populära MPC-plånboken, ZK-plånboken, modulära plånboken och andra nya arkitekturer:

● I MPC-modellen förlitar sig signaturbeteendet inte längre på en enda privat nyckel, utan är ett samarbetsbeslut från flera parter. Signaturer som genereras genom konvergensen av EIP-7702 och MPC styr den dynamiskt laddade kontraktslogiken, vilket möjliggör mer flexibla genomförandestrategier.

● ZK-plånboken verifierar användaridentitet eller auktorisering genom nollkunskapsbevis, utan att exponera information om privata nycklar. I kombination med EIP-7702 kan ZK-plånböcker tillfälligt injicera specifika logikkontrakt efter att verifieringen är klar, för att realisera utplaceringen av personliga beteenden efter integritetsberäkning, till exempel att automatiskt köra en viss logik endast efter att vissa integritetsvillkor är uppfyllda.

● Modulära plånböcker kan använda EIP-7702 för att dela upp kontologiken i flera moduler och dynamiskt ladda dem vid behov.

Därför tillhandahåller EIP-7702 en mer inbyggd "exekveringsbehållare" för de ovan nämnda avancerade plånböckerna: olika kontraktslogik kan injiceras med samma användaradress, vilket undviker problemet med adressberoende i den traditionella kontraktsimplementeringsprocessen och eliminerar behovet av fördistribution, vilket avsevärt förbättrar flexibiliteten och kombinationen av kontobeteende.

3. Implikationer för kontraktsutvecklare och

kommer att driva en djupgående förändring av utvecklingsparadigmet. Avtalsutvecklare behandlar inte längre bara den som ringer som en traditionell EOA eller ett fast kontraktskonto, utan måste anpassa sig till en ny mekanism: uppringarens identitet kan dynamiskt växlas mellan EOA och kontraktsstatus under transaktionen, och kontobeteendelogiken är inte längre statiskt befäst, utan kan flexibelt ändras beroende på efterfrågan. Detta kräver att utvecklare och granskare:

• inför striktare anropsverifiering och logik för tillståndsbedömning;

• Kontrollera om anropsvägen påverkas av den dynamiska kontraktslogiken.

• identifiera potentiella sårbarheter som förlitar sig på beteenden som msg.sender.code.length == 0, isContract(), etc.;

• Klargöra "kontextberoenden" för kontraktslogik, till exempel gränskontroll av statiska anrop och delegatanrop;

• På verktygskedjenivå stöds simulering och återställningsanalys av setCode-scenarier.

Med andra ord är kodsäkerhet inte längre bara ett "fördistributionsproblem" utan en "dynamisk process som måste verifieras under anrop och transaktion".

4.

introducerar en lättare, inbyggd och flexibel implementering av Account Abstraction (AA), så att vanlig EOA kan bära kontraktslogik och utföra den i en enda transaktion. Den här mekanismen bryter de traditionella statiska antagandena om kontobeteende, och utvecklare kan inte längre bara förlita sig på kodtillståndet för kontoadressen för att bedöma dess beteendemodell, utan måste rekonstruera förståelsen av anroparens identitets- och auktoritetsgräns.

Med det kommer ett paradigmskifte inom säkerhetsanalys. Fokus för granskningen är inte längre begränsat till "om en adress har behörighet", utan till "vad den kontraktslogik som bärs i transaktionen kan göra i den aktuella kontexten". Varje transaktion kan ha en oberoende definition av beteende, vilket ger kontot större funktionalitet och ställer högre krav på säkerhetsrevisioner.