Danksharding 提出者为何 diss 以太坊之外的 DA 层？

撰文：Faust，极客 web3

导语：近日，Danksharding 的提出者、以太坊基金会的研究员Dankrad Feist在推特上发表了一番颇具争议的言论。他明确指出，不采用 ETH 作 DA 层（数据可用性层）的模块化区块链不是 Rollup，同时也不是以太坊 Layer2。如果按照 Dankrad 的说法，Arbitrum Nova 和 Immutable X、Mantle 都要从 Layer2 名单里「除名」，因为它们只在 ETH 之外（自己构建了名为 DAC 的链下 DA 网络）披露交易数据。

同时，Dankrad 还表示，像 Plasmas 和状态通道这种不需要链上数据可用性（Data Availability）来确保安全的方案仍算是 Layer2，但Validium（不用 ETH 作 DA 层的 ZKRollup）不算 Layer2。

Dankrad 此言一出，便引来了诸多 Rollup 领域的 Founder 或 Researcher 质疑。毕竟有许多「Layer2」项目为了节约成本，并没有采用 ETH 作为 DA( 数据可用性 ) 层，如果把这些项目踢出 L2 名单，必然波及到相当多的扩容网络；同时，如果 validium 不算 L2，Plasma 应该也没资格算作 L2。

对此，Dankrad 表示，Plasma 用户在 DA 不可用时（就是指链下的 DA 层网络搞数据扣留，不公开交易数据），仍然可以把自己的资产安全撤出至 L1；但相同的情况下，Validium（大多数采用 StarkEx 方案的项目都是 validium）却可以让用户无法撤资至 L1，把钱冻住。

显然，Dankrad 打算从「是否安全」来界定一个扩容项目是否为以太坊 Layer2。如果从「安全性」的角度来考量，Validium 在定序器故障 + DA 层发动数据扣留攻击 ( 隐瞒新数据 ) 的极端情况下，的确可以把用户资产冻结在 L2 无法提到 L1；Plasma 因在设计上与 Validium 不同，虽然多数时候安全保障不及 Validium，但在定序器故障 + DA 层发动数据扣留攻击 ( 隐瞒新数据 ) 时，却允许用户把资产安全撤离至 L1。所以 Dankrad 的说辞不无道理。

本文打算从 Dankrad 的视角出发，通过对 Layer2 的细节作进一步分析，来深入理解为何 Validium 不是严格意义上的「Layer2」。

到底怎么定义 Layer2？

按照 ethereum.org 网站和多数以太坊社区成员的定义，Layer2 是「给以太坊扩容 + 继承以太坊安全性 的独立区块链」。首先，「给以太坊扩容」就是指分流以太坊无法承载的流量，分担 TPS 方面的压力。而「继承以太坊安全性」，其实可以转译为「借助以太坊保障自身安全性」。

比如，Layer2 上所有的交易 Tx 都要在 ETH 上完成最终结算 Finalize，数据有错误的 Tx 不会被放行；如果要回滚 Layer2 的区块，要先回滚以太坊区块，只要以太坊主网不发生类似 51% 攻击的区块回滚，L2 区块就不会回滚。

如果我们更进一步探讨 Layer2 的安全性，其实还要考虑许多极端情况。比如，如果 L2 项目方跑路、定序器 Sequencer 故障、链下 DA 层挂掉，在这些极端事件发生时，用户能否把自己在 L2 上的资金安全撤出到 L1 上？

Layer2 的「强制提款」机制

不考虑 L2 合约升级 / 多签隐患等因素，其实如Arbitrum 或 StarkEx 都有为用户设置强制提款的出口。假设 L2 的定序器发动审查攻击，故意拒绝用户的交易 / 提款请求，或干脆永久宕机，Arbitrum 用户可以调用 L1 上 Sequencer Inbox 合约的 force Inclusion 函数，将交易数据直接提交至 L1；如果在 24 小时内，定序器没有处理这笔需要「强制包含」的交易 / 提款，该交易会被直接包含进 Rollup 账本的交易序列中，这就为 L2 用户创造了一个可强制提款的「安全出口」。

