Beosin: EIP-7702 og neste generasjons AA-lommeboksikkerhetsrevisjonsanalyse

Kontoabstraksjon (AA) er en viktig retning for langsiktig utforskning i Ethereum-økosystemet, med sikte på å bryte grensen mellom eksterne kontoer (EOA) og kontraktskontoer, slik at lommeboken har sterkere programmerbarhet, sikkerhet og oppgraderingsmuligheter. EIP-4337 er for tiden den mest vanlige AA-implementeringsløsningen, og har blitt mye brukt i en rekke EntryPoint-baserte smarte kontraktslommebøker (som Safe, Stacks og Argent). Imidlertid har EIP-4337 fortsatt visse begrensninger når det gjelder innfødthet på kjeden, operasjonell kompleksitet og økologisk kompatibilitet på grunn av introduksjonen av en uavhengig transaksjonspool og kontraktsmekanisme på rampen.

For ytterligere å senke inngangsbarrieren og forbedre innfødt støtte for kontoabstraksjoner, foreslo Vitalik EIP-7702 i 2024 og inkluderte den i Pectra-oppgraderingen. Kjerneideen til EIP-7702 er å la en original EOA utføre kontraktskoden (contract_code) for en spesifisert adresse når du starter en transaksjon, og bruke denne koden til å definere utførelseslogikken til transaksjonen.

EIP-7702 introduserer en ny mekanisme for "kodeinjeksjon på transaksjonsnivå", som gjør det mulig for brukerkontoer å dynamisk spesifisere utførelseslogikk i hver transaksjon, i stedet for å stole på forhåndsdistribuert kontraktskode. Dette bryter den tradisjonelle statiske kodebaserte tillatelsesmodellen, gir større fleksibilitet og introduserer nye sikkerhetsutfordringer: kontrakter som er avhengige av vurderingslogikk som isContract og extcodehash kan bli ugyldige, og noen systemer som antar at anroperen er ren EOA kan også omgås. For revisorer er det viktig ikke bare å verifisere sikkerheten til selve den injiserte koden, men også å vurdere dens potensielle innvirkning på andre kontraktssystemer i en dynamisk kontekst.

I denne artikkelen vil Beosin-sikkerhetsteamet fokusere på designprinsippene og nøkkelfunksjonene til EIP-7702, systematisk sortere ut sikkerhetsrisikoene som AA-lommeboken bygget basert på den kan møte i revisjonen, og legge frem revisjonsprosessen og forslag fra et praktisk perspektiv for å hjelpe sikkerhetsforskere bedre å takle de tekniske utfordringene under dette nye paradigmet.

1. Introduksjon til EIP-77021

. EIP-7702 Teknisk

oversiktEIP-7702 introduserer en ny transaksjonstype, 0x 04 (SetCode), som lar EOA autorisere kontraktskoden som må utføres gjennom denne transaksjonen, med følgende transaksjonsstruktur:

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

2. destinasjon, verdi, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Der authorization_list inneholder flere autorisasjonslister, og også kan inneholde autorisasjonshandlinger for ikke-transaksjonsinitierere, er den interne strukturen:

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

der chain_id representerer kjeden der brukerens autorisasjon trer i kraft, og verdien må være lik kjede-ID-en til den utførende kjeden eller 0. Når chain_id er 0, trer autorisasjonen i kraft for alle EVM-kjeder som støtter EIP-7702, men bare hvis andre parametere (for eksempel nonce) samsvarer. adresse angir målkontraktadressen som er autorisert av brukeren.

Etter at autorisasjonen er fullført, vil systemet endre kodefeltet til den autoriserte brukeren til 0x ef 0100 || adresse, der adressen er den autoriserte kontraktsadressen. Hvis du vil fjerne autoriseringen, starter du bare en SetCode-transaksjon med adressen satt til 0.

2. Fordeler med EIP 7702

(1) Fleksibilitet og tilpasning

Abstrakte kontoerVed å skrive kontologikk inn i smarte kontrakter kan du fleksibelt tilpasse funksjoner etter dine behov. Brukere kan for eksempel konfigurere flere signaturer, sosial gjenoppretting og kvotekontroll for å dekke behovene til enkeltpersoner eller virksomheter i ulike scenarioer. Denne utformingen forbedrer den funksjonelle skalerbarheten til kontoen betraktelig og bryter gjennom begrensningene til tradisjonelle eksterne kontoer (EOA).

(2) Forbedret

