Il futuro degli aggiornamenti di Ethereum, post-unione [Parte 2]

Il più grande aggiornamento di sempre di Ethereum, il passaggio a un meccanismo di consenso proof-of-stake, è proprio dietro l'angolo. Ma mentre la fusione dovrebbe aggiungere sicurezza e sostenibilità, non include lo sharding, il metodo tanto atteso per ridimensionare la rete. 

In Parte I Durante la nostra conversazione con il ricercatore della Ethereum Foundation (EF) Danny Ryan, che ha contribuito a coordinare il processo di aggiornamento, abbiamo discusso di ciò che Merge è progettato per apportare in termini di sicurezza e stabilità.

Nella Parte II, Ryan parla degli aggiornamenti che gli utenti possono aspettarsi in futuro, tra cui danksharding, Ethereum senza stato e aggiornamenti di sicurezza che sono alle prese con l'aumento del valore estraibile dal minatore (MEV). Spiega anche come questo impegno durato anni abbia portato a nuovi metodi per la ricerca e il test dei futuri aggiornamenti.

---

Coordinamento su una rete decentralizzata

FUTURO: Hai accennato alla possibilità che i minatori si biforchino e continuino a provare a utilizzare la vecchia catena. Ma nella maggior parte dei casi, questo processo ha coinvolto tutti. Qual è il tuo ruolo in questo come ricercatore della Ethereum Foundation? Come viene coordinata una mossa così massiccia?

DANNY RYAN: Ho iniziato a occuparmi di prove di palo intorno al 2017, e anche allora sembrava una conclusione scontata. È stato cinque anni fa. E la comunità di Ethereum è stata molto disposta a non stagnare e a farlo bene, e a costruire un protocollo che non funzioni solo oggi ma funzioni, si spera, per 100 anni o più. 

Pertanto, all’inizio della sua etica, quando c’era la sensazione che la prova di posta in gioco potesse essere fatta in modo sicuro e migliore della prova di lavoro, le persone ne erano molto entusiaste. E quando arriva il 2016, il 2017, le persone non solo ne sono entusiaste, ma sono ansioso perché accada. Sembra che sia molto radicato nell'etica della comunità di Ethereum che ciò accada.

Ci sono questioni più delicate. Ci sono conclusioni meno scontate in cui EF, il team di ricerca e i clienti esterni a EF cercano tutti di trovare soluzioni ai problemi e mantenere le cose in movimento. A volte le soluzioni si trovano in una zona grigia: è questa la soluzione giusta? Lo facciamo adesso? Lo facciamo più tardi? Ciò finisce per essere difficile e l'EF tenta di aiutare a coordinare questi metodi, aiutare a fare un po' di ricerca e sviluppo per aiutare a verificare le soluzioni, aiutare a facilitare le conversazioni per decidere le tempistiche, le priorità e gli ordini. 

Ma alla fine, sulla maggior parte dei punti, l’agenda di EF è quella di contribuire a rendere il protocollo più sostenibile, sicuro e scalabile pur essendo decentralizzato – e non di offrire una particolare funzionalità rispetto ad un’altra. Quindi, gran parte di ciò su cui ci concentriamo quando si tratta sia di lavoro tecnico che di coordinamento sociale riguarda la facilitazione di una buona informazione, una buona ricerca e un buon dialogo in modo che i numerosi partecipanti coinvolti nella ricerca e sviluppo, nell’ingegneria e nella comunità possano mantenere le cose si muovono e prendono decisioni.

Negli ultimi cinque anni si sono aggiunte molte più voci alla comunità e, dopo la fusione, teoricamente diventerà più decentralizzata. Che cosa pensi del futuro processo di aggiornamento? È possibile che esamineremo una sorta di DAO di livello uno per coordinare gli aggiornamenti?

A quanto ho capito, la comunità di Ethereum non è favorevole al voto on-chain – o a qualsiasi tipo di voto e aggiornamento plutocratico – e che il protocollo sia quello che gli utenti decidono di eseguire. In generale, c'è un ampio consenso. A volte ci sono degli scismi, ad esempio Ethereum vs. Ethereum classico. Ma alla fine è un tuo diritto, un diritto della comunità e un diritto degli utenti decidere quale software vogliono eseguire. In generale, siamo d'accordo perché le persone stanno cercando di migliorare Ethereum, e non ci sono molti conflitti su alcune delle cose fondamentali. 

