以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

作者:Shew & Faust,极客web3

顾问:Kevin He, BitVM 中文社区发起人,ex Web3 Tech Head@Huobi

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

导语:目前的比特币Layer2赛道可谓百花齐放,各种不同的技术方案扎堆聚集在了BTC生态这个大熔炉之中。由于区块链领域迭代速度快,专业词汇或者标准,都是在研究创新和工程落地过程中不断变化的。在这样的背景下,很多项目会采用「造概念」/「蹭概念」的方式获取差异化和关注度,已然成为业内潜规则。

比如,许多原本活跃于以太坊/Celestia生态的模块化区块链项目,也乘着东风之便,搭上了“比特币Layer2”的快车,并自封为“Rollup”,但其技术方案往往不符合Rollup的标准。

但是,“Rollup”这样的词汇具有较高的被认可度,打着“Rollup”旗号更利于宣传。许多项目方要么是硬蹭(自封为Rollup),要么是分叉主流的Rollup概念(加个暧昧的定语,比如主权Rollup)。

但扒开其“XX Rollup”的外衣一看,很多项目的工作原理,还是单纯的“客户端验证”或“侧链”,只是在借着“XX Rollup”的宣传口号给自己牟方便。这种宣传方式虽然比较普遍,但往往带有误导性,对于追求真相的广大群众而言,带来的坏处要多于益处。

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

那我们该如何鉴别此类“蹭Rollup概念”的行为呢?

或许,从第一性原理出发,根据西方乃至业界广泛认可的标准,来定义不同Layer2项目的方案类别与安全程度,以及功能完备性,才能让我们开启雾里看花时的那双“万花筒写轮眼”。或者说,采用什么方案不是最重要的,核心在于项目在机制设计上,能否确保Layer2网络安全可靠,能否真正意义赋能BTC主网。

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

下面,我们打算以Chainway这个老外做的比特币Layer2为案例,剖析部分项目在“Rollup”宣传口号背后,隐藏着的“客户端验证”本质。我们可以更清晰的看穿,"主权Rollup"和"客户端验证",与业界主流意义上的ZKRollup,或OPRollup等依赖于智能合约实现的Rollup方案的明显差异。

当然,这并不是说,主权Rollup或客户端验证就不如ZK Rollup安全可靠,一切都要看其具体的细节实现。Chainway虽然是典型的客户端验证型Layer2,但其提出了“在BTC触发+在链下验证”的抗审查交易方案,并采用了类似于MINA公链的递归ZK Proof,领先于多数比特币Layer2。

我们认为,对Chainway的技术调研是比较有价值的,这对于广大比特币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,效果等价于发布完整的、可验证的交易数据。

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

但由于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项目却是赤裸裸的“客户端验证”,独立客户端/节点之间没有什么可靠的消息传递。

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

为了更好的理解“主权Rollup”这个独特的概念,我们可以把主权Rollup与其对应的智能合约Rollup相比较。以太坊上的Layer2基本都是智能合约Rollup,如Arbitrum和StarkNet等。智能合约Rollup的结构可以参考下图:

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

在上图中,我们可以看到模块化区块链叙事的几个术语,解释如下:

Execution执行层: 执行用户交易,更新区块链状态,向DA层和结算层提交数据

Settlement结算层: 验证执行层的状态转换,解决争议(如欺诈证明),并提供桥模块来处理L1-L2桥接资产

DA层: 一个大号公告板,接收执行层提交的状态转换数据,把这些数据去信任的提供给任何人

Consensus共识层: 确保交易排序的最终性,与DA层的职能似乎比较接近(以太坊社区对模块化区块链的分层方式,不包含共识层)

从智能合约Rollup的架构中,我们看到除了执行层外,其他三层的职能都由以太坊承担。下图更详细的展示了以太坊在智能合约Rollup中承担的角色。

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

以太坊上的Rollup合约会接收 validity proof(有效性证明) 或者 fraud proof(欺诈证明) ,以此验证Layer2状态转换的有效性。值得一提的是,此处的Rollup智能合约实际上就是模块化区块链中的结算层实体。结算层合约往往会包含桥接模块,用于处理以太坊桥接到Layer2的资产。

而对于DA,结算层合约可以强制要求排序器Sequencer 把最新的交易数据/状态变化细节上链,如果不把DA上链,就无法顺利更新Rollup合约上记录的L2状态。

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

我们可以看出,智能合约Rollup严重依赖于Layer1上的智能合约,对于BTC这种难以支持复杂业务逻辑的Layer1而言,基本无法构造出向以太坊Rollup“对齐”的Layer2。

主权Rollup方案干脆不需要Layer1上的合约进行状态验证/桥接处理。其架构如下图:

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

我们可以看到,在主权Rollup中,由DA层之外的节点群体作为交易执行和结算操作的实体,具备更高的自由度。其具体的工作流程如下:

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

主权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”宣传口号不符合。

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

最后,让我们简单归纳一下主权Rollup和智能合约Rollup的不同之处:

第一,可升级性。智能合约Rollup的更新迭代,涉及到智能合约的update,需要开发团队使用可升级合约。这种智能合约的升级权限一般由Rollup开发团队用多签控制。而主权Rollup的升级规则,类似于常规区块链的软硬分叉,节点可以自行选择更新版本,不同客户端可以选择是否接受升级。从这一点来看,主权Rollup要比智能合约Rollup更优越。

第二,桥。智能合约Rollup的桥,在理想条件下是符合信任最小化的,但是合约的可升级性会影响其安全。而主权Rollup方案下,需要开发者自己在Layer1链下构造桥接组件,构造出的桥十有八九不会像智能合约桥一样去信任。

BTC DA 构造

在上文中,我们提到,要实现基于BTC的主权Rollup,核心在于使用Ordinals协议将BTC作为DA层。Chainway就用了这种方案。

我们可以观察一笔来自Chainway排序器的DA数据提交,其交易哈希为:

24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000,示意图如下:

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

这笔交易的脚本代码,借鉴了 Ordinals Protocol 中使用 OP_0 OP_IF 实现数据写入的方案,将 Rollup的DA数据写入了BTC链(发布状态变化+ZK Proof,在安全性上等价于发布原始交易数据,但数据尺寸可以极大程度压缩)。

当然,除了 DA 数据外,排序器也在交易内写入了一些鉴权数据,最重要的就是 Rollup 排序器使用自己的私钥对 DA 数据进行签名,确保该笔 DA 数据提交是排序器提交的。

此处我们还要注意,任意一笔涉及DA数据提交的交易,交易哈希尾部都存在16个二进制的 0(也就是连续2个字节均为0) 。在代码内,我们可以看到此限制:

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

前面的示例交易图中的随机数 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为例,解读比特币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为例,解读比特币Layer2项目是怎么蹭概念的(一)

总而言之,Chainway客户端/节点会同步BTC主网区块,并从中,扫描出Chainway排序器发布的“DA数据”,确认这些数据是由指定的排序器发布的,且的确包含了所有提交到BTC链上的“Chainway规范交易”。

不难看出,只要用户能够构造出一笔符合限制条件的“规范交易”,并提交到BTC链上,这笔交易最终会被包含进Chainway客户端本地的L2账本中,不然Chainway排序器发布的L2 block会被客户端拒收。

如果配合可靠的链下共识/警报消息传递,Chainway的抗审查交易方案,就趋近于理想化的主权Rollup的抗审查方法。比如部分主权Rollup方案曾明确表示,遇到无效区块,会在链下客户端之间广播Alert警报信息,来增强安全性,尤其让无法同步完整DA数据的轻客户端也知道网络状态异常。

如果一个区块没有如实包含“强制交易”,显然会触发链下警报广播,但目前Chainway还没有实现这一块(至少目前公布的资料和代码库,显示它没有去做这块的技术实现)。

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

 

即便是实现了链下客户端/节点间的共识,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为例,解读比特币Layer2项目是怎么蹭概念的(一)

Chainway网络的排序器在处理完用户交易后,生成最终的ZK证明,连带不同账户的状态变化细节 state diff,发布到BTC链上。而全节点会同步BTC上发布的Chainway所有历史数据。每一次ZK证明不仅要对当前区块的状态转换过程进行证明,也要保证上一个区块的ZK证明有效。

基于上述方案,我们可以发现每次生成新的证明,实际上都对上一个证明进行了确认,依次递归,最新的一个ZK证明就可以保证从创世区块开始的所有ZK证明都有效。这个设计就类似于MINA。

当一个仅同步区块头的“轻客户端”,也就是轻节点加入网络时,仅需要验证BTC上披露的最新一个ZK Proof有效,就可以确认整条链的历史数据、所有的状态转换是有效的。

假如排序器作恶,故意不接受强制交易,或者不使用上一次ZK证明进行递归证明,则生成的新的ZK证明无法被客户端接受(生成了也不被认可),如下图:

以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)

总结

正如本文最开始的总结,Chainway本质上是一个使用BTC作为DA层的主权Rollup/客户端验证方案。为了提高 Rollup 的抗审查性,Chainway引入了强制交易的概念。另一方面,Chainway使用了递归ZK证明技术,使得新进入的节点可以更加信任排序器的输出结果,随时确认整条链的历史数据无误。

Chainway目前的问题在于跨链桥部分该如何去信任,由于其采用主权Rollup方案,没有说明在跨链桥方案上,打算如何解决技术细节,还难以判断其最终的安全性究竟如何。

今天,我们通过深入分析Chainway的技术方案,发现该项目社区所宣传的技术类型,并不是主流意义上的Rollup。考虑到当前比特币Layer2项目已达数十个(半年后可能上百个),为了降低大家对技术名词的认知成本,我们将持续的在Layer2方案分类和安全标准、功能完备性测评标准上深入调研,敬请期待!

承接区块链项目定制开发

微信:btc9767

QQ :1330797917

TELEGRAM: BTCOK9

承接区块链项目定制开发


qklbishe.com区块链毕设代做网专注|以太坊fabric-计算机|java|毕业设计|代做平台-javagopython毕设 » 以Chainway为例,解读比特币Layer2项目是怎么蹭概念的(一)