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:
- lack of synchronous composability
- 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.