Quindi non mi aspetto un meccanismo tecnico formale. Mi aspetto che il processo continui a crescere, cambiare ed evolversi in questo tipo di governance libera, dove ci sono ricercatori, ci sono sviluppatori, ci sono membri della comunità, ci sono dapps e cose del genere. 

Direi che – e penso che tu ne abbia fatto allusione – ci sono sempre più persone al tavolo, e sta diventando sempre più difficile prendere decisioni e spedire le cose. Personalmente credo che questa sia una caratteristica. Penso che sia dal punto di vista dell'affidabilità per le applicazioni e gli utenti, sia per evitare la cattura a lungo termine, sia probabilmente importante che gran parte del protocollo Ethereum si ossifichi. Quindi, anche se è sempre più difficile trovarsi nel vortice della governance e provare a spedire, e a volte mi sembra di provare a correre con un giubbotto zavorrato e dei pesi alle caviglie e ora ho dei pesi ai polsi, io Penso che abbiamo alcune cose fondamentali da portare a termine nei prossimi anni. Ma penso che sarà sempre più difficile portare a termine le cose. E penso che sia una buona cosa.

Vitalik lo chiama “velocità di fuga funzionale.” Portiamo Ethereum a un punto in cui abbia scala e funzionalità sufficienti da poter essere esteso e utilizzato in una moltitudine infinita di modi nello strato successivo dello stack. Avere l'EVM dotato di funzionalità minime sufficienti, avere una disponibilità di dati sufficiente per gestire enormi quantità di scala e quindi le applicazioni possono estenderlo in contratti intelligenti. I livelli due possono sperimentare nuove VM all'interno delle loro costruzioni di livello due; puoi scalare Ethereum e così via.

Penso che sarà sempre più difficile portare a termine le cose. E penso che sia una buona cosa.

Forche d'ombra

Una delle cose che sono emerse da questo specifico processo di test sono stati gli shadow fork, il processo di copia dei dati reali di Ethereum su una testnet per simulare un ambiente di test della mainnet. Era sempre nei piani? E come pensi che ciò potrebbe cambiare il processo di ricerca e sviluppo per futuri aggiornamenti?

Avremmo dovuto fare shadow fork negli ultimi quattro anni. Sono grandi; sono davvero fantastici. Essenzialmente prendo un numero di nodi che controlliamo - chiamiamolo 10, 20, 30 - e pensano che stia arrivando un fork, quindi sono sulla mainnet o su uno di questi testnet e poi in qualche condizione di fork, come l'altezza del blocco, loro dicono tutti: "Okay, siamo sulla nuova rete". E si biforcano e poi si ritrovano nella loro realtà, ma hanno lo stato delle dimensioni di una rete principale.

E per un po' puoi convogliare le transazioni dalla rete principale a questa realtà biforcuta per ottenere una quantità ragionevole di quella che sembra un'attività organica degli utenti, il che è davvero positivo. Ci consente di testare quelli che si sono rivelati processi altamente organici difficili da simulare. Ed è stato grandioso. Scommessa [Jayanthi] e altri che lavorano nel team DevOps di EF hanno orchestrato tutto questo e abbiamo imparato moltissimo da loro. Penso che se lo chiedessi a qualcuno, direbbero: "Beh, sì, sarebbe stato fantastico se lo avessimo fatto tre anni fa, quattro anni fa ad ogni aggiornamento".

Ma dirò un'altra cosa. Lo dico [da] un anno fa e ora siamo nella lunga coda in termini di sicurezza e test: è davvero un duro colpo questa cosa, assicurarsi che tutti i casi limite siano corretti, assicurarsi che quando arriva, accada - facciamo un tentativo e funziona. E si scopre che, visto il modo in cui il software è costruito con client a livello di esecuzione del consenso, c'è molto da costruire in termini di test. Le forcelle ombra sono una di queste. Utilizzando altri ambienti di simulazione in grado di testare queste due cose insieme, ad esempio curtosi, Antitesi, E altri. 

