Validium DAC 風險：資料可用性委員會如何決定資產可退出性

Validium 的便宜，來自把資料可用性移出鏈上

Validium 的安全敘事經常被一句話簡化：計算用 ZK proof 保證，資料由資料可用性委員會（Data Availability Committee / DAC）儲存，因此比 Rollup 更便宜。這個說法沒有錯，但它省略了最關鍵的工程事實：只要交易資料不完整，使用者就可能無法重建狀態路徑，也就無法生成退出、退款或清算所需的證明。ZK proof 保證的是狀態轉移有效，不保證使用者在故障時一定拿得到 witness。

對 [AllSwap 跨鏈交換](/exchange-swap) 這類無託管路由入口，Validium 的風險不在“平時能不能到帳”，而在異常路徑。若目標 Validium 的 DAC 停止提供資料、部分成員合謀隱匿資料、或委員會簽名流程與鏈上狀態根脫節，跨鏈交換失敗後可能出現一種很難處理的狀態：使用者或 Solver 知道資產理論上存在，但拿不到證明材料，無法觸發逃生、退款或再平衡。

本文討論的是 Validium/DAC 的協議邊界，不把所有 ZK L2 都歸為同一類。Rollup 把足夠的狀態資料釋出到 L1 或 DA 層，外部觀察者可以重建狀態；Validium 把資料放到鏈下委員會或服務中，用簽名、承諾和經濟約束證明“資料可用”。這降低成本，也把資產可退出性從純鏈上可驗證性改成了“鏈上 proof + 鏈下資料可用性”的複合假設。

系統模型：ZK 證明不等於資料可恢復

一個簡化 Validium 系統包含五個角色：

- 排序器 `Seq`：收集交易並生成批次； - 證明者 `P`：為批次狀態轉移生成 ZK proof； - DAC 成員集合 `D = {d_1, ... d_n}`：接收批次資料並簽署可用性承諾； - L1 驗證合約 `V`：驗證 ZK proof、狀態根和 DAC 簽名； - 使用者或 Solver `U`：需要在故障時重建賬戶 leaf、Merkle path 或 UTXO opening。

典型批次提交可以寫成：

`Batch = (oldRoot, newRoot, txDataCommitment, zkProof, dacCertificate)`

L1 合約驗證：

`VerifyZK(oldRoot, newRoot, publicInputs, zkProof) = true`

`VerifyDAC(txDataCommitment, dacCertificate, threshold) = true`

這裡的關鍵是第二個條件的語義。`dacCertificate` 只表示足夠多 DAC 成員聲稱自己收到了與 `txDataCommitment` 對應的資料，或承諾該資料可被提供。它不是資料本身，也不自動保證每個使用者都能在災難時拿到自己需要的 witness。

最小安全目標應寫成：

`available(data) -> reconstruct(stateWitness) -> exitOrRefund(user)`

如果第一步失敗，後面兩個步驟都可能失效。Validium 的風險不是“ZK proof 會不會錯”，而是“在 proof 正確的前提下，資料是否仍然可恢復”。這類風險對跨鏈交易尤其尖銳，因為使用者資產可能已經在來源鏈鎖定，目標鏈狀態卻無法被外部獨立重建。

DAC 簽名是可用性承諾，不是完整複製證明

DAC 常見實現會讓委員會成員接收批次資料，對資料雜湊、批次編號、狀態根或資料可用性訊息進行簽名。若至少 `t` 個成員簽名，L1 合約接受該批次為“資料可用”。如果使用 BLS 聚合簽名，鏈上驗證成本可以較低；如果使用普通多籤，驗證邏輯更簡單但證明體積更大。

可以把 DAC 證書抽象為：

`cert = AggregateSign(D_subset, H(chainId, batchId, oldRoot, newRoot, dataCommitment))`

安全邊界來自閾值關係。若 `n` 為委員會總數，`t` 為鏈上接受閾值，攻擊者控制或迫使離線的成員數達到 `n - t + 1` 時，系統可能失去可用性；若攻擊者控制至少 `t` 個成員，則可能簽署“資料可用”但事後拒絕提供完整資料。不同專案會在效能、組織可信度、法律約束和鏈上成本之間選擇不同閾值，但工程上不能把 DAC 等同於去中心化 DA 層。

更嚴格的設計會要求成員不僅籤雜湊，還要能對外提供分片、糾刪碼片段或資料可用性證明。但這裡仍有細節。成員簽名說明它在某一時刻拿到了資料，不說明它未來不會丟失；糾刪碼提高恢復機率，不說明網路一定能找到足夠片段；懲罰機制能約束成員，不代表使用者在當下能完成退款。

