Beosin: EIP-7702 și analiza de audit de securitate a portofelului AA de ultimă generație

Abstracția conturilor (AA) este o direcție importantă de explorare pe termen lung în ecosistemul Ethereum, cu scopul de a sparge granița dintre conturile externe (EOA) și conturile contractuale, astfel încât portofelul să aibă programabilitate, securitate și actualizare mai puternice. EIP-4337 este în prezent cea mai populară soluție de implementare AA și a fost utilizată pe scară largă într-o serie de portofele de contracte inteligente bazate pe EntryPoint (cum ar fi Safe, Stacks și Argent). Cu toate acestea, EIP-4337 are încă anumite limitări în ceea ce privește caracterul nativ on-chain, complexitatea operațională și compatibilitatea ecologică datorită introducerii unui grup de tranzacții independent și a unui mecanism de contract la rampă.

Pentru a reduce și mai mult bariera de intrare și pentru a îmbunătăți suportul nativ pentru abstracțiunile de conturi, Vitalik a propus EIP-7702 în 2024 și l-a inclus în actualizarea Pectra. Ideea de bază a EIP-7702 este de a permite unui EOA original să execute codul de contract (contract_code) al unei adrese specificate atunci când inițiază o tranzacție și să utilizeze acest cod pentru a defini logica de execuție a tranzacției.

EIP-7702 introduce un nou mecanism pentru "injecția de cod la nivel de tranzacție", care permite conturilor de utilizator să specifice dinamic logica de execuție în fiecare tranzacție, mai degrabă decât să se bazeze pe codul de contract pre-implementat. Acest lucru rupe modelul tradițional de permisiune bazat pe cod static, aduce o mai mare flexibilitate și introduce noi provocări de securitate: contractele care se bazează pe logica de judecată, cum ar fi isContract și extcodehash, pot deveni invalide, iar unele sisteme care presupun că apelantul este EOA pur pot fi, de asemenea, ocolite. Pentru auditori, este important nu numai să verifice securitatea codului injectat în sine, ci și să evalueze impactul potențial al acestuia asupra altor sisteme contractuale într-un context dinamic.

În acest articol, echipa de securitate Beosin se va concentra pe principiile de proiectare și caracteristicile cheie ale EIP-7702, va sorta sistematic riscurile de securitate cu care se poate confrunta portofelul AA construit pe baza acestuia în timpul auditului și va prezenta procesul de audit și sugestiile dintr-o perspectivă practică pentru a ajuta cercetătorii în securitate să facă față mai bine provocărilor tehnice din această nouă paradigmă.

1. Introducere în EIP-77021

. EIP-7702

Prezentare tehnicăEIP-7702 introduce un nou tip de tranzacție, 0x 04 (SetCode), care permite EOA să autorizeze codul de contract care trebuie executat prin această tranzacție, cu următoarea structură de tranzacție:

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

2. destinație, valoare, date, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

În cazul în care authorization_list conține mai multe liste de autorizare și poate conține și acțiuni de autorizare ale non-inițiatorilor de tranzacții, structura internă este:

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

unde chain_id reprezintă lanțul în care autorizația utilizatorului intră în vigoare, iar valoarea sa trebuie să fie egală cu ID-ul lanțului de execuție sau 0. Când chain_id este 0, autorizația intră în vigoare pentru toate lanțurile EVM care acceptă EIP-7702, dar numai dacă alți parametri (cum ar fi nonce) se potrivesc. Adresa indică adresa contractului țintă autorizată de utilizator.

După finalizarea autorizării, sistemul va modifica câmpul de cod al utilizatorului autorizat la 0x ef 0100 || adresă, unde adresa este adresa contractului autorizat. Dacă doriți să retrageți autorizarea, pur și simplu inițiați o tranzacție SetCode cu adresa setată la 0.

2. Avantajele EIP 7702

(1) Flexibilitate și personalizare

Conturi abstractePrin scrierea logicii contului în contracte inteligente, puteți personaliza în mod flexibil funcțiile în funcție de nevoile dvs. De exemplu, utilizatorii pot configura semnături multiple, recuperare socială și controlul cotelor pentru a satisface nevoile persoanelor sau întreprinderilor în diferite scenarii. Acest design îmbunătățește considerabil scalabilitatea funcțională a contului și depășește limitările conturilor externe tradiționale (EOA).

(2) Securitate îmbunătățităConturile