Ci sono altre cose che dobbiamo fare, come ricablare Alveare, che è il nostro framework di test di creazione notturna di integrazione, in modo che possa gestire entrambi questi tipi di client e in modo che tu possa scrivere test in cui si verificano diverse complessità su entrambi i lati del corridoio. Tutto ciò doveva accadere. Innanzitutto, le strutture dovevano essere sviluppate o modificate. Quindi è stato necessario scrivere molti test. Quindi la cosa bella del Merge è che abbiamo davvero migliorato gli strumenti nella nostra toolbelt per essere in grado di testare gli aggiornamenti in modo tale che il prossimo aggiornamento riguarderà molto più la scrittura dei test piuttosto che pensare a come testarlo e scrivere i framework per testarlo. 

Cosa c'è dopo la prova di puntata?

Dato che questa cosa va avanti da molto tempo, inizialmente lo sharding sarebbe arrivato prima. Ma gli sviluppi dell’ecosistema hanno fatto sì che si potesse prima passare alla prova di partecipazione. Ci sono stati altri sviluppi dell’ecosistema emersi durante questo processo che potrebbero spostare il tuo approccio verso futuri aggiornamenti?

Prima di tutto, ci sono probabilmente una serie di ragioni per cui è stata data priorità allo spostamento del proof of stake. Uno era smettere di pagare più del dovuto la sicurezza con la prova del lavoro. E l'altro era che la scala cominciava a emergere attraverso queste costruzioni del secondo strato. Quindi, forse se ne ottieni una scala 10-100x, puoi concentrarti su quest'altra cosa e finire il lavoro e unificare questi due sistemi disparati: la catena di beacon e l'attuale mainnet. 

Ci sono alcune altre cose che hanno influenzato il modo in cui pensiamo alle scadenze e alle priorità. Ho menzionato prima che l’intero mondo MEV ha messo i bastoni tra le ruote in alcune cose. Ci sono centralizzazione e altri problemi di sicurezza che emergono quando si inizia a pensare a dove potrebbe andare il MEV. E negli ultimi 12 e più mesi sono state condotte molte ricerche su come mitigare alcune di queste preoccupazioni con modifiche di primo livello. A seconda dell'analisi delle minacce provenienti dal mondo MEV, ciò potrebbe dare priorità ad alcune funzionalità di sicurezza e aggiunte di sicurezza a L1 rispetto a qualcos'altro che forse ci si aspettava fosse la priorità. 

Penso che qualcosa di interessante sia la tabella di marcia dello sharding e l'attuale costruzione prevista, che si chiama danksharding, dal nome Dankrad [Feist], il nostro ricercatore presso l'EF. L’intera costruzione è in realtà semplificata se si presuppone che esistano questi attori MEV altamente incentivati. Alcuni di questi attori esterni non solo hanno modificato il modo in cui pensiamo alla sicurezza, ma alterano anche il modo in cui possiamo pensare alla costruzione di questi protocolli. Se presumi che il MEV esista, se presumi che questi attori altamente incentivati ​​siano disposti a fare certe cose grazie al MEV, allora all’improvviso hai questo partecipante terzo nel consenso a cui forse puoi scaricare le cose, il che in molti modi può essere semplificativo. Quindi non arrivano solo cose brutte, ma si aprono anche nuovi tipi di progetti.

Abbiamo davvero migliorato gli strumenti nella nostra toolbelt per essere in grado di testare gli aggiornamenti in modo tale che il prossimo aggiornamento riguarderà molto più la scrittura dei test piuttosto che pensare a come testarlo.

L'Ethereum senza stato viene ancora discusso e ricercato attivamente? 

SÌ. Lo stato - tutti i conti, i contratti, i saldi e tutto il resto - questo è lo stato di Ethereum. Dato dove ti trovi nella blockchain, c'è uno stato di realtà. Quella cosa cresce nel tempo, cresce linearmente. E se aumenti il ​​limite del gas, cresce ancora più velocemente. Quindi questa è una preoccupazione. Se cresce più velocemente della memoria e dello spazio sul disco rigido delle macchine consumer, allora si avranno problemi con la possibilità effettiva di eseguire nodi su computer domestici e hardware consumer, con problemi di sicurezza e centralizzazione. Inoltre, se parli con alcuni dei Geth Membri del team [cliente], il fatto che lo stato continui a crescere significa che devono continuare a ottimizzare le cose. Quindi è difficile.

