Beosin: EIP-7702 e analisi di audit della sicurezza del portafoglio AA di nuova generazione

L'Account Abstraction (AA) è un'importante direzione di esplorazione a lungo termine nell'ecosistema Ethereum, con l'obiettivo di rompere il confine tra account esterni (EOA) e account a contratto, in modo che il portafoglio abbia una maggiore programmabilità, sicurezza e aggiornabilità. EIP-4337 è attualmente la soluzione di implementazione AA più diffusa ed è stata ampiamente utilizzata in una serie di portafogli di smart contract basati su EntryPoint (come Safe, Stacks e Argent). Tuttavia, EIP-4337 presenta ancora alcune limitazioni in termini di nativatà on-chain, complessità operativa e compatibilità ecologica a causa dell'introduzione di un pool di transazioni indipendente e di un meccanismo di contratto on-ramp.

Per ridurre ulteriormente la barriera all'ingresso e migliorare il supporto nativo per le astrazioni degli account, Vitalik ha proposto EIP-7702 nel 2024 e lo ha incluso nell'aggiornamento Pectra. L'idea centrale di EIP-7702 è quella di consentire a un EOA originale di eseguire il codice contratto (contract_code) di un indirizzo specificato all'avvio di una transazione e di utilizzare questo codice per definire la logica di esecuzione della transazione.

EIP-7702 introduce un nuovo meccanismo per l'"iniezione di codice a livello di transazione", che consente agli account utente di specificare dinamicamente la logica di esecuzione in ogni transazione, piuttosto che fare affidamento su codice contrattuale pre-distribuito. Ciò interrompe il tradizionale modello di autorizzazione statico basato su codice, offre una maggiore flessibilità e introduce nuove sfide di sicurezza: i contratti che si basano su logiche di giudizio come isContract e extcodehash possono diventare non validi e alcuni sistemi che presumono che il chiamante sia puro EOA possono anche essere ignorati. Per gli auditor, è importante non solo verificare la sicurezza del codice iniettato stesso, ma anche valutarne il potenziale impatto su altri sistemi contrattuali in un contesto dinamico.

In questo articolo, il team di sicurezza di Beosin si concentrerà sui principi di progettazione e sulle caratteristiche chiave di EIP-7702, risolverà sistematicamente i rischi per la sicurezza che il portafoglio AA costruito sulla base di esso potrebbe affrontare nell'audit e presenterà il processo di audit e i suggerimenti da una prospettiva pratica per aiutare i ricercatori di sicurezza a gestire meglio le sfide tecniche di questo nuovo paradigma.

1. Introduzione a EIP-77021

. Panoramica tecnica di EIP-7702EIP-7702

introduce un nuovo tipo di transazione, 0x 04 (SetCode), che consente a EOA di autorizzare il codice del contratto che deve essere eseguito tramite questa transazione, con la seguente struttura di transazione:

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

2. destinazione, valore, dati, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

Dove authorization_list contiene più elenchi di autorizzazioni e può anche contenere azioni di autorizzazione di iniziatori non di transazione, la struttura interna è:

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

dove chain_id rappresenta la catena in cui l'autorizzazione dell'utente ha effetto e il relativo valore deve essere uguale all'ID della catena in esecuzione o a 0. Quando chain_id è 0, l'autorizzazione ha effetto per tutte le catene EVM che supportano EIP-7702, ma solo se altri parametri (ad esempio nonce) corrispondono. Address indica l'indirizzo del contratto di destinazione autorizzato dall'utente.

Al termine dell'autorizzazione, il sistema modificherà il campo del codice dell'utente autorizzato in 0x ef 0100 || address, dove address è l'indirizzo del contratto autorizzato. Se si desidera rimuovere l'autorizzazione, è sufficiente avviare una transazione SetCode con l'indirizzo impostato su 0.

numero arabo. Vantaggi di EIP 7702

(1) Flessibilità e personalizzazione

Account astrattiScrivendo la logica dell'account negli smart contract, è possibile personalizzare in modo flessibile le funzioni in base alle proprie esigenze. Ad esempio, gli utenti possono configurare la firma multipla, il ripristino social e il controllo delle quote per soddisfare le esigenze di singoli utenti o aziende in diversi scenari. Questo design migliora notevolmente la scalabilità funzionale dell'account e supera i limiti dei tradizionali account esterni (EOA).

(2) Sicurezza avanzataGli