因此，DAC 風險至少有三層：

- 誠實可用性：成員誠實儲存並按需提供資料； - 協議可驗證性：外部能驗證成員確實承諾過某批資料； - 危機可恢復性：在停機、審查、法律壓力或網路分割槽下，使用者仍能拿到足夠 witness。

只有第三層成立，跨鏈失敗路徑才真正可用。

還要區分“閾值足夠”和“成員獨立”。如果 7 個 DAC 成員中 5 個簽名即可接受，表面看需要多數合謀才會出問題；但如果這些成員使用同一雲服務、同一金鑰託管商、同一運維團隊或處在同一司法轄區，真實相關故障機率會明顯上升。對路由器而言，`n` 和 `t` 只是最低引數，還需要成員相關性、歷史線上率、響應延遲和資料下載成功率。一個 10 人委員會若實際由兩套基礎設施支撐，不能按 10 個獨立實體建模。

閾值選擇也不是越高越好。高閾值降低少數成員偽造可用性承諾的機率，但會降低活性：只要足夠多成員離線，合法批次也無法提交。低閾值提升批次提交成功率，卻擴大合謀或被迫簽名的風險。Validium 的 DAC 是典型的安全性和活性折中，不是單向最佳化問題。對大額跨鏈路徑，AllSwap 更關心的是“在壓力條件下能否恢復 witness”，而不僅是平時批次能否快速提交。

資料 withholding 攻擊破壞的是退出能力

資料 withholding 攻擊不需要偽造 ZK proof。攻擊者可以讓狀態轉移仍然有效，但讓外部使用者無法獲得重建狀態所需的資料。對 Validium 來說，這會產生一種危險的“數學正確但不可恢復”狀態。

假設某批次從 `root_i` 轉到 `root_{i+1}`，ZK proof 有效，DAC 證書也被 L1 接受。隨後 DAC 停止提供對應交易資料或狀態差分。使用者 Alice 想證明自己在 `root_{i+1}` 下擁有 100 USDC，但她沒有賬戶 leaf、路徑節點、nonce 或 note opening。L1 合約即使有逃生函式，也只能驗證提交上來的 proof；它不能憑空生成 Alice 的 Merkle path。

攻擊收益可以用風險邊界表示：

`loss <= lockedValue(validium) - slashableStake(DAC) - recoveryCost`

如果 DAC 成員沒有足夠可削減質押，或法律/商業信譽懲罰弱於可控制資產價值，純經濟約束就不足。即使存在懲罰，使用者仍可能面對時間風險：等懲罰執行、等治理仲裁、等資料恢復服務上線，和即時退款完全不是一回事。

對無託管跨鏈交換，資料 withholding 的影響通常不是單點損失，而是狀態懸掛。來源鏈資金可能已鎖定，目標鏈付款可能未完成，Solver 的再平衡可能被卡住，路由器無法證明到底是未付款、已付款不可證明，還是可退款視窗尚未到達。若產品把這幾類狀態都顯示成“處理中”，使用者無法採取正確動作。

Proof of Data Possession 只能證明“某時持有”，不能保證“永遠可取”

選題中提到的“資料持有量零知識證明（ZK Proof of Data Possession）”方向很有價值，但不能被神化。PDP、PoR 或類似證明可以讓 DAC 成員週期性證明自己仍持有某些資料片段，甚至在不洩露全部資料的情況下證明儲存完整性。它能提高可審計性，卻不能單獨解決可用性。

原因有三個。

第一，抽樣覆蓋問題。若證明只抽樣部分片段，成員可能在抽樣視窗外丟失或隱藏未被抽中的資料。提高抽樣率會增加頻寬和計算成本。

第二，線上響應問題。成員能在某個證明週期內響應，不代表使用者在突發停機時能低延遲獲得資料。跨鏈退款通常有截止時間，證明週期過長會削弱實用性。

第三，服務路徑問題。證明成員持有資料，不等於使用者錢包、索引器或路由器有許可權、有頻寬、有 API 可靠性去下載資料。資料可用性不僅是“有人存著”，還包括“需要的人能拿到”。

更實用的模型是把 PoDP 當成 DAC 健康訊號，而不是最終安全根。路由器可以把最近證明缺失、響應延遲、分片恢復失敗率和成員離線率轉化為路徑風險分數。對大額跨鏈交易，若 DAC 健康度下降，路由應降低限額、提高風險溢價，或直接避開該 Validium。

