很多人对 DA 的理解是错误的：DA=数据发布，而不是数据可检索
作者：Faust，极客 Web3
封面：Photo by Conny Schneider on Unsplash
导语：到底什么是数据可用性？可能绝大多数人第一印象是 “可以获取某个时刻的历史数据”，但这其实是对 DA 概念最大的误解。近期 L2BEAT 联创与 Danksharding 提出者、Celestia 创始人都对这一误区做出了澄清，他们指出，Data Avalibity 实际上应该指 “数据发布”，但大多数人把 DA 理解成了 “历史数据可检索”，而后者实际上涉及到数据存储问题。
比如，前一阵子 Dankrad 曾提到了 Layer2 的强制提款/逃生舱机制，他指出，Validium 的强制提款需要获取最新的 L2 状态来构造 Merkle Proof，但 Plasma 只需要 7 天以前的（这和两者的合法 Stateroot 判定方式有关）。
借此，Dankrad 明确指出，Validium 需要 DA 保障用户资金安全，而 Plasma 不需要。在此处，Dankrad 用案例指出了 DA 和历史数据可检索的不同之处，即 DA 往往只涉及新发布的数据。
在 L2BEAT 那里，数据可用性 DA 与数据存储 DS 的区别被进一步加强。L2BEAT 的 Bartek 多次强调，DA 和数据存储/历史数据可查是两码事，而用户能够获取到自己需要的 L2 数据，只是因为那些提供数据的节点 “对你足够好”。此外，L2BEAT 还计划把 “是否有权限开放的数据存储节点” 当做 DA 之外的一个测评 Rollup 的新指标。
以太坊社区/以太坊基金会成员的上述言辞，表明了他们要在未来对 Layer2 相关概念进行规范化的梳理，并对 Layer2 本身进行更详实的定义。因为围绕着 Rollup 和 L2 的很多名词其实都没有被很好的解释清楚，比如多久前的数据算 “历史数据”——有人认为，因为智能合约只能调用 256 个 block 内的过往区块数据，所以 256 个区块（50min）前的数据都算 “历史数据”。
而 Celestia 和以太坊基金会口中的 “Rollup”，严格来说都是两种东西。本文旨在澄清 DA 概念和数据存储的区别，从 DA 的来源、数据可用性采样、Rollup 的 DA 实现方式，来为大家解释到底什么才是数据可用性——数据发布。
DA 概念的来源
关于 “数据可用性” 问题到底指什么，Celestia 创始人 Mustafa 如此解释：DA 就是，当区块生成者提出新 block 时，如何确保区块里的所有数据都发布到了网络中？如果区块生成者不 Release 区块中的所有数据，就无法检测区块里是否包含错误交易。
Mustafa 还指出，以太坊 Rollup 简单地将 L2 区块数据发布到以太坊链上，并依赖 ETH 来保障数据可用性。
而在以太坊官网，有关于 DA 的如下概括：可以把数据可用性难题概括为一个问题：“我们如何验证一个新区块的数据是否可用？”...... 对于轻客户端来说，数据可用性问题是指在无需下载整个区块的情况下，验证区块的可用性。
以太坊官网还明确区分了数据可用性与可检索性的区别：数据可用性是指区块被提出时，节点下载区块数据的能力。换句话说，数据可用性与区块尚未达成共识时相关...... 数据可检索性是指节点从区块链中检索历史信息的能力...... 虽然存档可能需要区块链历史数据，但节点无需使用历史数据就可以验证区块并处理交易。
在 Celestia 中国贡献者——W3Hitchhiker 合伙人任泓毅看来，Layer2 事先假设 Ethereum 足够安全和去中心化，排序器可以放心大胆的把 DA 数据发到以太坊，这些数据会无阻碍的传播给所有以太坊全节点。而 L2 全节点本身就要运行 Geth 客户端，算是以太坊全节点的子集，所以可以接收到 Layer2 的 DA 数据。
而在 EthStorage 的创始人 Qi Zhou 博士眼里，DA 的定义是没有人可以把用户提交到网络里的交易数据扣留住。对应的信任模型是，我们只需要信任 L1 的协议本身，不需要再引入其他信任假设。
Qi Zhou 指出，现在以太坊的 DA 实现方式其实就是 P2P 广播（gossip 流言协议），每个全节点都会下载并传播新 block，并存储 Rollup 的数据。当然，以太坊全节点并不会永久存储历史区块，在 4844 上线后可能会自动删除一段时间前的数据（貌似是 18 天）。存放全部历史数据的档案节点，现在全世界也没有多少，EthStorage 则打算填补以太坊体系的这一空白，并助力 Layer2 设置自己专属的数据永存节点。
而以太坊基金会关于数据可用性 Data availability 的早期讨论，可见于 Vitalik 在 2017 年的推文与 github 文档。当时他认为，如果要保证区块链可拓展/高效率，就要抬高全节点的硬件配置（全节点就是下载完整 block 并验证其有效性的节点，做共识的 Validator 是全节点的子集）。但如果提高全节点硬件配置，就会提升运行成本，导致区块链变得中心化。
关于这一点，Vitalik 说，可以设计一种方案，解决高性能全节点趋于中心化带来的安全隐患。他打算引入纠删码和数据随机抽样来设计一套协议，使得低配硬件的轻节点即便不获知完整的 block，也可以得知 block 没有问题。
他最开始的想法其实和比特币白皮书里提到的 idea 有关。这个 idea 说，轻节点可以不接收完整 block，而当 block 有问题时，诚实全节点会发出 “警报”，通知轻节点。这个思路可以引申到后来的欺诈证明，但不能保证诚实全节点始终可以获得足够数据，也无法事后判断区块提议者是否扣留了某些数据没发布。
比如，某个节点 A 可以发布欺诈证明，声称从节点 B 那收到了不完整的 block。但此时无法判断，这个不完整的 block 是 A 自己伪造的，还是 B 发出去的。Vitalik 指出可以用数据可用性采样 DAS 解决这个问题（显然数据可用性实质涉及数据发布问题）。
Vitalik 在"A note on data availability and erasure coding"一文中对这些问题及其解决方案进行了粗略讨论。他指出，DA 证明实质是对欺诈证明的一种 “补完”。
数据可用性采样
但显然，DA 概念不是那么好解释的，因为 Vitalik 的这篇 github 文档前前后后进行了 18 次更正。记录显示，最后一次更正提交于 2018.9.25。而就在前一天的 2018.9.24，Celestia 创始人 Mustafa 与 Vitalik 联名发表了日后声名大噪的论文——Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities.
有趣的是，这篇论文第一作者是 Mustafa 而不是 Vitalik（另一名作者现在是 Sui 公链的研究员）。文中提到了欺诈证明 Fraud Proof 的概念，并解释了数据可用性采样 DAS 的原理，粗略设计了一套 DAS +二维纠删码+欺诈证明的混搭协议。论文中则明确提到，DA 证明系统实质是欺诈证明之上的必要补充。
如果我们从 Vitalik 的视角出发的话，这套协议的作用可以概括如下：
假设一条公链有 N 个高配硬件的共识节点 Validator，它们的数据吞吐量很大，效率很高。这样的区块链虽然 TPS 高，但共识节点数量 N 比较少，是比较中心化的，节点串谋概率高。
但是，N 个共识节点中起码会有 1 个是诚实的。只要至少 1/N 的 Validator 诚实，检查出 block 无效，并愿意在必要时刻广播欺诈证明，轻节点或诚实 Validator 都能知道网络出现了安全问题，并可以通过 Slash 恶意节点、社会共识分叉等方式让网络恢复正常。
可是，就像之前 Vitalik 提到的，如果诚实全节点接收到一个 block 且发现它缺乏某些部分，并发布欺诈证明，此时不好判断出是 block 提议者没发布这部分数据，还是中途被其他节点扣留了，亦或是发布欺诈证明的节点自导自演。
此外，如果多数节点串谋，1/N 的诚实 Validator 被孤立，可能无法获取新的 block，这算是一种数据扣留攻击场景。需要注意的是，此时诚实节点不知道是网络状况不好，还是其他人串谋搞数据扣留，他也不知道其他节点是否也被孤立，不好判断多数人是否已经串谋搞数据扣留。
综上，要有一种办法，以极高概率保证诚实 Validator 能获取到验证 block 所需的数据；同时，要能判断出是谁在搞数据扣留攻击——是 block 提议者没发布足量数据，还是说被其他节点扣留了，亦或是多数节点在搞串谋。显然，这种安全模型比普通 POS 链的 “诚实多数假设” 多了很多保障，而数据可用性抽样 DAS 就是具体的实现方式。
我们现在假设，网络中轻节点很多，可能是 10 N，每个轻节点都连接了多个 Validator（为了方便分析，假设每个轻节点都连接了全部 N 个 Validator）。这些轻节点会向 Validator 多次发动数据抽样，每次随机请求一小部分数据（假设只占一个 block 的 1%）。随后，它们会把抽到的碎片传播给没有这些数据的 Validator。只要轻节点足够多，且数据抽样次数足够频繁，即便某些请求可能被拒绝，但只要大部分被响应，就可以保证所有 Validator 最终都能获取到验证 block 所需的足量数据。这样可以抵消掉 Block 提议者以外的其他节点扣留数据的影响。
而如果多数 Validator 搞串谋，拒绝响应大多数轻节点的请求，此时人们很容易意识到链出了问题（因为就算一部分人的网速不好，也不至于差到大部分轻节点的请求都被拒绝）。所以前述方案可以极高概率判断出多数串谋行为，当然这种情况本身极少发生。
到了这里，我们可以解决掉来自 Block 提议者之外的不确定性因素。如果 Block 提议者搞数据扣留，比如他没有在 block 里发布验证区块所需要的足量数据（引入二维纠删码后，一个区块里包含 2k*2k 个片段，而还原出区块的原始数据至少需要约 k*k 个片段，占 1/4。提议者想让其他人不能还原出原始数据，最少需要扣留 k+1*k+1 个片段），最终肯定会被诚实 Validator 检测出来，而后者会广播欺诈证明警告其他人。
按照 vitalik 和 mustafa 的说法，他们其实是把此前就有人提出的想法结合了起来，并在此之上做出了一定的创新。而从整个构思的出发点与实现方式来看，显然所谓的 “数据可用性” 指的是验证最新 block 所需的那些数据，是否都有被区块提议者发布出去，且能不能被验证者们接收到。这关乎 “数据是否完整发布” 而不是 “历史数据是否可以被检索到”。
以太坊 Rollup 的 DA 怎么实现
有了前面的论断，我们再来看以太坊 Rollup 的 DA 实现方式，其实就比较清晰了：Rollup 里的区块提议者就是排序器 Sequencer，它每隔一段时间就会在以太坊上发布验证 Layer2 状态转换所需要的数据。准确的说，是向指定的合约发起一笔 Transaction，在自定义的输入参数里塞进 DA 所涉及的数据，并最终被记录进以太坊区块里。由于以太坊足够去中心化，可以确信定序器提交的数据会被 “验证者” 顺利接收到。但不同 Rollup 网络中充当 “验证者” 角色的东西是不同的。
（Arbitrum 排序器向以太坊上某合约 post 的交易批次，合约本身不验证这些数据，只抛出一个事件让 L2 全节点来监听，让后者知道排序器发布了交易批次）
具体而言，ZK Rollup 采用以太坊上的 Verifier 合约充当 “验证者”。ZKR 最少只需要发布 State Diff + Validity Proof，也就是状态变化情况+有效性证明，Verifier 合约会检测有效性证明，判断它能否和 State Diff 对上号。验证通过后，定序器发布的 L2 Block/Batch 就被认作有效。
而乐观 Rollup 要在以太坊发布更多数据，因为它只能靠 L2 全节点去下载数据并验证 Block 有效性。这样的话，至少要披露 每笔 L2 交易的数字签名（现在一般用聚合签名）、如果有调用合约的话，还要披露输入参数，此外还要披露交易转账地址、防重放攻击的 Nonce 值等。但相较于完整的 Transaction data，还是有一些修剪。
相比于 ZK Rollup，乐观 Rollup 的 DA 成本更高，因为 ZK Rollup 只需要披露一批交易执行后的最终状态变化，附带一个有效性证明，利用到了 ZK SNARK/STARK 的简洁性；而乐观 Rollup 只能采用最笨重的方式，让所有交易都在其他 L2 全节点身上重新执行一遍。
此前 W3hitchhiker 曾粗略估算过，不考虑未来的 4844 和 blob，ZKR 的扩容效应可以达到 OPR 的数倍，而如果考虑到 4337 相关的智能钱包（用指纹、虹膜数据取代私钥签名），ZKR 的优势会更明显，因为它不需要把指纹、虹膜的二进制化数据 post 上以太坊，而乐观 Rollup 需要）。
至于 Validium 和 Plasma/Optimium，其实是用以太坊链下的 DA 层来实现 DA。比如，采用了有效性证明系统的 ImmutableX 自己搭建了一组 DAC 节点（数据可用性委员会），专门发布 DA 涉及的数据；Metis 则在 Memlabs 上发布 DA 数据，Rooch 和 Manta 则采用 Celestia。而目前看来，由于有 DAS 和欺诈证明系统的存在，Celestia 是以太坊之外可信度最高的 DA 层项目之一。
参考文献
1.https://coinmarketcap.com/alexandria/article/what-is-data-availability
2.https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
3.https://www.youtube.com/watch?v=xV2XVCtQIGw&t=2977s
4.https://www.chainfeeds.xyz/feed/detail/45ca8444-113b-4d81-b3eb-cd90a1297f8d
5. https://arxiv.org/abs/1809.09044
6.https://ethereum.org/zh/developers/docs/data-availability/
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。本文内容仅用于信息分享，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
