Bringing Polkadot tech to Ethereum

Hey everyone!

I am linking this post to my proposal on the Starknet Community forum which discusses an idea on how the Polkadot tech stack can be reused in Ethereum.

I wanted to repost it here for everyone to read it but as I am a new user I am only allowed one media file and 2 links per post. So about the proposal - essentially, a lot of players in the Ethereum ecosystem are re-inventing solutions for problems like shared security, interoperability etc. which Polkadot has already solved over the last few years. The proposal is to discuss the idea of forking the existing Polkadot SDK and to make it work for zk rollups. I believe this would be a win-win for both ecosystems. Hence I am posting it here again to get your feedback and suggestions on the feasibility of such an idea.

A glossary for some of the terms mentioned

  • Madara: A Substrate based framework for building zk rollups
  • Pragma, Kakarot, Mangata Finance, Dojo: App chains (parachains) which might use Madara

The proposal - Shared sequencers for Starknet and Madara app chains - đź“ś Development Proposals - Starknet Community Forum


If you think forking Polkadot SDK is a good idea, making CoreJam work for zk rollups may be a better idea – study it very closely. I think you might not need to fork it but just use it – the connections to XCM/XCMP are going to take some time to work through.

Posting this on behalf of @apoorvsadana, a follow-up to this post:

Hey everyone! I am copying this post from my proposal on the Starknet Community forum which discusses an idea on how the Polkadot tech stack can be reused in Ethereum. Essentially, a lot of players in the Ethereum ecosystem are re-inventing solutions for problems like shared security, interoperability etc. which Polkadot has already solved over the last few years. The proposal is to discuss the idea of modifying the existing Polkadot SDK to make it work for zk rollups. I believe this would be a win-win for both ecosystems. Hence I am posting it here again to get your feedback and suggestions on the feasibility of such an idea.

A glossary for some of the terms mentioned


Today, we are already seeing projects starting to experiment with Madara for their app chains. Pragma, Kakarot, Mangata Finance, and Dojo are just some examples. As long as we believe in the multi-chain future and the power of zk scaling, we will only see many more of these projects in the future. However, the increasing number of app chains also raises questions around

  1. Decentralisation

  2. Composability

  3. Development experience

In this post, I will try to explain the problems that arise due to having a lot of app chains and also pose a possible solution to the problem that I consider elegant and optimal for Madara and Starknet. If you are already well versed with app chains and shared sequencing, feel free to jump to the “Wait, it’s just Polkadot all over again” section.

What happens at 100 app chains?

Let’s say we are in a future where we now have 100 different app chains settling on Ethereum. Let’s address all the problems this will cause.

Fragmented decentralisation

Every app chain will need to solve for decentralisation on its own. Now the decentralisation of app chains is not as necessary as that of L1s mainly because we rely on L1s for security. However, we still need decentralisation to ensure liveliness, censorship resistance and to avoid monopolistic advantages (high fees for example). However, it’s also important to note that If each app chain goes on to solve for decentralisation its own way, this will very quickly lead to fragmentation of validator sets. Each app chain would have to develop economic incentives to onboard new validators. Also, validators would need to select what clients they are comfortable with running. Not to mention the huge barrier to entry this creates for developers to launch their own app chains (vs deploying a smart contract which is just a transaction).


Composability essentially means cross-app interaction. On Ethereum or Starknet, this just means calling another contract and everything else is handled by the protocol itself. However, with app chains, this becomes much more difficult. Different app chains have their own blocks and consensus mechanisms. Every time you try to try to interact with another app chain, you need to carefully examine the consensus algorithm and the finality guarantees and accordingly set up a cross-chain bridge (directly to the chain or via the L1). If you want to interact with 10 app chains with different designs, you would do this 10 different times.

Development experience

Solving for decentralisation and bridging is not easy. If this is a requirement for every app chain, it will make it very difficult for the usual smart contract developer to ever build his own app chain. Moreover, as every app chain tries to solve these problems in its own ways, we will soon see different standards being followed by different chains making it even more difficult to join the ecosystem.

Shared Sequencers can solve this

