Secara argumentatif, peristiwa terpenting dalam sejarah Ethereum, The Merge, terjadi pada 15 September 2022. Ini menandai transisi jaringan dari ke , yang secara fundamental mengubah cara Ethereum mencapai konsensus. Tapi mengapa disebut ‘ ’ dan bukan ‘transisi’? Proof of Work Proof of Stake The Merge Sebelum The Merge, Ethereum mengoperasikan konsensus Proof of Work, sebuah mekanisme yang mengharuskan ‘penambang’ untuk memecahkan teka-teki kriptografi yang kompleks, untuk memvalidasi transaksi, dan membuat blok baru. PoW memang keren, tetapi memiliki banyak keterbatasan, seperti penggunaan daya komputasi yang sangat besar yang menyebabkan penggunaan listrik yang tinggi dan kekhawatiran lingkungan, throughput transaksi yang rendah karena waktu verifikasinya yang lebih lambat, sehingga menjadi tantangan bagi adopsi institusional, kemungkinan risiko sentralisasi yang lebih tinggi, karena dapat berkonsolidasi ke beberapa entitas penambangan yang kuat, dll. Alasan-alasan ini dan alasan lainnya adalah motivasi yang mendorong Ethereum Foundation, hanya tiga tahun setelah didirikan, untuk mulai membangun Konsensus baru yang disebut Proof of Stake, yang dirancang untuk memecahkan sebagian besar masalah yang menantang PoW. Pada tanggal 1 Desember 2020, Ethereum meluncurkan versi PoS pertamanya, sebuah rantai baru yang disebut Beacon chain. Beacon Chain tidak memproses transaksi pengguna. Tujuannya hanya untuk mengoordinasikan validator dan mencapai konsensus menggunakan mekanisme baru yang disebut Gasper. Transaksi masih diproses di rantai Proof of Work utama, sehingga kedua rantai, rantai utama Ethereum dan Beacon chain, berjalan secara paralel. Selama hampir dua tahun, kedua rantai ini beroperasi secara independen. Kemudian, pada 15 September 2022, rantai asli melepaskan konsensus berbasis penambangannya dan terhubung langsung ke Beacon Chain. Dengan demikian, dua rantai menjadi satu. Itulah mengapa disebut The Merge, bukan transisi. Saat ini, Ethereum beroperasi sebagai blockchain dua lapis. Lapisan konsensus, yang dulunya adalah Beacon Chain, menangani proposal blok, attestations, dan finalitas. Lapisan eksekusi, rantai Ethereum asli, menangani pemrosesan transaksi. Anda mungkin pernah mendengar ini disebut sebagai Eth2 dan Eth1, masing-masing, tetapi Ethereum Foundation telah menghentikan penamaan tersebut karena menyiratkan dua jaringan terpisah daripada dua lapisan dari satu sistem. Artikel ini berfokus pada lapisan konsensus. Khususnya, bagaimana Beacon Chain beroperasi sebagai mesin status. Apa itu BeaconState? Untuk memahami bagaimana transisi mesin status terjadi, kita perlu memahami terlebih dahulu apa saja yang sebenarnya terkandung dalam status pada saat genesis rantai. Status Beacon Chain direpresentasikan oleh satu objek yang disebut BeaconState. Objek ini berisi semua yang dibutuhkan lapisan konsensus untuk berfungsi. Kadang-kadang disebut sebagai “objek Dewa”. Spesifikasi itu sendiri mengelompokkan bidang-bidang berdasarkan tujuan, yang merupakan cara paling jelas untuk menjelajahi semuanya. 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 Versioning: genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork Empat variabel pertama menjawab pertanyaan “rantai mana kita, dan di mana kita dalam rantai itu?”. Bidang-bidang ini mengikat identitas rantai dan memberi tahu setiap node aturan protokol mana yang harus diikuti. Waktu genesis adalah stempel waktu Unix yang ditetapkan di awal rantai, dan tidak pernah berubah. Stempel waktu genesis Beacon chain adalah 1606824023, yang persis pada 1 Desember 2020, pukul 12:00:23 siang UTC. Jika Anda pernah menanyakan ‘block.timestamp’ dari kontrak pintar, nilai itu dihitung dari bidang ini. Akar Validator Genesis, sama seperti stempel waktu, juga ditambahkan di awal rantai. Ini pada dasarnya bertindak sebagai pemisah domain; ini bercampur dengan tanda tangan validator selama proposal blok dan attestations untuk membedakan Ethereum mainnet dari rantai lainnya. Slot hanyalah sebuah penghitung yang memberi tahu kita di mana posisi rantai dalam waktu. Ini bertambah setiap 12 detik, terlepas dari apakah blok diproduksi atau tidak. Sementara Fork adalah objek yang berisi tiga bidang, yaitu versi rantai sebelumnya, versi rantai saat ini, dan epoch. Ketika peningkatan pertama pada beacon chain terjadi pada 27 Oktober 2021, versinya beralih dari Fase 0 ke Altair. Versi saat ini, pada saat penulisan artikel ini, adalah Fulu, dan versi sebelumnya adalah Electra. Sama seperti akar validator, hash versi ditambahkan ke tanda tangan untuk membedakan satu versi fork dari yang lain. Epoch, di sisi lain, adalah kumpulan 32 slot, yaitu , sekitar 6,4 menit. Di sinilah pemeriksaan finalitas, denda slashing, antrean keluar, dan semua hal keren lainnya yang spesifik untuk konsensus terjadi. Di sinilah Casper FFG, bagian terakhir dari Gasper, beroperasi. 12 detik x 32 Sejarah 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] Bagian ini menjawab pertanyaan, “Apa yang telah terjadi di rantai ini?”. Variabel-variabel ini memberikan rantai memori ringkas tentang masa lalunya sendiri, memungkinkan validator untuk merujuk dan memverifikasi status sebelumnya tanpa menyimpan semuanya. Header blok terbaru menyimpan header dari blok yang terakhir diproses. Ini digunakan untuk mencegah blok duplikat karena, sebelum memproses blok baru, rantai memeriksa bahwa akar induk blok cocok dengan akar header blok terbaru. Kedua bidang block roots dan state roots adalah daftar yang menyimpan akar blok dan akar status sebelumnya, masing-masing sampai penuh. Di setiap slot, akar ditulis ke array masing-masing pada indeks . Ini memungkinkan rantai untuk mencari tahu bagaimana statusnya terlihat pada slot terbaru mana pun dalam jendela waktu 27 jam. Akar Historis menambahkan hash gabungan dari array akar blok dan akar status ketika keduanya terisi. Daftar ini tidak terbatas, tetapi tumbuh lambat, hanya dengan satu entri setiap 27 jam. slot%8192 Eth1 eth1_data: Eth1Data eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH] eth1_deposit_index: uint64 Sebelum the merge, Eth2 (Beacon chain) perlu melacak apa yang terjadi di Eth1 (rantai PoW), khususnya transaksi deposit di mana validator baru mengunci 32 ETH. Anda mungkin bertanya-tanya mengapa 32 ETH yang dimaksudkan untuk PoS dikunci di rantai PoW alih-alih Beacon chain. Jawabannya sederhana karena Beacon chain itu sendiri tidak memiliki kemampuan transfer token atau pemrosesan transaksi, karena tidak dapat menangani deposit token secara native. Data Eth1 berisi tiga sub-bidang, yaitu, , yang merupakan akar merkle dari pohon deposit kontrak deposit, jumlah total deposit yang dibuat ke kontrak, dan hash dari blok eth1 yang dirujuk. deposit root deposit count, block hash, Beacon Chain tidak bisa hanya mempercayai pandangan satu validator tentang rantai Eth1 karena validator yang berbeda mungkin melihat keadaan yang berbeda karena penundaan jaringan, jadi ia menggunakan mekanisme pemungutan suara yang memungkinkan penambah blok menyertakan pandangan mereka tentang data Eth1 saat ini dalam blok mereka. Suara-suara itu terakumulasi dalam daftar ini selama periode pemungutan suara, dan jika ada nilai yang mendapatkan lebih dari setengah suara selama periode tersebut, itu menjadi data Eth1 baru. Di akhir periode pemungutan suara, daftar dikosongkan dan pemungutan suara dimulai lagi. Indeks Deposit Eth melacak berapa banyak deposit dari kontrak deposit yang telah diproses sejauh ini. Ketika rantai memproses blok baru, ia memeriksa apakah ada deposit yang belum diproses dengan membandingkan indeks ini dengan bidang jumlah deposit di data Eth1. Jika jumlah deposit lebih tinggi, blok harus menyertakan deposit berikutnya hingga jumlah deposit maksimum per blok, yaitu 16 pada saat itu. Registri validators: List[Validator, VALIDATOR_REGISTRY_LIMIT] balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT] Variabel ini pada dasarnya menyimpan daftar siapa yang berpartisipasi dalam konsensus, dan berapa banyak taruhan yang mereka miliki. Satu fakta menarik tentang bidang validator adalah bahwa bidang itu hanya bertambah dan tidak pernah berkurang, bahkan setelah validator menarik diri, entri mereka tetap ada dalam daftar. Saat ini, ada 2.210.484 entri, dan hanya 962.941 yang aktif. Bidang Validator memiliki delapan sub-bidang, yaitu, , yang pada dasarnya adalah kunci publik validator, , ke mana taruhan mereka pergi ketika mereka menarik diri, saldo mereka dibulatkan ke bawah ke gwei terdekat yang digunakan untuk menghitung hadiah dan penalti, dan itu hanya diperbarui di batas epoch dengan hysteresis untuk mencegahnya berkedip naik dan turun. s , flag boolean yang digunakan untuk menunjukkan apakah validator telah di-slashed. a , nomor epoch ketika validator memenuhi syarat untuk diaktifkan. epoch ketika mereka diaktifkan. , epoch ketika mereka pergi, dan akhirnya , epoch ketika saldo mereka dapat ditarik. pubKey withdrawable credentials effective balance, lashed ctivation eligibility epoch activation epoch, exit epoch withdrawable epoch Untuk menunjukkan mengapa kita memiliki bidang saldo efektif dalam daftar validator, dan bidang saldo secara langsung di status beacon adalah bahwa bidang saldo efektif tidak diperbarui saat saldo aktual Anda diperbarui, ada buffer untuk mencegahnya bolak-balik. Tanpa hysteresis, validator yang mendekati 32 ETH katakanlah berfluktuasi antara 31,99 dan 32,01 setiap epoch karena hadiah dan penalti akan membuat saldo efektifnya berkedip antara 31 dan 32 setiap epoch. Itu berarti melakukan re-Merkleizing objek validator terus-menerus dan mengubah bobotnya dalam perhitungan komite di setiap epoch. Keacakan randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] randao_mixes adalah daftar berukuran tetap 65.536 (sekitar 2 pangkat 16) entri. Setiap kali validator mengusulkan blok, mereka menambahkan apa yang kita sebut ‘randao reveal’ ke daftar. Pengungkapan ini pada dasarnya adalah nomor epoch saat ini yang ditandatangani oleh validator. Setelah menandatangani, rantai mengambilnya, dan XOR-kan dengan campuran terakhir untuk epoch saat ini, yang menghasilkan campuran baru. Semua penambah dalam sebuah epoch melakukan hal yang sama untuk mendapatkan campuran terakumulasi akhir untuk epoch berikutnya. Campuran randao digunakan untuk menentukan komite dan penambah blok untuk epoch berikutnya. Komite, yang merupakan semua validator aktif dibagi menjadi 32 slot, ditentukan oleh algoritma shuffle ‘swap-or-not’. Algoritma ini pada dasarnya hanya menukar indeks validator secara acak dengan campuran. Untuk pemilihan penambah blok, rantai menghash campuran randao untuk membentuk seed. Kemudian ia mengiterasi semua validator aktif mulai dari offset acak yang diturunkan dari seed itu. Untuk setiap kandidat, ia memeriksa apakah hash dari seed dan indeks validator, dibagi dengan saldo efektif validator, melewati ambang batas. Jika ya, validator menjadi penambah, jika tidak, ia melewati ke yang berikutnya. Dalam praktiknya, ia menemukannya dengan cepat karena sebagian besar validator aktif memiliki saldo 32 ETH. Slashings slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] Validator di-slashed karena dua alasan, yaitu, mengusulkan dua blok berbeda untuk slot yang sama mencoba membuat fork, atau, membuat attestations yang bertentangan. Bidang slashing adalah daftar tetap 8192 entri, satu per epoch. Ini berisi jumlah total saldo efektif validator yang di-slashed. Bidang ini digunakan untuk menghitung jumlah penalti. Attestations previous_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] current_epoch_attestations: List[PendingAttestation, MAX_ATTESTATIONS * SLOTS_PER_EPOCH] Setiap validator aktif melakukan attestasi sekali per epoch, dan attestations ini yang mendorong aturan pilihan fork (LMD-GHOST) dan mekanisme finalitas (Casper FFG). Sebuah attestasi berisi enam sub-bidang, yaitu, yang di-attest oleh validator, adalah blok yang dianggap validator sebagai kepala rantai, ini dianggap sebagai suara LMD-GHOST oleh validator yang digunakan untuk menentukan pilihan fork. adalah checkpoint epoch yang diyakini validator telah dijustifikasi, dan adalah epoch saat ini yang di-attest oleh validator, keduanya bersama-sama membentuk suara Casper FFG yang digunakan dalam finalitas. Sederhananya, validator menegaskan bahwa epoch sumber harus difinalisasi, dan epoch target harus dijustifikasi. menunjukkan validator mana dalam komite yang telah melakukan attestasi. Karena lebih murah untuk menggabungkan sesuatu sebagai bit dalam byte, bit agregasi disimpan dalam bidang bit untuk efisiensi memori. Terakhir, kita memiliki dari validator atas data attestasi. slot beacon block root source target aggregation bits signature Finalitas justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint Finalitas berarti blok dan semua transaksinya tidak pernah dapat dibatalkan. Di Beacon Chain, finalitas adalah mutlak. Setelah epoch difinalisasi, satu-satunya cara untuk memulihkannya adalah jika 1/3 dari total ETH yang di-stake di-slashed, yang akan menghabiskan biaya miliaran dolar. Justification bits adalah vektor bit sepanjang 4, pada dasarnya hanya melacak apakah empat epoch terakhir dijustifikasi. Checkpoint yang dijustifikasi sebelumnya adalah checkpoint yang dijustifikasi pada epoch sebelumnya. Current Justified Checkpoint adalah checkpoint yang paling baru dijustifikasi, sedangkan Finalized Checkpoint adalah checkpoint yang paling baru difinalisasi. Sebuah epoch menjadi dijustifikasi ketika 2/3 dari total taruhan aktif melakukan attestasi pada tautan mayoritas super yang menunjuk ke epoch itu sebagai target. Finalitas terjadi ketika Anda mendapatkan dua checkpoint yang dijustifikasi berturut-turut. Saat yang kedua dijustifikasi, yang pertama ditingkatkan menjadi final, meskipun ada beberapa nuansa tambahan. Mesin Status Sekarang kita tahu apa saja yang terkandung dalam status, kita bisa melihat bagaimana status tersebut berubah. Setiap 12 detik, slot baru tiba. Jika blok diusulkan, fungsi transisi status mengambil status saat ini dan blok tersebut, menjalankan validasi, pembaruan, dan menghasilkan status baru. Proses ini dibagi menjadi tiga tahap oleh spesifikasi: pemrosesan slot, pemrosesan blok, dan pemrosesan epoch. Pemrosesan Slot Pemrosesan Slot berjalan setiap kali rantai perlu maju dari satu slot ke slot berikutnya, baik blok diproduksi atau tidak. Tiga hal terjadi ketika slot maju dari N ke N+1. Pertama, akar status untuk slot N diperbarui untuk menyimpan catatan tentang bagaimana slot itu terlihat pada slot tersebut. Kedua, header blok terbaru yang menyimpan header dari blok yang terakhir diproses juga diperbarui, ingat bidang ini digunakan untuk mencegah blok duplikat. Juga akar dari header yang selesai itu ditulis ke akar blok. Terakhir, penghitung slot bertambah satu. Anda mungkin bertanya-tanya apa yang terjadi pada status ketika penambah melewatkan slotnya. Nah, semua status tetap diperbarui, misalnya, akar blok dari slot itu akan berisi akar dari header blok terbaru yang sama karena tidak ada blok baru yang datang untuk menggantikannya. Setelah menaikkan slot, rantai memeriksa apakah ia baru saja melintasi batas epoch, dapat dengan mudah dilakukan dengan slot mod 32 == 0, Jika ya, pemrosesan epoch dimulai sebelum hal lain terjadi. Jadi secara teknis, untuk setiap 32 slot, pemrosesan epoch berjalan bersamaan dengan pemrosesan slot, dengan kata lain, pemrosesan epoch berjalan setelah slot maju tetapi sebelum blok untuk slot itu diproses. Satu fakta terakhir untuk dicatat, ketika kita berada pada titik di mana array state roots dan block roots terisi, yaitu, pada posisi slot mod 8192 == 0, sebelum kedua array mulai ditimpa oleh data baru karena tampaknya sirkular, rantai menggabungkan kedua bidang tersebut, dan menambahkannya ke status historis. Pemrosesan Blok Pemrosesan blok berjalan ketika blok benar-benar diusulkan untuk suatu slot. Setelah pemrosesan slot memajukan status ke slot yang benar, pemrosesan blok mengambil blok yang ditandatangani dan menerapkan isinya ke status. Ini memiliki dua bagian utama, yaitu, memvalidasi header blok dan memproses badan blok. Sebelum hal lain, rantai memeriksa beberapa hal seperti apakah header blok cocok dengan slot status saat ini, dan apakah indeks penambah blok sebenarnya adalah validator yang dipilih oleh randao. Terakhir, ia memeriksa apakah akar induk blok cocok dengan akar header blok terbaru, jika divalidasi, header blok disimpan sebagai header blok terbaru dalam status. Selanjutnya, penambah harus menyertakan pengungkapan randao, yang seperti yang saya katakan sebelumnya, pada dasarnya adalah nomor epoch saat ini yang ditandatangani oleh validator. Rantai memverifikasi tanda tangan terhadap kunci publik penambah. Mudah untuk mengatakan bahwa metode saat ini bersifat deterministik, bahwa tanda tangan validator akan selalu sama untuk nomor epoch yang sama, benar, sebenarnya inti dari melakukan ini dengan cara ini adalah untuk memungkinkan siapa pun menggunakan kunci publik validator untuk memeriksa nomor epoch yang sebenarnya ditandatangani oleh validator. Perhatikan bahwa penambah tidak dapat melewati pengungkapan randao, jika mereka mengusulkan blok, mereka harus menyertakannya, satu-satunya cara untuk melewati proses ini adalah dengan tidak mengusulkan blok sejak awal. Setelah itu, penambah juga akan menyertakan pandangannya tentang status kontrak deposit rantai Eth1 sebagai suara data Eth1. Jika ada nilai data Eth1 dalam daftar suara mencapai mayoritas, itu menjadi data Eth1 baru dalam status. Selama pemrosesan blok, bidang penambah slashing berisi bukti bahwa validator menandatangani dua header blok yang berbeda untuk slot yang sama, rantai memverifikasi kedua tanda tangan, dan jika valid, ia melakukan slashing mereka dengan pertama-tama mengatur flag slashed mereka menjadi true, dan menambahkan saldo efektif mereka ke array slashings. Juga, untuk attestor, jika ada attestasi yang bertentangan, rantai memverifikasinya, dan mengidentifikasi validator yang bersalah melalui tanda tangan mereka, dan kemudian melakukan slashing validator tersebut, dengan cara dan proses yang sama seperti slashing penambah blok. Attestasi baru dalam blok divalidasi, attestasi dikonversi menjadi attestasi yang tertunda dengan menambahkan dua bidang baru, yaitu, inclusion delay dan indeks penambah, dan kemudian, mereka ditambahkan ke attestasi epoch saat ini atau attestasi epoch sebelumnya. Tidak banyak setelah ditambahkan karena tidak memengaruhi status segera, mereka tetap di sana sampai pemrosesan epoch mengevaluasinya. Deposit validator baru dari kontrak deposit Eth1 diproses, blok harus menyertakan semua deposit yang tertunda hingga maksimum 16 deposit. Rantai memverifikasi bukti merkle setiap deposit terhadap akar deposit untuk memastikan kebenarannya. Jika kunci publik depositor baru, entri validator baru ditambahkan, serta saldo yang sesuai. Validator dapat memberi sinyal bahwa mereka ingin keluar dengan mengirimkan keluar sukarela yang ditandatangani. Rantai memeriksa bahwa validator telah aktif setidaknya selama 256 epoch, dan bahwa epoch saat ini setidaknya adalah epoch keluar yang ditentukan. Jika semuanya berjalan lancar, epoch keluar dan epoch yang dapat ditarik dari validator diatur. Setelah semua di atas diproses, ada satu bagian terakhir tetapi penting, yaitu, akar status yang dihitung oleh node lain dibandingkan dengan akar status yang termasuk dalam blok. Jika tidak cocok, seluruh blok ditolak. Pemrosesan Epoch Pemrosesan epoch dipicu pada batas epoch yaitu setiap langkah ‘slot mod 32 = 0’. Ini berjalan selama pemrosesan slot ketika penghitung slot melintasi ke epoch baru. ini adalah tahap yang paling kompleks karena sebagian besar hal keren tentang konsensus terjadi di sini. Pertama, justifikasi dan finalitas dimulai, di sinilah Casper FFG bekerja, prosesnya mungkin terdengar rumit tetapi sangat mudah, sederhananya, rantai melihat attestations dari epoch sebelumnya dan menghitung saldo efektif validator yang melakukan attestasi dengan target yang benar. Jika jumlah itu setidaknya 2/3 dari total saldo aktif, epoch target menjadi dijustifikasi, dan jika dua epoch berturut-turut dijustifikasi, yang lebih awal menjadi final. Mudah! Satu fakta yang tidak saya sebutkan pada tahap pemrosesan blok, adalah bahwa untuk setiap tahap, validator mengumpulkan hadiah, mereka diberi hadiah karena menyertakan attestasi atau karena menambahkan bukti slashing, atau bahkan hadiah dasar biasa. Hadiah terakumulasi ini dievaluasi oleh rantai selama epoch sebelumnya dalam tahap pemrosesan epoch, dan saldo mereka disesuaikan. Jika rantai belum final dalam lebih dari empat epoch, apa yang digambarkan sebagai “kebocoran ketidakaktifan” terjadi. Selain penalti normal karena melewatkan attestations, validator yang tidak berpartisipasi akan dikenakan penalti ketidakaktifan tambahan yang tumbuh secara kuadratik dengan setiap epoch sejak epoch terakhir yang difinalisasi. Dengan kata lain, semakin lama blok membutuhkan waktu untuk final, semakin keras penalti Anda. Anda mungkin bertanya-tanya apa gunanya melakukan ini. Nah, ketika sebuah blok belum difinalisasi untuk sementara waktu, itu berarti tidak ada suara mayoritas pada blok itu, dan karena pemungutan suara untuk finalitas diukur dengan bobot saldo efektif validator, pada dasarnya berapa banyak ETH yang dimiliki validator, pengurangan jumlah saldo efektif mereka mengurangi kekuatan voting mereka. Dengan demikian, Ethereum menggunakannya sebagai cara untuk memaksa finalitas blok. Perlu dicatat bahwa selama kebocoran ketidakaktifan, bahkan attestor yang benar pun tidak menerima hadiah. Semuanya beralih ke mode penalti murni untuk mempercepat penyeimbangan kembali. Peristiwa penting lainnya yang terjadi pada tahap ini adalah aktivasi validator, yang epoch kelayakan aktivasinya telah tercapai. Juga, validator yang epoch keluarnya telah tiba, dipindahkan dari kumpulan validator aktif. Selanjutnya, ingat bahwa saldo efektif tidak diperbarui di setiap slot dan epoch, karena hysteresis berlaku. Ini hanya diperbarui jika saldo aktual telah naik cukup tinggi di atas ambang batas naik saldo efektif saat ini, saldo efektif meningkat sebesar 1 ETH, dan jika turun di bawah ambang batas turun, itu berkurang sebesar 1 ETH. Terakhir, campuran randao epoch saat ini disalin ke slot epoch berikutnya. Seperti yang dapat Anda lihat dengan jelas, pemrosesan epoch adalah bagian paling rumit dari mesin status, dan tidak ramah komputasi, sehingga selalu mengarah pada banyak pekerjaan optimasi bagi para insinyur yang membangun klien rantai. Dari Fase 0 ke Fulu BeaconState yang telah kita jelajahi sejauh ini adalah versi Fase 0, yang asli. Tetapi Beacon Chain adalah sistem yang hidup. Setiap fork lapisan konsensus telah memodifikasi BeaconState, baik dengan menambahkan bidang baru, menghapus yang lama, atau hanya mengubah cara beberapa yang ada beroperasi. Misalnya, dalam fork Altair, daftar attestasi epoch sebelumnya dan saat ini dihapus sepenuhnya untuk digantikan oleh epoch sebelumnya dan saat ini, perbedaannya adalah bahwa, sementara yang sebelumnya menyimpan objek attestasi penuh, jenis partisipasi baru hanya menyimpannya dalam bentuk bit. Sekarang, setiap validator hanya mendapatkan tiga bit per epoch yang mewakili apakah mereka mendapatkan sumber dengan benar, target dengan benar, dan kepala dengan benar. Ini menyebabkan pengurangan drastis dalam ukuran memori. Bellatrix, fork the merge, memperkenalkan bidang execution payload ke beaconState, bidang ini digunakan untuk menghubungkan lapisan konsensus dan lapisan eksekusi. Bidang Eth1 dipertahankan tetapi perannya berkurang karena tidak lagi diperlukan. partisipasi Fork Capella memperkenalkan kemampuan penarikan untuk validator, ia mencatatnya dengan menambahkan bidang baru yang disebut indeks penarikan berikutnya ke beaconState. Akar historis digantikan oleh ringkasan historis yang menyimpan akar blok dan akar status dalam sebuah struct alih-alih menggabungkannya. Fork Deneb, di sisi lain, hampir tidak berdampak pada beaconState, karena fork tersebut terutama berkaitan dengan blob. Di Electra dan Fulu, perubahan kuncinya adalah menaikkan saldo efektif maksimum dari 32 ETH menjadi 2048 ETH, ini menyebabkan pengenalan bidang baru di beaconState. Setiap fork dibangun di atas yang sebelumnya, dan BeaconState tumbuh dari 21 bidang di Fase 0 menjadi lebih dari 30 di Fulu. Satu hal yang konsisten, Dari Fase 0 ke Fulu, statusnya telah tumbuh, fork menambahkan bidang, fork menghapus bidang, tetapi arsitekturnya tetap sama. Kesimpulan Beacon Chain sering digambarkan sebagai kompleks, ya saya setuju, karena memang kompleks. Tetapi pada intinya, itu pada dasarnya adalah siklus, sebuah status ada, sebuah input tiba, status yang ada diperbarui untuk menghasilkan status baru, lalu ulangi! Sederhana! Yang membuat beacon chain benar-benar luar biasa bukanlah satu bidang pun, tetapi bagaimana semua itu terhubung untuk memberi kita ‘tek’ yang luar biasa ini, yang kita miliki hari ini! Referensi Spesifikasi Konsensus Ethereum (Fase 0) Spesifikasi Anotasi Ethereum oleh Ben Edgington eth2book.info Gasper: Menggabungkan GHOST dan Casper (Makalah Asli) Casper the Friendly Finality Gadget (Makalah Asli) Implementasi Klien Lighthouse Penjelajah Beacon Chain Ethereum Blog Ethereum Foundation tentang The Merge Spesifikasi Anotasi Ethereum oleh Vitalik Buterin
