Beosin: EIP-7702 en analyse van de beveiligingsaudit van de volgende generatie AA-portemonnees

Account Abstraction (AA) is een belangrijke richting van langetermijnverkenning in het Ethereum-ecosysteem, met als doel de grens tussen externe accounts (EOA) en contractaccounts te doorbreken, zodat de portemonnee een sterkere programmeerbaarheid, beveiliging en upgradebaarheid heeft. EIP-4337 is momenteel de meest gangbare AA-implementatieoplossing en wordt veel gebruikt in een aantal op EntryPoint gebaseerde slimme contractportefeuilles (zoals Safe, Stacks en Argent). EIP-4337 heeft echter nog steeds bepaalde beperkingen op het gebied van on-chain nativeness, operationele complexiteit en ecologische compatibiliteit vanwege de introductie van een onafhankelijke transactiepool en een on-ramp contractmechanisme.

Om de toetredingsdrempel verder te verlagen en de native ondersteuning voor accountabstracties te verbeteren, stelde Vitalik in 2024 EIP-7702 voor en nam deze op in de Pectra-upgrade. Het kernidee van EIP-7702 is om een originele EOA in staat te stellen de contractcode (contract_code) van een opgegeven adres uit te voeren bij het initiëren van een transactie, en deze code te gebruiken om de uitvoeringslogica van de transactie te definiëren.

EIP-7702 introduceert een nieuw mechanisme voor "code-injectie op transactieniveau", waarmee gebruikersaccounts dynamisch uitvoeringslogica in elke transactie kunnen specificeren, in plaats van te vertrouwen op vooraf geïmplementeerde contractcode. Dit doorbreekt het traditionele, op statische code gebaseerde toestemmingsmodel, zorgt voor meer flexibiliteit en introduceert nieuwe beveiligingsuitdagingen: contracten die afhankelijk zijn van beoordelingslogica zoals isContract en extcodehash kunnen ongeldig worden, en sommige systemen die ervan uitgaan dat de aanroeper pure EOA is, kunnen ook worden omzeild. Voor auditors is het niet alleen belangrijk om de veiligheid van de geïnjecteerde code zelf te verifiëren, maar ook om de potentiële impact ervan op andere contractsystemen in een dynamische context te beoordelen.

In dit artikel zal het Beosin-beveiligingsteam zich concentreren op de ontwerpprincipes en belangrijkste kenmerken van EIP-7702, systematisch de beveiligingsrisico's sorteren waarmee de AA-portemonnee die op basis daarvan is gebouwd, tijdens de audit kunnen worden geconfronteerd, en het auditproces en de suggesties vanuit een praktisch perspectief naar voren brengen om beveiligingsonderzoekers te helpen beter om te gaan met de technische uitdagingen onder dit nieuwe paradigma.

1. Inleiding tot EIP-77021

. EIP-7702 Technisch

overzichtEIP-7702 introduceert een nieuw transactietype, 0x 04 (SetCode), waarmee EOA de contractcode kan autoriseren die via deze transactie moet worden uitgevoerd, met de volgende transactiestructuur:

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

2. bestemming, waarde, gegevens, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Wanneer authorization_list meerdere autorisatielijsten bevat, en ook autorisatieacties van niet-transactie-initiators kan bevatten, is de interne structuur:

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

waarbij chain_id staat voor de keten waarin de autorisatie van de gebruiker van kracht wordt, en de waarde ervan moet gelijk zijn aan de keten-ID van de uitvoerende keten of 0. Wanneer chain_id 0 is, wordt de autorisatie van kracht voor alle EVM-ketens die EIP-7702 ondersteunen, maar alleen als andere parameters (zoals nonce) overeenkomen. Adres geeft het doelcontractadres aan dat door de gebruiker is geautoriseerd.

Nadat de autorisatie is voltooid, wijzigt het systeem het codeveld van de geautoriseerde gebruiker in 0x ef 0100 || adres, waarbij het adres het geautoriseerde contractadres is. Als u de machtiging wilt intrekken, start u eenvoudig een SetCode-transactie met het adres ingesteld op 0.

