Since the early days of Nakamoto consensus, the ideal of trustless agreement across blockchains has captured imaginations and inspired innovation. The intrigue of joint consensus, however, does not diminish the marvel of universal concurrence over a single blockchain.
A 2-way peg (2WP) allows the transfer of an asset from base chain to a secondary blockchain and vice-versa. The “transfer” is in fact an illusion: base layer assets are not transferred, but temporarily locked on the base blockchain while the same amount of equivalent tokens are unlocked in a secondary blockchain.
The base layer assets can be unlocked when the equivalent amount of tokens on the second blockchain are locked again (in the secondary blockchain). This is essentially the 2WP promise.
Challenges of the 2WP system
The problem with this promise is that it can only be theoretically realized if the secondary blockchain has settlement finality. Therefore any 2WP system must make compromises and rely on assumptions about the honesty of the actors involved in the 2WP.
The most important assumptions are that the primary blockchain is censorship resistant and that the majority of miners are honest. Another required assumption may be that the majority of third parties that will hold custody of locked assets is also honest.
If these assumptions do not hold, then base layer assets and their equivalent secondary blockchain tokens could be both unlocked at the same time, thus allowing a malicious double-spend.
Any 2WP system must choose an implementation so that the parties being assumed to behave honestly have economic and legal incentives to do so. This involves analysing the cost of an attack by these critical parties and consequences of an attack.
The security of a 2WP implementation depends on the incentives to enforce the 2WP promise by the critical parties taking part of the 2WP system.
Clover’s SPV Simulation Technology
To achieve a new-level of a trustless 2WP system, Clover created a model called built-in SPV chain simulation technology to enable trustless two-ways pegs between turing-complete and non-turing-complete blockchains.
Contrary to popular belief, an EVM can verify Bitcoin transactions directly, by enforcing some standards and dissecting Bitcoin transactions and block headers.
Clover is building advanced tools and opcodes to simplify the overall process for third-party developers. This is so that Clover can natively inspect a Bitcoin or Ether transaction without storing/checking the entire external blockchain history, allowing trustless two-way pegs for Bitcoin and Ether.
How does this work?
Bitcoin and Ethereum transactions are both included in a Merkle tree, whose block header contains the root of the Merkle tree for that block’s transactions. Given a header and a transaction, Clover can validate a merkle path from the root to the leaf that holds the transaction, which is called the Merkle-based inclusion proof.
This means that Clover only needs the base layer block header, transaction, and its inclusion proof to be stored in the Clover contract.
A user willing to peg-out some Bitcoin or Ether sends funds to a predetermined covenant/contract address that escrows funds for further peg-ins, along with any respective proof data Clover needs for verification.
Clover verifies an outside transaction inside a smart contract. This part is a quick run-through of transaction components, to ensure the caller isn’t trying to sneak through fake content.
Clover then can verify that the transaction is included in a block by checking a Merkle proof of inclusion, then checking each block references the previous one, and then calculate the total Proof of Work spent to make that chain.
Current State of SPV Simulation
Clover’s SPV simulation technology will soon be able to trustlessly peg-in and peg-out Ether and Ethereum based assets on the Clover testnet. Supporting Bitcoin however, requires further upgrades to Bitcoin Core.
The two upgrades required are splice opcodes and an arbitrary signature verification opcode. Thankfully, BIP-Tapscript proposes to allow future soft forks to introduce new opcode functionalities without breaking backwards compatibility.
BIP-Tapscript at the bottom also mentions OP_CHECKSIGFROMSTACK as a candidate for future opcodes which is required for Clover to build Bitcoin-native covenants via transaction introspection.
BIP-Schnorr is on the other hand proposing to activate Schnorr signatures, which is also required for Clover to convince the Bitcoin script to validate Clover block headers that are being produced by Schnorr-compatible n of m threshold validators.
Clover will roll out Bitcoin two-way peg support when respective upgrades are activated on Bitcoin Core in the next few years.