Tech Talk:走难行之路 - 共建 Bitcoin Layer 2 开发者生态
ScaleBit
2024-04-19 18:16
订阅此专栏
收藏此文章


本篇 Tech Talk 由 ScaleBit 研究团队的 Zorrot 演讲并撰写


TL;DR


全球首个聚焦 Bitcoin Layer 2 前沿发展与技术探讨的主题峰会 — Bitcoin Layer 2 香港主题峰会近日圆满落幕。会上,众多重点关注 Bitcoin Layer 2 的东西方创新思维齐聚,分别带来精彩的主题演讲。

 

其中,来自 BitsLab 旗下子品牌区块链安全团队 ScaleBit 的区块链研究员 Zorrot Chen 以「We Choose the Hard Way: Developing in the Bitcoin Ecosystem」为主题,探讨了 Bitcoin 开发者生态现状以及 Taproot 升级之后的变化,并且提出 OpenTap,一个包含了 Tapscript 构建以及完整测试用例的开源仓库。我们还演示了基于 Taproot 地址的多签资产桥 Demo。现在,我们将 Tech Talk 整理成文,以供更多 Bitcoin Layer 2 开发者和爱好者参考。


01

前言


Bitcoin 开发者生态向来较为深藏不露,相较于 Ethereum 等其他公链,拥有大量的教程,无数的案例以及成熟的 IDE 和开发测试工具,Bitcoin 生态尽管高手云集,但还未形成统一的开发共识。当然,这并不是由于 Bitcoin 的开发者不够精进,而是由于在 Bitcoin 上进行开发,本身就比其他的公链上更加困难。

 

对于以脚本开发为主的智能合约,开发者无需对区块链的运作原理非常了解,也能够写出高质量的项目;而 Bitcoin 开发则大部分需要面对客户端和交易等底层代码和原始操作,使得开发者必须对 Bitcoin 的概念和结构非常有经验,才能够顺利的进行开发。这些因素都使得基于 Bitcoin 进行开发变的非常“不友好” - 没有统一的解决方案,没有整合的测试环境,也没有足够多的教程和代码作为参考。同时,成熟 Bitcoin 开发者往往更加专注于自己所在的项目,并且非常激进地突破着一些困难的问题(比如最近的 Covenant,BitVM)而导致社区中更加普遍的开发需求遇冷。

 

但是这种情况随着 Bitcoin Layer 2 生态的成长而逐渐开始改善,许多项目方都意识到,Bitcoin 生态无法得到最佳释放,除去资金本身的效率和运转,开发者是否能够顺利的加入到生态中并贡献他们的想法,也是成败中极为关键的一环。我们很高兴能够看到许多项目如 Stacks,QED Protocol,UniSat,OKX 等等都开放了许多自 Taproot 升级之后比较时髦的功能以及它们对应的工具。但作为安全公司,我们更加注重代码层面的案例,并且我们也注意到,Taproot 升级之后带来了 Bitcoin 脚本,即 Tapscript 这一全新概念。传统的 Bitcoin 开发更加集中于构造交易,验证数据;而 Bitcoin Layer 2 的开发则无可避免的需要涉及到 Tapscript 的构造以及解锁。因此,我们希望能够在这一领域进行实践,为更多的开发者带来这一新概念的理解和便利。


02

基于 Taproot 地址的多签资产桥


资产桥对于绝大多数的 Bitcoin Layer 2 项目都是一个无法回避的问题。所谓资产桥,实际上是一个特殊的 Bitcoin 地址。当用户希望将他们的资产转移到 Layer 2 上的时候,实际上是将资产投入了这个地址;项目方会在确认了投入交易之后,在二层为用户增发对应的代币;反之提取的时候,则是用户在二层进行销毁,项目方在一层控制这个地址向用户退回对应的资产。


在 Taproot 升级之前,Bitcoin 采用了 OP_CHECKMULTISIGVERIFY 操作码来控制一个多签地址,但是最多仅能够支持 16 个地址。因此,曾经的资产桥往往会采用 MPC 的方案进行管理。当然,这种方案在托管方可靠的情况下是安全的。但这个方案被许多 Bitcoin 开发者诟病,认为它过于中心化,并且也产生过监守自盗的例子。在 Taproot 升级之后,Bitcoin 支持了 Schnorr 签名,这使得其验证效率大幅提升。进一步,通过新的操作码 OP_CHECKSIGADD,Layer 1 能够支持最多 999 个多签验证;这也就意味着,秘钥的持有人可以极大程度上的被分散,并且以去中心化的方式交互,这使得去信任的资产桥成为了可能。


