Domanda di approfondimento: Ethereum dovrebbe essere d'accordo nell'inserire più cose nel protocollo?

Autore: Vitalik Buterin

Compilato da: Nian Yin Si Tang, Planet Daily

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 costruendoci sopra dei protocolli. 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.

Questa è una ricostruzione approssimativa del diagramma della lavagna che io e Gavin Gavin Wood abbiamo disegnato all'inizio del 2015 quando stavo parlando di come sarebbe stato Ethereum 2.0.

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 del conto, invece, sapevamo fin dall'inizio che un qualche tipo di implementazione era possibile, quindi la ricerca ha subito iniziato cercando di realizzare qualcosa che si avvicinasse il più possibile al puro punto di partenza di "una transazione è solo una chiamata".

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 codici principali qui è validate_transaction(state, tx), che è responsabile di verificare se il nonce e la firma della transazione sono corretti. Il vero obiettivo dell'astrazione dell'account fin dall'inizio è 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 riprogettare apply_transaction in una semplice chiamata EVM non è solo un'attività "rendi il codice pulito per il gusto di renderlo pulito", si tratta invece di spostare la logica nel codice dell'account dell'utente, offrire 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 costo di aumentare enormemente la complessità di altre parti dello stack Ethereum, richiedendo essenzialmente che lo stesso codice sia scritto altrove, oltre a introdurre un intero nuova classe di stranezze. 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 divenne in seguito EIP-208 e infine il pratico EIP-2938.

Tuttavia, l’EIP-2938 è tutt’altro che minimalista. I suoi contenuti includono:

  • Nuovo tipo 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 EVM e per archiviare temporaneamente ETH per il pagamento una tantum delle commissioni

  • Un insieme complesso di strategie di mining e ritrasmissione, incluso un elenco di codici operativi vietati durante la fase di verifica della transazione

Nel tentativo di ottenere l'astrazione degli account senza coinvolgere gli sviluppatori principali di Ethereum (che erano concentrati sull'ottimizzazione dei client Ethereum e sull'implementazione delle fusioni), EIP-2938 è stato infine riprogettato come ERC-4337, che era completamente fuori protocollo.

ERC-4337. Si basa interamente sulle chiamate EVM!

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 di guida sul motivo per cui questo percorso dovrebbe essere considerato.

Pacchetto ERC-4337

Ci sono diversi motivi chiave discussi per riportare eventualmente ERC-4337 nel protocollo:

Efficienza del gas: qualsiasi operazione eseguita all'interno dell'EVM comporta un certo grado di sovraccarico della macchina virtuale, comprese inefficienze quando si utilizzano funzionalità costose del gas come gli slot di archiviazione. Attualmente, queste ulteriori inefficienze ammontano ad almeno 20.000 gas, o 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 la responsabilità implicita 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. Avvolgere ERC-4337 e rendere l'azione dell'utente un tipo di transazione "corretto" risolverebbe 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 (per un totale di 3.800 gas) e 413 volte il testimone Chunk_cost (per un totale di 82.600 gas). Questo per non parlare del punto di ingresso ERC-4337 stesso, che nella versione 0.6.0 ha 23.689 byte in 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 un 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 "leggibilità" al protocollo. 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 secp256k1. 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.

PacchettoZK-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 riguarda 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 molteplici 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à un livello base Ethereum, ha un EVM e abbiamo già un meccanismo funzionante per la gestione dei bug nell'implementazione: se c'è un bug, il client verrà aggiornato 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 solo mantenere il ruolo equivalente di EVM, allora devono implementare la propria governance per modificare costantemente le loro regole ZK-EVM interne per abbinare gli aggiornamenti al livello base di Ethereum, il che sembra sbagliato perché alla fine sono costruiti sopra dello strato base di Ethereum stesso, 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; è dimostrato che se un rollup comprime correttamente i dati, la compressione con stato può risparmiare 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 del rollup del 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 implementare EVM su L1 con il peso delle sue molteplici implementazioni e del consenso sociale off-chain, questo sembra sbagliato , ma L2 facendo lo stesso identico lavoro dovrebbe implementare un dispositivo complesso che coinvolga il consiglio di sicurezza. Ma d'altro canto c'è un grosso problema nei dettagli: esistono diverse versioni di ZK-EVM e hanno costi e vantaggi 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 sia speranza che 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 migliorare l’esperienza degli strumenti esistenti aumentandone le funzionalità e rendendoli più robusti. BOOST è il token di utilità nativo utilizzato per sbloccare funzionalità premium e aggiornabili, votazioni future in eventi di governance ed elaborazione dei pagamenti per funzionalità future del prodotto. I prossimi prodotti BOOST includono BoostSWAP, BoostFARM e BoostNFT. Questi prodotti innovativi miglioreranno l’infrastruttura DeFi esistente e contribuiranno ad espandere la comunità Internet decentralizzata. BOOST Coin è stata lanciata il 9 agosto 2021, con 1 miliardo di token in circolazione. Boost è attualmente negoziabile su Uniswap e sarà presto disponibile su BoostSwap. Scopri altre soluzioni a questo problema come la separazione proponente-costruttore fuori protocollo, che consente ai validatori regolari ("propositori") di esternalizzare la costruzione dei blocchi ad attori dedicati ("costruttori")).

