Author: Peter

Foreword

Since the emergence of BTC in 2009, Bitcoin, which has undergone three technological iterations, has evolved from a simple concept of digital native assets to a decentralized financial system with complex functions and applications.

This article is written by the founder of BEVM, sharing his insightful views on the technological evolution of BTC, and also providing detailed explanations on BEVM, a key milestone in the development of BTC Layer2 technology, and how it achieves the decentralized ecological prosperity of BTC in the technical aspect.

Through this article, you will gain a detailed understanding of:

1. The necessity of BTC Layer2

2. How to implement BTC Layer2?

3. The fully decentralized BEVM solution

Paying tribute to the three great revolutionary technological iterations of BTC since its birth:

2009: Birth of BTC, which first connected decentralized currency applications through the structure of blockchain.

2017: BTC Segregated Witness upgrade, supporting storage of up to 4MB, solving the on-chain storage issue of BTC. This also laid the foundation for the now popular Ordinals protocol (asset issuance).

2021: BTC Taproot upgrade, supporting the BTC threshold signature algorithm, which provides underlying support for fully decentralized BTC Layer2 technology.

I. Why do BTC Layer2?

1. There is a demand: The Bitcoin network meets the needs of asset registration, but there is still a large amount of assets that need to be settled on-chain (Layer2)

Current ETH Layer2 is just a copy of ETH Layer1, which does not solve any practical business problems that Layer1 cannot solve. The actual business problem that ETH Layer2 solves is the expensive gas fees of Layer1. It is precisely because of this demand that the first major Layer2 Arbitrum on ETH has achieved derivative applications, such as GMX.

However, BTC's Layer2 is not as irrelevant as ETH Layer2.

Because BTC's non-Turing complete on-chain virtual machine can only register assets, not settle them, BTC Layer1 must have a Turing complete BTC Layer2 to solve the settlement problem of assets issued by BTC Layer1.

2. There is capability: BTC can be made into a fully decentralized Layer2

Before the BTC Taproot upgrade in 2021, it was impossible to achieve a fully decentralized BTC Layer2. However, after this upgrade, the BTC threshold signature algorithm can enable BTC to support a fully decentralized Layer2 computation layer.

II. How to achieve decentralized BTC L2?

Bitcoin Improvement Proposals (BIPs) are design documents for introducing new features and information to Bitcoin, and the taproot upgrade is an assembly of three BIPs, namely Schnorr Signature (BIP 340), Taproot (BIP 341), and Tapscript (BIP 342). These three upgrades are collectively referred to as BIP Taproot.

It will bring a more efficient, flexible, and private way of transmission to Bitcoin, and its core lies in the use of Schnorr signatures and Merkel abstract syntax trees.

Schnorr signature is a digital signature scheme known for its simplicity and security. Schnorr signatures have multiple advantages in terms of computational efficiency, storage, and privacy.

Users confirm the identity of the signer through the public key and verify the contract content through the data to authenticate the validity of the digital contract.

Schnorr aggregate signatures can compress and merge multiple signature data into a single aggregate signature.

Validators verify the single aggregate signature by using a list of all the related signatures and public keys. If the verification passes, the effect is equivalent to independently verifying all related signatures and passing all of them.

Currently, most blockchains use the ECDSA multi-signature algorithm. For block data, each node generates independent digital signatures with its own private key and broadcasts them to other nodes. Other nodes verify the signature and write it into the next block data.

Using this method, when there are a large number of consensus nodes, each round of consensus block storage of signature data will continue to increase, occupying storage space.

When new nodes join the network and need to synchronize historical blocks, a large amount of signature data will pose a significant challenge to network bandwidth.

Using aggregate signature technology, each node will collect aggregate signature fragments broadcast by other nodes, and then aggregate and store the signature fragments, as shown in Figure 2.

As a result, when new nodes join, synchronizing historical blocks only requires downloading the aggregated signature data, greatly reducing the occupation of network bandwidth and reducing transaction costs.

In addition, key aggregation makes all Taproot outputs look similar. Whether it is multi-signature outputs, single-signature outputs, or other complex smart contracts, they all look the same on the blockchain, making many blockchain analyses unavailable and thus preserving privacy for all Taproot users.

MAST (Merkle Abstract Syntax Tree) uses Merkle trees to encrypt complex locking scripts, with the leaves being a series of non-overlapping scripts (e.g., multi-signature or time lock).

