Lompat ke konten
Financial Context Wiki

Subjektivitas lemah: checkpoint tepercaya dan sinkronisasi PoS yang aman

Subjektivitas lemah memungkinkan node proof-of-stake memverifikasi ke depan secara objektif setelah memperoleh checkpoint tepercaya yang cukup baru. Pelajari mengapa tanda tangan lama dapat mendukung sejarah jangka panjang, bagaimana kekinian checkpoint dan independensi sumber diverifikasi, dan apa yang tidak dibuktikan oleh sinkronisasi checkpoint.

Diperbarui

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

Jawaban langsung

Subjektivitas lemah adalah model keamanan proof-of-stake di mana sebuah node dapat memverifikasi blok, transisi status, suara, dan pilihan fork sesuai dengan aturan protokol setelah memulai dari checkpoint yang cukup baru yang diperoleh melalui saluran terpercaya atau yang dikonfirmasi secara sosial. Input subjektif “lemah” adalah titik awalnya. Ini bukan izin untuk memilih blok berikutnya secara sewenang-wenang: setelah tertambat, node harus menolak riwayat yang tidak mengandung checkpoint dan memverifikasi ke depan secara normal.

Masalahnya adalah ambiguitas historis. Seorang lawan yang memperoleh kunci dari validator yang telah keluar dan tidak lagi dapat dihukum secara ekonomi mungkin membangun sejarah alternatif yang panjang dengan tanda tangan yang tampak valid. Sebuah node yang mengamati rantai kanonik saat validator tersebut masih bisa dikenai slash mempertahankan memori yang berguna. Node yang benar-benar baru, node yang databasenya dihapus, atau node yang offline lebih lama dari jendela keamanan protokol mungkin tidak dapat mengidentifikasi sejarah kanonik secara sosial hanya dari data genesis dan pesan dari rekan-rekannya.

Pada Ethereum, sebuah checkpoint subjektivitas-lemah adalah epoch dan block_root yang dianggap klien sebagai jangkar mutlak. Sinkronisasi yang berhasil harus membuktikan bahwa jalur kanonik mengandung akar itu pada epoch tersebut; ketidaksesuaian merupakan kegagalan kritis, bukan suara pilihan-fork. Sebuah checkpoint subjektivitas-lemah juga berbeda dari checkpoint yang diselesaikan secara biasa: jika sebuah node pertama kali menemukan dua riwayat yang diselesaikan dan bertentangan tanpa memori sebelumnya, aturan finalitas saja tidak dapat mengidentifikasi riwayat sosial mana yang kanonik.

Jangan men-generalisasi mekanisme Ethereum. Klien ringan CometBFT dimulai dari header tepercaya dalam trusting_period yang dikonfigurasi dan mentransfer kepercayaan menggunakan tumpang tindih validator-set, tanda tangan, batas waktu, dan saksi. Penelitian Ouroboros Genesis sebaliknya mendefinisikan aturan pemilihan rantai yang dimaksudkan untuk memulai dari blok genesis yang tepercaya di bawah model keamanan yang dinyatakannya. “Proof of stake” oleh karena itu tidak menyiratkan satu format checkpoint, satu formula periode, atau satu prosedur bootstrap.

Juga pisahkan subjektivitas lemah dari pintasan sinkronisasi. Sinkronisasi checkpoint dapat mengurangi waktu startup dan pemrosesan riwayat, tetapi kecepatan bukanlah definisi keamanan. Root tepercaya tidak mengautentikasi situs web yang menyediakannya, memvalidasi payload eksekusi di luar asumsi yang dinyatakan klien, memulihkan riwayat yang dipangkas, membuktikan ketersediaan data, atau membuat set rekan yang tertutup menjadi jujur.

Cara memverifikasi bootstrap subjektivitas lemah

1. Identifikasi protokol dan model keamanan yang tepat

Catat network, chain ID, root atau hash genesis, fork atau runtime aktif, versi klien, tipe checkpoint, dan spesifikasi konsensus. Tentukan apakah protokol memerlukan checkpoint sosial terbaru, header terpercaya beserta set validator, rantai bukti finalitas, atau hanya genesis di bawah model yang berbeda. Jangan pernah memindahkan Ethereum’s compute_weak_subjectivity_period atau CometBFT’s trusting_period ke rantai lain tanpa aturannya.