abstracte oferă un mecanism de securitate pe mai multe niveluri, inclusiv autentificare cu mai mulți factori, limite de tranzacții și recuperare socială. Chiar dacă un utilizator își pierde cheia privată, își poate recupera contul prin contacte de încredere sau autentificare cu mai mulți factori, evitând pierderea permanentă a activelor cauzată de pierderea cheii private în conturile tradiționale. În același timp, funcții precum controlul limitelor pot preveni, de asemenea, furtul unor sume mari de fonduri.

(3) Contul de captare optimizată a gazului

acceptă un mecanism flexibil de captare a gazului, permițând utilizatorilor să plătească pentru gaz printr-o terță parte și chiar să utilizeze direct alte token-uri pentru a plăti taxele de tranzacție. Acest mecanism nu numai că reduce costul de operare al utilizatorilor, dar simplifică și mai mult utilizarea blockchain-ului, potrivit în special pentru utilizatorii începători sau scenarii complexe de tranzacții în mai mulți pași.

(4) Promovarea popularizării Web3Prin

optimizarea experienței și securității, conturile abstracte ascund complexitatea blockchain-ului în locuri pe care utilizatorii nu le pot vedea, oferind operațiuni convenabile mai aproape de Web2. Acest design reduce costul de învățare al utilizatorilor obișnuiți, permite mai multor oameni să participe la aplicațiile Web3 fără bariere și promovează popularizarea tehnologiei descentralizate.

2. Analiza riscurilor de securitate în EIP-7702 în practică

Deși EIP-7702 a injectat un nou impuls în ecosistemul Ethereum și a extins o mulțime de scenarii de aplicare, în același timp, a introdus în mod inevitabil unele noi riscuri de securitate:

1. Atac de reluare a autorizației

Conform modelului EIP-7702, dacă utilizatorul autorizează chain_ Dacă câmpul id este setat la 0, autorizarea poate intra în vigoare pe mai multe lanțuri. Deși acest design de "autorizare universală cross-chain" îmbunătățește flexibilitatea în unele scenarii, introduce și riscuri evidente de securitate.

Este important de reținut că, chiar dacă identitatea contului aceleiași adrese este aceeași pe lanțuri diferite, implementarea contractului din spatele acesteia poate fi complet diferită. Aceasta înseamnă că un atacator ar putea implementa o versiune rău intenționată a contractului pe un alt lanț și ar putea efectua acțiuni neintenționate folosind autorizarea aceleiași adrese din lanț, prezentând astfel riscuri pentru activele utilizatorilor.

Prin urmare, pentru furnizorii de servicii de portofel sau platformele de interacțiune front-end, atunci când utilizatorii efectuează astfel de operațiuni de autorizare, aceștia ar trebui să verifice în mod clar dacă chainId-ul declarat în autorizația utilizatorului este în concordanță cu rețeaua de conectare curentă; Dacă un utilizator este detectat setând chainId la 0, ar trebui să se dea un avertisment clar de risc pentru a reaminti utilizatorului că autorizarea va intra în vigoare pe toate lanțurile compatibile cu EVM și poate fi abuzată de contracte rău intenționate.

În plus, furnizorul de servicii ar trebui să evalueze dacă să restricționeze sau să interzică autorizarea cu chainId 0 în mod implicit la nivelul interfeței de utilizare pentru a reduce riscul de funcționare greșită sau atacuri de phishing.

2. Compatibilitatea contractului

1) Compatibilitatea apelului invers al contractului

transferă bani către o adresă de contract pentru contracte token existente, cum ar fi ERC-721, ERC-777 și ERC 1155, acestea vor apela interfețe de apel invers standard (cum ar fi onERC 721 Received, tokensReceived) pentru a finaliza operațiunea de transfer. Dacă adresa de primire nu implementează interfața corespunzătoare, transferul va eșua sau chiar va cauza blocarea activului.

În EIP-7702, o adresă de utilizator poate fi transformată într-un cont de contract prin primirea unui cod de contract prin operațiunea "set_code". În acest caz:

• Adresa utilizatorului este considerată un contract;

• Dacă contractul nu implementează interfața de apelare inversă necesară, transferul de token va eșua;

Este

• posibil ca utilizatorii să nu poată primi token-uri mainstream fără știrea lor.

Prin urmare, dezvoltatorii ar trebui să se asigure că contractul țintă delegat de utilizator implementează interfața de apel invers relevantă pentru a asigura compatibilitatea cu tokenurile principale.

