A blokklánc nem egy új találmány, de a technológia folyamatosan fejlődik. A blokklánc technológia a bitcoinnal együtt jelent meg, de azóta számos más alkalmazása is lett. A blokklánc technológia a kriptovalutákon kívül más területeken is felhasználható, mint például az egészségügy, a pénzügy vagy a szavazási rendszerek. A blokklánc technológia decentralizált jellegéből adódóan biztonságos és átlátható megoldást kínál az adatok kezelésére.

Valószínűleg az Ethereum történetének legfontosabb eseménye, a Merge 2022. szeptember 15-én zajlott le. Ez jelölte a hálózat átállását a rendszerről a rendszerre, alapvetően megváltoztatva, hogyan éri el az Ethereum a konszenzust. De miért hívják „ ”-nek, és nem „átmenetnek”? Proof of Work Proof of Stake Merge A Merge előtt az Ethereum a Proof of Work konszenzust használta, egy olyan mechanizmust, amelyhez „bányászokra” volt szükség, hogy összetett kriptográfiai rejtvényeket oldjanak meg a tranzakciók érvényesítéséhez és új blokkok létrehozásához. A PoW nagyszerű, de számos korlátja van, mint például az óriási számítási teljesítmény felhasználása, ami magas villamosenergia-fogyasztáshoz és környezeti aggályokhoz vezet, alacsony tranzakciós átviteli sebesség a lassabb ellenőrzési idő miatt, így kihívást jelent az intézményi elfogadás számára, nagyobb esély a központosítás kockázatára, mivel kevés hatalmas bányászati entitásba tömörülhet, stb. Ezek és más okok motiválták az Ethereum Alapítványt, hogy a létrehozása után mindössze három évvel elkezdjen egy új konszenzus mechanizmust, a Proof of Stake-et építeni, amelynek célja a PoW által jelentett problémák többségének megoldása. 2020. december 1-jén az Ethereum elindította a PoS első verzióját, egy új láncot, amelyet Beacon Chain-nek neveztek el. A Beacon Chain nem dolgozta fel a felhasználói tranzakciókat. Kizárólagos célja az volt, hogy koordinálja az érvényesítőket és konszenzust érjen el egy új mechanizmus, a Gasper segítségével. A tranzakciókat továbbra is a fő Proof of Work lánc dolgozta fel, így mindkét lánc, az Ethereum fő lánca és a Beacon Chain, párhuzamosan futott. Majdnem két évig ez a két lánc függetlenül működött. Aztán 2022. szeptember 15-én az eredeti lánc elhagyta bányászaton alapuló konszenzusát, és közvetlenül csatlakozott a Beacon Chain-hez. Így a két lánc eggyé vált. Ezért hívják Merge-nek, nem átmenetnek. Ma az Ethereum kétrétegű blokkláncként működik. A konszenzusréteg, amely korábban a Beacon Chain volt, kezeli a blokkjavaslatokat, az igazolásokat és a véglegesítést. Az izvrésréteg, az eredeti Ethereum lánc, kezeli a tranzakciók feldolgozását. Lehet, hogy ezekre Eth2-ként és Eth1-ként hivatkoztak, de az Ethereum Alapítvány elavulttá tette ezt a megnevezést, mert két különálló hálózatot sugallt, nem pedig egy rendszer két rétegét. Ez a cikk a konszenzusrétegre összpontosít. Konkrétan arra, hogyan működik a Beacon Chain állapotgépként. Mi az a BeaconState? Az állapotgép átmeneteinek megértéséhez először meg kell értenünk, hogy az állapot valójában mit tartalmaz a lánc genezisekor. A Beacon Chain állapota egyetlen objektumként jelenik meg, amelyet BeaconState-nek neveznek. Tartalmaz mindent, amire a konszenzusrétegnek szüksége van a működéshez. Néha „Isten objektumnak” is nevezik. Maga a specifikáció a mezőket céljuk szerint csoportosítja, ami a legvilágosabb módja azok áttekintésének. 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 Verziózás: genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork Az első négy változó válaszol a „milyen láncon vagyunk, és hol vagyunk azon a láncon?” kérdésre. Ezek a mezők rögzítik a lánc azonosítóját, és megmondják minden csomópontnak, hogy milyen protokollszabályokat kell követnie. A genezis időpontja egy Unix időbélyeg, amelyet a lánc elején állítottak be, és soha nem változik. A Beacon Chain genezis időbélyege 1606824023, ami pontosan 2020. december 1., 12:00:23 UTC. Ha valaha is lekérdeztél egy okosszerződésből egy „block.timestamp” értéket, az ebből a mezőből számítódik. A genezis érvényesítő gyökér, akárcsak az időbélyeg, szintén a lánc elején került hozzáadásra. Alapvetően csak domain elválasztóként működik; az érvényesítő aláírásával együtt használják a blokkjavaslatok és igazolások során, hogy megkülönböztessék az Ethereum főhálózatot bármely más lánctól. A Slot (rés) egyszerűen egy számláló, amely megmutatja, hogy a lánc hol tart az időben. 12 másodpercenként növekszik, függetlenül attól, hogy előállítottak-e blokkot. Míg a Fork (eloszlás) egy objektum, amely három mezőt tartalmaz: az előző lánc verziója, az aktuális lánc verziója és az epoch (időszak). Amikor a Beacon Chain első frissítése 2021. október 27-én megtörtént, a verziók a Phase 0-ról Altairra váltottak. Az aktuális verzió, a cikk írásakor, Fulu, és az előző verzió Electra. Akárcsak az érvényesítő gyökér, a verzió hash-t is hozzáadják az aláírásokhoz, hogy megkülönböztessék az egyik elágazást a másiktól. Az Epoch ezzel szemben 32 slot csomagja, ami , durván 6,4 perc. Itt történnek a véglegesítési ellenőrzések, a lecsapási büntetések, a kilépési várólista és minden más cool konszenzusspecifikus dolog. Itt működik a Casper FFG, a Gasper utolsó része. 12 másodperc x 32 Történelem 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] Ez a rész válaszol a „Mi történt ezen a láncon?” kérdésre. Ezek a változók tömör memóriát biztosítanak a lánc múltjáról, lehetővé téve az érvényesítők számára, hogy hivatkozzanak és ellenőrizzék a korábbi állapotokat anélkül, hogy mindent tárolniuk kellene. A legutóbbi blokk fejléce tárolja a legutóbb feldolgozott blokk fejlécét. Ezt a kettős blokkok megelőzésére használják, mert mielőtt egy új blokkot feldolgoznának, a lánc ellenőrzi, hogy a blokk szülő gyökere megegyezik-e a legutóbbi blokk fejlécének gyökerével. Mind a blokk gyökerek, mind az állapot gyökerek mezők listák, amelyek tárolják a múltbeli blokk gyökereket és állapot gyökereket, amíg meg nem telnek. Minden slotban a gyökerek a megfelelő tömbökbe íródnak a indexen. Ez lehetővé teszi a lánc számára, hogy lekérdezze, hogy az állapot hogyan nézett ki bármelyik nemrégen eltelt slotban a 27 órás ablakon belül. A Historical root (történelmi gyökér) összefűzi a blokk gyökerek és állapot gyökerek tömbjének egyesített hash-jét, amikor azok megtelnek. A lista határozatlan, de lassan növekszik, csak egy bejegyzéssel 27 óránként. slot%8192 Eth1 eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 A Merge előtt az Eth2 (Beacon Chain) nyomon kellett követnie, hogy mi történik az Eth1-en (PoW lánc), különösen a befizetési tranzakciókat, ahol az új érvényesítők 32 ETH-t zároltak. Talán azon gondolkodsz, miért volt a PoS céljára szánt 32 ETH zárolva a PoW láncban, nem pedig a Beacon Chain-ben. A válasz egyszerűen az, hogy maga a Beacon Chain nem rendelkezett token átviteli vagy tranzakció feldolgozási képességgel, mivel nem tudta natívan kezelni a token befizetéseket. Az Eth1 data három alkérdést tartalmaz: a , amely a befizetési szerződés befizetési fájának merkle gyökere; a , amely a szerződésre érkezett befizetések teljes száma; és a , amely a hivatkozott eth1 blokk hash-je. befizetési gyökeret befizetési számot blokk hash-t A Beacon Chain nem bízhat meg csak egy érvényesítő Eth1 láncra vonatkozó nézetében, mert a különböző érvényesítők eltérő állapotokat láthatnak a hálózati késedelmek miatt. Ezért használ egy szavazási mechanizmust, amely lehetővé teszi a blokk javaslók számára, hogy az aktuális Eth1 adatokról alkotott nézetüket beilleszthessék blokkjukba. Ezek a szavazatok egy szavazási időszak alatt halmozódnak ebben a listában, és ha bármely érték több mint fele szavazatot kap a periódust alatt, az lesz az új Eth1 adat. A szavazási időszak végén a lista törlődik, és a szavazás újraindul. Az Eth Befizetési Index nyomon követi, hogy a befizetési szerződésből eddig hány befizetés lett feldolgozva. Amikor a lánc feldolgoz egy új blokkot, ellenőrzi, hogy vannak-e fel nem dolgozott befizetések a befizetési index összehasonlításával az Eth1 adatok befizetési száma mezőjével. Ha a befizetések száma magasabb, a blokknak tartalmaznia kell a következő befizetéseket a blokkonkénti maximális befizetésig, ami akkoriban 16 volt. Névjegyzék validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] Ez a változó lényegében egy listát tárol arról, hogy kik vesznek részt a konszenzusban, és mennyi a tétjük. Egy érdekes tény a validators mezővel kapcsolatban, hogy csak növekszik és soha nem csökken, még akkor sem, ha egy érvényesítő kilép, az bejegyzése továbbra is a listán marad. Jelenleg 2 210 484 bejegyzés van, és csak 962 941 aktív. A Validator mező nyolc alkérdést tartalmaz: a , ami alapvetően az érvényesítő nyilvános kulcsa; a , ahová a tétjük kerül kivonáskor; az , az érvényesítő egyenlege lefelé kerekítve a legközelebbi gwei-re, amelyet a jutalmak és büntetések kiszámítására használnak, és csak epoch határokon frissül hiszterézissel, hogy megakadályozzák a fel-le ingadozását; a , egy logikai zászló, amelyet arra használnak, hogy jelezzék, ha egy érvényesítőt lenulláztak; az , az az epoch száma, amikor az érvényesítő jogosulttá vált az aktiválásra; az , az az epoch, amikor aktiválásra került; a , az az epoch, amikor kilépett; és végül a , az az epoch, amikor az egyenlege kivehető. pubKey withdrawable credentials effective balance slashed activation eligibility epoch activation epoch exit epoch withdrawable epoch Annak magyarázatára, hogy miért van egy effective balance mező a validator listában, és egy balances mező közvetlenül a beacon state-ben: az effective balance mező nem frissül abban a pillanatban, amikor a tényleges egyenlege frissül; van egy puffer, amely megakadályozza a vissza-oda mozgást. Hisztézis nélkül, egy 32 ETH körül ingadozó érvényesítő, mondjuk 31,99 és 32,01 között minden epochban jutalmak és büntetések miatt, az effective balance-e minden epochban 31-ről 32-re váltana. Ez azt jelentené, hogy az érvényesítő objektumot folyamatosan újra kellene Merkle-izálni, és az epochonkénti bizottsági számításokban a súlyukat állandóan változtatni kellene. Véletlenszerűség randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] A randao_mixes egy 65 536 (kb. 2^16) bejegyzésből álló, rögzített méretű lista. Minden alkalommal, amikor egy érvényesítő blokkot javasol, hozzáad egy úgynevezett „randao reveal”-t a listához. Ez a reveal lényegében az érvényesítő által aláírt aktuális epoch száma. Az aláírás után a lánc ezt veszi, és XOR-olja az aktuális epoch utolsó keverékével, ami egy új keveréket eredményez. Minden epochban minden javasló ugyanazt csinálja, hogy megszerezze a végső felhalmozott keveréket a következő epochra. A randao keverék a következő epoch bizottságának és blokkjavaslóinak meghatározására szolgál. A bizottság, amely az összes aktív érvényesítő 32 slotra van felosztva, az „swap-or-not” (csere-vagy-nem) keverési algoritmussal kerül meghatározásra. Ez az algoritmus lényegében véletlenszerűen cseréli fel az érvényesítő indexét a keverékkel. A blokkjavasló kiválasztásához a lánc hasheli a randao keveréket egy mag létrehozásához. Aztán végigmegy az összes aktív érvényesítőn, egy véletlenszerű eltolódástól kezdve, amelyet ebből a magból származtat. Minden jelölt esetében ellenőrzi, hogy a mag és az érvényesítő index hash-je, osztva az érvényesítő effektív egyenlegével, átlép-e egy küszöbértéket. Ha igen, az érvényesítő lesz a javasló, ha nem, akkor a következőre ugrik. A gyakorlatban gyorsan talál egyet, mivel a legtöbb aktív érvényesítőnek 32 ETH egyenlege van. Lefejlődések slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] Egy érvényesítőt két okból fejelnek le: kettő különböző blokkot javasol ugyanazon slotra, megpróbálva elágazást létrehozni, vagy ellentmondásos igazolásokat tesz. A slashings mező egy 8192 bejegyzésből álló fix lista, egy epochonként. Tartalmazza az összes lenullázott érvényesítő effektív egyenlegének összegét. Ezt a mezőt a büntetési összeg kiszámítására használják. Igazolások previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] Minden aktív érvényesítő epochonként egyszer igazol, és ezek az igazolások vezérlik mind az elágazás választási szabályt (LMD-GHOST), mind a véglegesítési mechanizmust (Casper FFG). Egy igazolás hat alkérdést tartalmaz: a , amiért az érvényesítő igazol; a , ami az a blokk, amelyet az érvényesítő a lánc csúcsának tekint, és amit az érvényesítő LMD-GHOST szavazataként tekintenek az elágazás választásának meghatározására; a az az epoch ellenőrzőpont, amelyet az érvényesítő indokoltnak tart; és a az aktuális epoch, amiért az érvényesítő igazol. Mindkettő együtt alkotja a Casper FFG szavazatot, amelyet a véglegesítéshez használnak. Egyszerűen fogalmazva, az érvényesítő igazolja, hogy a forrás epoch-ot véglegesíteni kell, és a cél epoch-ot indokolttá kell tenni. Az jelzi, hogy a bizottságban melyik érvényesítő igazolt. Mivel olcsóbb az elemeket bitekként egy bájtban kombinálni, az aggregációs bit a memória hatékonysága érdekében egy bitmezőben tárolódik. Végül van az érvényesítő az igazolási adatokra. slot beacon block root source target aggregation bits aláírása Véglegesítés justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint A véglegesítés azt jelenti, hogy egy blokkot és az összes tranzakcióját soha többé nem lehet visszafordítani. A Beacon Chain-ben a véglegesítés abszolút. Miután egy epoch véglegesítésre került, az egyetlen módja annak visszafordításának az, ha az összes staking ETH 1/3-át lenullázzák, ami milliárd dollárokba kerülne. A justification bits (indoklási bitek) egy 4 hosszúságú bitvektor, amely lényegében csak azt követi nyomon, hogy az utolsó négy epoch indokolt volt-e. Az előzőleg indokolt ellenőrzőpont az az ellenőrzőpont, amelyet az előző epoch-ban indokoltak. Az aktuális indokolt ellenőrzőpont a legutóbbi indokolt ellenőrzőpont, míg a véglegesített ellenőrzőpont a legutóbbi véglegesített ellenőrzőpont. Egy epoch indokolttá válik, amikor a teljes aktív tét 2/3-a igazol egy szuper-többségi kapcsolatot, amely az epochra mutat célként. A véglegesítés akkor történik, amikor két egymást követő indokolt epoch-ot kapsz. Abban a pillanatban, amikor a másodikat indokolttá teszik, az elsőt véglegesítettre frissítik, bár van néhány további árnyalat. Az Állapotgép Most, hogy tudjuk, mit tartalmaz az állapot, megnézhetjük, hogyan változik. Minden 12 másodpercben új slot érkezik. Ha egy blokkot javasolnak, az állapotátmeneti funkció veszi az aktuális állapotot és azt a blokkot, futtatja az érvényesítést, frissíti, és kimenetként egy új állapotot állít elő. Ezt a folyamatot a specifikáció három szakaszra osztja: slot feldolgozás, blokk feldolgozás és epoch feldolgozás. Slot Feldolgozás A Slot Processing minden alkalommal fut, amikor a láncnak egyik slotból a következőbe kell átlépnie, függetlenül attól, hogy blokkot állítottak-e elő. Három dolog történik, amikor egy slot N-ről N+1-re lép. Először is, az N slot állapot gyökerét frissítik, hogy megőrizzék az adott slot állapotának rekordját. Másodszor, a legutóbbi blokk fejlécét, amely a legutóbb feldolgozott blokk fejlécét tárolja, szintén frissítik – ne feledd, ezt a mezőt a kettős blokkok megelőzésére használják. Továbbá, annak a teljes fejlécnek a gyökerét beírják a blokk gyökerek közé. Végül pedig a slot számlálót eggyel növelik. Talán azon gondolkodsz, mi történik az állapottal, ha egy javasló kihagyja a slotját. Nos, minden állapot frissül, a slot blokk gyökerei például ugyanazt a legutóbbi blokk fejléc gyökerét fogják tartalmazni, mivel nem érkezett új blokk, amely helyettesítené. A slot növelése után a lánc ellenőrzi, hogy épp egy epoch határt lépett-e át, amit könnyen megtehetünk a `slot mod 32 == 0` paranccsal. Ha igen, az epoch feldolgozás lép életbe, mielőtt bármi más történne. Tehát technikailag minden 32 slot után az epoch feldolgozás a slot feldolgozással együtt fut, más szóval, az epoch feldolgozás a slot előrelépése után fut, de még mielőtt az adott slot blokkját feldolgoznák. Egy utolsó megjegyzés: amikor az állapot gyökerek és a blokk gyökerek tömbje megtelt, azaz a `slot mod 8192 == 0` pozícióban, mielőtt mindkét tömb elkezdi felülíródni új adatokkal, mivel körkörösnek tűnik, a lánc összefűzi a két mezőt, és hozzáadja a történelmi állapothoz. Blokk Feldolgozás A blokk feldolgozás akkor fut, amikor egy blokkot ténylegesen javasolnak egy slotra. Miután a slot feldolgozás az állapotot a megfelelő slotra léptette, a blokk feldolgozás veszi az aláírt blokkot, és alkalmazza annak tartalmát az állapotra. Két fő részből áll: a blokk fejlécének érvényesítése és a blokk törzsének feldolgozása. Mindenekelőtt a lánc ellenőriz néhány dolgot, például, hogy a blokk fejléc megegyezik-e az aktuális állapot slotjával, és hogy a blokk javasló indexe valóban az a validátor-e, amelyet a randao kiválasztott. Végül ellenőrzi, hogy a blokk szülő gyökerének meg kell-e egyeznie a legutóbbi blokk fejlécének gyökerével. Ha érvényesítve van, a blokk fejlécét legutóbbi blokk fejlécnek tárolják az állapotban. Ezután a javaslónak tartalmaznia kell egy randao rebeat-et, amely, mint korábban mondtam, lényegében az érvényesítő által aláírt aktuális epoch száma. A lánc ellenőrzi az aláírást a javasló nyilvános kulcsával szemben. Könnyű megmondani, hogy ez az aktuális módszer determinisztikus, hogy az érvényesítő aláírása mindig ugyanaz marad az azonos epoch számmal, igaz, valójában az egész célja ennek a megközelítésnek az, hogy bárki használhassa az érvényesítő nyilvános kulcsát az epoch szám ellenőrzésére, amit az érvényesítő valójában aláírt. Ne feledd, hogy egy javasló nem hagyhatja ki a randao rebeat-et; ha blokkot javasol, tartalmaznia kell azt; az egyetlen módja a folyamat kihagyásának az, ha eleve nem javasol blokkot. Ezután a javasló tartalmazni fogja az Eth1 lánc befizetési szerződés állapotára vonatkozó nézetét is Eth1 adat szavazatként. Ha a szavazatok listájában bármely Eth1 adat érték többséget ér el, az lesz az új Eth1 adat az állapotban. A blokk feldolgozása során a javasló slashing mező tartalmazza azt a bizonyítékot, hogy egy érvényesítő két különböző blokk fejlécet ír alá ugyanazon slotra. A lánc mindkét aláírást érvényesíti, és ha érvényes, lenullázza őket azáltal, hogy először az `slashed` zászlójukat `true`-ra állítja, és hozzáadja az effektív egyenlegüket a slashings tömbhöz. Továbbá, az igazolók esetében, ha van bármilyen ellentmondásos igazolás, a lánc érvényesíti azt, és az aláírásukon keresztül azonosítja a bűnös érvényesítőket, majd lenullázza azokat az érvényesítőket, ugyanúgy és ugyanazzal a folyamattal, mint a blokk javasló lenullázása. Az új blokkban lévő igazolások érvényesítésre kerülnek, az igazolás "pending attestation"-né alakul két új mező hozzáadásával, amelyek az `inclusion delay` (bekerülési késleltetés) és a `proposer index` (javasló index), majd a `current epoch attestation` (aktuális epoch igazolás) vagy a `previous epoch attestation` (előző epoch igazolás) listájához kerülnek. Nincs sok teendő azután, hogy hozzáadták őket, mivel nem befolyásolják azonnal az állapotot; ott ülnek, amíg az epoch feldolgozás ki nem értékeli őket. Az Eth1 befizetési szerződésből származó új érvényesítő befizetések feldolgozásra kerülnek, a blokknak tartalmaznia kell az összes függőben lévő befizetést a maximális 16-os befizetésig. A lánc minden befizetés merkle bizonyítékát összehasonlítja a befizetési gyökérrel, hogy biztosítsa annak helyességét. Ha a befizető nyilvános kulcsai újak, egy új érvényesítő bejegyzést adnak hozzá, valamint a hozzá tartozó egyenleget. Egy érvényesítő jelezheti, hogy távozni szeretne egy aláírt önkéntes kilépés benyújtásával. A lánc ellenőrzi, hogy az érvényesítő legalább 256 epoch-on keresztül aktív volt-e, és hogy az aktuális epoch legalább a megadott kilépési epoch. Ha minden rendben van, az érvényesítő `exit epoch` (kilépési epoch) és `withdrawable epoch` (kivehető epoch) beállításra kerül. Miután a fent említett összes feldolgozás megtörtént, van még egy utolsó, de fontos darab: a számított állapot gyökere összehasonlításra kerül a blokkban szereplő állapot gyökérrel. Ha nem egyeznek, az egész blokkot elutasítják. Epoch Feldolgozás Az epoch feldolgozás az epoch határán indul el, ami minden `slot mod 32 = 0` lépésnél van. A slot feldolgozás során fut, amikor a slot számláló átlépi az új epoch-ot. Ez a legbonyolultabb szakasz, mivel itt történik a legtöbb cool konszenzus dolog. Először az indoklás és a véglegesítés lép életbe, itt végzi a munkáját a Casper FFG. A folyamat bonyolultnak tűnhet, de nagyon egyszerű. Egyszerűen fogalmazva, a lánc megnézi az előző epoch igazolásait, és megszámolja azoknak az érvényesítőknek az effektív egyenlegét, akik a helyes célra igazoltak. Ha ez az összeg legalább 2/3-a a teljes aktív tétnek, a cél epoch indokolttá válik, és ha két egymást követő epoch indokolttá válik, az előbbi véglegesítetté válik. Egyszerű! Egy tény, amit a blokk feldolgozási szakaszban nem említettem, hogy minden szakaszban az érvényesítők jutalmakat halmoznak fel; jutalmat kapnak az igazolás tartalmáért, vagy a lenullázási bizonyíték hozzáadásáért, vagy akár a normál alapjutalmat. Ezeket a felhalmozott jutalmakat a lánc az előző epoch során értékeli ki az epoch feldolgozási szakaszban, és ennek megfelelően módosítja az egyenlegüket. Ha a lánc több mint négy epochon keresztül nem véglegesített, akkor az „inaktivitási szivárgás” nevű dolog lép életbe. A hiányzó igazolások normál büntetésein felül, a nem részt vevő érvényesítők egy további inaktivitási büntetéssel szembesülnek, amely négyzetesen nő minden egyes epoch után az utolsó véglegesített epoch óta. Más szóval, minél tovább tart egy blokk véglegesítése, annál szigorúbb a büntetés. Talán azon gondolkodsz, mi értelme ennek. Nos, ha egy blokk egy ideje nem véglegesített, az azt jelenti, hogy nincs többségi szavazat a blokkon, és mivel a véglegesítésre való szavazás az érvényesítő effektív egyenlegének súlyával mérhető, alapvetően azzal, hogy mennyi ETH-ja van az érvényesítőnek, az effektív egyenlegük csökkenése csökkenti a szavazati erejüket. Így az Ethereum ezt a blokkvéglegesítés kikényszerítésére használja.