前言

自2009年BTC的问世以来，经历三次技术迭代的比特币已经从简单意义上的数字原生资产概念，发展成为具有复杂功能和应用的去**化金融系统。

本篇文章则是由BEVM创始人编写，分享了他对BTC技术演进过程中鞭辟入里的见解，同时也详细解答了作为BTC Layer2技术发展的一个关键里程碑的BEVM，是如何在技术层面实现BTC未来的去**化生态繁荣。

通过本篇文章，您将详细了解到：

1.BTC Layer2的必要性

2.如何实现BTC Layer2？

3.**去**化的BEVM解决方案

致敬BTC从诞生以来的3次伟大的革命技术迭代：

2009年：BTC诞生，**用区块链的结构打通了去**化的货币应用。

2017年：BTC隔离见证升级，支持了**4MB的存储，解决了BTC的链上存储问题。这也为现在的爆火的Ordinals协议（发行资产）提供了依据。

2021年：BTC Taproot升级，支持了BTC门限签名算法，这给**去**的BTC Layer2 技术提供了底层支持。

一，为什么要做BTC Layer2？

1.有需求：Bitcoin网络满足了资产登记的需求，但仍有大量的资产需要进行链上结算（Layer2）

当前ETH的Layer2都只是ETH Layer1的Copy，没有解决什么Layer1解决不了，非得Layer2去解决的实际业务问题。

非得说ETH Layer2解决了ETH Layer1的问题是：Layer2解决了Layer1 Gas费用贵的问题。也正因为这一需求，成就了ETH**大Layer2 Arbitrum上的衍生品应用，如GMX。

而BTC的Layer2不像ETH Layer2一样无关紧要。

因为BTC非图灵**的链上虚拟机只能给资产做登记 ，而不能做结算，所以BTC Layer1 必须需要图灵**的BTC Layer2来做BTC Layer1发行的资产的结算问题。

2.有能力：BTC能够做成**去**化的Layer2

在2021年BTC Taproot升级前，能够做到**去**化的BTC Layer2是不可能的。但是在这次升级后，BTC门限签名算法可以让BTC 支持**去**化的Layer2计算层。

二，如何实现去**化的BTC L2？

比特币改进提案（BIPs）是为比特币引入新功能和信息的设计文档，而taproot升级则是三个BIPs的汇编，这三个BIPs分别是Schnorr签名（BIP 340）、Taproot（BIP 341）和Tapscript（BIP 342），这三个升级统称为 BIP Taproot。

它将为比特币带来更**、更灵活、更私密的传输方式，其核心在于使用了Schnorr签名和Merkel抽象语法树。

Schnorr 签名是一种以其简单性和安全性而闻名的数字签名方案。Schnoor签名在计算效率、存储和隐私方面具有多项优势。

用户通过公钥确认签名者身份，通过数据确认契约内容，从而来认证数字契约的有效性。

Schnorr 聚合签名可以将多个签名数据压缩合并成单个聚合签名。

验证者通过所有签名的相关数据和公钥组成的列表对单个聚合签名进行验证，若验证通过，其效果等同于对所有相关签名进行独立验证且**通过。

当前大多数区块链都是采用ECDSA多签算法，针对区块数据，每个节点用自身私钥生成独立的数字签名，并广播给其他节点。其他节点会验证该签名，并将其写入下一区块数据中。

使用这种方式，当共识节点数较多时，会导致每轮共识区块存储的签名数据不断增加，占用存储空间。

每当新节点加入网络，需要同步历史区块时，大量签名数据会对网络带宽造成很大的挑战。

使用聚合签名技术后，每个节点会收集其他节点广播的聚合签名名片，然后将签名分片聚合保存，如图2.

这样，当新节点加入时，同步历史区块只需下载聚合后的签名数据，大大减少对网络带宽的占用，同时减少交易费用的支出。

此外，密钥聚合还使所有的Taproot输出看起来类似。无论是多重签名输出、单签名输出或者其他复杂智能合约在区块链上看起来都长得一样，所以许多区块链分析将不可用，从而为所有Taproot用户保留隐私。

MAST（Merkle Abstract Syntax Tree）是使用**树来加密复杂的锁定脚本，其叶子是一系列相互不重叠的脚本（比如，多重签名或时间锁）。

支出时，只需披露相关脚本以及从该脚本通向默克树根的路径。如图3，要使用script1，只需披露script1、script2以及hash3即可。