Arabisch cijfer. Voordelen van EIP 7702

(1) Flexibiliteit en maatwerk

Abstracte accountsDoor accountlogica in slimme contracten te schrijven, kunt u functies flexibel aanpassen aan uw behoeften. Gebruikers kunnen bijvoorbeeld multi-ondertekening, sociaal herstel en quotabeheer configureren om te voldoen aan de behoeften van individuen of ondernemingen in verschillende scenario's. Dit ontwerp verbetert de functionele schaalbaarheid van het account aanzienlijk en doorbreekt de beperkingen van traditionele externe accounts (EOA).

(2) Verbeterde

beveiligingAbstracte accounts bieden een meerlaags beveiligingsmechanisme, inclusief multi-factor authenticatie, transactielimieten en sociaal herstel. Zelfs als een gebruiker zijn privésleutel verliest, kan hij zijn account herstellen via vertrouwde contacten of multifactorauthenticatie, waardoor het permanente verlies van activa wordt vermeden dat wordt veroorzaakt door het verlies van de privésleutel in traditionele accounts. Tegelijkertijd kunnen functies zoals limietcontrole ook voorkomen dat grote hoeveelheden geld kwaadwillig worden gestolen.

(3) De Gas Optimized

Abstraction Account ondersteunt een flexibel gasonttrekkingsmechanisme, waardoor gebruikers via een derde partij voor gas kunnen betalen en zelfs rechtstreeks andere tokens kunnen gebruiken om transactiekosten te betalen. Dit mechanisme verlaagt niet alleen de operationele kosten van gebruikers, maar vereenvoudigt ook het gebruik van de blockchain, vooral geschikt voor beginnende gebruikers of complexe transactiescenario's met meerdere stappen.

(4) Bevorder de popularisering van Web3Door

de ervaring en beveiliging te optimaliseren, verbergen abstracte accounts de complexiteit van de blockchain op plaatsen die gebruikers niet kunnen zien, waardoor gemakkelijke operaties dichter bij Web2 worden geboden. Dit ontwerp verlaagt de leerkosten van gewone gebruikers, stelt meer mensen in staat om zonder barrières deel te nemen aan Web3-applicaties en bevordert de popularisering van gedecentraliseerde technologie.

2. Analyse van beveiligingsrisico's in EIP-7702 in de praktijk

Hoewel EIP-7702 een nieuwe impuls heeft gegeven aan het Ethereum-ecosysteem en een schat aan toepassingsscenario's heeft uitgebreid, heeft het tegelijkertijd onvermijdelijk enkele nieuwe beveiligingsrisico's geïntroduceerd:

1. Autorisatie replay-aanval

Onder het EIP-7702-model, als de gebruiker de chain_ Als het id-veld is ingesteld op 0, kan de autorisatie van kracht worden op meerdere ketens. Hoewel dit ontwerp van "cross-chain universele autorisatie" de flexibiliteit in sommige scenario's verbetert, introduceert het ook voor de hand liggende beveiligingsrisico's.

Het is belangrijk op te merken dat zelfs als de accountidentiteit van hetzelfde adres hetzelfde is in verschillende ketens, de contractuitvoering erachter compleet anders kan zijn. Dit betekent dat een aanvaller een kwaadaardige versie van het contract op een andere keten kan inzetten en onbedoelde acties kan uitvoeren met behulp van de autorisatie van hetzelfde adres in de keten, waardoor risico's ontstaan voor gebruikersactiva.

Daarom moeten gebruikers die dergelijke autorisatiebewerkingen uitvoeren, voor wallet-serviceproviders of front-end-interactieplatforms duidelijk verifiëren of de chainId die in de autorisatie van de gebruiker is gedeclareerd, consistent is met het huidige verbindingsnetwerk; Als een gebruiker wordt gedetecteerd die de chainId op 0 zet, moet er een duidelijke risicowaarschuwing worden gegeven om de gebruiker eraan te herinneren dat de autorisatie van kracht wordt op alle EVM-compatibele ketens en kan worden misbruikt door kwaadwillende contracten.

