Původní název: "Ethereum Core Developer Meeting Update 014"
Původní zdroj: AllCoreDevs Update
Původní autor: Tim Beiko
Původní kompilace: Ethereum.cn
Vítejte v novém vydání aktualizace AllCoreDevs (Ethereum Core Developer Conference) – poslední v roce 2022.
přehled
Obsah aktualizace Shanghai/Capella byl dokončen: výběry, EOF a některé drobné úpravy... za předpokladu, že nezdržují výběry.
Blob space se blíží: EIP-4844 bude v centru příštího upgradu Etherea a jeho svolávací ceremonie začne brzy.
Po technické stránce probíhají snahy o koordinaci procesů upgradu prováděcí vrstvy a konsensuální vrstvy. Jsme také svědky aktivních diskusí o lepším začlenění příspěvku komunity do procesu.
Protokolová guilda vydala střednědobou pilotní zprávu a hrubý plán na rozšíření počtu správců první úrovně a lepší podporu v roce 2023.
Upgrade Shanghai/Capella
Na nedávném AllCoreDevs dosáhl klientský tým konsensu ohledně konečného rozsahu aktualizace Shanghai/Capella. I když název upgradu může být předmětem diskuse, tým má jasno v jeho rozsahu. Hlavním rysem upgradu je zavedení výběrů Beacon Chain pro stakery. Zavedení této funkce co nejrychleji je něco, v čem klientský tým nechce dělat kompromisy, takže ostatní funkce v upgradu musí být připraveny současně, jinak hrozí, že budou opuštěny.
Shanghai Executive Layer Specification uvádí všechny zahrnuté EIP:
EIP-3540: EVM Object Format (EOF) v1
EIP-3651: Snížení nákladů na plyn pro přístup k adresám COINBASE
EIP-3670: EOF – ověření kódu
EIP-3855: Přidán operační kód PUSH 0
EIP-3860: Omezte velikost initcode a zaveďte měření plynu
EIP-4200: EOF - statický relativní skok
EIP-4750: EOF - Funkce importu
EIP-4895: Stahování řetězu majáku jako operace systému
EIP-5450: EOF - Ověření zásobníku
Přestože je seznam dlouhý, lze jej rozdělit do tří různých částí: drobná vylepšení, formáty objektů EVM a stažení. Dále je postupně představíme:
Drobná vylepšení
EIP-3651: Teplá COINBASE (snížení nákladů na plyn při přístupu k adresám COINBASE)
Toto EIP opravuje nedopatření v EIP-2929, kde byly náklady na plyn za přístup k určitým datovým polím upraveny podle toho, zda data již byla v paměti klienta (WARM) nebo je třeba je načíst z disku (COLD).
EIP-2929 nastavuje na začátku každé transakce dvě data v paměti klienta na WARM: odesílací adresu a přijímací adresu. EIP-3651 přidává do tohoto seznamu třetí adresu, adresu COINBASE (tj. feeRecipient), protože je to také adresa, kterou má klient v paměti při zpracování blokových transakcí.
EIP-3855: instrukce PUSH 0 (nový operační kód `PUSH 0)
Jak název napovídá, EIP-3855 zavádí operační kód, který vloží do zásobníku hodnotu 0. K vyplnění hodnot v EVM se často používá stlačování 0, tento operační kód poskytne efektivnější a levnější způsob, jak toho dosáhnout.
EIP-3860: Limit a initcode měřiče (omezení velikosti initcode a zavedení měření plynu)
Tento EIP přidává omezení velikosti initkódu a zavádí měření plynu na základě jeho délky. Jeho horní limit velikosti přidává invariantu k EVM, což usnadňuje pochopení a navrhování úprav.
Zavádí režii 2 plyny na 32 bajtů pro initcode, který se používá k platbě za jumpdest analýzu, kterou musí klient provést před provedením a která není uvedena v plynoměru.
formát objektu
Většina EIP zahrnutých v aktualizaci Shanghai je ve skutečnosti součástí jediné funkce: EVM Object Format (EOF). Práce byla rozdělena do 5 různých EIP, aby pomohla vývojářům klientů porozumět každé jednotlivé modifikaci, ale aby poskytli přehled na vyšší úrovni, vývojáři vydali jednotnou specifikaci. EIP těchto pěti EOF jsou:
EIP-3540: EVM objektový formát verze 1
EIP-3670: EOF – ověření kódu
EIP-4200: EOF - statický relativní skok
EIP-4750: EOF - Funkce importu
EIP-5450: EOF - Ověření zásobníku
Stojí za zmínku, že prvním krokem EOF byl londýnský upgrade EIP-3541, který rezervoval prefix 0xEF 00 pro kontrakt EOF. Rozsah EOF aktualizace v Šanghaji se také během několika posledních měsíců změnil.
V únoru se klientský tým dohodl na zvážení upgradu v Šanghaji tak, aby zahrnoval dvě nejmenší EOF EIP: EIP 3540 a 3670. Všechny budou sloužit jako stavební bloky, ale nebudou poskytovat plnou funkčnost bez zavedení EIP 4200, 4750 a 5450. Ačkoli je možné rozšířit EOF, zpětná nekompatibilita může vyžadovat novou verzi. Protože smlouvy před EOF nebo EOF s konkrétní verzí musí být vždy spustitelné, každá nová verze EOF znamená, že vývojáři klientů musí udržovat novou sadu pravidel provádění EVM paralelně se starými pravidly.
Před EOF klienti udržovali pouze jednu sadu pravidel EVM najednou. Kódová základna také podporuje předchozí pravidla EVM, která se upravují při každém upgradu sítě, ale jakmile se dostanou do čela blockchainu, musí být aplikována pouze nejnovější pravidla. Po nasazení EOF bude klient udržovat dvě paralelní sady pravidel EVM, takže může spouštět kód v EOF a non-EOF kontraktech. Jinými slovy, zvyšující se verze EOF zvyšují počet paralelních než po sobě jdoucích sad pravidel EVM, které je třeba udržovat.
Za tímto účelem začaly klientské týmy v posledních několika měsících upřednostňovat přístup „velkého EOF“. Tímto způsobem, ačkoli musí implementovat větší sady úprav, verze EOF vydrží déle a sníží počet „paralelních EVM“, které je třeba udržovat. Proto vývojáři uvažovali o „velkém EOF“ a nakonec jej zařadili do šanghajského upgradu.
To znamená, že větší funkce je samozřejmě obtížnější implementovat a testovat a tým nechce, aby EOF vážně zdržoval stažení řetězce majáků. Pokud tedy nebude implementace EOF dokončena do ledna a nebudou moci rychle vzájemně spolupracovat, klientský tým souhlasí s přesunem EOF ze Šanghaje za účelem upgradu.
S ohledem na tyto souvislosti nyní stručně představíme každý EOF EIP:
EIP-3540: EVM Object Format (EOF) v1 (EVM Object Format verze 1)
Toto EIP zavádí „kontejner“ do smlouvy EOF. Přidává značky pro rozlišení kódových a datových částí smlouvy a zabraňuje nasazení smluv EOF, které neodpovídají formátu. To zaručuje, že každá smlouva EOF v řetězci bude mít platný formát, což zjednodušuje interakci s těmito smlouvami a také jejich statickou analýzu.
EIP-3670: EOF – ověření kódu (EOF – ověření kódu)
Na základě kontejneru zavedeného 3540 zajišťuje EIP-3670, že kód ve smlouvě EOF je platný, nebo brání jeho nasazení.
To znamená, že nedefinované operační kódy nelze nasadit do kontraktů EOF, což má další výhodu v tom, že snižuje počet verzí EOF, které je třeba přidat. Pokud je přidán nový operační kód, ověřovací pravidla lze jednoduše změnit tak, aby jej povolily a zajistily, že na něj nebude odkazovat žádný nasazený kontrakt EOF ve své kódové sekci.
EIP-4200: EOF – Statické relativní skoky (EOF – Statické relativní skoky)
EIP-4200 zavádí první operační kódy specifické pro EOF: RJUMP, RJUMPI a RJUMPV, které kódují cíle jako okamžité hodnoty se znaménkem. Tyto nové JUMP operační kódy mohou být použity kompilátory k optimalizaci plynové režie, protože eliminují potřebu runtime jumpdest analýzy, kterou vyžadují stávající JUMP & JUMPI operační kódy.
EIP-4750: EOF – Funkce (funkce zavedené EOF)
EIP-4750 jde o krok dále než 4200: zakazuje použití operačních kódů JUMP & JUMPI a přidává alternativy pro funkce, které nelze kopírovat. Je implementován zavedením specifických funkčních sekcí do EOF bytecode Tyto funkce mohou přeskakovat z nových operačních kódů JUMPF, CALLF a RETF a používat je k volání a návratu.
EIP-5450: EOF – Ověření zásobníku (EOF-Ověření zásobníku)
Nakonec EIP-5450 přidává další kontrolu platnosti smluv EOF, tentokrát kolem zásobníku. Toto EIP brání kontraktům EOF v nasazení kódu, který může způsobit podtečení zásobníku a v některých případech přetečení. S tímto EIP mohou klienti snížit počet ověřovacích kontrol při provádění kontraktů EOF, protože mají lepší záruky ohledně výjimek souvisejících se zásobníkem.
Jako odborník mimo EVM, který se velmi zaměřuje na samotné EIP, to je vše, co mohu říci! Pokud se čtenáři chtějí o EOF dozvědět více, doporučuji příslušné tweety zveřejněné lightklienty z týmu Geth a Leem z týmu Solidity.
Vytažení řetězu majáku
V neposlední řadě je hlavní částí „Shapella“ (poznámka překladatele: souhrnný název Shanghai/Capella) stažení řetězce majáku. Tato část změny je popsána ve specifikaci konsensuální vrstvy a EIP-4895. Nyní existuje mírně zastaralá meta-specifikace spojující tyto změny dohromady.
Na vysoké úrovni je mechanika výběrů následující:
Při navrhování bloku validátor lineárně skenuje index validátoru, aby našel prvních 16 validátorů s přihlašovacími údaji 0x01, které musí splňovat jednu z následujících podmínek:
Mít zůstatek vyšší než 32 ETH (tj. mít nashromážděné odměny validátoru)
lze vytáhnout (tj. úplně opustili sadu validátorů)
Zůstatek je větší než 32 ETH (to znamená, že byla získána odměna pro validátor)
Je vyjímatelný (vytahovací, to znamená, že zcela opustil sadu validátorů)
Z nich validátor vytvoří seznam výběrů, které budou zahrnuty do jejich ExecutionPayload. Každá položka v tomto seznamu obsahuje následující položky:
Validátor vytvoří seznam výběrů z těchto validátorů a zabalí jej do jejich ExecutionPayload. Každá položka v seznamu obsahuje následující položky:
WithdrawalIndex: Index všech provedených výběrových transakcí – pomáhá rozlišit výběry stejné částky ze stejné adresy, stejného validátoru
ValidatorIndex: index validátoru, kde byl navýšen zůstatek
ExecutionAddress: ETH adresa prováděcí vrstvy, kam mají být zasílány výběry
Částka: Částka odeslaná na adresu ExecutionAddress, tato částka se měří v gwei (nikoli wei)
Klienti prováděcí vrstvy provedou tyto výběry po provedení transakcí, kdy jsou sestavovány nebo zpracovávány bloky. Jinými slovy, výběry se zpracovávají podobným způsobem jako zaprotokolování odměn za důkaz práce a nesoutěží s transakcemi uživatelů o blokový prostor.
Za zmínku stojí i další detaily:
Při zpracování výběrů není rozdíl v prioritě/pořadí mezi "plnými prostředky" a "částečnými prostředky". K úplným výběrům dochází, když validátor opustí výstupní tým, zatímco k částečným výběrům dochází periodicky, to znamená, když je prováděno lineární skenování sady validátorů a je skenováno indexové číslo určitého validátoru.
Aby mohly být výběry zpracovány, musí validátoři použít přihlašovací údaje 0x01, které jsou reprezentovány adresami ETH. Když je řetězec majáků online, jsou povoleny pouze přihlašovací údaje pro pár klíčů BLS 0x00. Aby bylo možné zahájit výběr, validátor s přihlašovacími údaji 0x00 bude muset podepsat zprávu BLSToExecutionChange. Ty budou aktivovány v upgradu Capella. K podepsání této zprávy bude použita celá řada nástrojů a validátoři mohou očekávat podporu a výukové programy pro tyto nástroje.
Skenování validátorů je po bloku. Pokud po skenování podmnožiny sady validátorů není ke zpracování žádných 16 výběrů, validátor zastaví skenování a další validátor začne od posledního naskenovaného indexu validátoru.
Jako obvykle bude k dispozici několik vývojářských testovacích sítí a testovacích sítí (možná dokonce i nějaké nové testovací sítě!) pro validátory, aby spustili celý proces a vyřešili případné chyby, než se mainnet spustí.
Shanghai/Capella není jediný upgrade, který pokročil! Vývojářský tým stále čeká na další upgrade.
Upgrade Cancúnu
Protože obsah aktualizace Shanghai je již plný, mnoho EIP (CFI), které byly zvažovány pro aktualizaci, nemohlo vstoupit do aktualizace Shanghai. Klientský tým začíná diskutovat o tom, která EIP by měla být zvážena pro příští upgrade: Cancun Upgrade (název konsensuální vrstvy bude určen)
Z hlediska konsensuální vrstvy se EIP-4844 stal prvním EIP zapsaným do specifikace po upgradu Capella. Neexistuje (zatím) specifikace pro výkonnou vrstvu, která by mohla implementovat toto rozvržení, ale tým výkonné vrstvy souhlasil, že bude postupovat podobnou cestou a při příštím upgradu vycentruje EIP-4844.
Po konvenci upgradů s použitím názvů měst, kde se Devcon konal, byl vytvořen cancun.md s EIP-4844 oficiálně zahrnutým v upgradu.
K tomuto rozhodnutí došlo na poslední chvíli poslední schůzky AllCoreDevs v roce 2022, takže nebyl čas pracovat na dalších návrzích. EIP, které vstoupily do upgradu CFI v Šanghaji, ale nakonec nebyly zahrnuty, byly přesunuty do seznamu CFI pro upgrade v Cancúnu. Na fóru Ethereum Magicians byl také otevřen příspěvek k diskuzi o kandidátských EIP v Cancúnu. Diskuse o rozsahu upgradů v Cancúnu by měla začít vážně na začátku příštího roku.
Obřad KZG
Další věc, na kterou se můžete těšit v souvislosti s upgradem v Cancúnu, je ceremoniál KZG, což je požadavek EIP-4844.
Tento rituál vygeneruje náhodnost potřebnou k ověření platnosti dat blobu. Aby to bylo považováno za bezpečné, musí být upřímný pouze jeden účastník. Jinými slovy, pokud se všichni účastníci kromě jednoho domluví, celý proces je kryptograficky bezpečný.
Ceremoniál začíná v lednu a bude otevřen pro všechny po dobu několika měsíců. S cílovou účastí 10 000 účastníků bude program dosud největším ceremoniálem svého druhu! Pokud se chcete ujistit, že nic nepromeškáte, sledujte Trenta Van Eppse na Twitteru!
Proces upgradu po sloučení
Jak již bylo zmíněno v předchozí aktualizaci, po sloučení je koordinace procesu upgradu Etherea na prováděcí vrstvě a vrstvě konsensu důležitou položkou. Z pohledu vysoké úrovně používá prováděcí vrstva k popisu úprav Yellow Paper & EIP, zatímco vrstva konsensu používá spustitelné specifikace Pythonu.
Výhodou procesu výkonné vrstvy je, že EIP je komunitě dobře znám a je naformátován způsobem, který jasně demonstruje zdůvodnění návrhu. Žluté knihy s velkým množstvím matematického obsahu ve spojení s EIP a nutnost zařadit specifikace zpět do kontextu každého EIP ztěžují pochopení a rozšíření specifikací prováděcí vrstvy.
Problém s konsensuální vrstvou je opačný: má jasnou a srozumitelnou specifikaci v jediném úložišti, ale změny nejsou hmatatelné a návrhy jsou pohřbeny v jiných veřejných PR v úložišti.
Se zavedením specifikace prováděcí vrstvy Ethereum doufáme, že tuto mezeru zkrátíme na straně prováděcí vrstvy. A s určitými procesními hádkami bychom mohli být schopni zavést EIP do procesu konsensuální vrstvy!
To znamená, že jak byl rozsah šanghajského upgradu diskutován a finalizován, bylo jasné, že další část procesu může chybět: umožnit komunitě vyjádřit své relativní preference pro změny a zapojit se do diskusí o celém rozsahu upgradu (spíše než jednotlivá EIP) Diskutujte o tom na místě a udělejte to součástí rozhodnutí na setkání AllCoreDevs a konsensuální vrstvy.
Zatím není jasné, jak to bude vypadat – rád bych návrhy! — ale jak rostl počet zúčastněných stran aktivně zapojených do změn protokolu, stejně jako počet oblastí ovlivněných změnami první vrstvy, bylo jasné, že něco potřebujeme.
Naštěstí nemusíme začínat od nuly. Ethereum Magicians existuje již léta a jeho offline setkání, vyhrazená skupinová setkání nebo komunitní setkání mohou být dobrým výchozím bodem pro expanzi.
Větší pokrok v této oblasti očekávejte začátkem roku 2023!
Aktualizace cechu dohod
Vzhledem k tomu, že pilot Protocol Guild (PG) je nyní v polovině, vydali zprávu, aby se podívali, jak věci jdou, a zvážili, jaké jsou další kroky pro projekt.
Připomínáme, že PG je mechanismus financování bez povolení pro vývojáře klientů Ethereum Layer 1, výzkumníky protokolů a podpůrné přispěvatele (jako jste vy).
Tento mechanismus je zaměřen na jednotlivce, nikoli na organizaci. Stručně řečeno, každý člen má nárok na podíl z tokenů cechu, vážený podle toho, jak dlouho přispíval do Etherea. Přidávání a odstraňování členů se provádí skutečným způsobem Ethereum – na základě souboru standardů a hrubého konsenzu v rámci PG. Tento seznam bude poté vložen do řetězce pomocí smlouvy o rozdělení 0xSplit. Dárce pak může zasílat finanční prostředky přímo na adresu příjemce nebo na základě smlouvy, která uvolňuje prostředky na adresu příjemce.
Pilotní průběžná zpráva je shrnuta v tomto tweetu. Zde jsou některé hlavní body
Pilot získal 9,7 milionu dolarů od organizací jako Lido, Uniswap, ENS, NounsDAO a MolochDAO a také od pravidelných dárců od jednotlivců (díky Tetranode!) – děkujeme všem, kteří to umožnili!
PG měla při spuštění 90 členů a nyní jich má 128, přičemž mezi ně je rozděleno 5 milionů dolarů
V průměru každý člen obdržel 39 000 USD, přičemž nejnižší byla 13 000 USD a nejvyšší dosáhla 79 000 USD.
Architektura PG se mění a bude podporovat L2 a odstraní potřebu multi-sig pro aktualizaci vah
Tyto první výsledky ukazují, že PG funguje podle plánu: mechanismus, který distribuuje koš tokenů samo se inkubující rostoucí skupině přispěvatelů protokolu. Tento projekt by nebyl tím, čím je dnes, bez štědré podpory pilotních dárců.
Při pohledu do budoucnosti je nyní čas rozšířit dosah PG a realizovat jeho plný potenciál: poskytnout správcům Etherea konkurenceschopnou kompenzaci přizpůsobenou riziku. Nejjednodušší věc, kterou můžete udělat, je, že projekt od začátku daruje PG, jak řekl Danny Ryan v tweetu o spuštění PG.
Většina darů v pilotním projektu pocházela z velkých projektů s velkým objemem finančních prostředků. Pokud Protocol Guild dokáže přesvědčit tyto projekty, aby darovaly PG od prvního dne, kdy jsou jejich tokeny stále skutečně „bezcenné“, mohou správci Etherea těžit z celé vzestupné trajektorie těchto úspěšných projektů.
Pokud je zapojeno dostatečné množství projektů, mohou pobídky udržet nejlepší talenty na smlouvách o údržbě, místo aby je odtahovaly.
K podpoře tohoto a mnoha dalších typů darů bude PG potřebovat technologickou revizi. Příští verze bude podporovat L1 a L2 a dále sníží její dopad na řízení v řetězci.
Pokud jste projekt, který by rád přispěl do Protokolového cechu, kontaktujte mě - moje DM jsou otevřené!
Následná práce
Tím končí rok 2022... Jaký mimořádný rok! Před třemi měsíci jsme nebyli ani sloučeni! Nyní, když má Ethereum důkaz o podílu tiše běžící na pozadí, pozornost se přesunula na budoucí transakce.
Protože se všichni vrátí v lednu, můžete očekávat:
Shanghai/Capella upgradovala vývojářskou testovací síť a shadow fork
Ceremoniál KZG jde online
Diskuse kolem Cancúnu a o tom, jak by se měl proces upgradu sítě vyvíjet, aby lépe zachytil preference komunity
Protokolový pilot guildy skončí a my oznámíme post-pilotní strukturu.