2. Tentukan apakah kepercayaan yang ada masih berlaku

Inventarisasi titik pemeriksaan final terakhir yang diverifikasi secara lokal pada node, epok atau tingginya beserta waktunya, sumber waktu saat ini, dan setiap pemulihan basis data. Hitung usia menggunakan aturan dan status aktif protokol, bukan perkiraan kalender yang diingat. Untuk Ethereum, panduan Fase 0 menguji current_epoch <= ws_state_epoch + ws_period; Electra mengubah perhitungan periode agar bergantung pada total saldo aktif dan pergantian saldo. Jika kepercayaan telah kedaluwarsa, dapatkan jangkar baru melalui jalur terpisah daripada mencoba lebih keras terhadap rekan yang tidak dipercaya.

3. Peroleh dan perkuat titik pemeriksaan

Dapatkan checkpoint yang sama dari saluran yang dikelola secara independen dan bersumber secara independen: misalnya, sebuah node yang Anda operasikan, operator lain, beberapa tim klien, dan penjelajah dengan infrastruktur yang berbeda. Catat setiap sumber, waktu pengambilan, jaringan, epoch, dan root lengkap. Lima URL yang menyalin satu sumber hulu adalah satu domain kegagalan. Mayoritas respons sederhana bukan pengganti untuk independensi sumber, transportasi yang terautentikasi, atau tinjauan insiden sosial.

4. Ikat setiap bidang titik pemeriksaan

Verifikasi jaringan dan identitas genesis sebelum nilai checkpoint. Pertahankan root penuh tanpa pemotongan dan pasangkan dengan epoch atau tinggi yang tepat, status jika diperlukan, versi fork, dan waktu perolehan. Panduan Ethereum menggunakan block_root:epoch_number; inisialisasi CometBFT juga mengikat header tepercaya dan set validator serta parameter kepercayaan. Root yang benar yang terpasang pada chain atau tinggi yang salah bukanlah jangkar yang sah.

5. Terapkan jalur sinkronisasi yang gagal-tertutup

Konfigurasikan checkpoint melalui antarmuka terdokumentasi klien dan simpan log startup. Selama sinkronisasi, pastikan jalur kanonik pada epoch checkpoint sama dengan block_root yang disediakan. Panduan Ethereum mengharuskan adanya kesalahan kritis yang deskriptif dan keluar proses saat pernyataan gagal. Jangan mengabaikan checkpoint secara diam-diam, kembali ke mayoritas peer, menimpanya dengan respons peer yang lebih baru, atau mempertahankan penandatangan validator saat pandangan konsensusnya tidak pasti.

6. Pisahkan lapisan yang telah diverifikasi dan yang belum diverifikasi

Lacak kepercayaan titik pemeriksaan konsensus, verifikasi blok beacon atau konsensus, status payload eksekusi, sinkronisasi status eksekusi, pengisian kembali historis, dan bukti aplikasi secara terpisah. Sinkronisasi optimistis Ethereum memungkinkan ExecutionPayload dari jangkar titik pemeriksaan diasumsikan sebagai VALID tanpa terlebih dahulu memberikannya ke mesin eksekusi, sementara node optimistis tidak boleh melakukan tugas validator. Pengisian kembali titik pemeriksaan Lighthouse memeriksa integritas rantai hash historis dan tanda tangan pengusul tetapi secara default tidak membangun ulang setiap status historis.

7. Segarkan, pantau, dan latih pemulihan

Tetapkan peringatan dan segarkan margin dengan nyaman di dalam periode yang berlaku. Pantau finalisasi, kesehatan jam, perselisihan klien, status execution_optimistic, keberagaman rekan, usia checkpoint, dan celah pengisian kembali. Latih pemulihan dari database yang dihapus, checkpoint yang kedaluwarsa, sumber yang bertentangan, dan penyedia yang tidak tersedia. Simpan catatan yang ditandatangani dari jangkar dan keputusan, tetapi jangan biarkan checkpoint yang diarsipkan menjadi checkpoint kedaluwarsa yang dipercaya secara permanen.

Contoh yang dikerjakan

Titik pemeriksaan Ethereum dengan sisa kapasitas

