Where does the multi-chain development of Ethereum go? Maybe Polkadot can give you a reference answer.

Original text: Shared sequencers for Starknet and Madara app chains

Author: Apoorv Sadana

Compiled by: Odaily How about

When more and more L2 and application chains rely on Ethereum as the settlement layer, the interoperability between multiple chains and the degree of decentralization of each chain become particularly important.

This article discusses the concept of a shared sequencer, which enables different application chains to share a set of validators to achieve decentralization and handle transaction ordering and execution through an order engine and a rollup engine.

However, the shared sequencer and Polkadots multi-chain design architecture are highly similar. Can Polkadots ready-made technology be introduced into the Ethereum ecosystem to improve the development process of Ethereums multi-chain.

The following is compiled by Odaily.

What happens with 100 app chains?

Let’s say we’re in a future where there are now 100 different application chains settling on Ethereum. Lets address the issues this raises.

Decentralized fragmentation

Each application chain needs to solve the problem of decentralization on its own. Now, the decentralization of the application chain is not as necessary as L1, mainly because we rely on L1 to ensure security. However, we still need decentralization to ensure viability, resist censorship, and avoid monopoly advantages (such as high fees). However, if each application chain adopts its own way to solve the decentralization problem, this will lead to the fragmentation of the validator set. Each application chain must develop economic incentives to attract new validators. Additionally, validators need to choose which clients they are willing to run. This creates a huge barrier to entry for developers to launch their own application chains (compared to deploying smart contracts, which is just a single transaction).

composability

Composability basically means interaction across applications. On Ethereum or Starknet, this simply means calling another smart contract, and everything else is handled by the protocol itself. However, in the application chain, this becomes more difficult. Different application chains have their own blocks and consensus mechanisms. Every time you try to interact with another application chain, you need to carefully review the consensus algorithm and finality guarantees, and set up the cross-chain bridge accordingly (either directly to the chain or through L1). If you want to interact with 10 app chains with different designs, you need to do this 10 times.

Development experience

Solving decentralization and bridging is not easy. If every application chain needs to solve these problems, it will become very difficult for ordinary smart contract developers to build their own application chains. Additionally, as each application chain attempts to solve these problems in its own way, we will soon see different chains following different standards, which will make it more difficult for new project parties to join the ecosystem.

A shared sorter can solve this problem

If you follow the app chain space, you may have heard the term shared sequencer. It refers to the idea of ​​sharing a common set of validators to solve the above problems. Heres how it works.

Shared decentralization

The core idea of ​​a shared sequencer is that there is no need to have a different set of validators for each application chain or L2. But it is possible to have a very efficient and decentralized set of validators that order blocks for all chains.

Since almost every sequencer today is centralized, the sequencer is treated as a single application that collects transactions, sorts them, executes them, and publishes the results to L1. However, these tasks can be broken down into modular components. For the sake of explanation, Ill split it into two parts.

Sorting engine:Responsible for sorting transactions in a specific order. Once the sorting engine determines this order, it must be followed. This is implemented by committing this order on L1 and forcing L1 validators to check that transactions are executed in the required order.

Rollup engine:The Rollup engine basically includes everything Rollup does: collect transactions from users, execute transactions, create proofs and update state on L1. Ideally, this could be broken down into more components, but well avoid doing that in this article. Here, the sorting engine is the shared sorter and the Rollup engine is basically all the Rollup logic.

Therefore, the life cycle of a transaction is as follows.

The shared sequencer basically sorts the transactions in the rollup and commits them on L1. Shared sorters decentralize the shared sorter set, which means that all Rollups connected to this sorter set become decentralized.

composability

A major issue with composability is knowing when transactions are finalized on other application chains and taking action on the chain accordingly. But a shared sorter allows composable Rollups to share blocks with each other. Therefore, if a transaction rollback occurs on Rollup B, the entire block will be rolled back, which will also cause the transaction on Rollup A to be rolled back.

Now, this certainly sounds easier than it is. To do this, communication between Rollups needs to be efficient and scalable. Shared sequencers need to develop appropriate standards for how Rollups communicate, what cross-chain messages should look like, how Rollup upgrades are handled, etc. Although these problems are solvable, they are not easy to implement.

Developer experience