(2) verificarea "tx.origin" eșueazăÎn

contractele tradiționale, "tx.origin" este adesea folosit pentru a determina dacă tranzacția este inițiată direct de utilizator și este folosit pentru a preveni controalele de securitate, cum ar fi apelurile contractuale.

Cu toate acestea, în scenariul EIP-7702,

• utilizatorul semnează o tranzacție de autorizare, iar retransmisorul sau grupatorul o difuzează în numele utilizatorului. Când se execută o tranzacție, "tx.origin" este adresa de retransmisie, nu adresa utilizatorului.

• "msg.sender" este un contract de portofel care reprezintă identitatea utilizatorului.

Prin urmare, verificarea permisiunii bazată pe "tx.origin == msg.sender" va face ca operațiunile legitime ale utilizatorului să fie respinse și să își piardă fiabilitatea, iar aceleași apeluri contractuale restricționate, cum ar fi "tx.origin == user" vor fi, de asemenea, invalidate. Este recomandat să renunțați la "tx.origin" ca bază pentru judecata de securitate și să utilizați în schimb mecanismul de verificare sau autorizare a semnăturii.

(3) "isContract" judecă greșitMulte

contracte împiedică conturile contractuale să participe la anumite operațiuni, cum ar fi airdrop-uri, vânzări flash etc., prin "isContract(address)":

require(!isContract(msg.sender), "Contracte nu permise").

În cadrul mecanismului EIP-7702, adresa utilizatorului poate fi schimbată într-un cont contractual printr-o tranzacție "set_code", iar "isContract" returnează true, iar contractul va identifica în mod eronat utilizatorul legitim ca fiind contul contractual și va refuza să participe la operațiune, ceea ce va duce la imposibilitatea utilizatorului de a utiliza anumite servicii și blocarea experienței.

Odată cu popularizarea treptată a portofelelor contractuale, designul de a se baza pe "isContract" pentru a determina dacă "un utilizator uman" nu mai este sigur și se recomandă utilizarea unor metode mai precise de identificare a utilizatorilor, cum ar fi verificarea semnăturii.

3. Atac de phishingDupă

implementarea mecanismului de delegare al EIP-7702, activele din contul utilizatorului vor fi controlate pe deplin de contractul inteligent delegat. Odată ce un utilizator autorizează un contract rău intenționat, un atacator poate obține control deplin asupra activelor contului, ceea ce duce la transferul rapid sau furtul de fonduri, ceea ce este extrem de riscant.

Prin urmare, pentru furnizorii de servicii de portofel, este necesar să sprijine mecanismul EIP-7702 de rezoluție a tranzacțiilor și de identificare a riscurilor cât mai curând posibilCrucial. Atunci când un utilizator semnează o tranzacție de încredințare, front-end-ul ar trebui să afișeze în mod clar și vizibil adresa contractului țintă și să combine informații justificative, cum ar fi sursa contractului și informațiile de implementare, pentru a ajuta utilizatorii să identifice potențialele comportamente de phishing sau frauduloase, reducând astfel riscul de semnare greșită. Mai mult, serviciul de portofel ar trebui să integreze capabilități automate de analiză a securității pentru contractul țintă, cum ar fi verificarea stării codului contractului open source, analiza modelului de permisiune și identificarea operațiunilor potențial periculoase, pentru a ajuta utilizatorii să facă judecăți mai sigure înainte de autorizare.

În special, EIP-7702 introduce un format de semnătură delegată care nu este compatibil cu standardele existente de semnătură EIP-191 și EIP-712. Semnătura sa poate ocoli cu ușurință avertismentul original de semnătură și solicitarea de interacțiune a portofelului, ceea ce crește și mai mult riscul ca utilizatorii să fie înșelați să semneze operațiuni rău intenționate. Prin urmare, introducerea mecanismului de identificare și procesare a structurii de semnături în implementarea portofelului va fi o legătură cheie pentru asigurarea securității utilizatorilor.

4. Riscurile contractului de portofel

( 1) Managementul autorității contractelor de portofel

Multe contracte de portofel EIP-7702 adoptă o arhitectură proxy (sau permisiuni de gestionare încorporate) pentru a susține actualizările logice. Cu toate acestea, acest lucru prezintă și un risc mai mare de gestionare a drepturilor. Dacă privilegiile de escaladare nu sunt strict restricționate, un atacator poate înlocui contractul de implementare și poate injecta cod rău intenționat, ceea ce duce la manipularea contului utilizatorului sau la furtul de fonduri.

