Scritto da Christine Kim

Compilato da: Luccy, BlockBeats

Nota dell'editore: l'All Core Developers Consensus Call (ACDC) di Ethereum si tiene ogni due settimane per discutere e coordinare le modifiche all'Ethereum Consensus Layer (CL). Questa è la 135a teleconferenza ACDC. Questa conferenza si concentra principalmente sulla preparazione della rete di test di Pectra Devnet 1, PeerDAS Devnet 1 e Simple Serialize (SSZ) Ethereum Improvement Proposals (EIP).

Gli sviluppatori hanno avuto discussioni approfondite su questioni come la manutenzione dei pacchetti software, i processi di inclusione EIP e la denominazione del nuovo ciclo di aggiornamenti del livello di consenso di Ethereum. Inoltre, la sessione ha toccato i progressi nell'implementazione della specifica Electra, l'impatto dei cambiamenti della rete PeerDAS sul modo in cui i nodi Ethereum elaborano e convalidano i dati e le complesse questioni ingegneristiche relative all'aumento dei limiti di blob gas.

Christine Kim, vicepresidente della ricerca presso Galaxy Digital, ha registrato in dettaglio i punti chiave di questo incontro. BlockBeasts ha compilato il testo originale come segue:

Il 13 giugno 2024, gli sviluppatori di Ethereum si sono riuniti su Zoom per l'incontro#135dell'All Core Developers Consensus (ACDC). La chiamata ACDC è una serie bisettimanale ospitata dal ricercatore della Ethereum Foundation Alex Stokes in cui gli sviluppatori discutono e coordinano le modifiche all'Ethereum Consensus Layer (CL, noto anche come Beacon Chain). Questa settimana, gli sviluppatori hanno discusso dei preparativi per Pectra Devnet 1, PeerDAS Devnet 1 e una terza rete di test dedicata per le proposte di miglioramento Ethereum (EIP) Simple Serialize (SSZ).

annuncio

Gli sviluppatori hanno dato il via all'incontro con due annunci. L'ingegnere DevOps della Ethereum Foundation Parithosh Jayanthi ha affermato che il team ethPandaOps, un gruppo di ingegneri che lavora in Ethereum Foundation DevOps (EF DevOps), si occuperà della manutenzione e dello sviluppo del modulo Kurtosis del pacchetto ethereum. Questo pacchetto è stato utilizzato dagli sviluppatori in passato per lanciare reti di test Ethereum e strumenti correlati, come il dashboard dei dati Grafana per monitorare e testare varie implementazioni client. La migrazione di questo pacchetto dal team tecnico di Kurtosis al team ethPandaOps potrebbe avere un impatto sugli utenti poiché alcuni collegamenti verranno reindirizzati ai repository GitHub gestiti dal team ethPandaOps e non più dal team Kurtosis. Jayanthi consiglia agli utenti di aggiornare i collegamenti software e di tenere d'occhio le nuove versioni del team ethPandaOps.

Il secondo annuncio è stato fatto da Tim Beiko, responsabile del supporto al protocollo presso la Fondazione Ethereum. Beiko ha detto che sta lavorando per introdurre gradualmente un nuovo processo per includere gli EIP negli aggiornamenti di Ethereum. Ha creato una bozza dell'EIP che definisce le etichette "Proposto per l'inclusione", "Considerato per l'inclusione" e "Previsto per l'inclusione". Spera che gli sviluppatori esaminino il documento e forniscano feedback. Spera di completare il documento prima della prossima riunione dell'ACD.

Elettra

Le specifiche del codice per la prossima versione principale di Electra, v1.5.0-alpha.3, sono quasi complete. Gli sviluppatori hanno concordato di unire la richiesta pull (PR) n. 3768 nel repository GitHub delle specifiche di consenso nella versione successiva. La richiesta pull è stata creata dallo sviluppatore Nimbus Etan Kissling, che ha sottolineato che il campo "committee_bits" dovrebbe essere aggiunto alla fine dell'"Attestato" anziché al centro dei dati per evitare problemi di serializzazione dei dati. Oltre al PR n. 3768, Stokes ha chiesto se ci sono altri problemi aperti che devono essere risolti prima che venga rilasciata la prossima versione principale delle specifiche Electra. Jayanthi ha menzionato nella chat di Zoom che ci sono alcuni problemi in sospeso con l'integrazione dei validatori attivati ​​tramite il livello di esecuzione (EL). Stokes ha preso nota di dare seguito allo stato dell'integrazione del validatore attivato da EL dopo l'incontro.

