Lompat ke konten
Financial Context Wiki

Finalitas blockchain: bukti, asumsi, dan lapisan penyelesaian

Finalitas adalah jaminan khusus protokol bahwa suatu keputusan tidak akan diganti tanpa melanggar asumsi keamanan atau menjalankan pemulihan luar biasa. Validitas, pemilihan fork, bukti finalisasi, batas kegagalan, ketergantungan lapisan, dan penyelesaian aplikasi harus dianalisis terpisah.

Diperbarui

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

Jawaban langsung

Finalitas adalah jaminan khusus protokol bahwa keputusan yang diterima, seperti blok, checkpoint, atau komitmen status, tidak akan diganti tanpa melanggar asumsi keamanan yang dinyatakan atau memakai proses pemulihan luar biasa. Ini bukan sifat fisik byte transaksi dan bukan sekadar “transaksi berhasil”. Setiap klaim harus menyebut objek, jaringan, versi protokol, bukti, model kegagalan dan waktu, titik awal tepercaya, serta pengamat.

Validitas, kanonisitas, dan finalitas berbeda. Blok valid memenuhi aturan transisi status dan otorisasi. Pemilihan fork memilih head kanonis saat ini dari kandidat valid. Finalisasi menerapkan predikat tambahan, seperti sertifikat commit atau checkpoint final, pada leluhur head tersebut. Transaksi dapat berhasil di blok valid yang kemudian kalah dalam pemilihan fork; head dapat bersifat kanonis tetapi belum final; dan peristiwa yang final di chain sumber masih dapat gagal pada bridge, bursa, atau aplikasi.

Sistem proof of work biasanya memberi penyelesaian probabilistik, bukan bit finalitas eksplisit: semakin banyak kerja valid terakumulasi di atas blok, penggantiannya umumnya makin kecil kemungkinannya dan makin mahal di bawah asumsi daya hash dan jaringan. Protokol bergaya BFT dapat memberi finalitas deterministik bersyarat: setelah sertifikat commit valid, dua keputusan yang bertentangan tidak dapat sama-sama di-commit bila bobot yang salah tetap di bawah batas terbukti. Finalitas PoS juga dapat bersifat akuntabel atau ekonomi karena suara yang bertentangan mengidentifikasi bobot yang dapat di-slash. Istilah ini menjelaskan bukti yang berbeda.

Tidak ada protokol yang membuat riwayat mutlak tidak berubah. Kebocoran kunci besar, pelanggaran batas kegagalan, bug klien, transisi tidak valid yang diterima implementasi, intervensi tata kelola, atau pemulihan sosial dapat melewati batas model. “Final” harus berarti jalur reorganisasi biasa protokol tidak dapat mengganti keputusan tersebut berdasarkan asumsi ini; pemulihan luar biasa dan kewenangannya dicatat terpisah.

Cara menganalisis finalitas

  1. Tentukan objek dan cakupan. Identifikasi transaksi, blok, checkpoint, state root, pesan lintas chain, atau penarikan; catat chain, jaringan, lapisan, versi, ketinggian atau slot, hash blok, dan checkpoint tepercaya.
  2. Verifikasi validitas sebelum status. Eksekusi ulang atau validasi transisi status dan leluhur terkait. Menurut aturan sebenarnya, kuorum, skor kerja, atau lencana antarmuka tidak dapat memfinalkan objek tidak valid.
  3. Pisahkan pemilihan head dari finalisasi. Rekonstruksi fork choice dan jalur kanonis saat ini, lalu cari leluhur yang final atau committed. Catat apakah status baru diamati, dikonfirmasi, dijustifikasi, aman, committed, atau final.
  4. Reproduksi bukti. Untuk PoW, verifikasi header, target, dan chainwork kumulatif di atas blok. Untuk protokol suara, verifikasi kelayakan, snapshot bobot, domain pesan, sumber dan target, ketinggian, ronde, pertidaksamaan kuorum, tanda tangan, lock, dan leluhur sertifikat.
  5. Nyatakan asumsi safety dan liveness. Tentukan bobot Byzantine atau offline, sinkroni, penundaan, equivocating, kebocoran kunci, korelasi klien, perubahan anggota, ketersediaan slashing, dan respons saat finalisasi macet. Penghentian dapat mempertahankan safety sambil kehilangan liveness.
  6. Petakan setiap lapisan penyelesaian. Lacak penerimaan sequencer, eksekusi L2, publikasi data, inklusi L1, finalitas L1, selesainya bukti atau sengketa, eksekusi bridge, kredit bursa, dan tindakan aplikasi. Label serupa di lapisan berbeda belum tentu merupakan predikat yang sama.
  7. Tetapkan dan pantau kebijakan aplikasi. Definisikan bukti yang diterima menurut nilai dan konsekuensi, tanyakan node independen, tangani reorganisasi dan alarm finalitas bertentangan, hentikan tindakan hilir yang tidak dapat dibatalkan saat asumsi gagal, dan catat pemberi izin pemulihan.