account astratti forniscono un meccanismo di sicurezza a più livelli, tra cui l'autenticazione a più fattori, i limiti delle transazioni e il recupero sociale. Anche se un utente perde la propria chiave privata, può recuperare il proprio account attraverso contatti fidati o l'autenticazione a più fattori, evitando la perdita permanente di beni causata dalla perdita della chiave privata negli account tradizionali. Allo stesso tempo, funzioni come il controllo dei limiti possono anche impedire il furto intenzionale di grandi quantità di fondi.

(3) Il Gas Optimized

Abstraction Account supporta un meccanismo di estrazione flessibile del gas, che consente agli utenti di pagare il gas tramite una terza parte e persino di utilizzare direttamente altri token per pagare le commissioni di transazione. Questo meccanismo non solo riduce i costi operativi degli utenti, ma semplifica ulteriormente l'uso della blockchain, particolarmente adatto per utenti inesperti o complessi scenari di transazione in più passaggi.

(4) Promuovere la divulgazione del Web3Ottimizzando

l'esperienza e la sicurezza, gli account astratti nascondono la complessità della blockchain in luoghi che gli utenti non possono vedere, fornendo operazioni convenienti più vicine al Web2. Questo design riduce i costi di apprendimento degli utenti ordinari, consente a più persone di partecipare alle applicazioni Web3 senza barriere e promuove la divulgazione della tecnologia decentralizzata.

2. Analisi dei rischi per la sicurezza in EIP-7702 In pratica

Sebbene EIP-7702 abbia impresso nuovo slancio nell'ecosistema Ethereum e ampliato una vasta gamma di scenari applicativi, allo stesso tempo ha inevitabilmente introdotto alcuni nuovi rischi per la sicurezza:

1. Attacco di riproduzione dell'autorizzazione

Secondo il modello EIP-7702, se l'utente autorizza il chain_ Se il campo id è impostato su 0, l'autorizzazione può avere effetto su più catene. Sebbene questa progettazione di "autorizzazione universale cross-chain" migliori la flessibilità in alcuni scenari, introduce anche evidenti rischi per la sicurezza.

È importante notare che anche se l'identità dell'account dello stesso indirizzo è la stessa su catene diverse, l'implementazione del contratto dietro di esso potrebbe essere completamente diversa. Ciò significa che un utente malintenzionato potrebbe distribuire una versione dannosa del contratto su un'altra catena ed eseguire azioni non intenzionali utilizzando l'autorizzazione dello stesso indirizzo sulla catena, ponendo così dei rischi per le risorse degli utenti.

Pertanto, per i fornitori di servizi di wallet o le piattaforme di interazione front-end, quando gli utenti eseguono tali operazioni di autorizzazione, dovrebbero verificare chiaramente se il chainId dichiarato nell'autorizzazione dell'utente è coerente con la rete di connessione corrente; Se viene rilevato un utente che imposta chainId su 0, è necessario fornire un chiaro avviso di rischio per ricordare all'utente che l'autorizzazione avrà effetto su tutte le catene compatibili con EVM e potrebbe essere abusata da contratti dannosi.

Inoltre, il fornitore di servizi dovrebbe anche valutare se limitare o vietare l'autorizzazione con chainId 0 per impostazione predefinita a livello di interfaccia utente per ridurre il rischio di operazioni errate o attacchi di phishing.

2. Compatibilità del contratto

1) Compatibilità del callback del contratto

si trasferisce denaro a un indirizzo di contratto per contratti token esistenti come ERC-721, ERC-777 ed ERC 1155, chiameranno le interfacce di callback standard (come onERC 721 Received, tokensReceived) per completare l'operazione di trasferimento. Se l'indirizzo di ricezione non implementa l'interfaccia corrispondente, il trasferimento non riuscirà o addirittura causerà il blocco dell'asset.

In EIP-7702, un indirizzo utente può essere trasformato in un account contratto ricevendo un codice contratto tramite l'operazione "set_code". In questo caso:

• L'indirizzo dell'utente è considerato un contratto;

• Se il contratto non implementa l'interfaccia di callback necessaria, il trasferimento del token avrà esito negativo;

• Gli utenti potrebbero non essere in grado di ricevere token mainstream a loro insaputa.

Pertanto, gli sviluppatori devono assicurarsi che il contratto di destinazione delegato dall'utente implementi l'interfaccia di callback pertinente per garantire la compatibilità con i token mainstream.

