PaperlayerView exact revision on arXiv

Source-linked AI summary

Overview of Polkadot and its Design Considerations

Jeff Burdges, Alfonso Cevallos, Peter Czaban, Rob Habermeier, Syed Hosseini, Fabio Lama, Handan Kilinc Alper, Ximin Luo, Fatemeh Shirazi, Alistair Stewart, Gavin Wood

arXiv:2005.13456v3cs.CR

TL;DR

Blockchain scalability can be pursued through parallel chains, but Polkadot identifies interoperability and weaker security from splitting security power as issues to address. It connects heterogeneous parachains through a relay chain designed to provide shared security and trust-free interchain transactability.

  • Problem

    Polkadot identifies interoperability, scalability, and weaker security from splitting security power as blockchain challenges.

    Source: §1 · p. 3

  • Method

    Polkadot connects multiple heterogeneous, independent parachains through a central relay chain.

    Source: §1 · p. 3

  • Results

    The relay chain is responsible for providing shared security for all parachains and trust-free interchain transactability between them.

    Source: §1 · p. 3

  • Takeaways & Limitations

    Polkadot’s economic security backs every parachain, unlike independent chains that each receive only a fraction of equivalent total stake.

    Source: §4 · p. 9

    The Technical Committee mechanism may not be effective for emergencies involving political sensitivity or strategic importance.

    Source: §4.6.2 · p. 26

Abstract

from arXiv · show

In this paper we describe the design components of the heterogenous multi-chain protocol Polkadot and explain how these components help Polkadot address some of the existing shortcomings of blockchain technologies. At present, a vast number of blockchain projects have been introduced and employed with various features that are not necessarily designed to work with each other. This makes it difficult for users to utilise a large number of applications on different blockchain projects. Moreover, with the increase in number of projects the security that each one is providing individually becomes weaker. Polkadot aims to provide a scalable and interoperable framework for multiple chains with pooled security that is achieved by the collection of components described in this paper.

1 Introduction

The introduction frames blockchain adoption around interoperability and scalability challenges, alongside risks from centralized control. Polkadot is presented as a multi-chain system combining parallel chains with shared security and interchain communication.

1 Introduction

  • Centralized control can let a service stop, sell user data, or change its operation without users’ agreement, especially affecting those who rely on it.The paper distinguishes logical control from physical infrastructure decentralization.Source: §1 · p. 3
  • Blockchains face interoperability challenges across differing trust models and scalability limits, with existing systems generally handling tens of transactions per second versus thousands for major card networks.The paper notes that PoW and PoS systems rely on different security assumptions.Source: §1 · p. 3
  • Polkadot combines parallel chains in a shared-security system, aiming to pool their security power.The paper expands on the system first introduced in 2016.Source: §1 · p. 3
  • A relay chain communicates with heterogeneous parachains, providing shared security and trust-free interchain transactability to address interoperability, scalability, and weakened security from splitting security power.The paper describes the relay chain as central to Polkadot’s multi-chain design.Source: §1 · p. 3

2 Synopsis

The synopsis presents Polkadot as a relay chain coordinating external parachains through a defined interface. It outlines the security model, participant roles, and the sequence of relay-chain and parachain operations.

2 Synopsis

  • The relay chain provides external parachains with security and secure communication, while parachains supply application-level functionality.Parachains need only follow the specified interface; their internal systems may also be non-blockchain systems.Source: §2 · p. 4

2.1 Security model

  • The relay chain treats parachains as untrusted clients and makes no assumptions about their internals; a subverted parachain is treated as a malicious client entity.Individual relay-chain nodes are untrusted, while the protocol relies on a sufficiently large trusted subset.Source: §2.1 · p. 4

2.2 Nodes and roles

  • Relay-chain nodes may perform multiple roles; parachain collators submit data, fishermen conduct additional security checks, and validators perform the bulk of security work.The network is open to nodes participating in the listed node types.Source: §2.2 · pp. 4–5

2.3 Protocol

  • Collators build and submit signed parachain data for validator support, and block-producing validators include candidates with relay-chain extrinsics, metadata, and partial data in a relay-chain block.A later subprotocol checks data availability, message metadata informs recipient parachains of new messages, and validators vote to finalize blocks and resolve forks.Source: §2.3 · p. 5

3 Preliminaries

Section 3 frames Polkadot’s participants and security assumptions as the context for understanding the protocol’s later design.