相比之下，有逃生舱 Escape Hetch 机制的 StarkEx方案要有过之无不及。如果 L2 用户在 L1 提交的 Forced Withdrawal 请求在 7 天窗口期结束时，未得到定序器响应，则该用户可以调用 freeze Request 功能让 L2 进入冻结期。此时，L2 定序器将无法在 L1 上更新 L2 的状态，L2 状态冻结后要过 1 年才能解冻。

L2 状态冻结后，用户可以构造与当前状态相关的 Merkle Proof，证明自己在 L2 上有 XX 数额的资金，通过 L1 上的逃生舱 Escape Hetch 相关合约来提款。这便是 StarkEx 方案所提供的「全额提款」服务。即便 L2 项目方没了，定序器永久故障了，用户还是有办法把资金撤出 L2。

但这里存在一个问题：用 StarkEx 方案的 L2 大多是 Validium（比如 Immutable X 和 ApeX），并不会把 DA 所需的数据发布到 ETH，构造当前 L2 状态树的信息都存在链下。如果用户无法在链下获取构造 Merkle Proof 的数据（比如链下 DA 层发动数据扣留攻击），是无法通过逃生舱来提款的。

至此，文章开头提到的 Dankrad 认为 Validium 不安全的原因，其实很明确了：因为 Validium 不像 Rollup 一样把 DA 的数据发到链上，所以用户可能无法构造出「强制提款」所需的 Merkle Proof。

Validium 和 Plasma 在发生数据扣留攻击时的区别

事实上，Validium 的定序器只在 L1 链上发布 L2 最新的 Stateroot（状态树的根），再提交一个 Validity Proof（ZK Proof），证明新的 Stateroot 生成过程涉及的状态转换（用户资金变化），都是正确的。

（图源：eckoDAO）

但单凭 stateroot 无法还原出此刻的状态树 world state trie，也就无法知晓每个 L2 账户的具体状态（包含资金余额），L2 用户就无法构造对应当前合法 Stateroot 的 Merkle Proof。这便是 Validium 不利的地方。

（Merkle Proof 其实就是 root 生成过程中所需的数据，也就是图中暗色的部分。要构造对应 Stateroot 的 Merkle Proof，必须要知道状态树的构造，需要有 DA 数据）

这里必须要强调下 DAC 这个东西。Validium 的 DA 所涉数据，比如定序器最新处理的一批交易，会同步给名为数据可用性委员会 DAC（Data Availability Committee）的 L2 专属 DA 网络，DAC 由多台节点服务器构成，一般由 L2 官方和社区成员或其他单位负责运行和监督（但这只是表面上的，实际上 DAC 成员都有谁，外界很难查证）。

有意思的地方在于，Validium 的 DAC 成员需要频繁在 L1 提交多签，证明 L2 定序器在 L1 提交的新 Stateroot 和 Validity Proof，与 DAC 同步到的 DA 数据能对上号。DAC 的多签提交后，新的 Stateroot 和 Validity Proof 才会被认为是合法的。

目前 Immutable X 的 DAC 采用 5/7 多签，dYdX 虽然是 ZKRollup，但也有 DAC，用的是 1/2 多签。（dYdX 只在 L1 发布 State diff 即状态变化，而非完整交易数据。但获取了历史记录里的 State diff，就可以还原全部 L2 地址的资产余额，此时就可以构造 Merkle Proof 来全额提款）。

Dankrad 的观点不无道理。Validium 的 DAC 成员如果合谋，发起数据扣留攻击，不让其他 L2 节点同步此刻的最新数据，并且更新此刻 L2 的合法 Stateroot，用户无法构造此刻合法 root 对应的 Merkle Proof 来提款（因为此刻往后的 DA 数据不可用了，可用的是以前的 DA 数据）。

但 Dankrad 考虑的只是理论上的极端情况，现实中大多数 Validium 定序器都会实时的把新处理的交易数据广播给其他 L2 节点，其中不乏诚实节点。只要有 1 个诚实节点能够及时获取 DA 数据，用户就可以从 L2 全身而退。