(2) La verifica "tx.origin" fallisceNei

contratti tradizionali, "tx.origin" viene spesso utilizzato per determinare se la transazione è avviata direttamente dall'utente e viene utilizzato per prevenire controlli di sicurezza come le chiamate ai contratti.

Tuttavia, nello scenario EIP-7702,

• l'utente firma una transazione di autorizzazione e il relayer o il bundler la trasmette per conto dell'utente. Quando viene eseguita una transazione, "tx.origin" è l'indirizzo del relayer, non l'indirizzo dell'utente.

• "msg.sender" è un contratto di portafoglio che rappresenta l'identità dell'utente.

Pertanto, la verifica dei permessi basata su "tx.origin == msg.sender" causerà il rifiuto delle operazioni legittime dell'utente e la perdita di affidabilità, e le stesse chiamate contrattuali limitate come "tx.origin == user" saranno anche invalidate. Si consiglia di abbandonare "tx.origin" come base per il giudizio di sicurezza e di utilizzare invece la verifica della firma o il meccanismo di autorizzazione.

(3) "isContract" giudica maleMolti

contratti impediscono agli account contrattuali di partecipare a determinate operazioni, come airdrop, vendite flash, ecc., tramite "isContract(address)":

require(!isContract(msg.sender), "Contratti non consentiti").

Nell'ambito del meccanismo EIP-7702, l'indirizzo dell'utente può essere modificato in un account contrattuale tramite una transazione "set_code" e "isContract" restituisce true e il contratto identificherà erroneamente l'utente legittimo come account contrattuale e si rifiuterà di partecipare all'operazione, con il risultato che l'utente non sarà in grado di utilizzare determinati servizi e l'esperienza verrà bloccata.

Con la graduale diffusione dei portafogli a contratto, il design di affidarsi a "isContract" per determinare se "un utente umano" non è più sicuro e si consiglia di utilizzare metodi di identificazione dell'utente più accurati come la verifica della firma.

3. Attacco di phishingDopo

l'implementazione del meccanismo di delega dell'EIP-7702, gli asset nell'account dell'utente saranno completamente controllati dallo smart contract delegato. Una volta che un utente autorizza un contratto dannoso, un utente malintenzionato può ottenere il pieno controllo delle risorse dell'account, con conseguente rapido trasferimento o furto di fondi, il che è estremamente rischioso.

Pertanto, per i prestatori di servizi di portafoglio, è necessario sostenere il meccanismo di risoluzione delle transazioni EIP-7702 e di identificazione dei rischi il prima possibileCruciale. Quando un utente firma una transazione di affidamento, il front-end deve visualizzare in modo chiaro e ben visibile l'indirizzo del contratto di destinazione e combinare le informazioni di supporto, come l'origine del contratto e le informazioni sulla distribuzione, per aiutare gli utenti a identificare potenziali comportamenti di phishing o fraudolenti, riducendo così il rischio di firma errata. Inoltre, il servizio di portafoglio dovrebbe integrare funzionalità di analisi automatica della sicurezza per il contratto di destinazione, come il controllo dello stato open source del codice del contratto, l'analisi del modello di autorizzazione e l'identificazione di operazioni potenzialmente pericolose, per aiutare gli utenti a prendere decisioni più sicure prima dell'autorizzazione.

In particolare, l'EIP-7702 introduce un formato di firma delegata che non è compatibile con gli standard di firma EIP-191 e EIP-712 esistenti. La sua firma può facilmente aggirare l'avviso di firma originale e la richiesta di interazione del portafoglio, il che aumenta ulteriormente il rischio che gli utenti vengano indotti a firmare operazioni dannose. Pertanto, l'introduzione del meccanismo di identificazione ed elaborazione della struttura della firma nell'implementazione del portafoglio sarà un collegamento chiave per garantire la sicurezza degli utenti.

4. Rischi del contratto di portafoglio

( 1) Gestione dell'autorità del contratto di portafoglio

Molti contratti di portafoglio EIP-7702 adottano un'architettura proxy (o autorizzazioni di gestione integrate) per supportare gli aggiornamenti logici. Tuttavia, ciò comporta anche un rischio maggiore per la gestione dei diritti. Se i privilegi di escalation non sono strettamente limitati, un utente malintenzionato può sostituire il contratto di implementazione e iniettare codice dannoso, con conseguente manomissione dell'account dell'utente o furto di fondi.

Raccomandazioni per la sicurezza

