Oriģinālais nosaukums: "Ethereum Core Developer Meeting Update 014"
Sākotnējais avots: AllCoreDevs atjauninājums
Oriģinālais autors: Tim Beiko
Oriģinālā kompilācija: Ethereum.cn
Laipni lūdzam jaunajā AllCoreDevs (Ethereum Core Developer Conference) atjauninājuma izdevumā — pēdējā 2022. gada atjauninājumā.
pārskats
Šanhajas/Capella jauninājuma saturs ir pabeigts: izņemšana, EOF un dažas nelielas modifikācijas... ar nosacījumu, ka tās neaizkavē izņemšanu.
Tuvojas lāse: EIP-4844 būs Ethereum nākamā jauninājuma centrā, un drīz sāksies tā izsaukšanas ceremonija.
No tehniskās puses tiek veikti pasākumi, lai koordinētu izpildes slāņa un konsensa slāņa jaunināšanas procesus. Mēs arī redzam aktīvas diskusijas par labāku sabiedrības ieguldījuma iekļaušanu procesā.
Protokola ģilde ir izlaidusi vidēja termiņa izmēģinājuma ziņojumu un aptuvenu plānu, lai paplašinātu pirmā līmeņa uzturētājus un labāk atbalstītu tos 2023. gadā.
Šanhajas/Capella jauninājums
Nesenajā AllCoreDevs klientu komanda panāca vienprātību par Šanhajas/Capella jaunināšanas galīgo apjomu. Lai gan jauninājuma nosaukums var būt debatēts, komanda ir skaidra par tā darbības jomu. Jauninājuma galvenā iezīme ir Beacon Chain izņemšanas ieviešana stakeriem. Klientu komanda nevēlas pieļaut šīs funkcijas pēc iespējas ātrāku izlaišanu, tāpēc citiem jaunināšanas līdzekļiem ir jābūt gataviem vienlaikus, pretējā gadījumā pastāv risks, ka tās tiks pamestas.
Šanhajas izpildslāņa specifikācijā ir uzskaitīti visi iekļautie EIP:
EIP-3540: EVM objekta formāts (EOF) v1
EIP-3651: samaziniet gāzes izmaksas, lai piekļūtu COINBASE adresēm
EIP-3670: EOF — koda pārbaude
EIP-3855: pievienots darbības kods PUSH 0
EIP-3860: ierobežojiet sākuma koda lielumu un ieviesiet gāzes uzskaiti
EIP-4200: EOF - statisks relatīvais lēciens
EIP-4750: EOF - Importēšanas funkcijas
EIP-4895: Bākas ķēdes izvilkšana kā sistēmas darbība
EIP-5450: EOF — kaudzes pārbaude
Lai gan saraksts ir garš, to var iedalīt trīs dažādās daļās: nelieli uzlabojumi, EVM objektu formāti un atsaukumi. Tālāk mēs tos iepazīstināsim pa vienam:
Nelieli uzlabojumi
EIP-3651: silta COINBASE (samazināt gāzes izmaksas, piekļūstot COINBASE adresēm)
Šis EIP novērš EIP-2929 pārkāpumu, kurā tika mainītas gāzes izmaksas par piekļuvi noteiktiem datu laukiem, pamatojoties uz to, vai dati jau bija klienta atmiņā (SILTI) vai tie bija jāizgūst no diska (COLD).
EIP-2929 katra darījuma sākumā klienta atmiņā iestata divus datu gabalus uz WARM: nosūtīšanas adresi un saņemšanas adresi. EIP-3651 pievieno šim sarakstam trešo adresi, COINBASE adresi (t.i., feeRecipient), jo tā ir arī adrese, kas klientam ir atmiņā, apstrādājot bloku darījumus.
EIP-3855: PUSH 0 instrukcija (jauns operācijas kods PUSH 0)
Kā norāda nosaukums, EIP-3855 ievieš operācijas kodu, kas nospiež skursteņa vērtību 0. Nospiežot 0, bieži izmanto vērtību aizpildīšanai EVM, šis operācijas kods nodrošinās efektīvāku un lētāku veidu, kā to izdarīt.
EIP-3860: ierobežojiet un skaitītāja sākuma kodu (ierobežojiet sākuma koda lielumu un ieviesiet gāzes uzskaiti)
Šis EIP pievieno sākuma koda lieluma ierobežojumu un ievieš gāzes mērīšanu, pamatojoties uz tā garumu. Tā augšējā izmēra ierobežojums pievieno EVM invariantu, padarot to vieglāk saprotamu un ierosinātu modifikācijas.
Ievieš pieskaitāmās izmaksas 2 gāzes uz 32 baitiem sākuma kodam, ko izmanto, lai samaksātu par vislielāko analīzi, kas klientam jāveic pirms izpildes, un kas nav norādīta gāzes skaitītājā.
objekta formāts
Lielākā daļa EIP, kas iekļauta Šanhajas jauninājumā, faktiski ir daļa no vienas funkcijas: EVM objektu formāta (EOF). Darbs tika sadalīts 5 dažādos EIP, lai palīdzētu klientu izstrādātājiem izprast katru atsevišķu modifikāciju, taču, lai sniegtu augstāka līmeņa pārskatu, izstrādātāji izlaida vienotu specifikāciju. Šo piecu EOF EIP ir:
EIP-3540: EVM objekta formāta versija 1
EIP-3670: EOF — koda pārbaude
EIP-4200: EOF - statisks relatīvais lēciens
EIP-4750: EOF - Importēšanas funkcijas
EIP-5450: EOF — kaudzes pārbaude
Ir vērts atzīmēt, ka pirmais EOF solis bija Londonas jauninājums EIP-3541, kas EOF līgumam rezervēja prefiksu 0xEF 00. Pēdējo mēnešu laikā ir mainījies arī Šanhajas jauninājuma EOF apjoms.
Februārī klientu komanda piekrita apsvērt iespēju veikt jaunināšanu Šanhajā, lai iekļautu divus mazākos EOF EIP: EIP 3540 un 3670. Tie visi kalpos kā pamatelementi, taču nenodrošinās pilnu funkcionalitāti bez EIP 4200, 4750 un 5450 ieviešanas. Lai gan ir iespējams paplašināt EOF, atpakaļejošas nesaderības dēļ var būt nepieciešama jauna versija. Tā kā pirms-EOF vai EOF līgumiem ar noteiktu versiju vienmēr jābūt izpildāmiem, katra jauna EOF versija nozīmē, ka klientu izstrādātājiem ir jāuztur jauns EVM izpildes noteikumu kopums paralēli vecajiem noteikumiem.
Pirms EOF klienti vienlaikus uzturēja tikai vienu EVM noteikumu kopu. Kodu bāze atbalsta arī iepriekšējos EVM noteikumus, kas tiek mainīti ar katru tīkla jaunināšanu, taču, tiklīdz tie sasniedz blokķēdes galvu, ir jāpiemēro tikai jaunākie noteikumi. Pēc EOF izvietošanas klients uzturēs divas paralēlas EVM noteikumu kopas, lai varētu izpildīt kodu EOF un ne-EOF līgumos. Citiem vārdiem sakot, palielinot EOF versijas, palielinās paralēlo, nevis secīgo EVM noteikumu kopu skaits, kas jāuztur.
Šim nolūkam pēdējo dažu mēnešu laikā klientu komandas ir sākušas atbalstīt "lielo EOF" pieeju. Tādā veidā, lai gan tiem ir jāievieš lielākas modifikāciju kopas, EOF versija kalpos ilgāk un samazinās "paralēlo EVM" skaitu, kas jāuztur. Tāpēc izstrādātāji uzskatīja par "lielo EOF" un galu galā iekļāva to Šanhajas jauninājumā.
Tas nozīmē, ka lielākas funkcijas acīmredzami ir grūtāk ieviest un pārbaudīt, un komanda nevēlas redzēt, ka EOF nopietni aizkavē bākas ķēdes izņemšanu. Tāpēc, ja EOF ieviešana nav pabeigta līdz janvārim un viņi nevar ātri sadarboties savā starpā, klientu komanda piekrīt pārvietot EOF no Šanhajas, lai veiktu jaunināšanu.
Paturot prātā šos kontekstus, tagad īsi iepazīstināsim ar katru EOF EIP:
EIP-3540: EVM objekta formāta (EOF) v1 (EVM objekta formāta 1. versija)
Šī EIP ievieš "konteineru" EOF līgumā. Tas pievieno tagus, lai atšķirtu līguma koda un datu daļas, un neļauj izvietot EOF līgumus, kas neatbilst formātam. Tas garantē, ka jebkurš ķēdes EOF līgums atbilst derīgam formātam, kas vienkāršo mijiedarbību ar šiem līgumiem, kā arī to statisko analīzi.
EIP-3670: EOF — koda apstiprināšana (EOF — koda apstiprināšana)
Pamatojoties uz konteineru, ko ieviesa 3540, EIP-3670 nodrošina, ka EOF līgumā iekļautais kods ir derīgs vai novērš tā izvietošanu.
Tas nozīmē, ka nedefinētus operācijas kodus nevar izvietot EOF līgumos, un tam ir papildu ieguvums, jo tiek samazināts pievienojamo EOF versiju skaits. Ja tiek pievienots jauns operācijas kods, validācijas noteikumus var vienkārši mainīt, lai to iespējotu un nodrošinātu, ka neviena izvietotā EOF līgumā uz to nav atsauces savā koda sadaļā.
EIP-4200: EOF — statiski relatīvie lēcieni (EOF — statiski relatīvie lēcieni)
EIP-4200 ievieš pirmos EOF specifiskos operācijas kodus: RJUMP, RJUMPI un RJUMPV, kas kodē galamērķus kā parakstītas tūlītējas vērtības. Šos jaunos JUMP operācijas kodus var izmantot kompilatori, lai optimizētu pieskaitāmās gāzes izmaksas, jo tie novērš vajadzību pēc izpildlaika jumpdest analīzes, kas nepieciešama esošajiem JUMP un JUMPI operāciju kodiem.
EIP-4750: EOF — funkcijas (EOF ieviestās funkcijas)
EIP-4750 iet soli tālāk par 4200: tas neļauj izmantot JUMP & JUMPI operācijas kodus un pievieno alternatīvas funkcijām, kuras nevar kopēt. Tas tiek ieviests, ieviešot īpašas funkciju sadaļas EOF baitkodā. Šīs funkcijas var pāriet no jaunajiem JUMPF, CALLF un RETF operāciju kodiem un izmantot tos, lai izsauktu un atgrieztos.
EIP-5450: EOF — Stack Validation (EOF Stack Validation)
Visbeidzot, EIP-5450 pievieno vēl vienu EOF līgumu validācijas pārbaudi, šoreiz ap kaudzi. Šis EIP neļauj EOF līgumiem izvietot kodu, kas var izraisīt steka nepietiekamību un dažos gadījumos pārpildīšanu. Izmantojot šo EIP, klienti var samazināt validācijas pārbaužu skaitu, izpildot EOF līgumus, jo viņiem ir labākas garantijas par izņēmumiem, kas saistīti ar steku.
Kā eksperts, kas nav EVM un kurš ļoti koncentrējas uz pašu EIP, es par to nevaru daudz ko teikt! Ja lasītāji vēlas uzzināt vairāk par EOF, iesaku attiecīgos tvītus, ko publicējuši lightclients no Geth komandas un Leo no Solidity komandas.
Bākas ķēdes izņemšana
Visbeidzot, galvenā "Shapella" daļa (tulkotāja piezīme: Šanhajas/Capella kolektīvais nosaukums) ir bākas ķēdes izņemšana. Šī izmaiņu daļa ir aprakstīta konsensa slāņa specifikācijā un EIP-4895. Tagad ir nedaudz novecojusi metaspecifikācija, kas saista šīs izmaiņas.
Augstā līmenī izņemšanas mehānismi ir šādi:
Ierosinot bloku, validators lineāri skenē validatora indeksu, lai atrastu pirmos 16 pārbaudītājus ar 0x01 akreditācijas datiem, kuriem jāatbilst vienam no šiem nosacījumiem:
Jums ir jābūt bilancei virs 32 ETH (t.i., jums ir uzkrātas validatora atlīdzības)
ir izņemami (t.i., ir pilnībā izgājuši no validatora kopas)
Atlikums ir lielāks par 32 ETH (tas ir, ir iegūta pārbaudītāja atlīdzība)
Tas ir izņemams (izņemams, tas ir, tas ir pilnībā iziet no validatora kopas)
No tiem pārbaudītājs izveidos izņemšanas gadījumu sarakstu, kas jāiekļauj viņu ExecutionPayload. Katrs šī saraksta vienums satur šādu informāciju:
Validators izveidos izņemšanas sarakstu no šiem pārbaudītājiem un iesaiņos to savā ExecutionPayload. Katrs saraksta vienums satur šādu informāciju:
Izņemšanas indekss: visu veikto izņemšanas darījumu rādītājs — tas palīdz atšķirt vienas un tās pašas summas izņemšanu no vienas adreses, tā paša validatora.
ValidatorIndex: validatora indekss, kurā tika palielināts atlikums
ExecutionAddress: izpildes slāņa ETH adrese, uz kuru jānosūta naudas izņemšana
Summa: summa, kas nosūtīta uz ExecutionAddress, šī summa tiek mērīta gwei (nevis wei)
Izpildes slāņa klienti veiks izņemšanu pēc transakciju izpildes, veidojot vai apstrādājot blokus. Citiem vārdiem sakot, izņemšana tiek apstrādāta līdzīgi, kā tiek reģistrēta atlīdzība par darba apliecinājumu, un tā nekonkurē ar lietotāju darījumiem par bloka vietu.
Ir arī dažas citas nianses, kuras vērts pievērst uzmanību:
Apstrādājot naudas izņemšanu, nav atšķirības prioritātē/pasūtījumā starp "pilnajiem līdzekļiem" un "daļējiem līdzekļiem". Pilna izņemšana notiek, kad validators atstāj izejas komandu, savukārt daļēja izņemšana notiek periodiski, tas ir, kad tiek veikta validatora komplekta lineāra skenēšana un tiek skenēts noteikta validatora indeksa numurs.
Lai naudas izņemšana tiktu apstrādāta, pārbaudītājiem ir jāizmanto 0x01 akreditācijas dati, kurus attēlo ETH adreses. Kad bākas ķēde darbojas tiešsaistē, ir atļauti tikai BLS atslēgu pāra 0x00 akreditācijas dati. Lai sāktu izņemšanu, pārbaudītājam ar 0x00 akreditācijas datiem būs jāparaksta ziņojums BLSToExecutionChange. Tie tiks aktivizēti Capella jauninājumā. Lai parakstītu šo ziņojumu, tiks izmantoti dažādi rīki, un pārbaudītāji var sagaidīt atbalstu un apmācības par šiem rīkiem.
Validatoru skenēšana notiek katrā blokā. Ja pēc validatora kopas apakškopas skenēšanas nav jāapstrādā 16 izņemšanas gadījumi, pārbaudītājs pārtrauks skenēšanu un nākamais validators sāks no pēdējā skenētā validatora indeksa.
Kā parasti, būs vairāki izstrādātāju testtīkli un testtīkli (varbūt pat daži jauni testtīkli!), lai pārbaudītāji varētu palaist visu procesu un novērst visus traucējumus, pirms galvenais tīkls sāk darboties.
Shanghai/Capella nav vienīgais jauninājums, kas progresē! Izstrādātāju komanda joprojām gaida nākamo jaunināšanu.
Kankunas jauninājums
Tā kā Šanhajas jauninājuma saturs jau ir pilns, daudzi EIP (CFI), kas tika apsvērti jaunināšanai, nav varējuši iekļūt Šanhajas jauninājumā. Klientu komanda sāk apspriest, kuras EIP būtu jāņem vērā nākamajam jauninājumam: Kankunas jaunināšanai (konsensa slāņa nosaukums ir jānosaka)
Runājot par vienprātības slāni, EIP-4844 ir kļuvis par pirmo EIP, kas iekļauts specifikācijā pēc Capella jaunināšanas. Nav (pagaidām) specifikācijas izpildslānim, kas varētu ieviest šo izkārtojumu, taču izpildslāņa komanda piekrita iet līdzīgu ceļu un centrēt EIP-4844 nākamajā jaunināšanā.
Pēc konvencijas par jauninājumiem, izmantojot to pilsētu nosaukumus, kurās notika Devcon, tika izveidots cancun.md, kurā EIP-4844 ir oficiāli iekļauts jaunināšanā.
Šāds lēmums tika pieņemts pēdējā 2022. gada AllCoreDevs sanāksmes pēdējā minūtē, tāpēc nebija laika strādāt pie citiem priekšlikumiem. EIP, kas tika iekļauti CFI jaunināšanā Šanhajā, bet beigās netika iekļauti, tika pārvietoti uz CFI sarakstu Kankunas jauninājumam. Tika atvērta ziņa arī Ethereum Magicians forumā, lai apspriestu EIP kandidātus Kankunā. Diskusijas par jauninājumu apjomu Kankunā nopietni jāsāk nākamā gada sākumā.
KZG ceremonija
Vēl viena lieta, ko gaidīt saistībā ar Kankunas jaunināšanu, ir KZG ceremonija, kas ir EIP-4844 prasība.
Šis rituāls radīs nejaušību, kas nepieciešama, lai pārbaudītu blob datu derīgumu. Lai to uzskatītu par drošu, godīgam jābūt tikai vienam dalībniekam. Citiem vārdiem sakot, ja visi dalībnieki, izņemot vienu, sadarbojas, viss process ir kriptogrāfiski drošs.
Ceremonija sākas janvārī un būs atvērta ikvienam vairākus mēnešus. Plānots, ka tā būs līdz šim lielākā šāda veida ceremonija, kuras mērķis ir 10 000 dalībnieku! Ja vēlaties, lai jūs nepalaistu garām, sekojiet Trentam Van Epsam Twitter!
Jaunināšanas process pēc apvienošanās
Kā minēts iepriekšējā atjauninājumā, pēc apvienošanas Ethereum jaunināšanas procesa koordinēšana izpildes slānī un vienprātības slānī ir svarīgs uzdevums. No augsta līmeņa perspektīvas izpildes slānis izmanto Yellow Paper & EIP, lai aprakstītu modifikācijas, savukārt vienprātības slānis izmanto izpildāmās Python specifikācijas.
Izpildvaras procesa priekšrocība ir tāda, ka EIP ir labi zināma sabiedrībai un ir veidota tā, lai skaidri parādītu priekšlikuma pamatojumu. Dzeltenās grāmatas ar lielu matemātisku saturu, kas savienotas pārī ar EIP, un nepieciešamība atkal ievietot specifikācijas katras EIP kontekstā, padara izpildes slāņa specifikācijas grūti saprotamas un paplašināmas.
Problēma ar konsensa slāni ir pretēja: tam ir skaidra un saprotama specifikācija vienā repozitorijā, bet izmaiņas nav taustāmas un priekšlikumi tiek aprakti citos repozitorijas publiskajos PR.
Ieviešot Ethereum izpildes slāņa specifikāciju, mēs ceram saīsināt šo plaisu no izpildes slāņa puses. Un, ja process ir strīdīgs, mēs varētu panākt, lai EIP tiktu iekļauts vienprātības slāņa procesā!
Tomēr, apspriežot un pabeidzot Šanhajas jaunināšanas apjomu, kļuva skaidrs, ka, iespējams, trūkst vēl vienas procesa daļas: ļaut kopienai izteikt savas relatīvās izvēles izmaiņas un iesaistīties diskusijās par visu jaunināšanas apjomu (nevis atsevišķi EIP) Apspriediet to savā vietā un iekļaujiet to AllCoreDevs un vienprātības līmeņa sanāksmju lēmumos.
Pagaidām nav skaidrs, kā tas izskatīsies – labprāt saņemtu ieteikumus! — taču, pieaugot protokola izmaiņās aktīvi iesaistīto ieinteresēto personu skaitam, kā arī 1. slāņa izmaiņu skarto apgabalu skaitam, bija skaidrs, ka mums kaut kas ir vajadzīgs.
Par laimi, mums nav jāsāk no nulles. Ethereum Magicians pastāv jau gadiem ilgi, un tās bezsaistes tikšanās, īpašas grupu sanāksmes vai kopienas sanāksmes var būt labs sākumpunkts paplašināšanai.
Gaidiet lielāku progresu šajā jomā 2023. gada sākumā!
Līgumu ģildes atjauninājums
Tā kā Protokola ģildes (PG) izmēģinājuma projekts ir pusceļā, viņi ir izlaiduši ziņojumu, lai apskatītu, kā notiek lietas, un apsvērtu, kādi ir projekta nākamie soļi.
Atgādinām, ka PG ir bezatļauts finansēšanas mehānisms Ethereum Layer 1 klientu izstrādātājiem, protokolu pētniekiem un atbalsta sniedzējiem (piemēram, jums).
Šis mehānisms ir vērsts uz indivīdu, nevis organizāciju. Īsāk sakot, katrs dalībnieks ir tiesīgs saņemt daļu no ģildes žetoniem, kas tiek svērti atkarībā no tā, cik ilgi viņi ir ieguldījuši Ethereum. Dalībnieku pievienošana un dzēšana tiek veikta īstā Ethereum veidā, pamatojoties uz standartu kopumu un aptuvenu vienprātību PG. Pēc tam šis saraksts tiks ievietots ķēdē, izmantojot 0xSplit sadalīšanas līgumu. Pēc tam ziedotājs var nosūtīt līdzekļus tieši uz saņēmēja adresi vai uz piešķiršanas līgumu, kas atbrīvo līdzekļus uz saņēmēja adresi.
Izmēģinājuma starpziņojums ir apkopots šajā tvītā. Šeit ir daži svarīgākie punkti
Izmēģinājuma ietvaros tika savākti 9,7 miljoni USD no tādām organizācijām kā Lido, Uniswap, ENS, NounsDAO un MolochDAO, kā arī regulārie ziedotāji no privātpersonām (paldies Tetranode!) — paldies visiem, kas to padarīja iespējamu!
PG uzsākšanas brīdī bija 90 biedri, un tagad tajā ir 128, un starp viņiem ir sadalīti 5 miljoni USD
Vidēji katrs dalībnieks saņēma USD 39 000, zemākais bija USD 13 000 un augstākais sasniedza USD 79 000
PG arhitektūra mainās, un tā atbalstīs L2 un novērsīs nepieciešamību pēc vairākiem signāliem, lai atjauninātu svarus
Šie agrīnie rezultāti liecina, ka PG darbojas, kā plānots: mehānisms, lai izplatītu marķieru grozu pašinkubējošai, augošai protokolu līdzstrādnieku grupai. Šis projekts nebūtu tāds, kāds tas ir šodien, ja nebūtu dāsna izmēģinājuma ziedotāju atbalsta.
Raugoties nākotnē, tagad ir pienācis laiks paplašināt PG sasniedzamību un pilnībā realizēt tā potenciālu: nodrošināt Ethereum uzturētājiem konkurētspējīgu, riskam pielāgotu atlīdzību. Visvieglāk šeit ir projektam jau no paša sākuma ziedot PG, kā Denijs Raiens teica tvītā, uzsākot PG.
Pilotā lielākā daļa ziedojumu gūta no lieliem projektiem ar lielu finansējumu. Ja Protokola ģilde var pārliecināt šos projektus ziedot PG jau no pirmās dienas, kad to marķieri joprojām ir patiesi “bezvērtīgi”, tad Ethereum uzturētāji var gūt labumu no visu šo veiksmīgo projektu augšupejas trajektorijas.
Ja ir iesaistīts pietiekami daudz projektu, stimuli var saglabāt labākos talantus uzturēšanas līgumos, nevis atņemt tos.
Lai atbalstītu šo un daudzus citus ziedojumu veidus, PG būs jāveic kapitālais remonts. Nākamā versija atbalstīs L1 un L2 un vēl vairāk samazinās tās ķēdes pārvaldības nospiedumu.
Ja esat projekts, kas vēlētos ziedot Protokola ģildei, lūdzu, sazinieties ar mani - mani DM ir atvērti!
Pēcpārbaude
Tas noslēdz 2022. gadu... Kāds neparasts gads! Pirms trim mēnešiem mēs pat nebijām apvienoti! Tagad, kad Ethereum ir pierādījums par likmēm, kas klusi darbojas fonā, uzmanība ir pievērsta turpmākajiem darījumiem.
Tā kā visi atgriežas janvārī, jūs varat sagaidīt:
Shanghai/Capella jaunināts izstrādātāja testtīkls un ēnu dakša
KZG ceremonija notiek tiešsaistē
Diskusijas par Kankunu un to, kā būtu jāattīstās tīkla jaunināšanas procesam, lai labāk atspoguļotu kopienas preferences
Beigsies protokola ģildes pilots un paziņosim pēcpilota struktūru.