可理论上存在于 Validium 身上的问题，为何不存在于 Plasma 身上？这是因为Plasma 判定合法 Stateroot 的方式，和 Validium 不同，有欺诈证明窗口期的缘故。Plasma 是 OPRollup 之前的 L2 扩容方案，与 OPR 一样靠欺诈证明保证 L2 的安全。

Plasma 与 OPR 一样有窗口期的设定，定序器发布的新 stateroot 不会立刻判定为合法，要等窗口期 close 且没有 L2 节点发布欺诈证明。所以 Plasma 和 OPR 的当前合法 Stateroot，都是几天以前提交的（这就好比我们看到的星光，其实都是很久以前发出的），而用户往往可以获取过去时刻的 DA 数据。

同时，欺诈证明机制能在此刻生效的前提，是此刻 L2 的 DA 可用，也即 Plasma 的 Verifier 节点可以获取此刻的 DA 所涉数据，这样才能生成此刻的欺诈证明 ( 如果有必要的话）。

那么一切都很简单了：Plasma 正常工作的前提是此刻 L2 的 DA 数据可用。如果从此刻开始，L2 的 DA 不可用了，用户能安全撤资吗？

这个问题不难分析，假设 Plasma 的窗口期是 7 天，如果从某个时间点 T0 开始，新的 DA 数据就不可用（DAC 发动数据扣留攻击，不让诚实的 L2 节点获取 T0 往后的数据）。因为T0 及此后一段时间内的合法 Stateroot，是 T0 时刻前提交的，而 T0 时刻前的历史数据可追溯，所以用户可以构造 Merkle Proof 来强制提款。

即便很多人无法立刻察觉异常，但因为有窗口期存在（OP 是 7 天），只要 T0 时刻提交的 Stateroot 还未合法化，且 T0 之前的 DA 数据可追溯，用户就可以把钱安全撤出 L2。

总结

至此我们大致可以理清楚 Validium 和 Plasma 在安全性上的区别：

Validium 的定序器发布 Stateroot 后，只要立刻发布 Validity Proof 和 DAC 多签，就可以使其合法，成为最新的合法 Stateroot；如果用户和诚实 L2 节点遭遇数据扣留攻击，无法构造当前合法 Stateroot 对应的 Merkle Proof，就无法提款到 L1。

而 Plasma 提交新的 Stateroot 后，要等窗口期结束才能合法，此时的合法 Stateroot 是过去提交的。因为有窗口期（ARB 是 3 天，OP 是 7 天）存在，即便新提交的 Stateroot 的 DA 数据不可用，用户也有当前合法 Stateroot 的 DA 数据（合法 root 是过去提交的），有足够的时间强制提款到 L1。

所以，Dankrad 说的话有道理。当发生数据扣留攻击时，Validium 存在把用户资产困在 L2 的可能，但 Plasma 并不存在这个问题。

（下图中 Dankrad 说的有一点不对，Plasma 应该不允许构造过时的合法 Stateroot 对应的默克尔证明来提款，因为这会导致双重支付）

所以，链下 DA 层的数据扣留攻击会造成许多安全隐患，但 Celestia 尝试解决的正是这个问题。此外，因为大多数 Layer2 项目都会提供让 L2 节点与定序器保持链下同步的服务端口，所以 Dankrad 的忧虑其实往往只是理论上的，而不是现实中的。

如果我们用鸡蛋里挑骨头的态度，再提出更极端的假设：所有的 Plasma 链下节点都不可用了，那么那些没跑过 L2 节点的普通用户都无法强制提款到 L1。但这种事情发生的概率，等价于一条公链的所有节点集体永久性宕机的概率，可能永远不会发生。

所以，很多时候，大家只是在谈论一些根本就不会发生的事情。正如美剧《切尔诺贝利》里克格勃副主席对主角说的那段金句：「为何要担心根本就不会发生的事情呢？」