Recomandări de securitate

• : Utilizați mecanisme de semnătură multiplă, autentificare cu mai mulți factori sau de blocare temporală pentru a controla privilegiile de escaladare.

• Modificările codului și permisiunilor sunt supuse unui audit riguros și unei validări de securitate.

• Procesul de actualizare este deschis și transparent pentru a asigura dreptul utilizatorilor de a cunoaște și de a participa.

(2) Riscul de conflicte de stocare și izolare a datelor,

versiunile contractului de portofel sau diferiți furnizori de servicii de portofel pot reutiliza același slot de stocare. Dacă utilizatorul schimbă furnizorul de servicii de portofel sau actualizează logica portofelului, reutilizarea slotului de stocare va cauza conflictul variabilei de stare, suprascrierea datelor, excepții de citire și alte probleme. Acest lucru nu numai că poate perturba funcționarea normală a portofelului, dar poate duce și la pierderea de fonduri sau la permisiuni anormale.

Recomandări de securitate:

• Utilizați o schemă specializată de izolare a stocării, cum ar fi standardul EIP-1967, sau utilizați un spațiu de nume unic pentru a gestiona sloturile de stocare.

• Când actualizați contractul, asigurați-vă că aspectul de stocare este compatibil și evitați suprapunerea variabilelor.

• Testați riguros plauzibilitatea stării stocate în timpul procesului de actualizare.

(3) Managementul nonce în interiorul portofelului

Contractul de portofel configurează de obicei un nonce în interior și se gestionează singur pentru a asigura ordinea de execuție a operațiunilor utilizatorului și pentru a preveni atacurile de reluare. Dacă nonce este utilizat incorect, operațiunea utilizatorului nu va fi executată corect.

Recomandare de securitate:

• Nonce trebuie verificat forțat pentru o valoare echivalentă (sau increment) și nu poate fi omis.

• Este interzis ca funcțiile să modifice direct nonce, iar nonce va fi actualizat numai atunci când operațiunea utilizatorului este executată.

• Proiectați mecanisme de toleranță la erori și de recuperare pentru excepțiile nonce pentru a evita blocajele nonce.

(4) Verificarea permisiunii apelantului funcțieiPentru

a asigura securitatea, contractul portofelului trebuie să asigure că apelantul funcției cheie este contul proprietar al portofelului. Cele două metode comune includ:

• semnarea în afara lanțului autorizează

utilizatorii să semneze un set de operațiuni prin cheia privată, iar contractul portofelului verifică dacă semnătura este legitimă, expirată și satisface nonce corespunzător pe lanț. Această metodă este aplicabilă modului de tranzacție cu releu susținut de EIP-7702 (semnătura offline a utilizatorului + retransmisul trimite tranzacția în numele utilizatorului).

• de constrângere de apel (msg.sender == address(this))

poate fi declanșată numai de contractul în sine, care este în esență un mecanism de control al căii de apel care asigură că inițiatorul extern trebuie să fie contul însuși. Acest lucru este efectiv echivalent cu solicitarea apelantului să fie EOA inițial, deoarece adresa contractului este adresa EOA.

3. Perspectivă: Propunerea EIP-7702 și viitorul standard de portofel AA

EIP-7702 nu este doar o inovație a modelului tradițional de cont, ci și o promovare majoră a ecosistemului de abstractizare a conturilor. Capacitatea de a încărca codul de contract introdus de acesta aduce un spațiu larg de explorare pentru viitorul proiectare a portofelelor și a sistemului de contracte și, de asemenea, propune noi cerințe pentru standardele de audit de securitate.

1. Co-evoluție cu EIP-4337: Către compatibilitate dual-modeDeși

EIP-7702 și EIP-4337 au obiective de proiectare diferite, primul reconstruiește mecanismul de încărcare a codului contului, iar cel de-al doilea construiește un ecosistem complet de intrare și ambalare a tranzacțiilor. Cu toate acestea, cele două nu sunt în conflict, dar au o complementaritate puternică:

● EIP-4337 oferă un "canal comun de tranzacție" și o "interfață abstractă de execuție a contului";

● EIP-7702 permite conturilor de utilizator să acorde dinamic capabilități logice contractuale fără a schimba adresa;

