Multi-chain Settlement

Multi-chain settlement is one of the most important features of Rooch Network. How to realize multi-chain communication while maintaining the L2 security assumption (only one honest verifier node is needed) is its core problem, in this article we will briefly introduce the workflow and principles.

How it works

Let's illustrate how multi-chain settlement works by taking the most complex and well-attended withdrawal transaction as an example.

For any L1 (settlement chain/arbitration chain), the withdrawal process is the same for the user:

1. Initialization transaction (step 1 in the figure): the user initiates a withdrawal request at L2.
2. Proof transaction (step 4 in the figure): the user submits a proof of withdrawal at L1, and the withdrawal transaction is verified by the state commitment submitted by L2 to L1.
3. Finalize the transaction (step 5 in the figure): the user submits a finalizing of the withdrawal transaction at L1, and L1 releases the assets after verifying and confirming the end of the challenge period.

These three steps are all initiated by the user, which maximizes flexibility and makes the prerequisites for L2 to work correctly very clear:

1. state commitment is guaranteed to be validated on L1
2. only one honest verification node is needed to confirm the L2 state on the arbitration chain.

In Rooch terminology, a settlement chain refers to a chain that establishes message communication with Rooch but does not provide arbitration services, and an arbitration chain refers to a chain that provides arbitration services on top of the functions of a settlement chain.

For settlement chains, conditions 1 and 2 are not directly satisfied, since arbitrated chains cannot acknowledge messages from other chains. To solve this problem, we need a decentralized relay service that relays messages from the settlement chain (Condition 1) to L2, and then confirms L2's state commitment to the arbitration chain through L2's state commitment to the arbitration chain. At the same time, in order to verify condition 1, we also need to relay the block information of L1. For the settlement chain, the prerequisites is as follows:

a. In L2, each L1 light node is realized by contract, and the block data can be relayed by any person. Only one honest relay node is needed to guarantee correctness (light_client in the diagram). b. State commitment is guaranteed to be validated on L1 by relay node and condition a (step 3, 4.1 4.2 in the figure) c. Only one honest verification node is needed to confirm the L2 state on the arbitration chain (step 5 in the figure).

In short, we construct the L2 -> L1 -> L2 message validation mechanism so that any L1 is protected by the security of the arbitration chain.

Comparison with cross-chain bridges

Rooch can not only act as a messenger like a cross-link bridge, but also as a producer of messages.

In terms of messaging alone, Rooch offers the following features:

• Rollup-level security: Message validation through trustless relays and light node in contract, and message force inclusion and arbitration through L2 security.
• Generic messaging: Generic state migration enables secure movement of Token, NFT, digital contract, etc.

Further Reading

For more information on how Rooch implements transaction inclusion in a multi-chain system, see → Transaction Flow

For more information on how Rooch implements generic L1 to L2 messaging in a multichain system, see → L1 to L2 Messaging

For more information on how Rooch implements generic L2 to L1 messaging in multichain systems, see → L2 to L1 Messaging.