﻿---
title: "區塊鏈最終性：證據、假設與結算層"
description: "最終性是特定協議給出的保證：除非違反安全假設或啟動非常規恢復，某項決定不會被替換。應分別分析有效性、分叉選擇、最終化證據、故障界限、層間依賴與應用結算。"
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.

# 區塊鏈最終性：證據、假設與結算層

> 僅供協議研究與教育用途。“已確認”“安全”“已提交”或“已最終化”等標籤，只有連同其鏈、規則集、證據、故障假設、所在層和應用策略一起說明時才有意義。

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

## 直接答案

最終性是特定協議給出的保證：一個已接受的決定（如區塊、檢查點或狀態承諾）不會被替換，除非既定安全假設遭到違反，或啟動非常規恢復流程。它不是交易位元組的物理屬性，也不等於“交易執行成功”。任何最終性宣告都必須說明物件、網路、協議版本、證據、故障與時序模型、可信起點和觀察者。

有效性、規範性與最終性各不相同。有效區塊滿足狀態轉換和授權規則；分叉選擇從有效候選中選出當前規範鏈頭；最終化則對該鏈頭的某個祖先應用附加判定條件，如提交證書或已最終化檢查點。交易可能在後來輸掉分叉選擇的有效區塊中成功執行；鏈頭可能是規範的卻尚未最終化；已最終化的源鏈事件也仍可能在橋、交易所或應用中失敗。

工作量證明系統通常提供機率結算，而不是明確的最終化位：區塊之上累積的有效工作越多，在給定算力與網路假設下替換它通常越不可能、成本越高。BFT 類協議可以提供有條件的確定性最終性：取得有效提交證書後，只要故障投票權重低於已證明界限，兩個衝突決定就不可能同時提交。權益證明的最終性也可以是可問責或經濟性的，因為衝突投票能識別可罰沒權重。這些標籤描述不同證據，不能互換。

沒有協議能讓歷史在形而上意義上不可改變。災難性金鑰洩露、故障界限失守、客戶端缺陷、實現接受無效狀態轉換、治理干預或社會恢復，都可能越過模型邊界。因此，“已最終化”應表示“在這些假設下，協議的常規重組路徑排除了該決定”，而非常規恢復及其許可權應另行記錄。

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

## 如何分析最終性

1. **明確物件與範圍。** 確認交易、區塊、檢查點、狀態根、跨鏈訊息或提款；記錄鏈、網路、所在層、協議版本、高度或時隙、區塊雜湊和可信檢查點。
2. **先驗證有效性，再判斷狀態。** 重新執行或以其他方式驗證相關狀態轉換與祖先關係。按實際規則，法定人數、工作分數或介面徽章都不能讓無效物件最終化。
3. **區分鏈頭選擇與最終化。** 重建分叉選擇和當前規範路徑，再定位協議已最終化或已提交的祖先；記錄該宣告究竟只是已觀察、已確認、已合理化、安全、已提交還是已最終化。
4. **復現證據。** 對工作量證明，驗證區塊頭、目標和該區塊之上的累計鏈工作量；對投票協議，驗證簽名者資格、權重快照、訊息域、源與目標、高度、輪次、法定人數不等式、簽名、鎖定和證書祖先關係。
5. **說明安全與活性假設。** 明確拜占庭或離線權重、同步性、延遲、雙籤、金鑰洩露、客戶端相關性、成員變更、罰沒可用性，以及最終化停滯時會發生什麼。停機可能維持安全性，卻失去活性。
6. **對映每一層結算。** 追蹤排序器收據、L2 執行、資料釋出、L1 納入、L1 最終性、證明或爭議完成、橋訊息執行、交易所入賬與應用動作。不同層的相似標籤未必表示同一判定條件。
7. **制定並監控應用策略。** 按價值和後果定義可接受證據，查詢獨立節點，處理重組和衝突最終性警報，在假設失效時暫停不可逆的下游動作，並記錄誰有權批准恢復。

確認數是一項觀察值，不是通用最終性規則。在 Bitcoin Core 中，區塊的 `confirmations` 取決於它在當前活動鏈中的位置，而 `chainwork` 記錄累計預期工作量。在 Ethereum 中，LMD-GHOST 鏈頭選擇與 Casper FFG 檢查點合理化和最終化是不同狀態轉換。在 CometBFT 中，提交要求超過三分之二投票權在同一高度、同一輪次對同一區塊預提交。每種狀態都必須放回其協議中解釋。

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

## 計算示例

### 1. 機率型工作量證明結算

Bitcoin 白皮書對以下情形建模：攻擊者算力佔比為 `q=0.10`，試圖在誠實鏈領先 `z=6` 後追上。根據其中獨立雜湊試驗和泊松分佈假設，算得追趕機率為：

`P=0.0002428 = 0.02428%`

結果很小，但不為零，也不是通用的“六次確認”保證。真實策略還必須考慮交易價值、觀測到的鏈工作量、算力集中度、日蝕或分割槽風險、手續費激勵，以及模型的恆定份額假設是否可信。

### 2. Ethereum 的合理化與最終化

設一條簡化的連續檢查點路徑，總活躍有效餘額為 `100`。有 `67/100` 的投票把已合理化檢查點 `C_0` 連線至目標 `C_1`，達到至少三分之二門檻並使 `C_1` 合理化。隨後若有一條合格的 `67/100` 連結從 `C_1` 指向其直接子檢查點 `C_2`，則可依據適用的 Casper FFG 規則最終化 `C_1`。

