Autore originale: Vitalik Buterin Traduzione originale: Nian Yin Si Tang, Odaily
Fin dall'inizio del progetto Ethereum, c'è stata una forte filosofia di cercare di rendere il nucleo di Ethereum il più semplice possibile e di raggiungere questo obiettivo il più possibile costruendo protocolli sopra di esso. Nello spazio blockchain, il dibattito "build on L1" vs. "focus on L2" è spesso pensato principalmente come una questione di scalabilità, ma in realtà ci sono problemi simili nel soddisfare le esigenze di più utenti Ethereum: scambio di risorse digitali, privacy , nomi utente, crittografia avanzata, sicurezza dell'account, resistenza alla censura, protezione avanzata e altro ancora. Tuttavia, ci sono stati alcuni cauti tentativi recenti di incorporare più di queste funzionalità nel protocollo principale di Ethereum.
Questo articolo approfondirà alcuni dei ragionamenti filosofici alla base della filosofia originale dell'incapsulamento minimo, nonché alcuni modi recenti di pensare a queste idee. L'obiettivo sarà quello di iniziare a costruire un quadro per identificare meglio i possibili obiettivi in cui potrebbe valere la pena considerare l'incapsulamento di determinate funzionalità.
Una delle prime filosofie sul minimalismo del protocollo
Agli albori della storia di quello che allora era conosciuto come "Ethereum 2.0", c'era un forte desiderio di creare un protocollo pulito, semplice e bello che tentasse il meno possibile di costruirsi su se stesso e lasciasse quasi tutto il lavoro agli utenti. Idealmente, il protocollo è semplicemente una macchina virtuale e la convalida di un blocco è semplicemente una chiamata alla macchina virtuale.
La "funzione di transizione di stato" (la funzione che gestisce il blocco) sarà solo una singola chiamata VM e tutta l'altra logica avverrà tramite contratti: alcuni contratti a livello di sistema, ma soprattutto contratti forniti dall'utente. Una caratteristica molto interessante di questo modello è che anche un intero hard fork può essere descritto come una singola transazione per il contratto del processore a blocchi, che sarà approvato dalla governance off-chain o on-chain e quindi aggiornato il permesso di esecuzione.
Queste discussioni nel 2015 si applicano specificamente a due aree che consideriamo: astrazione dell’account e ridimensionamento. Nel caso del ridimensionamento, l'idea è provare a creare una forma astratta massima di ridimensionamento che sembri un'estensione naturale del diagramma sopra. I contratti possono chiamare dati che non sono archiviati dalla maggior parte dei nodi Ethereum e il protocollo lo rileverà e risolverà la chiamata tramite alcune funzionalità di calcolo estese molto generali. Dal punto di vista della macchina virtuale, la chiamata entrerà in un sottosistema separato e poi magicamente restituirà la risposta corretta qualche tempo dopo.
Abbiamo esplorato brevemente questa idea, ma l’abbiamo rapidamente abbandonata perché eravamo troppo concentrati nel dimostrare che qualsiasi tipo di scalabilità della blockchain fosse possibile. Tuttavia, come vedremo più avanti, la combinazione del campionamento della disponibilità dei dati e di ZK-EVM significa che un possibile futuro per la scalabilità di Ethereum sembra in realtà molto vicino a questa visione! Con l'astrazione dell'account, invece, sapevamo fin dall'inizio che un qualche tipo di implementazione era possibile, quindi la ricerca è subito iniziata cercando di rendere qualcosa il più vicino possibile al puro punto di partenza di "una transazione è solo una chiamata" diventare una realtà.
C'è molto codice boilerplate tra l'elaborazione della transazione e l'esecuzione dell'effettiva chiamata EVM sottostante dall'indirizzo del mittente, e successivamente altro codice boilerplate. Come possiamo ridurre questo codice il più vicino possibile allo zero?
Uno dei pezzi di codice principali qui è validate_transaction(state, tx), che è responsabile di verificare se il nonce e la firma della transazione sono corretti. Fin dall'inizio, l'obiettivo effettivo dell'astrazione dell'account è stato quello di consentire agli utenti di sostituire la verifica di base non incrementale e la verifica ECDSA con la propria logica di verifica, in modo che gli utenti possano utilizzare più facilmente funzionalità come il recupero sociale e i portafogli multi-firma. Quindi trovare un modo per ristrutturare apply_transaction in una semplice chiamata EVM non era solo un'attività di "rendere il codice pulito per il gusto di renderlo pulito", si trattava invece di spostare la logica nel codice dell'account dell'utente, offrendo agli utenti la flessibilità che hanno Bisogno.
Tuttavia, insistere sul fatto che apply_transaction contenga la minima logica fissa possibile ha finito per creare molte sfide. Possiamo esaminare una delle prime proposte di astrazione dell'account, EIP-86.
Se l'EIP-86 fosse incluso così com'è, ridurrebbe la complessità dell'EVM al prezzo di aumentare enormemente la complessità di altre parti dello stack Ethereum, richiedendo la scrittura essenzialmente dello stesso codice altrove, oltre all'introduzione di una classe completamente nuova di stranezza. Ad esempio, la stessa transazione con lo stesso valore hash può apparire più volte nella catena, per non parlare del problema dell'invalidazione multipla.
Molteplici problemi di invalidazione nell'astrazione dell'account. Una transazione inclusa nella catena potrebbe invalidare migliaia di altre transazioni nel mempool, rendendo facile il riempimento del mempool a buon mercato.
Da allora, l’astrazione del conto si è evoluta gradualmente. L'EIP-86 in seguito divenne EIP-208 e infine emerse il pratico EIP-2938.
Tuttavia, l’EIP-2938 è tutt’altro che minimalista. I suoi contenuti includono:
· Nuovi tipi di transazione
· Tre nuove variabili globali dell'ambito della transazione
· Due nuovi codici operativi, incluso il codice operativo PAYgas molto goffo per gestire il prezzo del gas e i controlli sui limiti del gas, come punti di interruzione dell'esecuzione dell'EVM e per archiviare temporaneamente ETH per commissioni di pagamento una tantum
· Un insieme complesso di strategie di mining e ritrasmissione, incluso un elenco di codici operativi vietati durante la fase di verifica della transazione
Per ottenere l'astrazione degli account senza coinvolgere gli sviluppatori principali di Ethereum (focalizzati sull'ottimizzazione dei client Ethereum e sull'implementazione delle fusioni), EIP-2938 è stato infine riprogettato come ERC-4337, che è completamente fuori protocollo.
Poiché si tratta di un ERC, non richiede un hard fork e tecnicamente esiste "al di fuori del protocollo Ethereum". Quindi...problema risolto? Si scopre che non è così. L’attuale tabella di marcia a medio termine di ERC-4337 prevede in realtà la transizione di gran parte di ERC-4337 in una serie di funzionalità del protocollo, il che è un utile esempio guida del motivo per cui questo percorso dovrebbe essere considerato.
Pacchetto ERC-4337
Ci sono diverse ragioni chiave discusse per l’eventuale reincorporazione di ERC-4337 nel protocollo:
Efficienza del gas: qualsiasi operazione eseguita all'interno dell'EVM comporta un certo livello di sovraccarico della macchina virtuale, comprese inefficienze quando si utilizzano funzionalità costose in termini di gas come gli slot di archiviazione. Attualmente, queste ulteriori inefficienze ammontano ad almeno 20.000 gas, se non di più. Inserire questi componenti nel protocollo è il modo più semplice per eliminare questi problemi.
Rischio di bug del codice: se il "contratto del punto di ingresso" ERC-4337 presenta un bug abbastanza terribile, tutti i portafogli compatibili con ERC-4337 potrebbero vedere tutti i loro fondi prosciugarsi. La sostituzione dei contratti con funzionalità interne al protocollo crea l'obbligo implicito di correggere i bug del codice tramite hard fork, eliminando così il rischio che gli utenti rimangano senza fondi.
Supporta codici operativi EVM come txt.origin. Lo stesso ERC-4337 fa sì che txt.origin restituisca l'indirizzo di un "bundler" che racchiude una serie di azioni dell'utente in una transazione. L'astrazione dell'account nativo risolve questo problema facendo in modo che txt.origin punti all'account effettivo che invia la transazione, facendolo comportare come EOA.
Resistenza alla censura: una delle sfide legate alla separazione proponente/costruttore è che diventa più semplice rivedere le singole transazioni. In un mondo in cui il protocollo Ethereum può identificare le singole transazioni, questo problema può essere notevolmente alleviato dalle liste di inclusione, che consentono ai proponenti di specificare un elenco di transazioni che devono essere incluse nei due slot successivi in quasi tutti i casi. Tuttavia, ERC-4337 al di fuori del protocollo incapsula le "operazioni dell'utente" in un'unica transazione, rendendo le operazioni dell'utente opache al protocollo Ethereum, pertanto l'elenco di inclusione fornito dal protocollo Ethereum non sarà in grado di fornire resistenza alla censura all'utente ERC-4337; operazioni. Incapsulare ERC-4337 e rendere le operazioni dell'utente un tipo di transazione "corretto" risolverà questo problema.
Vale la pena ricordare che nella sua forma attuale, ERC-4337 è significativamente più costoso delle transazioni Ethereum “di base”: una transazione costa 21.000 gas, mentre ERC-4337 costa circa 42.000 gas.
In teoria, dovrebbe essere possibile regolare il sistema di costo del gas EVM fino a quando il costo nel protocollo e il costo di accesso allo stoccaggio al di fuori del protocollo non coincidono; non vi è motivo di dover spendere 9.000 gas per trasferire ETH quando altri tipi di modifica dello stoccaggio le operazioni sono più economiche. In effetti, due EIP relativi all’imminente trasformazione dell’albero di Verkle tentano effettivamente di fare proprio questo. Ma anche se lo facciamo, c’è una ragione ovvia per cui, non importa quanto efficiente diventi l’EVM, le funzioni del protocollo incapsulato saranno inevitabilmente molto più economiche del codice EVM: il codice incapsulato non ha bisogno di pagare gas per il precaricamento.
Un portafoglio ERC-4337 completamente funzionante è grande, con questa implementazione compilata e messa in catena che occupa circa 12.800 byte. Naturalmente, potresti distribuire questo codice una volta e utilizzare DELEGATECALL per consentire a ogni singolo portafoglio di chiamarlo, ma dovresti comunque accedere al codice in ogni blocco in cui viene utilizzato. Secondo l'EIP sui costi del gas dell'albero Verkle, 12.800 byte formeranno 413 blocchi e l'accesso a questi blocchi richiederà il pagamento di 2 volte il testimone branch_cost (totale 3.800 gas) e 413 volte il testimone Chunk_cost (totale 82.600 gas). Per non parlare del punto di ingresso ERC-4337 stesso, che nella versione 0.6.0 ha 23.689 byte sulla catena (circa 158.700 gas da caricare secondo le regole EIP di Verkle tree).
Ciò porta a un problema: il costo del gas per accedere effettivamente a questi codici deve essere ammortizzato in qualche modo attraverso le transazioni. L'approccio attuale utilizzato da ERC-4337 non è molto buono: la prima transazione nel pacchetto consuma un costo una tantum di archiviazione/lettura del codice, rendendola molto più costosa rispetto ad altre transazioni. L’incapsulamento intra-protocollo consentirà a queste librerie pubbliche condivise di diventare parte del protocollo e di essere liberamente accessibili a tutti.
Cosa possiamo imparare da questo esempio e quando l’incapsulamento dovrebbe essere praticato più in generale?
In questo esempio vediamo alcune motivazioni diverse per incapsulare le astrazioni degli account nei protocolli.
Gli approcci basati sul mercato che “spingono la complessità al limite” hanno maggiori probabilità di fallire quando i costi fissi sono elevati. In effetti, la tabella di marcia per l’astrazione dei conti a lungo termine sembra avere molti costi fissi per blocco. 244.100 gas per caricare il codice del portafoglio standardizzato sono una cosa; ma l'aggregazione può aggiungere centinaia di migliaia di gas per la verifica ZK-SNARK, oltre al costo on-chain della verifica delle prove. Non c’è modo di addebitare agli utenti questi costi senza introdurre enormi inefficienze nel mercato, e trasformare alcune di queste funzionalità in funzionalità di protocollo liberamente accessibili a tutti risolverebbe molto bene questo problema.
Risposta a livello comunitario ai bug del codice. Se una parte di codice viene utilizzata da tutti gli utenti, o da una gamma molto ampia di utenti, spesso ha più senso che la comunità blockchain si assuma la responsabilità di un hard fork per correggere eventuali bug che si presentano. ERC-4337 introduce una grande quantità di codice condiviso a livello globale. Nel lungo periodo, è senza dubbio più ragionevole correggere gli errori nel codice tramite hard fork piuttosto che causare agli utenti la perdita di una grande quantità di ETH.
A volte è possibile implementare una forma più potente del protocollo sfruttando direttamente la sua funzionalità. L'esempio chiave qui sono le funzionalità resistenti alla censura all'interno del protocollo, come gli elenchi di inclusione: gli elenchi di inclusione interni al protocollo possono garantire una resistenza alla censura migliore rispetto ai metodi esterni al protocollo affinché le operazioni a livello di utente traggano realmente vantaggio dall'interno del protocollo includere elenchi, singoli utenti Le operazioni di livello richiedono che il protocollo sia "leggibile". Un altro esempio meno noto è che il progetto proof-of-stake di Ethereum del 2017 prevedeva l'astrazione dell'account delle chiavi di stake, che è stata abbandonata a favore del BLS incapsulato perché BLS supportava un meccanismo di "aggregazione" che doveva essere implementato nel protocollo e livelli di rete, ciò può rendere più efficiente l'elaborazione di un gran numero di firme.
Ma è importante ricordare che anche incapsulare le astrazioni degli account all’interno dei protocolli rappresenta comunque un enorme “de-incapsulamento” rispetto allo status quo. Oggi, le transazioni Ethereum di primo livello possono essere avviate solo da conti di proprietà esterna (EOA), che vengono verificati utilizzando una singola firma a curva ellittica da 256 k 1 secp. L'astrazione dell'account elimina questo problema e lascia che le condizioni di convalida siano definite dall'utente. Pertanto, in questa storia sull’astrazione dell’account, vediamo anche il motivo principale contro l’incapsulamento: la flessibilità per soddisfare le esigenze di diversi utenti.
Approfondiamo ulteriormente la storia esaminando alcuni altri esempi di funzionalità recentemente prese in considerazione per l'incapsulamento. Presteremo particolare attenzione a: ZK-EVM, separazione proponente-costruttore, pool di memoria privati, staking di liquidità e nuova precompilazione.
Pacchetto ZK-EVM
Rivolgiamo la nostra attenzione a un altro potenziale obiettivo di incapsulamento per il protocollo Ethereum: ZK-EVM. Attualmente, disponiamo di un gran numero di ZK-rollup che devono tutti scrivere codice abbastanza simile per verificare l'esecuzione di blocchi Ethereum simili in ZK-SNARK. Esiste un ecosistema abbastanza diversificato di implementazioni indipendenti: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth e altri.
Una recente controversia nel campo EVM ZK-rollup è legata a come gestire i bug che potrebbero apparire nel codice ZK. Attualmente, tutti questi sistemi in esecuzione dispongono di una qualche forma di meccanismo di "consiglio di sicurezza" che controlla il sistema di attestazione in caso di bug. L’anno scorso ho cercato di creare un quadro standardizzato che incoraggiasse i progetti a chiarire quanto si fidano del sistema di attestazione e quanto si fidano del Consiglio di Sicurezza, e a ridurre gradualmente nel tempo la loro autorità su tale organizzazione.
Nel medio termine, il rollup potrà basarsi su più sistemi di certificazione, e il Consiglio di Sicurezza avrà potere solo nei casi estremi in cui due diversi sistemi di certificazione divergono.
Tuttavia, c’è la sensazione che parte di questo lavoro sembri ridondante. Abbiamo già il livello base di Ethereum, ha un EVM e abbiamo già un meccanismo funzionante per la gestione dei bug nell'implementazione: se c'è un bug, il client si aggiornerà per risolverlo e la catena continuerà a funzionare. Dal punto di vista del client difettoso, sembra che i blocchi finalizzati non verranno più confermati, ma almeno non vedremo gli utenti perdere fondi. Allo stesso modo, se i rollup vogliono semplicemente rimanere equivalenti a EVM, allora devono implementare la propria governance per modificare costantemente le regole ZK-EVM interne per abbinare gli aggiornamenti al livello base di Ethereum, il che sembra sbagliato perché alla fine sono costruiti sopra il livello base di Ethereum. Lo stesso livello di base di Ethereum sa quando aggiornare e in base a quali nuove regole.
Dato che questi ZK-EVM L2 utilizzano fondamentalmente lo stesso identico EVM di Ethereum, possiamo in qualche modo incorporare "verifica l'esecuzione EVM in ZK" nella funzionalità del protocollo e gestire le eccezioni applicando il consenso sociale di Ethereum, come bug e aggiornamenti, come già facciamo per il esecuzione EVM del livello base stessa?
Questo è un argomento importante e stimolante.
Un possibile argomento di dibattito riguardante la disponibilità dei dati in ZK-EVM nativo è lo stato. Gli ZK-EVM sarebbero molto più efficienti in termini di dati se non avessero bisogno di trasportare dati "testimone". Cioè, se un particolare dato è stato letto o scritto in qualche blocco precedente, possiamo semplicemente supporre che il prover abbia accesso ad esso e non debba renderlo nuovamente disponibile. Non si tratta solo di non ricaricare spazio di archiviazione e codice; si scopre che se un rollup comprime correttamente i dati, la compressione con stato può salvare fino a 3 volte i dati rispetto alla compressione senza stato.
Ciò significa che per la precompilazione ZK-EVM abbiamo due opzioni:
1. La precompilazione richiede che tutti i dati siano disponibili nello stesso blocco. Ciò significa che il prover può essere senza stato, ma significa anche che l'utilizzo di questo rollup ZK precompilato è molto più costoso rispetto all'utilizzo di un rollup di codice personalizzato.
2. La precompilazione consente ai puntatori di puntare ai dati utilizzati o generati dalle esecuzioni precedenti. Ciò rende ZK-rollup vicino all'ottimale, ma è più complesso e introduce un nuovo stato che deve essere memorizzato dal prover.
Cosa possiamo imparare da questo? C'è una buona ragione per incapsulare la verifica ZK-EVM in qualche modo: rollup sta già costruendo la propria versione personalizzata, ed Ethereum è disposto a ponderare le sue molteplici implementazioni e il consenso sociale off-chain per eseguire EVM su L1, questo sembra sbagliato, ma L2, facendo lo stesso identico lavoro, dovrebbe implementare un gadget complesso che coinvolga il Consiglio di Sicurezza. Ma d'altra parte c'è un grosso problema nei dettagli: esistono diverse versioni di ZK-EVM, con costi e benefici diversi. La distinzione tra stateful e stateless graffia solo la superficie; i tentativi di supportare il codice personalizzato "quasi EVM" che è stato dimostrato da altri sistemi possono esporre uno spazio di progettazione più ampio. Pertanto, il confezionamento di ZK-EVM porta speranza e sfide.
Separazione del proponente e del costruttore dell'incapsulamento (ePBS)
L’ascesa del MEV rende la produzione di blocchi un’attività economica su larga scala, con attori sofisticati in grado di produrre blocchi che generano più entrate rispetto all’algoritmo predefinito, che semplicemente osserva un mempool di transazioni e le contiene. Finora, la comunità di Ethereum ha cercato di risolvere questo problema utilizzando schemi di separazione proponente-costruttore esterni al protocollo come MEV-Boost, che consente ai validatori regolari ("propositori") di inviare blocchi alla costruzione è affidata ad attori specializzati ("Costruttori ").
Tuttavia, MEV-Boost presuppone la fiducia in una nuova classe di attori chiamati relè. Negli ultimi due anni molte persone hanno proposto di creare un "PBS incapsulato". Quali sono i vantaggi di farlo? In questo caso, la risposta è molto semplice: una PBS costruita utilizzando direttamente le funzionalità del protocollo è più potente (nel senso di avere presupposti di fiducia più deboli) di una PBS costruita senza utilizzarle. Questo è simile al caso in cui si incapsulano gli oracoli dei prezzi all’interno di un protocollo – anche se in questo caso ci sono forti obiezioni.
Incapsula il pool di memoria privato
Quando un utente invia una transazione, questa è immediatamente pubblica e visibile a tutti, ancor prima di essere inserita nella catena. Ciò lascia gli utenti di molte applicazioni vulnerabili agli attacchi economici, come il front-running.
Recentemente, ci sono stati numerosi progetti dedicati alla creazione di “mempool privati” (o “mempool crittografati”), che crittografano le transazioni degli utenti fino a quando non vengono accettate in modo irreversibile in un blocco.
Il problema, tuttavia, è che uno schema del genere richiede un tipo speciale di crittografia: per impedire agli utenti di inondare il sistema e decrittografarlo prima, la crittografia deve essere decrittografata automaticamente dopo che la transazione è stata effettivamente accettata in modo irreversibile.
Esistono varie tecniche con diversi compromessi per implementare questa forma di crittografia. Jon Charbonneau una volta lo descrisse bene:
Crittografa gli operatori centralizzati come Flashbots Protect.
Crittografia con blocco temporale, questa forma di crittografia può essere decrittografata da chiunque dopo determinati passaggi di calcolo sequenziali e non può essere parallelizzata;
La crittografia a soglia si affida a un comitato di maggioranza onesto per decrittografare i dati. Vedi il concetto di catene di beacon chiuse per suggerimenti specifici.
Hardware affidabile come SGX.
Sfortunatamente, ogni metodo di crittografia presenta diversi punti deboli. Sebbene per ciascuna soluzione esista un sottoinsieme di utenti disposti a fidarsi di essa, nessuna soluzione è sufficientemente affidabile da essere effettivamente accettata dal Livello 1. Quindi, almeno fino a quando la crittografia ritardata non sarà perfezionata o qualche altra svolta tecnologica, incapsulare la funzionalità di trading anti-ahead nel Layer 1 sembra essere una proposta difficile, anche se è una caratteristica abbastanza preziosa da far emergere molte soluzioni applicative.
Staking di liquidità incapsulato
Un'esigenza comune tra gli utenti di Ethereum DeFi è la possibilità di utilizzare contemporaneamente i propri ETH per lo staking e come garanzia in altre applicazioni. Un'altra richiesta comune è semplicemente quella di comodità: gli utenti vogliono essere in grado di fare staking (e proteggere le chiavi di staking online) senza la complessità di gestire un nodo e mantenerlo sempre online.
Di gran lunga l'"interfaccia" di staking più semplice che soddisfa entrambe queste esigenze è solo un token ERC 20: converti il tuo ETH in "staking ETH", mantienilo e poi riconvertilo. In effetti, i fornitori di staking di liquidità come Lido e Rocket Pool lo stanno già facendo. Tuttavia, ci sono alcuni meccanismi naturali di centralizzazione in gioco con lo staking di liquidità: le persone scommetteranno naturalmente sulla versione più grande di ETH perché è la più familiare e liquida.
Ogni versione di ETH in staking deve avere un meccanismo per determinare chi può diventare l'operatore del nodo sottostante. Non può essere illimitato perché in tal caso gli aggressori si unirebbero e utilizzerebbero i fondi degli utenti per espandere i propri attacchi. Attualmente, i primi due sono Lido e Rocket Pool, con il primo che ha operatori di nodi inseriti nella whitelist DAO e il secondo che consente a chiunque di gestire un nodo con un deposito di 8 ETH. Questi due metodi comportano rischi diversi: il metodo Rocket Pool consente a un attacker di effettuare un attacco del 51% sulla rete e costringe gli utenti a pagare la maggior parte dei costi, mentre per il metodo DAO, se un certo token messo in staking diventa dominante, avrà la meglio; ad un singolo, un gadget di governance potenzialmente compromesso controlla gran parte di tutti i validatori di Ethereum. A suo merito, protocolli come Lido hanno implementato misure di salvaguardia, ma un livello di difesa potrebbe non essere sufficiente.
Nel breve termine, un’opzione è quella di incoraggiare i partecipanti all’ecosistema a utilizzare una serie diversificata di fornitori di liquidità per ridurre la possibilità che un attore dominante comporti un rischio sistemico. A lungo termine, tuttavia, questo equilibrio diventa instabile e l’eccessivo affidamento alla pressione morale per risolvere i problemi è pericoloso. Sorge spontanea una domanda: avrebbe senso incapsulare alcune funzionalità nel protocollo per rendere lo staking di liquidità meno centralizzato?
La domanda chiave qui è: che tipo di funzionalità nel protocollo? Un problema con la semplice creazione di un token "staking ETH" fungibile all'interno del protocollo è che dovrebbe avere una governance incapsulata a livello di Ethereum per scegliere chi può gestire i nodi, oppure essere a tempo indeterminato, il che lo trasformerebbe in un token dell'attaccante. Utensili.
Un’idea interessante è l’articolo di Dankrad Feist sulla massimizzazione dello staking di liquidità. Prima di tutto, stringiamo i denti se Ethereum è soggetto a un attacco del 51%, solo il 5% dell’ETH attaccato potrebbe essere tagliato. Si tratta di un compromesso ragionevole; con oltre 26 milioni di ETH attualmente in staking, il costo per attaccarne un terzo (~8 milioni di ETH) è eccessivo, soprattutto considerando il numero di attacchi "fuori modello" che possono essere eseguiti contemporaneamente. costo inferiore. In effetti, compromessi simili sono stati esplorati nella proposta del Super Comitato di implementare la definitività del singolo slot.
Se accettiamo che solo il 5% degli ETH di attacco venga tagliato, allora più del 90% degli ETH in staking non saranno interessati dal taglio, quindi potranno essere utilizzati come token di staking liquidi fungibili all'interno del protocollo e quindi utilizzati da altre applicazioni.
Questo percorso è interessante. Ma resta ancora una domanda: cosa viene incapsulato esattamente? Rocket Pool funziona in modo molto simile: ciascun operatore del nodo fornisce alcuni fondi e gli staker di liquidità forniscono il resto. Possiamo semplicemente modificare alcune costanti per limitare la penalità massima di taglio a 2 ETH e il rETH esistente di Rocket Pool diventerà privo di rischi.
Con semplici aggiustamenti del protocollo possiamo fare anche altre cose intelligenti. Ad esempio, supponiamo di volere un sistema con due "livelli" di staking: operatori dei nodi (requisiti collaterali elevati) e depositanti (nessun requisito minimo di garanzia, possono aderire e uscire in qualsiasi momento), ma vogliamo comunque essere in grado di aderire e andarsene in qualsiasi momento conferendo a un comitato di depositanti campionato casualmente i poteri per impedire la centralizzazione degli operatori dei nodi, come raccomandare un elenco di transazioni che devono essere incluse (per ragioni di resistenza alla censura), controllare la selezione dei fork durante le perdite di inattività o richiedere firme sui blocchi . Ciò potrebbe essere ottenuto in un modo che vada essenzialmente fuori protocollo, modificando il protocollo per richiedere a ciascun validatore di fornire (i) una chiave di staking regolare e (ii) un indirizzo ETH che può essere utilizzato in ogni slot viene chiamato per emettere il chiave di pegno secondaria. Il protocollo autorizzerebbe entrambe le chiavi, ma il meccanismo per selezionare la seconda chiave in ogni slot potrebbe essere lasciato al protocollo dello staking pool. Potrebbe essere comunque meglio incapsulare direttamente alcune funzioni, ma vale la pena notare che esiste questo tipo di spazio di progettazione di "includere alcune cose e lasciare altre cose all'utente".
Incapsula più precompilazione
I contratti precompilati (o "contratti precompilati") sono contratti Ethereum che implementano operazioni crittografiche complesse e la loro logica è implementata nativamente nel codice client anziché nel codice del contratto intelligente EVM. La precodifica è un compromesso adottato fin dall'inizio dello sviluppo di Ethereum: poiché il sovraccarico di una macchina virtuale è troppo grande per un codice molto complesso e altamente specializzato, possiamo implementare alcune importanti applicazioni nel codice nativo. Operazioni critiche per renderle più veloci. Oggi, questo include fondamentalmente alcune funzioni hash specifiche e operazioni su curve ellittiche.
Attualmente c'è una spinta per aggiungere la precompilazione per secp 256 r 1 , una curva ellittica leggermente diversa da secp 256 k 1 utilizzata per gli account Ethereum di base, poiché è ben supportata da moduli hardware affidabili e quindi ampiamente utilizzata per aumentare la sicurezza del portafoglio. Negli ultimi anni, la comunità ha anche spinto per aggiungere la precompilazione per BLS-12-377, BW 6-761, abbinamento generalizzato e altre funzionalità.
La controargomentazione a queste richieste di più precompilatori è che molti dei precompilatori aggiunti in precedenza (come RIPEMD e BLAKE) hanno finito per essere utilizzati molto meno del previsto, e dovremmo imparare da questo. Piuttosto che aggiungere ulteriore precompilazione per operazioni specifiche, dovremmo probabilmente concentrarci su un approccio più modesto basato su idee come EVM-MAX e la proposta SIMD Hibernate-But-Always-Resumable, che consentirebbe alle implementazioni EVM di funzionare a costi inferiori. eseguendo un'ampia gamma di classi di codice. Forse anche l’attuale precompilazione poco utilizzata potrebbe essere rimossa e sostituita con un’implementazione del codice EVM (inevitabilmente meno efficiente) delle stesse funzioni. Detto questo, è ancora possibile che esistano operazioni crittografiche specifiche sufficientemente preziose da poter essere velocizzate, quindi ha senso aggiungerle come precompilate.
Cosa abbiamo imparato da tutto questo?
Il desiderio di incapsulare il meno possibile è comprensibile e positivo; deriva dalla tradizione filosofica Unix di creare software minimalista che possa facilmente adattarsi alle diverse esigenze degli utenti ed evitare la maledizione dell'ingrossamento del software. Tuttavia, la blockchain non è un sistema operativo informatico personale, ma un sistema sociale. Ciò significa che ha senso incapsulare determinate funzionalità nel protocollo.
In molti casi, questi altri esempi sono simili a quanto visto nell’astrazione del resoconto. Ma abbiamo anche imparato alcune nuove lezioni:
La funzionalità di incapsulamento può aiutare a evitare i rischi di centralizzazione in altre aree dello stack:
Spesso, mantenere il protocollo di base minimale e semplice spinge la complessità verso qualche ecosistema esterno al protocollo. Dal punto di vista della filosofia Unix, questo va bene. Tuttavia, a volte esiste il rischio che l’ecosistema fuori protocollo diventi centralizzato, solitamente (ma non solo) a causa degli elevati costi fissi. L’incapsulamento a volte può ridurre la centralizzazione di fatto.
Incapsulare troppo potrebbe estendere eccessivamente il peso della fiducia e della governance del protocollo:
Questo è il tema del precedente articolo su "Don't Overload Ethereum Consensus": se incapsulare una caratteristica specifica indebolisce il modello di fiducia e rende Ethereum nel suo insieme più "soggettivo", ciò indebolisce la neutralità credibile di Ethereum. In questi casi, è meglio avere la funzionalità specifica come meccanismo sopra Ethereum piuttosto che cercare di portarla all’interno di Ethereum stesso. I pool di memoria crittografati sono l'esempio migliore in questo caso, che può essere un po' difficile da incapsulare, almeno finché la crittografia della latenza non migliora.
Incapsulare troppo può rendere il protocollo eccessivamente complesso:
La complessità del protocollo è un rischio sistemico che aumenta aggiungendo troppe funzionalità a un protocollo. La precompilazione è l'esempio migliore.
L'incapsulamento delle funzionalità può essere controproducente a lungo termine perché le esigenze degli utenti sono imprevedibili:
Una funzionalità che molte persone ritengono importante e che verrà utilizzata da molti utenti probabilmente non viene utilizzata molto spesso nella pratica.
Inoltre, lo staking di liquidità, lo ZK-EVM e gli esempi precompilati mostrano la possibilità di una via di mezzo: una consacrazione minima praticabile. Non è necessario che il protocollo incapsula l'intera funzionalità, ma può contenere parti specifiche che affrontano le sfide principali, rendendo la funzionalità facile da implementare senza essere troppo paranoici o troppo ristretti. Gli esempi includono:
Piuttosto che incapsulare un sistema completo di staking di liquidità, è meglio modificare le regole delle penalità di staking per rendere più fattibile lo staking di liquidità senza fiducia;
Piuttosto che incapsulare più precompilatori, è meglio incapsulare EVM-MAX e/o SIMD per rendere più semplice l'implementazione efficiente di una classe più ampia di operazioni;
È possibile incapsulare semplicemente la verifica EVM invece di incapsulare l'intero concetto di rollup.
Possiamo estendere lo schema precedente come segue:
A volte ha senso incapsulare qualcosa e la rimozione di precompilatori usati raramente ne è un esempio. Anche l’astrazione dell’account nel suo complesso, come accennato in precedenza, è un’importante forma di de-incapsulamento. Se vogliamo supportare la compatibilità con le versioni precedenti per gli utenti esistenti, il meccanismo potrebbe in realtà essere sorprendentemente simile a quello che ha eliminato la precompilazione: una delle proposte è EIP-5003, che consentirebbe agli EOA di convertire i propri account per avere lo stesso (o meglio) contratto funzionale.
Quali caratteristiche dovrebbero essere introdotte nel protocollo e quali dovrebbero essere lasciate ad altri strati dell’ecosistema è un compromesso complesso. Si prevede che questo compromesso continuerà a migliorare nel tempo man mano che la nostra comprensione delle esigenze degli utenti e la gamma di idee e tecnologie disponibili continuano a migliorare.