MAST的主要优点包括：

1）支持复杂的支出条件

2）不用披露未被执行的脚本或未被触发的支出条件，提供更好的隐私保护

3）压缩交易大小：随着脚本数量的增加，非MAST交易大小是线性增长，而MAST交易大小是对数增长。

然而，在Taproot升级中有一个问题，那就是P2SH与常见的支付到公钥的哈希（Pay-to-Public-Key-Hash，P2PKH）在表现上不一样，仍然有隐私保护问题。

有没有可能让P2SH和P2PKH在链上看起来一样？

为此，Taproot提出了一套解决方案，对于有限数量签名者的脚本，可以分解成两部分：

**部分是多重签名，所有签名者都同意某一支出结果，称为「协作式支出」。

第二部分称为「非协作式支出」,可以有非常复杂的脚本结构。

这两部分是「或」的关系。

如图3，Script3是一个2-of-2型多重签名，需要Alice和Bob两人都签名才有效，是「协作式支出」，Script1和2是「非协作式支出」。

「协作式支出」和「非协作式支出」，都能够花费这笔输出，其中：

1）对“非协作式支出”脚本，采取上述MAST的方式，用MerkleRoot表示默克树根。

2）对“协作式支出”脚本，采取基于Schnoor签名的多重签名算法。用Pa和Pb分别表示Alice和Bob的公钥，用Da和Db分别表示Alice和Bob的私钥。

因此，聚合公钥是P=Pa Pb，对应的私钥是Da Db。

3）将“协作式支出”与“非协作式支出”合在一起表示成P2PKH形式，其公钥是：PP H（P||MerkleRoot）G；对应的私钥是Da Db H(P||MerkleRoot)。

4）当 Alice 和 Bob 同意“协作式支出”，他们用 Da Db H(P||MerkleRoot)只需他们中的一个人在自己的私钥上加上 H（P||MerkleRoot）即可。

在链上，这表现得如同 P2PKH 交易一样，有一个公钥和对应的私钥，而不需要披露底层的 MAST。

三. 我们的**去**化的BTC layer2 方案：

3.1 BTC轻节点 分布式门限签名合约

在本方案中，选取n个（n可以取值为BEVM上所有的验证人）固定的验证人完成分布式门限签名的BTC 链上聚合托管合约。

BEVM layer2 中的每个验证人的出块私钥 同时衍生出BTC 的门限签名的聚合私钥的一部分， n个验证人的 门限私钥组合成 BTC的聚合签名合影地址。n的**取值范围可以到 1000 甚至更多。

1)当用户 A 想将 BTC 跨链到 BEVM，只需要用户向 Bitcoin 聚合托管合约发送 BTC，用户就能在 BEVM layer2 上收到 BTC。

2)相应地，用户 A 进行提现操作时，只需要 n个验证节点中组成聚合签名中的m个自动完成分布式门限签名合约互操作，就能在 Bitcoin 上完成从托管合约到用户 A 的转账，转账完成的同时，会在 BEVM上进行 BTC 的销毁。

3.2 实现BTC 作为原生Gas费用且兼容EVM 的 Layer2

1）EVM 原理

以太坊虚拟机是以太坊智能合约的运行时环境。它不仅是沙盒封装的，而且实际上是**隔离的。

这意味着在EVM中运行的代码无法访问网络、文件系统和其他进程。甚至智能合约之间的访问也是受限的。

以太坊底层通过EVM模块支持合约的执行与调用，调用时根据合约地址获取到合约代码，载入到EVM中运行。通常智能合约的开发流程是用solidlity编写逻辑代码，再通过编译器编译成字节码，**再发布到以太坊上。

2）EVM 主要部分

3）EVM Code

EVM代码是以太坊虚拟机代码， 指以太坊可以包含的编程语言的代码。与帐户相关联的EVM 代码在每次消息被发到这个账户的时候被执行，并且具有读/写存储和自身发送消息的能力。

4）Mchine State

Mchine State是执行evm代码的地方，包含程序计数器、堆栈和内存。

5）Storage

Storage是一个可读、可写、可修改的**存储的空间，也是每个合约**化存储数据的地方。Storage是一个巨大的map，一共有2256个插槽，每个插糟有32byte。

6）以BTC作为Gas费用

让从Bitcoin 网络转过来的 BTC 作为EVM的上交易执行的 Gas费用计算货币。