鏈頭可以延伸到 `C_2` 之後，而較新的部分仍未最終化。如果餘額 `34` 離線，只剩 `66`，即時最終化便會停滯，即便分叉選擇和出塊可能繼續。超過四個 epoch 未達最終性後，Ethereum 的不活躍洩漏機制開始懲罰不參與者，使活躍的超級多數最終能夠恢復最終性。

### 3. CometBFT 的安全性與活性

設總投票權為 `100`，提交要求在同一高度和輪次對同一區塊獲得 `>2/3` 預提交。整數投票權 `67` 可以提交。任意兩個 67 權重的提交集合至少交疊 `67 + 67 - 100 = 34` 權重。如果拜占庭權重低於三分之一且誠實驗證者遵守鎖定規則，就不可能形成兩個衝突提交。

若有 `34` 權重不可用，只剩 `66` 能投票，因而無法形成提交。協議可能在最終化停止時仍維持安全性。“不存在衝突的最終區塊”與“新區塊持續最終化”是兩個不同保證。

### 4. OP Stack 狀態與提款時鐘

OP Stack 排序器可能先把 L2 區塊公佈為 `unsafe`。當該區塊可以完全由當前規範 L1 鏈上的資料推匯出來時，彙總節點可將其標記為 `safe`。當對應 L1 輸入收到 L1 最終性訊號後，派生的 L2 區塊可變為 `finalized`。

該狀態說明區塊由已最終化輸入派生。樂觀彙總的輸出或 L2 到 L1 提款另有證明和爭議流程，並且可能只在挑戰條件滿足後才使用“已最終化”一詞。若應用把排序器確認、L1 資料納入、L1 共識最終性和提款執行壓縮成一個時間戳，就可能過早釋放價值。

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

## 風險與審查失誤

### 定義與證據

- 把任何成功執行、收據、確認、檢查點或介面徽章稱為“最終”。
- 省略鏈、網路、協議版本、物件雜湊、高度或時隙、所在層與觀察者。
- 把當前分叉選擇鏈頭當成已最終化祖先，或假定最終化會選擇最新鏈頭。
- 未驗證祖先關係、目標、工作量、投票或證書，只計算區塊數或經過分鐘數。
- 在證據與故障模型不同的協議間比較“兩次確認”或“十分鐘最終性”。
- 驗證簽名卻不驗證簽名者資格、權重快照、訊息域、源、目標、高度與輪次。
- 把經濟成本、可罰沒證據和實際執行懲罰視為同一保證。
- 把機率風險描述為零，或把有條件的確定性安全描述為無條件不可逆。

### 協議與操作故障

- 超出已證明的拜占庭權重界限、失去足夠線上權重而破壞活性，或掩蓋網路分割槽。
- 實現對有效性、分叉選擇、檢查點轉換、法定人數取整或證書祖先關係意見不一。
- 接受過期、重放或跨網路的投票、提交、檢查點或弱主觀性資料。
- 把驗證者金鑰、權益、算力、客戶端、中繼、雲或 RPC 檢視集中在名義獨立的身份背後。
- 假定不活躍洩漏、超時或檢視變更會即時且無經濟或分割槽後果地恢復進展。
- 未對最終化延遲、衝突證書、深度重組、雙籤或最終化根分歧報警。
- 使用緊急治理或社會恢復，卻不記錄許可權、協調、客戶端釋出和受影響的保證。

### 層與應用錯配

- 把排序器納入同時視為 L2 安全、L1 釋出、L1 最終性、證明接受和提款完成。
- 在源事件與橋自身驗證路徑滿足策略前釋放橋接資產。
- 根據單一 RPC 提供商的狀態給存款入賬或執行不可逆交易，而不做獨立核對。
- 假定鏈最終性保證預言機事實、合約正確性、資料可用性、交易所償付能力或法律結算。
- 對所有價值、對手方、攻擊激勵和恢復成本使用同一個固定確認門檻。

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

## 常見誤解

- **交易成功就已經最終化。** 執行成功只描述某條候選歷史中的一次狀態轉換；規範狀態和最終化狀態需要額外證據。
- **更多確認最終會讓工作量證明風險精確降到零。** 模型機率可以大幅下降，但仍取決於假設，並不會成為邏輯上的不可能。
- **三分之二永遠意味著最終性。** 不等式、訊息型別、權重快照、高度、輪次、源目標關係和鎖定規則均由具體協議定義。
- **最終性保證網路持續推進。** 當參與度或連通性不足以產生新最終化時，安全性仍可能完好。
- **L1 最終性會完成每一個 L2 或橋動作。** 資料推導、有效性或欺詐證明、挑戰期與目標鏈執行會增加不同的時鐘和故障路徑。

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

## 相關主題

- [區塊確認](/zh-tw/crypto/block-confirmation/)
- [鏈重組](/zh-tw/crypto/chain-reorg/)
- [共識機制](/zh-tw/crypto/consensus-mechanism/)
- [分叉選擇規則](/zh-tw/crypto/fork-choice-rule/)
- [弱主觀性](/zh-tw/crypto/weak-subjectivity/)

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

## 資料來源

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

Source: https://wiki.fcontext.com/zh-tw/crypto/finality/index.mdx
