Polkadot's Build Horizon

#polkadot

This write-up explains what Polkadot is at 4+1 different levels for Builders, in a color coded fashion:

Polkadot, the platform itself
Onchain Development: Runtime/Parachain/Task development
Onchain Development: Smart Contract
Messaging between the previous components
(+1) Off-chain applications talking to any of the above items.

For each item, I have listed what I believe to be the best “educational resource” on the topic now or in the near future. This is by no means exhaustive, and I encourage readers to comment what else they can think of.

I generally refrain from referencing docs.substrate.io as it is not a well maintained resource. I am working, and hope to see a smaller but more accurate replacement for this website, such as polkadot-sdk-docs

1. Polkadot, the Platform

First, what is Polkadot itself, as a platform? A ubiquitous computer/blockchain that is

Multicore, as in, it has heterogeneous sharded execution. Each shard/core can execute a different task.
Provides a homogenous layer of shared security over all the cores and all the tasks that run on these cores.
So far, the only type of task explored has been what we call a "para-chain", but going forward, we expect to see diverse type of tasks being deployed on Polkadot.
So far, the only way to acquire execution time on a core (i.e. "core-time") has been to win a parachain auction, but soon, with agile core-time, acquiring core-time will become much easier and granular.

Resources

2. Onchain Development – Runtime / Task

Runtimes are the primary type of tasks that can run on Polkadot cores. They are expressed as WASM blobs. They are scheduled anywhere between one block at a time (formerly known as on-demand parachain, or parathreads) to 2 years (formerly known as a parachain) to anywhere in between (agile-coretime). Commonly built with FRAME, and typically representing a blockchain application logic. But, crucially, a runtime can also represent any other application.

Resources

3. Onchain Development – Smart Contracts

A task/runtime that run on a Polkadot core can itself be what is known as a smart contract platform, similar to Ethereum or Solana, examples of which are Moonbeam and Astar. These platforms could support multiple virtual machines such as EVM and WASM, or both.

Therefore, Polkadot supports smart contract development as a secondary feature through its evolving ecosystem of parachains. There have also been discussions/proposals on a native smart contract platform for Polkadot, but none has existed so far.

Moreover, a team can utilize the above technology to deploy what is known as "single dApp chain". Imagine a contract is successful in a shared environment, such as Moonbeam, and now wants to have more bandwidth and lower fees. This can be achieved by a runtime, written with FRAME, that can execute smart contracts, and only hosts the contracts of this one team. Then, some contracts can be rewritten as FRAME modules, enabling more bandwidth and low-level features. Finally, the contract can graduate to a full FRAME runtime. More on this in the recap figure down below.

Resources

4. Onchain Development – Interoperability and Message Passing

Because of Polkadot’s shared security, Runtimes and Smart Contracts (or any other task that resides on a core) can communicate with one another without a need to worry about the economic security of the recipient of the message. Any message can be sent between cores, yet the primary language adopted in the ecosystem is XCM, short for Cross Consensus Message.

XCM-docs

5. Offchain Development

Polkadot ecosystem comes with a slew of APIs to write decentralized^[1] applications that are based on the previous primitives. These programming APIs will allow developers to connect to and interact with a runtime, a smart contract, or both.

Resources

Recap

The following figure shows all the aforementioned development types:

Polkadot, the platform itself
Onchain Development: Runtime/Parachain/Task development
Onchain Development: Smart Contract
Messaging between the previous components

All cores in this figure are being used for bulk coretime, except Core 3 which is meant to represent instantaneous coretime.
T1 and T2 are two runtimes sharing a core. This represents a broad category of scheduling where they take turns, uses a secondary market, or anything else.
- See RFC#1 for more examples.
T3 is a long-running Runtime, using bulk coretime.
T4 is a generic smart contract platform like Moonbeam. Your application can be one or many of the contracts running on T4.
T5 is a proprietary smart contract platform aka. “single dApp chain”, where you have pallet-contracts, a number of contracts, and a number of (custom) FRAME pallets all baked into a single runtime. This runtime can initially be scheduled sporadically, as is the case with T5.
T6 is the same as T5, but scheduled on a dedicated core, as opposed to on-demand.
- So, for example, imagine the following user journey for a business on Polkadot: You start as a set of contracts running on an existing parachain. You expand into T5, a "Single-dApp Chain" where you can have both contracts, and pallets. Once the demand ramps up, T5 evolves to T6, meaning you use more bandwidth. Finally, one could eliminate all contracts and use only pallets for their application logic, such that they can leverage control over the runtime maximally, such as T3.
Any communication within one Runtime (so long as you remain in one green box) is synchronous. Anything that wants to cross the boundaries of the green box is asynchronous. Any two components in this figure can talk to each other, but if it is asynchronous, it could use XCM.
- This is a good moment to reflect: a lot of the complexity in XCM is exactly because it is designed to deal with asynchronous communication across consensus systems.
Technically, any communication within one core can be synchronous, but this is not how it is implemented now. In principle, two parachains that are co-scheduled on a single core (T1 and T2) can also have synchronous communication.
Finally, T7 is representing an application that is utilizing two Polkadot cores at the same time. This essentially allows a runtime to move at very fast block times. This is enabled by what is known as "async-backing". Moreover, Polkadot could allow tasks to increase and reduce their bandwidth on the fly. This is called "elastic scaling".

Miscellaneous Resources

decentralized: Polkadot comes with a light-client-first application development mindset, which means applications written with the following tools can connect to light clients (instead of centralized API providers) and actually be decentralized. ↩︎