Layer 2 networks (L2) have proven in practice the ability to scale for a specific blockchain (L1). Many wonder if it is possible to migrate this capability from one to multi. Who would resist that temptation? But why haven't we seen such a L2 that is like the world's factory, the world's trade center, and the world's creative center? Is it just a myth in our minds? Or is it just one step away from reality? Without jumping to conclusions, let's explore the essence of the problem and see how Rooch naturally grows out of that essence¹.

Visibility is an essential problem

"She still looks the same after all these years." Said an anonymous person referring to the love of his life who ran off to a black hole.

Let's start with the causality of an Optimistic Rollup serving a single chain (Directed edges in a graph indicate that the cause points to the effect, i.e., causality.) Starting with.

The core of the L2 security assumption is that at least one honest Verifier verifies the state of the Proposer's commit on L1. In this diagram, we can clearly see how this traceability works.

When we reuse the same logic in a Multi-chain, we will find a potential inconsistency time window, which we need to ensure is smaller than the fraud proof window:

It's just that the Fraud Proof had to be repeated on each chain because:

1. the result of an arbitrary Verifier has no authority
2. L1s cannot directly reuse challenge results from other chains.

Repeated execution of fraud proofs is not costly, and it only takes one honest Verifier to launch a challenge to each L1 to expose Proposer's misbehavior. Although the amount of pledges required grows linearly with the number of chains, the honest Verifier's revenue grows linearly with it, so its motivation is not a problem.

However, inconsistencies do not arise only in the Verifier's and Proposer's judgments about the L2 state, but also inconsistencies in the L2 state recorded between different L1s. It is entirely possible for the Proposer to submit different L2 states on different chains. What about inconsistencies between logical Proposers derived from the same physical entity? There are two scenarios:

1. if the Proposer is penalized locally (banned from committing on the specific L1) then there are multiple Proposer physical entities
2. if the Proposer is penalized globally (banned from committing on all L1s) it relies on third-party arbitration.

In case 1, the problem is not the increased complexity of the stateful commit architecture, but rather the fundamental problem is the audit trail on which the local penalty is based, i.e., Data Availability (Data Publication). In the case where Sequencer colludes with Proposer, the log that Verifier relies on to validate the state can be different for each L1, and then Verifier can only rely on the wrong cause to get the wrong result consistent with Proposer.

For case 2, we need to introduce third-party arbitration, e.g., we introduce a trust assumption (2/3 trust assumption), then we can get a committee (such a committee we have seen in cross-chain bridges). Obviously this is not what we want, as it directly undermines the security assumptions of L2.

Thus, the solution to Multi-chain settlement on L2 is equivalent to determining causality in Multi-chain communication, but again there is no natural causality between the multiple chains. So is there a solution to this problem when cause and effect are not even visible?

Visible on L2

Let's try to derive the solution path from the end point of the problem, i.e. the outcome. Given:

1. Verifier verifies that single-chain state is visible
2. Verifier verifies that Multi-chain state is not visible
3. the Verifier verifies that the safety assumption is satisfied if the process is visible

We obtain:

a. Verifier verifying Multi-chain state in single chain satisfies the security assumption.

Regarding the messaging between L2 and L1, given:

1. the messaging between L2 and L1 is bidirectional
2. there is no messaging assumption between L1s

We obtain:

b. Any L1 can communicate with other L1s by means of L2.

From a and b:

1. Multi-chain state could be converted to L2 state by the mechanism of messaging between L1 and L2.
2. L2 state is converted to single chain state, verified by Verifier.

Force visibility

In the above derivation, we have assumed that L1 and L2 messaging is bidirectional, which is a strong assumption as this relies on a complex forced visibility mechanism:

1. L2 can verify L1 state: light nodes are implemented on L2 by contract, and the correct working of light nodes relies on at least one honest Relayer
2. L2 provides a timeliness commitment to L1 state: the Relayer's relayed L1 state must catch up with the fraud proof window.

Fortunately, the constraints are clear and do not violate the fundamental laws, so we can satisfy them.

Spiraling up

We already know the basics of how to implement Multi-chain settlement on L2, so I won't go into the details of the implementation due to space constraints. Using Rooch as an example, we can continue to expand on this in the following articles.

For more information on how Rooch implements transaction inclusion in Multi-chain systems, see → Transaction Flow

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

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

Like L1, L2 has a process of increasing liveness from a cold start, which is faithfully recorded on L1. For any L1, L2 is just a logical concept, and it doesn't matter who the physical entity behind it is. As the ecosystem on L2 becomes richer and richer, the community members become heavier and heavier, and member changes become more and more fluid, and the positive cycle, once started, spirals upward faster and faster.

Myth or reality

Myth is just one step away from reality, why not cross it together? Join us, right now!

• Discord (opens in a new tab)
• Twitter (opens in a new tab)
• GitHub (opens in a new tab)