Written by: Peter
Preface
Since the advent of BTC in 2009, Bitcoin has undergone three technological iterations and has developed from a simple concept of digital native assets to a decentralized financial system with complex functions and applications.
This article was written by the founder of BEVM, who shared his insightful views on the evolution of BTC technology. It also explained in detail how BEVM, a key milestone in the development of BTC Layer2 technology, can achieve the future prosperity of BTC's decentralized ecosystem at the technical level.
Through this article, you will learn in detail:
The necessity of BTC Layer2
How to implement BTC Layer2?
A fully decentralized BEVM solution
Tribute to BTC's three great revolutionary technological iterations since its birth:
2009: BTC was born, and for the first time, the blockchain structure was used to open up decentralized currency applications.
2017: BTC Segregated Witness upgrade supports up to 4MB of storage, solving BTC’s on-chain storage problem. This also provides a basis for the now popular Ordinals protocol (issuing assets).
2021: BTC Taproot is upgraded to support the BTC threshold signature algorithm, which provides underlying support for the fully decentralized BTC Layer2 technology.
1. Why do we need to build BTC Layer2?
1. There is demand: The Bitcoin network meets the needs of asset registration, but there are still a large number of assets that need to be settled on the chain (Layer2)
Currently, ETH's Layer2 is just a copy of ETH Layer1, and does not solve any practical business problems that Layer1 cannot solve and must be solved by Layer2.
If we have to say that ETH Layer2 solves the problem of ETH Layer1, it is: Layer2 solves the problem of expensive Layer1 gas fees. It is precisely because of this demand that the derivative applications on ETH's largest Layer2 Arbitrum, such as GMX, have been achieved.
And BTC's Layer2 is not as insignificant as ETH's Layer2.
Because BTC's non-Turing-complete on-chain virtual machine can only register assets but not settle them, BTC Layer1 must have a Turing-complete BTC Layer2 to settle the assets issued by BTC Layer1.
2. 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 computing layer.
Second, how to achieve decentralized BTC L2?
Bitcoin Improvement Proposals (BIPs) are design documents that introduce new features and information to Bitcoin, and the taproot upgrade is a compilation of three BIPs: Schnorr signatures (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 transmission method 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. Schnoor signature has several advantages in computational efficiency, storage, and privacy.
The user confirms the identity of the signer through the public key and the content of the contract through data, thereby authenticating the validity of the digital contract.
Schnorr aggregate signature can compress and merge multiple signature data into a single aggregate signature.
The verifier verifies a single aggregate signature through a list of all signature-related data and public keys. If the verification passes, the effect is equivalent to independent verification of all related signatures and all of them pass.
Most blockchains currently use the ECDSA multi-signature algorithm. For block data, each node generates an independent digital signature with its own private key and broadcasts it to other nodes. Other nodes will verify the signature and write it into the next block data.
When this method is used, when the number of consensus nodes is large, the signature data stored in each round of consensus blocks will continue to increase, occupying storage space.
Whenever a new node joins the network and needs to synchronize historical blocks, the large amount of signature data will pose a great challenge to the network bandwidth.
After using the aggregate signature technology, each node will collect the aggregate signature business cards broadcast by other nodes, and then aggregate and save the signature fragments, as shown in Figure 2.
In this way, when a new node joins, it only needs to download the aggregated signature data to synchronize the historical blocks, which greatly reduces the network bandwidth usage and reduces transaction fees.
Additionally, key aggregation makes all Taproot outputs look similar. Whether it is a multi-signature output, a single-signature output, or other complex smart contracts, they all look the same on the blockchain, so many blockchain analyses will be unavailable, preserving privacy for all Taproot users.
MAST (Merkle Abstract Syntax Tree) uses Merkle trees to encrypt complex locking scripts, whose leaves are non-overlapping scripts (for example, multi-signatures or time locks).
When spending, only the relevant script and the path from the script to the Merkle tree root need to be disclosed. As shown in Figure 3, to use script1, only script1, script2, and hash3 need to be disclosed.
The main benefits of MAST include:
Support complex spending conditions
Provides better privacy protection by not disclosing unexecuted scripts or untriggered spending conditions
Compressed transaction size: As the number of scripts increases, the size of non-MAST transactions grows linearly, while the size of MAST transactions grows logarithmically.
However, there is a problem in the Taproot upgrade, that is, P2SH is different from the common Pay-to-Public-Key-Hash (P2PKH) in performance and still has privacy protection issues.
Is it possible to make P2SH and P2PKH look the same on-chain?
To this end, Taproot proposed a solution. For the script of a limited number of signers, it can be decomposed into two parts:
The first part is multi-signature, where all signatories agree on a certain spending outcome, called “collaborative spending.”
The second part is called "non-cooperative spending" and can have very complex script structures.
The relationship between these two parts is "or".
As shown in Figure 3, Script3 is a 2-of-2 multi-signature, which requires the signatures of both Alice and Bob to be valid. It is a "collaborative spending". Script1 and 2 are "non-collaborative spending".
Both collaborative spending and non-collaborative spending can spend this output, where:
For the "non-collaborative spending" script, the above-mentioned MAST method is adopted, and MerkleRoot is used to represent the Merkle tree root.
For the "collaborative spending" script, a multi-signature algorithm based on Schnoor signature is adopted. Pa and Pb represent the public keys of Alice and Bob respectively, and Da and Db represent the private keys of Alice and Bob respectively. Therefore, the aggregate public key is P=Pa+Pb, and the corresponding private key is Da+Db.
The "collaborative spending" and "non-collaborative spending" are combined into P2PKH form, and its public key is: PP+H(P||MerkleRoot)G; the corresponding private key is Da+Db+H(P||MerkleRoot).
When Alice and Bob agree on a “collaborative spend”, they use Da+Db+H(P||MerkleRoot) and only one of them needs to add H(P||MerkleRoot) to their private key.
On-chain, this behaves like a P2PKH transaction, with a public key and corresponding private key, without revealing the underlying MAST.
3. Our fully decentralized BTC layer2 solution:
3.1 BTC Light Node + Distributed Threshold Signature Contract
In this scheme, n (n can be taken as all validators on BEVM) fixed validators are selected to complete the BTC on-chain aggregate custody contract with distributed threshold signatures.
Each validator's block private key in BEVM layer2 also derives a part of the aggregate private key of BTC's threshold signature. The threshold private keys of n validators are combined into the aggregate signature photo address of BTC. The maximum value range of n can be 1000 or even more.
When user A wants to cross-chain BTC to BEVM, he only needs to send BTC to the Bitcoin aggregation custody contract, and the user can receive BTC on BEVM layer2.
Accordingly, when user A withdraws money, only m of the n verification nodes that make up the aggregate signature need to automatically complete the distributed threshold signature contract interoperation to complete the transfer from the custody contract to user A on Bitcoin. When the transfer is completed, BTC will be destroyed on BEVM.
3.2 Implementing Layer2 with BTC as the native gas fee and EVM compatibility
1) EVM Principle
The Ethereum Virtual Machine is the runtime environment for Ethereum smart contracts. It is not only sandboxed, but is actually completely isolated.
This means that code running in the EVM cannot access the network, file system, and other processes. Even access between smart contracts is limited.
The underlying Ethereum supports the execution and calling of contracts through the EVM module. When calling, the contract code is obtained according to the contract address and loaded into the EVM for execution. Usually, the development process of smart contracts is to write logic code in solidity, compile it into bytecode through a compiler, and finally publish it on Ethereum.
2) EVM main parts
3）EVM Code
EVM code is Ethereum Virtual Machine code, which refers to the code of the programming language that Ethereum can contain. The EVM code associated with an account is executed every time a message is sent to this account, and has the ability to read/write storage and send messages itself.
4）Mchine State
Mchine State is where the evm code is executed, including the program counter, stack and memory.
5）Storage
Storage is a readable, writable, and modifiable persistent storage space. It is also where each contract stores data persistently. Storage is a huge map with a total of 2256 slots, each with 32 bytes.
6) Use BTC as Gas Fee
Let BTC transferred from the Bitcoin network be used as the currency for calculating the gas fee for transaction execution on the EVM.