3.1 Roles

  • Validators ratify parachain candidates and relay-chain blocks, while their randomly changing assignments require high availability and bandwidth.Validators receive, validate, and republish candidate blocks; proven failure to fulfill their role can result in slashing.Source: §3.1 · p. 6
  • Collators maintain parachain full nodes and provide validators with unsealed blocks and validity proofs; nominators contribute stake to validator security bonds.Nominators have no additional network role beyond contributing risk capital and signaling trust in validators.Source: §3.1 · p. 6
  • Fishermen can report illegal conduct for a bounty, especially invalid parachain-block ratification, but Polkadot is designed to remain secure without them.Their incentive model is not yet designed and is identified as future work.Source: §3.1 · pp. 6–7

Roles:

  • The model assumes three quarters of nominators’ stake is honest, yielding more than two-thirds honest elected validators, while malicious fishermen may be detected and punished.Honest parties follow the protocol; malicious parties may use arbitrary algorithms.Source: Roles · p. 7

Parachains:

  • Parachain security requires some honest collators, not a precise honest fraction; where a reachable honest member assumption is unrealistic, additional checks address totally malicious membership.The design makes no security assumption about parachain block production mechanisms.Source: Parachains · pp. 7–8
  • Validators and collators operate in a partially synchronous network with eventual message delivery, and honest parties are assumed to generate keys securely.The delivery bound is an unknown parameter, and collators and fishermen must be able to connect to the relay-chain network to submit reports.Source: Parachains · p. 8

4 Components and sub-protocols

This section describes Polkadot’s components and sub-protocols for coordinating a multi-chain system with pooled security. It covers validator election, relay-chain coordination, hybrid consensus, cross-chain messaging, BABE block production, GRANDPA finalisation, and parachain block and message handling.

4 Components and sub-protocols

  • Polkadot’s well-backed validators collectively secure every parachain, while erasure coding distributes block availability without sacrificing scalability.Validators attest to parachain blocks before their headers enter the relay chain; the availability and validity scheme makes attacks expensive in expectation. The paper contrasts pooled security with 100 independent chains, each backed by only 1/100 of the combined stake.Source: §4 · p. 9
  • XCMP delivers cross-parachain messages independently of finality speed, while fork-consistent histories prevent messages from reverted relay-chain branches from being received.SPREE can protect shared token-transfer logic: its centrally stored code is sandboxed from parachain state transitions, so chains cannot change it.Source: §4 · pp. 9–10
  • Polkadot combines adaptive validator and nominator rewards with per-action rewards or slashing, and uses state-weighted referenda with an elected council for governance.The reward schedule aims to sustain NPoS participation and evenly distribute validator backing; the council handles smaller decisions and cannot block a change wanted by a majority.Source: §4 · p. 10

4.1 Nominated proof-of-stake and validator election

  • NPoS lets unlimited DOT holders nominate a bounded validator set, aiming for security, scalability, and decentralisation through proportional justified representation.The election adapts Phragmén’s methods, and the paper reports efficient, scalable algorithms with constant-factor approximation guarantees for the NP-hard maximin-support problem [12].Source: §4.1 · pp. 10–12

4.2 Relay Chain State Machine

  • The relay chain is a replicated state machine coordinating global consensus across parachains, with a state-transition runtime that can be upgraded as part of the transition.Its state stores relay-chain operations rather than parachain internals; runtime functions are compiled as WebAssembly and stored as part of the state.Source: §4.2 · pp. 12–13

4.3 Consensus

  • Polkadot separates BABE block production from GRANDPA finality so blocks can be produced and optimistically executed while finality waits for availability and validity assurances.GRANDPA provides deterministic, provable finality; it can finalise quickly when no problems are reported or delay for further checks, while messaging speed depends on block time rather than finality time.Source: §4.3 · p. 14

4.3.1 Blind Assignment for Blockchain Extension (BABE)

  • BABE privately assigns validators to block-production slots using randomness and VRFs; a public Aura-based mechanism fills empty slots but does not contribute to BABE security.Validators learn their slot assignments at the start of each epoch and prove eligibility when producing a block; BABE is similar to Ouroboros Praos but differs in chain selection and timing assumptions.Source: §4.3.1 · p. 14
  • BABE elects slot leaders through VRF thresholds and provides common-prefix finality, honest block contribution, and chain growth under an honest supermajority.Its chain-quality guarantee ensures at least one honest block in the best chain during an epoch, preventing randomness from being biased; honest supermajority prevents malicious validators from preventing chain growth.Source: §4.3.1 · pp. 15–16

