---
title: "Finalitas blockchain: bukti, asumsi, dan lapisan penyelesaian"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Finalitas blockchain: bukti, asumsi, dan lapisan penyelesaian

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

<a id="answer"></a>

## 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.

<a id="mechanism"></a>

## 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.

<a id="example"></a>

## 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.

<a id="risks"></a>

## 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.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Topik terkait

- [Konfirmasi blok](/id/crypto/block-confirmation/)
- [Reorganisasi chain](/id/crypto/chain-reorg/)
- [Mekanisme konsensus](/id/crypto/consensus-mechanism/)
- [Aturan pemilihan fork](/id/crypto/fork-choice-rule/)
- [Subjektivitas lemah](/id/crypto/weak-subjectivity/)

<a id="sources"></a>

## Sumber

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (diakses: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (diakses: 2026-08-19)
- [Bitcoin Core RPC: getblockheader](https://developer.bitcoin.org/reference/rpc/getblockheader.html) - Bitcoin Project (diakses: 2026-08-19)
- [Ethereum Proof-of-Stake Consensus](https://ethereum.org/developers/docs/consensus-mechanisms/pos/) - Ethereum.org (diakses: 2026-08-19)
- [Ethereum Consensus Specifications: Beacon Chain](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (diakses: 2026-08-19)
- [Ethereum Proof-of-Stake Rewards and Penalties](https://ethereum.org/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/) - Ethereum.org (diakses: 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (diakses: 2026-08-19)
- [OP Stack Derivation Specification](https://specs.optimism.io/protocol/derivation.html) - Optimism (diakses: 2026-08-19)

Source: https://wiki.fcontext.com/id/crypto/finality/index.mdx