Alla scoperta degli aggiornamenti di Ethereum: Hegotá

Ciò che Ethlabs sta dando priorità per Hegotá e perché.

La direzione di Ethereum è importante per tutti coloro che ci costruiscono sopra, la usano, detengono ETH o semplicemente credono in ciò che può diventare. Sebbene quel futuro sarà in ultima analisi determinato dalle persone, dalle applicazioni e dalle comunità che costruiscono su Ethereum ogni giorno, gli aggiornamenti della rete sono uno dei modi principali con cui il protocollo si evolve per soddisfare le loro esigenze. Hegotá è il prossimo aggiornamento di rete pianificato di Ethereum dopo Glamsterdam, e questo documento condivide la visione di Ethlabs su ciò che riteniamo Ethereum dovrebbe priorizzare per esso, e perché.

Ethlabs è un laboratorio R&D senza scopo di lucro per Ethereum e ETH nato 8 settimane fa, e la nostra missione è rendere Ethereum il livello di regolamento dell'economia globale. Ci posizioniamo tra l'uso reale di Ethereum e lo sviluppo del protocollo, e dedichiamo il nostro tempo ad ascoltare utenti, wallet, applicazioni, rollup, istituzioni, detentori di ETH, ricercatori e team client. A volte costruiamo anche onchain, perché non si può costruire un'arena senza parteciparvi! Crediamo che una grande ingegneria del protocollo dovrebbe rendere possibili grandi prodotti, e che i grandi prodotti dovrebbero aiutare a informare la direzione futura del protocollo.

L'ambito di Hegotá è attualmente nelle fasi iniziali di definizione attraverso il processo tecnico aperto di Ethereum, e le proposte seguenti riflettono il lavoro di molti individui e team di ricerca e client. Questo documento è un resoconto trasparente di ciò che raccomandiamo di priorizzare e di dove le nostre opinioni sono ancora in fase di formazione. Queste sono posizioni che ci piacerebbe vedere valutate, contestate e migliorate da altri, e le itereremo man mano che discuteremo e impareremo di più nei prossimi giorni e settimane.

Per l'aggiornamento Hegotá, considerando tutti gli EIP proposti, queste sono le aree che vediamo come priorità massima per Ethereum:

1. Maggiore resistenza alla censura: Chiunque dovrebbe essere in grado di far includere una transazione, indipendentemente da chi sia o per cosa usi Ethereum.
2. Ethereum più veloce: Blocchi più veloci significano conferme più rapide, prezzi onchain più freschi e finalità più veloce.
3. Account abstraction nativa: Gli account dovrebbero supportare passkey, transazioni sponsorizzate, pagamento del gas in token, raggruppamento e una privacy più forte, con un percorso verso chiavi post-quantum.
4. Continua scalabilità L1: Le applicazioni necessitano di capacità che rimanga accessibile e prevedibile, anche quando la domanda aumenta.

Lavorare in modo trasparente è un obiettivo fondamentale per Ethlabs, motivo per cui pubblichiamo aggiornamenti settimanali e, in occasioni come questa, pubblichiamo articoli tecnici molto lunghi per condividere il nostro pensiero 😅. Pubblicheremo anche contenuti più sintetici nelle prossime settimane per chi vuole solo i punti salienti. La prossima parte sarà lunga e tecnica. Per quelli di voi che la leggeranno tutta, buona fortuna!

Prima di tutto: come funziona il processo EIP?

Prima di immergerci nelle proposte stesse, un punto importante: la seconda fase del processo di definizione dell'ambito di Hegotá è appena iniziata. La prima fase ha selezionato FOCIL come protagonista di Hegotá. Il 6 agosto c'era una scadenza per proporre EIP non protagonisti, e il processo ACD si sposterà ora per valutare l'aggiornamento Hegotá nella sua interezza.

