ZK-Rollup 詳解：zkSync、StarkNet、Scroll
ZK-Rollup 在鏈外批次執行交易，再把狀態資料與有效性證明提交到以太坊。ZKsync、Starknet 和 Scroll 都採用該思路，但執行環境、證明系統和 EVM 相容路線不同。
項目方目前的寫法通常為 ZKsync 和 Starknet，舊資料常寫作 zkSync 與 StarkNet。名稱變化不影響基本分類，但閱讀技術文件時應確認資料日期和所描述的協議版本。
ZK-Rollup 如何證明交易有效？
ZK-Rollup 的證明器把一批交易的執行過程轉換為密碼學證明。以太坊上的驗證合約不必重新執行批次中的每一筆交易，只需驗證證明和公開輸入，即可判斷新狀態是否由協議允許的狀態轉換產生。
典型流程包括：
- 排序器接收交易並形成 L2 區塊或批次。
- 執行環境計算帳戶、合約儲存和訊息的狀態變化。
- 證明器根據執行軌跡產生證明，多個區塊的證明還可以聚合。
- 批次資料或狀態差異發布到以太坊，以便其他節點恢復 L2 狀態。
- L1 驗證合約檢查證明，接受通過驗證的新狀態承諾。
證明產生可能晚於使用者看到的 L2 確認。應用顯示「成功」通常表示交易已被排序和執行，不一定表示證明已在以太坊驗證。
有效性證明與資料可用性為什麼要分開看？
有效性證明回答「狀態計算是否符合規則」，資料可用性回答「其他人能否取得足夠資料重建狀態」。兩者解決的是不同問題。
Rollup 把恢復狀態所需的資料發布到以太坊。Validium 也可以使用有效性證明，卻把資料放到外部網路或委員會。後者能進一步降低 L1 資料費用，但當外部資料不可用時，使用者可能難以重建狀態或完成退出。
因此，「使用 ZK 證明」不能單獨證明一條鏈擁有 Rollup 的完整安全屬性。還要查看該具體網路的資料發布模式、升級權限和退出機制。
ZKsync、Starknet 和 Scroll 有什麼區別？
三者都讓以太坊驗證批次狀態，但選擇了不同的執行與開發路線。
| 比較項 | ZKsync | Starknet | Scroll |
|---|---|---|---|
| 核心定位 | 以 ZK Stack 構建 Rollup 與可配置鏈網路 | 使用 STARK 證明和 Cairo 執行環境的有效性 Rollup | 面向以太坊相容應用的 zkEVM Rollup |
| 執行環境 | Era 路線包含為證明最佳化的 EraVM，目前協議文件也描述面向 EVM 的執行環境演進 | 原生使用 Cairo 與帳戶合約模型，不是直接複製 EVM | 重點證明 EVM 狀態轉換，開發體驗接近以太坊 |
| L1 資料 | Rollup 模式把壓縮狀態差異等資料發布到以太坊 | 把壓縮狀態差異發布到以太坊，可使用 Blob | 排序層向以太坊發布批次資料，結算層驗證證明 |
| 證明特點 | 證明器驗證批次狀態轉換，協議正在向新的 ZKsync OS 架構演進 | 使用 STARK 系證明，並透過聚合降低 L1 驗證負擔 | 證明電路約束 EVM 執行結果，由以太坊合約驗證 |
| 開發遷移 | Solidity 工具可用，但特殊 VM、系統合約和編譯路徑仍需測試 | 通常需要 Cairo、Starknet 帳戶與工具鏈知識 | Solidity 應用遷移阻力較低，仍需測試預編譯和系統差異 |
這裡的「相容」不能只寫成是或否。錢包 RPC、Solidity 編譯、位元組碼、操作碼、Gas 計量和除錯工具分別屬於不同層次。即使合約能部署，依賴底層區塊欄位、預編譯或精確 Gas 行為的應用仍要重新驗證。
ZK-Rollup 是否一定比 Optimistic Rollup 更快？
要先說明比較的是哪種速度。ZK-Rollup 在證明被 L1 驗證後，不需要再等待故障挑戰期來確認同一狀態，這通常有利於協議原生退出。可是證明產生、聚合和提交本身也需要時間。
使用者看到的互動速度主要由排序器出塊和應用確認策略決定。兩條不同路線都可能提供快速 L2 確認。若比較最終結算，應查看批次發布頻率、證明延遲和以太坊確認，而不是只看錢包動畫。
ZK-Rollup 的主要限制是什麼？
| 限制 | 實際影響 |
|---|---|
| 證明複雜度 | 證明器需要專門硬體和軟體，故障可能延遲證明但不一定回滾已排序交易 |
| 電路覆蓋 | 只有被電路或可證明執行環境約束的邏輯才獲得有效性保證 |
| 升級權限 | 管理者可能更新驗證合約、橋或系統配置，改變原有假設 |
| 排序集中 | 單一排序器仍可能延遲或審查交易，證明不能自動解決交易排序問題 |
| 生態差異 | 錢包、預言機、橋和應用深度可能與以太坊主網不同 |
此外，ZK-Rollup 的「零知識」常被誤讀為隱私。擴容型有效性證明可以在不隱藏地址、金額和合約呼叫的情況下運作，公開區塊瀏覽器仍可能展示完整交易活動。
使用三條網路前怎樣核對？
先從應用支援的具體網路出發，而不是先選證明名詞。確認官方 RPC、鏈 ID、瀏覽器、Gas 資產和標準橋，再檢查目標代幣是原生發行還是橋接版本。
對於合約應用，還應在目標執行環境實測部署、呼叫、事件索引和預言機。對於資產使用者，則要核對 L2 內確認、證明狀態和退出到 L1 的不同等待階段。
若要比較另一類驗證方式，可閱讀Optimistic Rollup：Arbitrum 與 Optimism；完整分類見Layer2 擴容方案全景解讀。ZK 證明在身分、隱私和跨鏈等方向的應用，可延伸查看Web3 前沿賽道與趨勢。
常見問題
ZK-Rollup 會隱藏轉帳金額和地址嗎？
不會自動隱藏。有效性證明可以只用於證明公開交易的計算正確。是否具有隱私，要看協議是否專門設計隱藏狀態、加密資料和查看權限。
有效性證明能保證某個 DeFi 應用沒有漏洞嗎？
不能。證明保證的是 L2 按既定執行規則處理交易。應用合約若本身存在權限、預言機或經濟設計問題，仍會按錯誤邏輯正確執行。
所有 ZK-Rollup 都需要可信設置嗎？
不一定。不同 SNARK、STARK 和遞迴證明系統的參數產生方式不同，有些需要多方儀式，有些強調透明設置。應查看具體證明系統，不能從「ZK」三個字推斷。
為什麼 L2 瀏覽器顯示成功，以太坊上還找不到對應證明？
排序器可以先執行並確認交易，證明器隨後才把多個區塊聚合成證明提交 L1。兩個瀏覽器觀察的是不同階段，延遲不一定表示交易失敗。
推薦閱讀
看更多
