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/