Riepilogo dell'ultimo incontro del dirigente dello sviluppatore Ethereum Core: nuova specifica del codice CL, condizioni di lancio di Devnet-10 e analisi della latenza dei blocchi

 Titolo originale: "Ethereum All Core Developers Consensus Call#120Writeup"
 Autore originale: Christine Kim
 Compilation originale: Lucy, BlockBeats
ultimo incontro
Il 19 ottobre, gli sviluppatori di Ethereum si sono riuniti su Zoom per l'incontro#120dell'All Core Developers Execution (ACDE). La ACDE Conference Call è una serie bisettimanale di incontri ospitati dal ricercatore della Ethereum Foundation Danny Ryan, in cui gli sviluppatori discutono e coordinano le modifiche all'Ethereum Consensus Layer (CL). Questa settimana, gli sviluppatori si concentreranno sullo stato di avanzamento dei seguenti argomenti:
1. Versione 1.4.0-beta.3 della specifica CL;
2. Condizioni di avvio di Devnet-10;
3. Analisi della latenza dei blob di Gajinder Singh, uno sviluppatore di software che gestisce i client Lodestar ed EthereumJS.
L'Evocazione
Danny Ryan ha annunciato il rilascio di una nuova specifica del codice CL per l'aggiornamento Cancun/Deneb (Dencun), chiamato "Summoning". Questa versione è ufficialmente contrassegnata come versione 1.4.0-beta.3 nel repository CL GitHub e contiene due modifiche principali:
1. Configurazione Mainnet KZG: completato il lavoro di formattazione richiesto per l'output della cerimonia di installazione affidabile di Ethereum e incluso nell'ultima versione delle specifiche CL.
2. Nuova regola di gossip: lo sviluppatore di Teku Enrico Del Fante ha creato una nuova regola di gossip per garantire che i nodi CL non si propaghino più del numero massimo di blob per blocco, attualmente definito nelle specifiche. La quantità è sei. Ciò garantirà che i validatori non possano inviare spam alla rete con messaggi non validi che superano i sei BLOB per blocco.
Devnet-10
Le modifiche alla versione 1.4.0-beta.3 delle specifiche CL verranno testate sulla prossima rete di sviluppo, Devnet-10. Tuttavia, ci sono alcuni ostacoli per far decollare Devnet-10. Barnabas Busa, un ingegnere DevOps presso la Ethereum Foundation, ha affermato che sta ancora aspettando che il team del cliente rilasci una nuova versione del software. Una volta che questi saranno pronti, Busa spera di lanciare la prossima rete di sviluppo martedì 20 ottobre.
Uno sviluppatore del client Prysm utilizzando lo pseudonimo "Potuz" ha sottolineato che la configurazione KZG della rete principale inclusa nell'ultima specifica CL non può essere unita a Geth e Prysm finché non vengono apportate modifiche a "go-kzg". "go-kzg" è un repository di codice separato che implementa lo schema di impegno KZG nel linguaggio di programmazione Go. Gli sviluppatori hanno espresso frustrazione per la chiamata con le dipendenze tra i repository go-kzg, Geth e Prysm. Questa non è la prima volta che Potuz e altri sviluppatori sollevano sfide relative all'utilizzo della libreria KZG per EIP 4844.
Parithosh Jayanthi, un ingegnere DevOps presso la Ethereum Foundation, ha affermato che gli sviluppatori possono lanciare Devnet-10 senza la configurazione KZG della mainnet e il nuovo rilascio del client, ma ciò significa che gli sviluppatori non testeranno alcun nuovo codice su Devnet-10, ma testeranno invece nuovamente quello rilasciato. codice su Devnet-9.
Questa settimana su Devnet-9, gli sviluppatori hanno scoperto un problema nell'implementazione del client CL. Mario Vega del team di test della Ethereum Foundation ha spiegato che i validatori non sono riusciti a gestire correttamente i blocchi di dati non validi (BLOB). Vega ha affermato che se un validatore trasmette maliziosamente blocchi di dati validi ad alcuni nodi e blocchi di dati non validi ad altri nodi, i nodi che ricevono i blocchi di dati non validi non saranno in grado di tracciare l'inizio della catena. Per risolvere questo problema, è stato creato un test hive per replicare facilmente queste condizioni e testarle rispetto alle nuove versioni del client. Ciò consentirà agli sviluppatori di vedere immediatamente se la soluzione al problema funziona.
Riguardo a questo problema, Enrico Del Fante ha affermato che in alcuni casi, quando un blocco contiene uno o più blob con indici che non corrispondono agli impegni blob esistenti nel blocco, il client Teku non importerà il blocco. Dankrad Feist, ricercatore presso la Ethereum Foundation, ha sottolineato che i validatori che propongono deliberatamente blocchi contenenti blob non validi non hanno altri vantaggi oltre ad aumentare potenzialmente il carico computazionale sulla rete peer-to-peer di Ethereum e far sì che alcuni validatori che ricevono i blocchi perdano la sincronizzazione con la rete. Feist ha sottolineato che non vi è alcun guadagno finanziario da tale comportamento e, anche se i validatori lo facessero, il carico computazionale aggiuntivo sul livello peer-to-peer di Ethereum sarebbe limitato dal numero massimo di blob per blocco.
Tuttavia, per impedire ai validatori di intraprendere questa azione, gli sviluppatori stanno discutendo la possibilità di aggiungere una nuova condizione di taglio. La nuova condizione di taglio tenterà di monitorare i blocchi per l'inclusione di BLOB non validi per impedire ai validatori di stressare deliberatamente il livello peer-to-peer. Tuttavia, a causa degli elevati costi di ricerca e analisi necessari per modificare l’economia del validatore di Ethereum, Ryan ha suggerito di discutere ulteriormente questa proposta nel contesto di Praga/Electra, il prossimo aggiornamento dopo Dencun.
Ryan ha aggiunto che gli sviluppatori possono impostare un comportamento appropriato per questa situazione nella specifica CL di Dencun e che i validatori dovrebbero comunque importare blocchi anche se l'indice BLOB non corrisponde all'impegno del blocco. Ha sostenuto che, poiché i validatori non hanno incentivi finanziari per propagare blocchi contenenti blob non validi nel modo descritto da Del Fante, il potenziale carico di rete derivante da tale comportamento irrazionale è limitato al massimo dal numero massimo di blob per blocco. Pertanto, piccole modifiche alle specifiche CL dovrebbero essere sufficienti per risolvere il problema a breve termine, mentre gli sviluppatori possono prendere in considerazione soluzioni più permanenti per futuri aggiornamenti, come nuove condizioni di riduzione.
Jayanthi e Ryan hanno riconfermato che almeno Devnet-10 non verrà lanciato sul client Prysm finché lo sviluppatore non imposterà la configurazione KZG della mainnet sul client e non risolverà il problema sollevato da Mario Vega. Ryan ha sottolineato che le discussioni sulle nuove condizioni di riduzione erano solo nel contesto dell'aggiornamento Praga/Electra, non Dencun, e che le modifiche alle specifiche CL per l'importazione di blocchi contenenti blob non validi non dovrebbero costituire un ostacolo al lancio di Devnet-10. I rappresentanti dei team clienti di Prysm e Lighthouse hanno dichiarato che rilasceranno gli aggiornamenti per il loro software domani, 20 ottobre.
Analisi del ritardo del blocco
In una condivisione di sabato 14 ottobre, Gajinder Singh, manutentore dei clienti Ethereum Lodestar ed EthereumJS, ha condiviso una nuova analisi sulla relazione tra il numero di blob e la latenza di importazione dei blocchi basata sulla propagazione dei pettegolezzi. Singh ha osservato che nei suoi esperimenti con Devnet-9, la latenza dei blocchi aumentava in modo significativo all'aumentare del numero di blob ricevuti da un validatore.
La tabella seguente riassume i risultati di Singh. La prima colonna elenca la percentuale di blocchi completi in arrivo, mentre i valori nella tabella rappresentano il numero di secondi impiegati per importare il blocco.
 Latenza di importazione del blocco in secondi rispetto al numero di BLOB contenuti nel blocco. Fonte: Gajinder Singh, Twitter