Prin urmare, în viitor, portofelele ar putea adopta o "arhitectură de suport dual-mode": utilizați EIP-7702 ca înlocuitor ușor pe lanțurile care nu suportă EIP-4337 și continuați să se bazeze pe stiva completă de protocoale a EIP-4337 în scenarii care necesită ambalare în afara lanțului și agregare multi-utilizator.

Acest mecanism dual-mode va permite, de asemenea, portofelelor să accepte modele de permisiuni de cont mai flexibile, mecanisme de downgrade și scheme de rollback la nivelul nucleului.

2. Suport și inspirație pentru noua logică a portofelului, cum ar fi MPC și ZK, iar

mecanismul de contract de cont susținut de EIP-7702 are un potențial natural de integrare cu portofelul MPC popular actual, portofelul ZK, portofelul modular și alte arhitecturi noi:

● În modelul MPC, comportamentul de semnătură nu se mai bazează pe o singură cheie privată, ci este un proces decizional colaborativ cu mai multe părți. Semnăturile generate prin convergența EIP-7702 și MPC controlează logica contractului încărcat dinamic, permițând strategii de execuție mai flexibile.

● Portofelul ZK verifică identitatea sau autorizarea utilizatorului prin dovezi zero-knowledge, fără a expune informații despre cheia privată. Combinate cu EIP-7702, portofelele ZK pot injecta temporar contracte logice specifice după finalizarea verificării, astfel încât să realizeze implementarea unor comportamente personalizate după calcularea confidențialității, cum ar fi executarea automată a unei anumite logici numai după îndeplinirea anumitor condiții de confidențialitate.

● Portofelele modulare pot folosi EIP-7702 pentru a dezasambla logica contului în mai multe module și pentru a le încărca dinamic atunci când este necesar.

Prin urmare, EIP-7702 oferă un "container de execuție" mai nativ pentru portofelele avansate menționate mai sus: diferite logici contractuale pot fi injectate cu aceeași adresă de utilizator, evitând problema dependenței de adresă în procesul tradițional de implementare a contractului și eliminând nevoia de pre-implementare, îmbunătățind considerabil flexibilitatea și combinația comportamentului contului.

3. Implicații pentru dezvoltatorii și

va conduce la o schimbare profundă în paradigma de dezvoltare. Dezvoltatorii de contracte nu mai tratează apelantul ca pe un EOA tradițional sau un cont de contract fix, ci trebuie să se adapteze la un nou mecanism: identitatea apelantului poate fi comutată dinamic între EOA și statutul contractului în timpul tranzacției, iar logica comportamentului contului nu mai este solidificată static, ci poate fi modificată în mod flexibil în funcție de cerere. Acest lucru necesită dezvoltatorilor și auditorilor să:

• introducă o logică mai strictă de verificare a apelantului și de judecată a permisiunilor;

• Verificați dacă calea apelului este afectată de logica dinamică a contractului;

• identificați potențialele vulnerabilități care se bazează pe comportamente precum msg.sender.code.length == 0, isContract() etc.;

• Clarificarea "dependențelor de context" ale logicii contractului, cum ar fi controlul limitelor apelurilor statice și apelurile delegate;

• La nivel de lanț de instrumente, sunt acceptate simularea și analiza de revenire a scenariilor setCode.

Cu alte cuvinte, securitatea codului nu mai este doar o "problemă de pre-implementare", ci un "proces dinamic care trebuie verificat în timpul invocării și tranzacției".

4.

introduce o implementare mai ușoară, nativă și flexibilă a abstracției conturilor (AA), astfel încât EOA obișnuit să poată transporta logica contractului și să o execute într-o singură tranzacție. Acest mecanism sparge ipotezele statice tradiționale despre comportamentul contului, iar dezvoltatorii nu se mai pot baza pur și simplu pe starea codului adresei contului pentru a-i judeca modelul de comportament, ci trebuie să reconstruiască înțelegerea identității și limitei de autoritate a apelantului.

Odată cu aceasta vine o schimbare de paradigmă în analiza securității. Accentul auditului nu se mai limitează la "dacă o adresă are permisiuni", ci la "ce poate face logica contractului în tranzacție în contextul actual". Fiecare tranzacție poate avea o definiție independentă a comportamentului, care oferă contului o funcționalitate mai mare și prezintă cerințe mai ridicate pentru auditurile de securitate.