sikkerhetAbstrakte kontoer gir en flerlags sikkerhetsmekanisme, inkludert flerfaktorautentisering, transaksjonsgrenser og sosial gjenoppretting. Selv om en bruker mister sin private nøkkel, kan de gjenopprette kontoen sin gjennom pålitelige kontakter eller multifaktorautentisering, og unngå permanent tap av eiendeler forårsaket av tap av den private nøkkelen i tradisjonelle kontoer. Samtidig kan funksjoner som grensekontroll også forhindre at store mengder midler blir stjålet med ondsinnet vilje.

(3) Den gassoptimaliserte

abstraksjonskontoen støtter en fleksibel gassabstraksjonsmekanisme, slik at brukere kan betale for gass gjennom en tredjepart, og til og med direkte bruke andre tokens for å betale transaksjonsgebyrer. Denne mekanismen reduserer ikke bare driftskostnadene til brukerne, men forenkler også bruken av blokkjeden ytterligere, spesielt egnet for nybegynnere eller komplekse flertrinns transaksjonsscenarier.

(4) Fremme populariseringen av Web3Ved

optimalisere opplevelsen og sikkerheten, skjuler abstrakte kontoer kompleksiteten til blokkjeden på steder som brukere ikke kan se, og gir praktiske operasjoner nærmere Web2. Denne designen reduserer læringskostnadene til vanlige brukere, lar flere delta i Web3-applikasjoner uten barrierer, og fremmer populariseringen av desentralisert teknologi.

2. Analyse av sikkerhetsrisikoer i EIP-7702 I praksis

Selv om EIP-7702 har injisert ny drivkraft i Ethereum-økosystemet og utvidet et vell av applikasjonsscenarier, har det samtidig uunngåelig introdusert noen nye sikkerhetsrisikoer:

1. Autorisasjonsavspillingsangrep

Under EIP-7702-modellen, hvis brukeren autoriserer chain_ Hvis id-feltet er satt til 0, kan autorisasjonen tre i kraft på flere kjeder. Selv om denne utformingen av "universell autorisasjon på tvers av kjeder" forbedrer fleksibiliteten i noen scenarier, introduserer den også åpenbare sikkerhetsrisikoer.

Det er viktig å merke seg at selv om kontoidentiteten til den samme adressen er den samme på forskjellige kjeder, kan kontraktsimplementeringen bak den være helt forskjellig. Dette betyr at en angriper kan distribuere en ondsinnet versjon av kontrakten på en annen kjede og utføre utilsiktede handlinger ved å bruke autorisasjonen av den samme adressen i kjeden, og dermed utgjøre en risiko for brukerressurser.

Derfor, for leverandører av lommeboktjenester eller front-end-interaksjonsplattformer, når brukere utfører slike autorisasjonsoperasjoner, bør de tydelig verifisere om chainId som er deklarert i brukerens autorisasjon er i samsvar med gjeldende tilkoblingsnettverk; Hvis en bruker oppdages ved å sette chainId til 0, bør det gis en klar risikoadvarsel for å minne brukeren på at autorisasjonen vil tre i kraft på alle EVM-kompatible kjeder og kan bli misbrukt av ondsinnede kontrakter.

I tillegg bør tjenesteleverandøren også vurdere om de skal begrense eller forby autorisasjon med chainId 0 som standard på brukergrensesnittlaget for å redusere risikoen for feiloperasjon eller phishing-angrep.

2. Kontraktskompatibilitet

1) Kontraktstilbakekallskompatibilitet

de overfører penger til en kontraktsadresse for eksisterende tokenkontrakter som ERC-721, ERC-777 og ERC 1155, vil de kalle standard tilbakeringingsgrensesnitt (for eksempel onERC 721 Received, tokensReceived) for å fullføre overføringsoperasjonen. Hvis mottaksadressen ikke implementerer det tilsvarende grensesnittet, vil overføringen mislykkes eller til og med føre til at eiendelen låses.

I EIP-7702 kan en brukeradresse transformeres til en kontraktskonto ved å få en kontraktskode gjennom "set_code"-operasjonen. I dette tilfellet:

• Brukeradressen anses som en kontrakt;

• Hvis kontrakten ikke implementerer det nødvendige tilbakeringingsgrensesnittet, vil tokenoverføringen mislykkes;

• Brukere kan kanskje ikke motta vanlige tokens uten deres viten.

Derfor bør utviklere sørge for at målkontrakten delegert av brukeren implementerer det relevante tilbakekallsgrensesnittet for å sikre kompatibilitet med vanlige tokener.

