Vysvětlení správy jádra Etherea

Prezentace od Nixa Rokishe z Nadace Ethereum na ETHBoulder, která vysvětluje správu základního protokolu Etherea, jak se koordinují hard forky, běžné mylné představy o tom, kdo ovládá Ethereum, a jak se zapojit do procesu správy.

Tento přepis je přístupnou kopií původního přepisu videa (opens in a new tab) zveřejněného komunitou EthBoulder. Pro lepší čitelnost byl lehce upraven.

Úvod (0:12)

Děkuji všem šesti mým přátelům, kteří dorazili. Dobrá. Dnes k vám budu mluvit o správě jádra Etherea. Jmenuji se Nixo. Vedu tým podpory protokolu v Nadaci Ethereum (EF). Mezi všechny naše úkoly patří i to, aby byl proces správy jasnější a snáze se v něm orientovalo všem ostatním, kteří se na těchto věcech podílejí, protože Ethereum zahrnuje mnohem více lidí než jen své hlavní vývojáře (core devs).

Zde je osnova přednášky. Budeme mluvit o tom, co je to správa jádra. Budeme mluvit o mylných představách a o tom, jak v současnosti funguje správa Etherea. Dotkneme se toho, jak si stojí v porovnání s jinými systémy decentralizované správy, proč by to mělo zajímat tvůrce (builders) a jaké jsou praktické možnosti, jak se zapojit.

Co je to tedy správa základního protokolu? Já provozuji uzel. To znamená, že mám u sebe doma kus hardwaru, počítač, na kterém běžím software Etherea. Když jsem tento software Etherea nastavoval, musel jsem si vybrat klienty, kteří tento software budou spouštět. Ethereum je do jisté míry unikátní v tom, že má více klientů pro zajištění klientské diverzity. Smyslem toho je, že pokud jeden klient spadne, pokud je v klientovi chyba, nespadne celá síť. Existují i jiné blockchainy, které mají další klienty. Nicméně Ethereum je jediné, které je nastaveno tak, že nás skutečně chrání před chybami. Pokud se podíváte například na Solanu, Solana má dalšího klienta, myslím, že se jmenuje nějak jako GTO, ale má jen 20–21% adopci. Takže pokud spadne většinový klient, spadne i celý řetězec. A už jsme viděli, jak jiné sítě spadly. A to je důvod, proč je Ethereum tím nejodolnějším a nejbezpečnějším blockchainem.

Otázkou tedy je, jak dostat změny do Etherea, když musíte koordinovat tolik různých klientů. Nejprve rozlišíme mezi hard forkem a soft forkem. Soft fork nevyžaduje takovou koordinaci jako hard fork. Ethereum primárně pracuje s hard forky. Hard fork v podstatě znamená, že všichni klienti vytvoří novou verzi Etherea a rozhodnou se v nějaký předem stanovený čas tuto novou verzi Etherea spustit. Je to stále Ethereum, ale má nové funkce. Má jiné funkce. A všichni provozovatelé uzlů, jako jsem já, kteří provozují uzly doma, nebo profesionální provozovatelé, musí tuto novou verzi Etherea přijmout. Musí svůj uzel upgradovat nebo aktualizovat tak, aby tento nový software obsahoval.

Jak se tedy rozhoduje o tom, jaké funkce se do těchto hard forků dostanou? Musí se dohodnout na prioritách, aby mohli alokovat svůj čas a zdroje, protože mají k dispozici jen omezený čas a zdroje. Upřednostňují věci jako bezpečnostní chyby nebo bezpečnostní záplaty, věci jako UX (uživatelská zkušenost) – pokud existuje jiný blockchain, který nám konkuruje, musíme se stát vůči těmto jiným blockchainům konkurenceschopnými. Jednou z věcí, na kterou se dívají, je to, že jakákoli funkce, která se přidá, musí být dopředně kompatibilní s potenciálními nadcházejícími položkami v plánu (roadmap).