Singh ha twittato che, sebbene avere un solo blob per blocco creerebbe una latenza trascurabile, qualsiasi numero superiore a due introdurrebbe una latenza significativa. Dankrad Feist ha affermato che i dati dell'analisi di Singh sono molto diversi dai risultati dei suoi esperimenti sulla propagazione di grandi blocchi sulla rete principale di Ethereum. "Sembra che questi dati non siano assolutamente corretti", ha affermato Feist, aggiungendo che poiché i blob vengono elaborati in parallelo con i blocchi, aggiungere ritardi di elaborazione dei blob ai tempi dei blocchi è un modo impreciso per prevedere il tempo di propagazione del blocco Mainnet. Le previsioni di Singh sulla propagazione dei blocchi con i BLOB possono essere trovate su
Singh ha affermato su Twitter che, sebbene avere un solo blob per blocco introdurrebbe una latenza trascurabile, qualsiasi numero superiore a due introdurrebbe una latenza significativa. Tuttavia, Dankrad Feist ha sottolineato che i dati dell'analisi di Singh sono significativamente diversi dai risultati dei suoi esperimenti sulla propagazione di grandi blocchi sulla rete principale di Ethereum. "Non è possibile che questi dati sembrino corretti", ha affermato Feist, aggiungendo che poiché i blob vengono elaborati in parallelo con i blocchi, aggiungere la latenza dell'elaborazione dei blob ai tempi dei blocchi per prevedere i tempi di propagazione dei blocchi sulla mainnet è un problema. Le previsioni di Singh sulla propagazione dei blocchi con i blob possono essere trovate qui. Feist ha definito l'analisi di Singh "eccessivamente pessimistica".
Nonostante le loro differenze, sia Feist che Ryan concordano sul fatto che l'analisi di Singh è davvero qualcosa da cui altri team clienti possono imparare. Ryan ha incoraggiato altri team di CL a provare a riprodurre gli esperimenti di Singh su Devnet-9 per vedere se potevano ottenere dati e risultati simili. Se ci sono nuovi dati sulla latenza dei blocchi dopo l'introduzione dei blob, Ryan ha suggerito di rivisitare l'argomento nella chiamata ACDE della prossima settimana.
"Link originale"