De overgang van Ethereum naar proof-of-stake – The Merge – is nabij:devnets worden opgericht, specificaties worden afgerond en het bereiken van de gemeenschap is serieus begonnen. The Merge is ontworpen om een minimale impact te hebben op hoe Ethereum werkt voor eindgebruikers, slimme contracten en dapps. Dat gezegd hebbende, zijn er enkele kleine veranderingen die het vermelden waard zijn. Voordat we erop ingaan, volgen hier een paar links om context te bieden over de algehele samenvoegingsarchitectuur:
In de rest van dit bericht wordt ervan uitgegaan dat de lezer bekend is met het bovenstaande. Voor degenen die nog dieper willen graven, zijn de volledige specificaties voor The Merge hier beschikbaar:
Na The Merge zijn er geen proof of work blocks meer op het netwerk. In plaats daarvan wordt de voormalige inhoud van het bewijs van werk een onderdeel van blokken die op de Beacon Chain zijn gemaakt. Je kunt de Beacon Chain dan beschouwen als de nieuwe proof-of-stake-consensuslaag van Ethereum, die de vorige proof-of-work-consensuslaag vervangt. Beacon chain-blokken bevatten ExecutionPayloads , die het post-merge-equivalent zijn van blokken in de huidige proof of work-keten. De afbeelding hieronder toont deze relatie:
Voor eindgebruikers en applicatieontwikkelaars:deze ExecutionPayloads zijn waar interacties met Ethereum plaatsvinden. Transacties op deze laag worden nog steeds verwerkt door cliënten van de uitvoeringslaag (Besu, Erigon, Geth, Nethermind, enz.). Gelukkig introduceert The Merge vanwege de stabiliteit van de uitvoeringslaag slechts minimale brekende wijzigingen.
Na het samenvoegen worden verschillende velden die voorheen in de headers van het bewijs van werkblok waren opgenomen ongebruikt omdat ze niet relevant zijn voor het bewijs van inzet. Om verstoring van tooling en infrastructuur tot een minimum te beperken, worden deze velden ingesteld op 0, of het equivalent van hun datastructuur, in plaats van volledig uit de datastructuur te worden verwijderd. De volledige wijzigingen om velden te blokkeren zijn te vinden in EIP-3675.
ommers [] RLP([]) =0xc0 ommersHash 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 =Keccak256(RLP([])) moeilijkheid 0 nonce 0x000000000000000000
Omdat proof of stake van nature geen ommers (ook wel oomblokken genoemd) zoals proof of work produceert, is de lijst hiervan in elk blok (ommers ) is leeg en de hash van deze lijst (ommersHash ) wordt de RLP-gecodeerde hash van een lege lijst. Evenzo, omdat moeilijkheid en nonce zijn kenmerken van bewijs van werk, deze worden ingesteld op 0 , met respect voor hun bytegrootte-waarden.
mixHash , een ander mijnbouwgerelateerd veld, wordt niet ingesteld op 0 maar bevat in plaats daarvan de RANDAO-waarde van de bakenketen. Meer hierover hieronder.
BLOCKHASH &MOEILIJKHEID opcodes veranderingen
Na het samenvoegen, de BLOCKHASH opcode zal nog steeds beschikbaar zijn voor gebruik, maar aangezien het niet langer zal worden vervalst door het hashingproces van het bewijs van werk, zal de pseudo-willekeurigheid die door deze opcode wordt geboden, veel zwakker zijn.
Aanverwant, de MOEILIJKHEID opcode (0x44 ) wordt bijgewerkt en hernoemd naar RANDOM . Na het samenvoegen wordt de uitvoer geretourneerd van het willekeurigheidsbaken dat door de bakenketen wordt geleverd. Deze opcode zal dus een sterkere, zij het nog steeds vooringenomen, bron van willekeur zijn voor toepassingsontwikkelaars om te gebruiken dan BLOCKHASH .
De waarde die wordt weergegeven door RANDOM wordt opgeslagen in de ExecutionPayload waar mixHash , een waarde die is gekoppeld aan de berekening van het bewijs van werk, is opgeslagen. De mixHash . van de payload veld wordt ook hernoemd willekeurig .
Hier is een illustratie van hoe de MOEILIJKHEID &RANDOM opcodes werken voor en na het samenvoegen:
Pre-merge, we zien de 0x44 opcode retourneert de moeilijkheid veld in de blokkop. Post-merge, de opcode, hernoemd naar RANDOM , verwijst naar het kopveld dat voorheen mixHash bevatte en slaat nu de willekeurige . op waarde van de bakenketenstatus.
Deze wijziging, geformaliseerd in EIP-4399, biedt ook on-chain-applicaties een manier om te beoordelen of The Merge heeft plaatsgevonden. Van het EIP:
Bovendien maken de wijzigingen die door dit EIP worden voorgesteld, slimme contracten mogelijk om te bepalen of de upgrade naar de PoS al heeft plaatsgevonden. Dit kan gedaan worden door de retourwaarde van de opcode DIFFICULTY te analyseren. Een waarde groter dan 2**64 geeft aan dat de transactie wordt uitgevoerd in het PoS-blok.
De samenvoeging heeft invloed op de gemiddelde blokkeringstijd op Ethereum. Momenteel onder proof-of-work, komen er gemiddeld elke ~13 seconden blokken binnen met een behoorlijke hoeveelheid variantie in de werkelijke bloktijden. Onder bewijs van inzet komen blokken precies elke 12 seconden binnen, behalve wanneer een slot wordt gemist omdat een validator offline is of omdat ze een blok niet op tijd indienen. In de praktijk gebeurt dit momenteel in <1% van de slots.
Dit impliceert een reductie van ~1 seconde van de gemiddelde bloktijd op het netwerk. Slimme contracten die in hun berekeningen uitgaan van een bepaalde gemiddelde bloktijd, moeten hier rekening mee houden.
Onder proof of work is er altijd het potentieel voor reorgs. Toepassingen wachten meestal tot er meerdere blokken zijn gedolven bovenop een nieuwe kop voordat ze het behandelen als onwaarschijnlijk dat het uit de canonieke keten wordt verwijderd, of "bevestigd". Na The Merge hebben we in plaats daarvan de concepten van afgerond en veilig hoofd blokken. Deze blokken kunnen nog betrouwbaarder worden gebruikt dan de "bevestigde" bewijs van werkblokken, maar vereisen een verschuiving in begrip om correct te gebruiken.
Een definitief blok is een blok dat door>2/3 van de validators als canoniek is geaccepteerd. Om een conflicterend blok te creëren, zou een aanvaller minstens 1/3 van de totale inzet moeten verbranden. Op het moment van schrijven vertegenwoordigt dit meer dan $ 10 miljard (of> 2,5 miljoen ETH) op Ethereum.
Een veilig hoofd block is er een waarvan we verwachten dat deze onder normale netwerkomstandigheden wordt opgenomen in de canonieke keten. Uitgaande van netwerkvertragingen van minder dan 4 seconden, een eerlijke meerderheid van validators en geen aanvallen op de fork-choice-regel, is de veilige kop zal nooit wees worden. Een presentatie waarin wordt beschreven hoe de veilige hoogte wordt berekend onder verschillende scenario's is hier beschikbaar. Bovendien zijn de aannames en garanties van veilig hoofd worden formeel gedefinieerd en geanalyseerd in een komende paper.
Na het samenvoegen, de uitvoeringslaag-API's (bijv. JSON RPC) retourneren de veilige kop standaard wanneer gevraagd om de nieuwste blok. Onder normale netwerkomstandigheden is de veilige kop en de werkelijke punt van de ketting zal gelijk zijn (met een veilige kop die slechts een paar seconden achterblijft). Veilige hoofden zal minder snel worden gereorganiseerd dan het huidige bewijs van werk nieuwste blokken. Om de eigenlijke tip van het bewijs van de inzetketting bloot te leggen, een onveilige vlag wordt toegevoegd aan JSON RPC.
Gefinaliseerde blokken zullen ook worden getoond via JSON RPC, via een nieuwe gefinaliseerde vlag. Deze kunnen dan dienen als een sterkere vervanging voor bewijs van werkbevestigingen. De onderstaande tabel vat dit samen:
nieuwste Te verwachten, moet met zorg worden gebruikt. hoofd Bewijs van inzet onveilig Te verwachten, moet met zorg worden gebruikt. veilig hoofd Proof of Stake nieuwste Mogelijk, vereist een grote netwerkvertraging of een aanval op het netwerk. bevestigd Proof of Work N.v.t. Onwaarschijnlijk, vereist een meerderheid van hashrate om een concurrerende keten van diepte> # bevestigingen te ontginnen. voltooid Proof of Stake voltooid Uiterst onwaarschijnlijk, vereist>2/3 van de validators om een concurrerende keten af te ronden waarvoor minstens 1/3 moet worden doorgesneden. We hopen dat dit bericht applicatieontwikkelaars helpt zich voor te bereiden op de langverwachte overgang naar proof of stake. In de komende weken zal een langlevend testnet beschikbaar worden gesteld voor testen door de bredere gemeenschap. Er is ook een aanstaande Merge-community-oproep voor infrastructuur-, tooling- en applicatieontwikkelaars om vragen te stellen en de laatste technische updates over The Merge te horen. Zie je daar 👋🏻
Bedankt aan Mikhail Kalinin voor het verstrekken van de kerninhoud van de sectie "Safe Head" en aan Danny Ryan en Matt Garnett voor het beoordelen van concepten van dit bericht.
