解析 B^2 新版技术路线图：比特币链下 DA 与验证层的必要性

此文包含 B^2 Network 官方文档未披露的内容，赶紧来先睹为快吧

作者：Faust，极客 Web3

封面：Photo by Shubham Dhage on Unsplash

摘要：· B^2 Network 在比特币链下设置了名为 B^2 Hub 的 DA 层，该 DA 层网络借鉴了 Celestia 的思路，引入数据采样与纠删码，确保新增数据可以快速的分发给大量的外部节点，并极力避免数据扣留的发生。同时，B^2 Hub 网络中的 Committer 会把 DA 数据的存储索引以及数据 hash 上传到比特币链上，供任何人读取；

· 为了减轻 DA 层节点的压力，B^2 Hub 中的历史数据不会永久保存，所以 B^2 又尝试搭建起一个存储网络，通过类似于 Arweave 的存储激励方式，刺激更多节点存储更完备的历史数据集，以获取存储激励；

· 在状态验证方面，B^2 采用了混合式的验证方案，在链下验证 ZK 证明，链上通过 bitVM 的思路，挑战 ZK 证明验证痕迹，只要有 1 个挑战者节点在检测到错误后发起挑战，B^2 网络就是安全的，这符合欺诈证明协议的信任模型，但由于用到了 ZK，这种状态验证实际上是混合型的。

·按照 B^2 Network 的未来路线图，EVM 兼容的 B^2 Hub 可以成为对接多个比特币 Layer2 的链下验证层与 DA 层，成为一个类似于 BTCKB 的比特币链下功能拓展层。由于比特币本身无法支持很多场景，这种链下搭建功能拓展层的方式将会成为 Layer2 生态里越来越常态化的现象。

B^2 Hub：比特币链下的通用 DA 层与验证层

如今的比特币生态可谓是一片机会与骗局共存的蓝海，这个因铭文之夏而焕发生机的全新领域简直是一片肥沃的处女地，到处都弥漫着金钱的气息。随着今年 1 月比特币 Layer2 如雨后春笋般集体涌现，这片原本如荒芜原野的土地瞬间就成为了无数造梦者的摇篮。

但回归到最本质的问题：什么是 Layer2，人们似乎始终没有达成共识。侧链是吗？索引器是吗？搭个桥的链就叫 Layer2 吗？一个依赖于比特币和以太坊的简易插件，可不可以当做一个 Layer？这些问题就像一组难解的方程式，始终都没有一个确切的结局。

而按照以太坊和 Celestia 社区的思路，Layer2 只是模块化区块链的特殊情况，在这种情况下，所谓的 “二层” 与 “一层” 之间会存在紧密的耦合关系，二层网络可以很大程度，或一定程度继承 Layer1 的安全性。至于安全性这个概念本身，可以拆解为细分的多个指标，包括：DA、状态验证、提款验证、抗审查性、抗重组等。

由于比特币网络本身存在诸多问题，其天生不利于支持较完备的 Layer2 网络。比如在 DA 上，比特币的数据吞吐量远低于以太坊，以其平均 10min 的出块时间来计算，比特币最大的数据吞吐量仅为 6.8KB/s，差不多是以太坊的 1/20，如此拥挤的区块空间自然而然造就了高昂的数据发布成本。

如果 Layer2 直接把新增的交易数据发布到比特币区块里，既不能实现高吞吐量，也不能实现低手续费。所以要么就通过高度压缩，把数据尺寸压缩的尽可能小，再上传到比特币区块。目前 Citrea 采用了这种方案，它们声称，将把一段时间内的状态变化量 (state diff)，也就是多个账户上发生的状态变更结果，连同对应的 ZK 证明，一起上传到比特币链上。

这种情况下，任何人都可以从比特币主网下载 state diff 和 ZKP，验证其是否有效，但上链的数据尺寸却可以轻量化。

