Ether moviĝas al Pruvo de Intereso (PoS)!Ĉi tiu transiro nomiĝas La Kunfandado, kaj ĝi unue estos aktivigita sur la signostanga ĉeno per Bellatrix-ĝisdatigo.Post tio, la ĉeno Proof of Work (PoW) de Ether migros al Proof of Stake (PoS) kiam specifa totala malfacilecvaloro estos atingita.
Laŭ la plano, la ĝisdatigo de Bellatrix okazos la 6-an de septembro 2022 je 11:34:47 UTC ĉe la 144896-a epoko de la lumĉeno.
La totala finpunkta malfacilecvaloro por ekigado de la kunfando estas 58750000000000000000000, atendita inter la 10-a kaj la 20-a de septembro 2022.
Noto: Kiel antaŭe anoncite, la Kiln-testreto finiĝas kaj la funkciigisto fermiĝos la 6-an de septembro 2022.
Fono
Post jaroj da malfacila laboro, la PoS-ĝisdatigo por Ethernet finfine estas ĉi tie!Ĉiuj publikaj testaj retoj nun estis sukcese ĝisdatigitaj, kaj kunfanda ĝisdatigo de la ĉefa EtherNet estis planita.
La kunfandiĝo diferencas de antaŭaj retaj ĝisdatigoj laŭ du manieroj.Unue, nodfunkciigistoj devas ĝisdatigi ambaŭ siajn klientojn de Interkonsenta Tavolo (CL) kaj Execution Layer (EL), ne nur unu el ili.Due, la ĝisdatigo estas aktivigita en du fazoj: la unua fazo, nomita Bellatrix, estos kompletigita je certa epoka alteco sur la signostango, kaj la dua fazo, nomita Parizo, estos kompletigita kiam la ekzekuttavolo atingas antaŭdifinitan totalan malfacilecon. valoro.
Ĝisdatigu informojn
Tempo
La kunfando estas dividita en du ŝtupojn;la unua paŝo estas Bellatrix reto ĝisdatigo ekigita ĉe la konsenta tavolo ĉe certa epoko alteco.La ekzekuttavolo tiam transiras de Pruvo de Laboro (PoW) al Pruvo de Stake (PoS), paŝo konata kiel Parizo, kiu estas ekigita post kiam la totala malfacilecvaloro de TTD atingas antaŭfiksitan valoron.
La ĝisdatigo de Bellatrix estas planita por la 6-a de septembro 2022 je la 11:34:47 UTC kiam la altlumo de la lumĉeno atingas 144896.
La ĝisdatigo de la ekzekutiva nivelo, Parizo, estos ekigita kiam la totala TTD-malfacilvaloro atingas 5875000000000000, kio estas atendita okazi inter la 10-a de septembro - la 20-a de septembro 2022. La preciza dato de atingi TTD dependas de la pruva aritmetiko, kaj taksoj por la transira tempo troveblas ĉe bordel.wtf kaj 797.io/themerge.
Post kiam la ekzekuttavolo atingas aŭ superas la antaŭfiksitan TTD-valoron, la signostanga ĉenkontrolilo generos postajn blokojn.Post kiam la signostangoĉeno kompletigas la blokon, tiam la kunfanda transiro estas konsiderita kompleta.Sub normalaj retaj kondiĉoj, tio okazos 2 epokojn (aŭ ĉirkaŭ 13 minutojn) post kiam la unua 'post-TTD-bloko' estos generita!
Nova JSON-RPC-bloka etikedo, finpretigita, resendas la lastan finan blokon, aŭ eraron se tia post-kunfanda bloko ne ekzistas.Aplikoj povas uzi ĉi tiun etikedon por kontroli ĉu la kunfando finiĝis.Simile, inteligentaj kontraktoj povas pridemandi la DIFFICULTY-opkodon (0 x44) (renomitan PREVRANDAO post la kunfando) por determini ĉu la kunfando okazis.Ni rekomendas, ke infrastrukturaj provizantoj monitoru la ĝeneralan retan stabilecon krom la fina stato.
Kliento-Eldonoj
La sekvaj klienteldonoj subtenas kunfandi ĝisdatigojn sur la ĉefa Ethernet-reto.Notu, ke nodfunkciigistoj devas funkcii kaj ekzekutajn kaj konsentajn tavolklientojn por resti sur la reto dum kaj post la kunfando.
Elektante kiun klienton kuri, kontrolintoj devas precipe atenti la riskojn prizorgi la plej multajn klientojn ĉe EL kaj CL.Vi povas trovi klarigon pri ĉi tiuj riskoj kaj iliaj sekvoj ĉi tie.Vi ankaŭ povas trovi taksojn pri la distribuado de ekzekutitaj kaj konsentaj tavolaj klientoj, kaj ankaŭ gvidliniojn por ŝanĝi de unu kliento al alia, ĉi tie.
Interkonsentaj Tavolaj Klientoj
Plenuma Tavola Kliento
Averto: geth v1.10.22 versio-kliento enhavas gravajn datumbazajn problemojn, bonvolu ne uzi ĉi tiun version, se vi uzas ĉi tiun version-klienton, bonvolu ĝisdatigi al v1.10.23 kiel eble plej baldaŭ.
Altgradiga Specifo
La kunfanditaj konsentaj ŝlosilaj ŝanĝoj estas precizigitaj en du lokoj.
Interkonsenta tavolo estas ŝanĝita en la Bellatrix-dosierujo de la Konsento-Specifika Deponejo
La ekzekuttavolo ŝanĝiĝas sub la Pariza specifo en la ekzekutspecifodeponejo
Aldone al tio, du aliaj specifoj kovras kiel la konsentotavolo kaj ekzekuttavolo klientoj interagas.
La Engine API specifita en la ekzekut-apis-deponejo por komunikado inter la konsento kaj ekzekuttavoloj
Optimistic Sync, specifita en la Synchronization-dosierujo de la Konsensus-specifa deponejo, estas uzata de la konsenta tavolo por importi blokojn kiam la ekzekuttavola kliento sinkronigas, kaj disponigas partan vidon de la ĉenkapo de la unua ĝis la lasta.
Kunfandi Vulnerability Bounty Program
Inter nun kaj la 8-a de septembro, ĉiuj kunfand-rilataj ekspluatpremioj havos 4x-multiplikaton.Severaj vundeblecoj povas esti ĝis $ 1 miliono.
Por pliaj detaloj, vidu la Programon pri Vulnerability Bounty.
Oftaj Demandoj
1. Kiel noda operatoro, kion mi faru?
Post la fuzio, la Ether Plena Nodo estas kombinaĵo de Interkonsenta Tavolo (CL) kliento, kiu prizorgas la Proof of Stake lumbran ĉenon, kaj Execution Layer (EL) kliento, kiu administras uzantŝtaton kaj kuras transakciajn kalkulojn.La klientoj de Execution Layer (EL) kaj Consensus Layer (CL) komunikas per aŭtentikigitaj havenoj uzante novan aron de JSON RPC-metodoj nomitaj Engine API.La klientoj de Execution Layer (EL) kaj Consensus Layer (CL) uzas JWT-ŝlosilojn por aŭtentikigi unu kun la alia.Por instrukcioj pri kiel generi kaj agordi ĉi tiun valoron, nodfunkciigistoj devus raporti al la dokumentado de sia kliento.
Alivorte, se vi jam kuras nodon sur signostanga ĉeno, tiam vi nun devas ankaŭ ruli Execution Layer-klienton.Simile, se vi kuras nodon en via nuna pruvo-de-labora reto (PoW), tiam vi ankaŭ devas ruli konsentan tavolklienton.Por ke ili sekure komunikiĝu, JWT-ĵetono devas esti transdonita al ĉiu kliento.La sekcio "Running a Node" de ethereum.org de la retejo estas ĝisdatigita por priskribi ĉi tiujn paŝojn pli detale.
Indas substreki, ke dum ili ambaŭ estas parto de la konsenta tavola klientversio, ruli lumĉennodon diferencas de ruli kontrolilon.Promesantoj devas ruli ambaŭ, dum nodfunkciigistoj nur bezonas ruli la unuan.Ĉi tiu artikolo klarigas la diferencon inter ĉi tiuj du komponantoj pli detale.
Ankaŭ, notu, ke ĉiu tavolo konservos apartan aron de samrangaj nodoj kaj elmontros sian propran API.kaj la Beacon kaj JSON RPC-APIoj daŭre funkcios kiel atendite.
2. Kion mi devas fari kiel promeson?
Kiel menciite supre, kontrolilo sur signostanga ĉeno devos kuri la ekzekuttavolan klienton post la kunfando aldone al la konsenta tavolo-kliento.Estas tre rekomendite, ke promesantoj faru tion antaŭ la fuzio, sed iuj validigiloj subkontraktis ĉi tiujn funkciojn al triaj provizantoj.Ĉi tio eblas ĉar la solaj datumoj necesaj por la ekzekuta tavolo estas la ĝisdatigo de la deponejo.
Post la fuzio, la validigiloj devas certigi, ke la uzanttransakcioj kaj ŝtattransirblokoj, kiujn ili kreas kaj pruvas, estas validaj.Por fari tion, ĉiu signostanga ĉennodo devas esti parigita kun ekzekuttavola kliento.Notu ke multoblaj validigiloj daŭre povas esti parigitaj kun ununura signostanga ĉennodo kaj ekzekuttavola klientkombinaĵo.Ĉi tio pligrandigas la respondecon de la validisto, sed ankaŭ rajtigas la validiston, kiu proponas la blokon al la rilata transakcia prioritatkotizo (kiu nuntempe apartenas al la ministo).
Dum kontrolilaj rekompencoj daŭre estas generitaj sur la signostango kaj postulas postan retan ĝisdatigon esti retirita, transakciaj kotizoj estos pagitaj, detruitaj kaj distribuitaj sur la ekzekuttavolo.Kontrolantoj povas indiki ajnan Ether-adreson kiel la ricevanto de la transakcia kotizo.
Post ĝisdatigi la konsentan klienton, nepre agordu la kotizricevanton kiel parton de la aŭtentikila klienta agordo por certigi, ke transakciaj kotizoj estas senditaj al la adreso, kiun vi kontrolas.Se vi uzas triapartan provizanton por promeso, dependas de la provizanto, kiun vi elektas, specifi kiel ĉi tiuj kotizoj estas asignitaj.
Staking Launchpad havas firmigitan pretecan kontrolon, kiun promesantoj povas uzi por certigi, ke ili plenumis ĉiun paŝon de la procezo.EthStaker ankaŭ gastigas laborrenkontiĝojn pri validigilo-preteco kaj planas gastigi pliajn laborrenkontiĝojn.
Promesantoj dezirantaj funkciigi validigilojn sur la testreto en preparo por la ĉefa reto PoS-konverto povas fari tion sur la Goerli-testreto (kiu nun kompletigis la fuzion), kiu ankaŭ havas Staking Launchpad-instancon.
3. Kial ekzistas tiom ampleksa gamo da atendataj datoj por Tuta Terminala Malfacilaĵo (TTD)?
La malfacileco aldonita al ĉiu bloko dependas de la malstabila reta aritmetiko, kaj se pli da aritmetiko aliĝas al la reto, la TTD estos atingita pli frue.Simile, se aritmetika potenco forlasas la reton, la TTD-alventempo estos prokrastita.En la kazo de signifa falo en fortonivelo, TTD-priraporta valoro povas esti kunordigita kiel estis farita sur la Ropsten-testreto.
4. Kiel programisto de aplikaĵo aŭ ilo, kion mi faru?
Kiel menciite en la antaŭa artikolo, la efiko de la kunfandiĝo sur la subaro de kontraktoj deplojitaj sur Etherpad estas minimuma kaj ĉiuj kontraktoj ne devas esti rompitaj.Krome, plej multaj uzantaj API-finpunktoj restos stabilaj (krom se vi uzas specifajn metodojn pri laborŝarĝaj pruvoj kiel eth_getWork).
Dirite, plej multaj aplikoj sur ethereum implikas multe pli ol ĉenaj kontraktoj.Nun estas la tempo certigi, ke antaŭfina kodo, iloj, disfaldaj duktoj kaj aliaj eksterĉenaj komponantoj funkcias kiel atendite.Ni forte rekomendas, ke programistoj rulu plenan teston kaj disfaldan ciklon sur Sepolia aŭ Goerli kaj raportu ajnajn ilajn aŭ dependecajn problemojn al la prizorgantoj de tiuj projektoj.Se vi ne certas, kie malfermi problemon, bonvolu uzi ĉi tiun deponejon.
Ankaŭ, bonvolu noti, ke ĉiuj testretoj, krom Sepolia kaj Goerli, estos malrekomenditaj post la fuzio.Se vi estas uzanto de Ropsten, Rinkeby aŭ Kiln, vi devus plani migri al Goerli aŭ Sepolia.por pliaj informoj pri tio, vidu ĉi tie.
5. Kiel Ether-uzanto aŭ ETH-posedanto, kion mi devas fari?
Ĉu vi uzas Ether-apon en la ĉeno, ĉu vi tenas ETH en interŝanĝo aŭ ĉu vi havas monujon en via propra gardado, vi ne bezonas fari ion ajn.Se la aplikaĵo, interŝanĝo aŭ monujo, kiun vi uzas, provizas pliajn instrukciojn aŭ konsilojn, vi devus kontroli, ke ĉi tiuj instrukcioj aŭ konsiloj venas de ili.Bonvolu zorgi pri fraŭdoj!
6. Ĉu estas io alia, kion mi povas fari kiel ethereum-ministo?
Ne. Se vi minas sur la ĉefa Ethernet-reto, vi devus scii, ke post la kunfandiĝo, la reto funkcios tute sub la Proof of Stake (PoS) algoritmo, kaj ĉe tiu punkto, POW-minado ne plu eblos.
7. Kio okazas se mi estas ministo aŭ nodfunkciigisto kaj mi ne estas implikita en la ĝisdatigo?
Se vi uzas ethereum-klienton, kiu ne estis ĝisdatigita al la plej nova versio (kiel listigita supre), via kliento estos sinkronigita al la antaŭforka blokĉeno post kiam la reto kompletigis la ĝisdatigon.
Vi estos blokita sur nekongrua ĉeno, kiu sekvas la malnovajn regulojn kaj ne povos sendi Ether-monerojn aŭ funkcii en la kunfandita Ether-reto.
8. Kiel kontrolisto, ĉu mi povas retiri mian promesitan ETH-interezon?
Ne. La fuzio estas la plej kompleksa ĝisdatigo al Ether ĝis nun, kaj por minimumigi la riskon de retaj malfunkcioj, ni prenis minimumisman aliron, kiu ekskludas ajnajn netransirajn ŝanĝojn en ĉi tiu ĝisdatigo.
Retiroj de la signostanga ĉeno eble devos esti lanĉitaj en la unua ĝisdatigo post la fuzio.Specifoj por la Interkonsento kaj Execution tavoloj estas evoluantaj.
9. Mi havas pliajn demandojn, kie mi povas demandi ilin?
Okazos komunuma voko pri la fuzio la 9-an de septembro je 14:00 UTC, kie vi povas aliĝi kun klientaj programistoj, membroj de ETHStaker, esploristoj kaj pli!
Dankon!
La transiro al Proof of Stake (PoS) por Ether estas en la laboroj dum longa tempo.Dankon al ĉiuj, kiuj kontribuis esplori, disvolvi, analizi, testi, rompi, ripari aŭ klarigi ĉion pri la Kunfandado (La Kunfandado).
Estas tro multaj kontribuantoj por listigi ĉi tie tra la jaroj, sed vi scias, kiu vi estas.Ni ne povus konstrui ĉi tiun katedralon sen vi ĉiuj.
Kiam okazos la fuzio?Estos tre baldaŭ.
Afiŝtempo: Aŭg-26-2022