د بلېدو سره، د ایتھیرم د تاریخ تر ټولو مهمه پیښه، د سپتمبر په 15, 2022 نیټه ترسره شوه. دا د شبکې لیږد له څخه ته په نښه کړ، په بنسټیز ډول یې هغه طریقه بدله کړه چې ایتھیرم موافقه تر لاسه کوي. خو ولې ورته ' ' ویل کیږي او 'لیږد' نه؟ Proof of Work Proof of Stake د بلېدو د بلېدو دمخه، ایتھیرم د Proof of Work موافقت سیسټم کاوه، یوه طریقه چې 'کان کیندونکو' ته یې اړتیا درلوده ترڅو پیچلي کریپټوګرافیکي پزلونه حل کړي، لیږدونې تایید کړي، او نوي بلاکونه رامنځته کړي. PoW خوندور دی، مګر دا ډیری محدودیتونه لري، لکه د لوی کمپیوټري ځواک کارول چې د لوړ بریښنا مصرف او چاپیریال اندیښنو لامل کیږي، د ټیټ لیږد له امله د لیږد ټیټه کچه د دې وروستي تایید وخت له امله، له همدې امله، د اداري تصویب لپاره یوه ننګونه، د مرکزي کیدو خطر لوړ احتمال، ځکه چې دا ممکن په یو څو ځواکمنو کان کیندونکو شرکتونو متمرکز شي، او داسې نور. دا او نور دلیلونه هغه هڅونې وې چې ایتھیرم فاونډیشن یې وهڅوله، یوازې له پیل څخه درې کاله وروسته، ترڅو د Proof of Stake په نوم یو نوی موافقت سیسټم جوړ کړي، چې د PoW ننګونو ډیری مسلو حل کولو لپاره ډیزاین شوی. د دسمبر په 1, 2020، ایتھیرم د PoS لومړۍ نسخه خپره کړه، یوه نوې چینل چې د Beacon چین په نوم یادیږي. Beacon چین د کاروونکو لیږدونه نه ترسره کول. د دې یوازینی هدف دا و چې تصدیق کونکي تنظیم کړي او د Gasper په نوم یو نوي میکانیزم په کارولو سره موافقه تر لاسه کړي. لیږدونه لاهم په اصلي Proof of Work چینل کې ترسره کیدل، نو دواړه چینلونه، د ایتھیرم اصلي چینل او Beacon چین، موازي پرمخ تلل. شاوخوا دوه کاله، دا دوه چینلونه په خپلواک ډول کار کاوه. بیا، د سپتمبر په 15, 2022، اصلي چینل خپل د کان کیندنې پر بنسټ موافقت سیسټم پریښود او مستقیم Beacon چین سره وصل شو. په دې توګه، دوه چینلونه یو شو. له همدې امله دې ته بلېدو ویل کیږي، نه لیږد. نن ورځ، ایتھیرم د دوه پوړیز بلاکچین په توګه کار کوي. د موافقت پوړ، چې پخوا د Beacon چین و، د بلاک وړاندیزونه، تاییدونه، او پایښت اداره کوي. د اجرا پوړ، اصلي ایتھیرم چین، د لیږد پروسس اداره کوي. تاسو ممکن دې ته په ترتیب سره Eth2 او Eth1 ویلي وي، مګر د ایتھیرم فاونډیشن دې نومونو ته له پامه غورځولی ځکه چې دا د یو سیسټم د دوه پوړونو پرځای دوه جلا شبکې ښودلې. دا مقاله د موافقت پوړ تمرکز کوي. په ځانګړې توګه، دا چې Beacon چین د حالت ماشین په توګه څنګه کار کوي. د بیکن حالت څه دی؟ د حالت ماشین بدلونونو د پوهیدو لپاره، موږ لومړی باید پوه شو چې په پیل کې د چینل حالت څه لري. د Beacon چین حالت د BeaconState په نوم یو واحد څیز لخوا ښودل کیږي. دا هغه څه لري چې د موافقت پوړ ته د کار کولو لپاره اړین دي. دا ځینې وختونه د "خدای څیز" په نوم هم یادیږي. مشخصات پخپله فیلډونه د اهدافو له مخې ګروپ کوي، کوم چې د دوی له لارې تګ لپاره ترټولو روښانه لاره ده. 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 نسخه: genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork لومړي څلور متغیرونه پوښتنې ته ځواب ورکوي "موږ په کوم چینل کې یو، او په هغه چینل کې موږ چیرته یو؟". دا فیلډونه د چینل پیژندنه تثبیتوي او هر نوډ ته د پروتوکول قواعدو ته د اطاعت کولو لارښوونه کوي. د پیل وخت د یونیکس وخت مهر دی چې د چینل په پیل کې ټاکل شوی، او دا هیڅکله نه بدلیږي. د بیکن چین د پیل وخت 1606824023 دی، چې دقیقا د دسمبر 1, 2020، په 12:00:23 PM UTC دی. که تاسو کله هم د سمارټ قرارداد څخه 'block.timestamp' پوښتلی وي، هغه ارزښت له دې فیلډ څخه محاسبه کیږي. د پیل تصدیق کونکي ریښه، د وخت مهر په څیر، په پیل کې چینل ته اضافه شوې وه. دا په اساس د ډومین جدا کونکي په توګه کار کوي؛ دا د بلاک وړاندیزونو او تاییدونو په جریان کې د تصدیق کونکي لاسلیک سره مخلوط کیږي ترڅو د ایتھیرم مینټ د نورو چینلونو څخه توپیر وکړي. Slot د ساده شمیرونکي په توګه کار کوي چې موږ ته وايي چینل په وخت کې چیرته دی. دا هره 12 ثانیې زیاتیږي، که څه هم یو بلاک تولید شوی وي یا نه. پداسې حال کې چې Fork یو څیز دی چې درې فیلډونه لري، دا د چینل پخوانی نسخه، د چینل اوسنی نسخه، او epoch شامل دي. کله چې د بیکن چین لومړی لوړوالی د اکتوبر په 27, 2021 کې ترسره شو، نسخې له Phase 0 څخه Altair ته بدل شوې. د اوسنۍ مقالې د لیکلو په وخت کې، اوسنی نسخه Fulu ده، او پخوانی نسخه Electra ده. د تصدیق کونکي ریښې په څیر، د نسخه هش لاسلیکونو ته اضافه کیږي ترڅو د یوې فورک نسخې له بلې څخه توپیر وکړي. له بلې خوا، Epoch د 32 سلټونو یوه بسته ده، دا ، چې شاوخوا 6.4 دقیقې کیږي. دلته د پایښت چکونه، د سلیشینګ جریمه، د وتلو قطار، او نور ټول په زړه پورې موافقې ځانګړي شیان پیښیږي. دلته Casper FFG، د Gasper وروستۍ برخه، کار کوي. 12 sec x 32 تاریخ 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] دا برخه پوښتنې ته ځواب ورکوي، "په دې چینل څه پیښ شوي؟". دا متغیرونه چینل ته د خپل تیر وخت لنډ حافظه ورکوي، چې تصدیق کونکو ته اجازه ورکوي چې پخواني حالتونه راجع کړي او تایید کړي پرته له دې چې هرڅه ذخیره کړي. وروستی بلاک سرلیک د وروستي پروسس شوي بلاک سرلیک ذخیره کوي. دا د ډیپلیکیټ بلاکونو مخنیوي لپاره کارول کیږي ځکه چې، د نوي بلاک له پروسس کولو دمخه، چینل تاییدوي چې د بلاک والد ریښه د وروستي بلاک سرلیک له ریښې سره مطابقت لري. د بلاک ریښو او حالت ریښو دواړه ساحې لیستونه دي چې پخوانۍ بلاک ریښې او حالت ریښې ساتي تر هغه وخته چې دوی ډک شي. په هر سلټ کې، ریښې په انډیکس کې خپلو اړوندو سرې ته لیکل کیږي. دا چینل ته اجازه ورکوي چې د 27-ساعتې کړکۍ دننه په هر وروستي سلټ کې حالت څنګه ښکاري، lookup کړي. د تاریخ ریښه د بلاک ریښو او حالت ریښو د سرې د ګډ هش سره ضمیمه کیږي کله چې دوی ډک شي. لیست بې حده دی، مګر دا په ورو ورو وده کوي، یوازې په هرو 27 ساعتونو کې یوه ننوتنه. slot%8192 Eth1 eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 د بلېدو دمخه، Eth2 (Beacon چین) اړتیا درلوده چې په Eth1 (PoW چین) کې څه پیښیږي، په ځانګړي توګه د زیرمه لیږدونو تعقیب کړي چیرې چې نوي تصدیق کونکي 32 ETH بند کړي. تاسو شاید حیران یاست چې ولې 32 ETH چې د PoS لپاره وو، د Beacon چین پرځای په PoW چینل کې بند شوي وو. ځواب دا دی چې ځکه چې Beacon چین پخپله د توک نقل یا لیږد پروسس کولو وړتیا نه درلوده، ځکه چې دا په اصل کې د توک زیرمې نشي اداره کولی. Eth1 ډاټا درې فرعي فیلډونه لري، دا دي، ، کوم چې د زیرمو قرارداد د زیرمو ونې د میرکل ریښه ده، ، د قرارداد ته شوي ټول زیرمو شمیر، او ، د حواله شوي eth1 بلاک هش. د زیرمو ریښه د زیرمو شمیر د بلاک هش Beacon چین یوازې په یوه تصدیق کونکي د Eth1 چینل لید باور نشي کولی ځکه چې مختلف تصدیق کونکي ممکن د شبکې ځنډ له امله مختلف حالتونه وګوري، نو دا د رایې ورکولو یو میتود کاروي چې د بلاک وړاندیز کونکو ته اجازه ورکوي چې د Eth1 اوسني ډاټا خپله لید په خپل بلاک کې شامل کړي. دا رایې د رایې ورکولو دورې په جریان کې په دې لیست کې راټیټیږي، او که کوم ارزښت د هغه دورې په جریان کې له نیمایي څخه ډیر رایې ترلاسه کړي، دا نوی Eth1 ډاټا کیږي. د رایې ورکولو دورې په پای کې، لیست پاک کیږي او رایې له سره پیل کیږي. Eth Deposit Index هغه شمیر زیرمو تعقیبوي چې د زیرمو قرارداد څخه تر اوسه پروسس شوي دي. کله چې چینل یو نوی بلاک پروسس کوي، دا چک کوي چې ایا د Eth1 ډاټا کې د زیرمو شمیر فیلډ په پرتله ناپروسس شوي زیرمې شتون لري. که د زیرمو شمیر لوړ وي، بلاک باید راتلونکي زیرمې تر اعظمي زیرمو پورې شامل کړي، کوم چې په هغه وخت کې 16 و. ثبت validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] دا متغیر اساسا د هغو کسانو لیست ساتي چې په موافقت کې برخه اخلي، او د دوی څومره ونډه لري. یو په زړه پورې حقیقت د تصدیق کونکو ساحه دا ده چې دا یوازې وده کوي او هیڅکله نه کمیږي، حتی وروسته له دې چې یو تصدیق کونکی بیرته واخلي، د دوی ننوتنه لاهم په لیست کې پاتې کیږي. اوس مهال، 2,210,484 ننوتنې شتون لري، او یوازې 962,941 اوس فعال دي. د Validator فیلډ اته فرعي فیلډونه لري، دا دي، ، کوم چې اساسا د تصدیق کونکي عام کیلي ده، ، چیرې چې د دوی ونډه د وتلو پر مهال ځي، ، د دوی توازن تر نږدې gwei ته راټیټ شوی چې د انعامونو او جریمو محاسبه لپاره کارول کیږي، او دا یوازې د epoch په سرحدونو کې د هایسټیریس سره تازه کیږي ترڅو د دې د ټیټیدو او پورته کیدو مخه ونیسي. ، یوه منطقي نښه چې د تصدیق کونکي د سلیش شوي په توګه کارول کیږي. ، د epoch شمیره کله چې تصدیق کونکی د فعالیدو لپاره وړ شو. ، د epoch شمیره کله چې دوی فعال شول. ، د epoch شمیره کله چې دوی پریښودل، او په پای کې ، د epoch شمیره کله چې د دوی توازن بیرته ترلاسه کیدی شي. pubKey withdrawable credentials effective balance slashed activation eligibility epoch activation epoch exit epoch withdrawable epoch د دې لپاره چې دا روښانه شي چې ولې موږ په تصدیق کونکي لیست کې یو اغیزمن توازن فیلډ لرو، او په بیکن حالت کې مستقیم توازن ساحه، دا ده چې، اغیزمن توازن فیلډ د هغه شیبه نه تازه کیږي کله چې ستاسو اصلي توازن تازه کیږي، هلته یوه بافر شتون لري ترڅو د دې له بیرته تګ مخه ونیسي. پرته له هایسټیریس، یو تصدیق کونکی چې د 32 ETH شاوخوا ګرځي، ووایو چې د هر epoch په جریان کې له 31.99 څخه 32.01 ته بدلیږي د انعامونو او جریمو له امله، د هر epoch په جریان کې به د 31 او 32 ترمنځ بدل شي. دا به پدې معنی وي چې د validator څیز په هر epoch کې په دوامداره توګه بیا میرکل کول او په کمیټې محاسبو کې د دوی وزن بدلول. بې نظمۍ randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] randao_mixes د 65,536 (شاوخوا 2 exp 16) ننوتنو یو ثابت اندازه لیست دی. هرکله چې یو تصدیق کونکی بلاک وړاندې کوي، دوی یو 'randao reveal' اضافه کوي. دا افشا اساسا د تصدیق کونکي لخوا لاسلیک شوی د اوسني epoch شمیره ده. د لاسلیک وروسته، چینل دا اخلي، او د اوسني epoch لپاره وروستي مکس سره XOR کوي، کوم چې یو نوی مکس تولیدوي. د یو epoch ټول وړاندیز کونکي ورته کار کوي ترڅو د راتلونکي epoch لپاره وروستی راټول شوی مکس ترلاسه کړي. د randao مکس د راتلونکي epoch لپاره کمیټې او د بلاک وړاندیز کونکي ټاکلو لپاره کارول کیږي. کمیټه، چې ټول فعال تصدیق کونکي په 32 سلټونو ویشل شوي دي، د 'swap-or-not' شافل الګوریتم لخوا ټاکل کیږي. دا الګوریتم اساسا د validator شاخص په تصادفي ډول له مکس سره بدلوي. د بلاک وړاندیز کونکي انتخاب لپاره، چینل د randao مکس هش کوي ترڅو یو تخم جوړ کړي. بیا دا د تصادفي آفسیټ څخه پیل کیږي چې له هغه تخم څخه ترلاسه کیږي، له ټولو فعالو تصدیق کونکو څخه تیریږي. د هر نوماند لپاره، دا چک کوي چې ایا د تخم او validator شاخص هش، د validator اغیزمن توازن لخوا ویشل شوی، یو حد پوره کوي. که دا کوي، validator وړاندیز کونکی کیږي، که دا نه کوي، دا بل ته تیریږي. په عمل کې دا په چټکۍ سره یو موندلی ځکه چې ډیری فعال تصدیق کونکي 32 ETH توازن لري. سلیشینګ slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] یو تصدیق کونکی د دوو دلیلونو لپاره سلیش کیږي، دا دي، د ورته سلټ لپاره دوه مختلف بلاکونه وړاندیز کول هڅه کول ترڅو یو فورک رامنځته کړي، یا، متضاد تاییدونه کول. د سلیشینګ ساحه د 8192 ننوتنو یو ثابت لیست دی، یو په هر epoch. دا د سلیش شوي ټولو تصدیق کونکو اغیزمن توازن مجموعه لري. دا ساحه د جریمې مقدار محاسبه کولو لپاره کارول کیږي. تاییدونه previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] هر فعال تصدیق کونکی په هر epoch کې یو ځل تایید کوي، او دا تاییدونه هغه څه دي چې د فورک انتخاب قانون (LMD-GHOST) او پایښت میکانیزم (Casper FFG) چلووي. یو تایید شپږ فرعي فیلډونه لري، دا دي، چې تصدیق کونکی یې تایید کوي، هغه بلاک دی چې تصدیق کونکی یې د چین د سر په توګه ګوري، دا د تصدیق کونکي لخوا د فورک انتخاب ټاکلو لپاره کارول شوي د LMD-GHOST رایې په توګه ګڼل کیږي. د epoch چکپاینټ دی چې تصدیق کونکی یې توجیه شوي ګڼي، او هغه اوسنی epoch دی چې تصدیق کونکی یې تاییدوي، دواړه په ګډه د Casper FFG رایې جوړوي چې په پایښت کې کارول کیږي. په ساده ډول، تصدیق کونکی تایید کوي چې د سرچینې epoch باید پایښت شي، او د هدف epoch باید توجیه شي. ښیې چې په کمیټه کې کوم تصدیق کونکي تایید کړی دی. ځکه چې دا په بایټ کې د شیانو ترکیب کول ارزانه دي، د استازیتوب بټ د حافظې موثریت لپاره په بټ فیلډ کې ساتل کیږي. په پای کې، موږ د تصدیق کونکي لاسلیک لرو چې د تایید ډاټا باندې لاسلیک کوي. slot beacon block root source target aggregation bits پایښت justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint پایښت پدې معنی دی چې یو بلاک او ټولې لیږدونه یې هیڅکله بیرته نه شي بدل کیدی. په Beacon Chain کې، پایښت مطلق دی. یوځل چې یو epoch پایښت شي، د دې بیرته راګرځولو یوازینۍ لاره دا ده که چیرې د ټولو سټیک شوي ETH 1/3 سلیش شي، کوم چې به ملیاردونه ډالر لګښت ولري. د توجیه بټونه د 4 اوږدوالي یو بټ ویکٹر دی، دا اساسا یوازې تعقیبوي که چیرې وروستي څلور epochs توجیه شوي وي. مخکینی توجیه شوی چکپاینټ هغه چکپاینټ دی چې د تیر epoch په توګه توجیه شوی و. اوسنی توجیه شوی چکپاینټ وروستی توجیه شوی چکپاینټ دی، پداسې حال کې چې پایښت شوی چکپاینټ وروستی پایښت شوی چکپاینټ دی. یو epoch توجیه کیږي کله چې د ټول فعال سټیک 2/3 تاییدونه د سوپر میجرایټي لینک ته اشاره کوي چې هغه epoch د هدف په توګه ګوري. پایښت هغه وخت پیښیږي کله چې تاسو دوه پرله پسې توجیه شوي چکپاینټونه ترلاسه کوئ. په هغه شیبه کې چې دوهم توجیه کیږي، لومړی پایښت ته لوړیږي، که څه هم په دې کې یو څه نور جزئیات شتون لري. د حالت ماشین اوس چې موږ پوهیږو حالت څه لري، موږ کولی شو وګورو چې دا څنګه بدلیږي. هره 12 ثانیې، یو نوی سلټ راځي. که چیرې یو بلاک وړاندې شي، د حالت لیږد فنکشن اوسنی حالت او هغه بلاک اخلي، تایید چلوي، تازه کوي، او یو نوی حالت تولیدوي. دا پروسه د مشخصاتو لخوا په دریو مرحلو ویشل شوې ده: سلټ پروسس کول، بلاک پروسس کول، او epoch پروسس کول. د سلټ پروسس کول د سلټ پروسس کول هرکله چې چینل له یو سلټ څخه بل ته پرمختګ ته اړتیا لري، که څه هم یو بلاک تولید شوی وي یا نه، پرمخ ځي. د سلټ N څخه N+1 ته پرمختګ کوي درې شیان پیښیږي. لومړی، د سلټ N د حالت ریښه تازه کیږي ترڅو هغه څه وساتي چې په هغه سلټ کې وو. دوهم، وروستی بلاک سرلیک چې د وروستي پروسس شوي بلاک سرلیک ذخیره کوي هم تازه کیږي، په یاد ولرئ دا ساحه د ډیپلیکیټ بلاکونو مخنیوي لپاره کارول کیږي. همدا رنګه د هغه بشپړ شوي سرلیک ریښه د بلاک ریښې ته لیکل کیږي. په پای کې، د سلټ کاونټر په یو زیاتیږي. تاسو شاید حیران یاست چې د حالت سره څه پیښیږي کله چې یو وړاندیز کونکی خپل سلټ له لاسه ورکړي. ښه، ټول حالت لاهم تازه کیږي، د مثال په توګه د دې سلټ بلاک ریښې به د وروستي بلاک سرلیک ریښه ولري ځکه چې هیڅ نوی بلاک نه دی راغلی ترڅو دا بدل کړي. د سلټ له زیاتیدو وروسته، چینل چک کوي که دا یوازې د epoch سرحد څخه تیریږي، دا د slot mod 32 == 0 په واسطه په اسانۍ سره کیدی شي، که داسې وي، د epoch پروسس کول د هرڅه دمخه پیل کیږي. نو په تخنیکي توګه، د هر 32 سلټونو لپاره، د epoch پروسس کول د سلټ پروسس کول سره یوځای پرمخ ځي، په بل عبارت، د epoch پروسس کول د سلټ له پرمختګ وروسته مګر د هغه سلټ لپاره د بلاک له پروسس کولو دمخه پرمخ ځي. یو وروستی حقیقت چې یادونه یې وکړو، کله چې موږ په هغه نقطه کې یو چېرې د حالت ریښې او د بلاک ریښې سرې ډکې وي، دا دی، په slot mod 8192 == 0 موقعیت کې، مخکې لدې چې دواړه سرې د نوي ډاټا لخوا بیا لیکل کیدل پیل کړي ځکه چې دا د حلقوي په څیر ښکاري، چینل دا دوه ساحې سره هش کوي، او دا په تاریخي حالت کې ضمیمه کوي. د بلاک پروسس کول د بلاک پروسس کول هغه وخت پرمخ ځي کله چې یو بلاک واقعیا د سلټ لپاره وړاندې کیږي. د سلټ پروسس کولو وروسته چې حالت سم سلټ ته پرمختللی، د بلاک پروسس کول لاسلیک شوی بلاک اخلي او د هغه مینځپانګه په حالت باندې تطبیقوي. دا دوه اصلي برخې لري، دا دي، د بلاک سرلیک تایید کول او د بلاک بدن پروسس کول. د هرڅه دمخه، چینل یو څو شیان چک کوي لکه ایا د بلاک سرلیک د اوسني حالت سلټ سره مطابقت لري، او ایا د بلاک وړاندیز کونکي شاخص واقعیا هغه تصدیق کونکی دی چې randao غوره کړی. په پای کې، دا چک کوي چې ایا د بلاک والد ریښه د وروستي بلاک سرلیک ریښې سره مطابقت لري، که تایید شي، د بلاک سرلیک په حالت کې وروستی بلاک سرلیک په توګه زیرمه کیږي. بیا، وړاندیز کونکی باید یو randao reveal شامل کړي، کوم چې لکه څنګه چې ما دمخه وویل، اساسا دvalidator لخوا لاسلیک شوی د اوسني epoch شمیره ده. چینل دا لاسلیک د وړاندیز کونکي عام کیلي په مقابل کې تاییدوي. دا اسانه ده چې ووایو دا اوسنی طریقه تغیر نه منونکې ده، دا چې validator لاسلیک به تل د ورته epoch شمیرې لپاره یو شان وي، ریښتیا، په حقیقت کې د دې کولو ټول هدف دا دی چې هر چا ته اجازه ورکړي چې د validator عام کیلي وکاروي ترڅو د epoch شمیره چې validator واقعیا لاسلیک کړی، وکاروي. یادونه وکړئ چې یو وړاندیز کونکی نشي کولی د randao reveal څخه تیښته وکړي، که دوی بلاک وړاندې کړي، دوی باید دا شامل کړي، د پروسې څخه د تیښتې یوازینی لاره دا ده چې په لومړي ځای کې بلاک وړاندې نه کړي. له هغې وروسته، وړاندیز کونکی به د Eth1 چین زیرمو قرارداد حالت خپله لید د Eth1 ډاټا رایې په توګه هم شامل کړي. که چیرې په رایو لیست کې کوم Eth1 ډاټا ارزښت اکثریت ته ورسیږي، دا په حالت کې نوی Eth1 ډاټا کیږي. د بلاک پروسس کولو په جریان کې، د وړاندیز کونکي سلیشینګ ساحه شواهد لري چې یو تصدیق کونکی د ورته سلټ لپاره دوه مختلف بلاک سرلیکونه لاسلیک کوي، چینل دواړه لاسلیکونه تاییدوي، او که معتبر وي، دوی سلیش کوي د دوی د سلیش شوي فلګ په true بدلولو سره، او د دوی اغیزمن توازن د سلیشینګ سرې ته اضافه کوي. همدا رنګه، د اتسترز لپاره، که کوم متضاد اتست وي، چینل دا تاییدوي، او د دوی له لاسلیک څخه مجرم تصدیق کونکي پیژني، او بیا هغه تصدیق کونکي سلیش کوي، په ورته لاره او پروسه لکه د بلاک وړاندیز کونکي سلیش. په بلاک کې نوي تاییدونه تایید کیږي، تایید په یو راټول شوي تایید بدل کیږي د دوه نوي فیلډونو اضافه کولو سره، دا دي، د شاملولو ځنډ او د وړاندیز کونکي شاخص، او بیا، دوی یا د اوسني epoch تایید یا د تیر epoch تایید ته ضمیمه کیږي. له دې وروسته چې دوی اضافه شوي هیڅ شی ډیر نه دی ځکه چې دوی سمدلاسه په حالت اغیزه نه کوي، دوی هلته ناست دي تر هغه چې د epoch پروسس کول یې ارزوي. د Eth1 زیرمو قرارداد څخه د نوي تصدیق کونکو زیرمه پروسس کیږي، بلاک باید ټول راټول شوي زیرمې تر اعظمي زیرمو 16 پورې شامل کړي. چینل د زیرمو ریښې په وړاندې د هر زیرمو میرکل ثبوت تاییدوي ترڅو ډاډمن شي چې دا سم دی. که د زیرمه کونکي عام کیلي نوي وي، یو نوی تصدیق کونکی ننوتنه اضافه کیږي، همدارنګه اړوند توازن. یو تصدیق کونکی کولی شي سیګنال کړي چې دوی غواړي د لاسلیک شوي داوطلبانه وتلو په سپارلو سره پریږدي. چینل چک کوي چې تصدیق کونکی لږترلږه 256 epoch فعال و، او دا چې اوسنی epoch لږترلږه وتلو epoch دی چې مشخص شوی دی. که هرڅه سم وي، د تصدیق کونکي د وتلو epoch او د وتلو وړ epoch ټاکل کیږي. له دې وروسته چې پورته هرڅه پروسس شي، یو وروستی مګر مهم ټکی شتون لري، دا دی، د نورو نوډونو لخوا محاسبه شوي د حالت ریښه د بلاک کې شامل شوي د حالت ریښې سره پرتله کیږي. که دوی سمون ونه لري، ټول بلاک رد کیږي. د Epoch پروسس کول د Epoch پروسس کول د epoch په سرحد کې پیل کیږي چې هر 'slot mod 32 = 0' ګام دی. دا د سلټ پروسس کولو په جریان کې پرمخ ځي کله چې د سلټ کاونټر نوي epoch ته تیریږي. دا ترټولو پیچلې مرحله ده ځکه چې ډیری په زړه پورې موافقت شیان دلته پیښیږي. لومړی، توجیه او پایښت پیل کیږي، دا هغه ځای دی چې Casper FFG خپل کار کوي، پروسه ممکن پیچلې ښکاري مګر دا خورا اسانه ده، په ساده ډول، چینل د تیر epoch څخه تاییدونه ګوري او د تصدیق کونکو اغیزمن توازن حسابوي چې د سم هدف سره یې تایید کړی. که دا مجموعه د ټول فعال توازن له 2/3 څخه زیاته وي، د هدف epoch توجیه کیږي، او که دوه پرله پسې epochs توجیه شي، لومړی پایښت ته ځي. اسانه! یو حقیقت چې ما د بلاک پروسس کولو مرحلې کې نه دی یاد کړی، دا دی چې د هر مرحلې لپاره، تصدیق کونکي انعامونه راټیټوي، دوی د اتست یا د سلیشینګ شواهدو اضافه کولو لپاره انعام ترلاسه کوي، یا حتی نورمال اساس انعام. دا راټول شوي انعامونه د چین لخوا د تیرو epoch په جریان کې د epoch پروسس کولو مرحله کې ارزول کیږي، او د دوی توازن په مناسب ډول تنظیم کوي. که چینل له څلورو epochs څخه ډیر وخت پایښت نه وي، هغه څه چې "غیر فعالیت لیک" په توګه تشریح کیږي پیل کیږي. د اتست له لاسه ورکولو لپاره د عادي جریمو سربیره، غیر حاضر تصدیق کونکي د وروستي پایښت شوي epoch راهیسې د هر epoch سره په چوکات ډول وده کوي. په بل عبارت، څومره چې د بلاک پایښت کولو لپاره ډیر وخت ونیسي، ستاسو جریمه ډیره درنه وي. تاسو شاید حیران یاست چې د دې کولو څه هدف دی. اوس، کله چې یو بلاک د یو څه وخت لپاره پایښت نه وي، دا پدې معنی ده چې په هغه بلاک کې اکثریت رایه نشته، او له هغه وخته چې د پایښت لپاره رایه ورکول د تصدیق کونکي اغیزمن توازن له وزن لخوا اندازه کیږي، اساسا څومره ETH تصدیق کونکی لري، د دوی اغیزمن توازن کمول د
