What should Bitcoin’s Layer2 do?

Author: jolestar, Source: Author Twitter @jolestar

Layer 2 of general computing smart contracts on Bitcoin has always been a problem because the Bitcoin network cannot be relied on to ensure the security of smart contracts. In 2018, we tried to make the Bitcoin Lightning Network support WASM smart contracts, but it also required a third party to provide arbitration, and finally gave up this route.

When the BTC ecology was booming this year, such as Ordinals and BRC20, another possibility was shown. They only use BTC as DA, and the technical solution is similar to sovereign Rollup, but it is recognized by the market and users. However, if you want to further expand the ecosystem, you will find many difficulties. The cost of the Bitcoin network as a DA is still too high.

So I thought about whether we could change the idea. The Bitcoin network serves as a source of DA, and the DA of Layer2 itself is solved in another way, so Rooch’s current solution was born.

Rooch as Bitcoin’s Side Rollup

1. Core components and interactions:

- Bitcoin: main chain, whose block information is synchronized to Rooch to provide verification data for Rooch.

- Rooch: As Side Rollup, it includes the following core components:

    - Bitcoin light client: implemented using the Move smart contract in Rooch, responsible for verifying the transfer from Bitcoin Synchronized block header information.

    - Relayer: Regularly synchronizes Bitcoin's latest block header information to Rooch's Bitcoin light client. Anyone can assume the role of Relayer, ensuring there is at least one honest Relayer ensuring overall security.

    - Rooch Sequencer: Interacts with the application contract in Rooch, used to verify transaction proofs and process related application logic.

    - Rooch Full node: stores the complete Rooch chain data and interacts with DA to synchronize transaction information.

- Client: User or application client, obtains transaction proof from the Bitcion network and interacts with the application contract.

2. Workflow:

1. Relayer regularly synchronizes Bitcoin block header information to Rooch’s Bitcoin light client.

2. The Bitcoin light client verifies and saves these block header information in Rooch.

3. Developers can use Move smart contracts to create applications in Rooch. These applications can process and verify Bitcoin transactions, because light clients can provide Merkle Tree proofs to verify transactions.

4. The client obtains the transaction proof from Bitcoin and interacts with the application contract.

3. Application scenarios:

- Triggered application: For example, when a certain transaction is completed on the Bitcoin network, the execution of a certain contract in Rooch is automatically triggered.

- Data copying and re-execution: For example, the json defined by Ordinals, BRC20, GRC20 and other standards on Bitcoin is re-executed in Rooch, so that Rooch acts as a decentralized Indexer service. In this way, anyone can deploy a Rooch node, synchronize and re-execute transactions, and create their own Indexer service.

The key points of this solution:

1. Bitcoin serves as the source DA, which provides time and key data sources for Layer2, and the user's Ordinals transactions are sent directly to the Bitcoin network.

2. Rooch, as Bitcoin Layer2, will execute Ordinals transactions on the Bitcoin network through smart contracts.

3. Rooch Layer2 can issue coins and applications on Layer2, and build an extended ecosystem around Bitcoin.

4. Layer2’s own transactions can be verified by writing to another DA. Anyone can run a node to verify the data provided by Indexer.

5. If the ecology further develops and security requirements increase, an arbitration layer can be connected to enhance security through fraud proof or effective proof. For example, arbitration is provided by Ethereum.

This solution is a feasible solution to implement Bitcoin Layer2 and provide application support without modifying the Bitcoin mechanism.

In the past, everyone would be limited to a portal view, but I think the industry is shifting from narrative logic to application logic, with application as the center, and the infrastructure only provides support, so there will be no portal view.

If anyone is interested in Bitcoin ecological technology, please contact me to discuss technical solutions and implementation.