Loni se stala jedna velmi sporná věc. Možná jste o ní slyšeli. Jmenovalo se to EOF. To je EVM Object Format. Byla to sada funkcí, která měla být součástí hard forku Fusaka – Pectra, Fusaka, myslím, že obou – ale rozdělilo se to. A jedním ze spouštěčů, proč to bylo z tohoto forku vyřazeno, bylo to, že Vitalik zveřejnil příspěvek o potenciálu Etherea přejít na RISC-V. Spousta lidí, kteří to četli, si řekla: dobře, pokud přejdeme na RISC-V, funkce, které zvažujeme v EOF, jsou v RISC-V nativní. Tak proč bychom do protokolu přidávali tuto složitost? Proč bychom na tuto věc vynakládali všechny tyto zdroje vývojářů klientů? Bylo by to bezpředmětné, kdybychom nakonec přešli na RISC-V.

Takže to byla taková ta poslední kapka pro EOF a nakonec to bylo z forku vyřazeno. Další věc, kterou musí vzít v úvahu, je, že to musí být napsáno a důkladně otestováno v šesti různých jazycích, protože tito klienti jsou napsáni v šesti různých jazycích. To je pro ně opravdu velká testovací matice, se kterou musí pracovat. A kvůli tomu je každé drobné rozhodnutí o designu předmětem debaty, aniž by existovala nějaká autorita, která by neshody vyřešila. To přináší otázku, kdo o tom rozhoduje – což je jádro správy.

Mylné představy (5:23)

To nás přivádí k mylným představám a na některé z nich se podíváme. Jednou z nich je, že Vitalik rozhoduje o tom, co se dostane do protokolu Etherea. Rozšířením toho je, že Nadace Ethereum ovládá všechno. A třetí je, že jsou to všechno zákulisní dohody – že tato rozhodnutí dělají zasvěcenci a veteráni (OGs).

Takže ta první: Vitalik rozhoduje. Vybral jsem jen podmnožinu stagnujících návrhů EIP, jejichž autorem je Vitalik. To znamená, že si Vitalik sedl, napsal návrh a řekl, že chce, aby se tyto věci dostaly do Etherea, a nikdo s ním nesouhlasil – tyto věci tam prostě jen tak leží. Nepodařilo se mu je do protokolu prosadit. Takže ne všechno, co navrhne, je automaticky zahrnuto.

Jedním z rozšíření tohoto tvrzení je, že Nadace Ethereum ovládá všechno. Vyberu konkrétní příklad z doby, která tomu podle mě odporuje. V roce 2024 se hodně mluvilo o limitu plynu. Důvodem je, že v roce 2022 během Merge jsme zvýšili limit plynu na 30 milionů. To je maximální výpočetní kapacita povolená v bloku. A pak jsme na to nějakou dobu nesáhli, protože to vlastně nebylo úzké hrdlo, kvůli kterému by lidé říkali: „To je důvod, proč nepřecházím na Ethereum“ nebo „To omezuje můj současný případ použití Etherea.“

A koncem roku 2023, začátkem roku 2024, se objevila narativa, že přichází Solana. Že Ethereu vypálí rybník. A tak lidé přemýšleli o tom, co může Ethereum udělat pro zrychlení. A jednou z věcí bylo, pojďme napumpovat tuto metriku gasu. A v té době si EF a vývojáři klientů tak trochu říkali: „Máme jiné starosti. Ale díky.“ Ale přišli tito dva lidé, Eric Connor a Mariano Conti, a řekli: „Ne, my limit plynu zvýšíme.“ Limit plynu je parametr kontrolovaný validátory. A tak mohli prostě začít mluvit s validátory, profesionálními provozovateli, a říct: „Hej, zvyšte svůj limit plynu.“

A v určitém okamžiku byla adopce tak velká, že si EF a klienti řekli: „Aha, tomuhle musíme věnovat pozornost. Musíme se ujistit, že to, co dělají, je bezpečné a že hodnota, na kterou to nakonec zvýší, bude pro síť bezpečná.“ Takže museli přerozdělit své zdroje. Nethermind přišel s tímto testovacím rámcem. EF odvedla spoustu práce v Berlíně. Všichni vývojáři klientů to benchmarkovali. A tak se mi to líbí, protože to donutilo EF rozhodnout o tom, co má prioritu.

