撰文：Shew & Faust，极客 web3
目前的比特币 Layer2 赛道可谓百花齐放，各种不同的技术方案扎堆聚集在了 BTC 生态这个大熔炉之中。由于区块链领域迭代速度快，专业词汇或者标准，都是在研究创新和工程落地过程中不断变化的。在这样的背景下，很多项目会采用「造概念」/「蹭概念」的方式获取差异化和关注度，已然成为业内潜规则。
比如，许多原本活跃于以太坊 /Celestia 生态的模块化区块链项目，也乘着东风之便，搭上了「比特币 Layer2」的快车，并自封为「Rollup」，但其技术方案往往不符合 Rollup 的标准。
但是，「Rollup」这样的词汇具有较高的被认可度，打着「Rollup」旗号更利于宣传。许多项目方要么是硬蹭（自封为 Rollup），要么是分叉主流的 Rollup 概念（加个暧昧的定语，比如主权 Rollup）。
但扒开其「XX Rollup」的外衣一看，很多项目的工作原理，还是单纯的「客户端验证」或「侧链」，只是在借着「XX Rollup」的宣传口号给自己牟方便。这种宣传方式虽然比较普遍，但往往带有误导性，对于追求真相的广大群众而言，带来的坏处要多于益处。
（纳粹宣传部长戈培尔对「撒谎式宣传」的总结，这种做法在很多项目方身上屡见不鲜）
那我们该如何鉴别此类「蹭 Rollup 概念」的行为呢？
或许，从第一性原理出发，根据西方乃至业界广泛认可的标准，来定义不同 Layer2 项目的方案类别与安全程度，以及功能完备性，才能让我们开启雾里看花时的那双「万花筒写轮眼」。或者说，采用什么方案不是最重要的，核心在于项目在机制设计上，能否确保 Layer2 网络安全可靠，能否真正意义赋能 BTC 主网。
下面，我们打算以 Chainway 这个老外做的比特币 Layer2 为案例，剖析部分项目在「Rollup」宣传口号背后，隐藏着的「客户端验证」本质。我们可以更清晰的看穿，「主权 Rollup」和「客户端验证」，与业界主流意义上的ZKRollup，或 OPRollup 等依赖于智能合约实现的 Rollup 方案的明显差异。
当然，这并不是说，主权 Rollup 或客户端验证就不如 ZK Rollup 安全可靠，一切都要看其具体的细节实现。Chainway 虽然是典型的客户端验证型 Layer2，但其提出了「在 BTC 触发 + 在链下验证」的抗审查交易方案，并采用了类似于 MINA 公链的递归 ZK Proof，领先于多数比特币 Layer2。
我们认为，对 Chainway 的技术调研是比较有价值的，这对于广大比特币 Layer2 观察者具有重要的参考意义。
（Chainway 的宣传图片，将自己标榜为 ZK Rollup，但其真实方案是客户端验证，目前其尚未实现 链下客户端间的共识，或可靠的讯息交换）
正文：Chainway 是一个在西方社区比较有名的比特币 Layer2 项目，许多 KOL 在宣传时，直接称其为「ZK Rollup」，而在其技术文档中，Chainway 又自我定位成「主权 Rollup」。近期 Chainway 还公布了其新项目 Citrea，自称是基于 BitVM 的 ZK Rollup。由于 Citrea 尚未详细说明其基于 BitVM 的 ZK 验证方案如何实现，本文将重点放在 Chainway 已有方案的技术解读。
我们可以用一句话概括Chainway 现已公开的技术方案: 通过 Ordinals 协议发布 DA 数据，将 BTC 作为其 DA 层，在 Layer1 发布状态变化细节 State diff + 证明状态变化正确性的 ZK Proof，效果等价于发布完整的、可验证的交易数据。
（State diff 就是账户状态的变化量）
但由于 Layer1 不直接验证 ZK Proof，验证工作由链下的独立客户端 / 节点进行，且Chainway 目前的代码库，并未在链下独立客户端之间实现共识，官方也没有在社交媒体上宣称解决这个问题。所以，目前 Chainway 公布的技术方案，本质上属于「客户端验证」类型，甚至更像一个支持桥接资产的铭文索引协议。
下文将主要介绍 Chainway 的具体技术实现，并分析其安全模型。
何谓主权 Rollup：DA 层发布数据 + 链下验证
在 Chainway 的技术文档中，用到了 Celestia 的主权 Rollup(sovereign rollup) 概念。而主权 Rollup 实际上与以太坊社区乃至业界主流的 Rollup 概念（智能合约 Rollup）有天壤之别。那么主权 Rollup 的具体构造是怎样的呢？
其实基于比特币的主权 Rollup 有点类似于——「在 BTC 链上发布 DA 数据 的 链下客户端群体 / 侧链」，其最大特点在于，不需要 Layer1 上的智能合约对 Layer2 的状态转换 / 跨链行为做验证，本质上只是把 BTC 作为 DA 层，安全模型与「客户端验证」(client side validation) 很大程度上接近。
当然，一些安全性高些的主权 Rollup 方案，会依赖于 BTC 链下的第三方结算层（类似于侧链）来完成状态转换验证，且不同的独立客户端 / 全节点之间，存在一层共识或是可靠的消息传递，以此来对某些有争议的行为达成「一致」。但有些主权 Rollup 项目却是赤裸裸的「客户端验证」，独立客户端 / 节点之间没有什么可靠的消息传递。
为了更好的理解「主权 Rollup」这个独特的概念，我们可以把主权 Rollup 与其对应的智能合约 Rollup 相比较。以太坊上的 Layer2 基本都是智能合约 Rollup，如 Arbitrum 和 StarkNet 等。智能合约 Rollup 的结构可以参考下图:
在上图中，我们可以看到模块化区块链叙事的几个术语，解释如下:
Execution 执行层: 执行用户交易，更新区块链状态，向 DA 层和结算层提交数据
Settlement 结算层: 验证执行层的状态转换，解决争议 ( 如欺诈证明），并提供桥模块来处理 L1-L2 桥接资产
DA 层: 一个大号公告板，接收执行层提交的状态转换数据，把这些数据去信任的提供给任何人
Consensus 共识层: 确保交易排序的最终性，与 DA 层的职能似乎比较接近（以太坊社区对模块化区块链的分层方式，不包含共识层）
从智能合约 Rollup 的架构中，我们看到除了执行层外，其他三层的职能都由以太坊承担。下图更详细的展示了以太坊在智能合约 Rollup 中承担的角色。
以太坊上的 Rollup 合约会接收 validity proof( 有效性证明 ) 或者 fraud proof( 欺诈证明 ) ，以此验证 Layer2 状态转换的有效性。值得一提的是，此处的 Rollup 智能合约实际上就是模块化区块链中的结算层实体。结算层合约往往会包含桥接模块，用于处理以太坊桥接到 Layer2 的资产。
而对于 DA，结算层合约可以强制要求排序器 Sequencer 把最新的交易数据 / 状态变化细节上链，如果不把 DA 上链，就无法顺利更新 Rollup 合约上记录的 L2 状态。
（ZK Rollup 或 OP Rollup，可以强制要求 DA 数据上链，不上链就无法更新结算层记录的状态）
参考资料：用木桶理论拆解比特币 / 以太坊 Layer2 安全模型与风险指标
我们可以看出，智能合约 Rollup 严重依赖于 Layer1 上的智能合约，对于 BTC 这种难以支持复杂业务逻辑的 Layer1 而言，基本无法构造出向以太坊 Rollup「对齐」的 Layer2。
而主权 Rollup 方案干脆不需要 Layer1 上的合约进行状态验证 / 桥接处理。其架构如下图:
我们可以看到，在主权 Rollup 中，由 DA 层之外的节点群体作为交易执行和结算操作的实体，具备更高的自由度。其具体的工作流程如下:
主权 Rollup 的执行层节点，将交易数据 / 状态变化细节 发送到 DA 层，而结算层 / 客户端设法获取数据并进行验证工作。值得注意的是，由于结算层模块不位于 Layer1 上，所以主权 Rollup 理论上无法实现等同于 Layer1 安全性的桥，往往要依赖于公证人桥，或是第三方的桥接方案。
目前看来，主权 Rollup/ 客户端验证方案落地难度较低，只需要在 BTC 链上实现数据发布，采用类似 Ordinals 协议的形式。至于链下验证和链下共识的部分，自由发挥的空间很大，甚至很多侧链只要往 BTC 上发布 DA 数据，基本就成了「基于 BTC 的主权 Rollup」，只是具体的安全性存疑。
但问题在于，比特币的数据吞吐量极低，每个 block 最大 4MB，平均出块时间为 10 分钟，换算下来数据吞吐量仅 6KB/s。现在自称为主权 Rollup 的 Layer2 方案，可能无法把所有 DA 数据都发布在 BTC 链上，进而采取其他折中方式：比如在链下发布 DA 数据，把 datahash 存放到 BTC 链上，作为一种「承诺」。或者找到一种把 DA 数据高度压缩的方法（比如 Chainway 自称用到的 State diff+ZK Proof）。
但显然这种模式不符合「主权 Rollup」或正经 Rollup 的定义，属于一种变体，其安全性有待商榷。我们预测，日后大多数打着「Rollup」旗号的 Layer2 项目，最终都不会把 DA 数据完整发布到 BTC 链上，所以其实践方案十有八九与白皮书上的「ZK Rollup」、「OP Rollup」宣传口号不符合。
最后，让我们简单归纳一下主权 Rollup 和智能合约 Rollup 的不同之处:
第一，可升级性。智能合约 Rollup 的更新迭代，涉及到智能合约的 update，需要开发团队使用可升级合约。这种智能合约的升级权限一般由 Rollup 开发团队用多签控制。而主权 Rollup 的升级规则，类似于常规区块链的软硬分叉，节点可以自行选择更新版本，不同客户端可以选择是否接受升级。从这一点来看，主权 Rollup 要比智能合约 Rollup 更优越。
第二，桥。智能合约 Rollup 的桥，在理想条件下是符合信任最小化的，但是合约的可升级性会影响其安全。而主权 Rollup 方案下，需要开发者自己在 Layer1 链下构造桥接组件，构造出的桥十有八九不会像智能合约桥一样去信任。
BTC DA 构造
在上文中，我们提到，要实现基于 BTC 的主权 Rollup，核心在于使用 Ordinals 协议将 BTC 作为 DA 层。Chainway 就用了这种方案。
我们可以观察一笔来自 Chainway 排序器的 DA 数据提交，其交易哈希为：
24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000，示意图如下:
这笔交易的脚本代码，借鉴了 Ordinals Protocol 中使用 OP_0 OP_IF 实现数据写入的方案，将 Rollup 的 DA 数据写入了 BTC 链（发布状态变化 +ZK Proof，在安全性上等价于发布原始交易数据，但数据尺寸可以极大程度压缩）。
当然，除了 DA 数据外，排序器也在交易内写入了一些鉴权数据，最重要的就是 Rollup 排序器使用自己的私钥对 DA 数据进行签名，确保该笔 DA 数据提交是排序器提交的。
此处我们还要注意，任意一笔涉及 DA 数据提交的交易，交易哈希尾部都存在 16 个二进制的 0（也就是连续 2 个字节均为 0） 。在代码内，我们可以看到此限制:
前面的示例交易图中的随机数 b715 ，目的是调整这笔交易取哈希后的数值，使其尾部携带特定的 16 个 0，道理类似于比特币挖矿时需要添加一个随机数 nonce，使得 hash 的前 N 位均为 0，满足特定的限制条件。
这种设计是为了简化 DA 数据的获取难度，当 Layer2 任意节点要获取 DA 数据时，只需要扫描 BTC 区块中，所有末尾设置为 16 个 0 的交易，相当于把 Chainway 排序器提交数据时发起的交易，与比特币链上其他交易明确区分开。后文中，称这种包含 DA 数据且满足末尾为 16 个 0 的交易为「Chainway 规范交易」。
那么到了本文标题中提及的重点：Chainway 如何实现抗审查呢？因为 Layer2 排序器可能会故意拒绝某个用户的交易请求，我们必须要用一种特殊方案，让用户发起抗审查的交易。
面对这一问题，Chainway 允许用户发起「强制交易」，Forced Transaction。一旦用户在 BTC 区块内提交此交易声明，Chainway 排序器必须在 Layer2 处理此交易请求，否则将无法正常出块，或者出的块不会被链下客户端认可。
强制交易的参数结构如下:
这笔交易会作为一笔「Chainway 规范交易」提交到比特币链上，交易哈希的末尾带 16 个 0。ChainWay 排序器在生成 L2 区块时,必须要包含 BTC 链上已披露、但未收录进 L2 账本的「Layer2 规范交易」，并汇总成一棵 Merkle Tree，将其 Merkle root 写入 L2 区块头。
一旦用户在 BTC 链上直接发起强制交易，排序器必须处理，否则无法生成下一个有效的区块。BTC 链下的 Chainway 客户端可以先校验 ZK 证明，确定排序器提交的 L2 区块有效性，校验 L2 区块头的 Merkle root，判断排序器是否如实包含了强制交易请求。
其工作流程可以参考以下流程图。注意，限于篇幅，下图中 verify_relevant_tx_list 缺失了一个条件判断:
总而言之，Chainway 客户端 / 节点会同步 BTC 主网区块，并从中，扫描出 Chainway 排序器发布的「DA 数据」，确认这些数据是由指定的排序器发布的，且的确包含了所有提交到 BTC 链上的「Chainway 规范交易」。
不难看出，只要用户能够构造出一笔符合限制条件的「规范交易」，并提交到 BTC 链上，这笔交易最终会被包含进 Chainway 客户端本地的 L2 账本中，不然 Chainway 排序器发布的 L2 block 会被客户端拒收。
如果配合可靠的链下共识 / 警报消息传递，Chainway 的抗审查交易方案，就趋近于理想化的主权 Rollup 的抗审查方法。比如部分主权 Rollup 方案曾明确表示，遇到无效区块，会在链下客户端之间广播 Alert 警报信息，来增强安全性，尤其让无法同步完整 DA 数据的轻客户端也知道网络状态异常。
如果一个区块没有如实包含「强制交易」，显然会触发链下警报广播，但目前 Chainway 还没有实现这一块（至少目前公布的资料和代码库，显示它没有去做这块的技术实现）。
参考资料：Celestia 研究员分析 6 种 Rollup 变体：Sequencer=聚合器 +Header 生成者
即便是实现了链下客户端 / 节点间的共识，Chainway「强制交易」的抗审查效果，也不如 Arbitrum 等智能合约 Rollup，因为 Arbitrum One 最终会通过 Layer1 上的合约来确保「强制交易」被包含进 Layer2 账本，完整继承 Layer1 的抗审查性，主权 Rollup 显然无法在这一点向智能合约 Rollup 看齐，其抗审查性最终还是取决于链下部分。
这也决定了，「主权 Rollup」以及「客户端验证」方案的思路，基本无法像 Arbitrum One 或 Loopring、dydx 和 Degate 一样，完整继承 Layer1 的抗审查性，因为强制交易能否被顺利包含进 Layer2 账本，要取决于 Layer2 链下实体们的决策，与 Layer1 本身无关。
很显然，Chainway这种单纯依赖于链下客户端自由定夺的方案，只是继承了 Layer1 的 DA 可靠性，没有完整继承其抗审查性。
类似于 MINA 的递归 ZK 证明
在本节中，我们将进一步介绍 Chainway 的其他组成部分，它除了使用 BTC 作为 DA 层外，也实现了类似于 MINA 的递归 ZK 证明。其整体结构如下图:
Chainway 网络的排序器在处理完用户交易后，生成最终的 ZK 证明，连带不同账户的状态变化细节 state diff，发布到 BTC 链上。而全节点会同步 BTC 上发布的 Chainway 所有历史数据。每一次 ZK 证明不仅要对当前区块的状态转换过程进行证明，也要保证上一个区块的 ZK 证明有效。
基于上述方案，我们可以发现每次生成新的证明，实际上都对上一个证明进行了确认，依次递归，最新的一个 ZK 证明就可以保证从创世区块开始的所有 ZK 证明都有效。这个设计就类似于 MINA。
当一个仅同步区块头的「轻客户端」，也就是轻节点加入网络时，仅需要验证 BTC 上披露的最新一个 ZK Proof 有效，就可以确认整条链的历史数据、所有的状态转换是有效的。
假如排序器作恶，故意不接受强制交易，或者不使用上一次 ZK 证明进行递归证明，则生成的新的 ZK 证明无法被客户端接受（生成了也不被认可），如下图:
总结
正如本文最开始的总结，Chainway 本质上是一个使用 BTC 作为 DA 层的主权 Rollup/ 客户端验证方案。为了提高 Rollup 的抗审查性，Chainway 引入了强制交易的概念。另一方面，Chainway 使用了递归 ZK 证明技术，使得新进入的节点可以更加信任排序器的输出结果，随时确认整条链的历史数据无误。
Chainway 目前的问题在于跨链桥部分该如何去信任，由于其采用主权 Rollup 方案，没有说明在跨链桥方案上，打算如何解决技术细节，还难以判断其最终的安全性究竟如何。
今天，我们通过深入分析 Chainway 的技术方案，发现该项目社区所宣传的技术类型，并不是主流意义上的 Rollup。考虑到当前比特币 Layer2 项目已达数十个（半年后可能上百个），为了降低大家对技术名词的认知成本，我们将持续的在 Layer2 方案分类和安全标准、功能完备性测评标准上深入调研，敬请期待！