資料服務路徑也應被納入狀態機。一個可操作的 Validium 退出系統不應假設使用者自己會執行完整索引器，而應提供至少三類獨立路徑：DAC 成員直接下載、第三方歸檔節點下載、錢包或路由器快取關鍵 witness。三條路徑的信任模型不同。DAC 直接下載最快，但最容易受同一故障影響；歸檔節點更獨立，但需要持續同步和校驗；錢包快取最貼近使用者，但儲存壓力和隱私風險更高。沒有多路徑恢復，PoDP 只能證明“有人曾經存著”，不能保證“使用者現在拿得到”。

可以把 witness 恢復成功率粗略寫成：

`P(recover) = 1 - product_i(1 - p_i)`

這裡 `p_i` 是第 `i` 條獨立恢復路徑在給定時間視窗內成功提供資料的機率。若路徑並不獨立，例如同一 API 後端同時服務 DAC 下載和歸檔下載，上式會高估安全性。嚴肅的路由風控應把相關故障折扣進去，而不是簡單把多個入口計為多個獨立來源。

從 Validium 降級到 Rollup，不是開關那麼簡單

“緊急降級到 Rollup”聽起來像完美方案：平時用 Validium 省成本，出事時把資料發上鏈，恢復 Rollup 級別的資料可用性。工程上它更接近一臺高速行駛的機器換軌。

降級狀態機至少要處理四個階段：

- `validiumMode`：批次由 ZK proof + DAC 證書接受； - `degradedDA`：檢測到 DAC 響應異常，新批次受限； - `rollupFallback`：後續批次必須把完整資料或足夠狀態差分發布到鏈上； - `withdrawOnly`：若歷史資料不可恢復，只允許使用者基於最後可恢復狀態退出。

難點在歷史資料。切到 Rollup 只能保證未來批次的資料上鍊，不能自動恢復過去已丟失的 Validium 批次。如果丟失發生在 `root_k`，系統必須定義最後可恢復 root，明確哪些使用者可以從該 root 退出，哪些後續交易需要回滾、仲裁或作廢。

還有成本突變。Validium 之所以便宜，正是因為不上鍊釋出完整資料；降級到 Rollup 後，鏈上資料成本會突然上升。若系統在壓力期才降級，L1 gas 可能同步上升，使用者退出、Solver 再平衡和批次提交會相互競爭區塊空間。

因此，降級機制必須提前寫進協議，而不是事故後由治理臨時決定。觸發條件、批次限制、最後可恢復 root、使用者退出視窗、DAC 懲罰和 Solver 結算規則，都應是可驗證狀態機的一部分。

還有一個經常被忽略的問題：降級期間是否允許新訂單。若系統進入 `degradedDA` 後仍接受普通跨鏈交換，使用者可能在風險已經可觀測時繼續把資產送入弱可用性路徑。更保守的策略是把新訂單分層處理：小額訂單允許但提高風險提示和費用；大額訂單暫停；已經鎖定但未填單的訂單優先進入退款；已經填單的 Solver 索賠進入單獨批次驗證。這樣降級不會直接變成全站停機，也不會把新風險繼續堆到不可恢復的狀態根之後。

對於 Solver，降級規則尤其重要。Solver 在目標 Validium 墊付資產時，實際承擔的是兩類風險：使用者訂單風險和 DAC 資料恢復風險。前者可以透過訂單約束、截止時間和目標鏈交易證明管理；後者必須靠路徑限額、保證金折扣和 fallback 規則管理。如果 DAC 健康狀態下降，Solver 理性地會撤出流動性或提高報價。路由器若不把這個訊號反映給使用者，就會在 UI 上製造“報價突然變差”的假象，而真實原因是資產可退出性變差。

AllSwap 路由應把 DAC 風險顯式納入報價

AllSwap 不需要把每個 DAC 成員的簽名細節展示給使用者，但路由系統應理解 Validium 與 Rollup 的差異。兩個路徑都顯示“ZK secured”，並不代表它們的失敗恢復能力相同。

路由評分可以寫成：

`routeScore = priceScore + speedScore - daTrustPenalty - witnessRisk - exitUncertainty`

其中 `daTrustPenalty` 來自 DAC 閾值、成員數量、獨立性和可削減約束；`witnessRisk` 來自使用者或第三方能否恢復狀態 witness；`exitUncertainty` 來自逃生路徑、退款視窗和最後可恢復 root 的清晰度。