A líbí se mi tenhle hloupý tweet, který jsem si tu vyfotil, protože je to jako když nějaký náhodný zpravodajský portál nazývá Erica Connora a Mariana Contiho hlavními vývojáři. Nejsou to hlavní vývojáři. Eric Connor byl staker a člen komunity. Mariano Conti byl bývalý vývojář aplikací pro MakerDAO. Ale prostě je nazvali hlavními vývojáři, protože vývoj Etherea je opravdu mimo svět toho, jak funguje tradiční software, a tak viděli, že se upravuje základní parametr, a řekli si: „Aha, to musí být hlavní vývojáři.“ Nebyli. Takže to je jen příklad toho, jak přijdou členové komunity a řeknou, že chtějí vidět tuto změnu, a zrealizují ji.

Jsou to všechno zákulisní dohody, zasvěcenci, veteráni – trochu víc chápu, proč je to mylná představa, protože v podstatě přijdete na tyto hovory o správě a je tam stovka lidí. Zdá se, že jsou všichni velmi v pohodě s tím, co se děje. Vy jste ztraceni. Nemáte tušení, jak se tato rozhodnutí dělají. Říkáte si: „Už je řada na mně, abych mluvil?“ A máte pocit, že lidé při rozhodování poslouchají pořád těch samých 10 lidí.

Meritokracie a statistiky účasti (10:18)

Pravdou ale je, že vývoj Etherea je větší meritokracií, než jakou jsem kdy viděl u většiny vývoje softwaru. Všichni tito lidé na tomto snímku obrazovky – to je jeden ze tří v tomto náhodném hovoru ACD, který jsem se rozhodl vyfotit – nikdo z těchto lidí nebyl jmenován, aby tu byl. Všichni jsou to prostě lidé, kteří se ukázali. Jsou to vývojáři, kteří s tímto protokolem strávili spoustu času. Jsou to ti, které lidé uznali jako talentované vývojáře v tomto prostoru, kteří neustále dělají dobrá rozhodnutí, a nikdo z nich tu není z moci úřední.

Já jsem se k EF připojil teprve před více než rokem. Vzal jsem tyto statistiky. Sahají jen do března 2025. Takže méně než rok. Průměrný počet účastníků All Core Dev – to jsou ty hovory o správě – je 98. Takže v průměru je na těchto hovorech 98 lidí. Maximální počet účastníků v jednom hovoru od té doby byl 153. Myslím, že to bylo v den, kdy jsme rozhodovali o datu spuštění Pectra na Mainnet. A celkový počet unikátních účastníků je 567 jen za poslední rok. Tahle metrika se mi opravdu líbí, protože ukazuje, že na tyto hovory nechodí pokaždé těch samých 100 lidí. Tito vývojáři aplikací, výzkumníci, někdo uslyší o nějaké funkci, o které se diskutuje, objeví se, aby vyjádřil svůj nesouhlas nebo podporu, a pak už na další hovor nepřijde.

Jak funguje proces správy (11:52)

Tohle je trochu suchý snímek, ale myslím, že je důležité si ho projít – takto v současnosti funguje správa Etherea. Takže když se diskutuje o jednom z těchto forků, první věc, která se stane, je, že lidé během tohoto vyhrazeného časového okna mohou předložit svůj hlavní návrh (headliner proposal). Hlavní návrh je ta stěžejní funkce, kolem které chceme, aby se lidé pro tento fork sjednotili. Může to být člen komunity, výzkumník, hlavní vývojář – opravdu kdokoli, kdo předloží jeden z těchto hlavních návrhů. Pak se okno uzavře a na hovorech o správě tak nějak diskutujeme o tom, který z nich dává smysl. Lidé předkládají své argumenty, lidé se přou a panuje konsensus ohledně toho, který bychom měli pro nadcházející fork vybrat.

Poté se vybírají menší funkce. Tedy ty menší věci, které ve skutečnosti nemusí být těmito hlavními funkcemi pohánějícími fork. A po celou tuto dobu máme devnety specifické pro dané funkce. Devnet je jako testnet – soukromá testovací síť pro vývojáře, aby tyto funkce otestovali a ujistili se, že na Ethereu skutečně fungují. A pak v určitém okamžiku dojde ke zmrazení funkcí (feature freeze). Takže jsme prodiskutovali hlavní funkce, prodiskutovali jsme menší funkce, spustili jsme tyto devnety specifické pro dané funkce, které jsou obvykle hlavními taháky forku. A to je zmrazení funkcí s hvězdičkou, protože v tu chvíli jsme se rozhodli, že do tohoto forku už žádné další funkce přidávat nebudeme. Spustíme všechny funkce dohromady, ujistíme se, že je vše v pořádku, ujistíme se, že se nic nerozbije. Ale pokud něco začne věci zpomalovat, pokud se fork zpozdí, pokud je to příliš složité, mohou být věci v tomto bodě stále vyřazeny.

