The ancient story goes that Merlin, the legendary wizard of Arthurian lore, is intricately connected to the Holy Grail across various medieval texts.
It is therefore appropriate that the BOS Grail bridge has done its first test transfer from Bitcoin to the Merlin chain. By extension, with Merlin being an EVM, we have now demonstrated that it is possible to bridge from BTC to an EVM, and mint an ERC20 token, using BitSNARKs ZK verification protocol. This opens the door to accelerating the integration of Grail with major EVM-based chains.
In this blog post below we are showcasing and explaining some of the steps behind the scenes on how this demo was executed - both for a valid bridge transaction but also for a fake proof scenario.
What was the scope of this demo?
Demonstrate that by locking a specified amount of Bitcoin in a Taproot (P2TR) address on the Bitcoin Testnet, we can mint an equivalent ERC20 token ("BitSnark" - BIS) on the Merlin Testnet.
This is what is called a PegIn process. The PegIn process allows a user to lock Bitcoin (BTC) on the Bitcoin network (Layer 1) and mint an equivalent amount of ERC20 tokens on an EVM-compatible blockchain (Layer 2).
- At the request of an agent initiating a PegIn, all agents collaborate to co-create a pre-signed Bitcoin Taproot (P2TR) transaction with a specified deposit amount.
- Using this pre-signed transaction, the requesting agent creates a PegIn request on the EVM network.
- This PegIn request must be confirmed by all agents, showing their commitment to the transaction.
- Once all confirmations are obtained, the agent completes the Bitcoin deposit into the Taproot address.
- The requesting agent then generates a zk-SNARK proof verifying the Bitcoin deposit.
- Upon verification and proof of deposit, the PegIn request is finalized, triggering the minting of equivalent ERC20 tokens on Merlin, credited to the requester’s address.
The Assumptions for his Demo
For this demo, we assume that agents have already collaborated to generate the pre-signed Bitcoin transaction.
The BTC deposit to the Taproot (P2TR) address on Bitcoin Testnet has been completed, but the PegIn request and approval are still pending. Ideally, the deposit should occur just before the PegIn transaction and after the PegIn request approval for added security.
The Bitcoin oracle has already been updated with the block containing this transaction, with a minimum confirmation depth of six blocks. This oracle is permissionless and has been updated only to streamline the demo. We could do the demo without this pre-update, with the prover updating it himself during the demo; however, it is beyond the scope of illustrating the provability of the bridge transaction itself.
Execution Details
We will run a script that performs the following steps:
Pre-PegIn Transaction
- The requesting agent creates the PegIn request on the Merlin network.
- All agents confirm the PegIn request, approving it for further processing. (2 agents total)
PegIn Transaction
- Fetch and parse UTXO data from Blockstream, gathering the necessary details for the deposit proof generation.
- Generate the PegIn proof based on the parsed UTXO data, verifying the Bitcoin deposit.
- Execute the PegIn transaction, minting the equivalent ERC20 tokens (BitSnark)on Merlin.
Demo Execution
Check Agent CLI Configuration
Check Requesting Agent Balance
Check Bitcoin Locked Transaction
Demo Script Execution
Breakdown of each step can be found in the images below - we have highlighted the starting balance and final balance on the Erc20. Each step of the execution process is written out in the images below within the ==== borders.
Screencast showing the program execute live can be found here.
Showing the initial ERC20 Balance and Account Address and that it is showing zero
Running the PegIn/Agent/Proof Programs
Performing the PegIn Transaction and Updating the ERC20 Balance on Merlin
You can also view the PegIn transaction on the Merlin chain explorer: https://testnet-scan.merlinchain.io/tx/0x872dbe30829dd704a25269be2e579d48df4245354dfaa405e084463be26a3eb1
Ensuring Secure PegIn Validations: Demo of a False PegIn Proof
The bridge relies on a network of operators/agents who ensure the creation, configuration, and confirmation of PegIn requests, backed by the Bitsnark protocol.
Additionally, the PegIn process leverages ZK-SNARK proofs and a Bitcoin oracle to prevent invalid transactions.
ZK-SNARK proofs validate the Bitcoin transaction by verifying its inclusion in a valid block. These proofs ensure the PegIn address, deposited amount, block header, transaction Merkle tree, and outputs meet all criteria for Bitcoin blockchain inclusion.
The on-chain Bitcoin oracle maintains the canonical Bitcoin blockchain and verifies that the block containing the transaction has been finalized with sufficient confirmations, ensuring the Bitcoin deposit is irreversible before minting ERC20 tokens on the EVM side.
A Fake PegIn
This would imply that someone has the intention of faking a pegIn on Bitcoin to mint ERC20 BTC on Merlin. We assume that the agents have already created and confirmed a PegIn request for a specific address. As shown below:
PegIn request created and confirmed - note the PegIn Address..0x27..
Creating a PegIn Request and confirming it with all agents
Now, the requesting agent is now attempting to falsify the PegIn by providing a fake deposit.
Invalid or fake ZK-proof
We assume that the requesting agent has generated a zk-proof for a different PegIn or an invalid one and is attempting to mint ERC20 tokens using this proof.
Generate a proof for 0xf37cbba1f066ec233d3070728cd894cc466263a79045b8f9ca198bea8b81d0a1 valid pegin.
Then rename the file 0xf37.. to our PegIn address starting with 0x27..
Try to mint an ERC20 using this proof causes an Error!
In this case, the bridge will reject the proof because it does not correspond to a valid PegIn transaction. The ZK-SNARK verification ensures that the proof matches the specific PegIn address, deposited amount, and block hash, preventing the minting of tokens based on invalid or mismatched data.
Block not Included in the Oracle
Although it is extremely difficult to generate a valid proof for a PegIn that has already been approved, as it would require achieving proof of work (PoW) for the block generation, we assume that this has been accomplished.
For this test, we created and confirmed a valid PegIn on the mainnet. However, the PegIn is valid only on the Bitcoin mainnet, not on the testnet. Then we attempt to mint using the mainnet valid proof for a valid PegIn, but on the testnet. Since it is only valid on mainnet and not on testnet we expect the prover to catch that and block the mint. This is how we have created a false proof.
Mainnet Proof Generation
Attempt to mint using the mainnet valid proof for a valid PegIn, but on the testnet - ERROR
When attempting to execute the PegIn transaction on the testnet, the Bitcoin oracle rejects it because the block containing the transaction is not included in the oracle’s records for the testnet. This prevents the transaction from being processed and ERC20 tokens from being minted.
Conclusion
In this demo, we demonstrated the PegIn process from the Bitcoin testnet to the Merlin testnet blockchain. Assuming the agents had already co-created a pre-signed Bitcoin Taproot transaction and the BTC deposit to the Taproot address was completed, the requesting agent initiated the PegIn request, which was then confirmed by all agents. A ZK-SNARK proof validated the transaction, finalizing the PegIn request and minting ERC20 tokens equivalent to the locked BTC.
We also tested and demonstrated the failure scenarios to ensure the security of the PegIn process. This includes cases like an invalid zk-proof, where a user attempts to use a proof for another PegIn, and a transaction for a block not included in the Bitcoin oracle, such as when the PegIn was confirmed on the mainnet but attempted on the testnet. These checks ensure that only valid PegIn transactions can be processed and that security is maintained throughout the process.
.png)