Gunakan sebuah negara ilustratif yang perhitungan referensi Electra yang berlaku memberikannya ws_period = 3,532 epochs. Misalkan current_epoch = 420,000 dan titik pemeriksaan yang dikonfirmasi secara independen adalah checkpoint_epoch = 418,200:

checkpoint_age = 420,000 - 418,200 = 1,800 epochs.

Tes kekinian panduan adalah 420,000 <= 418,200 + 3,532, jadi titik pemeriksa berada dalam periode. Pada 32 slots * 12 seconds = 6.4 minutes per epoch, umurnya adalah 1,800 * 6.4 / 1,440 = 8 days. Sisa batas adalah 3,532 - 1,800 = 1,732 epochs, atau 1,732 * 6.4 / 1,440 = 7.6978 days. Ini menggunakan periode tabel referensi, bukan janji jaringan langsung; klien harus menghitung dari percabangan dan status yang sebenarnya.

Titik pemeriksaan yang kedaluwarsa tidak diperbaiki oleh lebih banyak rekan

Misalkan current_epoch = 500,000, checkpoint_epoch = 496,000, dan ws_period = 3,532 epochs yang berlaku:

checkpoint_age = 500,000 - 496,000 = 4,000 epochs.

Karena 500,000 > 496,000 + 3,532, checkpoint sudah kadaluarsa oleh 4,000 - 3,532 = 468 epochs. Pada 6.4 menit per epoch, itu adalah 468 * 6.4 / 60 = 49.92 hours melebihi batas. Mengunduh root yang sama yang sudah kedaluwarsa dari 100 rekan tidak mengembalikan asumsi; operator membutuhkan checkpoint yang cukup baru dari saluran yang tepercaya dan dikonfirmasi.

Jumlah sumber versus independensi sumber

Seorang operator menerima lima tanggapan. Empat melaporkan epoch = 600,000 dan satu root penuh identik yang diberi label root_A, sementara satu melaporkan root penuh berbeda yang diberi label root_B. Penyelidikan menunjukkan bahwa ketiga situs web yang setuju semuanya menggunakan proxy dari node yang sama; yang keempat adalah node milik operator itu sendiri. Persetujuan yang tampak adalah 4 / 5 = 80%, tetapi itu hanya mewakili dua garis keturunan independen. Di bawah kebijakan yang mengharuskan tiga jalur administratif dan data independen, checkpoint belum disetujui. Operator independen ketiga mengonfirmasi root_A, layanan yang menentang diisolasi, dan catatan asal menjelaskan keputusan tersebut.

anggaran periode kepercayaan gaya CometBFT

Pertimbangkan sebuah rantai yang dikonfigurasi dengan unbonding_period = 21 days dan operator-memilih trusting_period = 14 days, sesuai dengan persyaratan bahwa periode kepercayaan harus lebih pendek dari unbonding. Sebuah header terpercaya yang telah menua 11 days memiliki 14 - 11 = 3 days ruang kepala. Target penyegaran harian meninggalkan margin operasional. Jika klien kembali setelah 16 days, header tersebut dua hari melewati periode kepercayaannya dan harus diganti melalui inisialisasi terpercaya baru; formula epoch Ethereum tidak menentukan kasus CometBFT ini.

