技术解读Chainway：比特币Layer2项目是怎么蹭概念的

作者：Shew & Faust，极客web3，顾问：Kevin He, BitVM 中文社区发起人，ex Web3 Tech Head@Huobi

目前的比特币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数据上链，不上链就无法更新结算层记录的状态）

我们可以看出，智能合约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还没有实现这一块（至少目前公布的资料和代码库，显示它没有去做这块的技术实现）。

即便是实现了链下客户端/节点间的共识，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方案分类和安全标准、功能完备性测评标准上深入调研，敬请期待！