这种方案在极大程度压缩了数据尺寸的同时，最终还是容易遇到瓶颈。比如，假设在 10 分钟内发生了几万笔交易，使得上万个账户发生了状态变更，你最终还是要把这些账户的变化情况，汇总上传到比特币链上。虽然比起直接上传每笔交易数据，要轻量很多，但还是会产生很可观的数据发布成本。

所以很多比特币 Layer2 干脆就不把 DA 数据上传到比特币主网，直接采用 Celestia 等第三方 DA 层。而 B^2 采用了另一种方式，直接在链下搭建一个 DA 网络（数据分发网络），名为 B^2 Hub。在 B^2 的协议设计中，交易数据或 state diff 等重要数据存放于链下，只向比特币主网上传这些数据的存储索引，以及数据 hash（其实是 merkle root，为了表述方便说成数据 hash）。

这些数据 hash 和存储索引，以类似铭文的方式写入到比特币链上，只要你运行一个比特币节点，就可以把数据 hash 和存储索引下载到本地，根据索引值，能从 B^2 的链下 DA 层或存储层中，读取到原始数据。根据数据 hash，你可以判断，自己从链下 DA 层获取的数据是否正确（能否和比特币链上的数据 hash 相对应）。通过这种简单的方式，Layer2 可以避免在 DA 问题上过度依赖比特币主网，节约手续费成本并实现高吞吐量。

当然，有一点不可忽视，就是这种链下的第三方 DA 平台有可能搞数据扣留，拒绝让外界获取到新增的数据，这种场景有一个专用术语，叫 “数据扣留攻击”，可以归纳为数据分发中的抗审查问题。不同的 DA 方案有不同的解决办法，但核心宗旨，都是要把数据尽可能快、尽可能广泛的传播出去，防止一小撮特权节点控制着数据获取权限不放。

按照 B^2 Network 官方新的路线图，其 DA 方案借鉴了 Celestia。在后者的设计中，第三方的数据提供者会不断的向 Celestia 网络提供数据，Celestia 出块者会把这些数据片段，组织为 Merkle Tree 的形态，塞到 TIA 区块里，广播给网络里的 Validator/全节点。

由于这些数据比较多，区块比较大，大多数人运行不起全节点，只能运行轻节点。轻节点不同步完整区块，只同步一个区块头，写有 Mekrle Tree 的树根 Root。

轻节点仅凭区块头，自然不知道 Merkle Tree 的全貌，不知道新增数据都有什么，无法验证数据是否有问题。但轻节点可以向全节点索要树上的某个叶子 leaf。全节点会按照要求，把 leaf 和对应的 Merkle Proof，一并提交给轻节点，让后者确信，这个 leaf 的确存在于 Celestia 区块里的 Merkle Tree 上，而不是被节点凭空杜撰出的虚假数据。

Celestia 网络里存在大量的轻节点，这些轻节点可以向不同的全节点发起高频的数据采样，随机性的抽选 Merkle Tree 上的某几个数据片段。轻节点获取到了这些数据片段后，也可以传播给他能连接到的其他节点，这样就可以快速的把数据分发给尽可能多的人/设备，以此来实现高效的数据传播，只要足够多的节点都能快速获取最新的数据，人们就不用再信任一小撮数据提供者，这其实就是 DA/数据分发的核心目的之一。

当然，仅凭上面描述的方案，还是存在攻击场景，因为它只能保证数据分发时，人们都能快速获取到数据，但无法保证数据的生产源头不作恶。比如，Celestia 出块者可能在区块里掺杂一点垃圾数据，人们即便获取了区块中的全部数据片段，也无法还原出 “本应包含” 的完整数据集（注意：这里 “本应” 这个词很重要）。

进一步说，原始数据集中可能有 100 笔交易，其中某笔交易的数据没有被完整传播给外界。这时，只需要隐藏 1% 的数据片段，外界就无法解析出完整数据集。这正是最早的数据扣留攻击问题中，所探讨的场景。