(2) "tx.origin"-verifisering mislykkesI

tradisjonelle kontrakter brukes "tx.origin" ofte for å avgjøre om transaksjonen er direkte initiert av brukeren, og brukes til å forhindre sikkerhetskontroller som kontraktssamtaler.

I EIP-7702-scenariet

• signerer imidlertid brukeren en autorisasjonstransaksjon, og videresenderen eller bunteren kringkaster den på vegne av brukeren. Når en transaksjon utføres, er "tx.origin" videresendingsadressen, ikke brukeradressen.

• "msg.sender" er en lommebokkontrakt som representerer brukerens identitet.

Derfor vil tillatelsesverifiseringen basert på "tx.origin == msg.sender" føre til at legitime brukeroperasjoner blir avvist og mister påliteligheten, og de samme begrensede kontraktskallene som "tx.origin == user" vil også bli ugyldige. Det anbefales å forlate "tx.origin" som grunnlag for sikkerhetsvurdering og bruke signaturverifisering eller autorisasjonsmekanisme i stedet.

(3) "isContract" feilbedømmerMange kontrakter

hindrer kontraktskontoer i å delta i visse operasjoner, for eksempel airdrops, flash-salg, etc., gjennom "isContract(adresse)":

require(!isContract(msg.sender), "Kontrakter ikke tillatt"

). Under EIP-7702-mekanismen kan brukerens adresse endres til en kontraktskonto gjennom en "set_code"-transaksjon, og "isContract" returnerer sann, og kontrakten vil feilaktig identifisere den legitime brukeren som kontraktskontoen og nekte å delta i operasjonen, noe som resulterer i at brukeren ikke kan bruke visse tjenester og opplevelsen blir blokkert.

Med den gradvise populariseringen av kontraktslommebøker, utformingen av å stole på "isContract" for å avgjøre om "en menneskelig bruker" ikke lenger er sikker, og det anbefales å bruke mer nøyaktige brukeridentifikasjonsmetoder som signaturverifisering.

3. Phishing-angrepEtter

implementeringen av EIP-7702s delegeringsmekanisme, vil eiendelene på brukerens konto bli fullstendig kontrollert av den delegerte smarte kontrakten. Når en bruker autoriserer en ondsinnet kontrakt, kan en angriper få full kontroll over kontomidlene, noe som resulterer i rask overføring eller tyveri av midler, noe som er ekstremt risikabelt.

Derfor, for leverandører av lommeboktjenester, er det nødvendig å støtte EIP-7702-transaksjonsoppløsningen og risikoidentifikasjonsmekanismen så snart som muligAvgjørende. Når en bruker signerer en overdragelsestransaksjon, bør front-end tydelig og fremtredende vise målkontraktadressen, og kombinere støtteinformasjon som kontraktskilde og distribusjonsinformasjon for å hjelpe brukere med å identifisere potensiell phishing eller uredelig atferd, og dermed redusere risikoen for feilsignering. Videre bør lommeboktjenesten integrere automatiske sikkerhetsanalysefunksjoner for målkontrakten, for eksempel statuskontroll av kontraktkode åpen kildekode, tillatelsesmodellanalyse og potensielt farlig operasjonsidentifikasjon, for å hjelpe brukere med å gjøre sikrere vurderinger før autorisasjon.

Spesielt introduserer EIP-7702 et delegert signaturformat som ikke er kompatibelt med de eksisterende signaturstandardene EIP-191 og EIP-712. Signaturen kan enkelt omgå den opprinnelige signaturadvarselen og interaksjonsmeldingen til lommeboken, noe som ytterligere øker risikoen for at brukere blir lurt til å signere ondsinnede operasjoner. Derfor vil innføringen av identifikasjons- og behandlingsmekanismen til signaturstrukturen i lommebokimplementeringen være et nøkkelledd for å sikre brukernes sikkerhet.

4. Risiko for lommebokkontrakter

( 1) Administrasjon av lommebokkontrakter

Mange EIP-7702-lommebokkontrakter tar i bruk en proxy-arkitektur (eller innebygde administrasjonstillatelser) for å støtte logiske oppgraderinger. Dette utgjør imidlertid også en høyere risiko for rettighetsforvaltning. Hvis eskaleringsrettighetene ikke er strengt begrenset, kan en angriper erstatte implementeringskontrakten og injisere skadelig kode, noe som resulterer i at brukerens konto blir tuklet med eller midler stjålet.