When spending, only the relevant scripts and the path leading from the script to the Merkle root need to be disclosed. As shown in Figure 3, to use script1, only script1, script2, and hash3 need to be disclosed.

The main advantages of MAST include:

1) Supporting complex spending conditions

2) Not disclosing unexecuted scripts or untriggered spending conditions, providing better privacy protection

3) Compressing transaction size: With an increase in the number of scripts, non-MAST transaction size grows linearly, while MAST transaction size grows logarithmically.

However, there is an issue in the Taproot upgrade, which is that P2SH behaves differently from the common Pay-to-Public-Key-Hash (P2PKH) and still has privacy protection issues.

Is it possible to make P2SH and P2PKH look the same on the chain?

To address this, Taproot proposes a solution where, for a limited number of signers' scripts, it can be decomposed into two parts:

The first part is multi-signature, where all signers agree on a certain spending result, called "cooperative spending." The second part is called "non-cooperative spending," which can have a very complex script structure. These two parts are in an "or" relationship. As shown in Figure 3, Script3 is a 2-of-2 type multi-signature, requiring both Alice and Bob to sign for it to be valid, which is "cooperative spending," while Script1 and 2 are "non-cooperative spending." "Cooperative spending" and "non-cooperative spending" can both spend this output, where: 1) For the "non-cooperative spending" script, it is handled using the MAST method mentioned above, with MerkleRoot representing the Merkle tree root. 2) For the "cooperative spending" script, it is handled using a multi-signature algorithm based on Schnorr signatures. Pa and Pb represent the public keys of Alice and Bob, and Da and Db represent the private keys of Alice and Bob. Therefore, the aggregated public key is P=Pa+Pb, and the corresponding private key is Da+Db. 3) Combining "cooperative spending" and "non-cooperative spending" into a P2PKH form, its public key is: PP+H(P||MerkleRoot)G; the corresponding private key is Da+Db+H(P||MerkleRoot). 4) When Alice and Bob agree on "cooperative spending," they only need one of them to add H(P||MerkleRoot) to their private key Da+Db.

On-chain, this behaves like a P2PKH transaction, with a public key and corresponding private key, without the need to disclose the underlying MAST.

III. Our fully decentralized BTC Layer2 solution:

3.1 BTC Light Node + Distributed Threshold Signature Contract

In this solution, n fixed validators (n can take all the validators on BEVM) complete the distributed threshold signature BTC on-chain aggregate custody contract.

The block generation private key of each validator in the BEVM Layer2 simultaneously derives a part of the aggregate private key of the BTC threshold signature. The threshold private keys of n validators combine to form the aggregate signature address of BTC. The maximum value of n can be up to 1000 or even more.

1) When user A wants to cross-chain BTC to BEVM, the user only needs to send BTC to the Bitcoin aggregate custody contract, and the user will receive BTC on BEVM Layer2.

2) Similarly, when user A performs a withdrawal operation, only m of the n validators in the aggregate signature automatically complete the distributed threshold signature contract interoperability, and the transfer from the custody contract to user A on Bitcoin is completed. At the same time, the BTC will be destroyed on BEVM.

3.2 Implementing BTC as a native Gas fee and EVM-compatible Layer2

1) EVM Principle

The Ethereum Virtual Machine is the runtime environment for Ethereum smart contracts. It is not only sandboxed but actually completely isolated.

This means that the code running in the EVM cannot access the network, file system, and other processes. Even access between smart contracts is restricted.

The underlying Ethereum supports contract execution and invocation through the EVM module. When invoked, the contract code is loaded into the EVM based on the contract address and executed. The typical development process for smart contracts involves writing logic code in Solidity, compiling it into bytecode using a compiler, and then deploying it on Ethereum.

2) Main Parts of EVM

3) EVM Code

EVM code refers to the Ethereum Virtual Machine code, which is the code of the programming languages that Ethereum can include. The EVM code associated with an account is executed every time a message is sent to that account and has the ability to read/write storage and send messages itself.

4) Machine State

The Machine State is where EVM code is executed, containing the program counter, stack, and memory.

5) Storage

Storage is a readable, writable, and modifiable persistent storage space, and it is also where each contract persists its data. Storage is a huge map with a total of 2^256 slots, each slot being 32 bytes.

6) Using BTC as Gas Fee

Using BTC transferred from the Bitcoin network as the currency for gas fee calculation for transaction execution on the EVM.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。