Minulý týden se něco málo přes 100 hlavních přispěvatelů Etherea sešlo za polárním kruhem – v Longyearbyenu na Špicberkách – na Soldøgn Interop: týden intenzivní práce na upgradu sítě Glamsterdam.
Soldøgn navázal na loňský Berlinterop, ale vrátil se k formátu, který použily Amphora 🏺, Edelweiss 🏔️ a Nyota ✨: jednotematický týden zaměřený na pokrok napříč více klienty směrem ke konkrétnímu upgradu – v tomto případě k posílení (hardening) Glamsterdamu.
Do pátku skupina splnila své tři hlavní cíle: shodu na spodní hranici limitu plynu po Glamsterdamu ve výši 200M, stabilní implementace ePBS běžící s externími tvůrci a finální čísla pro úpravu cen (repricing) EIP-8037. Významného pokroku bylo dosaženo také u funkcí pro Hegotá, jako je FOCIL a nativní abstrakce účtu, a u řady dalších témat.
Proč Špicberky?
Špicberky jsou jedním z mála míst na Zemi, kde může kdokoli bez ohledu na národnost žít a pracovat bez víza. Nachází se zde také Globální trezor semen (Global Seed Vault) a Arktický světový archiv (Arctic World Archive), dvě chladírenská zařízení vyhloubená v permafrostu za Longyearbyenem. Společně uchovávají zálohy plodin, knih, filmů, rukopisů a zdrojových kódů, které by lidstvo mohlo potřebovat za tisíc let, včetně Snapshotu zdrojového kódu Etherea. V neposlední řadě od konce dubna do srpna na Špicberkách nezapadá slunce. Mají 24/7 dostupnost (uptime), stejně jako Ethereum, čehož hlavní vývojáři během týdne maximálně využili!
Posílení Glamsterdamu, škálování Etherea
Cílem týdne bylo posílit implementace Glamsterdamu a odvodit cíl pro spodní hranici limitu plynu po upgradu. Bezpečné zvýšení limitu plynu je vícerozměrný problém a Glamsterdam řeší hned několik z nich: jak jsou bloky vytvářeny a navrhovány, jakou rezervu mají implementace klientů při zátěži a jak se náklady na vytvoření stavu škálují spolu s propustností.
V praxi to znamenalo zakončit týden se stabilním multi-klientským devnetem Glamsterdamu, na kterém běží nejnovější specifikace ePBS, úpravy cen a seznamy přístupů k blokům (block access lists), spolu s daty z benchmarkingu pro ukotvení důvěryhodného návrhu limitu plynu.
Většina času byla strávena usilovným psaním kódu, často až do časných ranních hodin, prokládaným pracovními skupinami (breakout sessions) za účelem sjednocení návrhových rozhodnutí a diskuse o dlouhodobějších bodech roadmapy.
Tři týmy EF (Ethereum Foundation) zajišťovaly infrastrukturu pro tento týden: EthPandaOps dodali ethIQ a panda MCP server pro podporu agentních workflow týmů; Protocol Support nastavili soldogn.xyz jako jediný zdroj pravdy pro cíle interopu, harmonogram a poznámky; a tým EF Digital Studio zachytil celý týden na film. Očekávejte vůbec první dokument o interopu 🔜!
ePBS
Kromě vyjasnění vztahu mezi navrhovatelem a tvůrcem (proposer/builder) ePBS restrukturalizuje sloty přidáním termínů pro konstrukci bloku, odhalení payloadu a atestace. Tím se explicitně stanoví, kolik času lze vyhradit pro exekuci, což zvyšuje rezervu, kterou máme pro zvýšení limitu plynu.
Týmy zahájily týden s cílem zprovoznit do pondělního večera devnet Glamsterdamu v konfiguraci 4 EL × 4 CL. První pokusy odhalily dostatek problémů na to, aby se cíl posunul na úterý, kdy konfigurace 4×3 běžela dostatečně stabilně, aby mohlo začít zátěžové testování.
Od té chvíle byl zbytek týdne cyklem posilování ePBS: zátěžový test, odhalení okrajových případů, oprava, opakování. Úterní ranní pracovní skupina k Builder API podstatně zjednodušila specifikaci ohledně registrace validátorů, toku nabídek/hlaviček/závazků (bid/header/commitments), modelu důvěry pro platby tvůrcům a chování pojistek (circuit-breaker). Ladění uprostřed týdne se zaměřilo na okrajové případy napříč klienty – zejména kolem zneplatnění beacon požadavků exekučními požadavky, kde nová testovací sada odhalila mezeru v implementaci každého klienta. Do čtvrtečního rána týmy CL hlásily stabilní ePBS, zatímco cesty nabídek na straně EL se stále ladily; ty se vyřešily během čtvrtka a pátku. Dvě otázky zůstávají pro ACD skutečně sporné: zda by se podpis požadavku měl zavazovat přijímajícímu tvůrci a jak udržet design tvůrce se stakem 1 ETH odolný vůči P2P Sybil útokům na živost (liveness).
Do pátku běželi téměř všichni klienti společně na glamsterdam-devnet-2 s end-to-end otestovanou pipeline externích tvůrců!
Optimalizace BAL
Pokud je ePBS stranou vrstvy konsensu v příběhu škálování Glamsterdamu, protějšek na exekuční vrstvě má dvě dominantní části: úpravy cen gasu a seznamy přístupů na úrovni bloku (Block-Level Access Lists - BAL). Tím, že klientům předem poskytnou dostatek informací o sadě pro čtení/zápis bloku, umožňují BAL paralelní exekuci, dávkované I/O a paralelní výpočet kořene stavu (state-root), což vše určuje, jak velký blok mohou klienti pohodlně zvládnout.
Větev BAL na Soldøgn běžela na vlastních devnetech, odděleně od ePBS řetězců Glamsterdamu, takže benchmarky optimalizací nebyly propleteny s prací na stabilizaci vrstvy konsensu. Každá optimalizace byla skryta za vlastním feature flagem, takže měření během týdne je mohlo porovnávat izolovaně, a ne jako jeden celek. Dashboard benchmarků BAL a žebříček odhalily nejhorší scénáře každého klienta napříč testovací sadou – zaměřením se nejprve na zrychlení nejpomalejších cest mohly týmy plošně zvednout spodní hranici limitu plynu, a to nejen pro nejrychlejší implementaci.
Úpravy cen gasu
Glamsterdam zahrnuje řadu úprav cen gasu na EL, které kalibrují náklady tak, aby lépe odpovídaly využití zdrojů při vyšší propustnosti. V jádru stojí EIP-8037, zvýšení nákladů gasu na vytvoření stavu: zvyšuje cenu zápisu nového stavu, aby se vyšší limit plynu nepromítl do neomezeného růstu stavu.
Před začátkem Soldøgn obsahovala specifikace 8037 dynamické naceňování za každý bajt stavu vázané na limit plynu bloku, což činilo testování kombinatoricky bolestivým (jedna fuzz matice na každé pásmo limitu plynu) a benchmarking téměř neřešitelným. Týmy se hned na začátku týdne dohodly, že upustí od dynamického naceňování ve prospěch fixního cost_per_state_byte, přičemž budoucí úpravy cen se budou řešit na hranicích forků, nikoli v rámci forku.
Samotný účetní model nabral iterativnější směr. Pondělní pracovní skupina přesunula účtování gasu za stav z průběhu exekuce na konec call-framu; úterní navazující setkání uzavřelo náklady na vytvoření účtu, náklady na uložení kódu a reverty CREATE-transakcí; ve středu se objevily okrajové případy vracení/doplňování rezervoáru, které si vyžádaly přehodnocení. Čtvrteční skupina vrátila účtování na úroveň operačních kódů (opcode), protože dospěla k závěru, že skutečná složitost spočívá v modelu rezervoáru, nikoli ve výpočtu účtování. Do pátku se specifikace stabilizovala na bal-devnet-6, přičemž větev BAL dodala finální čísla pro úpravu cen.
Celý tento vývoj zdůrazňuje jeden z nejdůležitějších aspektů interopu: schopnost vyřešit složité problémy se specifikací, implementací, testováním, laděním a návrhem v řádu hodin namísto týdnů. V nejlepším případě dokážou týdny interopu vtěsnat měsíc asynchronního pokroku do každého dne!
Do pátku se tyto tři linie sběhly u hlavního čísla týdne: důvěryhodné spodní hranice limitu plynu po Glamsterdamu ve výši 200M. Toto významné zvýšení je možné, protože ePBS strukturuje slot tak, aby poskytl exekuci více času, optimalizace BAL dávají klientům rezervu v propustnosti v rámci této struktury a 8037 zajišťuje, že se vyšší limit plynu nepromítne do nekontrolovatelného růstu stavu.
Další témata Glamsterdamu
Kromě ePBS, BAL a úprav cen byla většina zbývajícího rozsahu Glamsterdamu prodiskutována v rámci pracovních skupin.
Týmy CL dokončily rozhodnutí o menších EIP pro Glamsterdam: EIP-8061 (zvýšení fluktuace výstupů/konsolidací) bylo zahrnuto do glamsterdam-devnet-1; EIP-8080 (výstupy přes konsolidační frontu) bylo zamítnuto pro zařazení; EIP-8045 (odstranění povinností penalizovaného validátora) bylo zúženo pouze na povinnosti navrhovatele v rámci okna výhledu (look-ahead window); a EIP-7688 (stabilní kontejnery SSZ) zůstává v rozsahu Glamsterdamu, ale je pozastaveno z glamsterdam-devnet-1, zatímco tým řeší omezenou velikost gossip zpráv pro atestace v rámci progresivních seznamů.
Středeční ranní pracovní skupina k architektuře synchronizace EL/CL odložila EIP-8237 mimo Glamsterdam ve prospěch zachování volitelnosti pro dlouhodobější architekturu "top-up synchronizace" v budoucím forku. Místo toho se účastníci dohodli na vypracování návrhu EIP, který normalizuje sekvencování forkchoiceUpdated / newPayload / getPayload, specifikuje iniciační handshake pro snap-sync a zpřísňuje konzistenci validní/nevalidní mezi rozhraními engine API.
Posilování (hardening) bylo neustálým tématem týdne. Čtvrteční sekce se zabývala testovacími rámci pro shodu s fork-choice, repozitářem Diamond s reprodukovatelnými scénáři okrajových případů CL a nástrojem buildoor, což je testovací nástroj pro externí tvůrce od PandaOps, který byl uprostřed sekce předveden na dlouhé řadě scénářů útoků, jež účastníci navrhovali přímo na místě.
Za hranice Glamsterdamu
Několik pracovních skupin se zaměřilo na Hegotá a forky, které budou následovat.
Vše odstartovala záměrně na konkrétních návrzích nezávislá sekce o nativní abstrakci účtu, která prošla požadavky a omezeními, jež musí jakýkoli budoucí design splňovat. Cíle sady funkcí, jako jsou alternativní schémata podpisů, agregace, dávkování, obnova, sponzorování gasu, flexibilní nonce a peněženky s úložištěm klíčů, stály vedle pevných omezení týkajících se kompatibility s veřejným mempoolem, bezstavovosti a odolnosti vůči DoS na vrstvě 2 (l2).
Čtvrteční pracovní skupina k FOCIL se zaměřila na aktualizace implementace: rané prototypy již byly funkční, přičemž bezprostředními dalšími kroky jsou multi-klientský interop a dedikovaný FOCIL devnet. Byla také učiněna dvě významná návrhová rozhodnutí: deaktivace FOCIL během 2-epochové ne-finality (zrcadlící chování pojistky proposer-boost) a přijetí přístupu záložek založených na indexech pro kompatibilitu s frame transakcemi / EIP-7702.
V delším horizontu dlouhodobá větev ETH P2P nastínila náhradu za libp2p založenou na QUIC s výchozím soukromím a integrací zohledňující sloty, spolu s prototypem vysílání s erasure coding, který simuloval ~6× rychlejší šíření než GossipSub na 2,4 MB payloadech. Ve větvi CL se také objevil silný sentiment směrem k případnému úplnému zrušení konsolidací – vyhlášení finálního forku, který je podporuje, a následné vynucení postupu výstup-a-nový-vklad (exit-then-redeposit) – jakožto čistší dlouhodobé odpovědi na růst stavu sady validátorů.
Proces ACD
Ve středu odpoledne Nixo a Ansgar, dva spoluvůdci ACDE, uspořádali sekci, aby shromáždili podněty od hlavních přispěvatelů ohledně procesu ACD. Sekce se znovu zabývala konceptem headlinerů, diskutovala o výhodách a nevýhodách strawmapy a formalizovala kritéria EIP SFI. Místnost vesměs chtěla zachovat headlinery, ale uvolnit rigiditu EIP-vs-téma a přijmout "téma + kandidátské EIP" jako schůdný model. Přiřazení let k jednotlivým forkům ve strawmapě po roce 2026 byla označena za příliš kanonizovaná a pravděpodobně budou zmírněna. Byla předložena nová čtyřbodová definice SFI, přičemž ACDT signalizuje připravenost a ACDE/ACDC si ponechávají konečné slovo. Nový proces určování priorit – vytvořený po rozhodnutích CFI a zohledněný v meta-EIP – nahradí starou roli SFI při řízení začleňování do devnetu, počínaje Hegotá.
Co se týče koordinace hovorů, Alex Stokes oznámil, že si od příštího týdne bere tříměsíční sabatikal, přičemž Pari v mezidobí převezme moderování ACDC a Barnabas zaskočí za ACDT. Celkově vzato: Nixo a Ansgar předsedají ACDE, Pari je dočasně na ACDC a Mario, Barnabas a Danceratopz se střídají v moderování ACDT.
Všechno ostatní
Kromě všeho výše uvedeného týmy využily osobní setkání k dosažení pokroku ve všem možném, od lepších testovacích nástrojů (zkrácení smyček zpětné vazby Hive z hodin na minuty), přes vylepšení propojení engine-API (deduplikace gossipu, dávkované volání a objevování hlavy řízené lehkým klientem), až po těžké kompromisy ohledně klientské diverzity a mnoha dalších témat. Úplný seznam poznámek ze sekcí je k dispozici na soldogn.xyz.
Další kroky
Odtud se týmy vracejí domů, aby vzaly to, co bylo během týdne prototypováno, a připravily to do produkce. Očekávejte, že příštích několik týdnů bude ve znamení usilovné práce na posilování implementací klientů vůči novým specifikacím, dokončování pokrytí testy a přeměně draftových PR ze Soldøgn na sloučený kód.
Jako vždy budou konečná rozhodnutí o hodnotách, jako je cíl limitu plynu 200M a finální čísla pro úpravu cen, učiněna a veřejně sdílena na hovorech AllCoreDevs. Očekávejte, že to budou hlavní témata příštího týdne!
Velké díky všem, kteří vážili cestu až na 78° s. š. a přispěli k úspěchu tohoto týdne! Zvláštní poděkování patří EthPandaOps za to, že každý den udržovali skupinu ve formě, a všem, kteří pracovali pod půlnočním sluncem, aby zajistili splnění našich denních cílů – včetně týmu Ethrex, který se k nám připojil na svůj první interop. Byl to neuvěřitelně produktivní týden a naštěstí budeme mít celý krátký film, abychom si ho pamatovali ☀️