Ethereums övergång till bevis på insats – The Merge – är nära:utrustningar håller på att ställas upp, specifikationer håller på att slutföras och gemenskapsuppsökandet har börjat på allvar. Sammanslagningen är designad för att ha minimal inverkan på hur Ethereum fungerar för slutanvändare, smarta kontrakt och dapps. Som sagt, det finns några mindre förändringar värda att lyfta fram. Innan vi dyker in i dem, här är några länkar för att ge sammanhang om den övergripande sammanslagningsarkitekturen:

• Färdkartans utveckling
• Klientarkitektur efter sammanslagning

Resten av det här inlägget kommer att anta att läsaren är bekant med ovanstående. För dem som vill gräva ännu djupare, finns de fullständiga specifikationerna för The Merge här:

• Exekveringslager
• Konsensuslager
• Engine API

Blockstruktur

Efter sammanfogningen kommer bevis på arbetsblock inte längre att finnas på nätverket. Istället blir det tidigare innehållet i bevis på arbete en del av block skapade på Beacon Chain. Du kan då tänka på att Beacon Chain blir det nya konsensusskiktet för bevis på insats i Ethereum, och ersätter det tidigare konsensusskiktet för bevis på arbete. Beacon-kedjeblock kommer att innehålla ExecutionPayloads , som är motsvarigheten efter sammanslagningen av block i den aktuella arbetsbeviskedjan. Bilden nedan visar detta förhållande:

För slutanvändare och applikationsutvecklare, dessa ExecutionPayloads är där interaktioner med Ethereum sker. Transaktioner på detta lager kommer fortfarande att behandlas av exekveringslagerklienter (Besu, Erigon, Geth, Nethermind, etc.). Som tur är, på grund av exekveringsskiktets stabilitet, introducerar The Merge endast minimala brytningsändringar.

Mining &Ommer Block Fields

Efter sammanslagningen blir flera fält som tidigare ingick i proof of work block headers oanvända eftersom de är irrelevanta för bevis på insats. För att minimera störningar av verktyg och infrastruktur sätts dessa fält till 0, eller motsvarande datastruktur, snarare än att de tas bort helt från datastrukturen. De fullständiga ändringarna av blockfält finns i EIP-3675.

Fält Konstant värde Kommentar ommers [] RLP([]) =0xc0 ommersHash 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 =Keccak256(RLP([])) svårighet 0 icke 0x00000000000000000

Eftersom bevis på insats inte naturligt producerar ommer (a.k.a. farbrorblock) som bevis på arbete, listan över dessa i varje block (ommers ) kommer att vara tom, och hashen för denna lista (ommersHash ) kommer att bli den RLP-kodade hashen för en tom lista. På samma sätt, eftersom svårighet och nonce är funktioner för bevis på arbete, kommer dessa att ställas in på 0 , samtidigt som de respekterar deras byte-storleksvärden.

mixHash , ett annat gruvrelaterat fält, sätts inte till 0 utan kommer istället att innehålla beaconkedjans RANDAO-värde. Mer om detta nedan.

BLOCKHASH &SVÅRLIGHET opcodes ändringar

Post-merge, BLOCKHASH opcode kommer fortfarande att vara tillgänglig för användning, men med tanke på att den inte längre kommer att förfalskas genom proof of work hashing-processen, kommer pseudoslumpheten som tillhandahålls av denna opcode att vara mycket svagare.

Relaterat, SVÅRHET opcode (0x44 ) kommer att uppdateras och byta namn till RANDOM . Efter sammanslagningen kommer den att returnera utdata från slumpmässighetssignalen som tillhandahålls av beaconkedjan. Denna op-kod kommer därför att vara en starkare, om än fortfarande partisk, slumpmässig källa för applikationsutvecklare att använda än BLOCKHASH .

Värdet som exponeras av RANDOM kommer att lagras i ExecutionPayload där mixHash , ett värde som är associerat med bevis på arbetsberäkning, lagrades. Nyttolastens mixHash fältet kommer också att döpas om till slumpmässigt .

Här är en illustration av hur SVÅRHET &RANDOM opcodes fungerar före och efter sammanslagning:

För sammanslagningen ser vi 0x44 opcode returnerar svårigheten fältet i blockhuvudet. Post-merge, op-koden, bytt namn till RANDOM , pekar på rubrikfältet som tidigare innehöll mixHash och lagrar nu slumpmässiga värde från beacon-kedjans tillstånd.

Denna ändring, formaliserad i EIP-4399, ger också applikationer i kedjan ett sätt att bedöma om sammanslagningen har skett. Från EIP:

Dessutom tillåter ändringar som föreslås av denna EIP smarta kontrakt för att avgöra om uppgraderingen till PoS redan har skett. Detta kan göras genom att analysera returvärdet för SVÅRLIGT opcode. Ett värde större än 2**64 indikerar att transaktionen exekveras i PoS-blocket.

Blockeringstid

Sammanslagningen kommer att påverka den genomsnittliga blockeringstiden på Ethereum. För närvarande under bevis på arbete kommer block i genomsnitt var ~13:e sekund med en hel del varians i faktiska blocktider. Under bevis på insats kommer blocken in exakt var 12:e sekund utom när en lucka missas antingen för att en validator är offline eller för att de inte skickar in ett block i tid. I praktiken händer detta för närvarande i <1 % av platserna.

Detta innebär en ~1 sekunds minskning av genomsnittliga blockeringstider på nätverket. Smarta kontrakt som antar en viss genomsnittlig spärrtid i sina beräkningar måste ta hänsyn till detta.

Safe Head &Finalized Blocks

Under bevis på arbete finns det alltid potential för reorganiseringar. Applikationer väntar vanligtvis på att flera block ska brytas ovanpå ett nytt huvud innan det behandlas som osannolikt att det tas bort från den kanoniska kedjan, eller "bekräftas". Efter The Merge har vi istället konceptet slutfört och säkert huvud block. Dessa block kan användas ännu mer tillförlitligt än det "bekräftade" beviset på arbetsblock men kräver en förändring i förståelse för att kunna användas korrekt.

Ett slutfört block är ett som har accepterats som kanoniskt av>2/3 av validerarna. För att skapa ett konfliktblock måste en angripare bränna minst 1/3 av den totala insatsen. När detta skrivs representerar detta över $10 miljarder (eller>2,5 miljoner ETH) på Ethereum.

Ett tryggt huvud block är ett som, under normala nätverksförhållanden, förväntar oss att inkluderas i den kanoniska kedjan. Om man antar nätverksfördröjningar på mindre än 4 sekunder, en ärlig majoritet av validerare och inga attacker mot gaffelvalsregeln, är det säkra huvudet kommer aldrig att bli föräldralös. En presentation som beskriver hur det säkra huvudet beräknas under olika scenarier finns här. Dessutom antaganden och garantier för säkert huvud håller på att formellt definieras och analyseras i ett kommande dokument.

Efter sammanslagningen kommer exekveringslager-API:er (t.ex. JSON RPC) att returnera safe head som standard när du tillfrågas om det senaste blockera. Under normala nätverksförhållanden är safe head och den faktiska spetsen av kedjan kommer att vara likvärdig (med säker huvudet släpande endast med några sekunder). Säkra huvuden kommer att vara mindre sannolikt att omorganiseras än det nuvarande beviset på arbete senaste block. För att avslöja själva spetsen av proof of stake-kedjan, en osäker flaggan kommer att läggas till i JSON RPC.

Slutförda block kommer också att exponeras via JSON RPC, via en ny slutförd flagga. Dessa kan då fungera som ett starkare substitut för bevis på arbetsbekräftelser. Tabellen nedan sammanfattar detta:

Blocktyp Konsensusmekanism JSON RPC Villkor för omorganisering huvud Bevis på arbete senaste Förväntat, måste användas med försiktighet. huvud Insatsbevis osäkra Förväntat, måste användas med försiktighet. säkert huvud Insatsbevis senaste Möjligt, kräver antingen stor nätverksfördröjning eller attack mot nätverket. bekräftat Bevis på arbete N/A Osannolikt, kräver en majoritet av hashrate för att bryta en konkurrerande kedja av djup> # av bekräftelser. avslutad Insatsbevis slutfört Extremt osannolikt, kräver>2/3 av validerarna för att slutföra en konkurrerande kedja som kräver att minst 1/3 skärs ned.

Nästa steg

Vi hoppas att det här inlägget hjälper applikationsutvecklare att förbereda sig för den mycket efterlängtade övergången till bevis på insats. Under de närmaste veckorna kommer ett långlivat testnät att göras tillgängligt för testning av det bredare samhället. Det finns också ett kommande Merge-communityupprop för infrastruktur-, verktygs- och applikationsutvecklare att ställa frågor och höra de senaste tekniska uppdateringarna om The Merge. Vi ses där 👋🏻

---

Tack till Mikhail Kalinin för att ha tillhandahållit kärninnehållet i avsnittet "Safe Head" och till Danny Ryan &Matt Garnett för att ha granskat utkast till detta inlägg.