导语:目前的比特币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是一个在西方社区比较有名的比特币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,效果等价于发布完整的、可验证的交易数据。
但由于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严重依赖于Layer1上的智能合约,对于BTC这种难以支持复杂业务逻辑的Layer1而言,基本无法构造出向以太坊Rollup“对齐”的Layer2。而主权Rollup方案干脆不需要Layer1上的合约进行状态验证/桥接处理。其架构如下图:
但问题在于,比特币的数据吞吐量极低,每个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”宣传口号不符合。
BTC DA 构造
在上文中,我们提到,要实现基于BTC的主权Rollup,核心在于使用Ordinals协议将BTC作为DA层。Chainway就用了这种方案。
我们可以观察一笔来自Chainway排序器的DA数据提交,其交易哈希为:
24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000,示意图如下:
如果配合可靠的链下共识/警报消息传递,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证明。其整体结构如下图:
基于上述方案,我们可以发现每次生成新的证明,实际上都对上一个证明进行了确认,依次递归,最新的一个ZK证明就可以保证从创世区块开始的所有ZK证明都有效。这个设计就类似于MINA。当一个仅同步区块头的“轻客户端”,也就是轻节点加入网络时,仅需要验证BTC上披露的最新一个ZK Proof有效,就可以确认整条链的历史数据、所有的状态转换是有效的。假如排序器作恶,故意不接受强制交易,或者不使用上一次ZK证明进行递归证明,则生成的新的ZK证明无法被客户端接受(生成了也不被认可),如下图:
正如本文最开始的总结,Chainway本质上是一个使用BTC作为DA层的主权Rollup/客户端验证方案。为了提高 Rollup 的抗审查性,Chainway引入了强制交易的概念。另一方面,Chainway使用了递归ZK证明技术,使得新进入的节点可以更加信任排序器的输出结果,随时确认整条链的历史数据无误。Chainway目前的问题在于跨链桥部分该如何去信任,由于其采用主权Rollup方案,没有说明在跨链桥方案上,打算如何解决技术细节,还难以判断其最终的安全性究竟如何。
今天,我们通过深入分析Chainway的技术方案,发现该项目社区所宣传的技术类型,并不是主流意义上的Rollup。考虑到当前比特币Layer2项目已达数十个(半年后可能上百个),为了降低大家对技术名词的认知成本,我们将持续的在Layer2方案分类和安全标准、功能完备性测评标准上深入调研,敬请期待!
文章声明:以上内容(如有图片或视频亦包括在内)除非注明,否则均为谈天说币原创文章,转载或复制请以超链接形式并注明出处。