EIP-3074 è diventato l'argomento più caldo da un giorno all'altro, poiché è stato autorizzato a essere incluso nel prossimo hard fork di Ethereum (Pectra/Petra). Tuttavia, di cosa si tratta e che impatto avrà su Ethereum e sull’ecosistema EVM? In questo articolo esploreremo questa proposta, risponderemo alle domande più frequenti e dissiperemo alcuni miti e malintesi. Immergiamoci, ok?
Panoramica sull'astrazione dei conti EIP/ERC
Per rafforzare la tua comprensione dell'astrazione dell'account, devi sapere che il 99% delle volte, quando qualcuno dice "astrazione dell'account", intende "account (contratto) intelligenti", ovvero quando l'account è basato sul codice contratto anziché su un codice contratto. unica chiave privata. Può comunque essere autenticato da una singola chiave privata, come avviene la maggior parte delle volte (questo sarà importante in seguito), ma può anche essere un portafoglio multi-firma, come nel caso di Safe.
Il significato originale di "astrazione dell'account" era "consentire ai contratti intelligenti di avviare transazioni", ma da allora è cambiato in "tutte le funzionalità abilitate dagli account dei contratti intelligenti".
Gli account con contratto intelligente abilitano queste funzionalità e altro ancora
Astrazione del gas: dApp che sponsorizzano il gas, l'utente paga il gas in diversi token ERC20 o addirittura il pagamento anticipato del gas, il che è ottimo per l'onboarding cross-chain.
Questo è eccellente per la privacy e OpSec perché elimina il doxxing chiedendo agli amici di finanziare il tuo account con ETH MATIC, qualunque sia la valuta nativa della catena/rollup o, peggio, ritirandosi dagli scambi.
Batch di transazioni: ovvero raggruppare più azioni in un'unica transazione. Questo è fantastico sia per la sicurezza che per l’efficienza del gas.
Sicurezza: risoluzione delle approvazioni ERC-20. Come effetto collaterale del batching, possiamo approvare un importo esatto insieme a ciascuna azione che ne richiede una, eliminando così il problema dell'approvazione. Perché? Perché non abbiamo bisogno di approvazioni infinite/rimanenti e non abbiamo bisogno di una seconda firma per l'approvazione.
Crittografia personalizzata: abilitazione di nuove curve crittografiche, WebAuthn, enclave sicura iOS, sicurezza quantistica e altro ancora.
Rotazione delle chiavi e ripristino dell'account: modifica delle chiavi private per un account esistente o recupero di un account tramite schemi come il recupero sociale di Argent
Noti qualcosa? Tutti questi aiutano la sicurezza in qualche modo.
Torniamo agli ERC.
In generale, tutti gli ERC relativi all'astrazione dell'account rivendicano tali caratteristiche come motivazione, ma non necessariamente le forniscono; aiutano semplicemente a spianare la strada per rendere queste funzionalità mainstream.
Analizziamolo. I grandi ERC risolvono problemi distinti:
Avvio della transazione: la capacità dei contratti di avviare transazioni.
Nativo: tipo di transazione speciale nel protocollo che può avere origine da un contratto intelligente. Include ERC-2938, successivamente sostituito da RIP-7560
Emulato: ERC-4337 è "emulato" nel senso che le transazioni vengono effettivamente ancora avviate da un EOA. Ciò non significa che l'utente debba essere a conoscenza di questo EOA. Questo EOA è controllato e gestito dal bundler.
Conversione degli utenti esistenti: è qui che entra in gioco l'EIP-3074 (e il suo aiutante più piccolo, ERC-5003)
EIP-3074 consente di delegare il controllo di un EOA ESISTENTE a un contratto intelligente. Il contratto intelligente può controllare questo EOA ed effettuare chiamate dal suo indirizzo, ma non può avviare transazioni. Questo è importante perché dobbiamo ancora risolvere il problema dell’avvio della transazione.
L'ERC-5003 consente di convertire "completamente" un EOA in un conto smart contract, grazie alla revoca della chiave privata originale che agisce come una chiave principale per questo EOA.
Firme: i contratti normalmente non possono firmare firme. Ma in un certo senso possono – possono definire la logica che definisce quale sia una firma valida per quel contratto. Ad esempio, un portafoglio smart contract che è un multisig tra Bob e Alice definirà una firma valida come isValidSignature = isValid(bobsSignature) AND isValid(alicesSignature). Questo deve essere definito nel codice del contratto.
ERC-1271 definisce un'interfaccia per far sì che ciò accada.
ERC-6492 lo estende per supportare account smart contract non ancora distribuiti: ciò consente lo stesso indirizzo su tutte le catene senza soluzione di continuità, consentendo comunque all'utente di firmare messaggi.
Entrambi devono essere implementati dalle dApp per funzionare.
Per creare davvero un'esperienza AA, devi risolvere tutto quanto sopra contemporaneamente. Questo è il motivo per cui EIP-3074 non compete con ERC-4337, RIP-7560 o qualsiasi altro ERC di astrazione di account.
Se vuoi vedere tutto questo visivamente, ti suggeriamo questa diapositiva da un discorso sulla demistificazione degli ERC AA.
FUD comune EIP-3074 sfatato i miti
Cominciamo con l'elefante nella stanza. Ci sono stati tre pezzi di FUD relativi a EIP-3074:
Consente alle dApp dannose di svuotare i portafogli esistenti in una transazione: è vero che tale firma può essere prodotta, ma non c'è motivo o caso d'uso per cui un fornitore di portafogli possa mai consentire alle dApp di farti firmare tali richieste. Garantirlo dal lato del portafoglio è molto più semplice che proteggere la chiave privata stessa e la divulgazione di una chiave privata ha lo stesso effetto.
L'account conserva un'unica chiave principale (la chiave EOA originale). Esiste un ERC aggiuntivo che risolve questo problema, EIP-5003, altrimenti noto come AUTHUSURP, che consente la revoca della chiave privata originale
EIP-3074 è un cerotto che non offre i vantaggi dell'AA nativo: EIP-3074 non è mai stato concepito per competere con le attuali proposte AA come RIP-7560. Non è un cerotto per AA; è un percorso di migrazione. Abbiamo ancora bisogno dell'AA nativo perché, come ricordiamo in precedenza, non risolve il problema dell'avvio della transazione.
Pro e contro dell'EIP-3074
Pro: crea un percorso di migrazione molto semplice per gli utenti esistenti di MetaMask, Trezor, Ledger, ecc., per sperimentare le funzionalità di astrazione dell'account sui propri account esistenti.
Contro: Sacrifica la rotazione della chiave. Sebbene tutte le funzionalità AA menzionate sopra possano essere abilitate, la rotazione della chiave diventa leggermente sfuggente perché la chiave privata originale mantiene il controllo sull'account su tutte le reti che non sono mai state utilizzate, anche con EIP-5003.
Esercizio mentale
Ecco un esercizio mentale che ti aiuterà a comprendere i pezzi in movimento:
Esiste un EOA, аlice.eth (0x696969..69), sulla rete principale di Ethereum. Questo EOA è cross-chain per definizione, quindi esiste anche su tutti i rollup e le catene EVM.
Questo EOA è controllato esclusivamente da una chiave privata A, di proprietà di Alice.
EIP-3074 diventa attivo.
Una dApp dannosa tenta di attaccare Alice e le chiede di firmare una firma AUTH EIP-3074, autorizzando un contratto dannoso. Il portafoglio ignora questa richiesta e disconnette la dApp perché è ben implementata e non esiste un caso d'uso che lo consenta sempre da una dApp.
Alice fa clic su un pulsante "abilita l'astrazione dell'account" sul proprio fornitore di portafoglio (ad esempio MetaMask, tramite Snap o Ambire, in modo nativo). Il portafoglio firma una firma AUTH EIP-3074, che autorizza un contratto creato dal fornitore del portafoglio che aiuta a eseguire batching, sponsorizzazione del gas, ecc.
Questo contratto è controllato esclusivamente tramite la chiave privata A.
alice.eth è ora controllato separatamente da due entità: la chiave privata A (in modalità EOA) e il nuovo contratto, anch'esso controllato esclusivamente dalla chiave privata A.
Alice ora può eseguire il batching, ma per sponsorizzare il gas, il fornitore del portafoglio di Alice deve implementare ERC-4337 o RIP-7560 (se la rete lo supporta) o un relè proprietario in modo che Alice non debba utilizzare il suo ETH ( che è un requisito fondamentale della rete se si desidera avviare una transazione).
Alice decide di convertire alice.eth in un multisig e il fornitore del portafoglio ordina al contratto di revocare la chiave privata A e autorizzare 2/2 multi-sig di chiavi private BMobilePhone e BLaptop.
Tuttavia, questo non funziona perché la chiave privata A controlla ancora Alice.eth: secondo EIP-3074, la chiave privata originale mantiene il controllo nonostante sia delegata a un contratto.
EIP-5003 diventa attivo su Ethereum e consente ad alice.eth di inviare un'istruzione speciale alla rete tramite il fornitore del suo portafoglio per revocare il controllo della chiave privata A.
alice.eth è ora convertito con successo in multi-sig, ma solo su Ethereum. La chiave privata A (di proprietà di Alice) mantiene ancora il controllo su alice.eth su tutte le altre reti.
Alla fine, abbiamo imparato alcune cose:
Abbiamo fatto qualcosa di straordinario perché, senza EIP-3074, Alice probabilmente non avrebbe mai adottato l'astrazione dell'account.
EIP-3074 non risolve tutto; abbiamo ancora bisogno di ERC-4337 e RIP-7560 tanto quanto ci serviva ieri.
L'EIP-3074 non funziona bene con la rotazione della chiave, anche se abbiamo l'EIP-5003. Questo è il motivo per cui abbiamo ancora bisogno di account intelligenti effettivi per facilitare casi d’uso come multi-firma e rotazione delle chiavi.
Come nota a margine, crediamo che la rotazione delle chiavi sia troppo nuova per la maggior parte e un po' contorta in un mondo a catene incrociate in cui non si ha lo stesso stato tra tutti i rollup e le catene. La maggior parte degli utenti sembra attenersi al paradigma “una chiave = un account”, in particolare con i portafogli hardware, che sono sufficientemente sicuri per la maggior parte dei casi d’uso.
FAQ
Il resto di questo articolo sarà in formato FAQ in modo da poter rispondere meglio ad alcune delle domande più comuni che le persone hanno.
Aiuta MetaMask ad andare avanti?
Riteniamo che le società di astrazione dell'account otterranno un valore molto maggiore da una UX più semplice di onboarding rispetto a quanto otterranno gli operatori storici dalla capacità di offrire funzionalità AA al loro pubblico esistente.
In altre parole, "scatena" il potere dei portafogli AA sull'intero mercato indirizzabile, non solo sui primi utilizzatori disposti a spostare i propri fondi verso un nuovo indirizzo.
Grazie a MetaMask Snaps, molte aziende AA si impegneranno a costruire AA su MetaMask, che è il posizionamento del cervello galattico che nessuno, tranne gli osservatori più astuti, aveva previsto.
Il batching stesso è pericoloso?
Assolutamente no. Vedi ancora cosa stai firmando. Questo, combinato con la simulazione delle transazioni, significa che firmare più azioni è altrettanto sicuro, e nella maggior parte dei casi pratici, più sicuro che firmare una singola azione.
Il raggruppamento delle transazioni è una delle funzionalità più apprezzate di Account Abstraction
Questo aiuta le dApp ad adottare AA? Risolve i problemi di compatibilità?
Le dApp funzionano con qualsiasi forma di astrazione dell'account con alcune eccezioni:
Alcune dApp discriminano gli account (contratti) intelligenti
Alcune dApp non supportano ERC-1271
EIP-3074 risolve magicamente entrambi i problemi: gli account appaiono come EOA (non hanno codice), quindi non possono essere discriminati. Per quanto riguarda le firme, gli EOA abilitati ad AA (tramite 3074) continueranno a firmare come EOA, quindi non ci sono problemi. Funzionerà magicamente con tutte le dApp a scapito della perdita della rotazione delle chiavi.
Tuttavia, se la maggior parte delle persone sceglie EOA abilitati per AA rispetto ad account puramente intelligenti, ciò disincentiva le dApp dal supportare ERC-1271 ed ERC-6492, ma ERC-4337 ha già contribuito ad aumentare la consapevolezza per le proposte di firma.
Che ne dici di revocare la chiave originale?
Puoi revocare la chiave tramite EIP-5003 (che non è ancora pianificato nell'hard fork).
Una sfumatura è che questa non è una soluzione perfetta in un mondo a catena incrociata. L'EOA inizierà sempre come EOA su ogni nuova catena che inizi a utilizzare, il che significa che la chiave originale non potrà mai essere veramente revocata. Ma questo vale per ogni forma di AA perché le autorizzazioni/privilegi originali con cui hai creato l'account sono sempre quelli con cui inizia l'account su qualsiasi nuova rete.
EIP-3074 funziona meglio portando tutte le funzionalità AA tranne la rotazione delle chiavi agli EOA esistenti. In altre parole, se scegli di abilitare AA per un EOA, rimarrai per sempre bloccato con la chiave privata originale dietro questo EOA.
Uccide l'AA nativo (RIP-7560)?
No, perché hai comunque bisogno di una soluzione per avviare la transazione, almeno se vuoi pagare il gas con un token diverso da quello nativo (o hai bisogno di una sponsorizzazione del gas).
ERC-4337 è una di queste soluzioni che non richiede aggiornamenti del protocollo (non è nativa), ma l'AA nativo, sancito dal protocollo, è immensamente prezioso, poiché risolve il sovraccarico di gas e la complessità di ERC-4337.
Ma sì, che mi dici dell'EIP-7377
EIP-7377 consente di convertire un EOA in un account intelligente. Invece di consentire a un contratto intelligente di controllare l’EOA insieme al PK originale, questo EIP consente a un contratto di assumere il controllo dell’EOA in un’unica transazione.
Può essere considerato un'alternativa all'EIP-3074 + EIP-5003, ma non ha guadagnato lo stesso slancio.
Pensieri conclusivi
EIP-3074 non è un cerotto. È estremamente rialzista per il futuro di Ethereum e dell'ecosistema EVM perché chiedere agli utenti di abbandonare improvvisamente i loro conti esistenti e trasferire tutti i loro fondi, posizioni di staking, ecc. su un nuovo conto (conto contratto intelligente) aumenta significativamente la barriera all'ingresso.
EIP-3074 fornirà una nuova via di mezzo e un onboarding graduale, che è esattamente ciò di cui abbiamo bisogno per migliorare notevolmente la UX.
Interessato ad Ambire? Seguici:
Discordia | X (Twitter) | Reddit | GitHub | Telegramma | Facebook