Tuttavia, MEV-Boost presuppone la fiducia in una nuova classe di attori chiamati relè. Negli ultimi due anni ci sono state molte proposte per creare una "PBS confezionata". 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. Ciò è 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 privata

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 una serie di progetti dedicati alla creazione di "mempool privati" (o "mempool crittografici"), 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:

Crittografia per operatori centralizzati come Flashbots Flashbots Flashbots è una società di ricerca e sviluppo focalizzata sul Miner Extractable Value (MEV), con l'obiettivo di mitigare le esternalità negative e i rischi esistenziali che il MEV porta alle blockchain dei contratti intelligenti. Vedi di più Proteggi.

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 segmento di utenti disposti a fidarsi di essa, nessuna soluzione è abbastanza affidabile da essere effettivamente accettata dal Livello 1. Pertanto, almeno fino a quando la crittografia ritardata non sarà perfezionata o non sarà raggiunta 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 è quella di poter utilizzare i propri ETH sia per lo staking che come garanzia collaterale 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 ERC20: converti il ​​tuo ETH in "staking ETH", mantienilo e poi riconvertilo. Infatti, Lido Lido Lido è una soluzione di staking in pool di liquidità. Lido consente agli utenti di scommettere sulla catena pubblica PoS con rendimenti composti mentre partecipano ad attività sulla catena (come prestiti, scambi) senza depositi minimi o manutenzione dell'infrastruttura. Attualmente supporta ETH2.0, Terra e Solana e in futuro potrebbe essere esteso ad altre catene pubbliche POS. Visualizza altro e Rocket Rocket Rocket (ROCKET) è una criptovaluta lanciata nel 2021 e funziona sulla piattaforma BNB Smart Chain (BEP20). Visualizza di più Pool Pool supporta le organizzazioni che consentono alle persone comuni di monetizzare e condividere i propri dati Visualizza di più I fornitori di staking di liquidità come Già hanno iniziato a farlo. Tuttavia, ci sono alcuni meccanismi naturali di centralizzazione in gioco con lo staking di liquidità: le persone passeranno naturalmente allo staking della 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 Rocket Pool RocketPool è un servizio di infrastruttura PoS di Ethereum. Tutti gli individui e le organizzazioni che desiderano guadagnare interessi su Ethereum attraverso lo staking regolare possono partecipare allo staking utilizzando la rete decentralizzata e gestita da nodi di RocketPool. Vedi di più, il primo ha operatori di nodi inseriti nella whitelist DAO e il secondo consente a chiunque di gestire un nodo con un deposito di 8 ETH. I 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, ma questo lo trasformerebbe in Strumenti dell'attaccante.

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 perso. 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 dell'attacco venga tagliato, allora oltre il 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 del nodo (requisiti collaterali elevati) e depositanti (nessun requisito minimo di garanzia, possono aderire e uscire in qualsiasi momento), ma vogliamo comunque dotare un sistema campionato casualmente poteri del comitato dei depositanti 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 essenzialmente esce dal 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 funzionalità, ma vale la pena notare che esiste questo spazio di progettazione di "includere alcune cose e lasciare altre cose all'utente".

Incapsula più precompilazione

I precompilati (o "contratti precompilati") sono contratti Ethereum che implementano operazioni crittografiche complesse, con 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 secp256r1, una curva ellittica leggermente diversa da secp256k1 utilizzata per gli account Ethereum di base, poiché è ben supportata da moduli hardware affidabili, quindi utilizzarla ampiamente potrebbe migliorare la sicurezza del portafoglio. Negli ultimi anni, la comunità ha anche spinto per aggiungere la precompilazione per BLS-12-377, BW6-761, abbinamento generalizzato e altre funzionalità.

La controargomentazione a queste richieste di più precompilatori è che molti dei precompilatori aggiunti in precedenza (ad esempio 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 forse concentrarci su un approccio più modesto basato su EVM-MAX MAX MAX Token è un token di utilità emesso da Max Asset Exchange (MAX). MAX Exchange si concentra sul supporto della propria comunità commerciale e sulla fornitura della piattaforma di trading più sicura. I token MAX verranno ricompensati tramite il mining delle transazioni e potranno anche essere utilizzati per lo staking della piattaforma per ottenere premi. Visualizza altro e idee come la proposta SIMD dormiente ma sempre ripristinabile, che consentirebbe alle implementazioni EVM di eseguire un'ampia gamma di classi di codice a un costo inferiore. Forse anche la precompilazione esistente e 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 velocizzarle, 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 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 è l'argomento 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;

  • Invece di incapsulare l’intero concetto di rollup, è possibile incapsulare semplicemente la verifica EVM.

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.