Daarnaast moet de serviceprovider ook evalueren of autorisatie met chainId 0 standaard op de UI-laag moet worden beperkt of verboden om het risico op verkeerde bediening of phishing-aanvallen te verminderen.

2. Contractcompatibiliteit

1) Compatibiliteit met terugbellen van contracten

het overmaken van geld naar een contractadres voor bestaande tokencontracten zoals ERC-721, ERC-777 en ERC 1155, zullen ze standaard callback-interfaces aanroepen (zoals onERC 721 Received, tokensReceived) om de overdrachtsbewerking te voltooien. Als het ontvangende adres de bijbehorende interface niet implementeert, zal de overdracht mislukken of zelfs tot gevolg hebben dat het activum wordt vergrendeld.

In EIP-7702 kan een gebruikersadres worden omgezet in een contractaccount door een contractcode te krijgen via de bewerking "set_code". In dit geval:

• Het gebruikersadres wordt beschouwd als een contract;

• Als het contract de benodigde terugbelinterface niet implementeert, zal de tokenoverdracht mislukken;

• Gebruikers kunnen mogelijk geen reguliere tokens ontvangen zonder hun medeweten.

Daarom moeten ontwikkelaars ervoor zorgen dat het doelcontract dat door de gebruiker is gedelegeerd, de relevante callback-interface implementeert om compatibiliteit met reguliere tokens te garanderen.

(2) "tx.origin"-verificatie misluktIn

traditionele contracten wordt "tx.origin" vaak gebruikt om te bepalen of de transactie rechtstreeks door de gebruiker wordt geïnitieerd, en wordt het gebruikt om beveiligingscontroles zoals contractaanroepen te voorkomen.

In het EIP-7702-scenario

• ondertekent de gebruiker echter een autorisatietransactie en zendt de relayer of bundler deze namens de gebruiker uit. Wanneer een transactie wordt uitgevoerd, is "tx.origin" het adres van de herlaag, niet het adres van de gebruiker.

• "msg.sender" is een wallet-contract dat de identiteit van de gebruiker vertegenwoordigt.

Daarom zal de toestemmingsverificatie op basis van "tx.origin == msg.sender" ertoe leiden dat legitieme gebruikersbewerkingen worden geweigerd en hun betrouwbaarheid verliezen, en dezelfde beperkte contractaanroepen zoals "tx.origin == gebruiker" worden ook ongeldig verklaard. Het wordt aanbevolen om "tx.origin" te verlaten als basis voor veiligheidsbeoordeling en in plaats daarvan een handtekeningverificatie of autorisatiemechanisme te gebruiken.

(3) "isContract" beoordeelt ten onrechteVeel

contracten voorkomen dat contractaccounts deelnemen aan bepaalde bewerkingen, zoals airdrops, flash sales, enz., via "isContract(address)":

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

). Onder het EIP-7702-mechanisme kan het adres van de gebruiker worden gewijzigd in een contractaccount door middel van een "set_code"-transactie, en "isContract" retourneert waar, en het contract zal de legitieme gebruiker ten onrechte identificeren als het contractaccount en weigeren deel te nemen aan de operatie, waardoor de gebruiker bepaalde services niet kan gebruiken en de ervaring wordt geblokkeerd.

Met de geleidelijke popularisering van contractportefeuilles, is het ontwerp om te vertrouwen op "isContract" om te bepalen of "een menselijke gebruiker" niet langer veilig is, en het wordt aanbevolen om nauwkeurigere gebruikersidentificatiemethoden te gebruiken, zoals handtekeningverificatie.

3. Phishing-aanvalNa