Takže po několika devnetech – mohou to být dva, může jich být 10 – se všichni klienti v určitém okamžiku rozhodnou, že je to stabilní. Věříme tomu, co se právě děje. Jsme na dobré cestě. Začněme přemýšlet o tom, jak to dostat na Ethereum Mainnet. Vydají verze klientů a pak následuje 30denní období, kdy bezpečnostní tým EF vypíše odměnu za nalezení chyb (bug bounty). Sjednají bezpečnostní audity. A pak na konci tohoto 30denního období spustíme fork na testnetech. To jsou testnety, o kterých jste možná slyšeli – jako Holesky. Zde mohou vývojáři aplikací testovat své věci předtím, než se fork spustí naostro. A ty trvají obecně minimálně 14 dní každý, jen abychom se ujistili, že je vše v pořádku. Neočekáváme žádné velké problémy, protože to už prošlo devnety specifickými pro dané funkce a obecnými devnety, ale historicky to některé z těchto testnetů rozbilo. A tak je to taková poslední výzva k nalezení a odstranění všech těchto chyb.

A jakmile je testnet nevyžadující povolení stabilní, vybere se datum pro Mainnet. Poté následuje 30denní rezerva. Tato 30denní rezerva existuje, protože si to vyžádaly L2 a protokoly, aby se mohly na fork připravit. Takže to je minimálně 30 dní a pak dojde k forku.

Struktura hovorů a koordinace (15:01)

Během celé této doby probíhají některé hlavní série hovorů. Všechny tyto veřejné hovory jsou živě přenášeny na YouTube. Ty hlavní jsou ACDE a ACDC. E znamená exekuční vrstva – to jsou věci jako transakce, nasazování chytrých kontraktů, správa mempoolu. ACDC je vrstva konsensu – takže to jsou věci týkající se validátorů, jako je správa validátorů, penalizace. A ty se střídají ve čtvrtek. Takže každý čtvrtek je ACD a jeden z nich je ACDE a pak ten další je ACDC, a tak to pokračuje.

Hovory ACDE a ACDC se zaměřují na fork, který právě vytváříme, a na forky, které plánujeme do budoucna. Hovory ACDT jdou více do hloubky a detailů. Jsou to klienti, kteří mluví o chybách, přes které se nemohou dostat, nebo o detailech implementace, které je třeba vyřešit ohledně forku, na kterém právě pracují. Takže právě teď je dalším forkem, který se chystá, Glamsterdam. Těmto hovorům ACDT tedy dominuje konverzace o ePBS a seznamech přístupů na úrovni bloků, což jsou věci, které se do Glamsterdamu dostanou. A to jsou vysoce technické hovory.

A pak jsou tu oddělené hovory (breakout calls). Oddělené hovory jsou členové komunity, výzkumníci, vývojáři, kteří říkají: „Hej, mám funkci, kterou chci dostat do Etherea za dva forky.“ A tak pořádají tyto týdenní, měsíční nebo dvouměsíční hovory, kde probírají detaily implementace, mění a iterují specifikaci a obecně řeší všechny otázky, které lidé mají, všechny známé neznámé, aby se ujistili, že je to v nejlepším možném stavu pro zařazení do forku za dva forky. A ty mohou být naplánovány, kdykoli se facilitátor rozhodne.

Vyvíjející se proces (15:29)

Takže jedna věc, kterou chci všem vštípit, je, že tento proces není vůbec statický. Tento proces, který jsem vám právě popsal, funguje méně než rok. Ethereum funguje už 10 let. Ale neustále se mění a důvodem, proč se neustále mění, je to, že to nikdo neřídí. A tento proces se tak nějak vyvíjí, aby se zjistil nejefektivnější způsob fungování. A říkám sice efektivní, ale pověst, kterou správa Etherea má, je taková, že je opravdu stagnující, je těžké něco prosadit, je matoucí – a to proto, že když máte 100 až 500 lidí, kteří dělají rozhodnutí, jsem upřímně ohromen, že to vůbec funguje.

