解读BitVM:如何在BTC链上验证欺诈证明?(执行EVM或其他VM的操作码)

BitVM无需on chain的数据,先在链下发布并存储,链上只存放Commitment(承诺)。

作者:雾月 & Faust,极客web3

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

导语:目前,比特币Layer2已经成为一股热潮,市面上自我定位为“比特币Layer2”的项目,据说已有数十家。其中,不少自封为“Rollup”的比特币Layer2,声称采用了BitVM白皮书提出的方案,使得BitVM成为比特币生态的显学。

但无奈的是,目前大多数关于BitVM的文字资料,都未能通俗的解释其原理。

本文是我们读过了BitVM只有8页的白皮书后,查阅了与Taproot、MAST树、Bitcoin Script相关的资料后,得出的简单总结。为了便于读者理解,其中一些表达方式与BitVM白皮书中阐述的内容不同,我们假定读者对Layer2有一些了解,并能够理解“欺诈证明”的简单思想。

先几句话概括BitVM的思路:无需on chain的数据,先在链下发布并存储,链上只存放Commitment(承诺)

发生挑战/欺诈证明时,我们只把需要上链的数据on chian,证明其与链上的Commitment存在关联。之后,BTC主网再校验这些on chian的数据是否有问题,数据生产者(处理交易的节点)是否有作恶行为。这一切都遵循奥卡姆剃刀原则——“若非必要,勿增实体”(能少on chain,就少on chain)

正文:所谓的基于BitVM的BTC链上欺诈证明验证方案,通俗总结:

1.BitVM的核心思路

首先,计算机/处理器,是一个由大量逻辑门电路组合成的输入-输出系统。BitVM的核心思路之一,是用Bitcoin Script(比特币脚本),模拟出逻辑门电路的输入-输出效果

只要能模拟出逻辑门电路,理论上就可以实现图灵机,完成所有可计算任务。也就是说,只要你人多钱多,就可以召集一帮工程师,帮你用功能简陋的Bitcoin Script代码,先模拟出逻辑门电路,再用巨量的逻辑门电路实现EVM或是WASM的功能。

(此截图来自于一款 教学游戏:《图灵完备》 ,其中最核心的内容,就是用逻辑门电路尤其是与非门,搭建出完整的CPU处理器)

有人曾将BitVM的思路比作:在《我的世界》里,用红石电路做一个M1处理器。或者说,相当于用积木撘出来纽约帝国大厦。

(据说,这是有人花了一年时间,在《我的世界》里搭出来的“处理器”)

2. 为什么非要用Bitcoin Script模拟EVM或WASM?

这样不是很麻烦吗?这是因为大多数比特币Layer2往往选择支持Solidity或Move等高级语言,而目前可以直接在比特币链上运行的,是Bitcoin Script这种简陋的、由一堆独特操作码组成的、非图灵完备的编程语言

(一段Bitcoin Script代码示例)

如果比特币Layer2打算像Arbitrum等以太坊Layer2一样,在Layer1上验证欺诈证明,极大程度继承BTC安全性,需要在BTC链上直接验证“某笔有争议的交易”或“某个有争议的操作码”。如此一来,就要把Layer2采用的Solidity语言 / EVM对应的操作码,放在比特币链上重新跑一遍。问题归结为:

用Bitcoin Script这种比特币native的简陋编程语言,实现出EVM或其他虚拟机的效果。

所以,从编译原理的角度去理解BitVM方案,它是把EVM / WASM / Javascript操作码,转译为Bitcoin Script的操作码,逻辑门电路作为“ EVM 操作码 ——> Bitcoin Script操作码”两者之间的一种中间形态(IR)。

(BitVM白皮书里,谈到在比特币链上执行某些“有争议的指令”的大致思路)

Anyway,最终模拟出的效果是,把原本在EVM / WASM上才能处理的指令,放到比特币链上直接处理 。这个方案虽然可行,但难点在于,如何用大量的逻辑门电路作为中间形态,表达出所有的EVM / WASM 操作码op code。而且,用逻辑门电路的组合,直接表达某些极为复杂的交易处理流程,可能产生巨大的工作量。

3.与Arbitrum高度相似的“交互式欺诈证明”

下面说下BitVM白皮书中提到的另一个核心,也就是与Arbitrum高度相似的“交互式欺诈证明”。

交互式欺诈证明会涉及到一个称为assert(断言)的词,一般而言,Layer2的提议者Proposer(往往由排序器充当),会在Layer1上发布assert断言,声明某些交易数据、状态转换结果,是有效无误的。

