```html ``` Het misschien wel belangrijkste evenement in de geschiedenis van Ethereum, de Merge, vond plaats op 15 september 2022. Het markeerde de netwerkovergang van naar , wat fundamenteel veranderde hoe Ethereum consensus bereikt. Maar waarom heet het ‘ ’ en niet ‘de transitie’? Proof of Work Proof of Stake de Merge Voor de Merge werkte Ethereum met het Proof of Work-consensusmechanisme, een mechanisme dat ‘miners’ vereiste om complexe cryptografische puzzels op te lossen, transacties te valideren en nieuwe blokken te creëren. PoW is cool, maar het heeft veel beperkingen, zoals het gebruik van immense rekenkracht, wat leidt tot een hoog energieverbruik en milieuproblemen, een lage transactiedoorvoer vanwege de langzamere verificatietijd, wat een uitdaging is voor institutionele adoptie, en een grotere kans op centralisatierisico, omdat het kan consolideren tot een paar krachtige mining-entiteiten, enz. Deze en andere redenen waren de motivaties die de Ethereum Foundation, slechts drie jaar na de oprichting, ertoe aanzetten om te beginnen met het bouwen van een nieuwe consensus genaamd Proof of Stake, die ontworpen was om de meeste problemen op te lossen die PoW uitdaagden. Op 1 december 2020 lanceerde Ethereum de eerste versie van PoS, een nieuwe keten genaamd de Beacon Chain. De Beacon Chain verwerkte geen gebruikers transacties. Het enige doel was om validators te coördineren en consensus te bereiken met behulp van een nieuw mechanisme genaamd Gasper. Transacties werden nog steeds verwerkt op de hoofd Proof of Work-keten, dus beide ketens, de Ethereum hoofdketen en de Beacon Chain, draaiden parallel. Gedurende bijna twee jaar werkten deze twee ketens onafhankelijk. Op 15 september 2022 liet de oorspronkelijke keten zijn op mining gebaseerde consensus vallen en werd direct gekoppeld aan de Beacon Chain. Zo werden twee ketens één. Daarom heet het de Merge, niet de transitie. Tegenwoordig functioneert Ethereum als een blockchain met twee lagen. De consensuslaag, voorheen de Beacon Chain, beheert blokvoorstellen, attestaties en finaliteit. De executielaag, de oorspronkelijke Ethereum-keten, beheert transactieverwerking. Mogelijk heb je hier naar verwezen als respectievelijk Eth2 en Eth1, maar de Ethereum Foundation heeft die naamgeving afgeschaft omdat het twee afzonderlijke netwerken impliceerde in plaats van twee lagen van één systeem. Dit artikel richt zich op de consensuslaag. Specifiek, hoe de Beacon Chain functioneert als een statemachine. Wat is de BeaconState? Om te begrijpen hoe de statemachine overgangen maakt, moeten we eerst begrijpen wat de staat daadwerkelijk bevat bij de genesis van de keten. De staat van de Beacon Chain wordt vertegenwoordigd door een enkel object genaamd de BeaconState. Het bevat alles wat de consensuslaag nodig heeft om te functioneren. Het wordt soms de “God-object” genoemd. De specificatie groepeert de velden op doel, wat de duidelijkste manier is om ze te doorlopen. class BeaconState(Container): genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork latest_block_header: BeaconBlockHeader block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint Versiebeheer: genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork De eerste vier variabelen beantwoorden de vraag “welke keten zijn we, en waar zijn we op die keten?”. Deze velden verankeren de identiteit van de keten en vertellen elke node welke protocolregels te volgen zijn. Genesis time is een Unix-timestamp die aan het begin van de keten is ingesteld en nooit verandert. De genesis-timestamp van de Beacon Chain is 1606824023, wat exact 1 december 2020 om 12:00:23 UTC is. Als je ooit ‘block.timestamp’ hebt opgevraagd vanuit een smart contract, wordt die waarde berekend op basis van dit veld. De Genesis Validator root, net als de timestamp, werd ook aan het begin van de keten toegevoegd. Het fungeert in feite als de domeinscheider; het wordt gemengd met de handtekening van de validator tijdens blokvoorstellen en attestaties om de Ethereum mainnet te onderscheiden van elke andere keten. Een Slot is simpelweg een teller die ons vertelt waar de keten zich in de tijd bevindt. Het wordt elke 12 seconden verhoogd, ongeacht of er een blok wordt geproduceerd. Terwijl Fork een object is dat drie velden bevat: de vorige ketenversie, de huidige ketenversie en het epoch. Toen de eerste upgrade op de beacon chain plaatsvond op 27 oktober 2021, schakelden de versies over van Phase 0 naar Altair. De huidige versie, op het moment van schrijven van dit artikel, is Fulu, en de vorige versie is Electra. Net als de validator root, wordt de versie-hash toegevoegd aan handtekeningen om de ene forkversie van de andere te onderscheiden. Een Epoch daarentegen is een bundel van 32 slots, wat neerkomt op , ongeveer 6,4 minuten. Hier vinden finaliteitscontroles, slashing-boetes, de exit-wachtrij en andere coole consensus-specifieke zaken plaats. Hier werkt Casper FFG, het laatste deel van Gasper. 12 sec x 32 Geschiedenis latest_block_header: BeaconBlockHeader block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] Dit gedeelte beantwoordt de vraag: “Wat is er gebeurd op deze keten?”. Deze variabelen geven de keten een compact geheugen van zijn eigen verleden, waardoor validators eerdere staten kunnen raadplegen en verifiëren zonder alles op te slaan. De nieuwste block header slaat de header op van het meest recent verwerkte blok. Het wordt gebruikt om dubbele blokken te voorkomen, omdat de keten, voordat een nieuw blok wordt verwerkt, controleert of de parent root van het blok overeenkomt met de root van de nieuwste block header. Zowel de block roots als de state roots velden zijn lijsten die respectievelijk eerdere block roots en state roots opslaan totdat ze vol zijn. In elke slot worden de roots opgeslagen in hun respectieve arrays op index . Hierdoor kan de keten opzoeken hoe de staat eruitzag in elke recente slot binnen het venster van 27 uur. De Historical root voegt de samengevoegde hash toe van de array van block roots en state roots wanneer deze gevuld zijn. De lijst is onbegrensd, maar groeit langzaam, met slechts één vermelding elke 27 uur. slot%8192 Eth1 eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 Voor de merge moest Eth2 (Beacon chain) bijhouden wat er gebeurde op Eth1 (PoW-keten), met name stortingstransacties waarbij nieuwe validators 32 ETH vastzetten. Je vraagt je misschien af waarom de 32 ETH die bedoeld was voor PoS werd vastgezet in de PoW-keten in plaats van de Beacon Chain. Het antwoord is simpelweg omdat de Beacon Chain zelf geen tokenoverdrachts- of transactieverwerkingscapaciteit had, omdat het geen native tokenstortingen kon afhandelen. Eth1 data bevat drie subvelden: de , wat de merkle root is van de deposit contract deposit tree; de het totale aantal stortingen dat bij het contract is gedaan; en de de hash van het eth1-blok waarnaar wordt verwezen. deposit root deposit count, block hash, De Beacon Chain kan niet zomaar vertrouwen op het beeld van één validator van de Eth1-keten, omdat verschillende validators verschillende staten kunnen zien vanwege netwerkvertragingen. Daarom gebruikt het een stemsysteem waarmee blokvoorstellers hun beeld van de huidige Eth1-gegevens in hun blok kunnen opnemen. Die stemmen worden gedurende een stemperiode in deze lijst verzameld, en als een waarde gedurende die periode meer dan de helft van de stemmen krijgt, wordt deze de nieuwe Eth1-gegevens. Aan het einde van de stemperiode wordt de lijst gewist en begint het stemmen opnieuw. Eth Deposit Index houdt bij hoeveel stortingen van het deposit contract tot nu toe zijn verwerkt. Wanneer de keten een nieuw blok verwerkt, controleert het of er onverwerkte stortingen zijn door deze index te vergelijken met het deposit count veld in Eth1 data. Als het deposit count hoger is, moet het blok de volgende stortingen bevatten, tot een maximum van 16 stortingen per keer. Register validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] Deze variabele bevat in feite een lijst van wie deelneemt aan de consensus en hoeveel inzet ze hebben. Een cool feit over het validatorsveld is dat het alleen groeit en nooit krimpt; zelfs na een terugtrekking van een validator blijft hun vermelding op de lijst staan. Momenteel zijn er 2.210.484 vermeldingen, waarvan slechts 962.941 actief zijn. Het Validator-veld heeft acht subvelden: , wat in feite de publieke sleutel van de validator is; , waar hun inzet naartoe gaat bij terugtrekking; hun saldo naar beneden afgerond op de dichtstbijzijnde gwei, gebruikt voor het berekenen van beloningen en boetes, en dit wordt alleen bijgewerkt aan het einde van epochgrenzen met hysteresis om te voorkomen dat het op en neer flikkert; , een booleaanse vlag die aangeeft of een validator is geslashed; , het epochnummer waarop de validator in aanmerking kwam om geactiveerd te worden; het epoch waarop ze zijn geactiveerd; , het epoch waarop ze vertrokken zijn; en tenslotte , het epoch waarop hun saldo kan worden opgenomen. pubKey withdrawable credentials effective balance, slashed activation eligibility epoch activation epoch, exit epoch withdrawable epoch Om uit te leggen waarom we een effectief saldoveld in de validatorlijst hebben en een saldoveld direct in de beacon state: het effectieve saldoveld wordt niet bijgewerkt op het moment dat je werkelijke saldo’s dat wel doen; er is een buffer om te voorkomen dat het heen en weer gaat. Zonder hysteresis zou een validator die rond de 32 ETH zweeft, zeg maar fluctuerend tussen 31,99 en 32,01 per epoch vanwege beloningen en boetes, elke epoch een effectief saldo hebben dat tussen 31 en 32 wisselt. Dat zou betekenen dat het validatorobject voortdurend opnieuw gemerkeld moet worden en hun gewicht in commisiebepalingen elke epoch verandert. Willekeur randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] randao_mixes is een lijst met een vaste grootte van 65.536 (ongeveer 2 tot de macht 16) vermeldingen. Elke keer dat een validator een blok voorstelt, voegt deze een ‘randao reveal’ toe aan de lijst. Deze reveal is in feite het huidige epochnummer, ondertekend door de validator. Na ondertekening neemt de keten het en XORt het met de laatste mix voor het huidige epoch, wat een nieuwe mix produceert. Alle voorstellers in een epoch doen hetzelfde om de uiteindelijke geaccumuleerde mix voor het volgende epoch te verkrijgen. De randao mix wordt gebruikt om de commissie en blokvoorstellers voor het volgende epoch te bepalen. De commissie, wat alle actieve validators verdeeld over de 32 slots is, wordt bepaald door het ‘swap-or-not’ shuffle-algoritme. Dit algoritme wisselt in feite simpelweg de validator-index willekeurig met de mix. Voor de selectie van de blokvoorsteller hasht de keten de randao mix om een seed te vormen. Vervolgens doorloopt het alle actieve validators, beginnend bij een willekeurige offset die is afgeleid van die seed. Voor elke kandidaat controleert het of een hash van de seed en de index van de validator, gedeeld door het effectieve saldo van de validator, een drempel overschrijdt. Zo ja, dan wordt de validator de voorsteller; zo niet, dan wordt deze overgeslagen. In de praktijk wordt er snel een gevonden, aangezien de meeste actieve validators een saldo van 32 ETH hebben. Slashings slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] Een validator wordt om twee redenen geslashed: het voorstellen van twee verschillende blokken voor dezelfde slot, in een poging een fork te creëren, of het maken van tegenstrijdige attestaties. Het slashing-veld is een vaste lijst van 8192 vermeldingen, één per epoch. Het bevat de som van alle effectieve saldi van geslashte validators. Dit veld wordt gebruikt om de boetebedrag te berekenen. Attestaties previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] Elke actieve validator attesteert één keer per epoch, en deze attestaties drijven zowel de fork choice rule (LMD-GHOST) als het finaliteitsmechanisme (Casper FFG). Een attestation bevat zes subvelden: de waarvoor de validator attesteert; de is het blok dat de validator beschouwt als het hoofd van de keten, het wordt beschouwd als een LMD-GHOST-stem van de validator die wordt gebruikt om de fork choice te bepalen; de is het epoch checkpoint dat de validator gerechtvaardigd acht, en is het huidige epoch waarvoor de validator attesteert; beide vormen samen de Casper FFG-stem die wordt gebruikt bij finaliteit. Simpel gezegd, de validator attesteert dat het source epoch gefinaliseerd moet worden en het target epoch gerechtvaardigd moet worden. De geeft aan welke validator in de commissie heeft geattesteerd. Aangezien het goedkoper is om dingen als bits in een byte te combineren, wordt de aggregation bit opgeslagen in een bitveld voor geheugenefficiëntie. Ten slotte hebben we de van de validator over de attestation data. slot beacon block root source target aggregation bits signature Finaliteit justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint Finaliteit betekent dat een blok en al zijn transacties nooit meer ongedaan kunnen worden gemaakt. In de Beacon Chain is finaliteit absoluut. Zodra een epoch is gefinaliseerd, is de enige manier om het terug te draaien als 1/3 van alle gestakete ETH wordt geslashed, wat miljarden dollars zou kosten. Justification bits is een bit vector van lengte 4, het volgt in feite alleen of de laatste vier epochs gerechtvaardigd waren. Het previously justified checkpoint is het checkpoint dat gerechtvaardigd was in het vorige epoch. Current Justified Checkpoint is het meest recent gerechtvaardigde checkpoint, terwijl Finalized Checkpoint het meest recent gefinaliseerde checkpoint is. Een epoch wordt gerechtvaardigd wanneer 2/3 van de totale actieve inzet attesteert naar een supermeerderheidslink die naar dat epoch wijst als target. Finalisatie vindt plaats wanneer je twee opeenvolgende gerechtvaardigde checkpoints krijgt. Zodra de tweede gerechtvaardigd is, wordt de eerste gepromoveerd tot gefinaliseerd, hoewel er meer nuances zijn. De State Machine Nu we weten wat de staat bevat, kunnen we kijken hoe deze verandert. Elke 12 seconden arriveert een nieuwe slot. Als er een blok wordt voorgesteld, neemt de state transition function de huidige staat en dat blok, voert validatie uit, updates, en produceert een nieuwe staat. Dit proces is verdeeld in drie fasen volgens de specificatie: slotverwerking, blokverwerking en epochverwerking. Slotverwerking Slotverwerking wordt uitgevoerd telkens wanneer de keten van de ene slot naar de volgende moet gaan, ongeacht of er een blok is geproduceerd. Drie dingen gebeuren wanneer een slot van N naar N+1 gaat. Ten eerste wordt de state root voor slot N bijgewerkt om een record bij te houden van hoe de slot eruitzag in die slot. Ten tweede wordt de nieuwste block header, die de header van het meest recent verwerkte blok opslaat, ook bijgewerkt; onthoud dat dit veld wordt gebruikt om dubbele blokken te voorkomen. Ook wordt de root van die voltooide header in de block root geschreven. Ten slotte wordt de slot-teller met één verhoogd. Je vraagt je misschien af wat er met de staat gebeurt als een voorsteller zijn slot mist. Welnu, alle staten worden nog steeds bijgewerkt; de block roots van die slot bevatten bijvoorbeeld de root van dezelfde nieuwste block header, aangezien er geen nieuw blok arriveerde om deze te vervangen. Nadat de slot is verhoogd, controleert de keten of deze zojuist een epochgrens is gepasseerd, wat eenvoudig kan worden gedaan met slot mod 32 == 0. Zo ja, dan treedt epochverwerking in werking voordat er iets anders gebeurt. Technisch gezien, voor elke 32 slots, draait epochverwerking naast slotverwerking, met andere woorden, epochverwerking draait nadat de slot is geavanceerd, maar voordat het blok voor die slot is verwerkt. Nog een laatste feit: wanneer we op het punt zijn dat de arrays voor state roots en block roots gevuld zijn, d.w.z. op de positie slot mod 8192 == 0, voordat beide arrays beginnen te worden overschreven door nieuwe gegevens omdat het circulair lijkt, hasht de keten de twee velden samen en voegt deze toe aan de historische staat. Blokverwerking Blokverwerking wordt uitgevoerd wanneer er daadwerkelijk een blok wordt voorgesteld voor een slot. Nadat slotverwerking de staat naar de juiste slot heeft gebracht, neemt blokverwerking het ondertekende blok en past de inhoud ervan toe op de staat. Het heeft twee hoofddelen: het valideren van de block header en het verwerken van de block body. Voordat er iets anders gebeurt, controleert de keten een paar dingen, zoals of de block header overeenkomt met de huidige slot van de staat, en of de index van de blokvoorsteller daadwerkelijk de validator is die de randao heeft geselecteerd. Ten slotte controleert het of de parent root van het blok overeenkomt met de root van de nieuwste block header. Indien gevalideerd, wordt de block header opgeslagen als de nieuwste block header in de staat. Vervolgens moet de voorsteller een randao reveal opnemen, die, zoals ik al zei, in feite het huidige epochnummer is, ondertekend door de validator. De keten verifieert de handtekening tegen de publieke sleutel van de voorsteller. Het is gemakkelijk te zien dat deze huidige methode deterministisch is, dat de handtekening van de validator altijd hetzelfde zal zijn voor hetzelfde epochnummer, inderdaad, het hele punt van deze werkwijze is om iedereen toe te staan de publieke sleutel van de validator te gebruiken om het epochnummer te controleren dat de validator daadwerkelijk heeft ondertekend. Merk op dat een voorsteller de randao reveal niet kan overslaan; als ze een blok voorstellen, moeten ze deze opnemen, de enige manier om het proces over te slaan is door helemaal geen blok voor te stellen. Daarna neemt de voorsteller ook zijn beeld van de Eth1-keten deposit contract staat op als een Eth1 data stem. Als een Eth1 data waarde in de stemmenlijst een meerderheid bereikt, wordt deze de nieuwe Eth1 data in de staat. Tijdens de blokverwerking bevat het voorsteller slashing-veld bewijs dat een validator twee verschillende block headers voor dezelfde slot ondertekent; de keten verifieert beide handtekeningen, en indien geldig, slasht deze de validator door eerst de slashed-vlag op true te zetten en hun effectieve saldo aan de slashings array toe te voegen. Ook voor de attesters, als er tegenstrijdige attestaties zijn, verifieert de keten deze en identificeert de schuldige validators via hun handtekening, en slasht vervolgens die validators, op dezelfde manier en proces als de blokvoorsteller slashing. Nieuwe attestaties in het blok worden gevalideerd, de attestation wordt omgezet in een pending attestation door twee nieuwe velden toe te voegen, namelijk de inclusion delay en de proposer index, en vervolgens worden ze toegevoegd aan de current epoch attestation of de previous epoch attestation. Daarna gebeurt er niet veel meer, aangezien ze de staat niet onmiddellijk beïnvloeden; ze blijven daar totdat epochverwerking ze evalueert. Nieuwe validator-stortingen van het Eth1-deposit contract worden verwerkt; het blok moet alle pending stortingen tot de maximale storting van 16 bevatten. De keten verifieert het merkle proof van elke storting tegen de deposit root om ervoor te zorgen dat deze correct is. Als de publieke sleutel van de stortende partij nieuw is, wordt er een nieuwe validatorvermelding toegevoegd, evenals het bijbehorende saldo. Een validator kan aangeven dat hij wil vertrekken door een ondertekende vrijwillige exit in te dienen. De keten controleert of de validator minstens 256 epochs actief is geweest en of het huidige epoch minstens het opgegeven exit epoch is. Als alles klopt, worden het exit epoch en withdrawable epoch van de validator ingesteld. Nadat alles hierboven is verwerkt, is er nog één laatste, maar belangrijk stuk: de berekende state root door de andere node wordt vergeleken met de state root die in het blok is opgenomen. Als ze niet overeenkomen, wordt het hele blok afgewezen. Epochverwerking Epochverwerking wordt geactiveerd aan het begin van het epoch, dus elke stap van ‘slot mod 32 = 0’. Het wordt uitgevoerd tijdens slotverwerking wanneer de slot-teller een nieuw epoch ingaat. Het is de meest complexe fase, omdat de meeste coole consensus-zaken hier gebeuren. Ten eerste treden rechtvaardiging en finaliteit in werking; hier doet Casper FFG zijn werk. Het proces klinkt misschien complex, maar het is heel eenvoudig. Simpel gezegd, de keten bekijkt de attestaties van het vorige epoch en telt de effectieve saldi van validators die met de juiste target hebben geattesteerd. Als die som minstens 2/3 is van het totale actieve saldo, wordt het target epoch gerechtvaardigd, en als twee opeenvolgende epochs gerechtvaardigd zijn, wordt de eerste gefinaliseerd. Eenvoudig! Een feit dat ik in de blokverwerkingsfase niet heb vermeld, is dat voor elke fase de validators beloningen accumuleren; ze worden beloond voor het opnemen van attestaties, voor het toevoegen van slashing-bewijs, of zelfs voor normale basisbeloningen. Deze geaccumuleerde beloningen worden geëvalueerd door de keten over het vorige epoch in de epochverwerkingsfase, en hun saldo wordt dienovereenkomstig aangepast. Als de keten al meer dan vier epochs niet heeft gefinaliseerd, treedt wat wordt omschreven als “de inactiviteitslek” in werking. Bovenop de normale boetes voor gemiste attestaties, krijgen niet-deelnemende validators een extra inactiviteitsboete die kwadratisch toeneemt met elk epoch sinds het laatste gefinaliseerde epoch. Met andere woorden, hoe langer het duurt voordat een blok wordt gefinaliseerd, hoe zwaarder je boete. Je vraagt je misschien af wat het nut hiervan is. Welnu, wanneer een blok een tijdje niet is gefinaliseerd, betekent dit dat er geen meerderheidsstem is op dat blok, en aangezien stemmen voor finaliteit wordt gemeten aan de hand van het gewicht van het effectieve saldo van een validator, in feite hoeveel ETH de validator heeft, vermindert een verlaging van hun effectieve saldo hun stemkracht. Ethereum gebruikt het dus als een manier om blokfinaliteit af te dwingen. Het is vermeldenswaard dat tijdens een inactiviteitslek, zelfs correcte attesters geen beloningen ontvangen. Alles verschuift naar pure boetemodus om de herbalancering te versnellen. Een ander belangrijk evenement dat in deze fase plaatsvindt, is de activering van validators, wier activation eligibility epoch is bereikt. Ook validators wiens exit epoch is aangebroken, worden uit de actieve set van validators verwijderd. Vervolgens, onthoud dat het effectieve saldo niet bij elke slot en epoch wordt bijgewerkt, omdat hysteresis geldt. Het wordt pas bijgewerkt als het werkelijke saldo voldoende is gestegen boven de huidige effectieve saldovoorwaartse drempel; het effectieve saldo neemt toe met 1 ETH, en als het onder de neerwaartse drempel daalt, neemt het met 1 ETH af. Ten slotte wordt de randao mix van het huidige epoch gekopieerd naar de slot van het volgende epoch. Zoals je duidelijk kunt zien, is epochverwerking het meest ingewikkelde deel van de statemachine en is het rekenkundig onvriendelijk, wat leidt tot veel optimalisatiewerk voor de ingenieurs die de ketenclients bouwen. Van Fase 0 tot Fulu De BeaconState die we tot nu toe hebben doorlopen, is de Phase 0-versie, de originele. Maar de Beacon Chain is een levend systeem. Elke consensuslaag fork heeft de BeaconState aangepast, hetzij door nieuwe velden toe te voegen, oude te verwijderen, of gewoon de werking van bestaande velden te veranderen. In de Altair fork zijn bijvoorbeeld de lijsten met vorige en huidige epoch attestaties volledig verwijderd en vervangen door de vorige en huidige epoch ; het verschil is dat terwijl de vorige volledige attestation-objecten opslaat, het nieuwe deelnametype dit alleen in bitvorm opslaat. Nu krijgt elke validator slechts drie bits per epoch die aangeven of ze de source correct hadden, de target correct hadden en de head correct hadden. Dit leidde tot een drastische vermindering van de geheugengrootte. Bellatrix, de merge fork, introduceerde het execution payload veld in de beaconState; dit veld wordt gebruikt om de consensuslaag en de executielaag te verbinden. De Eth1-velden werden behouden, maar hun rol werd verminderd omdat ze niet langer nodig waren. deelname De Capella fork introduceerde opnamemogelijkheden voor de validator; dit wordt vastgelegd door een nieuw veld, next withdrawal index, toe te voegen aan de beaconState. Historical roots werd vervangen door historical summaries, die block root en state root in een struct opslaan in plaats van ze samen te hashen. De Deneb fork had daarentegen nauwelijks impact op de beaconState, omdat de fork voornamelijk betrekking had op blobs. In Electra en Fulu was de belangrijkste verandering het verhogen van het maximale effectieve saldo van 32 ETH naar 2048 ETH, wat leidde tot de introductie van nieuwe velden in de beaconState. Elke fork bouwde voort op de vorige, en de BeaconState groeide van 21 velden in Phase 0 naar meer dan 30 in Fulu. Eén ding is consistent: van Phase 0 tot Fulu is de staat gegroeid; forks voegen velden toe, forks verwijderen velden, maar de architectuur is hetzelfde gebleven. Conclusie De Beacon Chain wordt vaak omschreven als complex, ja ik ben het ermee eens, want het is complex. Maar in de kern is het in feite een cyclus van: een staat bestaat, een input arriveert, de bestaande staat wordt bijgewerkt om een nieuwe staat te produceren, en dan herhaalt het zich! Simpel! Wat de beacon chain werkelijk opmerkelijk maakt, is niet één specifiek veld, maar hoe alles met elkaar verbonden is om ons deze geweldige ‘tek’ te geven die we vandaag hebben! Referenties Ethereum Consensus Specifications (Phase 0) Ethereum Annotated Specification by Ben Edgington eth2book.info Gasper: Combining GHOST and Casper (Original Paper) Casper the Friendly Finality Gadget (Original Paper) Lighthouse Client Implementation Ethereum Beacon Chain Explorer Ethereum Foundation Blog on the Merge Ethereum Annotated Spec by Vitalik Buterin