4.3.2 GRANDPA

  • GRANDPA separates finalisation from block production, using 2/3-GHOST voting to agree on and finalise chain prefixes across multiple blocks.Validators prevote on a best chain, precommit to the 2/3-GHOST head of observed prevotes, then finalise the head derived from observed precommits; safety constrains later votes to descendants of the prior estimate, while a rotating primary supports liveness.Source: §4.3.2 · pp. 16–18

4.4.1 Block Production

  • A parachain collator produces a block, validators verify its PoV and sign its header, and relay-chain inclusion and finalisation determine its canonical status.Stateless parachain validators use the relay-chain-stored state transition validation function (STVF) to check the PoV block, whose witnesses provide Merkle proofs for state elements used or modified by the transition.Source: §4.4.1 · p. 18

4.4.2 Validity and Availability

  • Polkadot distributes parachain PoV data using erasure coding so validators can reconstruct it, and combines validator checks, staked fishermen reports, and randomly assigned checks to detect invalid blocks.Validators who signed an invalid block are slashed, and enough randomly assigned checks are awaited before voting on the block in GRANDPA.Source: §4.4.2 · p. 19

4.4.3 Cross-chain Message Passing (XCMP)

  • XCMP aims to deliver messages quickly and fairly, in order, and with proof that they belong to the sender’s finalised history.Outgoing-message metadata is committed on the relay chain, while message bodies are distributed with proofs linking them to that metadata; relay-chain history provides consistent ordering and prevents a sender from reorging away a sent message.Source: §4.4.3 · pp. 19–20

4.5 Economics and Incentive Layer

This section describes Polkadot’s economic and governance mechanisms, including staking rewards, fees, treasury funding, block-resource limits, and parachain-slot allocation. It also covers the separation and cryptographic design of account and session keys for staking, governance, and validator security.

4.5.1 Staking rewards and inflation

  • Validators and nominators earn stake-proportional rewards, while commissions, equal-work support payouts, and action points shape incentives for reliable, decentralized validation.Governance-set staking and interest targets adjust the average reward rate and thereby control inflation; stakers’ DOT can be locked and slashed for misconduct.Source: §4.5.1 · pp. 21–22

4.5.2 Relay-chain block limits and transaction fees

  • Relay-chain blocks cap byte length, processing time, and memory, reserving at least 25% of each resource limit for high-priority transactions.Fees vary by transaction type, on-chain length, and expected resource use, and an adaptive traffic-based multiplier aims to keep blocks from being full and inclusion times short.Source: §4.5.2 · pp. 22–23

4.6 Governance

  • All protocol changes require a stake-weighted referendum, with the majority of stake commanding the network.DOT holders can submit and endorse proposals, vote on referenda, and participate in Council elections.Source: §4.6 · p. 23

4.6.1 Proposals and Referenda

  • Public proposals favor the status quo at low turnout, while unanimously supported Council proposals favor approval; approved changes take effect after an enactment delay.Referendum voting power is stake-weighted and can increase with voluntary token-locking; the delay is fixed at 28 days for public and ordinary Council proposals, while emergency proposals are fast-tracked.Source: §4.6.1 · pp. 24–25

4.6.2 The Council and the Technical Committee

  • The Council represents passive stakeholders and elects 23 members monthly through stake-weighted approval voting, while the Technical Committee can help fast-track emergency referenda.Emergency proposals require approval from at least three-quarters of Council members and two-thirds of Technical Committee members; the unelected Committee cannot act unilaterally, and its narrow remit may not suit politically sensitive emergencies.Source: §4.6.2 · p. 26

4.6.3 Allocation of parachain slots

  • Candle auctions allocate DOT-bid parachain leases, with winning bids locked as deposits whose opportunity cost is the lease cost.The design offers contiguous six-month slots in combinations lasting 6, 12, 18, or 24 months and aims to limit sniping and give less-funded projects a chance to win.Source: §4.6.3 · pp. 26–27

4.6.4 Treasury

  • The Treasury funds software updates and system operations under DOT-holder governance, drawing on validator-reward minting, transaction fees, and slashings.The difference between scheduled minting and validator rewards goes to the Treasury; slashed DOT can fund responses to issues or governance-approved reimbursements.Source: §4.6.4 · p. 27