Takže Tim v dubnu 2025 napsal příspěvek s názvem „Reconfiguring All Core Devs“, který se nakonec stal návrhem toho, jak věci fungují právě teď. A důvodem je to, že předtím jsme měli takovou ucelenou narativu o tom, na co bychom se měli v Ethereu zaměřit. Byl tu Merge, což byl obrovský podnik. Všichni byli velmi nadšení. Většina lidí byla velmi nadšená. Těžaři ne. A pak po Merge přišly výběry. Nechtěli jsme, aby lidé měli své ETH uzamčené v kontraktu a aby se šířil FUD, že z toho své ETH už nikdy nedostanou. Takže jsme to museli dodat co nejrychleji. A pak tu byl proto-danksharding a pak přišla Pectra a Pectra byla takovým amalgámem různých nesouvisejících EIP a vlastně neměla ucelenou narativu. A stala se tak velkou, protože lidé do ní kvůli nedostatku soudržnosti prostě jen cpali věci, že se musela rozdělit do dvou různých forků, protože testovací týmy si tak nějak řekly: „Rozsah je příliš velký. Tohle všechno otestovat nemůžeme.“

A tak Timovým impulsem k tomu bylo: dobře, musíme vymyslet způsob, jak udržet tyto forky co nejvíce zaměřené a soudržné. A hlavní návrh (headliner) byl tak nějak odpovědí na to. Smyslem toho bylo dodávat věci způsobem, který upřednostňoval pocit, že všichni vědí, o čem ten fork je, takže do něj nemuseli cpát 25 různých EIP.

Takže ten druhý snímek obrazovky nahoře je Tim, který navrhuje definice pro fáze začlenění těchto EIP. A to, co tím chci říct, je, že někdy slyšíte lidi říkat, že tento proces je příliš byrokratický. Ale to, co se ve skutečnosti děje, je, že lidé přijdou do tohoto procesu správy a ptají se: „Jak tam dostanu EIP?“ a lidé, kteří tam jsou už 10 let, odpoví: „Prostě to nějak uděláš.“ A lidé si řeknou: „To je hrozné.“ A tak to, co tyto věci dělají, je, že popisují, co se děje, aby usnadnily outsiderům účast v tomto procesu, protože pokud sem jen přijdete a řeknete si: „Mám jedno EIP, nezajímá mě správa Etherea, chci tam jen dostat tohle jedno EIP“ – chcete rubriku, chcete kontrolní seznam, chcete velmi jasný postup krok za krokem, jak tam toto EIP dostat. Takže většina těchto věcí je spíše o popisu toho, jak proces funguje, než o vytváření byrokratických pravidel, která lidé musí dodržovat, aby bylo těžké EIP prosadit.

Třetí věcí jsou commity v průběhu času na Forkcastu. Forkcast je produkt mého týmu, od Wolframa Marka, kluka z mého týmu, který ho vytvořil v polovině loňského roku, když se můj tým v současné podobě zformoval. A stal se z něj takový kanonický zdroj, který lidé používají k interakci s forkem, aby viděli, co se do forku dostane a jak je to ovlivní. Všechny tyto věci jsou staré méně než dva roky. Takže chci jen říct, že tento proces se hodně mění. Není vůbec statický. Není to nějaká zamrzlá byrokracie, do které je těžké proniknout.

Srovnatelné systémy správy (20:21)

Takže jen v rychlosti jsem se chtěl dotknout nejpodobnějších decentralizovaných systémů správy, které vidím ve srovnání se správou Etherea. A to, co se tu tak nějak snažím říct, je, že je to udržitelné – i když je úžasné, že 100 až 500 lidí dokáže dělat rozhodnutí, v reálném světě je to udržitelné. Vidíme příklady toho, že to funguje.

IETF je Internet Engineering Task Force. Je to dobrovolníky řízený standardizační orgán, který vytvořil TCP/IP, HTTP. Je to organizace, která je nejvíce zodpovědná za to, že dnes máme svobodný internet. Jádro Linuxu (Linux kernel) – to je jádro operačního systému Linux. Takže to je open-source software, který pohání internetové servery, telefony s Androidem, superpočítače. Rozdíl je v tom, že tam mají s Linusem Torvaldsem takový model benevolentního diktátora. Ale i tak mají přes 17 000 přispěvatelů, což je ohromující.

