Autore: Alfred, sviluppatore di imToken Labs
Dall'8 all'11 luglio 2024 si è tenuta a Bruxelles, in Belgio, la Ethereum Community Conference (EthCC). È il più grande evento annuale di Ethereum in Europa, incentrato sulla tecnologia e sulla comunità.
A questa Ethereum Community Conference (EthCC 7), più di 350 opinion leader attivi nel settore blockchain hanno tenuto discorsi. imToken Labs Alfred è stato invitato a partecipare e ha tenuto un discorso alla conferenza con il tema "Revealing the Future: Abstract Analysis of Multi-. Conti di catena"" discorso.
Breve riassunto del discorso:
L'astrazione dell'account (AA) comprende principalmente due punti chiave: l'astrazione della firma e l'astrazione del pagamento. L'astrazione della firma consente agli utenti di scegliere qualsiasi meccanismo di verifica preferiscano e l'astrazione del pagamento consente una varietà di opzioni di pagamento delle transazioni. Questa flessibilità offre un'esperienza utente migliore e più sicura.
In ERC-4337 e AA nativo, la funzione del punto di ingresso nella fase di "verifica" è fissa, mentre nella fase di "esecuzione" è fisso solo il punto di ingresso in AA nativo. Le limitazioni alla verifica delle transazioni e ai passaggi per eseguire le transazioni hanno le proprie caratteristiche e limitazioni nelle diverse implementazioni.
Esistono due differenze fondamentali quando si implementa ERC-4337 su una catena compatibile con EVM: differenze di protocollo nella progettazione Rollup e differenze nel modo in cui vengono calcolati gli indirizzi, con conseguenti dettagli di sviluppo difficili da notare quando si implementa ERC-4337 tra L1 e L2.
Quello che segue è il testo completo del discorso:
Ciao a tutti, mi chiamo Alfred e attualmente sono uno sviluppatore blockchain presso imToken Labs. Oggi vi presenterò i concetti di ERC-4337 e AA nativo, discuterò le differenze tra loro e mi concentrerò sull'analisi delle principali differenze tra gli standard 4337 di L1 e L2.
Introduzione all'astrazione contabile
1. Cos'è l'astrazione del conto?
L'astrazione dell'account (AA) comprende principalmente due punti chiave: l'astrazione della firma e l'astrazione del pagamento.
Astrazione della firma: gli utenti possono scegliere qualsiasi meccanismo di verifica preferiscano, non limitarsi solo a determinati algoritmi di firma digitale (come ECDSA).
Astrazione del pagamento: gli utenti possono utilizzare una varietà di opzioni di pagamento delle transazioni, come pagare con risorse ERC-20 invece che con risorse native o avere una terza parte che sponsorizza la transazione.
Questa flessibilità offre un'esperienza utente migliore e più sicura. L’obiettivo dell’astrazione dell’account è raggiungere questi due punti chiave in vari modi.
2. Cos'è l'ERC-4337
Attualmente, ci sono alcune limitazioni agli account di proprietà esterna (EOA) nel protocollo Ethereum, come metodi di firma fissa e modelli di pagamento. L'ERC-4337 affronta questi problemi introducendo un approccio più flessibile alla gestione dei conti e all'elaborazione delle transazioni.
Struttura userOp: in ERC-4337, l'utente invia la struttura userOp a Bundler. Bundler raccoglie più userOps e li invia al contratto EntryPoint chiamando la funzione handleOps.
Contratto EntryPoint: questo contratto gestisce le transazioni come un sistema operativo. Le sue funzioni principali includono:
Chiama la funzione di convalida nel contratto dell'account per garantire che userOp sia autorizzato dal proprietario dell'account.
Tassa.
Chiama la funzione di esecuzione nel contratto dell'account per eseguire l'operazione di destinazione di userOp.
3. Cos'è l'AA nativo?
In Ethereum, i conti sono divisi in conti EOA e conti contrattuali. Tuttavia, nell’AA nativo, ogni conto è un contratto e il meccanismo di elaborazione delle transazioni è direttamente integrato nel protocollo blockchain.
Design AA in ogni rete blockchain:
Astrazione account ERC-4337: Ethereum, Arbitrum, Optimism, Base, Linea, Scroll, Polygon PoS
L'astrazione dell'account nativo segue ERC-4337: era StarkNet e zkSync
Astrazione dell'account nativo con privacy in base alla progettazione: Aztec
Se sei interessato all'AA nativo azteco o all'EIP-3074, EIP-7702, oggi ci concentreremo sull'AA nativo dopo ERC-4337. Per informazioni dettagliate si rimanda all'articolo da me scritto, riportato a fine articolo.
La differenza tra ERC-4337 e AA nativo
1. Ruolo del sistema operativo
AA OS deve rispondere alle seguenti domande:
Chi decide i prezzi del gas?
Chi decide l’ordine delle transazioni? Dov'è il pool di memoria?
Chi attiva la funzione del punto di ingresso?
Cosa determina il flusso di elaborazione delle transazioni?
In ERC-4337, questi ruoli vengono svolti in modo collaborativo tramite il contratto Bundler e EntryPoint.
In AA nativo, gli utenti inviano i propri userOps all'operatore/sequenziatore del server ufficiale invece che al contratto Bundler e EntryPoint.
In StarkNet, il Sequencer gestisce tutte queste attività.
In zkSync, la differenza principale tra Era e altre implementazioni AA è che l'Operatore deve lavorare con il bootloader (contratto di sistema). Il Bootloader apre un nuovo blocco, ne definisce i parametri (inclusi i parametri del blocco e altri parametri del Gas) e riceve le transazioni dall'Operatore per la verifica.
2. Interfaccia contrattuale
A causa dell'esistenza di tre passaggi, l'interfaccia del contratto dell'account è simile in diverse implementazioni. Queste funzioni del punto di ingresso possono essere richiamate solo dal sistema operativo AA:
ERC-4337: Verifica delle azioni dell'utente
zkSync: verifica transazioni, paga transazioni ed esegui transazioni
StarkNet: esegui、convalida、validate_declare、validate_deploy
In ERC-4337 e AA nativo, la funzione del punto di ingresso nella fase di "verifica" è fissa, mentre nella fase di "esecuzione" è fisso solo il punto di ingresso in AA nativo.
3. Limitazioni delle fasi di verifica
Poiché non esiste alcun limite di costo per la convalida di una transazione (sostanzialmente, convalidare una transazione chiama una funzione di visualizzazione), un utente malintenzionato può eseguire un attacco DoS sul pool di memoria, danneggiando così il bundler (EIP-4337) o l'operatore/sorter (nativo AA).
EIP-4337 definisce quali codici operativi sono vietati e come limitare l'accesso allo spazio di archiviazione. L'era zkSync semplifica l'utilizzo di OpCode:
La logica del contratto può accedere solo al proprio slot di archiviazione. Se l'indirizzo del contratto dell'account è l'indirizzo A, può accedere:
Slot di memoria appartenente all'indirizzo A
Uno slot di memoria appartenente a qualsiasi altro indirizzo A
Slot di archiviazione keccak256 (A || Ad esempio, i saldi patrimoniali nei contratti ERC-20.
La logica del contratto non può accedere alle variabili globali come i numeri di blocco. StarkNet inoltre non consente chiamate di contratti esterni.
4. Limitazioni alle fasi di esecuzione
In zkSync, l'esecuzione delle chiamate di sistema richiede la conferma della presenza di flag di sistema. Ad esempio, l'unico modo per incrementare un nonce è interagire con un NonceHolder, mentre la distribuzione di un contratto richiede l'interazione con un ContractDeployer. I flag di sistema garantiscono che gli sviluppatori di account interagiscano intenzionalmente con i contratti di sistema.
In ERC-4337 e StarkNet non ci sono restrizioni speciali sulla fase di esecuzione.
5. Numeri casuali
In ERC-4337, la progettazione del punto di ingresso nonce distingue tra un valore chiave a 192 bit e un nonce a 64 bit.
In zkSync, il contratto di sistema NonceHolder gestisce il nonce e garantisce un incremento rigoroso, ovvero il nonce viene aumentato di 1.
In StarkNet anche i nonce sono strettamente in aumento, ma non esiste un nonce astratto da gestire con un contratto specifico.
6. Distribuire utilizzando la prima transazione
ERC-4337 Includere il campo initcode nella struttura userOp per distribuire il mittente (contratto dell'account) nel suo primo userOp.
In StarkNet e zkSync, gli utenti devono inviare la prima transazione all'operatore/sequenziatore per implementare il contratto dell'account.
7. Design speciale in zkSync
Se trasferisci ETH direttamente da Ethereum EOA a zkSync, senza implementare un contratto di account personalizzato, riceverai un account predefinito con lo stesso indirizzo. L'account funziona come un EOA di Ethereum ed è anche controllato dalla chiave privata dell'EOA di Ethereum corrispondente.
Questo tipo di account è la versione None anziché la versione1 . Non è possibile chiamare la funzione DefaultAccount perché non distribuisce alcun codice nello spazio del kernel.
La differenza tra 4337 di L1 e 4337 di L2
Esistono due differenze fondamentali nell'implementazione di ERC-4337 su una catena compatibile con EVM: differenze di protocollo e differenze di indirizzo.
1. Differenze contrattuali
Nella progettazione Rollup, L2 deve caricare i dati su L1 per sicurezza e regolamento. Nel contesto di ERC-4337, le tariffe associate a questo processo di caricamento, come le tariffe di sicurezza L1 e le tariffe blob, dovrebbero essere incluse nel gas di pre-convalida. Determinare la tariffa di caricamento appropriata nel gas di pre-convalida rappresenta una sfida significativa.
2. Affrontare le differenze
La codifica dell'indirizzo nella funzione di creazione di zkSync ERA differisce dai rollup Ethereum e OP. Inoltre, StarkNet utilizza una funzione hash unica per i calcoli degli indirizzi. Nel contesto di ERC-4337 sulle catene compatibili con EVM, generalmente presupponiamo che i calcoli degli indirizzi siano coerenti tra le catene. Tuttavia, esiste un sottile dettaglio che potrebbe far sì che gli indirizzi dei contratti degli account differiscano tra Ethereum e l'implementazione ERC-4337 in L2.
La questione chiave è l’aggiunta di nuovi codici operativi nell’hard fork. Ad esempio, se la catena L2 non supporta l'hard fork Shanghai e la versione EVM non è specificata in fase di compilazione, l'introduzione di push0 causerà la modifica del bytecode, anche se il codice Solidity è lo stesso.
Conclusione
Ecco alcune risorse per saperne di più sull'astrazione dell'account. Non esitate a contattarmi e se avete domande potete trovarmi su Twitter (@murmurlu).
"Introduzione all'astrazione dell'account azteco", consulta:
https://medium.com/@ChiHaoLu/introduction-of-aztec-account-abstraction-98535c9edf2e
"Introduzione all'estratto dell'account StarkNet", consultare:
https://medium.com/taipei-ethereum-meetup/introduction-of-starknet-account-abstraction-2c343b561d6e
"Introduzione all'astrazione dell'account zkSync", controlla:
https://medium.com/taipei-ethereum-meetup/zksync-%E4%B8%AD%E7%9A%84%E5%8E%9F%E7%94%9F-account-abstraction-%E4%BB% 8B%E7%B4%B9-bc7269f8893a
"Starknet e zkSync: un'analisi comparativa", consulta:
https://medium.com/nethermind-eth/starknet-and-zksync-a-comparative-analysis-d4648786256b