L'Ethereum senza stato e cose in quella direzione di ricerca sono un potenziale percorso di soluzione per questo, dove per eseguire un blocco non ho effettivamente bisogno dell'intero stato; c'è una specie di input nascosto nell'esecuzione della funzione di un blocco. Ho bisogno del pre-stato, ho bisogno del blocco e poi ottengo il post-stato per sapere se il blocco è valido. Mentre con Ethereum senza stato, i requisiti statali – gli account e altre cose necessarie per eseguire quel particolare blocco – sono incorporati nel blocco e sono la prova che quello è lo stato corretto. Ora eseguire un blocco e verificare la validità di Ethereum diventa semplicemente [dover] avere il blocco, il che è davvero positivo. Ora possiamo avere nodi completi che non hanno necessariamente uno stato completo. Apre un intero spettro di come costruire i nodi. Quindi potrei avere un nodo che convalida completamente e non ha lo stato, potrei avere un nodo che mantiene semplicemente lo stato rilevante per me, oppure potrei avere nodi molto completi che hanno tutto lo stato e quel genere di cose.

Si sta lavorando attivamente su questo. In realtà, credo, attualmente esiste un testnet con tutte le altre cose divertenti che devono accadere per far sì che ciò accada. La mia valutazione attuale è che la domanda di sharding e scala L1 è superiore all’imminente minaccia di crescita statale. Quindi è molto probabile che, poiché l'uno avrà la priorità rispetto all'altro, anche la scala avrà la priorità. 

Detto questo, è difficile dirlo. C'è "proto-dankharding”, che è una specie di modo graduale per ottenere un po’ più di scala. Forse ciò accade e poi accade lo stateless e poi avviene lo sharding completo, a seconda delle esigenze e della valutazione di ciò che sta accadendo e delle minacce coinvolte. Penso che il pensiero generale sulla crescita dello stato sia che dobbiamo avere un percorso e dobbiamo risolverlo, ma [che] gli incendi imminenti sono stati spenti e che questa non è una cosa che paralizzerà Ethereum nei prossimi due anni. Ma è una cosa che va sistemata.

Guidami attraverso gli aggiornamenti che abbiamo do sapere per dopo la fusione. Ci sarà un aggiornamento di pulizia? È separato dall'aggiornamento di Shanghai? E quando viene introdotto lo sharding?

Shanghai sarà probabilmente il nome di qualunque sia il bivio dopo la fusione. Per ritirare effettivamente i tuoi fondi che hai puntato per quasi due anni ormai, [questo] non viene abilitato al momento della fusione. Inizialmente si prevedeva che venissero completati, ma data la complessità della fusione, nel tempo, si è deciso di ridurla davvero e di eseguire semplicemente la fusione e di non aggiungere la funzionalità extra dei prelievi. Mi aspetterei moltissimo che i prelievi fossero abilitati a Shanghai, quindi il primo aggiornamento dopo la fusione. Questo è stato promesso a molte, molte persone che hanno molto capitale in gioco e non mi aspetto alcun problema al riguardo. Questi sono generalmente specificati, ci sono test scritti e quel genere di cose. 

Ci sono una serie di altri miglioramenti all'EVM [Ethereum Virtual Machine] che penso possano essere inseriti in questo sistema: diverse operazioni matematiche, alcune diverse cose di estensibilità, un controllo delle versioni leggermente migliore all'interno dell'EVM e altre funzionalità. È una sorta di valvola di rilascio della pressione sui miglioramenti dell'EVM, che sono stati messi da parte ormai da diversi anni per eseguire la fusione e altri aggiornamenti. E le persone vogliono davvero vedere una sorta di piccolo aggiornamento della scalabilità qui. Quindi potrebbe trattarsi di proto-danksharding, che getta le basi per lo sharding completo e ottiene un po' più di scala, o potenzialmente chiamate riduzioni del prezzo del gas, che sono molto facili ma non sono realmente una soluzione sostenibile. Ecco cosa ci aspettiamo, si spera, a Shanghai: ritiri e un po' di scala.

Allora la domanda è: cosa c'è dopo? E questo è difficile da dire. Se otteniamo un po' di scala lì, e si integra molto bene con gli L2 e le cose vanno abbastanza bene, allora forse ci sarà una richiesta di fare stateless a quel punto. O se gli L2 hanno un bisogno insaziabile di maggiore scala, allora forse questo prepara il terreno per il danksharding completo.

Questa intervista è stata modificata e condensata. 

Pubblicato il 27 luglio 2022