de implementatie van het delegatiemechanisme van EIP-7702 worden de activa in het account van de gebruiker volledig beheerd door het gedelegeerde slimme contract. Zodra een gebruiker een kwaadaardig contract autoriseert, kan een aanvaller volledige controle krijgen over de accountactiva, wat resulteert in de snelle overdracht of diefstal van geld, wat uiterst riskant is.

Daarom is het voor aanbieders van portemonneediensten noodzakelijk om het EIP-7702-mechanisme voor transactieafwikkeling en risico-identificatie zo snel mogelijk te ondersteunenCruciaal. Wanneer een gebruiker een toewijzingstransactie ondertekent, moet de front-end duidelijk en prominent het doelcontractadres weergeven en ondersteunende informatie zoals contractbron en implementatie-informatie combineren om gebruikers te helpen mogelijk phishing of frauduleus gedrag te identificeren, waardoor het risico op verkeerde ondertekening wordt verkleind. Verder moet de portemonnee-service automatische beveiligingsanalysemogelijkheden voor het doelcontract integreren, zoals open source-statuscontrole van contractcode, analyse van toestemmingsmodellen en identificatie van potentieel gevaarlijke operaties, om gebruikers te helpen veiligere beoordelingen te maken voordat ze worden geautoriseerd.

In het bijzonder introduceert EIP-7702 een formaat voor gedelegeerde handtekeningen dat niet compatibel is met de bestaande EIP-191- en EIP-712-handtekeningnormen. De handtekening kan gemakkelijk de oorspronkelijke handtekeningwaarschuwing en interactieprompt van de portemonnee omzeilen, wat het risico verder vergroot dat gebruikers worden misleid om kwaadaardige bewerkingen te ondertekenen. Daarom zal de invoering van het identificatie- en verwerkingsmechanisme van de handtekeningstructuur in de portemonnee-implementatie een belangrijke schakel zijn om de veiligheid van gebruikers te waarborgen.

4. Risico's van portemonneecontracten

( 1) Beheer van portefeuillecontracten

Veel EIP-7702-portemonneecontracten maken gebruik van een proxy-architectuur (of ingebouwde beheermachtigingen) om logische upgrades te ondersteunen. Dit brengt echter ook een hoger risico op rechtenbeheer met zich mee. Als de escalatiebevoegdheden niet strikt worden beperkt, kan een aanvaller het implementatiecontract vervangen en kwaadaardige code injecteren, waardoor er met het account van de gebruiker wordt geknoeid of geld wordt gestolen.

• Beveiligingsaanbevelingen: Gebruik mechanismen voor meerdere handtekeningen, meervoudige verificatie of tijdsloten om escalatiebevoegdheden te beheren.

• Wijzigingen in code en machtigingen zijn onderworpen aan strenge audits en beveiligingsvalidatie.

• Het upgradeproces is open en transparant om het recht van gebruikers om te weten en deel te nemen te waarborgen.

(2) Risico op opslagconflicten en gegevensisolatie, versies van

wallet-contracten of verschillende wallet-serviceproviders kunnen hetzelfde opslagslot opnieuw gebruiken. Als de gebruiker de wallet-serviceprovider wijzigt of de wallet-logica upgradet, zal het hergebruik van de opslagsleuf leiden tot het conflict met de statusvariabele, het overschrijven van gegevens, leesuitzonderingen en andere problemen. Dit kan niet alleen de normale werking van de portemonnee verstoren, maar het kan ook leiden tot verlies van geld of abnormale machtigingen.

Beveiligingsaanbevelingen:

• Gebruik een gespecialiseerd opslagisolatieschema, zoals de EIP-1967-standaard, of maak gebruik van een unieke naamruimte om opslagsleuven te beheren.

• Zorg er bij het upgraden van het contract voor dat de opslaglay-out compatibel is en vermijd overlappende variabelen.

• Test de plausibiliteit van de opgeslagen status grondig tijdens het upgradeproces.

(3) Het nonce-beheer in de portemonnee

