Původní název: "Ethereum All Core Developers Consensus Call#120Writeup"

Původní autor: Christine Kim

Původní kompilace: Luccy, BlockBeats

poslední schůzka

Dne 19. října se vývojáři Etherea sešli na konferenci Zoom na setkání All Core Developers Execution (ACDE) Call #120. Konferenční hovor ACDE je série setkání pořádaných jednou za dva týdny Dannym Ryanem, výzkumníkem nadace Ethereum, kde vývojáři diskutují a koordinují změny Ethereum Consensus Layer (CL). Tento týden se vývojáři zaměřují na pokrok v následujících tématech:

1. Verze 1.4.0-beta.3 specifikace CL;

2. Podmínky spuštění Devnet-10;

3. Analýza latence blob od Gajindera Singha, softwarového vývojáře, který spravuje klienty Lodestar a EthereumJS.

Přivolání

Danny Ryan oznámil vydání nové specifikace CL kódu pro upgrade Cancun/Deneb (Dencun), nazvaného „Summoning“. Tato verze je v repozitáři CL GitHub oficiálně označena jako verze 1.4.0-beta.3 a obsahuje dvě hlavní změny:

1. Konfigurace Mainnet KZG: Dokončení formátování požadované pro výstup Ethereum Trusted Setup Ceremony a jeho zahrnutí do nejnovější verze specifikace CL.

2. Nové pravidlo klepů: Vývojář Teku Enrico Del Fante vytvořil nové pravidlo klepů, které zajistí, že se uzly CL nebudou šířit více, než je maximální počet blobů na blok, aktuálně definovaný ve specifikaci, šest. To zajistí, že validátoři nebudou moci spamovat síť neplatnými zprávami přesahujícími šest objektů BLOB na blok.

Devnet-10

Změny ve verzi 1.4.0-beta.3 specifikace CL budou testovány na další vývojové síti Devnet-10. Existují však určité překážky, jak dostat Devnet-10 ze země. Barnabas Busa, inženýr DevOps v Ethereum Foundation, řekl, že stále čeká, až klientský tým vydá novou verzi softwaru. Jakmile budou připraveny, Busa doufá, že spustí další vývojovou síť někdy v úterý 20. října.

Vývojář klienta Prysm používající pseudonym „Potuz“ poukázal na to, že konfiguraci mainnetu KZG obsaženou v nejnovější specifikaci CL nelze začlenit do Geth a Prysm, dokud nebudou provedeny změny na „go-kzg“. "go-kzg" je samostatné úložiště kódu, které implementuje schéma závazků KZG do programovacího jazyka Go. Vývojáři vyjádřili frustraci z hovoru se závislostmi mezi repozitáři go-kzg, Geth a Prysm. Není to poprvé, co Potuz a další vývojáři vznesli výzvy týkající se použití knihovny KZG pro EIP 4844.

Parithosh Jayanthi, inženýr DevOps z Ethereum Foundation, řekl, že vývojáři mohou spustit Devnet-10 bez konfigurace mainnetu KZG a nového klienta, ale to znamená, že vývojáři nebudou testovat žádný nový kód na Devnet-10 a místo toho znovu otestují vydanou verzi. kód na Devnet-9.

Tento týden na Devnet-9 vývojáři objevili problém v implementaci klienta CL. Mario Vega z testovacího týmu Ethereum Foundation vysvětlil, že validátoři nedokázali správně zpracovat neplatné datové bloky (bloby). Vega řekl, že pokud validátor škodolibě vysílá platné datové bloky do některých uzlů a neplatné datové bloky do jiných uzlů, uzly, které přijímají neplatné datové bloky, nebudou schopny vysledovat hlavu řetězce. K vyřešení tohoto problému byl vytvořen test podregistru, který tyto podmínky snadno replikuje a testuje proti novým klientským verzím. To vývojářům umožní okamžitě zjistit, zda jejich oprava problému funguje.

V souvislosti s tímto problémem Enrico Del Fante zmínil, že v určitých případech, kdy blok obsahuje jeden nebo více objektů blob s indexy, které neodpovídají existujícím závazkům objektů blob v bloku, klient Teku blok neimportuje. Dankrad Feist, výzkumník z Ethereum Foundation, poukázal na to, že validátoři, kteří záměrně navrhují bloky obsahující neplatné bloby, nemají žádné další výhody kromě potenciálního zvýšení výpočetní zátěže sítě Ethereum peer-to-peer a toho, že někteří validátoři přijímající bloky ztratí synchronizaci. se sítí. Feist zdůraznil, že z takového chování není žádný finanční zisk, a i kdyby to validátoři udělali, další výpočetní zátěž na peer-to-peer vrstvě Etherea by byla omezena maximálním počtem blobů na blok.

