---
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.
# 有效性證明
> 僅供教育參考，不構成投資或安全建議。有效性證明的可靠性取決於所證明的命題、公開輸入綁定、證明系統、驗證器、資料可用路徑、合約、營運方、治理和結算鏈。
## 直接答案
有效性證明是一份密碼學證據，用來表明某項計算滿足一組精確定義的關係。驗證器依據驗證金鑰和公開輸入檢查證明。在彙總協定中，這些輸入通常綁定前狀態根、擬議的新狀態根，以及交易批次承諾。驗證成功後，結算合約可以接受新狀態根，而無須重新執行每筆交易。
這項保證比「整個系統正確」更窄。它依賴可靠的密碼學、預期程式或電路、正確的公開輸入編碼、真實的驗證金鑰，以及正確的驗證器與狀態更新合約。僅憑驗證成功，無法證明使用者能取得底層資料、證明者會持續在線、結算區塊已經最終確定、升級沒有惡意，或提款路徑確實可用。有效性證明可以採用零知識證明系統，但「有效性」本身不代表隱私。
## 運作方式
1. 鎖定確切部署：L1 與 L2 鏈 ID、彙總協定版本、狀態更新合約、驗證器位址與位元組碼、驗證金鑰雜湊、證明系統、電路或程式版本、資料可用模式、管理員權限、暫停狀態和結算最終性政策。`validity proof` 不是跨系統的統一規格。
2. 解讀結果之前，先定義被證明的關係。簡寫為：在證明系統可靠性假設成立時，`Verify(vk, x, proof) = 1` 應當意味著存在見證 `w`，使 `R(x, w) = 1`。其中 `vk` 是驗證金鑰，`x` 是完整公開輸入，`R` 是編碼後的規則集。證明只涵蓋這項關係。
3. 獨立重建公開輸入。確認前狀態根正是合約已接受的狀態根；從規範資料推導批次或資料承諾、鏈與批次識別碼、後狀態根、訊息或提款根及協定參數。綁定至錯誤鏈、狀態根、程式或批次的有效證明，只是對錯誤命題有效。
4. 核驗證明和合約路徑。執行相容的獨立驗證器，再檢查鏈上呼叫、收據、事件、已接受批次編號和儲存變更。確認狀態更新合約呼叫預期驗證器，且沒有透過升級或特權分支繞過、模擬或替換驗證結果。
5. 分開核驗資料可用性。取得協定要求的交易資料、狀態差異、blob sidecar 或委員會證明的資料；核對其承諾，並重現狀態轉換或退出見證。證明有效與資料不可用可以同時發生，尤其是 validium 或外部委員會把資料保存在鏈下時。
6. 分別追蹤生命週期狀態：已產生、已提交、已納入、證明已驗證、狀態已接受、結算安全、結算最終確定和提款完成。衡量證明積壓與成本、排序器和證明者活躍性、L1 納入、鏈重組、跨鏈橋延遲、強制納入和逃生程序，不能把所有狀態都稱作「最終」。
7. 保存可重現證據：合約位址與程式碼雜湊、驗證金鑰與程式雜湊、完整公開輸入、證明位元組或持久引用、批次資料、驗證指令與軟體版本、交易收據、最終確定區塊引用和成功退出測試。每次升級後都要重新核驗。
## 算例
- **批次命題。** 某彙總協定處理 `8,192 transfers`。證明綁定舊狀態根 `R0`、新狀態根 `R1` 和批次承諾 `B7`。驗證成功支援的命題是：「存在滿足該電路、針對 `B7` 從 `R0` 轉換至 `R1` 的見證。」它不能證明 `B7` 的位元組可取得、排序器納入每筆已提交交易，或 `R1` 已經最終確定。
- **遞迴彙整。** 彙整器在一個父電路內驗證 `16 child proofs`，再提交一個父證明。父證明通過時，驗證器接受彙整關係及其綁定的子證明承諾。稽核者仍須確認父電路檢查每個子證明、順序和公開輸入映射；證明數量本身不能建立這種綁定。
- **假設 Gas 帳本。** 假設直接重新執行需要 `24,000,000 gas`，證明驗證需要 `600,000 gas`，所需資料發布需要 `180,000 gas`。證明路徑合計 `600,000 + 180,000 = 780,000 gas`，模型中的降幅為 `(24,000,000 - 780,000) / 24,000,000 = 96.75%`。這裡不含證明硬體、彙整、失敗提交、儲存、跨鏈橋操作和資料留存成本。
## 風險
- 核驗錯誤的鏈、部署、批次、驗證器、驗證金鑰或電路版本。
- 可靠的證明系統忠實證明不完整或錯誤的電路。
- 公開輸入遺漏或錯誤編碼鏈 ID、狀態根、批次、訊息域或協定參數。
- 驗證器、預編譯合約、不安全函式庫或不相容實作存在缺陷。
- 初始化材料遭竊或密碼學假設失效。
- 可升級合約或治理替換驗證器、金鑰、程式或接受規則。
- 特權繞過、緊急模式、暫停或允許清單削弱公開宣稱的路徑。
- 證明產生缺陷、非確定性或不同用戶端推導出不同見證。
- 證明者中心化、審查、停機、積壓或硬體故障使狀態更新停滯。
- 交易資料、狀態差異、blob、原像或歸檔歷史缺失。
- 把委員會簽章或資料承諾當成目前可取得資料的證明。
- 接受來自不安全、已重組或非規範結算區塊的證明交易。
- 把證明獲接受當成提款立即完成或經濟最終性。
- 未能獨立重現狀態轉換、餘額、訊息或退出見證。
- 低估驗證 Gas、資料費用、證明延遲、跨鏈橋延遲或復原成本。
- 假設一個彙總協定的證明、可用性和升級模型適用於另一部署。
## 常見誤解
- 有效性證明通過驗證，就證明所有實作細節和使用者可見餘額均正確。
- 每份有效性證明都是零知識證明，都會隱藏交易資料。
- 有效性證明消除資料可用性、排序器活躍性和審查風險。
- 證明通過驗證後，結算交易立即最終確定並可提款。
- 證明更小或驗證器更快，就一定代表系統更安全或更便宜。
## 相關主題
- [資料可用性](/zh-tw/crypto/data-availability/)
- [故障證明](/zh-tw/crypto/fraud-proof/)
- [彙總協定](/zh-tw/crypto/rollup/)
- [零知識證明](/zh-tw/crypto/zero-knowledge-proof/)
- [ZK Rollup](/zh-tw/crypto/zk-rollup/)
## 來源
- [Zero-knowledge rollups](https://ethereum.org/developers/docs/scaling/zk-rollups/) - Ethereum.org（查閱日期：2026-08-22）
- [Zero-knowledge proofs](https://ethereum.org/zero-knowledge-proofs/) - Ethereum.org（查閱日期：2026-08-22）
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals（查閱日期：2026-08-22）
- [Sequencing and verification flows](https://docs.polygon.technology/tools/zkevm/architecture/unified-LxLy/ulxly-sequence-verify) - Polygon Documentation（查閱日期：2026-08-22）
- [Data availability](https://docs.starkware.co/starkex/con_data_availability.html) - StarkEx Documentation（查閱日期：2026-08-22）
Source: https://wiki.fcontext.com/zh-tw/crypto/validity-proof/index.mdx