Het portemonnee-contract zet meestal een nonce op en beheert zichzelf om de uitvoeringsvolgorde van gebruikersbewerkingen te waarborgen en replay-aanvallen te voorkomen. Als de nonce onjuist wordt gebruikt, wordt de gebruikersbewerking niet correct uitgevoerd.

Beveiligingsaanbeveling:

• De nonce moet geforceerd worden gecontroleerd op een equivalente waarde (of verhoging) en kan niet worden overgeslagen.

• Het is verboden voor functies om de nonce rechtstreeks te wijzigen, en de nonce wordt alleen bijgewerkt wanneer de gebruikersbewerking wordt uitgevoerd.

• Ontwerp fouttolerantie en herstelmechanismen voor nonce-uitzonderingen om nonce-impasses te voorkomen.

(4) Controle

de toestemming van de functieOm de veiligheid te garanderen, moet het portemonneecontract ervoor zorgen dat de aanroeper van de sleutelfunctie het eigenaarsaccount van de portemonnee is. De twee veelgebruikte methoden zijn:

• off-chain ondertekening machtigt

gebruikers om een reeks bewerkingen te ondertekenen via de privésleutel, en het portemonnee-contract controleert of de handtekening legitiem is, verlopen is en voldoet aan de overeenkomstige nonce op de keten. Deze methode is van toepassing op de relay-transactiemodus die wordt bepleit door EIP-7702 (offline handtekening van de gebruiker + relayer verzendt transactie namens de gebruiker).

• De aanroepbeperking (msg.sender == address(this))

gebruikersactiefunctie mag alleen worden geactiveerd door het contract zelf, wat in wezen een mechanisme voor het beheer van het oproeppad is dat ervoor zorgt dat de externe initiator het account zelf moet zijn. Dit komt in feite overeen met de eis dat de beller de oorspronkelijke EOA is, aangezien het contractadres het EOA-adres is.

3. Vooruitzichten: Het voorstel van EIP-7702 en de toekomstige AA-portemonneestandaard

EIP-7702 is niet alleen een innovatie van het traditionele rekeningmodel, maar ook een belangrijke bevordering van het ecosysteem voor rekeningabstractie. De mogelijkheid om contractcode te laden die hierdoor wordt geïntroduceerd, biedt een brede ruimte voor verkenning van het toekomstige ontwerp van de portemonnee en het contractsysteem, en stelt ook nieuwe eisen aan de normen voor beveiligingsaudits.

1. Co-evolutie met EIP-4337: op weg naar dual-mode compatibiliteitHoewel

EIP-7702 en EIP-4337 verschillende ontwerpdoelen hebben, reconstrueert de eerste het codelaadmechanisme van de rekening, en de laatste bouwt een compleet ecosysteem voor het invoeren en verpakken van transacties. De twee zijn echter niet met elkaar in conflict, maar hebben een sterke complementariteit:

● EIP-4337 biedt een "gemeenschappelijk transactiekanaal" en een "abstracte interface voor het uitvoeren van rekeningen";

● EIP-7702 stelt gebruikersaccounts in staat om dynamisch contractlogische mogelijkheden toe te kennen zonder het adres te wijzigen;

Daarom kunnen wallets in de toekomst een "dual-mode ondersteuningsarchitectuur" aannemen: EIP-7702 gebruiken als een lichtgewicht vervanging op ketens die EIP-4337 niet ondersteunen, en blijven vertrouwen op de volledige protocolstack van EIP-4337 in scenario's die off-chain packaging en multi-user aggregatie vereisen.

Dit dual-mode mechanisme stelt wallets ook in staat om flexibelere accountmachtigingsmodellen, downgrademechanismen en rollback-schema's op de kernellaag te ondersteunen.

2. Ondersteuning en inspiratie voor nieuwe portemonnee-logica zoals MPC en ZK, en het

accountcontractmechanisme dat wordt bepleit door EIP-7702 heeft een natuurlijk integratiepotentieel met de huidige populaire MPC-portemonnee, ZK-portemonnee, modulaire portemonnee en andere nieuwe architecturen:

● In het MPC-model is het handtekeninggedrag niet langer afhankelijk van een enkele privésleutel, maar is het een gezamenlijke besluitvorming met meerdere partijen. Handtekeningen die worden gegenereerd door de convergentie van EIP-7702 en MPC regelen de dynamisch geladen contractlogica, waardoor flexibelere uitvoeringsstrategieën mogelijk zijn.

● ZK-portemonnee verifieert de identiteit of autorisatie van gebruikers door middel van zero-knowledge proofs, zonder privésleutelinformatie vrij te geven. In combinatie met EIP-7702 kunnen ZK-portefeuilles tijdelijk specifieke logische contracten injecteren nadat de verificatie is voltooid, om de implementatie van gepersonaliseerd gedrag na privacy computing te realiseren, zoals het automatisch uitvoeren van een bepaalde logica pas nadat aan bepaalde privacyvoorwaarden is voldaan.

● Modulaire portefeuilles kunnen EIP-7702 gebruiken om de accountlogica in meerdere modules te demonteren en deze dynamisch te laden wanneer dat nodig is.

Daarom biedt EIP-7702 een meer native "uitvoeringscontainer" voor de bovengenoemde geavanceerde portefeuilles: verschillende contractlogica kan worden geïnjecteerd met hetzelfde gebruikersadres, waardoor het probleem van adresafhankelijkheid in het traditionele contractimplementatieproces wordt vermeden en de noodzaak van pre-implementatie wordt geëlimineerd, waardoor de flexibiliteit en combinatie van accountgedrag aanzienlijk wordt verbeterd.

3. Implicaties voor contractontwikkelaars en

zal een diepgaande verandering in het ontwikkelingsparadigma teweegbrengen. Contractontwikkelaars behandelen de beller niet langer alleen als een traditionele EOA of een vaste contractrekening, maar moeten zich aanpassen aan een nieuw mechanisme: de identiteit van de beller kan tijdens de transactie dynamisch worden omgeschakeld tussen EOA en contractstatus, en de logica van het accountgedrag is niet langer statisch gestold, maar kan flexibel worden gewijzigd afhankelijk van de vraag. Dit vereist dat ontwikkelaars en auditors:

• strengere logica voor het verifiëren van bellers en toestemmingsoordelen introduceren;

• Controleer of het gesprekspad wordt beïnvloed door de dynamische contractlogica;

• potentiële kwetsbaarheden identificeren die afhankelijk zijn van gedrag zoals msg.sender.code.length == 0, isContract(), enz.;

• Verduidelijk de "contextafhankelijkheden" van contractlogica, zoals grensbeheer van statische aanroepen en gedelegeerde oproepen;

• Op toolchain-niveau worden simulatie en terugdraaianalyse van setCode-scenario's ondersteund.

Met andere woorden, codebeveiliging is niet langer alleen een "pre-deployment probleem", maar een "dynamisch proces dat moet worden geverifieerd tijdens het aanroepen en de transactie".

4.

introduceert een lichtere, native en flexibele implementatie van Account Abstraction (AA), zodat gewone EOA contractlogica kan uitvoeren in een enkele transactie. Dit mechanisme doorbreekt de traditionele statische aannames over accountgedrag, en ontwikkelaars kunnen niet langer simpelweg vertrouwen op de codestatus van het accountadres om het gedragsmodel te beoordelen, maar moeten het begrip van de identiteit en autoriteitsgrens van de aanroeper reconstrueren.

Dat brengt een paradigmaverschuiving in beveiligingsanalyse met zich mee. De focus van de audit is niet langer beperkt tot "of een adres machtigingen heeft", maar tot "wat de contractlogica die in de transactie wordt gedragen, in de huidige context kan doen". Elke transactie kan een onafhankelijke gedragsdefinitie hebben, waardoor het account meer functionaliteit krijgt en hogere eisen worden gesteld aan beveiligingsaudits.