如果有人认为Proposer提交的assert断言有问题(关联的数据有误),就会发生争议。此时,Proposer和Challenger会回合式的交换信息,并对有争议的数据进行二分法查找,快速定位到某个粒度极细的操作指令,及其关联的数据片段。

对这个有争议的操作指令(OP Code),需要连带其输入参数在Layer1上直接执行,并对输出结果作出验证(Layer1节点会把自己计算得到的输出结果,与Proposer之前发布的输出结果进行对比)。在Arbitrum里,这被称为“单步欺诈证明”。

(Arbitrum的交互欺诈证明协议中,会通过二分法检索Proposer发布的数据,尽快定位到有争议的那条指令及执行结果,最后发送单步欺诈证明到Layer1,进行最终验证)

参考资料:前Arbitrum技术大使解读Arbitrum的组件结构(上)

(Arbitrum的交互式欺诈证明流程图,阐述的比较粗糙)

到了这里,单步欺诈证明的思路很好理解了:绝大多数发生在Layer2的交易指令,不需要在BTC链上重新验证。但其中某个有争议的数据片段/操作码,在被人挑战时要在Layer1重放一遍。

如果检测结论为:

  • Proposer之前发布的数据有问题,则Slash掉Proposer质押的资产;

  • 如果是Challenger有问题,则Slash掉Challenger质押的资产。

  • 如果Prover长时间不响应挑战,也可以被Slash。

Arbitrum通过以太坊上的合约来实现上述效果,BitVM则要借助Bitcoin Script实现时间锁、多签等功能。

4.MAST树和Merkle Proof

简单讲完“交互式欺诈证明”与“单步欺诈证明”后,我们将谈及MAST树和Merkle Proof。

前面谈到,BitVM方案中,不会将Layer2在链下处理的大量交易数据/涉及的巨量逻辑门电路 直接on chain,只在必要时刻将极少数据/逻辑门电路on chian。

但是,我们需要某种方式,证明这些“原本在链下,现在要on chain”的数据,不是随手捏造的,这就是密码学中常提到的Commitment。Merkle Proof就是Commitment的一种。

首先,我们说下MAST树。MAST树全名为Merkelized Abstract Syntax Trees,是把编译原理里涉及的AST树,转化为Merkle Tree之后的形态

那么,AST树又是什么?它的中文名是“抽象语法树”,简单的讲,就是把一段复杂的指令,通过词法分析,细分为一堆基础的操作单元,然后组织为一棵树状的数据结构。

(一个AST树的简单案例,这棵AST树将x=2,y=x*3 这样的简单运算,细分为了底层操作码+数据)

而MAST树,就是把AST树Merkle化,以支持Merkle Proof。Merkle树有一个好处,就是它可以实现高效率的“数据压缩”。比如,你想在必要时,将Merkle树上的某段数据发布到BTC链上,但又要让外界确信,这个数据片段确实存在于Merkle树上,而不是你“随手拈来”的,怎么办?

你只要事先将Merkle树的Root记录在链上,在未来出示Merkle Proof,证明某段数据,存在于Root对应的Merkle树上,就行。

(Merkle Proof/Branch与Root之间的关系)

所以,无需将完整的MAST树存放在BTC链上,只需要提前披露其Root充当Commitment,在必要时出示 数据片段 + Merkle Proof /Branch即可。这种可以极大程度压缩on chain的数据量,且能保证on chain数据真的存在于MAST树上。而且,仅在BTC链上公开小部分数据片段+Merkle Proof,而不是公开所有数据,能起到很好的隐私保护效果。

参考资料:数据扣留与欺诈证明:Plasma不支持智能合约的原因

(MAST树示例)

BitVM的方案,尝试把所有的逻辑门电路用比特币脚本表达出来,再组织成一个巨大的MAST树,这棵树最底下的叶子leaf(图中的Content),就对应着用比特币脚本实现的逻辑门电路。

Layer2的Proposer,会频繁的在BTC链上发布MAST树的root,每棵MAST树,都关联着一笔交易,涉及其所有的 输入参数 / 操作码 / 逻辑门电路。某种程度上,这类似于Arbitrum的Proposer在以太坊链上发布Rollup Block。

当争议发生时,挑战者在BTC链上声明,自己要挑战Proposer发布的哪个Root,然后要求Proposer揭示Root对应的某段数据。之后,Proposer出示默克尔证明,反复在链上披露MAST树的小部分数据片段,直到和挑战者共同定位到有争议的逻辑门电路。之后就可以执行Slash。

