BEVM: A fully decentralized Bitcoin Layer 2 compatible with EVM and using BTC as the native Gas fee
This article is to tribute Bitcoin’s 3 great technological iterations since its birth:
i.) 2009: The birth of BTC, the first decentralized monetary application with the structure of a blockchain.
ii.) 2017: BTC SegWit upgrade, support up to 4MB of storage, solve the on-chain storage problem of BTC, which provides the basis for the current explosive Ordinal protocol (issuing assets).
iii.) 2021: BTC Taproot upgrades to support the BTC threshold signature algorithm, which provides the underlying support for fully decentralized BTC Layer2 technology.
I. Why do we want to develop Bitcoin Layer 2?
1. Demand: Bitcoin network has already met the demand for asset registration, but there’s still a large number of assets that need Layer 2 for on-chain settlement.
At present, ETH’s Layer 2 is only a copy of ETH Layer 1, and there is no actual business problem that Layer 1 cannot solve, and must be solved by Layer 2.
If we have to admit what ETH L2 actually solved, it must be the problem of the high gas cost of Layer1, which also achieved the first derivative application on Layer2 Arbitrum, such as GMX.
But BTC’s Layer 2 is not as irrelevant as ETH Layer2.
Because BTC’s non-Turing-complete on-chain virtual machines can only register assets, but not for settlement. That’s why BTC Layer1 must need Turing-complete BTC Layer2 to help with the settlement of assets.
2. Enforceability: BTC produces fully decentralized Layer 2.
It was impossible to achieve a fully decentralized BTC Layer2 before the BTC Taproot upgrade in 2021. But the BTC threshold signature algorithm upgrade makes it come true, allowing BTC to support a fully decentralized Layer 2 computing layer.
II. How to implement decentralized BTC Layer2?
Bitcoin Improvement Proposals (BIPs) are design documents that introduce new features and information to Bitcoin, while the Taproot upgrade is a compilation of three BIPs, namely Schnorr signature (BIP 340), Taproot (BIP 341) and Tapscript (BIP 342).
These three upgrades are collectively known as BIP Taproot, which will bring more efficient, flexible, and private transmission methods to Bitcoin. At its core is the use of Schnorr signatures and Merkel Abstract Syntax Trees (MAST).
Schnorr signatures are a digital signature scheme known for their simplicity and security, offering several advantages in terms of computational efficiency, storage, and privacy.
Figure 1 shows the interactive process of Schnorr’s aggregate signature. The user verifies the validity of the digital contract by confirming the identity of the signer through the public key and the content of the contract through the data.
Schnorr aggregate signatures can compress multiple signature data into a single aggregate signature.
The verifier verifies a single aggregate signature with a list of all signature-related data and public keys, and if passed, the effect is equivalent to independently verifying all relevant signatures and passing them all.
Figure 2 Most blockchains today use the ECDSA multi-sig algorithm. For block data, each node generates an independent digital signature with its own private key and broadcasts it to other nodes. The other nodes verify the signature and write it to the next chunk of data.
In this way, 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, a large amount of signed data poses a significant challenge to network bandwidth.
After using the aggregate signature technology, each node collects the aggregate signature shards broadcast by other nodes, and then saves the signature shards in the aggregate, as shown in Figure 2.
In this way, when a new node joins, the synchronous historical block only needs to download the aggregated signature data, which greatly reduces the consumption of network bandwidth and reduces the expenditure of transaction fees.
In addition, key aggregation makes all taproot outputs look similar. Whether it’s multi-sig output, single-signature output, or other complex smart contracts, they all look the same on the blockchain, so many blockchain analytics will not be available, preserving privacy for all Taproot users.
MAST (Merkle Abstract Syntax Tree) is a use of Merck trees to encrypt complex locking scripts, whose leaves are a series of scripts that do not overlap with each other (e.g., multi-signature or time lock).
When spending, simply disclose the script and the path from it to the root of the Merck tree. As shown in Figure 3, to use script 1, simply disclose script 1, script 2, and hash 3.
The main advantages of MAST include: First, it supports complex spending conditions. The second is to provide better privacy protection by not disclosing unexecuted scripts or untriggered spending conditions. The third is to compress the transaction size.
As the number of scripts increases, the non-MAST transaction size grows linearly, while the MAST transaction size grows logarithmically.
However, there is a problem with the Taproot upgrade, that is, P2SH does not behave the same as the common Pay-to-Public-Key-Hash (P2PKH) and still has privacy issues.
Is it possible to make P2SH and P2PKH look the same on-chain?
To this end, Taproot proposes a solution that can be broken down into two parts for a limited number of signers:
1)Multi-sig, where all signers agree on a certain expenditure result, called “collaborative spending”
2) “non-collaborative spending” , having a very complex script structure. These two parts are OR.
As shown in Figure 3, Script 3 is a 2-of-2 type multi-signature, which requires both Alice and Bob to sign to be effective, which is “collaborative spending”;
Scripts 1 and 2 are “non-collaborative spending.” Both “collaborative spending” and “non-collaborative spending” can spend this output, where:
(1) For the “non-collaborative spending” script, take the MAST approach described above, using MerkleRoot to represent the Merck tree root.
(2) For the “collaborative spending” script, adopt a multi-signature algorithm based on the Schnorr signature.
Pa and Pb represent Alice and Bob’s public keys, respectively, and Da and Db represent Alice and Bob’s private keys, respectively. Therefore, the aggregate public key is P=Pa Pb, and the corresponding private key is Da Db.
(3) Combine “collaborative spending” with “non-collaborative spending” in the form of P2PKH, and its public key is: P=P H(P||MerkleRoot）G； The corresponding private key is Da Db H(P||MerkleRoot)
(4) When Alice and Bob agree to “collaborative spending,” they use Da Db H(P||MerkleRoot (Just one of them adds H(P||.) to his private keyMerkleRoot)).
On the chain, this behaves like a P2PKH transaction, with a public key and a corresponding private key, without the need to disclose the underlying MAST.
III. How do we build BTC layer 2?
1.BTC light node + distributed threshold signature contract
In this solution, n (n can be valued as all validators on BEVM) are selected to complete the BTC on-chain aggregation escrow contract signed by distributed thresholds.
The block private key of each validator in BEVM layer2 also derives part of the aggregate private key of BTC’s threshold signature, and the threshold private key of n validators is combined into the aggregate signature group photo address of BTC. The maximum value range of n can be 1000 or more.
A) WHEN THE USER A WANTS TO CROSS BTC TO BEVM, ONLY NEEDS TO SEND BTC TO THE BITCOIN AGGREGATE ESCROW CONTRACT, AND THE USER CAN RECEIVE BTC ON BEVM LAYER 2.
B)Correspondingly, when user A performs the withdrawal operation, only m of the n verification nodes that make up the aggregate signature automatically complete the distributed threshold signature contract interoperability.
The transfer from the escrow contract to user A can be completed on Bitcoin, and the BTC will be destroyed on BEVM at the same time as the transfer is completed.
2. How to implement BTC as a native gas fee and EVM-compatible Layer 2?
1)EVM principle
The Ethereum Virtual Machine is the runtime environment for Ethereum smart contracts. Not only is it sandboxed, but it’s actually completely isolated, meaning that code running in the EVM can’t access the network, file system, and other processes. Even access between smart contracts is restricted.
The Ethereum layer supports the execution and invocation of contracts through the EVM module, and the contract code is obtained according to the contract address when called, and loaded into the EVM for operation.
Usually, the development process of smart contracts is to write logic code in solidlity, compile it into bytecode through the compiler, and finally publish it on Ethereum.
2) The main part of EVM
3) EVM Code
EVM code is Ethereum Virtual Machine code, which refers to the code of programming languages that Ethereum can contain. The EVM code associated with the account is executed each time a message is sent to the account and has the ability to read/write and send messages by itself.
3) Mchine State
Mchine State is where EVM code is executed, containing program counters, stacks, and memory.
4) Storage
Storage is a readable, writable, and modifiable persistent storage space, and it is also where each contract persists data storage. Storage is a huge map with ²²⁵⁶ slots, each with 32 byte.
5) BTC as a gas fee
Let BTC transferred from the Bitcoin network be used as the currency for gas fees executed on EVM’s onboard transactions.
Contacts:
Twitter：https://twitter.com/BTClayer2
Discord: https://discord.gg/FJMEWCjY8R
Contact: https://t.me/BEVMtech
