Lompat ke konten
Financial Context Wiki

Aturan fork choice: cabang valid, bobot, dan head kanonis

Aturan fork choice memetakan pandangan lokal tervalidasi milik node ke head kanonis saat ini. Validitas kandidat, garis keturunan, kerja atau bobot suara, checkpoint, waktu, tie-break, dampak reorganisasi, dan finalitas harus dianalisis terpisah.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Aturan fork choice adalah prosedur protokol yang memetakan pandangan lokal tervalidasi milik sebuah node atas blok dan pesan konsensus yang bersaing ke head kanonis saat ini. Hasilnya bersifat sementara dan relatif terhadap pengamat: dua node jujur dapat memilih head berbeda untuk sesaat karena menerima blok, suara, atau peristiwa waktu valid yang berbeda. Setelah pandangan yang dapat diterima menyatu dalam asumsi jaringan protokol, aturan tersebut juga diharapkan menyatu.

Fork choice tidak membuat blok invalid menjadi valid. Pemeriksaan transisi state, otorisasi, bukti, garis keturunan, dan ketersediaan data menentukan kandidat yang dapat diterima sebelum bobotnya dibandingkan. Head terpilih juga belum tentu final. Fork choice menentukan cabang yang perlu diperpanjang sekarang; aturan finalitas dapat melindungi leluhur yang lebih lama dengan bukti keamanan lebih kuat. Mengganti head saat ini dapat menjadi operasi biasa, sedangkan mengganti checkpoint final akan melintasi batas protokol yang berbeda.

“Rantai terpanjang” bukan rumus universal. Bitcoin memilih rantai valid dengan kerja terbesar: bukti kerja harapan kumulatif, bukan tinggi mentah, yang menentukan. LMD-GHOST Ethereum dimulai dari checkpoint justified, menyaring cabang yang layak, lalu secara greedy mengikuti anak dengan saldo attestasi pesan terbaru terbesar ditambah proposer boost yang berlaku; hanya pesan terbaru yang memenuhi syarat dari setiap validator yang berkontribusi. Protokol lain dapat memakai sertifikat ketersediaan, leader lock, round, atau sertifikat commit eksplisit alih-alih kompetisi cabang terberat yang terus berlangsung.

Hasil bergantung pada input yang tepat: chain dan network, versi fork, anchor tepercaya, waktu atau slot saat ini, blok valid yang diketahui, hubungan parent, snapshot kerja atau bobot voting, pesan terbaru, bukti equivocation, checkpoint justified dan finalized, status ketersediaan, waktu proposer, serta tie-break deterministik. Lencana block explorer atau satu hasil RPC adalah pengamatan atas output satu node, bukan aturan maupun bukti independen atas inputnya.

Cara menganalisis aturan fork choice

  1. Tetapkan identitas dan versi. Catat chain, network, fork konsensus, versi client, genesis atau anchor tepercaya, tinggi atau slot saat ini, dan aturan tepat yang aktif. Jangan terapkan logika mainnet pada testnet, sidechain, rollup, atau proposal masa depan.
  2. Bangun graf blok yang dapat diterima. Verifikasi hash, parent, bukti konsensus, transisi state, status execution payload, dan ketersediaan data yang diwajibkan. Tandai node unknown, optimistic, invalid, dan pruned secara eksplisit; bobot tidak dapat menyelamatkan cabang invalid.
  3. Rekonstruksi garis keturunan dan batasan. Temukan leluhur bersama dan pastikan kandidat mana yang merupakan turunan checkpoint, lock, atau sertifikat wajib. Pisahkan pohon mentah yang diamati dari pohon tersaring yang benar-benar boleh dipertimbangkan aturan.
  4. Reproduksi setiap input bobot. Untuk PoW, dekode target dan jumlahkan bukti per blok menjadi chainwork kumulatif. Untuk aturan voting, verifikasi identitas validator, effective balance aktif atau bobot lain, domain pesan, root target, slot atau epoch, penggantian pesan terbaru, perlakuan equivocation, dan boost sementara.
  5. Jalankan seleksi dan tie-break dengan tepat. Terapkan rekursi atau comparator yang ditentukan pada setiap percabangan, memakai pembulatan protokol dan urutan deterministik. Catat apakah bobot sama mengizinkan preferensi lokal sementara, bukan menganggap tie sebagai kesepakatan final.
  6. Rekonsiliasi perubahan head. Saat pemenang berubah, identifikasi blok yang dilepas dan dipasang, rollback lalu replay state, rekonsiliasi receipt, log, dan mempool, serta hitung kedalaman reorganisasi dari leluhur bersama. Bedakan label head, safe, justified, committed, dan finalized.
  7. Uji tekanan dan pantau sistem produksi. Uji blok tertunda atau ditahan, partition, vote basi, equivocation, balancing, waktu proposer, perbedaan client, checkpoint lemah, dan data tidak tersedia. Bandingkan node independen dan beri alarm atas divergensi head tak terduga, reorganisasi dalam, atau konflik dengan state final sebelum tindakan hilir yang tidak dapat dibatalkan.