Sikkerhetsanbefalinger

• : Bruk multisignatur-, multifaktorautentisering eller tidslåsmekanismer for å kontrollere eskaleringsprivilegier.

• Kode- og tillatelsesendringer er underlagt streng revisjon og sikkerhetsvalidering.

• Oppgraderingsprosessen er åpen og transparent for å sikre brukernes rett til å vite og delta.

(2) Risiko for lagringskonflikter og dataisolering,

versjoner av lommebokkontrakter eller forskjellige leverandører av lommeboktjenester kan gjenbruke det samme lagringssporet. Hvis brukeren endrer lommeboktjenesteleverandøren eller oppgraderer lommeboklogikken, vil gjenbruk av lagringssporet føre til tilstandsvariabelkonflikt, dataoverskriving, leseunntak og andre problemer. Ikke bare kan dette forstyrre den normale funksjonen til lommeboken, men det kan også føre til tap av midler eller unormale tillatelser.

Sikkerhetsanbefalinger:

• Bruk et spesialisert lagringsisoleringsskjema, for eksempel EIP-1967-standarden, eller bruk et unikt navneområde for å administrere lagringsspor.

• Når du oppgraderer kontrakten, må du sørge for at lagringsoppsettet er kompatibelt og unngå overlappende variabler.

• Test grundig plausibiliteten til den lagrede tilstanden under oppgraderingsprosessen.

(3) Nonce-administrasjonen inne i lommeboken

Lommebokkontrakten setter vanligvis opp en nonce inne og administrerer seg selv for å sikre utførelsesrekkefølgen for brukeroperasjoner og forhindre replay-angrep. Hvis nonce brukes feil, vil ikke brukeroperasjonen bli utført riktig.

Sikkerhetsanbefaling:

• Nonce-verdien må kontrolleres med makt for en tilsvarende verdi (eller økning) og kan ikke hoppes over.

• Det er forbudt for funksjoner å endre nonce-verdien direkte, og nonce-verdien oppdateres bare når brukeroperasjonen utføres.

• Utform feiltoleranse og gjenopprettingsmekanismer for nonce-unntak for å unngå nonce-vranglåser.

(4) Kontroll av funksjonsanropstillatelseFor

å ivareta sikkerheten må lommebokkontrakten sørge for at den som ringer opp nøkkelfunksjonen, er eierkontoen til lommeboken. De to vanlige metodene inkluderer:

• signering utenfor kjeden autoriserer

brukere til å signere et sett med operasjoner gjennom den private nøkkelen, og lommebokkontrakten bekrefter om signaturen er legitim, utløpt og tilfredsstiller den tilsvarende nonce på kjeden. Denne metoden kan brukes på relétransaksjonsmodusen som anbefales av EIP-7702 (brukerens frakoblede signatur + videresender sender transaksjonen på vegne av brukeren).

• Anropsbegrensningen (msg.sender == adresse(dette))

brukerhandlingsfunksjonen kan bare utløses av selve kontrakten, som i hovedsak er en kontrollmekanisme for anropsbane som sikrer at den eksterne initiativtakeren må være selve kontoen. Dette tilsvarer i praksis å kreve at innringeren er den opprinnelige EOA, siden kontraktsadressen er EOA-adressen.

3. Fremtidsutsikter: Forslaget til EIP-7702 og den fremtidige AA-lommebokstandarden

EIP-7702 er ikke bare en innovasjon av den tradisjonelle kontomodellen, men også en stor promotering av kontoabstraksjonsøkosystemet. Muligheten til å laste inn kontraktskode introdusert av den gir et bredt rom for utforskning for fremtidig lommebokdesign og kontraktssystem, og stiller også nye krav til sikkerhetsrevisjonsstandarder.

1. Samutvikling med EIP-4337: Mot dual-mode-kompatibilitetSelv

om EIP-7702 og EIP-4337 har forskjellige designmål, rekonstruerer førstnevnte kodeinnlastingsmekanismen til kontoen, og sistnevnte bygger et komplett transaksjonsoppførings- og pakkeøkosystem. De to er imidlertid ikke i konflikt, men har sterk komplementaritet:

● EIP-4337 gir en "felles transaksjonskanal" og et "abstrakt grensesnitt for kontoutførelse";

● EIP-7702 lar brukerkontoer dynamisk gi kontraktslogikkfunksjoner uten å endre adressen;