4.7.1 Account keys

  • Stash accounts lock funds for staking and delegate staking powers to controllers and governance votes to proxies, neither of which can transfer funds.Balances can support staking, resource rental, and governance locks of different durations, including concurrent unlocking periods. Account keys support ed25519 and Schnorrkel/sr25519, with similar security; ed25519 is recommended for HSMs, while sr25519 supports HDKD and multisignatures.Source: §4.7.1 · pp. 27–28

4.7.2 Session keys

  • Session keys receive role-specific authority through controller-signed certificates that can be paused, revoked, or replaced in advance.Keeping session keys on one machine and having operators issue certificates through RPC reduces accidental equivocation; duplicated keys across machines weaken security and can cause pointless slashing.Source: §4.7.2 · p. 28
  • BABE uses Schnorrkel/sr25519 VRFs to assign slots: producers know their eligible slots in advance, while public keys let others verify slot correctness.The randomness input hashes prior-session VRF outputs, so BABE keys must be registered at least two epochs early. Hashing the signer key with the input reduces output malleability, and hashing input and output together improves composability.Source: §4.7.2 · pp. 28–29
  • GRANDPA uses aggregatable BLS signatures on BLS12-381 for performance, with a straightforward curve upgrade anticipated if security falls significantly below 128 bits.The passage notes that number-field-sieve advances could reduce BLS12-381 security below that threshold.Source: §4.7.2 · p. 29

4.8 Networking

This section outlines Polkadot’s networking layer, the communication services it needs, and the mechanisms, limitations, and design choices involved in providing them. It also describes planned separations in discovery and address-book design, plus transport authentication and resource controls for unauthenticated connections.

4.8.1 Networking overview

  • The networking functions include accepting user transactions and other external data, distributing collation and finalisation artifacts, synchronizing previously finalized state, accepting parachain blocks, and distributing block metadata with validity attestations.Source: §4.8.1 · pp. 29–30

4.8.2 Gossiping

  • Polkadot’s relay-chain gossip uses push-based dissemination with hash-based duplicate tracking and ordering and protocol-specific restrictions, while its current ad-hoc topology is a weakness.Planned topology work includes a rotating structured overlay for trusted nodes and latency-informed neighbor selection, with designs intended to mitigate eclipse and Sybil attacks.Source: §4.8.2 · pp. 30–31

4.8.3 Distributed service

  • For external services such as transaction acceptance, state synchronization, and collated-block intake, clients connect to selected nodes in the relevant validator set.The initial implementation selects nodes via the address book; load balancing connections across the target set and ensuring availability remain future work.Source: §4.8.3 · p. 31

4.8.4 Storage and availability

  • To avoid requiring every node to store all parachain state, blocks are erasure-coded into validator-specific pieces, and the protocol aims to keep enough pieces retrievable for distribution, approval, and later checks.It follows a BitTorrent-like approach with known recipients, allowing proactive pushes as well as pulls; piece-location information is broadcast through relay-chain gossip rather than a centralized tracker.Source: §4.8.4 · pp. 31–32

4.8.5 Cross-chain message

  • XCMP networking must deliver each recipient parachain’s incoming messages from sender outboxes; retrieving and decoding all erasure-coded outboxes is a possible but inefficient initial approach.Further work is aimed at converting outboxes into retrievable inboxes, and messages must be distributed reliably because, unlike availability pieces, they have no built-in redundancy.Source: §4.8.5 · p. 33

4.8.6 Sentry nodes

  • Optional sentry nodes let a private full node communicate through proxy-like full nodes, supporting load balancing and DoS protection, though they add latency and cannot protect against exploits granting arbitrary execution on a sentry.Sentry traffic receives some verification and sanitisation by the Polkadot protocol, unlike traffic through lower-level proxies.Source: §4.8.6 · pp. 33–34

4.8.7 Authentication, transport, and discovery

  • Polkadot uses a modified libp2p Kademlia DHT for address lookup and discovery, with large routing tables and planned S-Kademia multipath routing to help prevent Eclipse attacks.Random key-space lookups and acceptance of incoming connections ease support for light clients and other unprivileged users, but also make DoS attacks easier.Source: §4.8.7 · p. 34
  • Further work plans to separate discovery from the address book, authenticate some transport connections against trusted validators, and resource-limit unauthenticated incoming connections without starving authenticated peers.The design retains the ability to accept incoming connections from unauthenticated entities.Source: §4.8.7 · p. 34
  • Further work would decouple the address book implementation from its interface, enabling options such as an on-chain component despite differing security tradeoffs, including out-of-scope location privacy.Offering alternatives is intended to serve nodes with different security requirements.Source: §4.8.7 · p. 34