Dalam Bitcoin Core saat ini, pengurutan kandidat pertama-tama membandingkan nChainWork; kandidat dengan kerja sama kemudian diurutkan berdasarkan urutan paling awal yang dapat diaktifkan, dengan tie-break internal sebagai cadangan. Field RPC blocks adalah tinggi rantai kerja-terbesar yang sepenuhnya tervalidasi, sedangkan bestblockhash mengidentifikasi tip-nya. Dalam spesifikasi fork choice Ethereum saat ini, get_head(store) dimulai dari justified_checkpoint, menelusuri pohon tersaring, dan pada setiap langkah memilih anak yang memaksimalkan (get_weight(store, child), child.root). Detail ini khusus protokol dan versi, bukan definisi generik konsensus.

Contoh perhitungan

1. Peralihan kerja kumulatif Bitcoin

Dua cabang valid berbagi leluhur bersama C. Tip saat ini memiliki chainwork(A)=240 dan chainwork(B)=235, sehingga node memilih A meskipun tampilan tinggi sederhana membuat kedua cabang tampak serupa. Sebuah blok valid baru menambahkan kerja 10 ke cabang B:

chainwork(B') = 235 + 10 = 245

Karena 245 > 240, B menjadi kandidat dengan kerja terbesar. Node memutus blok A setelah C, menghubungkan B sampai B', dan merekonsiliasi transaksi. Jumlah blok mentah tidak cukup bila target per blok berbeda, dan kerja yang sama adalah kasus tie sementara, bukan bukti finalitas.

2. Subtree teramati terberat secara greedy

Gunakan pohon LMD-GHOST sederhana yang berakar pada checkpoint justified J. Anak-anaknya adalah A dan B. Pesan terbaru validator yang memenuhi syarat memberi seluruh subtree A bobot 61 dan subtree B bobot 39, sehingga langkah greedy pertama memilih A. A memiliki anak A_1 dan A_2 dengan bobot subtree 34 dan 27; langkah berikutnya memilih A_1.

Head ditemukan dengan berulang kali memilih anak terberat, bukan dengan menghitung panjang cabang atau memilih leaf dengan vote langsung terisolasi terbesar. Aturan produksi juga mencakup penyaringan kelayakan, snapshot balance, penanganan equivocation, waktu proposer, dan tie-break yang dihilangkan dari pohon pengajaran ini.

3. Penggantian pesan terbaru

Misalkan pesan terbaru yang memenuhi syarat awalnya memberi cabang A bobot 55 dan cabang B bobot 45. Validator berbobot 20 kemudian mengirim pesan baru yang memenuhi syarat dan mendukung turunan B. Akuntansi pesan terbaru menghapus dukungan lama validator itu dari A dan menambahkannya ke B:

A: 55 - 20 = 35; B: 45 + 20 = 65

Bobot dihitung sekali, bukan pada kedua cabang, sehingga jalur terpilih dapat berubah. Ini bukan izin untuk voting yang tidak konsisten: jika bukti attester slashing yang valid mengidentifikasi equivocation, store Ethereum saat ini melacak validator tersebut dan mengecualikan bobotnya dari skor attestasi biasa.

4. Penyaringan checkpoint dan proposer boost

Anggap sebuah node mengamati bobot pesan terbaru mentah 70 pada cabang yang bertentangan dengan checkpoint final-nya dan bobot 30 pada turunan yang layak. Cabang yang bertentangan dikeluarkan sebelum pemilihan head; mayoritas bobot mentah tidak dapat mengatasi batasan checkpoint final melalui fork choice biasa.

Sekarang pertimbangkan dua anak yang layak dalam slot saat ini dengan bobot attestasi 35 dan 50. Dalam konfigurasi Ethereum yang dirujuk, proposer boost tepat waktu sama dengan 40% dari bobot satu committee, bukan 40 persen dari total stake. Jika bobot committee adalah 100 dan boost berlaku pada anak berbobot 35, skor perbandingannya menjadi 35 + 40 = 75, sehingga mengalahkan 50 pada langkah itu. Boost ini sementara dan khusus fork; bukan vote validator tambahan maupun finalitas.

Risiko dan kegagalan peninjauan

Kumpulan kandidat dan bukti

  • Membandingkan bobot cabang sebelum memvalidasi parent, transisi state, bukti, status payload, atau data wajib.
  • Memperlakukan eksekusi unknown atau optimistic, data tidak tersedia, atau pandangan headers-only sebagai state yang sepenuhnya tervalidasi.
  • Menggunakan tinggi blok, timestamp, jumlah transaksi, fee, atau popularitas explorer sebagai pengganti bobot yang ditentukan.
  • Menjumlahkan difficulty yang ditampilkan alih-alih mereproduksi bukti per blok dan chainwork kumulatif dengan target yang benar.
  • Menghitung semua vote historis alih-alih pesan terbaru yang memenuhi syarat dari setiap validator berdasarkan snapshot bobot yang benar.
  • Mengabaikan domain pesan, root, slot, epoch, ketepatan waktu, signature, equivocation, dan bukti slashing.
  • Membandingkan cabang mentah yang dibuat tidak layak oleh filter checkpoint, lock, sertifikat, atau ketersediaan protokol.
  • Menerapkan spesifikasi masa depan, parameter jaringan lain, atau optimisasi implementasi sebagai hukum konsensus saat ini.

Seleksi dan kegagalan operasional

  • Menjelaskan aturan Bitcoin sebagai “tinggi terpanjang” mentah atau aturan Ethereum sebagai vote head dua pertiga sederhana.
  • Mengganti rekursi subtree greedy dengan skor leaf global, atau menghilangkan proposer boost, pembulatan, dan tie-break root.
  • Menganggap node dengan urutan kedatangan, jam, atau pandangan pesan berbeda harus langsung melaporkan head yang sama.
  • Gagal memutus dan replay state, receipt, log, index, dan entri mempool dengan benar selama reorganisasi.
  • Membiarkan implementasi client berbeda dalam validitas, kelayakan checkpoint, pesan terbaru, waktu, atau tie-break.
  • Gagal mendeteksi balancing, withholding, equivocation, partition, eclipse, vote tertunda, dan kondisi proposer reorganization.
  • Memercayai satu RPC, explorer, relay, keluarga client, cloud, atau operator validator sebagai pandangan konsensus independen.

Finalitas dan ketidakselarasan aplikasi

  • Menyebut head terpilih final, tidak dapat dibalik, atau aman tanpa bukti finalitas terpisah milik protokol.
  • Melepaskan deposit, pesan bridge, atau trade tak dapat dibalik pada head sementara tanpa kebijakan yang sensitif terhadap nilai.
  • Menganggap leluhur final menjamin kebenaran atau ketersediaan setiap head, payload, oracle, atau hasil aplikasi yang lebih baru.
  • Menggunakan jumlah konfirmasi tetap untuk chain dengan model kerja, vote, checkpoint, dan pemulihan berbeda.
  • Memperlakukan checkpoint darurat, anchor weak-subjectivity, atau social recovery sebagai input fork choice biasa tanpa batas kepercayaan.

Kesalahpahaman umum

  • Cabang terpanjang selalu menang. Protokol dapat membandingkan kerja kumulatif, pesan terbaru berbobot, sertifikat, atau skor lain; tinggi mentah tidak universal.
  • Cabang teramati terberat otomatis valid. Validitas dan ketersediaan menyaring kandidat sebelum bobot dapat memilih di antaranya.
  • Fork choice dan finalitas adalah aturan yang sama. Fork choice memilih head saat ini untuk diperpanjang; finalitas melindungi leluhur dengan syarat keamanan tambahan.
  • Setiap vote validator selamanya berada dalam total. Dalam aturan pesan terbaru, pesan baru yang memenuhi syarat mengganti dukungan fork choice sebelumnya.
  • Satu explorer membuktikan chain kanonis. Explorer melaporkan pandangan satu tumpukan infrastruktur; validasi dan rekonsiliasi independen tetap diperlukan.

Topik terkait

Sumber

Navigasi

Cari di wiki...