其实，根据这里描述的场景来理解数据可用性，可用性这个词描述的是区块里的交易数据是否完整，是否可用，能否直接交由其他人去验证，而不是像很多人理解的那样，可用性代表区块链历史数据能否被外界读取到。所以，Celestia 官方和 L2BEAT 创始人曾指出，数据可用性应该改名为数据发布，意指区块里是否发布了完整可用性的交易数据集。

Celestia 引入了二维纠删码，解决上面描述的数据扣留攻击。只要区块里包含的 1/4 的数据片段（纠删码）有效，人们就可以还原出对应的原始数据集。除非出块者在区块里掺杂 3/4 的垃圾数据片段，才能让外界无法还原出原始数据集，但这种情况下，区块里包含的垃圾数据太多了，很容易就会被轻节点们检测出来。所以对于区块生产者而言，还是不要作恶来的更好些，因为作恶几乎很快就被无数人察觉到。

通过前面描述的方案，可以有效防止 “数据分发平台” 出现数据扣留，而 B^2 Network 未来会以 Celestia 的数据采样作为重要参考，可能结合 KZG 承诺等密码学技术，进一步降低轻节点执行数据采样和验证的成本。只要执行数据采样的节点足够多，就能让 DA 数据的分发变得有效且去信任。

当然，上述方案只解决了 DA 平台自身的数据扣留问题，但在 Layer2 的底层结构中，有能力发动数据扣留的不止 DA 平台，还有排序器（Sequencer）。在 B^2 Network 乃至大多数 Layer2 的工作流程中，新增数据是由排序器 Sequencer 产生的，它会把用户端发来的交易汇总处理，附带这些交易执行后的状态变更结果，打包成批次 (batch)，再发送给充当 DA 层的 B^2 Hub 节点们。

如果排序器一开始生成的 batch 就有问题，就还存在数据扣留的可能性，当然还包括其他形式的作恶场景。所以，B^2 的 DA 网络 (B^2 Hub) 收到排序器生成的 Batch 后，会先对验证 Batch 的内容，有问题就拒收。可以说，B^2 Hub 不但充当了类似于 Celestia 的 DA 层，也充当了链下的验证层，有点类似于 CKB 在 RGB++协议中的角色。

按照 B^2 Network 最新的技术路线图，B^2 Hub 在收到并验证了 Batch 后，只保留一段时间，过了这个窗口期，Batch 数据就会被过期淘汰，从 B^2 Hub 节点本地删除掉。为了解决类似于 EIP-4844 的数据淘汰及丢失问题，B^2 Network 设置了一组存储节点，这些存储节点会负责永存 Batch 数据，这样一来，任何人在任何时候，都可以在存储网络中搜索到自己需要的历史数据。

不过，没有人会平白无故的运行 B^2 存储节点，如果想让更多人来运行存储节点，增强网络的去信任程度，就要提供激励机制；要提供激励机制，就要先想办法反作弊。比如，假如你提出了一套激励机制，任何人在自己的设备本地存储了数据，就可以获取奖励，可能有人在下载了数据后，又偷偷的把一部分数据删掉，却声称自己存储的数据是完整的，这就是最常见的作弊方法。

Filecoin 通过名为 PoRep 和 PoSt 的证明协议，让存储节点向外界出示存储证明，证明自己在给定时间段内的确完整的保存了数据。但这种存储证明方案需要生成 ZK 证明，且计算复杂度很高，对存储节点的硬件设备会有较高要求，可能不是一个经济成本上可行的方法。

在 B^2 Network 的新版技术路线图中，存储节点会采用类似于 Arweave 的机制，需要争夺出块权来获取代币激励。如果存储节点私自删除了一些数据，则其成为下一个出块者的概率会降低，而保留数据最多的节点，越有可能成功出块，获取到更多的奖励。所以对于大多数存储节点而言，还是保留完整的历史数据集比较好。