图源

5.最后

到这里,BitVM整个方案最重要的部分基本讲完,虽然其中某些细节还是有点晦涩,但相信读者已经可以get到BitVM的精华与要旨。

至于其白皮书里提到的bit value commitment,是为了防止Proposer在被挑战并被迫在链上验证逻辑门电路时,给该逻辑门的输入值“既赋值0,又赋值1”,产生二义性混乱

总结

BitVM的方案,先用比特币脚本表达逻辑门电路,再用逻辑门电路表达EVM/其他VM的操作码,再用操作码表达任意一条交易指令的处理流程,最后组织成merkle tree/MAST树。

这样的一棵树,如果表达的交易处理流程很复杂,很容易破1亿个leaf,所以要尽量缩减Commitment占用的区块空间,以及欺诈证明波及的范围。

虽然单步欺诈证明,只需要onchain极小的一段数据和逻辑门脚本,但完整的Merkle Tree要长期存储在链下,以备有人挑战时,可以随时onchain树上的数据。

Layer2每笔发生的交易,都会产生一个大号Merkle Tree,节点的计算和存储压力可想而知,大多数人可能不愿意去运行节点(但这些历史数据可以被过期淘汰,而B^2 network专门引入类似Filecoin的zk存储证明,激励存储节点长期保存历史数据)

不过,基于欺诈证明的乐观Rollup,本身也不需要有太多节点,因为其信任模型是1/N,只要N个节点中有1个是诚实的,能够在关键时刻发起欺诈证明,Layer2网络就是安全的。

但是,基于BitVM的Layer2方案设计中,还存在许多挑战,比如:

1)理论上说,为了进一步压缩数据,不必直接在Layer1验证操作码,可以将操作码的处理流程再度压缩为zk proof,让挑战者对zk proof的验证步骤进行挑战。这样可以大幅度压缩on chain的数据量。但具体的开发细节会很复杂。

2)Proposer和Challenger要在链下反复产生交互,协议该如何设计,Commitment和挑战过程,该如何在处理流程上进一步优化,需要消耗很多脑细胞。

作者极客web3@eternal1997L
相关文章
2024.04.09 - 49 天前
详解 BitVM:比特币可编程性的曙光
尽管BitVM处于初期阶段,本质上是一个未落地的虚拟计算机概念,但已激发来自各个项目的大量兴趣和声明。
2023.10.20 - 221 天前
BitVM 与 RGB 协议:瞄准比特币生态的“双星”
BitVM意味着比特币现在可以像任何其他链一样具有图灵完备性:允许开发者在比特币上运行复杂的合约,而无需改变比特币基本规则。
2024.04.18 - 40 天前
Merlin 技术方案解读:它到底是怎么运转的?
让更多人理解 Merlin 的大致工作流程,对其安全模型有更清晰的认知。
2023.07.24 - 309 天前
全链游戏/自治世界(FOG/AW):游戏状态同步与技术挑战解析
对于完全运行在链上的游戏,区块链是游戏服务器并作为游戏状态的去中心化的信任源。
2023.07.24 - 309 天前
Rollup 升级背后的多签与委员会信任风险:L2 并不像许多人所想的那么“美好”
该如何降低多签和安全委员会带来的信任风险?
2023.06.27 - 336 天前
解读 zkSync 推出的 ZK Stack:L2 和 L3 齐头并进
ZK 技术解锁了现有非 ZK 解决方案无法实现的能力。
2023.06.25 - 338 天前
时间绑定代币:代币化的时限、所有权与收益,会给加密资产带来哪些新玩法?
时间绑定代币具体如何实现?又有哪些可实现的场景?
2023.06.01 - 362 天前
解读信标层:Rollup 网络安全与跨链转账的关键
本文探讨了以太坊Rollup网络中的Enshrined跨链桥以及AltLayer的信标层架构。
2023.05.30 - 364 天前
以钱包为中心,打造面向客户体验的技术栈
以钱包为中心的客户体验堆栈,是当前加密市场中最重要和最大的“挖掘”b2b 基础设施机会。
2023.05.29 - 365 天前
EIP-6963 概述:多钱包冲突的可能解决方案
EIP-6963 旨在增强多个钱包提供商之间的互操作性,降低新提供商的准入门槛,并改善以太坊网络上的用户体验。