Jumlah konfirmasi adalah pengamatan, bukan aturan finalitas universal. Di Bitcoin Core, confirmations bergantung pada posisi blok dalam chain aktif saat ini, sedangkan chainwork mencatat kerja harapan kumulatif. Di Ethereum, pemilihan head LMD-GHOST serta justifikasi dan finalisasi checkpoint Casper FFG adalah transisi terpisah. Di CometBFT, commit memerlukan lebih dari dua pertiga daya suara untuk melakukan precommit pada blok yang sama di ketinggian dan ronde yang sama. Setiap status harus ditafsirkan dalam protokolnya.

Contoh perhitungan

1. Penyelesaian proof of work probabilistik

White paper Bitcoin memodelkan penyerang dengan pangsa daya hash q=0.10 yang mencoba mengejar chain jujur setelah tertinggal z=6. Berdasarkan asumsi percobaan hash independen dan distribusi Poisson, probabilitas mengejar yang dihitung adalah:

P=0.0002428 = 0.02428%

Hasilnya kecil, bukan nol, dan bukan jaminan universal “enam konfirmasi”. Kebijakan nyata harus mempertimbangkan nilai transaksi, chainwork yang diamati, konsentrasi daya hash, risiko eclipse atau partisi, insentif biaya, dan kredibilitas asumsi pangsa konstan.

2. Justifikasi dan finalisasi Ethereum

Gunakan jalur checkpoint berurutan yang disederhanakan dengan total saldo efektif aktif 100. Suara 67/100 yang menghubungkan checkpoint terjustifikasi C_0 ke target C_1 mencapai sekurangnya dua pertiga dan menjustifikasi C_1. Tautan berikutnya yang memenuhi syarat sebesar 67/100 dari C_1 ke anak langsung C_2 dapat memfinalkan C_1 menurut aturan Casper FFG yang berlaku.

Head dapat melaju melewati C_2 sementara bagian baru belum final. Jika saldo 34 offline, hanya 66 tersisa dan finalisasi langsung macet walaupun fork choice dan produksi blok dapat berlanjut. Setelah lebih dari empat epoch tanpa finalitas, inactivity leak Ethereum mulai menghukum nonpartisipasi agar supermayoritas aktif akhirnya dapat memulihkan finalitas.

3. Safety dan liveness CometBFT

Misalkan total daya suara 100 dan commit membutuhkan >2/3 precommit untuk blok yang sama pada satu ketinggian dan ronde. Daya bulat 67 dapat melakukan commit. Dua himpunan commit berbobot 67 beririsan sekurangnya 67 + 67 - 100 = 34 daya. Bila bobot Byzantine di bawah sepertiga dan validator jujur menaati aturan lock, dua commit bertentangan tidak dapat terbentuk.

Jika bobot 34 tidak tersedia, hanya 66 yang dapat bersuara sehingga commit tidak terbentuk. Protokol dapat mempertahankan safety saat finalisasi berhenti. “Tidak ada blok final yang bertentangan” dan “blok baru terus difinalkan” adalah dua jaminan berbeda.

4. Status OP Stack dan waktu penarikan

Sequencer OP Stack dapat lebih dulu menampilkan blok L2 sebagai unsafe. Saat blok dapat sepenuhnya diturunkan dari data chain L1 kanonis saat ini, node rollup dapat menandainya safe. Ketika input L1 terkait menerima sinyal finalitas L1, blok L2 turunan dapat menjadi finalized.

