# Secure bridge between BTC and based BTC rollup

An innovative new design for a bridge.

## Context.

**What is a rollup?**. A rollup is a blockchain scaling technology, where you use one blockchain (the layer 1 - L1) as a settlement layer for storing the "rolled up state" aka a state root of a second blockchain (the layer 2 - L2). The scalability comes from being able to process transactions off-chain from the L1 on the L2, and instead only paying the cost to settle the state of the L2 to the L1. Its security is based on making claims of the state root's validity via ZK validity proofs or optimistic fraud proofs.

**What is a based rollup?**. A based rollup is a stupider term. Instead of using the L1 to post a state root, we use the L1 as the sequencer for an L2. Meaning - you just post your L2 transactions to the L1 and the L2 network executes them. Hence the rollup is "based". (It's stupid because there is no rollup at all, it's more just execution rolling up).

There is **one key advantage to based rollups** - they are wholly secured by the L1 base chain. Since the L1 performs sequencing for the L2, there is no separate sequencer (like Optimism) or consensus set (like all the Tendermint-based Bitcoin L2's).

We are building an EVM L2 based on Bitcoin, where users post EVM transactions to Bitcoin mainnet (L1) and they are executed offchain by the L2 network.

## Problem.

How can we securely bridge BTC to our EVM L2 that is Bitcoin-based?

## Concept.

For shorthand, we will refer to the EVM L2 rollup as "Etch".

We can construct a **trustless** bridge between the bitcoin L1 and etch L2, via an atomic swap.

**Swapping: L2 <-> L1**

To trustlessly swap BTC from L2 to L1, there are two parties - Alice and Bob. Alice has the L2 BTC, Bob has L1 BTC. They can swap trustlessly using an atomic cross-chain swap based on [hashlocked time contracts](https://hackmd.io/@PIncentivus/Hy52EFQnh).

1. Bob locks L1 BTC into a bitcoin script, and locks it with a hashlock H(S1). If someone reveals the preimage S1, the payment goes to Alice's address. Else it expires after a set period and the BTC returns to Bob.
2. Alice gets the hash H1, verifies that it pays to her address. Alice then locks L2 BTC into a smart contract, and locks it with the same hashlock H(S1), which pays the assets to Bob upon revealing the secret.
3. Bob verifies Alice's contract pays to his address. They are now ready for a trustless swap.
5. Bob redeems the L2 BTC by revealing the secret he knows, S1. The contract verifies H(S1) == C. The L2 BTC is sent to Bob's address.
6. Alice sees Bob reveal the secret S1, and uses it to claim the L1 BTC. The L1 BTC goes to Alice's address.

In this way, Bob and Alice exchange their BTC tokens without an oracle, collateral, or bridges.

Since the Etch L2 is purely a subset of Bitcoin security (transactions and blocks), there is no risk of reorg.

### Open questions.

**Where does the BTC on the L2 come into existence?**

We've skirted over the question of - how does Alice actually have L2 BTC in the first place? When does this come into existence?

We introduce an L1 address called the **native mint**, where users can send L1 BTC to this wallet and as part of the L2 protocol, it is minted as an ERC20 L2 BTC to the sender's account.

For example, Alice on L1 can send her BTC to the native mint address. The Etch L2 nodes recognise these special transactions and mint L2 BTC to Alice.

Should Alice choose to later swap her L2 BTC to L1 BTC, any party on L1 can come along and buy it off her - using the hashlock atomic swap protocol described above.

Some notes about this approach:

- **It is secure against fraud**. The native mint is a semantic defined in the Etch L2 protocol. Alice incurs no counterparty risk, as this is enshrined into the protocol. Any change to the protocol which would ignore Alice's transaction would incur a protocol fork of Etch L2.
- Since Etch L2 is a strict subset of the Bitcoin L1 security, there is no risk of reorg or censorship.
- There is no guarantee that buyers will be available to swap Alice's L2 BTC back into L1 BTC. **However**, we can make the provision that this native mint address is controlled by the Etch developers. **Keep in mind, this introduces no counterparty risk** - the native mint is enshrined as part of the protocol; the BTC L2 mint will always succeed. It doesn't matter who controls the native mint address, it could be the [null address](https://bitcoin.stackexchange.com/a/3778).

**What is the DA cost of Bitcoin L1?**

Bitcoin segwit txs and Ethereum ERC20 transfers are roughly the same size (180 bytes). The difference is that BTC only prices calldata, whereas Ethereum prices execution too.