5 Future Work

Polkadot’s future work spans incentives, messaging, scalability, bridging, and usability. Planned extensions include SPREE, nested relay chains, bridges to other chains, and temporary Parathreads.

5 Future Work

  • Future work includes incentivising fishermen to report malicious behaviour and developing SPREE for trustless messaging.The authors also plan to investigate nested relay chains to increase scalability.Source: §5 · p. 34
  • Planned bridging protocols target Bitcoin, Ethereum, and Zcash.Source: §5 · p. 34
  • Parathreads are planned as temporary alternatives to parachains, with a different fee model, to increase usability.Source: §5 · p. 34

A.1 SPREE

SPREE is intended to let parachains use shared, sandboxed code whose execution is protected by Polkadot’s shared security. The section describes its module design and upgrade behavior, illustrates trust-minimising token transfers, and notes that parts remain unfinished.

A.1 SPREE

  • SPREE addresses uncertainty about trusting another parachain’s code or governance by providing shared code that governance cannot change.Shared security can then guarantee correct execution of that known code.Source: §A.1 · p. 37
  • A SPREE module is relay-chain code that parachains can opt into, with execution and state sandboxed from the rest of their state transition validation function.Remote modules can be addressed by XCMP, and a module controls message distribution for chains using SPREE modules.Source: §A.1 · p. 37
  • SPREE module upgrades are scheduled on the relay chain and applied across parachains in their next blocks, preventing messages from newer versions reaching older ones.The authors say these messages therefore need neither forward-compatible formats nor standards.Source: §A.1 · p. 37
  • A SPREE token module could let parachain B transfer A’s tokens onward without A maintaining an account for B, while preventing B from minting them.XCMP delivery and SPREE’s interpretation guarantee support a trust-free transfer using one message per transfer.Source: §A.1 · p. 37
  • Parts of SPREE’s design and implementation have not yet been fully designed.Source: §A.1 · p. 37

A.2 Interoperability with External Chains

Polkadot’s external-chain bridges are designed around a bridge relay and a bank, with the relay verifying the bridged chain and the bank handling backed assets. For Bitcoin and Ethereum 1.0, the proposed bridge relay uses a longest-chain bridge chain with voting or attestation to resolve conflicts.

A.2 Interoperability with External Chains

  • The bridge has two parts: a relay that verifies bridged-chain consensus and transaction inclusion proofs, and a bank of staked actors holding bridged-chain tokens for Polkadot.Source: §A.2 · p. 38
  • Users can lock bridged-chain tokens in the bank to back corresponding Polkadot assets, then redeem those assets for the bridged-chain tokens.Source: §A.2 · p. 38
  • The bridge relay aims to place as much thin-client logic as feasible on a bridge parachain, where cryptography and storage are cheaper than in an Ethereum smart contract.The design puts bridged-chain block headers and transaction inclusion proofs in bridge-parachain blocks to assess whether a transaction is in a probably final chain.Source: §A.2 · p. 38
  • For Bitcoin and Ethereum 1.0, the proposed bridge relay uses a longest-chain bridge chain and voting or attestation to resolve conflicts.Source: §A.2 · p. 38

A.3.1 ETH2.0

Polkadot and Ethereum 2.0 share design elements, but differ in shard structure, validator selection, availability checks, and finality. The paper highlights trade-offs in security assumptions and participation.