Now if you’re following the app chain space, you might have heard of the term “shared sequencers”. It’s the idea of having a common set of validators for all chains that aim to solve the problems mentioned above. This is how it works.

Shared Decentralisation

The very essence of shared sequencers is that you don’t need to have a different set of validators for each app chain or L2. Instead, you can have a really efficient and decentralised set of validators that sequence the blocks for all the chains! Imagine blocks that contain transactions from 100 different app chains. You might be thinking this is going to really bloat up the sequencer as you need to be able to handle execution engines for each app chain.

Well, you don’t!

Since today almost every sequencer is centralized, the sequencer is thought of as a single application that collects transactions, orders them, executes them and posts the results on the L1. However, these jobs can be separated into multiple modular components. For the sake of this explanation, I will divide them into two.

  1. Order engine: This is responsible for sequencing the transactions in a specific order. Once this order has been decided by the order engine, it MUST be followed. This is enforced by committing this order on the L1 and forcing L1 verifiers to check if transactions were executed in the required order.

  2. Rollup engine: The rollup engine is basically everything else the rollup does - collecting transactions from users, executing them, creating proofs and updating the state on the L1. Ideally, this can be broken into more components but we would avoid that for this post.

Here, the ordering engine is the shared sequencer and the rollup engine is basically all the rollup logic. So the transaction lifecycle looks like this

The shared sequencers basically order transactions across rollups and commit them to the L1. Hence, by decentralising the shared sequencer set, you basically decentralise all the rollups linked to that sequencer set! To get a more detailed idea of the working of shared sequencers, you can also refer to this amazing article by Espresso.


One of the major issues of composability is understanding when the transaction is finalised on the other app chain and accordingly taking actions on your chain. But with shared sequencers, both the composable rollups share blocks with each other. So if a transaction rolls back on rollup B, the entire block is rolled back, and this causes the transaction on rollup A to revert as well.

Now this surely sounds easier said than done. For this. communication between rollups needs to be efficient and scalable. The shared sequencers need to come up with proper standards on how rollups can communicate, what should cross-chain messages look like, how to deal with rollup upgrades etc. While these are solvable problems, they are complicated and not easy to solve.

Developer experience

While the shared sequencers do abstract the decentralisation aspect and make cross-chain messaging easier, there are still some standards that every chain needs to follow to be compatible with the shared sequencer. For example, all rollup transaction needs to be transformed into a general format that the sequencer understands. Similarly, blocks from the sequencer need to be filtered to fetch the relevant transactions. To solve this, I would assume shared sequencers would come up with rollup frameworks or SDKs that abstract the boilerplate code and expose only the business logic part to app chain developers.

Here’s a diagram of how app chains will look with shared sequencers

Wait, it’s just Polkadot all over again

Polkadot started working on the multi-chain future much before Ethereum. In fact, they have been working on it for more than 5 years now and if you’re familiar with Polkadot, you might have noticed that the above design is basically re-inventing a lot of things Polkadot has already done!

The Relay Chain (Shared Decentralisation)

The Relay chain is basically the ordering engine + L1 in the sequence diagram above. The relay chain

  1. Orders transactions across all the parachains (rollups)

  2. It verifies the transactions executed correctly (instead of zk verification, it actually re-runs the execution code of the rollup to verify the state diffs)

You might have realised the relay is basically the shared sequencer we discussed above. Except for the fact that the relay chain also needs to do verify the execution (as Polkadot is an L1) whereas we leave that to Ethereum.


We mentioned in the previous section that if every chain built its own methods to interoperate with other chains, we would soon be bloated with different standards and formats across all chains. You’ll need to keep track of all these formats for every chain you interact with. Moreover, you will also need to answer questions like what happens if a chain upgrades? However, these problems can be tackled elegantly by introducing standards that all chains must follow.

As you might have guessed, Polkadot has already done this. XCM is the messaging format and XCMP is the messaging protocol that all substrate chains can use to communicate with each other. I won’t go into the details of it but you can read about it here.

Substrate and Cumulus

