Polkadot Direction · Polkadot Wiki (2024)

Understanding what Polkadot 1.0 is about and the philosophy behind it will helpus to envision the future direction of the Polkadot ecosystem toward abstraction and generalization.

Polkadot as a Computational Resource​

Polkadot has been abstracted and generalized beyond what was originally proposed and envisioned inthe whitepaper. Polkadot is:

• About Blockspace (the underlying resources thatchains need), not chains.
• A platform to build applications rather than chains and for people to use those applications.Fundamentally, Polkadot is not a platform to host chains, and so far, chains happened to be oneway to build applications and grow Polkadot's utility.
• A provider of resilient general-purpose continuation computation, where the termcontinuation refers to a broad, long-running task that can do something, pause, continue (or dosomething else) later.
• A multicore computer where chains that continuously operate in parallel on different cores arecalled parachains. Currently, one core is reserved for one chainthrough slot auction mechanism, although one core can be reservedon-demand to multiple chains at different periods (see theAgile Coretime page). At the time of writing (mid 2024), thereare around 50 cores independently operating in parallel on Polkadot.

From now on application will be used as a general term to describe anything that can use aPolkadot core to access secure and decentralized computation.

Summary​

If we see Polkadot as a service provider of trustless and resilient computation through cores aswell as secure interoperability between core-powered applications, the future development ofPolkadot can be directed towards the following main changes.

A paradigm shift from:

• being a chain-focused ecosystem where each parachain owned an execution core at all times(acquired through fixed parachain slots), which allowed a simple and secure, sharded executionenvironment
• to being an application-focused ecosystem where we remove the assumption that each applicationowns a core, and instead that all cores are a resource to be consumed and used as needed by allapplications.

Previously, securing a parachain slot was a competitive process through anauction mechanism. With coretime rental, there is no need for slotauctions anymore. Teams can purchase on-demand coretime or reserve bulk coretime as required. Thisgreatly decreases the barrier-to-entry for software tinkerers and parachain teams.

On top of those main changes, agile core usage andcoretime allocation will allow any application to access Polkadot'scomputation based on their needs without wasting valuable blockspace. Accordswill improve cross-chain communication and the security guarantees of XCM messages. Finally,Polkadot will scale by moving on-chain logic into its system parachains, allowing it to have morebandwidth for the parachains protocol and accords.

From Slot Auctions to Coretime Marketplace​

The end product of blockchains is Blockspace.Applications need to access Polkadot's blockspace, and the entry points to blockspace are the cores.Thus, applications will need to reserve some time on cores or Coretime to gain the right toaccess Polkadot's secure blockspace and interoperability for a finite period.

Cores must be agile and general: they can change what job they run as easily as a modern CPU. Itfollows that the procurement of those cores must be agile as well.

The slot auction mechanism is not agile, creates high entry barriers, and is designed forlong-running single applications (i.e., the original Polkadot vision proposed in the whitepaper).

We depart from the classic lease auctions and propose an agile marketplace for coretime, whereessentially coretime becomes a commodity that can be tokenized, sold, and traded. This setupmaximizes the agility of Polkadot and lets the market figure out the best solution needed forapplications to be successful.

Applications can reserve bulk coretime and on-demand coretime depending on their needs. Bulkcoretime rental will be a standard rental of coretime through a broker system parachain at a fixedprice for a fixed period of time. On-demand coretime rental will be available through ongoing saleof coretime for immediate use at a spot price. This system lowers the barrier to entry forprospective builders.

For example, revenues from coretime sales can be burnt, used to fund the Treasury, or used for a mixof those options. The topic is currently under discussion. For more information, seeRFC-0010 andRFC-0015.

From Chain-centricity to Application-centricity​

Polkadot 1.0 was a chain-centric paradigm consisting of isolated chains able to exchange messages.This was not fundamentally different from having completely different chains connected to bridges,with the only difference of having the relay-chain securing the network, providing message-passingcapability, and doing some extra tasks such as crowdloans,auctions, staking,accounts, balances,and governance. Having a chain-centric system will ultimatelyend in chain-centric application and UX.

The true innovation of Polkadot is about leveraging the unique value proposition offered bydifferent chains and using those chains’ collaborative potential to build inter-chain applicationsto solve real-world problems. Those applications will thus need to span across chains.

Increasingly fewer tasks will be handled by the relay-chain that will focus efforts only onprimary tasks: securing the network and providing secure message-passing capability.System parachains will be used to take over secondary relay-chaintasks such as staking, governance, etc.

XCM and Accords​

XCMP is the transport layer for delivering XCM messages. It gives thetransportation method and a secure route but not a framework for binding agreements.

XCM is a format, a language of intention abstract overfunctionality common within chains. It creates an expressive language of what you intend to do orwant to happen. XCM messages are transported between different chains using XCMP. Ideally, in afully trustless environment, strong guarantees ensure chains faithfully interpret XCM messages. Wecan have a secure mode of delivering messages that can be interpreted across protocols, but stillmessages might be misinterpreted. These guarantees can be achieved with accords.