A.3.1 ETH2.0

  • The paper notes extensive similarities in block production and finality-gadget design between Polkadot and Ethereum 2.0.It characterizes Ethereum 2.0 as promising partial proof-of-stake transition and sharding for speed and throughput.Source: §A.3.1 · p. 38
  • Polkadot parachains are independent heterogeneous blockchains, unlike Ethereum 2.0’s homogeneous smart-contract shards; the paper argues parachains can more easily support higher performance.Ink! is presented as a way to make smart-contract code easier to migrate into parachain code.Source: §A.3.1 · p. 38
  • Polkadot fixes a target validator count and uses NPoS to maximize backing stake, while Ethereum 2.0 requires validators to stake exactly 32 ETH.The paper argues this may make Ethereum 2.0 validators less independent, while acknowledging that the Gini coefficient initially favors Ethereum 2.0 and that NPoS may broaden participation by smaller DOT holders.Source: §A.3.1 · p. 38
  • Ethereum 2.0 has no exact availability-and-validity protocol analog; its shard committees verify randomly chosen code pieces, relying on an honest committee majority.Polkadot’s scheme instead relies on at least one honest validator among parachain validators or secondary checkers, allowing smaller parachain-validator committees.Source: §A.3.1 · p. 38
  • Both systems use proof-of-stake beacon or relay chains and finality gadgets, but the paper says GRANDPA has better liveness than Casper.Both gadgets combine eventual finality and Byzantine agreement.Source: §A.3.1 · p. 39

A.3.2 Sidechains

Sidechains are presented as an alternative scaling approach that can also support interoperability by bridging independent chains to a main chain.

A.3.2 Sidechains

  • Sidechains can scale blockchain technologies while enabling bridges between independent chains and a main chain.The passage describes tokens from one blockchain being considered valid and usable on another.Source: §A.3.2 · p. 39
  • Plasma Cash and Loom are cited as sidechains introduced for Eth1.0 that contributed to scalability.The passage names Cosmos as a prominent solution based solely on bridging independent chains to each other.Source: §A.3.2 · p. 39

A.3.3 Cosmos

Polkadot and Cosmos share an interoperability-oriented structure, but the paper distinguishes Polkadot’s unified state and shared security from Cosmos’s independent zones. It also contrasts their cross-chain trust and block-finalization behavior.

A.3.3 Cosmos

  • Cosmos Hub transfers messages among zones, resembling the Polkadot Relay Chain’s role in passing messages among parachains.The passage describes both systems as addressing interoperability and scalability for the decentralised web.Source: §A.3.3 · p. 39
  • Polkadot is a sharded state machine with zone-like chains reflected in unified state, whereas Cosmos does not unify zone state in its Hub.Cosmos therefore does not offer shared security among zones, and its overall security is equal to that of the least secure zone.Source: §A.3.3 · p. 39
  • Cosmos cross-chain messages require a receiving zone to trust the sender zone, while Polkadot’s security promise includes later retrieval and audit of validated parachain data.Cosmos users are expected to trust zone operators to preserve chain-state history.Source: §A.3.3 · p. 39
  • SPREE modules provide stronger security than shared security for specified XCMP messages by guaranteeing their processing through predefined module code.The passage says Cosmos offers no similar cross-zone trust framework.Source: §A.3.3 · p. 39
  • Polkadot’s parachains can temporarily fork alongside the relay chain, decoupling block production from finality and allowing multiple blocks to finalize at once.Cosmos zones depend on instant Hub-state finality for cross-chain operations, so delayed finalization halts those operations.Source: §A.3.3 · p. 39

B Glossary

The glossary defines Polkadot’s chain, consensus, validator, timing, and runtime vocabulary, including the roles and mechanisms used across its network.

B Glossary

  • BABE randomly assigns elected validators to block production for slots, each about five seconds, while an epoch of randomness lasts about four hours.An era is the period for deciding a new validator set and lasts about one day.Source: B Glossary · p. 40
  • Collators assist validators in block production, and a session is a period with a constant validator set whose membership changes only at session boundaries.DOT is Polkadot’s native token; a PJR aims to ensure validators represent as many nominator minorities as possible.Source: B Glossary · p. 40
  • GRANDPA finalizes blocks, and a GRANDPA round is an algorithm state that leads to block finalization.Fishermen monitor the network for misbehaviour, while gossiping broadcasts newly received messages to peers.Source: B Glossary · p. 40
  • NPoS is Polkadot’s nominated proof-of-stake system, in which nominated validators are elected to produce blocks; nominators stake and nominate validators.Validators are elected parties with a chance to be selected by BABE to produce a block.Source: B Glossary · p. 40
  • A parachain is an independent heterogeneous chain, and XCMP is the protocol parachains use to send messages to each other.The glossary also describes sidechains as allowing tokens from one blockchain to be considered valid and used on another.Source: B Glossary · pp. 39–41
  • A PoV lets a validator verify a block without its full state, and the STVF is a Runtime function that verifies the PoV.The Runtime is the Wasm blob containing state-transition functions and other required core operations.Source: B Glossary · p. 40
Loading 2005.13456v3…