致敬 BTC 从诞生以来的 3次伟大的革命技术迭代
- 2009 年： BTC 的出生， 首次 用区块链的结构 跑起来了去中心化 的货币应用。
- 2017 年： BTC 隔离见证升级， 最大支持 4MB的存储，解决了BTC的链上存储问题， 这就为现在的爆火的 Ordinal 协议（发行资产）提供了依据。
- 2021 年： BTC Taproot 升级， 支持了BTC 门限签名算法，这给完全去中心化的 BTC Layer2 技术提供了底层支持。
为什么要做 Bitcoin 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 Layer2 ？
比特币改进提案（BIPs）是为比特币引入新功能和信息的设计文档，而 Taproot 升级则是三个 BIPs 的汇编，这三个 BIPs 分别是 Schnorr 签名(BIP 340)、Taproot (BIP 341)和Tapscript (BIP 342)，这三个升级统称为 BIP Taproot，它将为比特币带来了更高效、更灵活、更私密的传输方式，其核心在于使用了 Schnorr 签名和 Merkel 抽象语法树(MAST)。
Schnorr 签名是一种以其简单性和安全性而闻名的数字签名方案。Schnorr 签名在计算效率、存储和隐私方面具有多项优势。
如图1是Schnorr聚合签名的交互流程。用户通过公钥确认签名者身份，通过数据确认契约内容，从而来认证数字契约的有效性。Schnorr 聚合签名可以将多个签名数据压缩合并成单个聚合签名。验证者通过所有签名相关的数据和公钥组成的列表对单个聚合签名进行验证，若验证通过，其效果等同于对所有相关签名进行独立验证且全部通过。
当前大多数区块链采用 ECDSA 多签算法。针对区块数据，每个节点用自身私钥生成独立的数字签名，并广播给其他节点。其他节点会验证该签名，并将其写入下一区块数据中。使用这种方式，当共识节点数较多时，会导致每轮共识区块存储的签名数据不断增加，占用存储空间。每当新节点加入网络，需要同步历史区块时，大量签名数据会对网络带宽造成很大的挑战。
使用聚合签名技术后，每个节点会收集其他节点广播的聚合签名分片，然后将签名分片聚合保存，如图2。这样，当新节点加入时，同步历史区块只需下载聚合后的签名数据，大大减少对网络带宽的占用，同时减少交易费用的支出。
此外，密钥聚合还使所有的 Taproot 输出看起来类似。无论是多重签名输出、单签名输出或者其他复杂智能合约在区块链上看起来都长得是一样的，所以许多区块链分析将不可用，从而为所有 Taproot 用户保留隐私。
MAST(Merkle Abstract Syntax Tree) 是使用默克树来加密复杂的锁定脚本，其叶子是一系列相互不重叠的脚本（比如，多重签名或时间锁）。支出时，只需披露相关脚本以及从该脚本通向默克树根的路径。如图3，要使用 script 1，只需披露 script 1、script 2 以及 hash 3 即可。
MAST 的主要优点包括：一是支持复杂的支出条件。二是不用披露未被执行的脚本或未被触发的支出条件，提供更好的隐私保护。三是压缩交易大小。随着脚本数量的增加，非 MAST 交易大小是线性增长，而 MAST 交易大小是对数增长。
然而，在 Taproot 升级中有一个问题，那就是 P2SH 与常见的支付到公钥的哈希（Pay-to-Public-Key-Hash，P2PKH）在表现上不一样，仍然有隐私保护问题。有没有可能让 P2SH 和 P2PKH 在链上看起来一样？
为此，Taproot 提出了一套解决方案，对于有限数量签名者的脚本，可以分解成两部分：第一部分是多重签名，所有签名者都同意某一支出结果，称为「协作式支出」；第二部分称为「非协作式支出」，可以有非常复杂的脚本结构。这两部分是「或」的关系。
如图3，Script 3 是一个 2-of-2 型多重签名，需要 Alice 和 Bob 两人都签名才有效，是「协作式支出」；Script 1 和 2 是「非协作式支出」。「协作式支出」和「非协作式支出」，都能够花费这笔输出，其中：
-（1）对“非协作式支出”脚本，采取上述 MAST 的方式，用 MerkleRoot 表示默克树根。
-（2）对“协作式支出”脚本，采取基于 Schnorr 签名的多重签名算法。用 Pa 和 Pb 分别表示 Alice 和 Bob 的公钥，用 Da 和 Db 分别表示 Alice 和 Bob 的私钥。因此，聚合公钥公钥是 P=Pa+Pb，对应的私钥是 Da+Db。
-（3）将“协作式支出”与“非协作式支出”合在一起表示成P2PKH形式，其公钥是：P=P+H（P||MerkleRoot）G；对应的私钥是 Da+Db+H(P||MerkleRoot)。
-（4）当 Alice 和 Bob 同意“协作式支出”，他们用 Da+Db+H(P||MerkleRoot)（只需他们中的一个人在自己的私钥上加上 H（P||MerkleRoot））即可。在链上，这表现得如同 P2PKH 交易，有一个公钥和对应的私钥，而不需要披露底层的 MAST。
BTC 完全去中心化的 layer2 方案： BTC 轻节点 + 分布式门限签名合约
在本方案中，选取n（n可以取值为BEVM上所有的验证人）个固定的验证人完成分布式门限签名的BTC 链上聚合托管合约。BEVM layer2 中的每个验证人的出块私钥 同时衍生出BTC 的门限签名的聚合私钥的一部分， n个验证人的 门限私钥组合成 BTC的聚合签名合影地址。n的最大取值范围可以到 1000 甚至更多。
- 当用户 A 想将 BTC 跨链到 BEVM，只需要用户向 Bitcoin 聚合托管合约发送 BTC，用户就能在 BEVM layer2 上收到 BTC。
- 相应地，用户 A 进行提现操作时，只需要 n个验证节点中组成聚合签名中的m个自动完成分布式门限签名合约互操作，就能在 Bitcoin 上完成从托管合约到用户 A 的转账，转账完成的同时，会在 BEVM上进行 BTC 的销毁。
如何实现 BTC 作为 原生Gas 费用 且兼容EVM 的 Layer2 ？
EVM 原理
以太坊虚拟机是以太坊智能合约的运行时环境。它不仅是沙盒封装的，而且实际上是完全隔离的，这意味着在EVM中运行的代码无法访问网络、文件系统和其他进程。甚至智能合约之间的访问也是受限的。
以太坊底层通过EVM模块支持合约的执行与调用，调用时根据合约地址获取到合约代码，载入到EVM中运行。通常智能合约的开发流程是用solidlity编写逻辑代码，再通过编译器编译成字节码，最后再发布到以太坊上。
EVM主要部分
EVM Code
EVM代码是以太坊虚拟机代码， 指以太坊可以包含的编程语言的代码。与帐户相关联的EVM 代码在每次消息被发到这个账户的时候被执行，并且具有读/写存储和自身发送消息的能力。
Mchine State
Mchine State是执行evm代码的地方，包含程序计数器、堆栈和内存。
Storage
Storage是一个可读、可写、可修改的持久存储的空间，也是每个合约持久化存储数据的地方。Storage是一个巨大的map，一共有2^256个插槽，每个插糟有32byte。
以BTC作为Gas费用
让从Bitcoin 网络转过来的 BTC 作为EVM的 上交易 执行的 Gas费用计算货币。