An Accord is an opt-in treaty across many chains, where treaty logic cannot be changed orundermined by one or more of those chains, and Polkadot guarantees faithful execution of this logic.Accords will be specific to a particular function, and any chain that enters the accord will be heldto it and will service that particular function. To lower the entry barrier, accords can be proposedpermissionlessly, but because they are opt-in, the accord proposal will take effect until chainsagree and sign up.

To sum up, accords ensure that the receiver faithfully interprets XCM messages securely sent viaXCMP channels. Accords are the missing piece of the puzzle to achieve a fully trustless andcollaborative environment between applications.

Polkadot is the only ecosystem where accords can properly exist because it has a hom*ogenous securitylayer that provides a specific state transition function for each logic component. This allowspatterns of cooperation between multiple logic components (i.e., trans-applications) that would notbe possible to achieve over bridges.

Accords will be implemented using SPREE technology.

Core Usage in Polkadot 1.0​

In Polkadot 1.0, applications produced blocks at a fixed rate of 12 seconds, whether needed or not.This led to inefficient energy allocation and economic incentives for producing full blocks underheavy traffic and empty blocks under light traffic.

The figure below shows the core usage for Polkadot 1.0, where the horizontal axis is time, and eachrow represents a core. Colors show different parachains, each using one core (i.e., one parachain,one core formula).

The above setup allowed a simple and secure, sharded execution environment.

However, to achieve full efficiency, blocks must be produced when needed, and the system must targetfull block capacity, lowering the probability of incentivizing validators to build blocks half fullor, worse, empty.

Agile Coretime Allocation​

In Polkadot 1.0, coretime is a fixed two-year period on one specific core. Here, we remove thislimitation and generalize coretime usage to meet different application needs.

Split Coretime​

Owners of coretime can split or trade it. An application A1 can run on core C1 for a finite periodand then another application A2 can run on that core, or application A1 can continue running onanother core C2. Some applications might stop running for some time and resume later on.

Strided Coretime​

Ranges can be strided (i.e., applications can take turns on a core) to share costs or decrease blockproduction rate, for example.

Combined Coretime​

An application can be assigned to multiple cores simultaneously. Some applications can have apermanent core assignment and an intermittent one, for example, in a period of high demand to sendmultiple blocks to multiple cores at the same time slot to reduce latency.

Agile Core Usage​

In Polkadot 1.0, one core is assigned to one application (in this case, equivalent to a parachain).Ideally, core affinity (i.e., which application operates on which core) is unimportant (see below).Cores do not have any higher friendliness to one application than another.

Here, we remove the assumption that each application owns a core and instead that all cores are aresource to be consumed and used as needed by all applications in the ecosystem.

Compressed Cores​

The same core can secure multiple blocks of the same application simultaneously. Combining multipleapplication blocks in the same relay chain core will reduce latency at the expense of increasedbandwidth for the fixed price of opening and closing a block.

Sharing cores with other applications to share costs but with no reduction in latency. Note thatthis is different from the split coretime where one core is used by multipleapplication at different times to share costs at the expense of higher latency.

Agile Composable Computer​

All the above options of agile coretime allocation andcore usage can be composable and enable the creation of an agile decentralizedglobal computing system.

Thus, this new vision is focused on Polkadot’s resource, which is secure, flexible, and availableblockspace that can be accessed by reserving some time on a core. Agility in allocating coretime andusing cores allows for maximized network efficiency and blockspace usage.

Polkadot's Resilience​

Systems that have yet to be engineered with decentralization, cryptography, and game theory in mind,are breakable and prone to cyber-attacks. Polkadot is basing its resilience on different pillars:

• Preponderance of light-client usage: Centralized RPC servers are common but susceptible toattack and not trustless decentralized entry points to using blockchain-based applications. Lightclient usage on Polkadot is possible throughSmoldot.
• Zero-Knowledge (ZK) Primitives: They can have a problematic effect on censorship andcentralization as having a big state transition function boiled down to a single proof of correctexecution is not currently a scaling solution to build resilient systems. However, a library ofrichly featured and high-performance ZK primitives ready for specific use cases is being built.The first use-case will be used to improve privacy for on-chain collectives such asthe Polkadot Technical Fellowship.
• SAFROLE consensus: New forkless block-production consensusalgorithm replacing BABE and where block arenot produced unless they are expected to be finalized. This will provide several benefits, suchas:
  • Improved security, parachain performance, and UX from being forkless
  • Preventing front-running attacks through high-performance transaction routing where transactionsare included in blocks in one hop instead of being gossiped, and transaction encryption.
• Internode Mixnet: Shielded transport for short messages that
  • avoids leaking IP information for transactions, and
  • introduces a general messaging system allowing users, chains and off-chain workers, smartcontracts, pallets, and anything else existing within a chain to exchange messages containingsignatures, intentions, etc.
• Social Decentralization: Resilience is achieved by including many participants contributing tothe system and coming to decisions through on-chain governance. Involving as many people aspossible ensures resilience against spending becoming systemically misjudged and appropriatelydirects wealth for spending treasury funds, salaries, and grants. Another crucial way ofdecentralizing the network is ensuring experts on which the maintenance of the system relies uponare incentivized and recruited over time by the Polkadot network and not by organizations withinthe Polkadot ecosystem.