Substrate is a framework developed by Parity that can be used to build blockchains. While all parachains on Polkadot use substrate, substrate is actually built in a chain-agnostic way. The framework abstracts all the common aspects of a blockchain so that you can just focus on your application logic. As we know, Madara is built on Substrate and so are Polkadot, Polygon Avail and many other projects. Moreover, Cumulus is a middleware on top of Substrate that allows you to connect your chain to Polkadot.

So continuing our analogy like before, Substrate and Cumulus can be thought of as substitutes to the rollup frameworks that allow you to build app chains and connect them to the shared sequencers.

Shared Sequencers → Relay Chains

Composability → XCM and XCMP

Rollup frameworks/Stacks → Substrate and Cumulus

So yes, it’s pretty much Polkadot all over again! Apart from this, Polkadot and Parity have some of the most experienced and funded teams that continue to build Substrate and Polkadot to add more features and make it more scalable. The technology is already battle-tested for years and has a ton of dev tooling out of the box.

Settle Polkadot on Ethereum?

While it’s true Polkadot did start building the multi-chain future way before Ethereum, there’s no denying that as of today, Ethereum is the most decentralised blockchain and the place where most of the apps and liquidity rests. However, what if there was a way to bring all the Polkadot tech into the Ethereum ecosystem?

There is! In fact, we have already started this with Madara. Madara uses the Substrate framework to allow anyone to build their own zk-powered L2/L3 solution on top of Ethereum. What we need next is the Polkadot relay chain in the form of a shared sequencer. So basically, if we can reuse the Polkadot relay chain but

  1. Remove the verification part as that happens on the L1 via zk proofs

  2. Commit the order of transactions to the L1

  3. Optimise the nodes and consensus algorithms to support Tendermint/HotStuff

We can get shared sequencers as mentioned before. Obviously, this is easier said than done. However, I believe this path is more pragmatic than rebuilding the sequencers, standards and frameworks from scratch. Polkadot has already solved a lot of problems in a chain-agnostic way which we can borrow for Ethereum. As a side product, we get

  1. An active set of developers that continue to build and educate the world about Substrate

  2. An active developer tooling set and a strong community

  3. A lot of active parachains can choose to settle on Ethereum as well if they wish to do so (we saw Astar do the same recently with the Polygon CDK)


My main idea behind writing this post is to open the discussion amongst the broader ecosystem of Starknet and Ethereum. I feel the shared sequencing model will play an important role in the decentralisation of not only Starknet but also all the app chains that consider building on top of it. As long as we are confident about the app chain thesis and zk scaling, a thorough analysis of the shared sequencing model is inevitable. Moreover, as Madara is moving towards production and Starknet has started its work on decentralisation, I feel this topic is now important to address. Hence, I request everyone reading this to leave any feedback/suggestions you have about the topic. Looking forward to reading your thoughts!


Polkadot vs Cosmos

Cosmos, similar to Polkadot, has been solving for a multi-chain future for many years now. As a result, it has made a lot of developments with the Cosmos SDK and IBC and we also see a lot of app chains building on top of the Cosmos ecosystem. Hence, it’s only fair to consider Cosmos as well for this approach. My personal view on this topic is that Polkadot is more relevant as it solves the shared sequencers problem whereas Cosmos requires each app chain to build its own validator set. Moreover, Substrate has always been built in a chain-agnostic way to allow developers to build blockchains with no assumptions about consensus algorithms or the Polkadot ecosystem. This is also the reason why we chose Substrate for Madara. However, with that being said, my experience on Cosmos is limited and would love to hear more on this from the more experienced folks! You can also find more about the comparison of the two networks here.


Instead of a “fork” of Polkadot SDK, how can we have new relay chains use Substrate but not be seen as a threat to Polkadot 2.0 and fall under the Polkadot Alliance?