Per quanto riguarda i progressi nell'implementazione dell'ultima specifica Electra, la maggior parte dei team clienti del livello di consenso (CL) presenti alla riunione hanno dichiarato che saranno in grado di avere la nuova versione pronta per il test entro una o due settimane dopo la versione v1.5.0-alpha.3 è finalizzato. Gli sviluppatori hanno concordato di rivedere i tempi della prossima rete di sviluppo Pectra, Pectra Devnet 1, tra poche settimane.

PeerDAS

Successivamente, gli sviluppatori hanno discusso i progressi nell'implementazione di PeerDAS. PeerDAS è un miglioramento della rete Ethereum che migliorerà la capacità dei nodi di elaborare e verificare grandi quantità di dati arbitrari inviati dagli utenti tramite transazioni blob. Stokes ha ricordato la decisione presa nell'ultimo incontro dell'ACDC secondo cui gli sviluppatori avrebbero sviluppato PeerDAS in parallelo con altri Pectra EIP, attivando un ciclo di attivazione separato per PeerDAS sulla rete di sviluppo.

Lo sviluppatore di Lodestar Gajinder Singh ha affermato che, sulla base delle discussioni avvenute in una recente sessione di discussione su PeerDAS, gli sviluppatori attiveranno PeerDAS oltre all'aggiornamento di Deneb e su una rete di sviluppo separata da altri Pectra EIP. Lo sviluppatore Teku Enrico Del Fante ha affermato che sarebbe più semplice per gli sviluppatori creare PeerDAS sulle specifiche del codice stabile già stabilite nel precedente aggiornamento di Ethereum Deneb, piuttosto che sulle specifiche del codice Pectra in continua evoluzione. Jayanthi ha convenuto che l'unione dell'implementazione PeerDAS con altre implementazioni Pectra EIP potrebbe causare complicazioni durante i test, soprattutto quando si cerca di individuare la fonte degli errori. Ha suggerito di mantenere separati i due flussi di lavoro e di unirli una volta che le loro implementazioni saranno più stabili. Stokes è d'accordo, affermando che gli sviluppatori potrebbero rivedere la fusione di PeerDAS e altre implementazioni Pectra EIP in circa un mese.

Per quanto riguarda il lancio di PeerDAS Devnet 1, il team del cliente non ha una stima chiara su quando la testnet sarà pronta per il lancio. Le stime individuali durante le sessioni variavano approssimativamente da 2 settimane a 1 mese. Stokes ha suggerito di rivedere la tempistica per lo sviluppo della rete tra poche settimane, quando il team del cliente avrà più tempo per lavorare sull'implementazione PeerDAS.

Beiko ha poi sottolineato che, sebbene PeerDAS sia un miglioramento della rete piuttosto che una modifica al protocollo principale di Ethereum, desidera comunque che le modifiche al codice siano incluse nel meta-EIP per l'aggiornamento di Pectra. Il documento meta-EIP è un documento pubblico che elenca tutte le modifiche al protocollo principale incluse nell'aggiornamento di Ethereum. Beiko ha sottolineato che PeerDAS è la "caratteristica più importante" di Pectra e, sebbene non richieda un'attivazione hard fork, dovrebbe comunque essere incluso nella documentazione per dimostrare che gli sviluppatori sono seriamente intenzionati a averlo pronto in tempo per l'attivazione della mainnet di Pectra. Nessuna obiezione a questo.

Aumenta il limite del gas del blob

PeerDAS cambia il modo in cui i nodi elaborano e propagano i dati attraverso il livello di rete peer-to-peer di Ethereum. Affinché gli utenti, in particolare i rollup Layer-2, possano beneficiare di queste modifiche, gli sviluppatori devono aumentare il limite attuale di sei BLOB per blocco a una soglia più alta, che consentirà un throughput di BLOB (dati arbitrari) più elevato. La modifica del limite del blob richiederebbe modifiche al protocollo principale di Ethereum che, come hanno discusso gli sviluppatori in una conferenza questa settimana, potrebbe comportare un lavoro di ingegneria più complesso rispetto alla semplice modifica di un valore costante nello stack del protocollo.

Stokes ha proposto di disaccoppiare le dipendenze tra il livello di esecuzione (EL) e il livello di consenso (CL) quando si modificano i limiti del blob gas. Attualmente, qualsiasi modifica ai limiti del blob gas richiede modifiche ai protocolli EL e CL. Stokes ha proposto modi per interrompere queste dipendenze, consentendo agli sviluppatori di rimuovere in modo sicuro i limiti di gas blob codificati da EL e lasciarli interamente alla CL. Dankrad Feist, ricercatore della Ethereum Foundation (EF), ha sottolineato che oltre al problema della dipendenza tra EL e CL, è importante anche l'effetto a catena della modifica del limite del blob gas sul calcolo del gas del blocco. "L'approccio migliore è cambiare il modo in cui viene calcolato", ha detto Feist. "Probabilmente è un bug che il calcolo del prezzo del gas avvenga in EL. Dovrebbe essere in CL, ma ora è più difficile cambiare... Non è facile. "