Status itu menyangkut derivasi dari input final. Output optimistic rollup atau penarikan L2-ke-L1 memiliki proses bukti dan sengketa tersendiri dan mungkin disebut “final” hanya setelah syarat tantangannya terpenuhi. Aplikasi yang menyatukan konfirmasi sequencer, inklusi data L1, finalitas konsensus L1, dan eksekusi penarikan dalam satu waktu dapat melepas nilai terlalu dini.

Risiko dan kegagalan peninjauan

Definisi dan bukti

  • Menyebut setiap eksekusi, tanda terima, konfirmasi, checkpoint, atau lencana yang berhasil sebagai “final”.
  • Menghilangkan chain, jaringan, versi, hash objek, ketinggian atau slot, lapisan, dan pengamat.
  • Menganggap head fork choice saat ini sebagai leluhur final atau mengira finalisasi memilih head terbaru.
  • Menghitung blok atau menit tanpa memvalidasi leluhur, target, kerja, suara, atau sertifikat.
  • Membandingkan “dua konfirmasi” atau “finalitas sepuluh menit” antarprotokol dengan bukti dan model kegagalan berbeda.
  • Memverifikasi tanda tangan tanpa kelayakan, bobot, domain, sumber, target, ketinggian, dan ronde.
  • Menyamakan biaya ekonomi, bukti yang dapat di-slash, dan pelaksanaan penalti sebenarnya.
  • Menggambarkan risiko probabilistik sebagai nol atau safety deterministik bersyarat sebagai tidak dapat dibalik mutlak.

Kegagalan protokol dan operasi

  • Melampaui batas Byzantine, kehilangan bobot online yang diperlukan untuk liveness, atau menyembunyikan partisi jaringan.
  • Membiarkan implementasi berbeda tentang validitas, fork choice, transisi, pembulatan kuorum, atau leluhur sertifikat.
  • Menerima suara, commit, checkpoint, atau data weak subjectivity yang usang, diputar ulang, atau dari jaringan lain.
  • Memusatkan kunci, stake, daya hash, klien, relay, cloud, atau pandangan RPC di balik identitas yang tampak terpisah.
  • Menganggap inactivity leak, timeout, atau view change langsung memulihkan kemajuan tanpa konsekuensi.
  • Tidak memberi alarm atas keterlambatan finalitas, sertifikat bertentangan, reorganisasi dalam, equivocating, atau akar final yang berbeda.
  • Memakai tata kelola darurat atau pemulihan sosial tanpa mendokumentasikan kewenangan, koordinasi, rilis klien, dan jaminan terdampak.

Ketidakcocokan lapisan dan aplikasi

  • Menganggap inklusi sequencer sekaligus sebagai safety L2, publikasi L1, finalitas L1, penerimaan bukti, dan selesainya penarikan.
  • Melepas aset bridge sebelum peristiwa sumber dan jalur verifikasi bridge sendiri memenuhi kebijakan.
  • Mengkredit deposit atau menjalankan perdagangan tak dapat dibatalkan dari status satu penyedia RPC tanpa rekonsiliasi independen.
  • Menganggap finalitas chain menjamin kebenaran oracle, ketepatan kontrak, ketersediaan data, solvabilitas bursa, atau penyelesaian hukum.
  • Menerapkan satu ambang konfirmasi tetap untuk setiap nilai, pihak lawan, insentif serangan, dan biaya pemulihan.

Kesalahpahaman umum

  • Transaksi yang berhasil sudah final. Keberhasilan hanya menjelaskan satu transisi dalam riwayat kandidat; kanonisitas dan finalitas memerlukan bukti tambahan.
  • Lebih banyak konfirmasi membuat risiko PoW tepat nol. Probabilitas model dapat turun tajam, tetapi tetap bersyarat dan tidak menjadi kemustahilan logis.
  • Dua pertiga selalu berarti finalitas. Pertidaksamaan, jenis pesan, snapshot bobot, ketinggian, ronde, relasi sumber-target, dan aturan lock bersifat khusus protokol.
  • Finalitas menjamin jaringan terus maju. Safety dapat tetap utuh ketika partisipasi atau konektivitas yang kurang mencegah finalisasi baru.
  • Finalitas L1 menyelesaikan setiap tindakan L2 atau bridge. Derivasi, bukti validitas atau fraud, periode tantangan, dan eksekusi tujuan menambah waktu dan jalur kegagalan tersendiri.

Topik terkait

Sumber

Navigasi

Cari di wiki...