BEVM 创始人自述：为什么以及如何做 BTC Layer2？

本文详细解答了作为 BTC L2 技术发展的一个关键里程碑，BEVM 是如何在技术层面实现 BTC 未来的去中心化生态繁荣。

撰文：Peter

前言

自 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 费用计算货币。