Module polkadot_sdk_docs::polkadot_sdk::polkadot

Learn about Polkadot as a platform.

Polkadot

Implementation of the Polkadot node/host in Rust.

Learn More and Get Involved

• Polkadot Forum
• Polkadot Parachains
• Polkadot (multi-chain) Explorer
• Polkadot Fellowship
  • Manifesto
  • Runtimes
  • RFCs
• Polkadot Specs
• The Polkadot Parachain Host Implementers’ Guide
• Whitepaper

Alternative Node Implementations 🌈

• Smoldot. Polkadot light node/client.
• KAGOME. C++ implementation of the Polkadot host.
• Gossamer. Golang implementation of the Polkadot host.

Platform

In this section, we examine what platform Polkadot exactly provides to developers.

Polkadot White Paper

The original vision of Polkadot (everything in the whitepaper, which was eventually called Polkadot 1.0) revolves around the following arguments:

• Future is multi-chain, because we need different chains with different specialization to achieve widespread goals.
• In other words, no single chain is good enough to achieve all goals.
• A multi-chain future will inadvertently suffer from fragmentation of economic security.
  • This stake fragmentation will make communication over consensus system with varying security levels inherently unsafe.

Polkadot’s answer to the above is:

The chains of the future must have a way to share their economic security, whilst maintaining their execution and governance sovereignty. These chains are called “Parachains”.

• Shared Security: The idea of shared economic security sits at the core of Polkadot. Polkadot enables different parachains* to pool their economic security from Polkadot (i.e. “Relay Chain”).
• (heterogenous) Sharded Execution: Yet, each parachain is free to have its own execution logic (runtime), which also encompasses governance and sovereignty. Moreover, Polkadot ensures the correct execution of all parachains, without having all of its validators re-execute all parachain blocks. When seen from this perspective, Polkadot achieves the ability to verify the validity of the block execution of multiple parachains using the same set of validators as the Relay Chain. In practice, this means that the shards (parachains) share the same economic security as the Relay Chain. Learn about this process called Approval Checking.
• A framework to build blockchains: In order to materialize the ecosystem of parachains, an easy blockchain framework must exist. This is Substrate, FRAME and Cumulus.
• A communication language between blockchains: In order for these blockchains to communicate, they need a shared language. XCM is one such language, and the one that is most endorsed in the Polkadot ecosystem.

Note that the interoperability promised by Polkadot is unparalleled in that any two parachains connected to Polkadot have the same security and can have much better guarantees about the security of the recipient of any message. Bridges enable transaction and information flow between different consensus systems, crucial for Polkadot’s multi-chain architecture. However, they can become the network’s most vulnerable points. If a bridge’s security measures are weaker than those of the connected blockchains, it poses a significant risk. Attackers might exploit these weaknesses to launch attacks such as theft or disruption of services.

Polkadot delivers the above vision, alongside a flexible means for parachains to schedule themselves with the Relay Chain. To achieve this, Polkadot has been developed with an architecture similar to that of a computer. Polkadot Relay Chain has a number of “cores”. Each core is (in simple terms) capable of progressing 1 parachain at a time. For example, a parachain can schedule itself on a single core for 5 relay chain blocks.

Within the scope of Polkadot 1.x, two main scheduling ways have been considered:

• Long term Parachains, obtained through locking a sum of DOT in an auction system.
• on-demand Parachains, purchased through paying DOT to the relay-chain whenever needed.

The Future

After delivering Polkadot 1.x, the future of Polkadot as a protocol and platform is in the hands of the community and the fellowship. This is happening most notable through the RFC process. Some of the RFCs that do alter Polkadot as a platform and have already passed are as follows:

• RFC#1: Agile-coretime: Agile periodic-sale-based model for assigning Coretime on the Polkadot Ubiquitous Computer.
• RFC#5: Coretime-interface: Interface for manipulating the usage of cores on the Polkadot Ubiquitous Computer.

Learn more about Polkadot as a Computational Resource.