技术解读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层发布数据 + 链下验证