• : utilizzare meccanismi di firma multipla, autenticazione a più fattori o timelock per controllare i privilegi di escalation.

• Le modifiche al codice e alle autorizzazioni sono soggette a un controllo rigoroso e alla convalida della sicurezza.

• Il processo di aggiornamento è aperto e trasparente per garantire il diritto degli utenti di conoscersi e partecipare.

(2) Rischio di conflitti di archiviazione e isolamento dei dati, versioni del contratto di

portafoglio o diversi fornitori di servizi di portafoglio possono riutilizzare lo stesso slot di archiviazione. Se l'utente cambia il provider di servizi del portafoglio o aggiorna la logica del portafoglio, il riutilizzo dello slot di archiviazione causerà il conflitto della variabile di stato, la sovrascrittura dei dati, la lettura delle eccezioni e altri problemi. Questo non solo può interrompere il normale funzionamento del portafoglio, ma può anche portare alla perdita di fondi o a autorizzazioni anomale.

Raccomandazioni per la sicurezza:

• utilizzare uno schema di isolamento dello storage specializzato, ad esempio lo standard EIP-1967, o sfruttare uno spazio dei nomi univoco per gestire gli slot di storage.

• Quando si aggiorna il contratto, assicurarsi che il layout di archiviazione sia compatibile ed evitare la sovrapposizione di variabili.

• Testare rigorosamente la plausibilità dello stato archiviato durante il processo di aggiornamento.

(3) La gestione del nonce all'interno del portafoglio

Il contratto del portafoglio di solito imposta un nonce all'interno e si gestisce da solo per garantire l'ordine di esecuzione delle operazioni dell'utente e prevenire attacchi di riproduzione. Se il nonce viene utilizzato in modo errato, l'operazione dell'utente non verrà eseguita correttamente.

Raccomandazione per la sicurezza:

• il nonce deve essere controllato forzatamente per un valore equivalente (o incremento) e non può essere saltato.

• È vietato alle funzioni modificare direttamente il nonce e il nonce verrà aggiornato solo quando viene eseguita l'operazione dell'utente.

• Progettare meccanismi di tolleranza di errore e ripristino per le eccezioni nonce per evitare deadlock nonce.

(4) Controllo dell'autorizzazione del chiamante

della funzioneAl fine di garantire la sicurezza, il contratto del portafoglio deve garantire che il chiamante della funzione chiave sia l'account proprietario del portafoglio. I due metodi comuni includono:

• firma off-chain autorizza

gli utenti a firmare una serie di operazioni tramite la chiave privata e il contratto del portafoglio verifica se la firma è legittima, scaduta e soddisfa il nonce corrispondente sulla catena. Questo metodo è applicabile alla modalità di transazione relay consigliata da EIP-7702 (firma offline dell'utente + relayer invia la transazione per conto dell'utente).

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

essere attivata solo dal contratto stesso, che è essenzialmente un meccanismo di controllo del percorso di chiamata che assicura che l'iniziatore esterno debba essere l'account stesso. Ciò equivale effettivamente a richiedere che il chiamante sia l'EOA originale, poiché l'indirizzo del contratto è l'indirizzo EOA.

3. Prospettive: la proposta dell'EIP-7702 e del futuro standard di portafoglio AA

EIP-7702 non è solo un'innovazione del modello di conto tradizionale, ma anche un'importante promozione dell'ecosistema di astrazione dei conti. La possibilità di caricare il codice del contratto introdotta da esso offre un ampio spazio di esplorazione per la futura progettazione del portafoglio e del sistema contrattuale, e pone anche nuovi requisiti per gli standard di audit di sicurezza.

1. Co-evoluzione con EIP-4337: verso la compatibilità dual-modeSebbene

EIP-7702 e EIP-4337 abbiano obiettivi di progettazione diversi, il primo ricostruisce il meccanismo di caricamento del codice dell'account e il secondo costruisce un ecosistema completo di inserimento e pacchettizzazione delle transazioni. Tuttavia, i due non sono in conflitto, ma hanno una forte complementarietà:

● EIP-4337 fornisce un "canale di transazione comune" e una "interfaccia astratta per l'esecuzione del conto";

● EIP-7702 consente agli account utente di concedere dinamicamente funzionalità logiche di contratto senza modificare l'indirizzo;