While the shared sequencer does abstract away the decentralization aspect, making cross-chain messaging easier, there are still some standards that each chain needs to follow in order to be compatible with the shared sequencer. For example, all Rollup transactions need to be converted to a common format understood by the sequencer. Likewise, the sequencers blocks need to be filtered to get relevant transactions. To solve this problem,I think the shared sorter will launch a Rollup framework or SDK that abstracts the boilerplate code and only exposes the business logic part to application chain developers.

The following is a schematic diagram of the application chain when using a shared sequencer.

Can Ethereum’s multi-chain learn from Polkadot’s design architecture?

Polkadot was working on a multi-chain future before Ethereum. In fact, theyve been working on this for over 5 years. If you are familiar with Polkadot, you may have noticed that the design above basically reinvents many things that Polkadot already does.

Relay chain (shared decentralization)

The relay chain is basically the sorting engine + L1 in the sequence diagram above. Functions of the relay chain include:

Sorts the transactions of all parachains (Rollup) to verify that transactions are executed correctly (it does not use zero-knowledge verification, but re-runs the execution code of the Rollup to verify the status difference).

As you may have realized, the relay chain is basically the shared sequencer we discussed above. The difference is that the relay chain also requires verification execution, and we leave this to Ethereum.

XCM and XCMP

We mentioned in the previous section that if each chain establishes its own way to interoperate with other chains, then soon we will see different standards and formats across all chains. You need to keep track of all these formats that interact with each chain. Additionally, you will need to answer questions such as what will happen if a chain is upgraded. However, these problems can be solved by introducing standards that all chains must follow.

As you might have guessed, Polkadot already does this. XCM is a message format and XCMP is a message protocol that all sub-chains can use to communicate with each other.

Substrate and Cumulus

Substrate is a framework developed by Parity for building blockchains. While all parachains on Polkadot use Substrate, Substrate is actually built in a chain-agnostic way. The framework abstracts all common aspects of blockchain and focuses on application logic. As we know, Madara is built on Substrate, as are Polkadot, Polygon Avail, and many other projects. Additionally, Cumulus is a middleware on top of Substrate that can connect your chain to Polkadot.

Therefore, continuing the previous analogy, Substrate and Cumulus can be considered as alternative solutions to the Rollup framework, which allow building chains of applications and connecting them to a shared sequencer.

shared sequencer → relay chain

Composability → XCM and XCMP

Rollup framework/stack → Substrate and Cumulus

The above is basically a carbon copy of Polkadot, except that Polkadot and Parity have some experienced and well-funded teams who continue to improve Substrate and Polkadot, adding more features and improving scalability. This technology has been field-tested for many years and comes with a wealth of development tools.

Settling Polkadot on Ethereum?

While Polkadot did start building the multi-chain future before Ethereum, there is no denying that as of today, Ethereum is the most decentralized blockchain and is where most applications and liquidity reside. However, what if there was a way to bring all Polkadot technology into the Ethereum ecosystem?

In fact, we have already started working on this, and Madara is an example. Madara uses the Substrate framework to allow anyone to build their own ZK-based L2/L3 solutions on Ethereum. The next thing we need is a Polkadot relay chain in the form of a shared sequencer. If we could reuse the Polkadot relay chain, but remove the validation part, since the order of transactions is verified via zk proofs on L1 and the order of transactions is submitted to L1, optimizing the nodes and consensus algorithm to support Tendermint/HotStuff we can get the aforementioned shared sorter.

Obviously, this is easier said than done. However, I think this path is more pragmatic than rebuilding sequencers, standards, and frameworks from scratch. Polkadot has solved many problems in a chain-agnostic way that we can borrow for Ethereum. As a side product we also get:

● An active developer community that continues to build and educate the world on Substrate.

● An active development toolset and strong community.

● Many active parachains also have the option to settle on Ethereum if they wish to do so (recently we saw Astar do the same thing using Polygon CDK).

in conclusion

My main goal in writing this article is to spark discussion within the broader ecosystem of Starknet and Ethereum. I think the shared ordering model will play an important role in the decentralization of Starknet and the decentralization of all application chains considered building on top of it. As long as we have confidence in the AppChain argument and ZKs scalability, a thorough analysis of the shared ordering model is inevitable. Additionally, as Madara moves toward production and Starknet has begun work on decentralization, I think now is the time to address this issue. Therefore, I am requesting any feedback/suggestions on this topic from everyone reading this post. Looking forward to reading your thoughts.