I would like to see Kusama 2.0 evolve to be a Hybrid Relay Chain (see RFC #33 Kusama Network 2.0: The Hybrid Chain Network) (for more fun reading: TLDR memes ala Kusama 2024 = Ethereum 2029) to expose its DA for optimismic (OP Stack/…) + ZK Rollups (StarkNet, zksyncera, …). But perhaps there is so much baggage that only a fork can be pursued.

It’s a truly interesting project – thank you for sharing!

We’re curious, do you see it as a long-term solution or as an interim one until the generalized work processing model for Polkadot 2.0 stabilizes and gets implemented? Please correct any mistakes on our understanding– with the proposed work classes and work packages in the new model for the relay chain, Madara would implement a work class for its shared sequencer set (and the same would apply to Avail in the validiums and sovereign rollups space). So, is Madara considering this alignment? Do you foresee showstoppers?

Having said that, it’s evident that the pragmatic approach for now is to build something that works and can be used immediately.

We’re thrilled to see projects like yours moving forward!

Hi @apoorvsadana!

We replied to Bruno in the other thread who helped to post your full proposal, linking the comment here: Bringing Polkadot Tech to Ethereum (Full Post) - #3

1 Like

Thanks @sourabhniyogi and @sodazone for your comments. I am not sure if I understand the Polkadot 2.0 concern completely (sorry for my lack of knowledge here). From what I know, Polkadot 2.0 is the concept of having on demand core time on the relay chain which would essentially allow things similar like smart contracts on Ethereum. While Polkadot did have smart contracts via parachains, these ones would be different as they would be on the relay chain directly and users only need to pay for them during execution (like gas fees).

So in the Polkadot 2.0 world, it becomes relatively easier for all the current L2s/L3s to rollup to Polkadot. However, this doesn’t answer questions like how decentralisation would increase in Polkadot 2.0 or how liquidity would be attracted (in fact I don’t think anyone can answer those questions deterministically for any chain). On the other hand, Ethereum also plans to move towards full dank sharding and single slot finality (once again, no one knows when this will happen or how different parts would play out eventually).

I am not trying to say Polkadot 2.0 won’t be an attractive solution for rollups or projects coming up but at the same time Ethereum won’t disappear. I feel the future would have different projects choosing different infra layers based based on what they have to offer at that point. Also, @sourabhniyogi on your point of violation of the Polkadot Alliance, I am not sure how true that is. The way I look at it, Substrate has always been made in a chain agnostic way to allow anyone (linked or not linked to Polkadot) to build blockchains. If it so happens that a lot of L2s/L3s are built using Substrate, it’s only natural to expect forked relay chain concepts to evolve around Ethereum as well. In fact I see this as a plus for both ecosystems as a lot of great work can eventually be pushed upstream to Substrate! It’s the same way Eclipse, a Solana backed startup, is using the Solana SVM for their layer 2. If L2s are inevitable, you would want them to be made using your tech stack is my opinion.

Once again, thanks for your comments. Sorry if I am missing some important points here, I am relatively new to the Polkadot ecosystem. Would love to hear your points on these thoughts :slight_smile:

1 Like

Here you can find the RFC:

Essentially, from what I understand, you will have the ability to add your use case specific processing logic (work classes) into the relay chain, i.e the shared sequencing parts that make sense. And, of course, in your case keeping the settlement on Ethereum.

Seems like a very good fit for your project, at least in theory.

This is indeed very interesting @sodazone. Building a shared sequencer on top of Polkadot has it’s own merit of being backed by billions of dollars in economic security. However, I feel this would also force the sequencer to follow Polkadot block times and other restrictions (if any) of the relay chain? For instance, Polkadot being an L1 would need to focus on liveliness whereas shared sequencers can opt for optimistic responsiveness as in the worst case users can withdraw from L1.

EDIT: Moreover, the shared sequencers also involve interactions with the L1 for reading and posting commitments. Is this possible by embedding the shared sequencer logic within the relay chain itself?


I’m a big fan of Madara and support creating closer technical bonds between Starknet and Polkadot. However, the assertion that Ethereum is the most decentralized blockchain is untrue.

According to MEV Watch, 91% of Ethereum blocks in the last 7 days were created through MEV-Boost. 26% of all Ethereum blocks enforced OFAC Compliance. Ethereum has been under heavy attack for many years. It has not yet been able to defend itself against those censorship and toxic MEV attacks.

Therefore it is crucial that Ethereum does not eat all apps, as suggested in the post… We can be friends. But we don’t want to fall prey to the same dynamics. An essential part of decentralization is to maintain several big related but separated networks.



After we got that out of the way, let’s get to the subject matter. I am super grateful that we are finally having the discussion of shared sequencers. However, I think that you are misunderstanding the nature of the relay chain.

Relay Chain vs. Shared Sequencing

Parachains follow a runtime that is operated by networks of parachain block producers (collators, similar in nature to sequencer + proposer). Those blocks are submitted to the relay chain, where subsets of validators re-execute them for verification.

Thus the relay chain cannot really influence the sequencing anymore. It is rather providing sharding by verifying parachain blocks through the validator groups.

Polkadot 2.0 is more than Cores

We went a little bit early with shouting “Polkadot 2.0” to the world in July, so there is only partial information out there about what it is. The most commonly known parts are

  • smart contracts directly on Polkadot
  • introducing the notion of coretime and allowing constructs (parachains, smart contracts, etc) to use partial cores or even multiple cores
  • sharing immutable business logic between constructs (called “accords”)

More in this video.

Since then, there have been additional substantial additions to the concept of Polkadot 2.0.

The first one is called “CoreJam” and effectively proposes to transform the Polkadot Core to a map-reduce like system, where each core executes the map step (e.g. re-executing a parachain block, running smart contracts) and the reduce step ensures global state consistency.

The effect of this proposal is that you can abstract Polkadot further out and allow any type of rollup or other construct to be run on Polkadot. So Polkadot and Parachains will no longer be strongly coupled and we could also get zk-Rollups or other things natively running on Polkadot.

Another new relevant perspective is Polkadot Kernel/Userland, which proposes (at least a mental) separation between the Polkadot Kernel and Userland, but also looks at how the primary sellable resource of Polkadot (Cores) could be packaged and sold, and how responsibilities between the Polkadot Kernel and userland applications lie.

Shared Sequencers on Polkadot

Now let’s get to the good stuff. Shared sequencers on Polkadot would be really good! There is a project in Polkadot called Tanssi (which you might conceptualize as a RaaS provider at first sight) that offers to deploy “containerchains” in a very short time. They offer parachain templates, collator infrastructure, explorers, etc.

Since it will become much easier to build and deploy constructions anywhere on the complexity spectrum between smart contracts and parachains on Polkadot, we need more efficient sequencer networks. This is where shared sequencers would come in and provide great value to our ecosystem since they would offer cost-effective ways to run chains and more lightweight constructions on Polkadot.

The way it could be achieved is either by just building it as a mechanism within the parachain system that parachains can opt-in to, or even as a work type in the new CoreJam paradigm, where traditional parachains (and other constructions) opt-in but are represented as something different than parachains in Polkadot.


Let me use an analogy of electric cars (Polkadot) vs hybrid cars [TBD] vs gas powered cars (Ethereum) to explain. Polkadot builds beautiful electric cars (consensus systems) using electric batteries, self-driving cars, and a bunch awesome stuff (Substrate, CoreJam, app chains, XCM/XCMP, PolkaVM) all dedicated to zero emissions (scalability of permissionless systems).

This community cannot stand to see their tech used in hybrid cars (Bringing Polkadot tech to Ethereum). How could the Polkadot Treasury fund even 1 DOT to pollute the world with 1 Carbon Atom when ZERO EMISSIONS is the goal? Greta Thunberg how DARE YOU travel the world in a jet you hypocrite! How could moderators of the POLKADOT forum (paid for by DOT) forum allow for such heresy as this post! People who build Madara are thieves, stealing our tech to build competing stacks StarkNet and Ethereum! How could we possibly support a competing relay chain! Ban @apoorvsadana NOW! Flag this post! Make sure Madara never gets any of the new 5MM DOT and 20MM CHF! You are either with the Polkadot Alliance or for Hamas!

[Above is a total caricature, hopefully you get the idea of how something starts with the ideal (save the world, inclusiveness) but ends up in silly places (overzealous tribalism, protectorates, censorship, etc.).]

I think a new relay chain to support rollups based off Madara is a great idea. Again, I’d rather see it in Kusama but you’re going to be up against “you’re either with us or against us” tribalism with that “to Ethereum”.

Its a VERY good question why Kusama would be part of the Polkadot Alliance and Madara would be like on the side of Hamas. Your first guess is probably the right one:

Who EXACTLY owns the token that controls the security?

While I don’t think the Polkadot Alliance was much more than vaporware, you might conclude that superengineers are the new Popes. Who am I to judge?

Thanks @alice_und_bob for the thoughtful reply. Firstly, I do agree the future would involve multiple L1/L0 chains like Ethereum, Polkadot, Solana co existing with each other. Your insights on MEV are interesting and I will definitely have a deeper look at this.

Relay Chain vs. Shared Sequencing

Coming to your comparison between the relay chain and shared sequencers, I understand that the relay chain isn’t involved in sequencing of transactions as of now. It’s more of like Ethereum where execution is verified. But when I was speaking about forking the relay chain, adding this capability was a part of it (in hindsight, it wasn’t clear and I should have probably written it in the original post). To be more precise, the parts that I would like to borrow from the relay chain are

  • Communication between Substrate based chains and the shared sequencer
  • Accords to ensure trustless communication between chains
  • XCM and other standards for all app chains

The parts which would need to be implemented on top are

  • Ability to just listen to app chain transactions and build blocks (no verification)
  • Commitments to the L1 regarding the order of transactions
  • Maybe a new consensus algorithm like Hotstuff

Actually, given your experience @alice_und_bob, I am curious to know what are your thoughts on building this shared sequencer from scratch using Substrate VS forking the relay chain?

Shared Sequencers on Polkadot

I am not sure if I understand this correctly. Do you mean a root parachain that collects transactions for multiple other chains and creates blocks? Or perhaps something like nested relay chain? Sorry, I can’t create a clear picture here.

1 Like

I don’t really get the point here @sourabhniyogi. If it’s possible with engineering to have the shared sequencers on Polkadot (or maybe Kusama) with the same efficiency and promise as forking it, I don’t see why it won’t be done. It not only gives a very high economic security to the shared sequencers but also adds the possibility of interoperating with other chains in the Polkadot ecosystem. However, as mentioned here, I am not sure if this is the most efficient way.

I think the view that Madara or chains like Avail are stealing the Polkadot tech is indeed short-sighted. I think it’s almost certain that we are going to see hundreds of rollups on Ethereum in the near future. That will happen regardless of whether they use Substrate (or any Polkadot tech) or not. Under such a situation, I feel it makes sense for Polkadot to want Substrate to be the go to framework for these rollups. This not only opens opportunities for a lot of new developments to be pushed upstream into the Substrate framework but also helps in spreading the word and battle-testing the framework. Correct me if I am wrong, but I believe that has always been the promise of Substrate - build blockchains regardless of whether they are linked to Polkadot or not.

You are right, it should be done, will be done, can’t be stopped. You’ll just get a lot of resistance from others who have been trained with “Ethereum=sync=unscalable=broken” (on par with “gas is bad for the environment”), none from me. If you create demand for DOT (or KSM) because all you need is Polkadot (or Kusama’s) DA, you decrease the resistance significantly because like, revenues+user growth, but you’ll still have the resistance psychologically from that training, and some people prioritize technical purity and beauty over revenues+user growth.

For developments to be pushed upstream into the Substrate framework, I think that’s very exciting! It has happened from parachains => Parity and should happen in new ways with Madara. With “decentralizing Parity” tectonic plates in motion, now is the best time to talk about it.

Could you explain what Madara can do concretely on that upstream path in Winter/Spring 2024 and how this create can demand for more DOT (or KSM) by the end of 2024?

1 Like

My point is that forking Polkadot to become a shared sequencer is looking at the existing solution in the wrong way.

The sequencing happens at the level of collators and is already done when blocks reach the relay chain.

From what I understand, one would want shared sequencing for at least one of three reasons:

  • atomic synchronous composability
  • reducing cost overhead on infrastructure
  • MEV opportunities

It would be helpful to highlight which of these goals you want to achieve.

If you are looking for a good starting point to build shared sequencing with Substrate I suspect it will be by separating consensus from business logic within the Substrate runtime such that a single Substrate runtime runs consensus but could host multiple business logic sub-runtimes and it actually just runs on a single chain. You could cherry pick some logic from the relay chain on WASM management. But it wouldn’t be the full parachain system on the relay chain side.

But it would be helpful to involve actual Substrate developers in this discussion. I’m just guessing here.

What I can suggest as an approach is that you familiarize yourself more with how Polkadot 1.0 works and then read up on the current 2.0 concepts that are floated around. Maybe you will discover a fundamentally different but even better fitting approach. E.g. the Polkadot Ethereum bridge allows you to open XCM channels to smart contracts on Ethereum. Maybe there is already something feasible in the existing infrastructure

I totally agree – I think the DA layer is underutilized and if we just get Smart Contracts on the relay chain (with suitable sandboxing and limits) we have not much engineering to do. This should be done in CoreJam but we can build a PoC right now in a testnet, with Kusama as the starting point.


  1. here is my proposal to put OP Stack on Kusama where I’m quite sure doing Arbitrum would be quite straightforward as a followon.
  2. If you and/or others in the Madara team could write a parallel proposal to put zk Rollups on Kusama…

Then we have pretty much have 90% of Ethereum L2s covered and we will be like revenue/user growth heroes, if those 100s of rollups show up. If demonstrating on Kusama can lead to Polkadot later, then the 100s of rollups will have SCALABILITY of both Kusama and Polkadot relay chain in 2024, probably with 2 different price points (just like two kinds of car models from the same company). As soon as practicable, we would want to see a full CoreJam way to get L2=>L1 sequences recorded (the big revenue), fraud proofs, and the zk verification process. The CoreJam solution WILL have XCM in there and I suspect with a messaging chain for scale.

This would basically be:


However, the primary gating condition is #33 Kusama Relay chain having EVM Contracts. The resistance to this idea is entirely cultural coming from the top down. If you encounter resistance from the people who can’t see why hybrid relay chains would be beneficial with a highly sophisticated Ethereum L2 Business Owner customer base, then I think a fork would be in order.

I guess we are confusing what parts of Polkadot I would like to fork. I am actually not thinking of forking any of the WASM management code as the verification of rollups will continue to happen on the L1. The purpose of the shared sequencer is to

  1. Collect transactions and create blocks (this feature would need to be added because as of now the relay gets ordered transactions from collators)
  2. Create standards for interoperability. XCM and XCMP (parts of Substrate to be precise)
  3. Trustless cross chain communication (accords when it’s available)
  4. Commitment to the L1 (will need to be added)
  5. Allow rollups to sync blocks from the shared sequencer (the same way parachains listen to the relay chain)

With that being said, I agree, there’s still a lot I need to read about the Polkadot ecosystem and there’s a maybe a better way to approach this problem. Thanks for your suggestions!

Sure! Here are some things that the people at Madara plan to do (or have already done) with Substrate

PS: This work has been done by multiple organisations in the Starknet ecosystem over the past few months.

  1. Madara has created a pallet which integrates the Cairo VM into Substrate. This means you can just add the pallet and support Cairo contracts out of the box. This is the template to create a Madara chain. For context, Cairo is a general purpose zk provable programming language. So using this pallet allows you to support provable smart contracts.
  2. We have a team working on implementing HotStuff using Substrate and also plan to implement Tendermint eventually.
  3. We have already built interfaces to support DA layers like Avail, Celestia or even Ethereum.
  4. We are working on integrating the Starknet OS which would allow Substrate chains that use Madara to directly use Starkware’s SHARP prover for creating proofs.

how this create can demand for more DOT (or KSM)

To be clear, my post here was intended to get feedback from the ecosystem and not ask for any specific monetary assistance. However, I understand your concern in the context of the DOT ecosystem. We feel that we are paving the way for building zk powered blockchains using Substrate. This should eventually allow zk powered parachains for Polkadot (which I believe is of interest to the ecosystem based on other posts on this forum). And it only makes sense that this should then create demand for DOT/KSM.

Can you point us the github links for these interfaces? I think we can map it to Polkadot + Kusama DA layers, and this would basically result in DOT+KSM revenue.