当然，有激励的不只是存储节点，还包括前面提到的 B^2 Hub 节点，按照路线图，B^2 Hub 会组建成一个 Permissionless 的 POS 网络，任何人只要质押了足够多的 Token，就可以成为 B^2 Hub 或存储网络中的一员，通过这种方式，B^2 Network 尝试在链下打造去中心化的 DA 平台及存储平台，并在未来集成 B^2 以外的比特币 Layer2，搭建通用的比特币链下 DA 层与数据存储层。

ZK 与欺诈证明混用的状态验证方案

前面我们阐述了 B^2 Network 的 DA 解决方案，接下来我们将重点讲述其状态验证方案。所谓的状态验证方案，就是指 Layer2 如何保证自己的状态转换足够 “去信任”。

前面我们曾提到，在 B^2 Network 乃至大多数 Layer2 的工作流程中，新增数据是由排序器 Sequencer 产生的，它会把用户端发来的交易汇总处理，附带这些交易执行后的状态变更结果，打包成批次 (batch)，发送给 Layer2 网络中的其他节点，包括普通的 Layer2 全节点，以及 B^2 Hub 节点。

B^2 Hub 节点在收到 Batch 数据后，会解析其内容并做出验证，这里就包含了前面提到的 “状态验证”。其实状态验证，就是验证排序器生成的 Batch 中，记录的 “交易执行后的状态变化” 是否正确。如果 B^2 Hub 节点收到了包含错误状态的 Batch，会将其拒收。

其实，B^2 Hub 本质是一条 POS 公链，会有出块人和验证人的分野。每隔一段时间，B^2 Hub 的出块人会生成新的区块，并传播给其他节点（验证人），这些区块里包含了排序器提交的 Batch 数据。剩下的工作流程和前面提到的 Celestia 有些许类似，有很多外部的节点，频繁的向 B^2 Hub 节点索要数据片段，在这个过程中，Batch 数据会被分发给很多节点设备，也包括前面提到的存储网络。

B^2 Hub 中存在名为 Committer（承诺人）的可轮换角色，它会把 Batch 的数据 hash（其实是 Merkle root），以及存储索引，以铭文的形式提交到比特币链上。只要你读取到这个数据 hash 和存储索引，就有办法在链下的 DA 层/存储层获取到完整的数据。假设链下有 N 个节点存放着 Batch 数据，只要其中 1 个节点愿意对外提供数据，就能让任何人获取到它需要的数据，这里的信任假设是 1/N。

当然，我们不难发现，上述过程中，负责验证 Layer2 状态转换有效性的 B^2 Hub，是独立于比特币主网的，只是一个链下的验证层，所以这个时候，Layer2 的状态验证方案，在可靠性上无法等价于比特币主网。

一般而言，ZK Rollup 可以完整的继承 Layer1 的安全性，但目前比特币链上只支持一些极为简单的计算，无法直接验证 ZK 证明，所以还没有哪个 Layer2 可以在安全模型上等价于以太坊的那种 ZK Rollup，包括 Citrea 和 BOB 等。

目前看来，“比较可行” 的思路是 BitVM 白皮书中所阐述的那样，复杂的计算过程挪到比特币链下，仅在必要时把某些简单的计算挪到链上进行。比如验证 ZK 证明时产生的计算痕迹，可以公开，交由外界去检查。如果人们发现其中某个比较细微的计算步骤有问题，就可以在比特币链上验证这道 “有争议的计算”。这里面需要用比特币的脚本语言，模拟出 EVM 等特殊虚拟机的功能，消耗的工程量可能会非常巨大，但并不是不可行。

在 B^2 Network 的技术方案中，排序器产生了新的 Batch 后，会转发给聚合器以及 Prover，后者把 Batch 的数据验证过程 ZK 化，生成 ZK 证明，最终转发给 B^2 Hub 节点。B^Hub 节点是 EVM 兼容的，通过 Solidity 合约来验证 ZK Proof，这其中涉及的全部计算过程，会被拆分为非常底层的逻辑门电路形态，这些逻辑门电路又会以比特币脚本语言的形式表达出来，全部提交至吞吐量足够大的第三方 DA 平台中。

