Den måske vigtigste begivenhed i Ethereums historie, The Merge, fandt sted den 15. september 2022. Den markerede netværksovergangen fra til , hvilket fundamentalt ændrede, hvordan Ethereum opnår konsensus. Men hvorfor kaldes det 'The Merge' og ikke 'overgangen'? Proof of Work Proof of Stake Før The Merge opererede Ethereum med Proof of Work-konsensus, en mekanisme, der krævede, at 'minere' løste komplekse kryptografiske gåder for at validere transaktioner og skabe nye blokke. PoW er cool, men det kommer med mange begrænsninger, såsom at bruge enorm computerkraft, hvilket fører til højt elforbrug og miljømæssige bekymringer, lav transaktionsgennemstrømning på grund af langsommere verifikationstid, hvilket er en udfordring for institutionel adoption, en højere risiko for centralisering, da det kan konsolidere sig til få magtfulde mining-enheder osv. Disse og andre grunde var motivationen, der pressede Ethereum Foundation, kun tre år efter dens start, til at begynde at bygge en ny konsensus kaldet Proof of Stake, der skulle løse de fleste af de problemer, der udfordrede PoW. Den 1. december 2020 lancerede Ethereum sin første version af PoS, en ny kæde kaldet Beacon Chain. Beacon Chain behandlede ikke brugeranmodninger. Dens eneste formål var at koordinere validatorer og opnå konsensus ved hjælp af en ny mekanisme kaldet Gasper. Transaktioner blev stadig behandlet i den primære Proof of Work-kæde, så begge kæder, Ethereum-hovedkæden og Beacon Chain, kørte parallelt. I næsten to år kørte disse to kæder uafhængigt. Derefter, den 15. september 2022, opgav den oprindelige kæde sin mining-baserede konsensus og koblede sig direkte til Beacon Chain. Dermed blev to kæder til én. Derfor kaldes det The Merge, ikke overgangen. I dag fungerer Ethereum som en to-lags blockchain. Konsensuslaget, som plejede at være Beacon Chain, håndterer blokforslag, attestations og finalitet. Udførelseslaget, den oprindelige Ethereum-kæde, håndterer transaktionsbehandling. Du har måske hørt disse omtalt som henholdsvis Eth2 og Eth1, men Ethereum Foundation har opgivet den navngivning, fordi den antydede to separate netværk snarere end to lag af ét system. Denne artikel fokuserer på konsensuslaget. Specifikt, hvordan Beacon Chain fungerer som en tilstandsmaskine. Hvad er BeaconState? For at forstå, hvordan tilstandsmaskinens overgange fungerer, skal vi først forstå, hvad tilstanden faktisk indeholder ved kædens genesis. Beacon Chain's tilstand repræsenteres af et enkelt objekt kaldet BeaconState. Den indeholder alt, hvad konsensuslaget har brug for for at fungere. Den omtales undertiden som "Gud-objektet". Specifikationen grupperer felterne efter formål, hvilket er den tydeligste måde at gennemgå dem på. 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 Versionering: genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork De første fire variabler besvarer spørgsmålet "hvilken kæde er vi, og hvor er vi på den kæde?". Disse felter forankrer kædens identitet og fortæller hver node, hvilke protokolregler der skal følges. Genesis-tidspunktet er en Unix-tidsstempel, der sættes ved kædens begyndelse og aldrig ændres. Beacon Chain genesis-tidsstemplet er 1606824023, hvilket præcis svarer til 1. december 2020, kl. 12:00:23 UTC. Hvis du nogensinde har forespurgt 'block.timestamp' fra en smart kontrakt, er den værdi beregnet ud fra dette felt. Genesis Validator-roden blev ligesom tidsstemplet også tilføjet ved kædens begyndelse. Den fungerer grundlæggende som domæneseparator; den blandes med validatorens signatur under blokforslag og attestations for at adskille Ethereum mainnet fra enhver anden kæde. En Slot er simpelthen en tæller, der fortæller os, hvor kæden er i tid. Den inkrementeres hvert 12. sekund, uanset om der produceres en blok. Mens Fork er et objekt, der indeholder tre felter, er de kædens tidligere version, den aktuelle kædeversion og epoch'en. Da den første opgradering på Beacon Chain fandt sted den 27. oktober 2021, skiftede versionerne fra Fase 0 til Altair. Den aktuelle version, som dette skrives, er Fulu, og den tidligere version er Electra. Ligesom validator-roden tilføjes versionshashen til signaturer for at adskille en fork-version fra en anden. Epoch er derimod en samling af 32 slots, hvilket er , cirka 6,4 minutter. Det er her, finalitetstjek, slashing-straffe, exit-kø og alle andre seje konsensus-specifikke ting foregår. Det er her, Casper FFG, den sidste del af Gasper, opererer. 12 sek x 32 Historik 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] Denne sektion besvarer spørgsmålet: "Hvad er der sket på denne kæde?". Disse variabler giver kæden et kompakt minde om dens egen fortid, hvilket giver validatorer mulighed for at referere til og verificere tidligere tilstande uden at gemme alt. Den seneste blokheader gemmer headeren for den senest behandlede blok. Den bruges til at forhindre duplikatblokke, fordi kæden, før den behandler en ny blok, kontrollerer, at blokkens forældrerod stemmer overens med roden af den seneste blokheader. Både felterne for blokrødder og tilstandsrødder er lister, der gemmer tidligere blokrødder og tilstandsrødder, henholdsvis indtil de er fulde. I hvert slot skrives rødderne til deres respektive arrays ved indekset . Dette giver kæden mulighed for at slå op, hvordan tilstanden så ud på et hvilket som helst nyligt slot inden for 27-timers vinduet. Den historiske rod tilføjer den sammensmeltede hash af arrayet af blokrødder og tilstandsrødder, når de er fyldte. Listen er ubegrænset, men den vokser langsomt, med kun én post hver 27. time. slot%8192 Eth1 eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 Før The Merge skulle Eth2 (Beacon Chain) spore, hvad der skete på Eth1 (PoW-kæden), specifikt indbetalingstransaktioner, hvor nye validatorer låste 32 ETH. Du spekulerer måske på, hvorfor de 32 ETH, der var beregnet til PoS, var låst i PoW-kæden i stedet for Beacon Chain. Svaret er simpelthen, at Beacon Chain selv ikke havde nogen tokenoverførsel eller transaktionsbehandlingsevne, da den ikke kunne håndtere token-indbetalinger nativt. Eth1 data indeholder tre underfelter: , som er merkle-roden af indbetalingskontraktens indbetalingstræ, , det samlede antal indbetalinger foretaget til kontrakten, og , hashen af den eth1-blok, der refereres til. deposit root deposit count block hash Beacon Chain kan ikke bare stole på én validators syn på Eth1-kæden, da forskellige validatorer kan se forskellige tilstande på grund af netværksforsinkelser, så den bruger en afstemningsmekanisme, der tillader blokproposers at inkludere deres syn på den aktuelle Eth1-data i deres blok. Disse stemmer akkumuleres i denne liste over en afstemningsperiode, og hvis en værdi opnår mere end halvdelen af stemmerne i den periode, bliver den til de nye Eth1-data. Ved afslutningen af afstemningsperioden tømmes listen, og afstemningen starter forfra. Eth Deposit Index sporer, hvor mange indbetalinger fra indbetalingskontrakten der er blevet behandlet hidtil. Når kæden behandler en ny blok, kontrollerer den, om der er ubehandlede indbetalinger ved at sammenligne denne indeks med feltet 'deposit count' i Eth1-data. Hvis 'deposit count' er højere, skal blokken inkludere de næste indbetalinger op til det maksimale antal indbetalinger pr. blok, hvilket dengang var 16. Register validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] Denne variabel gemmer grundlæggende en liste over, hvem der deltager i konsensus, og hvor meget stake de har. Et sejt faktum om validator-feltet er, at det kun vokser og aldrig skrumper, selv efter en validator trækker sig, forbliver deres post på listen. I øjeblikket er der 2.210.484 poster, og kun 962.941 er i øjeblikket aktive. Validator-feltet har otte underfelter: , som grundlæggende er validatorens offentlige nøgle, , hvor deres stake går hen, når de trækker sig, , deres saldo afrundet ned til nærmeste gwei, der bruges til at beregne belønninger og straffe, og det opdateres kun ved epoch-grænser med hysteres for at forhindre, at det flimrer op og ned. , et boolsk flag, der bruges til at angive, om en validator er blevet 'slashed'. , epoch-nummeret, hvor validatoren blev berettiget til at blive aktiveret. , epoch'en, hvor de blev aktiveret. , epoch'en, hvor de forlod, og endelig , epoch'en, hvor deres saldo kan hæves. pubKey withdrawable credentials effective balance slashed activation eligibility epoch activation epoch exit epoch withdrawable epoch For at påpege, hvorfor vi har et felt for effektiv saldo i validatorlisten og et felt for saldi direkte i beacon-tilstanden, er det, at feltet for effektiv saldo ikke opdateres i det øjeblik, din faktiske saldo gør; der er en buffer for at forhindre, at den går frem og tilbage. Uden hysteres ville en validator, der svinger omkring 32 ETH, f.eks. svinger mellem 31,99 og 32,01 hver epoch på grund af belønninger og straffe, have sin effektive saldo skiftende mellem 31 og 32 hver epoch. Det ville betyde konstant at gen-Merkleize validator-objektet og ændre dets vægt i komitéberegninger i hver epoch. Tilfældighed randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] randao_mixes er en liste med fast størrelse på 65.536 (ca. 2 i 16) poster. Hver gang en validator foreslår en blok, tilføjer de, hvad vi kalder en 'randao reveal', til listen. Denne reveal er grundlæggende det aktuelle epoch-nummer signeret af validatoren. Efter signering tager kæden den og XOR'er den med den sidste mix for den aktuelle epoch, hvilket producerer en ny mix. Alle proposers i en epoch gør det samme for at få den endelige akkumulerede mix for den næste epoch. Randao-mixen bruges til at bestemme komitéen og blokproposers for den næste epoch. Komitéen, som er alle de aktive validatorer opdelt i 32 slots, bestemmes af 'swap-or-not'-shuffle-algoritmen. Denne algoritme bytter grundlæggende validatorindekset tilfældigt med mixen. For valget af blokproposer hasher kæden randao-mixen for at danne et seed. Derefter itererer den gennem alle aktive validatorer startende fra en tilfældig forskydning afledt af det seed. For hver kandidat kontrollerer den, om en hash af seed'et og validatorens indeks, divideret med validatorens effektive saldo, passerer en tærskel. Hvis det gør det, bliver validatoren proposeren, hvis ikke, springer den til den næste. I praksis finder den hurtigt en, da de fleste aktive validatorer har 32 ETH i saldo. Slashings slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] En validator bliver 'slashed' af to grunde: at foreslå to forskellige blokke til det samme slot og forsøge at skabe en fork, eller at lave modstridende attestations. Slashing-feltet er en fast liste med 8192 poster, én pr. epoch. Den indeholder summen af alle validatorers effektive saldo, der er blevet 'slashed'. Dette felt bruges til at beregne strafbeløbet. Attestations previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] Hver aktiv validator attesterer én gang pr. epoch, og disse attestations driver både fork choice-reglen (LMD-GHOST) og finalitetsmekanismen (Casper FFG). En attestation indeholder seks underfelter: 'et, som validatoren attesterer for, er den blok, som validatoren anser for at være kædens hoved; den betragtes som en LMD-GHOST-afstemning af validatoren, der bruges til at bestemme fork choice. er epoch-checktæppet, som validatoren mener er retfærdiggjort, og er den aktuelle epoch, som validatoren attesterer for; begge kombineres til Casper FFG-afstemningen, der bruges til finalitet. Simpelthen sagt attesterer validatoren, at source-epoch'en skal gøres endelig, og target-epoch'en skal gøres retfærdiggjort. angiver, hvilken validator i komitéen der har attesteret. Da det er billigere at kombinere ting som bits i en byte, gemmes aggregeringsbitten i et bitfelt for hukommelseseffektivitet. Endelig har vi af validatoren over attesteringsdata. slot beacon block root source target aggregation bits signaturen Finalitet justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint Finalitet betyder, at en blok og alle dens transaktioner aldrig kan omgøres. I Beacon Chain er finalitet absolut. Når en epoch er gjort endelig, er den eneste måde at omgøre den på, hvis 1/3 af al staked ETH bliver 'slashed', hvilket ville koste milliarder af dollars. Justification bits er en bitvektor af længde 4, den sporer grundlæggende kun, om de sidste fire epochs er blevet retfærdiggjort. Det tidligere retfærdiggjorte checkpoint er det checkpoint, der blev retfærdiggjort pr. den forrige epoch. Det aktuelle retfærdiggjorte checkpoint er det senest retfærdiggjorte checkpoint, mens det endelige checkpoint er det senest endelige checkpoint. En epoch bliver retfærdiggjort, når 2/3 af den samlede aktive stake attesterer en supermajoritetsforbindelse, der peger på den epoch som target. Finalisering sker, når man får to retfærdiggjorte checkpoints i træk. I det øjeblik det andet bliver retfærdiggjort, opgraderes det første til 'finalized', selvom der er flere nuancer til det. Tilstandsmaskinen Nu hvor vi ved, hvad tilstanden indeholder, kan vi se på, hvordan den ændrer sig. Hvert 12. sekund ankommer et nyt slot. Hvis en blok foreslås, tager tilstandsovergangsfunktionen den aktuelle tilstand og den blok, udfører validering, opdaterer og giver en ny tilstand. Denne proces er opdelt i tre faser ifølge specifikationen: slotbehandling, blokbehandling og epochbehandling. Slotbehandling Slotbehandling kører, hver gang kæden skal avancere fra et slot til det næste, uanset om der blev produceret en blok eller ej. Tre ting sker, når et slot avancerer fra N til N+1. Først opdateres tilstandsroden for slot N for at bevare en registrering af, hvordan slottet så ud på det tidspunkt. For det andet opdateres den seneste blokheader, der gemmer headeren for den senest behandlede blok, også; husk, at dette felt bruges til at forhindre duplikatblokke. Også roden af den færdiggjorte header skrives ind i blokroden. Sidst, men ikke mindst, inkrementeres slot-tælleren med én. Du spekulerer måske på, hvad der sker med tilstanden, når en proposer går glip af sit slot. Nå, al tilstand opdateres stadig, f.eks. vil blokrødderne for det pågældende slot indeholde roden af den samme seneste blokheader, da ingen ny blok ankom for at erstatte den. Efter at have inkrementeret slottet, kontrollerer kæden, om den lige har krydset en epoch-grænse, hvilket let kan gøres med 'slot mod 32 == 0'. Hvis ja, træder epochbehandling i kraft, før noget andet sker. Så teknisk set, for hver 32 slots, kører epochbehandling parallelt med slotbehandling, med andre ord, epochbehandling kører efter, at slottet er avanceret, men før blokken til det slot behandles. Endnu et vigtigt punkt er, at når vi når det punkt, hvor arraysene for tilstands- og blokrødder er fyldt op, dvs. ved 'slot mod 8192 == 0'-positionen, før begge arrays begynder at blive overskrevet af nye data, da det virker cirkulært, hasher kæden de to felter sammen og tilføjer dem til den historiske tilstand. Blokbehandling Blokbehandling kører, når en blok faktisk foreslås for et slot. Efter at slotbehandling har avanceret tilstanden til det korrekte slot, tager blokbehandling den signerede blok og anvender dens indhold på tilstanden. Den har to hoveddele: validering af blokheaderen og behandling af blokkroppen. Før noget andet kontrollerer kæden et par ting, som om blokheaderen stemmer overens med den aktuelle tilstands-slot, og om blok proposer-indekset rent faktisk er den validator, som randao har valgt. Endelig kontrollerer den, om blokkens forældrerod stemmer overens med roden af den seneste blokheader. Hvis den er valideret, gemmes blokheaderen som den seneste blokheader i tilstanden. Derefter skal proposeren inkludere en randao-reveal, som, som jeg sagde tidligere, grundlæggende er det aktuelle epoch-nummer signeret af validatoren. Kæden verificerer signaturen mod proposers offentlige nøgle. Det er let at se, at denne aktuelle metode er deterministisk, at validatorens signatur altid vil forblive den samme for det samme epoch-nummer, sandt, faktisk er hele pointen med at gøre det på denne måde at tillade enhver at bruge validatorens offentlige nøgle til at kontrollere epoch-nummeret, som validatoren faktisk har underskrevet. Bemærk, at en proposer ikke kan springe randao-reveal over; hvis de foreslår en blok, skal de inkludere den, den eneste måde at springe processen over på er ved slet ikke at foreslå en blok. Derefter vil proposeren også inkludere sit syn på Eth1-kædens indbetalingskontraktstilstand som en Eth1-data-afstemning. Hvis en hvilken som helst Eth1-data-værdi i afstemningslisten når et flertal, bliver den til de nye Eth1-data i tilstanden. Under blokbehandling indeholder proposer-slashing-feltet bevis for, at en validator underskriver to forskellige blokheadere for det samme slot. Kæden verificerer begge signaturer, og hvis de er gyldige, 'slasher' den dem ved først at sætte deres 'slashed'-flag til sandt og tilføje deres effektive saldo til slashing-arrayet. Ligeledes, for attestanterne, hvis der er modstridende attestationer, verificerer kæden dem og identificerer de skyldige validatorer gennem deres signatur og 'slasher' derefter de validatorer, på samme måde og proces som blok proposer slashing. Nye attestations i blokken valideres, attestationen konverteres til en ventende attestation ved at tilføje to nye felter, som er inkluderingsforsinkelsen og proposer-indekset, og derefter tilføjes de enten til den aktuelle epoch-attestation eller den forrige epoch-attestation. Intet sker videre, når de er tilføjet, da de ikke påvirker tilstanden med det samme; de ligger der, indtil epochbehandling evaluerer dem. Nye validators indbetalinger fra Eth1 indbetalingskontrakten behandles. Blokken skal inkludere alle ventende indbetalinger op til det maksimale antal indbetalinger på 16. Kæden verificerer hver indbetalings merkle-bevis mod indbetalingsroden for at sikre, at den er korrekt. Hvis indskyderens offentlige nøgle er ny, tilføjes en ny validatorpost samt den tilsvarende saldo. En validator kan signalere, at de ønsker at forlade, ved at indsende en underskrevet frivillig udgang. Kæden kontrollerer, at validatoren har været aktiv i mindst 256 epochs, og at den aktuelle epoch er mindst den angivne 'exit epoch'. Hvis alt tjekker ud, sættes validatorens 'exit epoch' og 'withdrawable epoch'. Efter at alt ovenstående er behandlet, er der et sidste, men vigtigt punkt, nemlig at den beregnede tilstandsrod af den anden node sammenlignes med den tilstandsrod, der er inkluderet i blokken. Hvis de ikke stemmer overens, afvises hele blokken. Epochbehandling Epochbehandling udløses ved epoch-grænsen, som er hvert 'slot mod 32 = 0'-trin. Den kører under slotbehandling, når slot-tælleren krydser ind i en ny epoch. Det er den mest komplekse fase, da de fleste af de seje konsensus-ting sker her. Først kommer retfærdiggørelse og finalitet i gang. Det er her, Casper FFG udfører sit arbejde. Processen kan lyde kompleks, men den er meget enkel. Simpelthen sagt, kigger kæden på attestations fra den forrige epoch og tæller de effektive saldi af validatorer, der attesterede med det korrekte target. Hvis den sum er mindst 2/3 af den samlede aktive saldo, bliver target-epoch'en retfærdiggjort, og hvis to på hinanden følgende epochs er retfærdiggjort, bliver den tidligere 'finalized'. Nemt! Et faktum, som jeg ikke pegede på i blokbehandlingsfasen, er, at validatorerne akkumulerer belønninger for hver fase; de belønnes for at inkludere attestation eller for at tilføje slashing-beviser eller endda for normal basisbelønning. Disse akkumulerede belønninger evalueres af kæden over den forrige epoch i epochbehandlingsfasen og justerer deres saldo tilsvarende. Hvis kæden ikke har været 'finalized' i mere end fire epochs, træder det, der beskrives som "inaktivitetslækket", i kraft. Oven på de normale straffe for at gå glip af attestations, får ikke-deltagende validatorer en yderligere inaktivitetsstraf, der vokser kvadratisk med hver epoch siden den sidste 'finalized' epoch. Med andre ord, jo længere tid det tager en blok at blive 'finalized', jo hårdere er din straf. Du spekulerer måske på, hvad formålet med dette er. Nu, når en blok ikke er blevet 'finalized' i et stykke tid, betyder det, at der ikke er et flertalsafstemning om den blok, og da afstemning om finalitet måles ved vægten af en validators effektive saldo, grundlæggende hvor mange ETH validatoren har, reducerer en reduktion i deres effektive saldo deres stemmekraft. Således bruger Ethereum det som en måde at tvinge blokfinalitet på. Det er værd at bemærke, at under et inaktivitetslække modtager selv korrekte attestanter ikke belønninger. Alt skifter til ren straftilstand for at fremskynde rebalanceringen. En anden vigtig begivenhed, der sker på dette stadie, er aktiveringen af validatorer, hvis 'activation eligibility epoch' er nået. Desuden flyttes validatorer, hvis 'exit epoch' er ankommet, ud af det aktive sæt af validatorer. Derefter, husk at den effektive saldo ikke opdateres med hvert slot og hver epoch, fordi hysteres gælder. Den opdateres kun, hvis den faktiske saldo er steget tilstrækkeligt over den aktuelle effektive saldos øvre tærskel; den effektive saldo øges med 1 ETH, og hvis den falder under den nedre tærskel, falder den med 1 ETH. Endelig kopieres den aktuelle epochs randao-mix til den næste epochs slot. Som du tydeligt kan se, er epochbehandling den mest komplicerede del af tilstandsmaskinen og er beregningsmæssigt uvenlig, hvilket fører til en masse optimeringsarbejde for ingeniørerne, der bygger kædeklienterne. Fra Fase 0 til Fulu BeaconState, som vi har gennemgået hidtil, er Fase 0-versionen, den originale. Men Beacon Chain er et levende system. Hver konsensuslag-fork har modificeret BeaconState, enten ved at tilføje nye felter, fjerne gamle eller bare ændre, hvordan nogle eksisterende fungerer. For eksempel, i Altair-forken blev listerne for tidligere og nuværende epoch-attestationer helt fjernet for at blive erstattet af tidligere og nuværende epoch- . Forskellen er, at mens den tidligere gemte fulde attestation-objekter, gemmer den nye deltagelsestype den kun i bitform i stedet. Nu får hver validator kun tre bits pr. epoch, der angiver, om de fik kilden rigtig, target rigtig og hovedet rigtig. Dette førte til en drastisk reduktion i hukommelsesstørrelsen. Bellatrix, The Merge-forken, introducerede execution payload-feltet til beaconState. Dette felt bruges til at forbinde konsensuslaget og udførelseslaget. Eth1-felterne blev bibeholdt, men deres roller blev reduceret, da de ikke længere var nødvendige. deltagelse Capella-forken introducerede udbetalingsmuligheder for validatoren. Den registrerer det ved at tilføje et nyt felt kaldet 'next withdrawal index' til beaconState. Historical roots blev erstattet af historical summaries, der gemmer blokrod og tilstandsrod i en struct i stedet for at hashe dem sammen. Deneb-forken havde derimod næsten ingen indflydelse på beaconState, fordi forken primært handlede om blobs. I Electra og Fulu var den vigtigste ændring at hæve den maksimale effektive saldo fra 32 ETH til 2048 ETH, hvilket førte til introduktionen af nye felter i beaconState. Hver fork byggede på den forrige, og BeaconState voksede fra 21 felter i Fase 0 til over 30 i Fulu. Én ting er konstant: Fra Fase 0 til Fulu er tilstanden vokset, forks tilføjer felter, forks fjerner felter, men arkitekturen er forblevet den samme. Konklusion Beacon Chain beskrives ofte som kompleks, ja, det er jeg enig i, for den er kompleks. Men i sin kerne er det grundlæggende en cyklus af: en tilstand eksisterer, en input ankommer, eksisterende tilstand opdateres for at producere en ny tilstand, og så gentages det! Simpelt! Det, der gør Beacon Chain virkelig bemærkelsesværdig, er ikke noget enkelt felt, men hvordan det hele forbinder for at give os den fantastiske 'tek', vi har i dag! Referencer Ethereum Consensus Specifications (Phase 0) Ethereum Annotated Specification af 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 om The Merge Ethereum Annotated Spec af Vitalik Buterin