Věci, kterým se to nepodobá: jiné blockchainy, které mají onchain hlasování pomocí tokenů. Ethereum se specificky vyhýbá jakémukoli mechanismu hlasování, protože to podle mého názoru vede k možnostem ovládnutí a tak nějak to odstraňuje motivaci dělat věci jako meritokracii, kde lidé prostě důvěřují těm, kteří píšou nejlepší kód. A pak jsou tu L2. Ty mají multi-sigy. Mají bezpečnostní rady. To jsou spíše jmenované pozice, které dělají tato rozhodnutí. A to má své kompromisy. Je to více centralizované. Pohybuje se to ale rychleji.

Proč to zajímá tvůrce (22:38)

Proč se tedy tvůrci zajímají o správu? Protože tvůrci jsou doslova ti, pro které je Ethereum vytvořeno. Ethereum není vytvořeno pro hlavní vývojáře. Není vytvořeno pro validátory. Někdy jsou z toho tito lidé zmatení. Hlavní vývojáři Etherea a validátoři slouží Ethereu, které slouží tvůrcům a uživatelům.

A každý už zažil ten moment s umělou inteligencí, kdy se dostáváte příliš do detailů a ona se snaží opravit tuhle maličkost a nedokáže si poodstoupit a podívat se na celkový smysl projektu. A hlavní vývojáři mohou být takoví, když se snaží zdokonalit proces vývoje jádra. A v tom případě je velmi klíčové, aby přišli tvůrci, protože vývoj jádra je tak pohlcující, že většinou zároveň nestaví na Ethereu. Jsou velmi zapojeni do vývoje jádra. Zabírá jim to veškerý čas. A tak se tvůrci aplikací musí opravdu snažit přijít a říct: „Hej, tohle potřebujeme. Tohle je pro Ethereum klíčové.“ Jen aby se ujistili, že tam ta perspektiva je a že nejsou jen zaškatulkováni do práce pouze pro hlavní vývojáře.

Jak se zapojit (24:40)

Jak se tedy zapojit nebo prosadit svou funkci? Tohle je taková obecná rada, ale myslím, že je ta nejlepší. Buďte hlasití ohledně svých problémů. Běžte na Twitter, pište příspěvky na blog, hledejte řešení svých problémů. Spekulujte o věcech, které by vám mohly pomoci. Pokud najdete další lidi, kteří mají stejné problémy, obecně můžete najít EIP, které existuje k řešení tohoto problému, nebo vám někdo pomůže napsat EIP, které to udělá.

Jedna věc, která se mi na open-source softwaru líbí, je, že obecně dobře kapitalizované společnosti alokují čas svých vývojářů a zdroje na údržbu open-source nástrojů, které používají. A nakonec to dopadne tak, že na údržbě této věci spolupracuje spousta různých společností, a tak to může fungovat i v Ethereu. Takže pokud máte problém, který jste identifikovali, můžete najít vývojáře z Base, který má podobný problém, a Base je dobře kapitalizovaná organizace, takže by pravděpodobně byli ochotni alokovat nějaké zdroje na dodání funkce nebo na provedení funkce přes hard fork Etherea.

Nechám vám tu jen nějaké zdroje. Forkcast.org – tam se můžete podívat, co se dostane do forku a jak to ovlivní určité zúčastněné strany. Takže pokud jste vývojář aplikací, je tam sekce pro vývojáře aplikací. Pokud jste vývojář peněženek, vývojář klienta vrstvy konsensu, jsou tam sekce o tom, jak vás to všechno ovlivní. Na YouTube se nahrávají všechna videa z těchto hovorů. Jsou také vložena na stránce forkcast.org/calls, kde jsou shrnutí, přiřazení řečníků, takže je snazší se v těchto hovorech orientovat. Adresář EIP, fórum Ethereum Magicians, kam můžete jít a mluvit s ostatními lidmi o potenciálních řešeních nebo EIP, které chcete napsat. A velmi brzy bude mít můj tým stránku podpory protokolu. Vypadá úžasně. Ještě není připravena ke sdílení. Je tam i můj e-mail – nixo@ethereum.org (opens email client). To je vše.