Pertanto, in futuro, i wallet potrebbero adottare una "architettura di supporto dual-mode": utilizzare EIP-7702 come sostituto leggero su chain che non supportano EIP-4337 e continuare a fare affidamento sullo stack di protocollo completo di EIP-4337 in scenari che richiedono il packaging off-chain e l'aggregazione multiutente.

Questo meccanismo dual-mode consentirà inoltre ai portafogli di supportare modelli di autorizzazione dell'account più flessibili, meccanismi di downgrade e schemi di rollback a livello di kernel.

2. Supporto e ispirazione per nuove logiche di portafoglio come MPC e ZK e il meccanismo del

contratto di conto sostenuto da EIP-7702 ha un potenziale di integrazione naturale con l'attuale portafoglio MPC, il portafoglio ZK, il portafoglio modulare e altre nuove architetture:

● Nel modello MPC, il comportamento della firma non si basa più su una singola chiave privata, ma è un processo decisionale collaborativo multilaterale. Le firme generate attraverso la convergenza di EIP-7702 e MPC controllano la logica del contratto caricata dinamicamente, consentendo strategie di esecuzione più flessibili.

● Il portafoglio ZK verifica l'identità o l'autorizzazione dell'utente attraverso prove a conoscenza zero, senza esporre le informazioni sulla chiave privata. In combinazione con EIP-7702, i portafogli ZK possono iniettare temporaneamente contratti logici specifici dopo il completamento della verifica, in modo da realizzare l'implementazione di comportamenti personalizzati dopo il calcolo della privacy, come l'esecuzione automatica di una determinata logica solo dopo che sono state soddisfatte determinate condizioni di privacy.

● I portafogli modulari possono utilizzare EIP-7702 per smontare la logica dell'account in più moduli e caricarli dinamicamente quando necessario.

Pertanto, EIP-7702 fornisce un "contenitore di esecuzione" più nativo per i portafogli avanzati sopra menzionati: diverse logiche di contratto possono essere iniettate con lo stesso indirizzo utente, evitando il problema della dipendenza dell'indirizzo nel tradizionale processo di distribuzione del contratto ed eliminando la necessità di pre-distribuzione, migliorando notevolmente la flessibilità e la combinazione del comportamento dell'account.

3. Implicazioni per gli sviluppatori e

guiderà un profondo cambiamento nel paradigma di sviluppo. Gli sviluppatori di contratti non trattano più semplicemente il chiamante come un EOA tradizionale o un conto a contratto fisso, ma devono adattarsi a un nuovo meccanismo: l'identità del chiamante può essere commutata dinamicamente tra EOA e stato del contratto durante la transazione e la logica di comportamento dell'account non è più solidificata staticamente, ma può essere modificata in modo flessibile in base alla domanda. Ciò richiede agli sviluppatori e ai revisori di:

• introdurre una logica di verifica del chiamante e di giudizio delle autorizzazioni più rigorosa;

• Verificare se il percorso della chiamata è interessato dalla logica del contratto dinamico;

• identificare potenziali vulnerabilità che si basano su comportamenti come msg.sender.code.length == 0, isContract(), ecc.;

• Chiarire le "dipendenze di contesto" della logica del contratto, come il controllo dei limiti delle chiamate statiche e delle chiamate delegate;

• A livello di toolchain, sono supportate la simulazione e l'analisi di ripristino degli scenari setCode.

In altre parole, la sicurezza del codice non è più solo un "problema pre-distribuzione", ma un "processo dinamico che deve essere verificato durante la chiamata e la transazione".

4.

introduce un'implementazione più leggera, nativa e flessibile dell'astrazione dell'account (AA), in modo che l'EOA ordinario possa trasportare la logica del contratto ed eseguirla in un'unica transazione. Questo meccanismo rompe le tradizionali ipotesi statiche sul comportamento dell'account e gli sviluppatori non possono più semplicemente fare affidamento sullo stato del codice dell'indirizzo dell'account per giudicare il suo modello di comportamento, ma devono ricostruire la comprensione dell'identità e del limite di autorità del chiamante.

Con ciò arriva un cambiamento di paradigma nell'analisi della sicurezza. L'attenzione dell'audit non è più limitata a "se un indirizzo dispone di autorizzazioni", ma a "ciò che la logica contrattuale contenuta nella transazione può fare nel contesto attuale". Ogni transazione può contenere una definizione indipendente di comportamento, che conferisce all'account una maggiore funzionalità e impone requisiti più elevati per i controlli di sicurezza.