Derfor kan lommebøker i fremtiden ta i bruk en «dual-mode support-arkitektur»: bruk EIP-7702 som en lett erstatning på kjeder som ikke støtter EIP-4337, og fortsett å stole på hele protokollstabelen til EIP-4337 i scenarier som krever off-chain-pakking og flerbrukeraggregering.

Denne dual-mode-mekanismen vil også gjøre det mulig for lommebøker å støtte mer fleksible kontotillatelsesmodeller, nedgraderingsmekanismer og tilbakerullingsordninger på kjernelaget.

2. Støtte og inspirasjon for ny lommeboklogikk som MPC og ZK, og

kontokontraktsmekanismen som EIP-7702 tar til orde for, har naturlig integrasjonspotensial med den nåværende populære MPC-lommeboken, ZK-lommeboken, modulære lommeboken og andre nye arkitekturer:

● I MPC-modellen er signaturatferden ikke lenger avhengig av en enkelt privat nøkkel, men er en samarbeidsbeslutning fra flere parter. Signaturer generert gjennom konvergensen mellom EIP-7702 og MPC kontrollerer den dynamisk lastede kontraktslogikken, noe som muliggjør mer fleksible utførelsesstrategier.

● ZK-lommebok verifiserer brukeridentitet eller autorisasjon gjennom nullkunnskapsbevis, uten å avsløre privat nøkkelinformasjon. Kombinert med EIP-7702 kan ZK-lommebøker midlertidig injisere spesifikke logiske kontrakter etter at verifiseringen er fullført, for å realisere distribusjonen av personlig tilpasset atferd etter personverndatabehandling, for eksempel automatisk kjøring av en bestemt logikk først etter at visse personvernbetingelser er oppfylt.

● Modulære lommebøker kan bruke EIP-7702 til å demontere kontologikken i flere moduler og laste dem dynamisk når det er nødvendig.

Derfor gir EIP-7702 en mer naturlig "utførelsesbeholder" for de ovennevnte avanserte lommebøkene: forskjellig kontraktslogikk kan injiseres med samme brukeradresse, noe som unngår adresseavhengighetsproblemet i den tradisjonelle kontraktsdistribusjonsprosessen, og eliminerer behovet for forhåndsdistribusjon, noe som i stor grad forbedrer fleksibiliteten og kombinasjonen av kontoatferd.

3. Implikasjoner for kontraktsutviklere og

vil drive en dyptgripende endring i utviklingsparadigmet. Kontraktsutviklere behandler ikke lenger bare innringeren som en tradisjonell EOA eller en fast kontraktskonto, men må tilpasse seg en ny mekanisme: innringerens identitet kan dynamisk byttes mellom EOA og kontraktsstatus under transaksjonen, og kontoatferdslogikken er ikke lenger statisk stivnet, men kan endres fleksibelt i henhold til etterspørselen. Dette krever at utviklere og revisorer:

• introduserer strengere anropsverifisering og tillatelsesvurderingslogikk;

• Kontroller om kallebanen påvirkes av den dynamiske kontraktlogikken.

• identifisere potensielle sårbarheter som er avhengige av atferd som msg.sender.code.length == 0, isContract(), etc.;

• Klargjør «kontekstavhengighetene» av kontraktslogikk, for eksempel grensekontroll for statiske kall og delegatekall;

• På verktøykjedenivå støttes simulering og tilbakestillingsanalyse av setCode-scenarier.

Med andre ord er kodesikkerhet ikke lenger bare et "pre-distribusjonsproblem", men en "dynamisk prosess som må verifiseres under påkalling og transaksjon".

4.

introduserer en lettere, naturlig og fleksibel implementering av Account Abstraction (AA), slik at vanlig EOA kan bære kontraktslogikk og utføre den i en enkelt transaksjon. Denne mekanismen bryter de tradisjonelle statiske antagelsene om kontoatferd, og utviklere kan ikke lenger bare stole på kodetilstanden til kontoadressen for å bedømme atferdsmodellen, men må rekonstruere forståelsen av identiteten og autoritetsgrensen til anroperen.

Med det kommer et paradigmeskifte innen sikkerhetsanalyse. Fokuset for revisjonen er ikke lenger begrenset til «om en adresse har tillatelser», men til «hva kontraktslogikken i transaksjonen kan gjøre i den nåværende konteksten». Hver transaksjon kan ha en uavhengig definisjon av atferd, noe som gir kontoen større funksjonalitet og stiller høyere krav til sikkerhetsrevisjoner.