Risiko dan kegagalan tinjauan

  • Jaringan salah: Root valid dari testnet, fork, clone, atau genesis lain dapat menambatkan riwayat yang keliru.
  • Checkpoint kedaluwarsa: Root di luar periode yang berlaku tidak lagi memenuhi asumsi tentang set validator terbaru.
  • Rumus periode salah: Upgrade fork, saldo, churn, unbonding, dan parameter keamanan dapat mengubah batas.
  • Sumber tunggal: Beberapa endpoint dapat memakai node, akun cloud, database, penyedia DNS, atau operator yang sama.
  • Distribusi disusupi: Rilis, situs, paket, respons DNS, atau pesan dukungan berbahaya dapat mengganti checkpoint.
  • Perbandingan terpotong: Membandingkan awalan, tangkapan layar, atau pengenal terformat saja dapat menyembunyikan perbedaan root penuh.
  • Field tidak cocok: Root yang benar dengan epoch, ketinggian, status, fork, atau chain yang salah bukan checkpoint yang sama.
  • Fallback ke mayoritas peer: Node yang terkena eclipse dapat melihat banyak peer lawan; jumlah peer tidak mengalahkan anchor tepercaya.
  • Fallback diam-diam: Klien atau wrapper yang mengabaikan checkpoint tertolak merusak kontrol fail-closed.
  • Riwayat final yang bertentangan: Node baru tidak menyelesaikan kegagalan konsensus hanya karena kedua fork diberi label final.
  • Kesalahan jam: Waktu lokal yang salah merusak pemeriksaan slot, epoch, usia, periode kepercayaan, dan header masa depan.
  • Kebingungan status optimistic: Blok konsensus yang diimpor mungkin masih berisi execution payload yang belum divalidasi penuh.
  • Tugas validator terlalu dini: Menandatangani saat optimistic, belum sinkron, atau memakai anchor tidak pasti dapat menimbulkan suara salah atau slashing.
  • Kebingungan kelengkapan riwayat: Sinkronisasi checkpoint dan backfill dapat melewatkan status historis meski head saat ini valid.
  • Tanda tangan backfill tidak valid: Blok historis yang terhubung dengan hash tetap membutuhkan pemeriksaan tanda tangan proposer.
  • Bukti eksekusi atau aplikasi tidak memadai: Anchor konsensus tidak membuktikan nilai RPC arbitrer, klaim kontrak, atau indeks off-chain.
  • Kesenjangan ketersediaan data: Mengetahui state root tidak menjamin akses ke setiap body, Blob, witness, atau catatan historis.
  • Rencana pemulihan kedaluwarsa: Jika masa berlaku habis baru diketahui saat gangguan, sumber checkpoint independen mungkin tidak tersedia.
  • Koordinasi sosial dikuasai: Tata kelola, tim klien, explorer, bursa, dan operator dapat berbagi insentif atau ketergantungan.
  • Universalitas palsu: Desain PoS lain dapat memakai asumsi, rantai bukti, periode kepercayaan, atau jaminan bootstrap dari genesis yang berbeda.

Kesalahpahaman umum

Apakah subjektivitas lemah berarti aturan protokol bersifat subjektif setelah startup?

Tidak. Node menerima anchor tertentu yang terbaru melalui saluran sosial atau tepercaya, kemudian menerapkan validasi deterministik dan aturan pemilihan fork ke depan. Blok yang bertentangan dengan anchor ditolak.

Apakah setiap checkpoint yang telah selesai secara otomatis merupakan checkpoint bootstrap yang aman?

Tidak. Itu harus merupakan bagian dari jaringan yang dimaksud dan sejarah sosial kanonik, cukup baru sesuai aturan yang berlaku, mencakup bidang yang diperlukan, dan melalui jalur yang dapat dipercaya dan terverifikasi. Finalitas yang diamati untuk pertama kalinya pada sejarah yang disediakan penyerang tidak menetapkan asal-usul.

Apakah menyinkronkan dari genesis menghilangkan masalah serangan jarak jauh?

Tidak untuk protokol yang model keamanannya memerlukan checkpoint subyektivitas-lemah baru. Memutar ulang tanda tangan yang valid secara internal sejak genesis tidak memberi tahu node baru sejarah finalisasi lama mana yang sebenarnya diikuti oleh komunitas. Protokol lain mungkin memberikan jaminan bootstrap-genesis yang berbeda di bawah asumsi yang berbeda.

Apakah sinkronisasi checkpoint memvalidasi semua eksekusi dan status historis?

Tidak. Perilaku klien bersifat berlapis dan spesifik implementasi. Node mungkin mempercayai atau secara optimistis mengimpor anchor, menyinkronkan status eksekusi saat ini secara terpisah, dan hanya mengisi kembali tautan blok dan tanda tangan proposer tanpa membangun kembali semua status historis.

Apakah sebuah checkpoint yang dikodekan secara tetap bisa dipercaya selamanya?

Tidak. Sebuah checkpoint terikat pada jaringan dan periode tertentu. Itu dapat tetap berguna sebagai catatan audit atau batasan historis, tetapi sebuah node yang asumsi kepercayaannya baru-baru ini telah berakhir membutuhkan anchor yang sesuai baru atau proses pemulihan yang ditentukan oleh protokol tersebut.

Topik terkait

Sumber

Navigasi

Cari di wiki...