Technically speaking Polkadot is way ahead of the curve. If you look at the Ethereum ecosystem, e.g. super chains: The future they are describing, the things they want to build, if you read it you realize: “Wait isn’t this Polkadot?” And then you realize uh no, because you still have a multisig smart contract at the bottom and the whole trust of everything relies on the L2 sequencers, rendering the L1 pretty much pointless.
So the future they want to build is pretty much what Polkadot already is, but not as good. Their vaporware is worse than our already running production system.
Despite that, if you go to conferences, barely anyone speaks about Polkadot. Everything is Ethereum. Why is that? One argument you could come up with is network effects, but in my mind this hardly holds. Given the nature of optimistic rollups, the interfacing to the L1 is hardly any better (or actually worse), than what we could do with a bridge.
So what else is it, given that we even have Ethereum compatibility parachains? There are a couple of potential reasons, but one that is likely relevant is that we are not meeting the users where they are. We always treated smart contracts as a second class citizen, despite all of Ethereum (the largest ecosystem) having nothing else to offer and still being the largest ecosystem. Conclusion: Smart contracts are actually not that bad and they have something, we are badly lacking at: A really low barrier to entry.
For this reason I would suggest that we should make smart contracts an integral and very well communicated part of our network onboarding strategy. Ethereum compatible chains should not be perceived as some random parachain, but as something absolutely crucial to our ecosystem and should be one of the first things people stumble upon when looking into Polkadot. Ethereum is after all where the people are - we need to meet them there.
Then obviously bridges - we need to have a good interoperability story with Ethereum main net.
Now that we have them, we can convince them of the unique benefits of our platform and win them over to use ink!. Then if they want to go even further beyond Ethereum capabilities, they will write their own pallets … contribute to their existing smart contract chain or spin their own on-demand chain.
Now we really want shared collator-as-a-service infrastructure, so the step from smart contract to on-demand will still be as easy as possible (no need to run your own infrastructure).
Then you will advance to using bulk core time and only at the very end of your journey, you might want to start looking into having your own collator set.
So roughly, what would be good priorities from my perspective (lot of it already aligns well):
- Developer Experience:
- Great Docs
- Way less breaking changes
- If we break things: Clear description of those changes in the release notes, together with upgrade path. SemVer!
- Better onboarding
- Great smart contract chains - maybe improved by making the L1 a full text segment of the Polkadot UC. (Does not only offer ability to store PVFs, but also smart contract code.)
- Compatibility to Ethereum: Move focus here even more.
- core time
- shared collator infrastructure so people don’t have to run their own nodes
- Improved reliability and code quality
- Scalability promise via “low quality” blockspace
Last point needs some elaboration: Ethereum L2s and other projects have crazy scalability promises these days. They basically want to deliver on our own promise of a decentralized web. If you want to decentralize whole web 2, you need crazy scalability - way more than Polkadot in its current form could ever deliver. The reason being, totally different security and threat models. For lot’s, if not all classic web2 applications our block space quality is massive overkill. We should have a story to tell for these applications. Like having an idea, some concept of being able to provide “low quality” block space in the future, in a way that does not taint our high quality block space. (If low quality block space gets compromised, it must not take down high quality block space with it.) This should be possible by restricting communication between the two (e.g. only one way)
In a nutshell: The parachain first approach was in my opinion the wrong bet. Smart contracts and then hybrid chains make way more sense. This also immediately leads to larger surface areas you can have synchronous compatibility over. From a technical standpoint (scalability), parachains should be grouping localized data. Data that is highly likely to be used often and intensely together should ideally live on the same chain.
From my perspective, there are only two reason, why you would want to run your own parachain:
- You ran into scalability limitations and just need another shard.
- You need to do something, existing parachains just can’t (or not efficiently enough) do, and you can also not extend one of them to do it (for technical, or other reasons)
And that is pretty much it, I think.
TL;DR: Ideally, Polkadot would be seen to outsiders as part of the Ethereum ecosystem. One could be worried that this would make us lose our identity, but I would not be worried too much about that. We could be the Ethereum solution on the market, that is also known as having so much more to offer as a nice bonus. Then eventually, with enough adoption, those “nice bonuses” will become non-negotiable. Think of it as: “They will come for Ethereum, but then they stay for Polkadot.”