Ethereums overgang til proof of stake - The Merge - er tæt på:Devnets er ved at blive rejst op, specifikationer er ved at blive færdiggjort, og community outreach er begyndt for alvor. Sammenlægningen er designet til at have minimal indflydelse på, hvordan Ethereum fungerer for slutbrugere, smarte kontrakter og dapps. Når det er sagt, er der nogle mindre ændringer, der er værd at fremhæve. Før vi dykker ned i dem, er her et par links til at give kontekst om den overordnede Merge-arkitektur:
Resten af dette indlæg vil antage, at læseren er bekendt med ovenstående. For dem, der ønsker at grave endnu dybere, er de fulde specifikationer for The Merge tilgængelige her:
Efter The Merge vil bevis for arbejdsblokke ikke længere eksistere på netværket. I stedet bliver det tidligere indhold af bevis for arbejde en del af blokke oprettet på Beacon Chain. Du kan så tænke på, at Beacon Chain bliver det nye proof of stake-konsensuslag i Ethereum, der erstatter det tidligere proof of work-konsensuslag. Beacon-kædeblokke vil indeholde ExecutionPayloads , som er post-merge-ækvivalenten til blokke på den nuværende proof of work-kæde. Billedet nedenfor viser dette forhold:
For slutbrugere og applikationsudviklere er disse ExecutionPayloads er, hvor interaktioner med Ethereum sker. Transaktioner på dette lag vil stadig blive behandlet af eksekveringslagsklienter (Besu, Erigon, Geth, Nethermind osv.). Heldigvis introducerer The Merge på grund af stabiliteten af eksekveringslaget kun minimale brudændringer.
Efter fletning bliver flere felter, der tidligere var indeholdt i proof of work block headers, ubrugte, da de er irrelevante for bevis for indsats. For at minimere afbrydelse af værktøj og infrastruktur er disse felter sat til 0, eller deres datastrukturs ækvivalent, i stedet for at blive helt fjernet fra datastrukturen. De fulde ændringer af blokeringsfelter kan findes i EIP-3675.
ommers [] RLP([]) =0xc0 ommersHash 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 =Keccak256(RLP([])) sværhedsgrad 0 nonce 0x00000000000000000
Fordi bevis for indsats ikke naturligt producerer ommere (a.k.a. onkelblokke) som bevis på arbejde, er listen over disse i hver blok (ommers ) vil være tom, og hashen på denne liste (ommersHash ) bliver den RLP-kodede hash for en tom liste. Tilsvarende, fordi sværhedsgrad og nonce er funktioner til bevis for arbejde, vil disse blive sat til 0 , mens de respekterer deres byte-størrelsesværdier.
mixHash , et andet minerelateret felt, vil ikke blive sat til 0, men vil i stedet indeholde beacon-kædens RANDAO-værdi. Mere om dette nedenfor.
BLOCKHASH &SVÆRLIGHED opcodes ændringer
Post-fletning, BLOCKHASH opcode vil stadig være tilgængelig til brug, men i betragtning af at den ikke længere vil blive forfalsket gennem proof of work hashing-processen, vil pseudorandomiteten, som denne opcode giver, være meget svagere.
Relateret, SVÆRLIGHED opcode (0x44 ) vil blive opdateret og omdøbt til RANDOM . Efter fletning returnerer den outputtet fra tilfældighedsbeaconet, der leveres af beaconkæden. Denne opcode vil således være en stærkere, omend stadig partisk, kilde til tilfældighed for applikationsudviklere at bruge end BLOCKHASH .
Værdien eksponeret af RANDOM vil blive gemt i ExecutionPayload hvor mixHash , en værdi forbundet med bevis for arbejdsberegning, blev gemt. Nyttelastens mixHash feltet vil også blive omdøbt til tilfældig .
Her er en illustration af, hvordan SVÆRLIGHED &RANDOM opcodes fungerer før og efter fletning:
Før fusion ser vi 0x44 opcode returnerer sværhedsgraden felt i blokoverskriften. Post-fletning, opkoden, omdøbt til RANDOM , peger på overskriftsfeltet, som tidligere indeholdt mixHash og gemmer nu tilfældige værdi fra beacon-kædetilstanden.
Denne ændring, der er formaliseret i EIP-4399, giver også on-chain-applikationer en måde at vurdere, om sammenlægningen er sket. Fra EIP:
Derudover giver ændringer foreslået af denne EIP mulighed for smarte kontrakter til at afgøre, om opgraderingen til PoS allerede er sket. Dette kan gøres ved at analysere returværdien af DIFFICULTY-opkoden. En værdi større end 2**64 angiver, at transaktionen udføres i PoS-blokken.
Sammenlægningen vil påvirke den gennemsnitlige blokeringstid på Ethereum. I øjeblikket under bevis for arbejde kommer blokke i gennemsnit hvert ~13. sekund med en rimelig mængde afvigelser i faktiske blokeringstider. Under bevis for indsats, kommer blokke ind præcis hvert 12. sekund, undtagen når et slot er savnet, enten fordi en validator er offline, eller fordi de ikke indsender en blok i tide. I praksis sker dette i øjeblikket i <1 % af slots.
Dette indebærer en ~1 sekunds reduktion af gennemsnitlige blokeringstider på netværket. Smarte kontrakter, der antager en bestemt gennemsnitlig blokeringstid i deres beregninger, skal tage højde for dette.
Under bevis på arbejde er der altid potentiale for reorganiseringer. Ansøgninger venter normalt på, at flere blokke bliver udvundet oven på et nyt hoved, før de behandler det som usandsynligt at blive fjernet fra den kanoniske kæde eller "bekræftet". Efter The Merge har vi i stedet konceptet færdiggjort og sikkert hoved blokke. Disse blokke kan bruges endnu mere pålideligt end det "bekræftede" bevis for arbejdsblokke, men kræver et skift i forståelse for at kunne bruges korrekt.
En afsluttet blok er en, der er blevet accepteret som kanonisk af>2/3 af validatorerne. For at skabe en modstridende blokering skal en angriber brænde mindst 1/3 af den samlede indsats. I skrivende stund repræsenterer dette over $10 milliarder (eller>2,5 millioner ETH) på Ethereum.
Et sikkert hoved blok er en, som vi under normale netværksforhold forventer at blive inkluderet i den kanoniske kæde. Forudsat netværksforsinkelser på mindre end 4 sekunder, et ærligt flertal af validatorer og ingen angreb på fork-choice-reglen, er det sikre hoved vil aldrig blive forældreløs. En præsentation, der beskriver, hvordan det sikre hoved beregnes under forskellige scenarier, er tilgængelig her. Derudover antagelser og garantier for sikkert hoved bliver formelt defineret og analyseret i et kommende papir.
Efter-fletning vil eksekveringslags API'er (f.eks. JSON RPC) returnere det sikre hoved som standard, når du bliver bedt om den seneste blok. Under normale netværksforhold er det sikre hoved og den faktiske spids af kæden vil være ækvivalent (med sikker hoved, der kun slæber sig et par sekunder). Sikker hoveder vil være mindre tilbøjelige til at blive omorganiseret end det aktuelle bevis på arbejdet seneste blokke. For at afsløre selve spidsen af proof of stake-kæden, en usikker flag vil blive tilføjet til JSON RPC.
Afsluttede blokke vil også blive afsløret via JSON RPC via en ny afsluttet flag. Disse kan så tjene som en stærkere erstatning for bevis for arbejdsbekræftelser. Tabellen nedenfor opsummerer dette:
seneste Forventes, skal bruges med forsigtighed. hoved Indsatsbevis usikker Forventes, skal bruges med forsigtighed. sikkert hoved Indsatsbevis seneste Muligt, kræver enten stor netværksforsinkelse eller angreb på netværket. bekræftet Bevis for arbejde N/A Usandsynligt, kræver et flertal af hashrate for at udvinde en konkurrerende kæde af dybde> # af bekræftelser. afsluttet Indsatsbevis afsluttet Yderst usandsynligt, kræver>2/3 af validatorer for at færdiggøre en konkurrerende kæde, hvilket kræver, at mindst 1/3 skal skæres ned. Vi håber, at dette indlæg hjælper applikationsudviklere med at forberede sig på den længe ventede overgang til bevis på indsats. I de næste par uger vil et langvarigt testnet blive gjort tilgængeligt for test af det bredere samfund. Der er også en kommende Merge-fællesskabsopfordring til infrastruktur-, værktøjs- og applikationsudviklere til at stille spørgsmål og høre de seneste tekniske opdateringer om The Merge. Vi ses der 👋🏻
Tak til Mikhail Kalinin for at levere kerneindholdet i "Safe Head"-sektionen og til Danny Ryan &Matt Garnett for at have gennemgået udkast til dette indlæg.
Sådan reduceres de gennemsnitlige omkostninger ved tandimplantater med op til 50 %
Konvolutbudgettet:Sådan får du det til at fungere for dig
Sådan fungerer studielån | Forstå det grundlæggende
Recessionsbevis:Sådan forbereder du dig på den næste recession
Hvordan fungerer aktier? Det grundlæggende i at forstå aktiemarkedet