Make Polkadot great again

Ecosystem
1

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):

  • Marketing
  • Bizdev
  • 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.
    • on-demand
    • 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:

  1. You ran into scalability limitations and just need another shard.
  2. 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.”

28 Likes
2

First, thank you for the write-up! Thought-provoking and timely.

As of last year, the PBA content explicitly conveys a similar message (see speaker notes of the slide for the answer). But it is hard to imagine that this would trump years of marketing around “build your own parachain”. Nonetheless, if your conclusions are valid, the material around Polkadot should move more and more towards: “You should use Polkadot cores through any of the given ways, including but not limited to building a parachain”.

I’ve personally felt the downside of the slower workflow of the runtime development model, as opposed to the smart contract development model in a few places (example), and wished for a way to deploy contracts on the relay/system chain for faster prototyping.

All in all, I think the trend of moving toward a more agile ecosystem was already coming (previously by the anticipated release of parathreads), and is bolder nowadays with the agile coretime-centric future. The two main issues with our previous approach seem to have been:

  1. lack of synchronous composability
  2. development burden and maintenance cost

Rephrasing your main thesis: Polkadot did a great job at providing a sharded interoperable blockspace platform aka. cores years ahead. But, possibly it made a mistake at making the utilization of those cores be centered 2y parachains without focus on the downsides of it. Nonetheless, I see a lot of value in Polkadot having the superior foundations in place. More agile development possibilities combined with the much more scalable core primitive can open doors beyond what we see today in Ethereum and its L2s.

If I were to describe Polkadot’s development landscape to a new developer today, this is my latest interpretation:

Polkadot (was and still) is the only platform that provides proper sharded execution and shared security. Cores are the main primitive that enable this.

  • If look at Ethereum, it is like one massive core where you have shared security among the first-class users of the core (native contracts), but no native sharded execution.
  • If you look at Cosmos, it is like a potentially infinite number of sharded execution cores (hubs) with no shared security.