Tutti gli EIP qui sotto sono attualmente nella fase PFI (Proposti per l'Inclusione), ad eccezione degli EIP che hanno superato il processo per i protagonisti. Proporre un EIP per l'inclusione è senza permessi, e la maggior parte non arriva mai nell'aggiornamento finale.

Nello specifico, man mano che il lavoro di implementazione procede, le proposte attraversano fasi progressivamente più forti di revisione e fiducia nel rilascio finale:

• PFI (Proposto per l'Inclusione): un'idea è stata proposta per l'aggiornamento. Questa fase è senza permessi e non implica il supporto del client o l'inclusione finale.
• CFI (Considerato per l'Inclusione): i team client hanno esaminato la proposta e intendono prototiparla e testarla.
• SFI (Programmato per l'Inclusione): c'è una chiara intenzione di includerlo, presupponendo che l'implementazione e i test continuino ad andare bene.

Per saperne di più su come funziona questo processo, consigliamo di guardare la rapida spiegazione di Tim Beiko qui.

Avvertenze: come navigare in questo articolo

Seguiamo la classifica a livelli di Forkcast per esprimere la nostra visione della priorità degli EIP per Hegotá. Per minimizzare le decisioni, mappiamo tutti gli EIP revisionati in quattro livelli con le seguenti interpretazioni:

• [Livello S] fortemente raccomandato per l'inclusione.
• [Livello A] raccomandato per l'inclusione se i restanti blocchi come la complessità di implementazione, l'analisi dell'impatto o l'adozione vengono risolti.
• [Livello B] utile, ma forzato per questo aggiornamento.
• [Livello D] non raccomandato per l'inclusione in Hegotá nella sua forma attuale.
• [opinione in formazione] stiamo ancora formando la nostra opinione su questo EIP.

Si prega di notare che queste sono raccomandazioni di Ethlabs. Valutiamo ogni proposta principalmente in termini di scopo, specifica e la nostra comprensione della plausibile complessità di implementazione, tranne dove abbiamo maggiore certezza o coinvolgimento diretto (es. Frames e Quick Slots), e aggiorneremo la nostra visione basandoci sulle valutazioni di ethPandaOps, dei team di test e dei client man mano che procediamo nel processo.

[CL] significa che un EIP influisce sui client del livello di consenso e [EL] significa che influisce sui client del livello di esecuzione.

Nota che siamo co-autori e coinvolti in diversi EIP (inclusi FOCIL, Frame Transactions e Quick Slots). Sebbene ci sforziamo di valutare tutti gli EIP indipendentemente dal nostro coinvolgimento o meno, ti preghiamo di tenerlo in considerazione quando valuti la nostra posizione.

tl;dr

Classifica CL

Puoi iterare su questa specifica classifica [CL] su Forkcaster qui.

Classifica EL

Puoi iterare su questa specifica classifica [EL] su Forkcaster qui.

Ora, senza ulteriori indugi, ecco le nostre opinioni sull'aggiornamento Hegotá così come sono oggi, nella loro interezza:

Temi per Hegotá

0. FOCIL: rafforzare la resistenza alla censura

EIP-7805: FOCIL è già SFI'd e confermato come protagonista di Hegotá. Tre membri del team Ethlabs (Francesco, Barnabé e Julian) sono tra i suoi co-autori, e sosteniamo fortemente la sua inclusione. Dato che la decisione è già presa, la teniamo breve. Solo una catena che è neutrale verso tutti può diventare la radice di fiducia per tutti. Questo è ciò che permette a Ethereum di scalare per diventare il vero livello di regolamento per l'economia globale, e per ogni singola persona al suo interno.

1. Quick Slots: Ethereum più veloce

Lo slot di 12 secondi di Ethereum è un costo di latenza che degrada il valore per l'utente. Raccomandiamo quindi fortemente di includere [CL] EIP-8198: Quick Slots [Livello S] in Hegotá, per quattro motivi:

1. UX migliorata su L1 con conferma delle tx più rapida.
2. I mercati onchain su L1 operano con prezzi più freschi, migliorando gli spread e l'economia degli LP.
3. La finalità e la regola di conferma rapida ereditano il tempo dello slot, quindi entrambi diventano più veloci con blocchi più veloci, migliorando l'interoperabilità con Ethereum.
4. Più proposer di blocchi al secondo significa maggiore resistenza alla censura, inclusa la resistenza alla censura economica: l'importo che devi pagare per mantenere i blocchi vuoti per un certo periodo di tempo.

Andare più veloci preservando la decentralizzazione unica di Ethereum rende il blockspace di Ethereum più prezioso, e quel valore si accumula per la rete e per ETH. Ogni diminuzione è più valore immediatamente consegnato ai nostri utenti. Infine, i blocchi più veloci sono una delle richieste più frequenti da parte degli sviluppatori di applicazioni.

L'argomento per iniziare ora è che la riduzione del tempo dello slot non sarà mai un cambiamento una tantum. Come per la scalabilità, le riduzioni consegnate danno alle applicazioni più certezza degli impegni sulla roadmap. La strada verso slot inferiori a 6 secondi inizia rendendo il tempo dello slot modificabile, poi modificandolo iterativamente. EIP-8198 divide il lavoro in due:

• Un refactoring una tantum che rende il tempo dello slot più facile da aggiornare nelle specifiche e nel codice del client.
• Una prima diminuzione in Hegotá, seguita da ulteriori diminuzioni nei fork successivi, man mano che la roadmap progredisce e si ottengono prove empiriche di sicurezza.

Hegotá è il fork giusto per pagare il costo una tantum. ePBS in Glamsterdam ristruttura già lo slot. Hegotá è quindi un fork relativamente leggero per il livello di consenso, una finestra che si chiude con il consenso disaccoppiato in I*, quindi la larghezza di banda CL per il refactoring una tantum è disponibile ora in un modo che non lo sarà più per diversi fork.

Significato: O ci impegniamo a rimanere a 12 secondi per almeno i prossimi due anni, o arriviamo a 10 secondi in circa un anno in Hegotá, e possibilmente a meno di 10 secondi l'anno successivo. Queste due diminuzioni non sono miglioramenti teorici. Ottengono direttamente un maggiore valore per l'utente e una migliore economia di rete. Pensiamo che sia ora di iniziare.

Le obiezioni più comuni

Discutiamo qui 4 punti importanti che sono emersi durante le discussioni preliminari con gli sviluppatori client e l'EF Protocol:

1. Complessità di implementazione: La tempistica dello slot con precisione millisecondo è già stata integrata nelle specifiche di consenso attraverso il lavoro ePBS, e esistono bozze di specifiche CL e EL per EIP-8198, con la commissione di base, il limite del gas e la pianificazione dei blob ridimensionati per preservare il comportamento al secondo. Il costo rimanente è una coda di casi limite nei client e negli strumenti che assumono un tempo di slot fisso, più i test. Il refactoring una tantum anticipa esattamente questo lavoro. Successivamente, ogni diminuzione è un cambiamento di parametro.

2. Prova zkEVM: I due problemi principali sono il tempo di prova relativo e il sovraccarico di prova costante.

2.1 Il tempo di prova relativo misura la quota del tempo dello slot dedicata alla prova, e come questa quota cambia quando il tempo dello slot cambia. Ecco una breve descrizione dei momenti rilevanti nello slot. I builder attuali osservano il rilascio del payload precedente e possono iniziare a costruire immediatamente. Il beacon block corrente si impegna quindi per il payload dello slot corrente. Questo payload deve essere provato prima del rilascio del blocco del prossimo proposer di beacon.

Per la prova, il tempo relativo minimo è uno slot intero, meno la latenza del rilascio di un beacon block. La latenza del rilascio del beacon block è incomprimibile, ma è breve per costruzione, quindi non ci limita fondamentalmente in questa fase. C'è anche la possibilità che builder ottimizzati co-provino il payload mentre viene costruito, permettendo loro di iniziare a provare prima che il payload vincente sia impegnato dal proposer del beacon block.

2.2 La prova zkEVM scala principalmente in modo lineare con la dimensione del blocco, tranne per un certo sovraccarico fisso. Slot più veloci significano che il sovraccarico fisso viene pagato più frequentemente, il che aggiunge più latenza per la stessa quantità di throughput. Dato un budget fisso di latenza, bisogna quindi assicurarsi che si possa ancora ottenere un buon throughput. Qui vediamo due opportunità: In primo luogo, il progresso ingegneristico continuerà a ridurre la latenza di queste operazioni fisse. In secondo luogo, ritardare il calcolo della radice di stato, come descritto da EIP-7862, sposta più parte della prova al di fuori del percorso critico, il che significa che possiamo aumentare il nostro budget di latenza per le operazioni incomprimibili. La convergenza di queste due opportunità ci dice che slot più veloci non ostacoleranno ampi aumenti di throughput in futuro.

3. Transizione post-quantum: L'approccio del consenso disaccoppiato ha ottenuto sufficiente supporto per essere considerato stabile per quanto riguarda la futura architettura di consenso. Disaccoppiare significa spostare la votazione sulla finalità al di fuori del percorso critico della produzione di blocchi. In particolare, l'aggregazione su larga scala delle firme PQ, e tutta la relativa macchina STARK ricorsiva, sarà al di fuori del percorso critico. Ciò che rimane per produrre blocchi e ottenere una regola di scelta del fork per tracciare la testa della catena risultante è un sottocomitato attualmente previsto per comprendere 512 validatori, e possibilmente 256. Le dimensioni delle firme post-quantum sono maggiori, ma sono comode da propagare entro il tempo di slot proposto di 10 secondi e probabilmente meno in futuro.

4. Smart contract e infrastruttura: La dipendenza dal tempo dello slot negli smart contract e nell'infrastruttura è attualmente in fase di studio. Per gli smart contract, abbiamo collaborato con Sourcify per eseguire analisi su tutti i contratti verificati. Stiamo studiando gli impatti di un aggiornamento del tempo dello slot sulle radici dei beacon block storici, come memorizzate secondo EIP-4788: Beacon block root nell'EVM. Per quanto riguarda l'infrastruttura, come aneddoto, Etherscan ha menzionato che un cambiamento del tempo dello slot avrebbe probabilmente portato a un carico maggiore, ma che l'infrastruttura era stata costruita al tempo dei tempi di slot variabili nel Proof-of-Work, quindi non richiedeva molte modifiche.

2. Account Abstraction: migliorare UX, sicurezza e privacy

Ethereum e il suo ecosistema più ampio aspettano da tempo una AA nativa, che porterà vantaggi UX come wallet passkey, transazioni sponsorizzate, pagamenti del gas in ERC20, raggruppamento di transazioni e altro ancora.

Tuttavia, la strada verso la AA nativa è stata particolarmente accidentata perché la AA tocca ogni parte dello stack di Ethereum, inclusi client, L2, wallet, RPC, strumenti di sviluppo, ecc., quindi richiede il consenso di un'enorme varietà di stakeholder. Questo rende difficile per qualsiasi EIP AA farsi strada attraverso il processo di sviluppo guidato dal consenso di Ethereum, ma anche raggiungere un'adozione pratica dopo che l'EIP è stato rilasciato.

Pertanto, mettiamo la proposta AA nativa di Hegotá, Frame Transactions, nel livello A, non perché non sia tecnicamente abbastanza buona per il livello S, ma perché vogliamo tenere conto dei rischi di adozione pratica che richiederanno un'enorme quantità di coordinamento per essere risolti. Dato il background del nostro team nella AA, Ethlabs intende svolgere un ruolo importante nel portare Frame Transactions sul mercato, lavorando con stakeholder come L2 e wallet per realizzare un'implementazione di successo per la AA nativa.

Ora passiamo alle specifiche proposte AA per Hegotá.

[EL] EIP-8141: Frame Transactions [Livello A]

Crediamo che EIP-8141: Frame Transactions sia il miglior candidato per il sistema AA nativo di Ethereum. Rispetto ad altre proposte AA native, Frames ha una serie di proprietà desiderabili che lo rendono unicamente allineato con il mandato CROPS di Ethereum:

• Innovazione degli account senza permessi: la logica di convalida è gestita dal codice EVM, quindi gli sviluppatori sono liberi di sviluppare qualsiasi logica di convalida desiderino, a differenza di altri approcci AA che impongono una whitelist di logica di convalida.
• Supporto di prima classe per i protocolli di privacy: come corollario del primo punto, un protocollo di privacy come Railgun può gestire la logica di convalida delle frame transaction, permettendo agli utenti di inviare transazioni private senza fare affidamento su relayer centralizzati come fanno oggi. Questo rende i protocolli di privacy significativamente più privati e non censurabili.
• Sicurezza post-quantum: le frame transaction sono state sviluppate tenendo presente la più ampia roadmap PQ di Ethereum. Ad esempio, le frame transaction sono esplicitamente progettate in modo che le firme possano essere aggregate, permettendo a Ethereum di addebitare eventualmente un gas basso per le firme PQ anche se individualmente ogni firma può essere molto costosa da convalidare.

La principale debolezza di Frame Transactions deriva anche dalla sua più grande forza: poiché la convalida è gestita dal codice EVM, la convalida ora induce un costo dinamico invece di un costo fisso, il che può porre sfide per le catene ad alto TPS come le L2. Siamo ottimisti sul fatto che questo problema possa essere affrontato attraverso ulteriori EIP o ERC basati sulle frame transaction come EIP-7819, dove le transazioni possono indicare staticamente la loro logica di convalida in modo che i sequencer possano "abbreviare" la convalida con codice nativo se necessario. Intendiamo anche lavorare con le L2 e l'EF per condurre benchmark sulle frame transaction in modo da poter identificare e affrontare eventuali colli di bottiglia delle prestazioni.

[CL][EL] Componenti aggiuntivi di Frame Transactions

Ci sono un certo numero di EIP che possono essere visti come estensione delle Frame tx, basandosi sulle loro capacità.

[EL] EIP-8250: Nonce Chiave per Frame Transactions [Livello A]

• Pensiamo a questo EIP come concettualmente parte di EIP-8141: Frame Transactions, e crediamo che dovrebbe essere rilasciato con esso.
• Questo EIP introduce nonce 2D per le Frame transaction. I nonce 2D consentono agli account di inviare transazioni parallele al mempool, oltre a permettere ai protocolli di privacy di memorizzare i nullifier come nonce 2D. Questo è importante perché i nonce 2D sono uno storage speciale che costa molto poco da leggere e memorizzare, quindi le transazioni di privacy risparmiano significativamente sul gas rispetto a se memorizzassero i nullifier nello storage dinamico regolare come oggi. Questo è particolarmente importante nel contesto della riprezzatura dello storage di Glamsterdam (EIP-8037: Aumento del Costo del Gas per la Creazione di Stato).

[EL] EIP-8272: Radici Recenti per Frame Transactions [Livello B]

• Questo è un altro EIP che migliora l'esperienza dell'uso dei protocolli di privacy con le Frame transaction. I protocolli di privacy necessitano di accedere alle radici di impegno recenti durante la convalida, che se memorizzate nello storage regolare possono essere non solo costose ma anche in conflitto con le regole del mempool pubblico di Frames. EIP-8272 risolve questi problemi esponendo un contratto di sistema per memorizzare queste radici in un buffer circolare che elimina automaticamente le radici vecchie.
• Lo mettiamo nel livello B perché questo EIP aggiunge una complessità significativa a Frames per un caso d'uso specifico, e non siamo sicuri se potrebbe esserci un modo più generale/elegante per raggiungere lo stesso obiettivo.

[CL] EIP-8369: Profili VOPS per l'Eleggibilità FOCIL [Livello B]

• Questo EIP affronta l'interazione tra Frames e VOPS (validity-only partial statelessness), che è una proposta per permettere ai nodi del mempool di memorizzare solo lo stato sufficiente per convalidare le transazioni, in modo che anche in un mondo di assenza di stato (a causa di zkEVM) il mempool possa rimanere resistente alla censura.
• Lo mettiamo nel livello B perché questo EIP è fortemente legato a una particolare visione di assenza di stato su cui la comunità non si è ancora completamente allineata.

[EL] EIP-7906: Asserzioni di Transazione tramite Opcode di Diff dello Stato [Livello B]

• Questo EIP migliora la verificabilità statica dei risultati delle transazioni. Gli utenti possono già affermare cosa dovrebbe accadere, ma non che non sia accaduto nient'altro. Dimostrare l'assenza di cambiamenti di stato richiede un nuovo opcode. Combinare asserzioni positive (es. saldo WETH aumentato di almeno 1.5) con un'asserzione negativa (nessun altro stato cambiato) permette agli utenti di vincolare gli effetti completi di una transazione per costruzione, senza simulazione, con i wallet hardware come uno dei chiari beneficiari.
• Data la complessità, includerlo nell'hard fork sarebbe una scelta molto impegnativa. Suggeriamo di farlo solo se (a) i team client comprendono veramente le sfumature e le implicazioni di questo specifico EIP, e (b) la superficie di test e le complessità sono molto ben comprese.

[EL] Migrazione EOA [Livello B]

[EL] EIP-7851: Delega EOA Controllata dal Codice [Livello B] e [EL] EIP-8151: ecRecover con Codice Account Limitato [Livello B] sono meglio visti come standard accoppiati che insieme presentano una storia su come gli EOA possono passare a smart account. In questa storia, un EOA delegherebbe prima a uno smart account tramite EIP-7702. Quindi, l'opcode introdotto da EIP-7851 renderebbe permanente la delega 7702, disabilitando la chiave ECDSA radice. D'altra parte, EIP-8151 renderebbe ecrecover consapevole della disattivazione, in modo che la vecchia chiave non possa prosciugare i fondi tramite flussi di tipo Permit.

Valutiamo questa coppia nel livello B perché è solo uno dei tanti approcci per migrare gli EOA a smart account, e questo approccio particolare non ha ricevuto un'ampia revisione o consenso. In particolare, siamo preoccupati che questo approccio non risponda alla questione multi-catena: come migra lo stesso EOA sulle L2? L'utente dovrebbe eseguire la stessa azione su TUTTE le catene, incluse catene che non esistono ancora, il che si tradurrà in una cattiva UX. Sospettiamo che possa esserci un approccio migliore in cui le L2 possono sfruttare la L1 come "radice di fiducia" per la migrazione EOA, quindi riserviamo i livelli A/S per approcci che consentirebbero agli utenti di migrare una volta per tutte le catene EVM.

[EL] Schema di firma PQ [Livello A]

Hegotá dovrebbe stabilire un percorso credibile verso le firme post-quantum, ma dovremmo confermare il meccanismo corretto prima di impegnarci.

• EIP-8355: Aggiungere verifica ML-DSA precompilati, rendendo concreta la sicurezza dell'account post-quantum insieme a Frame Transactions.
• Alternativa: Pre-registrare il supporto PQ senza attivarlo, o definire un formato di derivazione che possa accogliere chiavi PQ in seguito.

[EL] EIP-7819: Istruzione SETDELEGATE [Livello A]

• Con la AA nativa che probabilmente arriverà in Hegotá, è importante che il costo di implementazione di nuovi smart account sia basso, ma implementare account diventerà effettivamente più costoso in Glamsterdam a causa di EIP-8037. Con EIP-7819, i nuovi account utilizzerebbero semplici puntatori di delega invece di contratti proxy, riducendo enormemente la quantità di nuovo stato che deve essere creato, riducendo così il costo di implementazione.
• Mettiamo questo EIP nel livello A perché crediamo che un costo di implementazione dell'account inferiore ridurrebbe significativamente l'attrito per l'adozione della AA.

3. Ingegneria delle prestazioni: continua scalabilità L1

Glamsterdam ha segnato un cambiamento nel modo in cui Ethereum affronta la R&D, con le prestazioni trattate come un vincolo R&D di prima classe, sia nella progettazione del protocollo che nel lavoro del client. L'esecuzione ritardata, le riprezzature delle risorse e molto lavoro di ottimizzazione del client hanno permesso di scalare da 30M a (almeno) 200M negli ultimi due anni. In generale, il lavoro sulle prestazioni ci dà opzionalità: il margine di manovra che guadagniamo può essere utilizzato per la scalabilità, per accorciare gli slot, per abbassare i requisiti dei nodi, o tutti e tre.

Oggi, vediamo ancora la continua scalabilità come una necessità. Le applicazioni decidono dove costruire basandosi non solo sui prezzi correnti, ma sul fatto che Ethereum possa espandere l'offerta di blockspace in modo prevedibile nel tempo. Fornire costantemente aumenti fornisce più certezza dei soli impegni sulla roadmap. La capacità della mainnet è anche ancora piuttosto lontana dall'essere in grado di gestire picchi di domanda: all'undicesimo compleanno di Ethereum, la commissione di base mediana giornaliera era solo di circa 0,1 gwei, eppure un NFT mint l'ha spinta sopra i 10 gwei per un po' di tempo, con i costi medi di transazione che hanno raggiunto circa $1 e il 90° percentile più di $5. La spinta alla scalabilità di Glamsterdam dovrebbe quindi continuare in Hegotá.

Nell'insieme, i seguenti EIP continuano lo slancio di scalabilità di Glamsterdam rafforzando al contempo il principio più ampio alla base: le prestazioni dovrebbero rimanere una preoccupazione di prima classe sia nel lavoro del client che nella progettazione del protocollo.

[EL] EIP-8131 e EIP-8279 [Livello S]: Pacchetto di riprezzatura dei dati

Dopo Glamsterdam, il prossimo vincolo stringente è la propagazione del payload, in parte perché diverse fonti di byte del payload si riflettono in modo incoerente, o per niente, nella contabilizzazione del gas. EIP-8131: Unified Transaction Content Floor estende il floor di transazione esistente al contenuto noto prima dell'esecuzione, mentre EIP-8279: Block Access List Byte Floor copre i byte BAL creati dinamicamente durante l'esecuzione.

Questa misurazione dinamica rende EIP-8279 chiaramente il più complesso dei due. Tuttavia, suggeriamo di considerarli come un pacchetto. Insieme, stabiliscono una contabilizzazione coerente per i byte associati a una transazione, limitando il payload nel caso peggiore, lasciando inalterate la maggior parte delle transazioni ordinarie e non dat-heavy. Questo risolve il divario nella contabilizzazione delle risorse e apre la strada a ulteriori aumenti del limite del gas.

[CL][EL] EIP-8146: Block Access List Sidecars [Tier A]

EIP-8146 completa le riprezzature migliorando il percorso critico stesso, propagando i BAL separatamente dal payload, il che migliora la propagazione e offre ai client di esecuzione un vantaggio iniziale nel prefetching dello stato e nel calcolo della radice dello stato post-esecuzione. Vediamo questo come il tipo di ottimizzazione a basso costo che non dovremmo lasciare sul tavolo. Il lavoro di implementazione è principalmente il familiare meccanismo di gossip del CL, rendendo questo un EIP a basso sforzo e alto valore, specialmente in un fork che si sta configurando come piuttosto pesante sul lato EL.

Altri EIP correlati

[EL] Ricalibrazione CPSB [Tier A]

• Modifiche molto semplici, raccomandiamo di mantenerle in cantiere e di includerne una delle due se ritenuto necessario in base agli aumenti pianificati del limite del gas e all'uso osservato del gas di stato e di esecuzione.
• EIP-8368: CPSB Recalibration for New Gas Limit: Follow-up pre-pianificato di EIP-8037, che compensa il fatto che il costo per byte di stato (CSPB) è stato reso statico anziché una funzione del limite del gas, puramente come semplificazione di implementazione e test. L'idea era di sostituire l'aggiustamento blocco per blocco con aggiustamenti una tantum ai fork, se necessario, per mantenere la crescita dello stato in linea con l'aumento del limite del gas. Poiché l'attuale CPSB è stato calibrato su un limite di gas di 150M, è probabile che un aggiustamento in Hegotá sia giustificato.
• EIP-8372: Normalized state gas limit: Ancora un superset abbastanza minimale di EIP-8368, che consente un aggiustamento più granulare del solo CPSB, compensando il fatto che l'obiettivo di crescita dello stato o l'obiettivo regolare del gas vengano mancati a causa di un errore relativo di prezzo.

[EL] EIP-7862: Delayed State Root [Tier B]

• Semplice da specificare, ma la complessità delle implementazioni dei client non è molto ben compresa per quanto ne sappiamo. La radice dello stato è pervasiva nei codebase.
• Sebbene ci sia qualche beneficio nell'abbassare la barriera di accesso alla creazione competitiva (calcolo veloce della radice dello stato), il vantaggio più sostanziale dell'EIP è, a nostro avviso, nel futuro (più tempo per dimostrare il calcolo della radice dello stato).
• L'EL è già il lato pesante di Hegotá.

[CL] EIP-8341: Partial Execution Payload Commitments [Tier D]

• Raccomandiamo di respingere: piccolo beneficio (ritardare leggermente il calcolo della radice dello stato), non urgente, e superato da EIP-7862: Delayed State Root (che dà molto più tempo per farlo).

Altri EIP

Ora copriamo il resto degli EIP, raggruppati liberamente per argomenti. Su alcuni EIP stiamo ancora formando la nostra opinione. Aggiorneremo questo documento man mano che impareremo di più dai team client e dagli autori degli EIP nei prossimi giorni e settimane.

Poiché Hegotá si prospetta come un hard fork sbilanciato verso l'EL, suggeriamo di rimanere disciplinati e di mantenere uno standard elevato per qualsiasi EIP lato EL che voglia essere incluso. Pensiamo che mantenere Hegotá relativamente leggero sul lato CL oltre a FOCIL e Quick Slots sia desiderabile: un ambito più ristretto preserva la larghezza di banda per dare ai team client lo spazio per prepararsi alla più ampia transizione architetturale.

[CL] Emissione

Intenzionalmente non assegniamo un tier a EIP-8363: Tapered Issuance Burn. Pensiamo che l'emissione non sia una decisione che gli sviluppatori core dovrebbero prendere da soli, e una lista di tier è una raccomandazione esplicita agli sviluppatori core. Per la maggior parte degli EIP, il processo ACD funziona bene perché le decisioni sono principalmente tecniche e la comunità ha effettivamente delegato queste decisioni agli sviluppatori core. L'emissione è diversa in quanto è una questione di politica monetaria su cui la comunità stessa deve raggiungere un consenso approssimativo. Le opinioni degli sviluppatori core contano, ma come input per quella discussione pubblica. Classificare EIP-8363 insieme agli altri EIP lo tratterebbe come una normale decisione ACD, cosa che riteniamo non dovrebbe essere.

Tecnicamente, vediamo del merito nel cambiare l'emissione in linea con EIP-8363. I problemi che affronta sono reali: la credibilità dello slashing si erode man mano che più ETH viene messo in staking, alti rapporti di staking significano che le ricompense compensano principalmente la diluizione, e le economie di scala continuano ad ampliare il divario tra i grandi operatori e gli staker solitari. Un cambiamento comporta anche dei rischi, dall'incertezza degli effetti sulla distribuzione dello stake al resettare l'orologio dell'ossificazione della politica monetaria. Il thread di Ansgar espone entrambi i lati e riflette la nostra posizione. Alcuni di noi hanno sostenuto cambiamenti all'emissione in passato e continuano ad avere convinzione in quel percorso.

Raccomandiamo di prendere la decisione sull'emissione dopo tutte le altre decisioni sull'ambito di Hegotá. Questo dà alla discussione della comunità il tempo necessario ed evita di distrarre dal processo di definizione dell'ambito stesso.

[CL] Funzionalità di staking

I miglioramenti allo staking possono essere preziosi, ma i benefici per l'utente finale dovrebbero avere la priorità rispetto ai cambiamenti infrastrutturali, a meno che non siano strettamente necessari.

[CL] EIP-8015: Remove deposit and eth1data fields [Tier A]

• Pulizia molto semplice del debito tecnico. Grazie a EIP-7688: Forward compatible consensus data structures, le prove Merkle di campi non correlati non sono influenzate, quindi nessun impatto sui consumatori della catena.

[EL][CL] EIP-8237: Independent CL/EL Sync [Tier B]

• Si basa sulla separazione del blocco beacon e del payload introdotta da ePBS, per consentire all'EL e al CL di sincronizzarsi in modo indipendente. Pensiamo che questo abbia il potenziale per semplificare una parte complessa dei client Ethereum.

[CL] EIP-8205: Withdrawal credentials preregistration [Tier D]

• Raccomandiamo di respingere. Sebbene l'EIP fornisca una soluzione in-protocollo per un problema reale nello staking delegato, pensiamo che la soluzione pre-deposito esistente sia adeguata e che la complessità dei meccanismi aggiunti non sia attualmente giustificata.

[CL] EIP-8148: Custom sweep threshold for validators [Tier D]

• Raccomandiamo di respingere. Pensiamo che l'EIP sia troppo complesso (nuovo contratto di sistema, nuova richiesta di esecuzione, meccanismi CL) per i suoi benefici, che vediamo principalmente come un incoraggiamento a un po' di consolidamento marginale aggiuntivo dal pool di operatori domestici. Non pensiamo che questo avrà molto effetto sul consolidamento complessivo dei validatori data la distribuzione dello stake.

[CL] EIP-8375: ePBS Mandatory Burn of Execution Rewards [Tier D]

• Raccomandiamo di respingere. Pensiamo che questo probabilmente porterà solo a più canali laterali. Inoltre, anni di discussioni sulle strategie di burn MEV non hanno portato a nessuna proposta che abbia raggiunto un ampio consenso di ricerca.

[CL] EIP-7716: Anti-correlation attestation penalties [Tier D]

• Raccomandiamo di respingere. Non pensiamo ci siano prove abbastanza chiare che un cambiamento così grande negli incentivi allo staking sia giustificato. Inoltre, gli incentivi allo staking saranno probabilmente rielaborati come parte del consenso disaccoppiato.

[CL] EIP-8333: Align Checkpoint with Epoch Boundary Block [Tier D]

• Raccomandiamo di respingere. Sebbene sia una bella pulizia, pensiamo valga la pena rimandarla alla grande transizione imminente del consenso disaccoppiato.

[CL] EIP-8359: Beacon Block Reporting Field [formazione opinione]

[CL] Ulteriore preparazione PQ

Queste proposte riducono le rimanenti dipendenze BLS in vista di una futura transizione post-quantistica.

[CL] EIP-8365: BLS withdrawal credential retirement [Tier A]

• Ritira una credenziale di prelievo legacy, preparando il terreno per semplificazioni del protocollo e semplificando la futura transizione PQ.
• Data la sua semplicità, pensiamo valga la pena includerlo ora.

[CL] EIP-8367: Balance sunset for retired BLS validators [Tier D]

• Raccomandiamo di respingere. Pensiamo sia probabile che la maggior parte dei validatori 0x0 effettui un cambio di credenziale (BLSToExecutionChange) prima o dopo l'attivazione di EIP-8365: BLS withdrawal credential retirement, sia per ritirare i propri fondi sia per poter continuare a fare staking. Non pensiamo ci sia grande urgenza di introdurre un meccanismo per gestire il restante stake 0x0. Raccomandiamo di includere solo EIP-8365 e vedere il risultato prima di decidere i prossimi passi.

[CL] EIP-8321: Hash-Chain RANDAO [Tier D]

• Raccomandiamo di respingere. Rendere RANDAO post-quantistico sicuro in isolamento fornisce poca sicurezza a livello di protocollo mentre le chiavi BLS dei validatori rimangono vulnerabili, ma aggiunge circa 32 byte per validatore, nuovi meccanismi di gestione dei segreti e un meccanismo in gran parte monouso. Il design più ampio del consenso PQ rimane incerto. Supportiamo una transizione iterativa, ma il suo primo passo dovrebbe seguire una roadmap concordata piuttosto che rischiare di essere superato dal design finale.

[EL][CL] Preparazione zkEVM

La maggior parte della preparazione zkEVM offre benefici a breve termine limitati, al di là di rendere l'operatività del nodo completo più facile per un insieme ristretto di utenti, consumando al contempo larghezza di banda di implementazione e potenzialmente rendendo l'EVM più costoso. Dovremmo includere solo quei cambiamenti il cui valore a lungo termine giustifichi chiaramente questi costi immediati.

[CL] EIP-8025: Optional Execution Proofs [Tier D]

• L'EIP non richiede un hard fork. La proposta di raggrupparlo con Hegota è puramente un'espressione di priorità, e siamo in disaccordo con quella scelta. Pensiamo che il lavoro dovrebbe continuare su di esso, ma Hegotá non dovrebbe essere bloccato da questo.
• Prima di rilasciare prove opzionali, dovremmo prima lavorare per definire lo stato finale, poi accelerare verso quello, piuttosto che rilasciare prove opzionali prima di una visione chiara del modello validatore/stato a lungo termine.
• La domanda aperta fondamentale è quale ruolo dovrebbero avere i validatori rispetto allo stato: se dovrebbero continuare a servire o detenere parte di esso, piuttosto che diventare completamente stateless. Poiché i validatori sono una coorte di nodi core con hardware reale e valore di rete, i cambiamenti che indeboliscono quel ruolo dovrebbero superare uno standard più elevato.

[EL] EIP-7666: EVM-ify the identity precompile [Tier A]

• utile, piccolo cambiamento

[EL] EIP-8200: EVMification [Tier B]

• EIP-8200 sostituisce tre precompile native con bytecode EVM equivalente. Due vedono poco utilizzo e sembrano semplici da migrare. La terza è ampiamente utilizzata nella verifica SNARK, quindi vorremmo una valutazione dell'impatto prima di supportarne la rimozione.
• Se l'analisi dell'impatto trova bassi costi di migrazione per gli utenti interessati, o se la terza precompile viene rimossa dall'ambito, sposteremmo EIP-8200 al [Tier A].

[EL] EIP-7709: Read BLOCKHASH from Storage and Update Cost [Tier D]

• Abbastanza dirompente a causa del grandissimo aumento del costo del gas, non urgente
• Mitigare il rischio potrebbe comportare un'analisi dell'impatto, o farlo in seguito con una qualche forma di riscaldamento a livello di blocco (o riscaldamento ad-hoc di questi valori) per ridurre l'impatto.

[EL] EIP-8268: Storage Roots in Block Access Lists [Tier B]

• Potrebbe aver bisogno di un'analisi dell'impatto concreto sulle dimensioni dei BAL e sul relativo impatto sui costi delle transazioni (EIP-8279 propone di addebitare i byte BAL), poiché la voce BAL per ogni account toccato ottiene una radice di trie di storage aggiuntiva.

[EL] Funzionalità EVM

Hegotá richiederà ancora alcune decisioni EVM ad hoc. Crediamo che dopo Hegotá Ethereum dovrebbe lavorare verso una roadmap EVM a lungo termine modellata dal più ampio ecosistema EVM. Ethlabs contribuirà a questo.

[EL] EIP-5920: PAY opcode [Tier A]

• Molto semplice, e pensiamo sia un buon primitivo per l'EVM da avere
• Sarebbe importante comprendere meglio i casi d'uso concreti

[EL] EIP-8163: Reserve EXTENSION (0xae) opcode [Tier A]

• Molto utile per le L2, nessun costo reale per L1 (solo informativo)

[EL] Riutilizzo / deduplicazione del codice [Tier B]

• EIP-8058: Contract Bytecode Deduplication Discount e EIP-8298: SETCODEFROM Code Reuse Instruction cercano entrambi di sfruttare il fatto che il codice del contratto è memorizzato separatamente dall'account corrispondente nei client, con l'hash del codice come puntatore tra di loro. Quindi il codice condiviso identico può essere memorizzato deduplicato. Entrambi gli EIP consentono un modo per impostare a buon mercato l'hash del codice dell'account sull'hash di un codice esistente altrove.
• Consideriamo questa un'idea generale attraente, ma sarebbe importante comprenderne le implicazioni e la compatibilità futura con gli alberi binari. Nessuna preferenza per ora tra i due.

[EL] Riforma dei prezzi della memoria [Tier B]

• Dobbiamo decidere se vogliamo o meno fare una riforma della memoria in Hegota. Non ci è chiaro se abbiamo attualmente una comprensione sufficiente dello spazio di progettazione per fare questa valutazione.

EIP-7686: Linear EVM memory limits

• Cambiamento più piccolo, elimina semplicemente il costo di espansione della memoria quadratica.

EIP-7923: Linear, Page-Based Memory Costing

• Rielaborazione più profonda e più basata su principi, ma più complessa.

[EL] EIP-8219: Checked Arithmetic Opcodes [Tier B]

• In generale, aggiungere la matematica sicura all'EVM sembra utile.
• Il prezzo dovrebbe essere confermato con benchmark, quanto è complesso?
• Con benchmark e un'analisi dell'impatto (quante transazioni potrebbero beneficiare, quanto, quali compilatori aggiungerebbero supporto?) potrebbe essere Tier A.

[EL] EIP-8360: TCREATE Opcode [Tier B]

• L'EIP introduce la capacità di creare contratti temporanei con ambito di transazione. Questo è un buon primitivo da avere in generale.
• L'EIP aggiunge una complessità significativa. Con una valutazione più approfondita della complessità di implementazione e test, potrebbe essere Tier A.

[EL] EIP-7645: Alias ORIGIN to SENDER [Tier D]

• Raccomandiamo di respingere: Cambiamento di rottura, uso improprio di ORIGIN.

[EL] EIP-8182: Private ETH and ERC-20 Transfers [Tier D]

• Raccomandiamo di respingere: Cambiamento enorme, aggiunge dipendenze zk. Se mai introdotto, pensiamo dovrebbe essere un headliner.

[EL] EIP-2488: Deprecate the CALLCODE opcode [formazione opinione]

[EL] EIP-4758: Deactivate SELFDESTRUCT [formazione opinione]

[EL] EIP-7979: Call and Return Opcodes for the EVM [formazione opinione]

[EL] EIP-8173: Foundations of EVM Control Flow [formazione opinione]

[EL] EIP-8253: Bump nonce of zero-nonce storage accounts [formazione opinione]

[EL] EIP-8030: P256 algorithm support [formazione opinione]

[EL] Prezzi EVM

Glamsterdam ha aumentato i prezzi per le operazioni sottoprezzate che limitavano la produttività complessiva. Le proposte di prezzo EVM di Hegotá affrontano principalmente l'altro lato: abbassare i prezzi per le singole operazioni il cui costo attuale ne limita l'uso, ma non la scalabilità della rete. Questi sono quindi piacevoli da avere con un impatto per-EIP inferiore. Siamo aperti a riprezzature mirate, ma le proposte che introducono nuovi meccanismi di misurazione dovrebbero essere incluse solo se il loro design è solido e sufficientemente derisked da un campione impegnato.

[EL] EIP-8358: Net Gas Metering for Account Changes [Tier B]

• Non convinti dell'impatto. In 900 blocchi mainnet campionati, ~400k transazioni: il 2.07% di tutte le transazioni risparmierebbe gas e l'1.14% del gas del blocco verrebbe risparmiato

[EL] EIP-7973: Warm Account Write Metering [formazione opinione]

[EL] EIP-7609: Decrease base cost of TLOAD/TSTORE [formazione opinione]

[EL] EIP-7971: Hard Limits for Transient Storage [formazione opinione]

[EL] EIP-3298: Removal of refunds [formazione opinione]

[EL] EIP-8374: Persist Warm Access Sets Across Reverts [formazione opinione]

[EL] EIP-8115: Batch priority fees at end of block [formazione opinione]

[EL] EIP-8188: Last-Written Block for Accounts and Slots [formazione opinione]

[EL][CL] Dati di esecuzione e indicizzazione

[EL][CL] EIP-7668: Remove bloom filters [formazione opinione]

[EL][CL] EIP-7807: SSZ execution blocks [formazione opinione]

[EL] EIP-8116: Replace cumulative receipt fields [formazione opinione]

[EL] EIP-8304: Trustless log and transaction index [formazione opinione]

[EL][CL] Networking

Il livello P2P di Ethereum ha spazio per miglioramenti mirati, specialmente nel modo in cui transazioni, blob e attestazioni vengono propagati attraverso la rete.

[CL] EIP-8371: RowDAS - Distributed Blob Reconstruction [Tier A]

• Generalmente impedisce che la ricostruzione completa e le prestazioni del nodo di custodia completa diventino un collo di bottiglia per la scalabilità del conteggio dei blob.
• Prezioso, prima o poi una qualche forma di ricostruzione distribuita dovrebbe sicuramente farsi strada nel protocollo. Questo potrebbe permetterci di rimuovere la custodia del validatore
• Necessità di comprendere meglio la complessità

[CL] EIP-8142: Block-in-Blobs (BiB) [Tier D]

• Prematuro, nessuna forte urgenza, abbastanza last minute, molte domande rimaste (KZG o no? Nuovi argomenti gossip o no?).
• Non vogliamo introdurre KZG nel percorso critico della produzione di blocchi, le alternative non sono chiare e aggiungerebbero ulteriore complessità.

[CL] EIP-8243: Batching Attestations at Source [Tier D]

• Non chiaro se possiamo fare affidamento su questo per diminuire il tempo per la finalità, non mette un limite chiaro al carico.
• La resistenza DoS del meccanismo non è del tutto chiara.

[EL] EIP-8077: eth/XX - announce transactions with nonce [formazione opinione]

[EL] EIP-8094: eth/vhash - Blob-Aware Mempool [formazione opinione]

[CL] EIP-8334: Bundled Attestation Propagation [formazione opinione]

Se sei ancora con noi in qualche modo, grazie per aver letto fino alla fine. Sentiti libero di rispondere con qualsiasi domanda, e faremo del nostro meglio per risponderti! Se hai saltato e sei semplicemente scorso qui perché leggere un muro gigantesco di testo non era il modo in cui hai deciso di passare la tua domenica, troverai piacere nel sapere che questa prossima parte è breve.

Ancora (qualche) parola...

Gli aggiornamenti di Ethereum sono complessi perché la posta in gioco è alta. Migliaia di nodi in tutto il mondo passano a nuove regole nello stesso slot, e la rete non si ferma nemmeno per un secondo mentre lo fanno. Quel rigore ha accompagnato ogni aggiornamento che Ethereum ha rilasciato, risultando in una rete decentralizzata che ha celebrato 11 anni di uptime al 100%.

Le nostre posizioni su Hegotá sono le nostre migliori valutazioni ad oggi, ma aggiorneremo il nostro pensiero ogni volta che nuove prove da discussioni o lavori di implementazione cambieranno la nostra visione.

Alcuni di questi EIP sono stati scritti o promossi da membri di Ethlabs, altri provengono dall'incredibilmente vasto, talentuoso e ben intenzionato gruppo di ricercatori, sviluppatori client e contributori individuali in tutto l'ecosistema Ethereum. Tuttavia, tutti richiederanno collaborazione tra team client, wallet, applicazioni, L2, fornitori di infrastrutture, istituzioni, operatori di nodi e, in ultima analisi, utenti per avere successo. Ethereum è il progetto condiviso del mondo, e il progresso significativo della rete non è mai il lavoro di una singola organizzazione.

Siamo grati di essere una piccola parte di questo ecosistema, e non vediamo l'ora di aiutare Ethereum a realizzare il suo potenziale.

– Ethlabs