對於 [/fees](/fees)，這意味著便宜路徑應標註它便宜的原因：是 gas 更低、流動性更深，還是因為資料可用性假設更強。對於 [/swap/usdt-erc20](/swap/usdt-erc20) 和 [/assets/usdc](/assets/usdc) 這類穩定幣路徑，大額交易尤其需要區分 Rollup、Validium、Volition 與普通橋。低費用並不總是最優，尤其當失敗恢復要依賴少數 DAC 成員時。

後臺狀態也要更細。跨鏈交易不應只有 `pending` 和 `failed`，還應區分 `dacHealthy`、`dacDelayed`、`witnessUnavailable`、`fallbackMode`、`refundAvailable`、`exitProofRequired`。當路徑進入 DAC 風險狀態時，產品應主動降低限額或暫停新訂單，而不是繼續接受交易後再讓使用者承擔不可恢復風險。

更進一步，AllSwap 可以把 DA 模式作為路由能力描述，而不是營銷標籤。一個路徑的 `daProfile` 至少應包含：資料釋出位置、DAC 閾值、成員數量、最近響應視窗、是否有第三方歸檔、是否支援使用者自助 witness 下載、是否定義 Rollup fallback、是否有 withdraw-only 模式。這樣使用者不需要理解 Validium 的全部細節，但路由器能把不同 DA 假設轉化成報價、限額和恢復指引。對無託管產品來說，風險透明不是附加說明，而是失敗時能否保護使用者資產的核心功能。

監控訊號也應可執行。若連續多個批次缺少外部歸檔確認，或 DAC 成員響應時間超過閾值，路由器應自動降低該路徑額度；若 witness 下載失敗率上升，應停止承諾即時退款；若 fallback 已觸發，應只展示可證明恢復動作。否則監控只會變成後臺告警，不能真正保護交易。

這類規則越早自動化，異常時越少依賴人工判斷。 否則風險會在使用者最需要確定性時才集中暴露。

仍未解決的問題

第一，DAC 獨立性難以量化。成員數量不等於獨立性。如果多個成員共享雲服務、法律轄區、運營商或金鑰管理供應商，實際相關故障機率會遠高於表面閾值。

第二，資料證明和資料服務之間缺少標準介面。成員可以證明自己持有資料，但使用者錢包和路由器仍需要穩定下載、驗證、快取 witness 的路徑。

第三，懲罰機制和使用者恢復之間存在時間差。即使 DAC 成員最終被罰，使用者資產可能已經在跨鏈交換中卡住數小時或數天。懲罰不能替代即時恢復。

第四，Validium、Volition、Rollup 的風險標籤缺少統一機器可讀格式。聚合器需要 `daCapabilities`：資料模式、DAC 閾值、成員後設資料、最近響應、可恢復 root、fallback 規則和退出視窗。

第五，跨鏈 Solver 的風險敞口仍難定價。Solver 可能願意在 Rollup 路徑墊付資產，卻不願在 DAC 健康度下降的 Validium 路徑承擔相同庫存風險。路由器需要把這種差異反映到報價、限額和失敗狀態中。

References

[1] Validium, Ethereum.org, 2026, https://ethereum.org/en/developers/docs/scaling/validium/

[2] Data Availability, Ethereum.org, 2026, https://ethereum.org/en/developers/docs/data-availability/

[3] StarkEx Data Availability, StarkWare Docs, 2026, https://docs.starkware.co/starkex/con_data_availability.html

[4] StarkEx Validium and Data Availability Committee, StarkWare Docs, 2026, https://docs.starkware.co/starkex/overview.html

[5] L2BEAT Scaling Summary and Risk Framework, L2BEAT, 2026, https://l2beat.com/scaling/summary

[6] Rollup, Validium, Volition: Where is Your Data Stored?, StarkWare, 2020, https://starkware.co/blog/rollup-validium-volition-where-is-your-data-stored/

[7] Rollups, Validiums, and Disconnected Exits, Vitalik Buterin, 2021, https://vitalik.eth.limo/general/2021/01/05/rollup.html

[8] Polygon CDK Validium Documentation, Polygon, 2026, https://docs.polygon.technology/cdk/concepts/validium/

[9] Celestia Data Availability, Celestia Docs, 2026, https://docs.celestia.org/learn/celestia-101/data-availability/

[10] EigenDA Overview, EigenDA Docs, 2026, https://layr-labs.github.io/eigenda/