如果人们对这些披露出来的 ZK 验证痕迹存在疑问，觉得某个小步骤有错误，就可以在比特币链上进行 “挑战”，要求比特币节点直接检查这个有问题的步骤，并适当做出惩罚。

那么是谁被惩罚呢？其实是 Committer。在 B^2 Network 的设定中，Committer 不但会把前面说的数据 hash 发布到比特币链上，还要把 ZK 证明的验证 “承诺” 发布到比特币主网。通过比特币 Taproot 的一些设定，你可以随时在比特币链上，对 Committer 发布的 “ZK 证明验证承诺” 进行质疑和挑战。

这里解释下什么 “承诺”（Commitment）。“承诺” 的含义在于，某些人声称，某些链下数据是准确无误的，并在链上发布对应的声明，这个声明就是 “承诺”，承诺值与特定的链下数据相绑定。在 B^2 的方案中，如果有人认为 Committer 发布的 ZK 验证承诺有问题，就可以进行挑战。

可能有人会问，前面不是提到 B^2 Hub 在收到 Batch 后，会直接验证其有效性吗，这里为何又要 “多次一举” 的验证 ZK 证明？为什么不直接把验证 Batch 的过程公开披露，让人们直接挑战，非要引入 ZK 证明干什么？这其实是为了把计算痕迹压缩的足够小，如果直接把验证 Layer2 交易、产生状态变更的计算流程，全部以逻辑门电路和比特币脚本的形式公开披露，将会产生极大的数据尺寸。而 ZK 化之后，可以把数据尺寸极大程度压缩后，再发布出去。

这里大致总结下 B^2 的工作流程：

1. B^2 的排序器 Sequencer 负责产生新的 Layer2 区块，并将多个区块聚合为 data batch（数据批次）。data batch 会被送给聚合器 Aggregator，以及 B^Hub 网络中的 Validator 节点。
2. 聚合器会将 data Batch，发送给 Prover 节点，让后者生成对应的零知识证明。ZK 证明随后会被发送给 B^2 的 DA 与验证者网络 (B^2Hub)。
3. B^2Hub 节点会验证聚合器发来的 ZK Proof，能否和 Sequencer 发过来的 Batch 相对应。若两者可以对应，则通过验证。通过验证的 Batch，其数据 hash 与存储索引，会被某个指定的 B^Hub 节点（称为 Committer）发送至比特币链上。
4. B^Hub 节点会将其验证 ZK Proof 的整个计算过程公开披露，将计算过程的 Commitment 发送到比特币链上，允许任何人对其进行挑战。如果挑战成功，则发布 Commitment 的 B^Hub 节点将受到经济惩罚（它在比特币链上的 UTXO 将被解锁并转移给挑战者）

B^2 Network 的这种状态验证方案，一面引入了 ZK，一面采用了欺诈证明，实际上属于混合型的状态验证方式。只要链下存在至少 1 个诚实的节点，在检测出错误后愿意发起挑战，就可以保证 B^2 Network 的状态转换是没有问题的。

按照西方比特币社区成员的看法，未来比特币主网可能会进行适当的分叉，以支持更多的计算功能，也许在未来，直接在比特币链上验证 ZK 证明会成为现实，届时将为整个比特币 Layer2 带来新的范式级变革。而 B^2 Hub 作为一个通用的 DA 层与验证层，不但可以作为 B^2 Network 的专用模块，还可以赋能其他比特币二层，在比特币 Layer2 的大争之世中，链下功能拓展层必将越来越重要，而 B^Hub 和 BTCKB 的涌现，或许才刚刚揭开这些功能拓展层的冰山一角。

免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。文章内的信息仅供参考，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。