Gli sviluppatori hanno concordato di continuare a studiare il modo migliore per apportare modifiche ai limiti del gas blob e ai calcoli del gas in blocchi. Gli sviluppatori hanno inoltre concordato di continuare a discutere se l'attivazione di PeerDAS in Pectra sarà accompagnata da un aumento del limite del blob gas. Gli sviluppatori sono divisi sulla questione se le modifiche debbano essere implementate insieme o implementate in più fasi su più hard fork.

Jayanthi ha affermato che incorporare queste modifiche è stata una decisione “rischiosa” perché gli sviluppatori non sapranno esattamente come funzionerà PeerDAS finché non verrà attivato sulla rete principale. Barnabas Busa, ingegnere DevOps della Ethereum Foundation (EF), ha aggiunto che l'ambito dell'hard fork Pectra è già molto ampio e non richiede ulteriori modifiche al codice. "La chiave è che abbiamo già molti EIP e sento che continueremo ad aggiungerne altri e non finirà mai", ha detto Busa "Quindi, dobbiamo tracciare una linea da qualche parte ed è lì che finiamo. Penso che non lo sia possibile rilasciare PeerDAS e aumentare il numero di blob durante il prossimo anno e mezzo di test."

Uno sviluppatore il cui screen name è "Francesco" ha suggerito che se i cambiamenti della rete non sono accompagnati da un aumento del numero di blob, PeerDAS può essere rimosso per "ridurre il rischio di Pectra". Francesco ha chiesto: “Qual è esattamente il vantaggio del PeerDAS di Pectra se non aumenta il numero di blob?”

Per illustrare ulteriormente la difficoltà di testare PeerDAS, Jayanthi ha sottolineato che il test di EIP 4844, che ha introdotto i blob su Ethereum, non ha simulato completamente le prestazioni effettive e l'impatto dei blob sulla rete principale di Ethereum. Jayanthi ha detto: “Il problema è che è molto difficile testare la rete. Abbiamo fatto molti ottimi test relativi a 4844, ma i blob non hanno funzionato esattamente come nei test che abbiamo visto emergono nodi più deboli. Domanda. Vediamo sfide temporali e cose del genere, motivo per cui anche se possiamo simulare una situazione perfetta nella rete di sviluppo in cui PeerDAS e l'aumento del numero di blob funzionano, non ha alcuna implicazione pratica per the mainnet Significato, questo è il motivo principale per cui penso che dovremmo farlo passo dopo passo invece di farlo tutto in una volta.

Il ricercatore EF Ansgar Dietrichs ha commentato che è un errore associare l'aumento del conteggio dei blob a PeerDAS, poiché PeerDAS da solo richiede già agli sviluppatori di scegliere un valore di conteggio dei blob. Mentre gli sviluppatori possono scegliere lo stesso numero della rete principale di Ethereum, è necessario prendere una decisione su quale numero PeerDAS dovrebbe utilizzare. L'unico motivo per cui è stato scelto lo stesso numero è che gli sviluppatori hanno aumentato la complessità di PeerDAS per consentirgli di ricorrere al meccanismo di propagazione dei blob nell'attuale specifica Deneb in caso di errore. Dietrichs ha aggiunto che le preoccupazioni sulla complessità dei test rafforzano ulteriormente la sua opinione secondo cui Pectra dovrebbe essere attivato tramite due hard fork anziché uno, ma ciò non significa che pensa che PeerDAS dovrebbe essere disaccoppiato dalle modifiche al conteggio dei blob.

Aggiornamento SSZ

Kissling ha condiviso un aggiornamento sui progressi su tre EIP relativi alla SSZ. Ha osservato che l'implementazione di questi EIP è già in corso su diversi clienti, tra cui Teku, Grandine e Lighthouse. Gli sviluppatori possono iniziare a discutere la tempistica della rete di sviluppo per questi EIP SSZ ed eventualmente includerli nell'ambito dell'aggiornamento Pectra al prossimo incontro ACDC, ha affermato.

Denominazione F-Star

C'è un post su Ethereum Magicians che discute il nome del prossimo aggiornamento del livello di consenso di Ethereum (CL) dopo Electra. Gli sviluppatori hanno deciso un nome per l'aggiornamento del livello executive (EL) dopo Praga: Osaka. I nomi degli aggiornamenti CL candidati sono: Fulu, Felis, Formosa e Funi. Questi nomi seguono tutti la principale convenzione di denominazione delle stelle che inizia con "F" e sono adatti per il sesto aggiornamento a livello di rete di Beacon Chain. Stokes ha chiesto agli sviluppatori durante la chiamata di valutare l'argomento nel thread Magicians.