Then, the (onchain) build opportunities are as follows:

  • In principle, any task (coined by RFC #1) can reside on a core and utilize it. A task can occupy a core as short as 1 relay chain block, and as long as 28 days at a time, or any fancy variety in between.
  • At the moment, the primary type of tasks are FRAME-based runtimes.
  • Other types of tasks, as long as they adhere to some standard, can be scheduled on cores as well. This is similar to running a smart contract directly on a core.
  • A task can itself be a long living L2 platform like Moonbeam or Astar where you can deploy other types of secondary tasks, such as EVM or WASM contracts.

All in all I find this a very promising narrative. The move toward agile coretime is by no means an acknowledgement that something in the foundations of Polkadot was wrong (a misunderstanding that I am worried might arise – Oh, Polkadot realized it should have done contracts all along), but it is mostly a matter of how the same solid foundation is packaged and sold to others.

12 Likes
3

I disagree…

I do think PolkaVM should be a high priority, both for smart contracts and PVFs. Yet, prioritizing smart contracts per se sounds like web2 companies saying they want to scale with SQL stored procedures. If anything, frame/storage already behaves too much like a smart contract language.

It’s actually worse of course…

Smart contracts bring too many additional problems. Ethereum always wanted sharding, but gave up, in part because smart contracts play poorly with sharding. At some point they’d some massive list of proposals, like maybe 40 or 60, so tricks like yanking smart contracts across shards, etc.

There is a semi-crackpot named DataFinnovation who claims scalable blockchains cannot exist because they cannot handle negative balances (via). In reality, we only need negatived balances in accounting so that humans can check everything manually, while computers are plenty fast enough to handle worldwide transactions with only positive balances, but…

There is a kernel of truth in his argument in that you still need data sharding. This is at odds with the smart contract model, but not at odds with messaging models, like parachains or diverse roll ups.

Yes, a single parachain could sequence multiple blocks in one single relay-chain slot, but this remains non-scalable because the collator that creates these little blocks sequence remains non-scalable, and one relay chain can only track so many chained state root updates. Yes, we should make a polkadot based smart contract chain faster than solana.

Yet, if you want to challenge web2 platforms then you need parachains which could in theory scale to hundreds, or even thousands of blocks, within a single step of the multiple blocks across multiple relay chains. This requires paracahins shard their data models sensibly, which really conflicts with them being smart contracts.

We only kinda need smart contracts, better on-boarding, or bridges to ethereum. We really need to deliver useful applications, like actually fun games, built around sharded data models, without using smart contracts, or that use smart contracts super narrowly they cannot mess up the sharded data model. After we build a couple of these, then our ecosystem can then copy them, and produce real products.

We want say a successful massively multiplayer game with say 1 million active users, using maybe 10s of cores per relay chain block. What does an MVP require?

  • Fix storage: Radix 2 hashing. Make thread_local! work, so pallets can bypass storage.
  • User side state channels for interactivity.
  • Messages passed outside the relay chain, like XCMP, but maybe state channels between parachain shards too.
  • And doing the game itself well enough is harder than all the above.

tl;dr Smart contracts have nasty scalability rabbit holes which we’ll never solve, so focus real scalability and final products.

8 Likes
4

I agree with your point on users and that we should look for them in the Ethereum ecosystem. Ultimately, the Polkadot ecosystem should ask itself one simple question: “What can Polkadot offer to crypto users that Ethereum doesn’t already offer?” And the answer should not lie in some technical domain. Average Joe could care less about the sharding, ink, XCM, and async backing… He wants to speculate, ape shitcoins, or transfer and store value.

2 Likes
5

Just my personal opinion, but fundamentally I agree with @eskimor in that I think what we need is to fundamentally lower the barriers of entry, whether we call that a “smart contract” or not.

With smart contracts it’s easy to get started - you write some code, you compile it, you upload it on-chain, and… you’re done. Contrast that with the effort required to launch a parachain, which is a lot more involved. Developer experience is the king (usually). Ethereum would not see this level of activity if it weren’t as easily programmable, and while it’s definitely not a sufficient requirement, I think it’s a necessary one for widespread adoption.

9 Likes
6

It’s fine of course if we set some reasonable goal like “faster smart contracts than solana”, so maybe 10k tps, perhaps one single larg “sequencer” aka collator producing 20 parablocks per relay parent with 3000 tx each. We’ll need all the optimizations required to deliver this anyways.

We should remember that our core product is scalability though, and this sort of stunt is merely fast, but not scalable. We should also build something cool and much faster, not based around smart contracts.

2 Likes
7

The trend across the industry has been exactly the opposite for years: applications moving from smart contracts to appchains. This seems to be only accelerating, especially with the release of lighter weight toolkits and shared utilities for blockchains.

You could argue supporting smart contracts on the relay chain could be a funnel for future parachains, but then they should use EVM not ink!. And anyway, that doesn’t seem to be supported by the industry data.

I do think your idea of “low quality blockspace” is about right, although I wouldn’t phrase it that way. I agree with a lot of this: https://twitter.com/odysseas_eth/status/1704901732600352893. From a purely technical standpoint, Polkadot is overengineered. It’s a diamond, not a big ball of mud. One solution to this, in addition to the scheduling flexibility brought by coretime, is exposing the services offered by the relay chain à la carte so client chains can opt in to only backing or only data publication, etc.

From a perception standpoint, Polkadot has a reputation that’s in many ways opposite how it technically compares to other protocols. Parachains are actually more sovereign, more heterogenous, and in some ways (not all) less permissioned than most rollup stacks built on Ethereum. We should be hammering these points.

8 Likes
8

It is really dead-simple, if I want to build a web3 dapp on “Polkadot” (not on a parachain that is built by an external team) then how do I do this? There has never been a way.

We need a “Polkadot-native” smart contract layer. Yes smart contract is inferior to much of the tech we currently already have BUT we need to put on our “product hats” and understand that smart contracts is how we lure them in. And like @eskimor noted, once they get a taste for the smart contract they will want more in our ecosystem.

What would this smart contract layer look like? Would every system parachain have a smart contract layer akin to an API for that system parachain? Or would there be XCM-enabled smart contract system parachain? Would the smart contract layers support ink! AND Solidity? Solidity contracts that transpile to ink!? Or support both EVM and pallet-contracts?

Yes this makes sense. Ethereum is also where the liquidity is. I agree, we need a way for dapp engineers to build on Ethereum via Polkadot. Make it so that best way to build on Ethereum is to use our tech stack.

Lastly, we could do better with zk/validity tech. IMO, the Polkadot SDK should have a native ZK Prover at it’s heart in the parachain protocol and in the collator protocol. Whether we choose Risc0, Arkworks, collaborate with an existing third-party zk company, or build this from scratch, that is another discussion.

9 Likes
9

“Developer experience is king” is just an opinion.

If that were the case, then 2013/15 Bitcoin didn’t get the memo… new stuff is supposed to be hard, its just most people here have only ever known a world of insane valuations and are now obsessing over stuff that really makes very little difference in the grand scheme of things.

Maybe, just maybe, adoption is actually at the right point for the maturity of the tech, and maybe, just maybe, everything in the entire space is STRATOSPHERICALLY overvalued, unless you’re betting on a meme token, which does not require any actual tech development, just shit like this.

https://twitter.com/justinsuntron/status/1704792191451988316

When people finally start embracing the things that ONLY substrate / Kusama/Polkadot design / structure affords and stop looking jealously over the fence and cloning ideas/narratives from elsewhere at some other project there’ll be progress.

Crypto has a short shelf-life, don’t get fooled into thinking the winners have already been picked.

4 Likes
10

Polkadot offers a shared security model and a growing ecosystem of parachains. You can run network-native economies and societies using advanced features like XCM and governance and leverage on the whole expanding ecosystem.

On the other hand, Ethereum enjoys a significant first-mover advantage along with a large pool of liquidity resulting from the crypto bubble. However, it is also known for hosting numerous low-quality tokens and fraudulent schemes. The prevalent L2 narrative appears subpar compared to the existing parachain model in every aspect. Layer 2 networks could create a conflict of interest between ETH holders and users seeking lower fees, which would lead to inflation and asset devaluation. This is a compelling reason to consider switching to alternative base networks that do not have such conflicts built-in.

The space is gradually shifting towards local-first apps, which in Polkadot’s case translates into abstracting multi-chain interactions (likely intent-driven). This challenges the traditional web2 model with concepts like light clients, seamless asset swaps, and cross-network fees. You no longer need a middleman to interact transparently across different network capabilities.

Given these factors, transitioning back to a smart contract-centric position may not be the most sensible choice. Smart contracts would play a relevant role but won’t be the main competitive advantage.

Regarding liquidity, is better to get it clean from direct providers like Circle, than trying to divert it from the Ethereum network.

1 Like
11

The future is not won buy superior technology alone. Especially if it is extremely impractical to use.

Javascript was an inferior developer ecosystem with bad performance for a long time. But its intentional simplicity made it big, carried it through its initial years and bought it time to get properly optimized. Javascript has won over all its seemingly technologically superior counterparts.

Resting on techno-moral superiority will not win battles. Only creating an attractive ecosystem for developers will.

image

Giving developers easy exposure to use all aspects of the ecosystem is crucial to onboard them. All the good tech will help nobody if you need a team of 5+ people and hundreds of thousands of dollars just to operate infra and MAYBE be successful later. Most cannot afford this level of experimentation.

The current corejam draft offers some amount of isolation between different work classes in that transaction atomicity is only shared within a work class (while offering full read access to the relay-chain state). It provides the basis for an environment in which a smart contract execution environment can compete for blockspace with the parachain system and other rollups.

We need to provide a simple on-ramp for developers to tap into features deployed on Polkadot: build smart contracts → build a containerchain → build a chain

5 Likes
12

when we focus on labelling ‘people’, we fall into the trap of over indexing for some specific ‘skill’ of citizen… the contrarian view is that there are too many devs in the ecosystem and that this will in time be seen as a high water mark…

When we start with the idea that polkadot is a city. the city right now has in it only a theatre, per Coreplay RFC appendix, we can see that yes developers are important to a degree, but they are just one group - and a highly nuanced and complex one at that whose relative worth exists on a spectrum.

so yes a city could in principle be run by 99% devs, but it would likely not function very well and as things began to break down, a heap of the Rust engineers would end up becoming defacto doctors, nurses, rubbish collectors, artists and bus drivers as these would then become the skillsets needed. (to clarify I am not suggesting that we need doctors, nurses etc, just that the skills we need are myriad and ‘devs’ isn’t particularly helpful in this regard).

this article (from city to civium) and indeed Geoffrey West’s book Scale, are both useful references when considering how innovation emerges (as a necessity) as population (not of devs) grows:

Increasing population produces superlinear wealth and innovation. It also produces a variety of new pressures. To the degree that the people of the city can craft and implement solutions to those pressures, the city can continue to grow and produce superlinear results. To the degree that they can’t, stagnation and even collapse.

1 Like
13

I would argue that we already have much of the tooling to make this happen already, if not present then coming soon™. Most notably, XCM is often overlooked as something that can be used in userland to compose multichain apps via pallet_xcm. Most parachains also support contracts already, meaning if you can create an app using XCM, you can include contracts as part of your stack without touching protocol development.

I believe we have the path to scalability via coretime, and can meet demands once they exist. For example, on-demand coretime should eventually just let someone create some pallet, or very stripped down runtime, deploy it, and measure how it performs.

From the POV of someone who just wants to tinker and quickly prototype an idea on the mainnet (not locally via a template), there are really only a few options (each of which presents a large gap between time/complexity, etc).

  1. Create and deploy a parachain
  2. Choose a parachain and deploy a smart contract(s)
  3. Build a frontend app that uses various pallets

The complexity gap between these options are quite large, not to mention intimidating to most people who are new to the space, or just used to creating Solidity contracts. Simply streamlining the use of something like XCM, which is already implemented on a plethora of parachains, could be very viable in allowing people to simply create applications which fully utilize Polkadot and its parachains’ existing functionality.

3 Likes
14

Couldn’t agree more, Polkadot needs to get in the action, not ignore it on some superior tech dream. Get with the action, with the money and then show how it works better. Actions speak louder than words. Telling people its better means nothing. Showing them, means everything.

1 Like
15

I’m a big fan of this thread and the many ideas that have been highlighted.

I wonder however, with about a month since this discussion began, if the new MarComms is taking notice? (if they still work at Parity)

Three months ago they had this great interview at Kusamarian and could have included this discussion in a collaborative workshop with the community. I think the community management in this aspect is leaving lots of potential unused.