Nicméně, aby zabránili validátorům v provedení této akce, vývojáři diskutují o možném přidání nové podmínky sekání. Nová podmínka sekání se pokusí monitorovat bloky pro zahrnutí neplatných objektů blob, aby zabránila validátorům v úmyslném namáhání vrstvy peer-to-peer. Vzhledem k vysokým nákladům na výzkum a analýzy potřebné ke změně ekonomiky validátoru Etherea však Ryan navrhl další diskusi o tomto návrhu v kontextu Prague/Electra, dalšího upgradu po Dencunu.

Ryan dodal, že vývojáři mohou nastavit vhodné chování pro tuto situaci ve specifikaci CL Dencunu a validátoři by měli stále importovat bloky, i když index objektů blob neodpovídá závazku bloku. Argumentoval tím, že protože validátoři nemají žádnou finanční motivaci propagovat bloky obsahující neplatné bloby způsobem popsaným Del Fantem, potenciální zatížení sítě z takového iracionálního chování je maximálně omezeno maximálním počtem blobů na blok. K vyřešení problému v krátkodobém horizontu by proto měly stačit drobné úpravy specifikace CL, zatímco vývojáři mohou uvažovat o trvalejších řešeních pro budoucí upgrady, jako jsou nové omezující podmínky.

Jayanthi a Ryan znovu potvrdili, že alespoň Devnet-10 nebude spuštěn na klientovi Prysm, dokud vývojář nenastaví konfiguraci mainnet KZG na klientovi a nevyřeší problém, který vznesl Mario Vega. Ryan zdůraznil, že diskuse o nových podmínkách omezení byly pouze v souvislosti s upgradem Prague/Electra, nikoli Dencun, a že změny specifikace CL pro import bloků obsahujících neplatné bloby by neměly být překážkou pro spuštění Devnet-10. Zástupci klientských týmů Prysm a Lighthouse uvedli, že zítra, 20. října, vydají aktualizace pro svůj software.

Analýza blokového zpoždění

Gajinder Singh, správce klientů Ethereum Lodestar a EthereumJS, v akci v sobotu 14. října sdílel novou analýzu vztahu mezi počtem blobů a latencí při importu bloků na základě šíření klepů. Singh poznamenal, že v jeho experimentech s Devnet-9 se latence bloku výrazně zvyšovala, čím vyšší byl počet blobů, které validátor obdržel.

Níže uvedená tabulka shrnuje Singhova zjištění. První sloupec uvádí procento příchozích kompletních bloků, zatímco hodnoty v tabulce představují počet sekund, které trvalo importování bloku.

Latence importu bloku v sekundách oproti počtu objektů BLOB obsažených v bloku. Zdroj: Gajinder Singh, Twitter

Singh tweetoval, že zatímco pouhý jeden blob na blok by vytvořil zanedbatelnou latenci, jakékoli číslo vyšší než dvě by způsobilo významnou latenci. Dankrad Feist řekl, že Singhova analytická data se velmi liší od výsledků jeho experimentů na šíření velkých bloků na Ethereum mainnet. "Vypadá to, že neexistuje žádný způsob, jak jsou tato data správná," tvrdil Feist a dodal, že protože bloby jsou zpracovávány paralelně s bloky, přidávání zpoždění zpracování blobu k časům bloků je nepřesný způsob, jak předpovědět dobu šíření bloků v Mainnetu. Singhovy předpovědi o šíření bloků pomocí kuliček lze nalézt na

Singh na Twitteru uvedl, že zatímco mít pouze jeden blob na blok by zavedlo zanedbatelnou latenci, jakékoli číslo vyšší než dva by přineslo významnou latenci. Dankrad Feist však poukázal na to, že Singhova analytická data se výrazně liší od výsledků jeho experimentů s šířením velkých bloků v síti Ethereum. "Neexistuje žádný způsob, jak tato data vypadat správně," tvrdil Feist a dodal, že protože bloby jsou zpracovávány paralelně s bloky, přidání latence zpracování blobu k časům bloků pro předpovídání doby šíření bloků v síti je problém. Singhovy předpovědi o šíření bloků pomocí kuliček lze nalézt zde. Feist označil Singhovu analýzu za „příliš pesimistickou“.

Navzdory rozdílům se Feist i Ryan shodují, že Singhova analýza je skutečně něco, z čeho se mohou ostatní klientské týmy poučit. Ryan povzbudil ostatní týmy CL, aby se pokusily reprodukovat Singhovy experimenty na Devnet-9, aby zjistily, zda mohou získat podobná data a výsledky. Pokud jsou k dispozici nová data o latenci bloku po zavedení blobů, Ryan navrhl znovu se podívat na toto téma na výzvě ACDE příští týden.

"Původní odkaz"