03

不只是仓库,更是可运行的案例


但是当许多开发者和项目方“摩拳擦掌”的时候,他们发现了一件很尴尬的事情 - 那就是,他们没有办法找到一个完整的代码,告诉他们应该如何建立这个跨链桥。是的,Taproot 升级从 2020 年开始,如今已经过去了将近 4 年,也诞生了许多开源的仓库,告诉你应该如何构建 Taproot 地址以及其中的 Tapscript。但是这些代码都存在同一个问题,它们太过于分散了。尽管它们分别对 Taproot 中的不同技术进行了概念验证,例如,你可以在 A 项目中找到如何构建 PSBT,在 B 项目中找到如何构建 Taproot 地址,在 C 项目中找到 MuSig 协议的运作…… 但是你很难将它们全部组合到一起。


正如我们先前提到的那样,在进行 Bitcoin 开发的时候,你必须对 Bitcoin 所有的细节都非常了解。因此这就产生了一个特殊的困境:尽管所有代码组件都是开源的,是可以被找到的,但是想用它们做出一个可用的项目,依然非常困难;而且最令人难受的是,没有任何教程告诉你应该怎么去做。我们也知道,对于一个经验丰富的 Bitcoin 开发者而言,他会说:答案是显而易见的,你只要将他们组合起来就好,并且不屑于帮助你完成这些愚蠢又简单的工作。但你确确实实被困住了。

 

你不必自责,这实际上是 Bitcoin 生态固有的问题:缺乏完整的代码,完整的测试环境,完整的案例。“完整”,是理解代码以及模块运作最基本的条件之一。我们注意到了这些沉默的大多数,发现了他们一直在基础的问题上挣扎,苦于没有好的案例供他们学习,以及进行进一步的开发。因此我们决定解决这个问题:我们基于 Node.js,构建了一套完整的,Taproot 多签跨链桥的 Layer 1 解决方案。它能够被作为一个库,其中已经封装好了我们认为非常实用的一些函数和模块。更多的,它还是一个完整的演示,包括如何构建测试环境,使用区块浏览器进行可视化,发送 RPC 交易与 Bitcoin 节点互动,并且当然,能够建立一个完整的 Taproot 资产桥。


04

构建跨链桥和项目实例


实际上,对于 Taproot 资产桥的原理,BIP-0341 以及许多极好的文章都已经讲述过了它的原理,我们尤其推荐 Taproot-Workshop,一个由 Bitcoin Optech 开源的仓库。其中包含了大量关于 Taproot 关键技术的介绍以及代码。一般来说,构建一个 Tapscript 脚本需要经过多个步骤:

(1)创建秘钥对,并且对密钥对进行调整(tweak)

(2)创建该地址中可能会用到的脚本,它通常会是多个脚本组成的,因此其也可以被称为 Taptree

(3)通过密钥对和脚本共同构建一个 Taproot 地址

(4)处理转账逻辑和解锁脚本

(5)通过 RPC 命令构建和发送交易

 

显然,其中关键主要在于Taptree 的构建。就目前而言,一般构建多签脚本会采用三种不同的方案,其分别是单叶子节点,多叶子结点,以及聚合签名方案。严格来说,这些方案尽管都能够构建多签地址的需求,但是其也有优劣之分。最简单的方案就是和单叶子节点方案:通过反复地在脚本中加入 OP_CHECKSIGADD 操作码,来构建单个多签解锁脚本,如下图所示:


这个方案虽然简单,但是它实际上能够很好地完成任务,并且易于理解。因此我们实现了这个方案,并且也推荐在不太复杂的情形下(例如 3-2 的门限签名)使用这个方案。但是其拥有一个显著的缺点,就是会很大程度上暴露隐私。由于它采用了单个叶子节点,因此所有的公钥都会随着交易一起被显示在链上。这样一来,任何人都能够看到这个脚本的签名者构成 - 当然,这不会直接影响其安全性;但可能会产生利用社会工程学手段的隐患。

 

为了解决这个问题,产生了第二种方案。即对于一个 m-n 的门限签名,需要将其每一种 m-m 的签名组合都作为 Taptree 当中的一个叶子结点,并最终拼接为一个巨大的 Taptree。这种方式能够比较好的保护隐私,因为解锁一个 Taproot 地址的时候,只会使用一个叶子节点。这样一来,其只会暴露 m-m 个公钥地址,就很好地保护了其他的公钥,如下图所示:


这个方案实际上已经能够起到较好的效果了。但它存在两个问题,第一,它的构建难度显然相较于单叶子结点方案要复杂非常多。其不仅需要构建许多分支,而且还需要有方法跟踪每一个不同的解锁脚本,否则即使成功构建了 Taproot 地址,也没有办法控制它。幸运的是,这个问题我们已经帮助你解决了。你可以非常方便地通过我们提供的 bridge builder 模块来建立这样的脚本树。你只需要填写所需的秘钥以及门限,就可以获得一个完整且准确的 Taptree,同时我们为每一个分支都进行了编号,你可以通过它们的序号进行追踪并进行解锁。

 

通过我们的库,可以非常快速地完成多叶子多签方案,但这个方案实际上还存在第二个问题:当公钥太多的情况下,计算所有的解锁组合会让最终的 Taptree 分支过多,导致计算开销过大。因此,它还不是最终的解决方案。

 

实际上还存在一种更好的方案,即聚合签名方案。由于 Taproot 之后支持了 Schnorr 聚合签名,因此除去使用 OP_CHECKSIGADD,事实上完全可以令所有的公钥持有者完全在链下进行秘钥的聚合以及签名。通过类似于 MuSig 以及 MuSig2 这类的协议,节点完全能够通过单个公钥直接构建资产桥,并且用单个签名进行解锁,如下图所示:


这个方案具有极大的优点,除去一个担忧:整个聚合过程都在链下,因此存在潜在的泄露风险(用户可能不会严格的采用 MuSig 之类的协议)。但是除此之外,它能够为 Taproot 地址提供终极的隐私性。当然,它非常难以构建,因为 MuSig 和聚合签名与 Tapscript 严格来说完全是两件不同的事情,并且 MuSig 协议也较为复杂,包含了节点之间的多轮的通信。但是再次,幸运的是,我们已经帮助大家整合了 MuSig2,并且将其封装为了非常易于操作和理解的函数,能够令开发者立刻将 MuSig 移植到它们的资产桥当中。

 

最后,我们还需要一个逃生舱。当 Layer 2 网络失效之后,用户显然需要一个方法将它们的资产撤回到自己的账户中。这点可以通过一个包含了 OP_CHECKSEQUENCEVERIFY 操作码的脚本,并作为 Taptree 的一个分支来完成。如下图所示:


通过这些所有的元素,我们非常肯定你可以通过这个库建立你所需要的任何 Tapscript 脚本,包括多签钱包,资产桥,以及条件支付地址等。于此同时,你也可以通过我们提供的 Demo 进行快速学习,并且通过整个测试和可视化环境来调试你的代码。


05

共建 Bitcoin Layer 2 生态


最后,在完成了这些工作之后,我们并没有感到满足。相反,我们注意到了 Bitcoin Layer 2 生态中,事实上存在着许多非常有趣的脚本,例如铭文,符文,Atomical 协议等等。我们接下来会探索更多的脚本以及它们的最佳实践。于此同时,我们当然会将我们的成果开源,在确保他们足够安全和规范之后。并且,我们希望邀请你一起参与到这些代码的建设当中,通过一起为 Tapscript 进行建设,让 Bitcoin Layer 2 生态对开发者更加友好。

 

ScaleBit,BitsLab 旗下子品牌,作为 Web3 领先的区块链安全团队,分布于硅谷、新加坡、香港、台湾等地。我们已为全球 Web3 200+ 个机构和项目提供了区块链安全解决方案,累计审计代码 180,000+ 行,累计保护用户资产超过 80 亿 + 美元。Make Security Accessible for All!若您有任何安全审计需要,欢迎随时与我们取得联系,我们将为您定制细致、全面、专业的安全解决方案,护航您和 Web3 安全无虞!


关于 ScaleBit



ScaleBitBitsLab 旗下子品牌,是一个为 Web3 Mass Adoption 提供安全解决方案的区块链安全团队。凭借在区块链跨链和零知识证明等扩展技术方面的专业能力,我们主要为 ZKP、Bitcoin Layer 2  和跨链应用提供细致和尖端的安全审计。ScaleBit 团队由在学术界和企业界都有丰富经验的安全专家组成,致力于为可扩展的区块链生态系统的大规模应用提供安全保障。


https://www.scalebit.xyz/

https://twitter.com/scalebit_


END


击卡片,关注 ScaleBit ~

【免责声明】市场有风险,投资需谨慎。本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资,责任自负。

ScaleBit
数据请求中
查看更多

推荐专栏

数据请求中
在 App 打开