POLKADOT

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 DR. GAVIN WOOD FOUNDER, ETHEREUM&PARITY [email protected] Abstract. Present-day blockchain architectures all suffer from a number of issues not least practical means of extensi- bility and scalability. We believe this stems from tying two very important parts of the consensus architecture, namely canonicality and validity, too closely together. This paper introduces an architecture, the heterogeneous multi-chain, which fundamentally sets the two apart. In compartmentalising these two parts, and by keeping the overall functionality provided to an absolute minimum of security and transport, we introduce practical means of core extensibility in situ. Scalability is addressed through a divide-and-conquer approach to these two functions, scaling out of its bonded core through the incentivisation of untrusted public nodes. The heterogeneous nature of this architecture enables many highly divergent types of consensus systems interop- erating in a trustless, fully decentralised “federation”, allowing open and closed networks to have trust-free access to each other. We put forward a means of providing backwards compatibility with one or more pre-existing networks such as Ethereum [6,22]. We believe that such a system provides a useful base-level component in the overall search for a practically implementable system capable of achieving global-commerce levels of scalability and privacy. 1. Preface technological promise and grand talk, we have yet to see This is intended to be a technical “vision” summary significant real-world deployment of present technology. of one possible direction that may be taken in further de- Webelieve that this is down to five key failures of present veloping the blockchain paradigm together with some ra- technology stacks: tionale as to why this direction is sensible. It lays out in Scalability: How much resources are spent globally as much detail as is possible at this stage of development on processing, bandwidth and storage for the sys- a system which may give a concrete improvement on a temtoprocess a single transaction and how many number of aspects of blockchain technology. transactions can be reasonably processed under It is not intended to be a specification, formal or oth- peak conditions? erwise. It is not intended to be comprehensive nor to be a Isolatability: Can the divergent needs of multiple final design. It is not intended to cover non-core aspects parties and applications be addressed to a near- of the framework such as APIs, bindings, languages and optimal degree under the same framework? usage. This is notably experimental; where parameters Developability: How well do the tools work? Do are specified, they are likely to change. Mechanisms will the APIs address the developers’ needs? Are ed- be added, refined and removed in response to community ucational materials available? Are the right inte- ideas and critiques. Large portions of this paper will likely grations there? be revised as experimental evidence and prototyping gives Governance: Can the network remain flexible to us information about what will work and what not. evolve and adapt over time? Can decisions be This document includes a core description of the pro- made with sufficient inclusivity, legitimacy and tocol together with ideas for directions that may be taken transparency to provide effective leadership of a to improve various aspects. It is envisioned that the core decentralised system? description will be used as the starting point for an initial Applicability: Does the technology actually ad- series of proofs-of-concept. A final “version 1.0” would be dress a burning need on its own? Is other “mid- based around this refined protocol together with the ad- dleware” required in order to bridge the gap to ditional ideas that become proven and are determined to actual applications? be required for the project to reach its goals. In the present work, we aim to address the first two 1.1. History. issues: scalability and isolatability. That said, we believe • 09/10/2016: 0.1.0-proof1 the Polkadot framework can provide meaningful improve- • 20/10/2016: 0.1.0-proof2 ments in each of these classes of problems. • 01/11/2016: 0.1.0-proof3 Modern, efficient blockchain implementations such as • 10/11/2016: 0.1.0 the Parity Ethereum client [16] can process in excess of 3,000 transactions per second when running on perfor- 2. Introduction mant consumer hardware. However, current real-world blockchain networks are practically limited to around 30 Blockchains have demonstrated great promise of util- transactions per second. This limitation mainly origi- ity over several fields including “Internet of Things” nates from the fact that the current synchronous consen- (IoT), finance, governance, identity management, web- sus mechanisms require wide timing margins of safety on decentralisation and asset-tracking. However, despite the the expected processing time, which is exacerbated by the 1

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 2 desire to support slower implementations. This is due to the reader should be aware that certain mechanisms may the underlying consensus architecture: the state transi- be described (for example interoperation with other pub- tion mechanism, or the means by which parties collate lic networks) which are not directly relevant to Polkadot and execute transactions, has its logic fundamentally tied when deployed under non-public (“permissioned”) situa- into the consensus “canonicalisation” mechanism, or the tions. means by which parties agree upon one of a number of possible, valid, histories. This applies equally to both proof-of-work (PoW) sys- 2.2. Previous work. Decoupling the underlying consen- tems such as Bitcoin [14] and Ethereum [6,22] and proof- sus from the state-transition has been informally proposed of-stake (PoS) systems such as NXT [8] and Bitshares [12]: in private for at least two years—Max Kaye was a pro- all ultimately suffer from the same handicap. It is a simple ponent of such a strategy during the very early days of strategy that helped makeblockchainsasuccess. However, Ethereum. bytightlycouplingthesetwomechanismsintoasingleunit A more complex scalable solution known as Chain of the protocol, we also bundle together multiple different fibers, dating back to June 2014 and first published later actors and applications with different risk profiles, differ- 1 that year , made the case for a single relay-chain and mul- ent scalability requirements and different privacy needs. tiple homogeneous chains providing a transparent inter- One size does not fit all. Too often it is the case that in a chain execution mechanism. Decoherence was paid for desire for broad appeal, a network adopts a degree of con- through transaction latency—transactions requiring the servatism which results in a lowest-common-denominator coordination of disparate portions of the system would optimally serving few and ultimately leading to a failing take longer to process. Polkadot takes much of its ar- in the ability to innovate, perform and adapt, sometimes chitecture from that and the follow-up conversations with dramatically so. various people, though it differs greatly in much of its de- Some systems such as e.g. Factom [20] drop the state- sign and provisions. transition mechanism altogether. However, much of the While there are no systems comparable to Polkadot utility that we desire requires the ability to transition state actually in production, several systems of some relevance according to a shared state-machine. Dropping it solves have been proposed, though few in any substantial level of an alternative problem; it does not provide an alternative detail. These proposals can be broken down into systems solution. which drop or reduce the notion of a globally coherent It seems clear, therefore, that one reasonable direction state machine, those which attempt to provide a globally to explore as a route to a scalable decentralised compute coherent singleton machine through homogeneous shards platform is to decouple the consensus architecture from and those which target only heterogeneity. the state-transition mechanism. And, perhaps unsurpris- ingly, this is the strategy that Polkadot adopts as a solu- tion to scalability. 2.2.1. Systems without Global State. Factom [20] is a sys- 2.1. Protocol, Implementation and Network. Like temthatdemonstrates canonicality without the according Bitcoin and Ethereum, Polkadot refers at once to a net- validity, effectively allowing the chronicling of data. Be- work protocol and the (hitherto presupposed) primary cause of the avoidance of global state and the difficulties public network that runs this protocol. Polkadot is in- with scaling which this brings, it can be considered a scal- tended to be a free and open project, the protocol speci- able solution. However, as mentioned previously, the set fication being under a Creative Commons license and the of problems it solves is strictly and substantially smaller. code being placed under a FLOSS license. The project is Tangle [17] is a novel approach to consensus systems. developed in an open manner and accepts contributions Rather than arranging transactions into blocks and form- where ever they are useful. A system of RFCs, not unlike ing consensus over a strictly linked list to give a glob- the Python Improvement Process, will allow a means of ally canonical ordering of state-changes, it largely aban- publicly collaborating over protocol changes and upgrades. dons the idea of a heavily structured ordering and instead Our initial implementation of the Polkadot protocol pushes for a directed acyclic graph of dependent trans- will be known as the Parity Polkadot Platform and will actions with later items helping canonicalise earlier items include a full protocol implementation together with API through explicit referencing. For arbitrary state-changes, bindings. Like other Parity blockchain implementations, this dependency graph would quickly become intractable, 2 PPPis designed to be a general-purpose blockchain tech- however for the much simpler UTXO model this becomes nology stack, neither uniquely for a public network nor for quite reasonable. Because the system is only loosely co- private/consortium operation. The development of it thus herent and transactions are generally independent of each far has been funded by several parties including through other, a large amount of global parallelism becomes quite a grant from the British government. natural. Using the UTXO model does have the effect This paper nonetheless describes Polkadot under the of limiting Tangle to a purely value-transfer “currency” context of a public network. The functionality we envi- system rather than anything more general or extensible. sion in a public network is a superset of that required in Furthermore without the hard global coherency, interac- alternative (e.g. private and/or consortium) settings. Fur- tion with other systems—which tend to need an absolute thermore, in this context, the full scope of Polkadot can degree knowledge over the system state—becomes imprac- be more clearly described and discussed. This does mean tical. 1 https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2unspent transaction output, the model that Bitcoin uses whereby the state is effectively the set of address associated with some value; transactions collate such addresses and reform them into a new set of addresses whose sum total is equivalent

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 3 2.2.2. Heterogeneous Chain Systems. Side-chains [3] is a remains unseen as to how Casper will iterate in the future proposed addition to the Bitcoin protocol which would al- and what it will look like should it finally be deployed. low trustless interaction between the main Bitcoin chain While Casper and Polkadot both represent interest- and additional side-chains. There is no provision for any ing new protocols and, in some sense, augmentations of degree of ‘rich’ interaction between side-chains: the in- Ethereum, there are substantial differences between their teraction would be limited to allowing side-chains to be ultimate goals and paths to deployment. Casper is an custodians of each other’s assets, effecting—in the local EthereumFoundation-centeredprojectoriginallydesigned jargon—a two-way peg3. The end vision is for a frame- to be a PoS alteration to the protocol with no desire to work where the Bitcoin currency could be provided with create a fundamentally scalable blockchain. Crucially, it is additional, if peripheral, functionality through pegging it designed to be a hard-fork, rather than anything more ex- onto some other chains with more exotic state transition pansive and thus all Ethereum clients and users would be systems than the Bitcoin protocol allows. In this sense, required to upgrade or remain on a fork of uncertain adop- side-chains addresses extensibility rather than scalability. tion. As such, deployment is made substantially more dif- Indeed, there is fundamentally no provision for the va- ficult as is inherent in a decentralised project where tight lidity of side-chains; tokens from one chain (e.g. Bitcoin) coordination is necessary. held on behalf of a side-chain are secured only by the Polkadot differs in several ways; first and foremost, side-chain’s ability to incentivise miners to canonicalise Polkadot is designed to be a fully extensible and scalable valid transitions. The security of the Bitcoin network blockchain development, deployment and interaction test cannot easily be transitioned to work on behalf of other bed. It is built to be a largely future-proof harness able to blockchains. Furthermore, a protocol for ensuring Bitcoin assimilate new blockchain technology as it becomes avail- miners merge-mine (that is duplicate their canonicalisa- able without over-complicated decentralised coordination tion power onto that of the side-chain) and, more impor- or hard forks. We already envision several use cases such tantly, validate the side-chain’s transitions is outside the as encrypted consortium chains and high-frequency chains scope of this proposal. with very low block times that are unrealistic to do in Cosmos [10] is a proposed multi-chain system in the any future version of Ethereum currently envisioned. Fi- same vein as side-chains, swapping the Nakamoto PoW nally, the coupling between it and Ethereum is extremely consensus method for Jae Kwon’s Tendermint algorithm. loose; no action on the part of Ethereum is necessary to Essentially, it describes multiple chains (operating in enable trustless transaction forwarding between the two zones) each using individual instances of Tendermint, to- networks. gether with a means for trust-free communication via a In short, while Casper/Ethereum 2.0 and Polkadot master hub chain. This interchain communication is lim- share some fleeting similarities we believe their end goal ited to the transfer of digital assets (“specifically about to- is substantially different and that rather than competing, kens”) rather than arbitrary information, however such in- the two protocols are likely to ultimately co-exist under a terchain communication does have a return path for data, mutually beneficial relationship for the foreseeable future. e.g. to report to the sender on the status of the transfer. Validator sets for the zoned chains, and in particular the means of incentivising them, are, like side-chains, left 3. Summary as an unsolved problem. The general assumption is that each zoned chain will itself hold a token of value whose in- Polkadot is a scalable heterogeneous multi-chain. This flation is used to pay for validators. Still in the early stages means that unlike previous blockchain implementations of design, at present the proposal lacks comprehensive de- which have focused on providing a single chain of varying tails over the economic means of achieving the scalable degrees of generality over potential applications, Polka- certainty over global validity. However, the loose coher- dot itself is designed to provide no inherent applica- ence required between the zones and the hub will allow tion functionality at all. Rather, Polkadot provides the for additional flexibility over the parameters of the zoned bedrock “relay-chain” upon which a large number of val- chains compared to that of a system enforcing stronger idatable, globally-coherent dynamic data-structures may coherence. be hosted. We call these data-structures “parallelised” chains or parachains, though there is no specific need for them to be blockchain in nature. 2.2.3. Casper. As yet no comprehensive review or side- In other words, Polkadot may be considered equiva- by-side comparison between Casper [7] and Polkadot lent to a set of independent chains (e.g. the set containing have been made, though one can make a fairly sweeping Ethereum, Ethereum Classic, Namecoin and Bitcoin) ex- (and accordingly inaccurate) characterisation of the two. cept for two very important points: Casper is a reimagining of how a PoS consensus algorithm • Pooled security; could be based around participants betting on which fork • trust-free interchain transactability. would ultimately become canonical. Substantial consider- ation was given to ensuring that it be robust to network These points are why we consider Polkadot to be “scal- forks, even when prolonged, and have some additional de- able”. In principle, a problem to be deployed on Polka- gree of scalability on top of the basic Ethereum model. As dot may be substantially parallelised—scaled out—over such, Casper to date has tended to be a substantially more a large number of parachains. Since all aspects of each complex protocol than Polkadot and its forebears, and a parachain may be conducted in parallel by a different seg- substantial deviation from the basic blockchain format. It ment of the network, the system has some ability to scale. 3as opposed to a one-way peg which is essentially the action of destroying tokens in one chain to create tokens in another without the mechanism to do the converse in order to recover the original tokens

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 4 Polkadot provides a rather bare-bones piece of infrastruc- offloaded into middleware, placed through a ture leaving much of the complexity to be addressed at the parachain or introduced in a later optimisation. middleware level. This is a conscious decision intended to General: no unnecessary requirement, constraint reduce development risk, enabling the requisite software or limitation should be placed on parachains; to be developed within a short time span and with a good Polkadot should be a test bed for consensus sys- level of confidence over its security and robustness. temdevelopmentwhichcanbeoptimisedthrough making the model into which extensions fit as ab- stract as possible. 3.1. The Philosophy of Polkadot. Polkadot should Robust: Polkadot should provide a fundamentally provide an absolute rock-solid foundation on which to stable base-layer. In addition to economic sound- build the next wave of consensus systems, right through ness, this also means decentralising to minimise the risk spectrum from production-capable mature designs the vectors for high-reward attacks. to nascent ideas. By providing strong guarantees over se- curity, isolation and communication, Polkadot can allow 4. Participation in Polkadot parachains to select from a range of properties themselves. Indeed, we foresee various experimental blockchains push- There are four basic roles in the upkeep of an Polkadot ing the properties of what could be considered sensible network: collator, fisherman, nominator and validator. In today. one possible implementation of Polkadot, the latter role We see conservative, high-value chains similar to mayactually be broken down into two roles: basic valida- Bitcoin or Z-cash [19] co-existing alongside lower-value tor and availability guarantor; this is discussed in section “theme-chains” (such marketing, so fun) and test-nets 6.5.3. with zero or near-zero fees. We see fully-encrypted, “dark”, consortium chains operating alongside—and even Collator Fisherman Nominator providing services to—highly functional and open chains such as those like Ethereum. We see experimental new provides block VM-basedchains such as a subjective time-charged Wasm candidates reports chain being used as a means of outsourcing difficult com- for monitors bad approves pute problems from a more mature Ethereum-like chain behaviour to or a more restricted Bitcoin-like chain. To manage chain upgrades, Polkadot will inherently Validators Validators support some sort of governance structure, likely based (this group) becomes (other groups) on existing stable political systems and having a bicam- eral aspect similar to the Yellow Paper Council [23]. As theultimateauthority, theunderlyingstakabletokenhold- Figure 1. The interaction between the ers would have “referendum” control. To reflect the users’ four roles of Polkadot. need for development but the developers’ need for legiti- macy, we expect a reasonable direction would be to form 4.1. Validators. A validator is the highest charge and the two chambers from a “user” committee (made up of helps seal new blocks on the Polkadot network. The val- bonded validators) and a “technical” committee made up idator’s role is contingent upon a sufficiently high bond of major client developers and ecosystem players. The being deposited, though we allow other bonded parties to body of token holders would maintain the ultimate legit- nominate one or more validators to act for them and as imacy and form a supermajority to augment, reparam- such some portion of the validator’s bond may not neces- eterise, replace or dissolve this structure, something we sarily be owned by the validator itself but rather by these don’t doubt the eventual need for: nominators. In the words of Twain “Governments and diapers must Avalidator must run a relay-chain client implementa- be changed often, and for the same reason”. tion with high availability and bandwidth. At each block Whereas reparameterisation is typically trivial to ar- the node must be ready to accept the role of ratifying range within a larger consensus mechanism, more qualita- a new block on a nominated parachain. This process tive changes such as replacement and augmentation would involves receiving, validating and republishing candidate likely need to be either non-automated “soft-decrees” (e.g. blocks. The nomination is deterministic but virtually un- through the canonicalisation of a block number and the predictable much in advance. Since the validator cannot hash of a document formally specifying the new protocol) reasonably be expected to maintain a fully-synchronised or necessitate the core consensus mechanism to contain a database of all parachains, it is expected that the valida- sufficiently rich language to describe any aspect of itself tor will nominate the task of devising a suggested new which may need to change. The latter is an eventual aim, parachain block to a third-party, known as a collator. however, the former more likely to be chosen in order to Once all new parachain blocks have been properly rat- facilitate a reasonable development timeline. ified by their appointed validator subgroups, validators Polkadot’s primary tenets and the rules within which must then ratify the relay-chain block itself. This involves we evaluate all design decisions are: updating the state of the transaction queues (essentially Minimal: Polkadot should have as little functional- moving data from a parachain’s output queue to another ity as possible. parachain’s input queue), processing the transactions of Simple: noadditional complexity should be present the ratified relay-chain transaction set and ratifying the in the base protocol than can reasonably be final block, including the final parachain changes.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 5 A validator not fulfilling their duty to find consensus the existence of fishermen, we expect events of misbe- under the rules of our chosen consensus algorithm is pun- haviour to happen seldom, and when they do only due to ished. For initial, unintentional failures, this is through the bonded party being careless with secret key security, withholding the validator’s reward. Repeated failures re- rather than through malicious intent. The name comes sult in the reduction of their security bond (through burn- from the expected frequency of reward, the minimal re- ing). Provably malicious actions such as double-signing or quirements to take part and the eventual reward size. conspiring to provide an invalid block result in the loss of Fishermen get their reward through a timely proof that the entire bond (which is partially burnt but mostly given at least one bonded party acted illegally. Illegal actions to the informant and the honest actors). include signing two blocks each with the same ratified par- Insomesense,validatorsaresimilartotheminingpools ent or, in the case of parachains, helping ratify an invalid of current PoW blockchains. block. To prevent over-rewarding of the compromise and illicit use of a session’s secret key, the base reward for 4.2. Nominators. A nominator is a stake-holding party providing a single validator’s illegally signed message is who contributes to the security bond of a validator. They minimal. This reward increases asymptotically as more have no additional role except to place risk capital and as corroborating illegal signatures from other validators are such to signal that they trust a particular validator (or provided implying a genuine attack. The asymptote is set set thereof) to act responsibly in their maintenance of the at 66% following our base security assertion that at least network. They receive a pro-rata increase or reduction two-thirds of the validators act benevolently. in their deposit according to the bond’s growth to which Fishermen are somewhat similar to “full nodes” in they contribute. present-day blockchain systems that the resources needed Together with collators, next, nominators are in some are relatively small and the commitment of stable uptime sense similar to the miners of the present-day PoW net- and bandwidth is not necessary. Fishermen differ in so works. muchastheymustpostasmallbond. Thisbondprevents sybil attacks from wasting validators’ time and compute 4.3. Collators. Transactioncollators (collators for short) resources. It is immediately withdrawable, probably no are parties who assist validators in producing valid more than the equivalent of a few dollars and may lead parachain blocks. They maintain a “full-node” for a par- to reaping a hefty reward from spotting a misbehaving ticular parachain; meaning that they retain all necessary validator. information to be able to author new blocks and execute 5. Design Overview transactions in much the same way as miners do on cur- rent PoW blockchains. Under normal circumstances, they This section is intended to give a brief overview of the will collate and execute transactions to create an unsealed system as a whole. A more thorough exploration of the block, and provide it, together with a zero-knowledge system is given in the section following it. proof, to one or more validators presently responsible for 5.1. Consensus. On the relay-chain, Polkadot achieves proposing a parachain block. low-level consensus over a set of mutually agreed valid The precise nature of the relationship between colla- blocks through a modern asynchronous Byzantine fault- tors, nominators and validators will likely change over tolerant (BFT) algorithm. The algorithm will be inspired time. Initially, we expect collators to work very closely by the simple Tendermint [11] and the substantially more with validators, since there will be only a few (perhaps involved HoneyBadgerBFT [13]. The latter provides an only one) parachain(s) with little transaction volume. The efficient and fault-tolerant consensus over an arbitrarily initial client implementation will include RPCs to allow a defective network infrastructure, given a set of mostly be- parachaincollator node to unconditionally supply a (relay- nign authorities or validators. chain) validator node with a provably valid parachain Foraproof-of-authority (PoA)style network, this alone block. As the cost of maintaining a synced version of would be sufficient, however Polkadot is imagined to be all such parachains increases, we expect to see additional also deployable as a network in a fully open and public infrastructure in place which will help separate out the situation without any particular organisation or trusted duties to independent, economically-motivated, parties. authority required to maintain it. As such we need a Eventually, we expect to see collator pools who vie to means of determining a set of validators and incentivising collect the most transaction fees. Such collators may be- them to be honest. For this we utilise PoS based selection come contracted to serve particular validators over a pe- criteria. riod of time for an on-going share in the reward proceeds. Alternatively, “freelance” collators may simply create a 5.2. Proving the Stake. We assume that the network market offering valid parachain blocks in return for a com- will have some means of measuring how much “stake” petitive share of the reward payable immediately. Simi- any particular account has. For ease of comparison to larly, decentralised nominator pools would allow multiple pre-existing systems, we will call the unit of measurement bonded participants to coordinate and share the duty of a “tokens”. Unfortunately the term is less than ideal for a validator. This ability to pool ensures open participation number of reasons, not least that being simply a scalar leading to a more decentralised system. value associated with an account, there is no notion of individuality. 4.4. Fishermen. Unlike the other two active parties, Weimaginevalidators be elected, infrequently (at most fishermen are not directly related to the block-authoring once per day but perhaps as seldom as once per quarter), process. Rather they are independent “bounty hunters” through a Nominated Proof-of-Stake (NPoS) scheme. In- motivated by a large one-off reward. Precisely due to centivisation can happen through a pro-rata allocation of

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 6 Transaction (submitted by external actor) Propagated transactions Collator Block candidate submission Propagated block Fisherman Validator swarm 2nd order (each coloured by its Relay-chain Parachain community designated parachain) Account Inbound transaction Interchain transactions (managed by validators) Relay chain Outbound transaction Parachain Parachain Parachain queues and I/O bridge Virtual parachain (e.g. Ethereum) Figure 2. A summary schematic of the Polkadot system. This shows collators collecting and propa- gating user-transactions, as well as propagating block candidates to fishermen and validators. It also shows how an account can post a transaction which is carried out of its parachain, via the relay-chain and on into another parachain where it can be interpreted as a transaction to an account there. 4 funds coming from a token base expansion (up to 100% Long-range “nothing-at-stake” attacks are circum- per year, though more likely around 10%) together with vented through a simple “checkpoint” latch which pre- any transaction fees collected. While monetary base ex- vents a dangerous chain-reorganisation of more than a pansion typically leads to inflation, since all token owners particular chain-depth. To ensure newly-syncing clients would have a fair opportunity at participation, no token- are not able to be fooled onto the wrong chain, regular holder would need to suffer a reduction in value of their “hard forks” will occur (of at most the same period of the holdings over time provided they were happy to take a validators’ bond liquidation) that hard-code recent check- role in the consensus mechanism. A particular proportion point block hashes into clients. This plays well with a fur- of tokens would be targeted for the staking process; the ther footprint-reducing measure of “finite chain length” or effective token base expansion would be adjusted through periodic reseting of the genesis-block. a market-based mechanism to reach this target. Validators are bonded heavily by their stakes; exiting 5.3. Parachains and Collators. Each parachain gets validators’ bonds remain in place long after the valida- similar security affordances to the relay-chain: the tors’ duties cease (perhaps around 3 months). This long parachains’ headers are sealed within the relay-chain block bond-liquidation period allows future misbehaviour to be ensuring no reorganisation, or “double-spending”, is possi- punished up until the periodic checkpointing of the chain. ble following confirmation. This is a similar security guar- Misbehaviour results in punishment, such as reduction of antee to that offered by Bitcoin’s side-chains and merge- reward or, in cases which intentionally compromise the mining. Polkadot, however, also provides strong guaran- network’s integrity, the validator losing some or all of its tees that the parachains’ state transitions are valid. This stake to other validators, informants or the stakeholders happens through the set of validators being cryptograph- as a whole (through burning). For example, a validator ically randomly segmented into subsets; one subset per whoattemptstoratify both branches of a fork (sometimes parachain, the subsets potentially differing per block. This known as a “short-range” attack) may be identified and setup generally implies that parachains’ block times will punished in the latter way. be at least as long as that of the relay-chain. The specific means of determining the partitioning is outside the scope 4 Such an attack is where the adversary forges an entirely new chain of history from the genesis block onwards. Through controlling a relatively insignificant portion of stake at the offset, they are able to incrementally increase their portion of the stake relative to all other stakeholders as they are the only active participants in their alternative history. Since no intrinsic physical limitation exists on the creation of blocks (unlike PoW where quite real computational energy must be spent), they are able to craft a chain longer than the real chain in a relatively short timespan and potentially make it the longest and best, taking over the canonical state of the network.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 7 of this document but would likely be based either around Account sends post: Account receives post: a commit-reveal framework similar to the RanDAO [18] or entry placed in entry removed from use data combined from previous blocks of each parachain egress Merkle tree ingress Merkle tree under a cryptographically secure hash. for destination parachain Such subsets of validators are required to provide a parachain block candidate which is guaranteed valid (on Source: shares egress Destination: gets pain of bond confiscation). Validity revolves around two data with next block’s data from prior important points; firstly that it is intrinsically valid—that validators ingress block’s validators. all state transitions were executed faithfully and that all external data referenced (i.e. transactions) is valid for in- clusion. Secondly, that any data which is extrinsic to its proof-of-post stored in routed reference placed candidate, such as those external transactions, has suffi- parachain egress Merkle in destination parachain’s ciently high availability so that participants are able to tree ingress Merkle tree 5 download it and execute the block manually. Valida- tors may provide only a “null” block containing no ex- Figure 3. A basic schematic showing ternal “transactions” data, but may run the risk of get- the main parts of routing for posted ting a reduced reward if they do. They work alongside transactions (”posts”). a parachain gossip protocol with collators—individuals who collate transactions into blocks and provide a non- To ensure minimal implementation complexity, min- interactive, zero-knowledge proof that the block consti- imal risk and minimal straight-jacketing of future tutes a valid child of its parent (and taking any transaction parachain architectures, these interchain transactions are fees for their trouble). effectively indistinguishable from standard externally- It is left to parachain protocols to specify their own signed transactions. The transaction has an origin seg- means of spam-prevention: there is no fundamental no- ment, providing the ability to identify a parachain, and tion of “compute-resource metering” or “transaction fee” an address which may be of arbitrary size. Unlike com- imposed by the relay-chain. There is also no direct en- mon current systems such as Bitcoin and Ethereum, in- forcement on this by the relay-chain protocol (though it terchain transactions do not come with any kind of “pay- is unlikely that the stakeholders would choose to adopt ment” of fee associated; any such payment must be man- a parachain which didn’t provide a decent mechanism). aged through negotiation logic on the source and desti- This is an explicit nod to the possibility of chains unlike nation parachains. A system such as that proposed for Ethereum, e.g. a Bitcoin-like chain which has a much sim- Ethereum’s Serenity release [?] would be a simple means pler fee model or some other, yet-to-be-proposed spam- of managing such a cross-chain resource payment, though prevention model. we assume others may come to the fore in due course. Polkadot’s relay-chain itself will probably exist as an Interchain transactions are resolved using a simple Ethereum-likeaccountsandstatechain, possiblyanEVM- queuing mechanism based around a Merkle tree to ensure derivative. Since the relay-chain nodes will be required to fidelity. It is the task of the relay-chain maintainers to do substantial other processing, transaction throughput move transactions on the output queue of one parachain will be minimised partly through large transaction fees into the input queue of the destination parachain. The and, should our research models require, a block size limit. passedtransactionsgetreferencedontherelay-chain, how- ever are not relay-chain transactions themselves. To pre- vent a parachain from spamming another parachain with transactions, for a transaction to be sent, it is required that the destination’s input queue be not too large at the time of the end of the previous block. If the input queue is too large after block processing, then it is con- sidered “saturated” and no transactions may be routed to it within subsequent blocks until reduced back below the limit. These queues are administered on the relay-chain allowing parachains to determine each other’s saturation 5.4. Interchain Communication. The critical final in- status; this way a failed attempt to post a transaction gredient of Polkadot is interchain communication. Since to a stalled destination may be reported synchronously. parachains can have some sort of information channel be- (Though since no return path exists, if a secondary trans- tween them, we allow ourselves to consider Polkadot a action failed for that reason, it could not be reported back scalable multi-chain. In the case of Polkadot, the commu- to the original caller and some other means of recovery nication is as simple as can be: transactions executing in a would have to take place.) parachain are (according to the logic of that chain) able to 5.5. Polkadot and Ethereum. Due to Ethereum’s Tur- effect the dispatch of a transaction into a second parachain ing completeness, we expect there is ample opportu- or, potentially, the relay-chain. Like external transactions nity for Polkadot and Ethereum to be interoperable with on production blockchains, they are fully asynchronous each other, at least within some easily deducible secu- and there is no intrinsic ability for them to return any rity bounds. In short, we envision that transactions from kind of information back to its origin. Polkadot can be signed by validators and then fed into 5 Such a task might be shared between validators or could become the designate task of a set of heavily bonded validators known as availability guarantors.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 8 Ethereum where they can be interpreted and enacted by it need simply call into a special “break-out contract”. a transaction-forwarding contract. In the other direction, Thebreak-out contract would take any payment that may we foresee the usage of specially formatted logs coming be required and issue a logging instruction so that its ex- from a “break-out contract” to allow a swift verification istence may be proven through a Merkle proof and an as- that a particular message should be forwarded. sertion that the corresponding block’s header is valid and canonical. 5.5.1. Polkadot to Ethereum. Through the choice of a Of the latter two conditions, validity is perhaps the BFTconsensus mechanism with validators formed from a most straightforward to prove. In principle, the only re- set of stakeholders determined through an approval voting quirement is for each Polkadot node needing the proof mechanism, we are able to get a secure consensus with an (i.e. appointed validator nodes) to be running a fully syn- infrequently changing and modest number of validators. chronised instance of a standard Ethereum node. Unfor- In a system with a total of 144 validators, a block time of tunately, this is itself a rather heavy dependency. A more 4 seconds and a 900-block finality (allowing for malicious lightweight methodwouldbetouseasimpleproofthatthe behaviour such as double-votes to be reported, punished header was evaluated correctly through supplying only the and repaired), the validity of a block can reasonably be part of Ethereum’s state trie needed to properly execute considered proven through as little as 97 signatures (two- the transactions in the block and check that the logs (con- thirds of 144 plus one) and a following 60-minute verifica- tained in the block receipt) are valid. Such “SPV-like”6 tion period where no challenges are deposited. proofs may yet require a substantial amount of informa- Ethereum is able to host a “break-in contract” which tion; conveniently, they would typically not be needed at can maintain the 144 signatories and be controlled by all: a bond system inside Polkadot would allow bonded them. Since elliptic curve digital signature (ECDSA) re- third-parties to submit headers at the risk of losing their covery takes only 3,000 gas under the EVM, and since bond should some other third-parity (sometimes referred we would likely only want the validation to happen on a to as a “fisherman”) provide a proof that the header is in- super-majority of validators (rather than full unanimity), valid (specifically that the state root or receipt roots were the base cost of Ethereum confirming that an instruction impostors). was properly validated as coming from the Polkadot net- On a non-finalising PoW network like Ethereum, the work would be no more than 300,000 gas—a mere 6% of canonicality is impossible to proof conclusively. To ad- the total block gas limit at 5.5M. Increasing the num- dress this, applications that attempt to rely on any kind ber of validators (as would be necessary for dealing with of chain-dependent cause-effect wait for a number of “con- dozens of chains) inevitably increases this cost, however firmations”, or until the dependent transaction is at some it is broadly expected for Ethereum’s transaction band- particular depth within the chain. On Ethereum, this width to grow over time as the technology matures and depth varies from 1 block for the least valuable transac- infrastructure improves. Together with the fact that not tions with no known network issues to 1200 blocks as was all validators need to be involved (e.g. only the highest the case during the initial Frontier release for exchanges. staked validators may be called upon for such a task) the On the stable “Homestead” network, this figure sits at limits of this mechanism extend reasonably well. 120 blocks for most exchanges, and we would likely take Assuming a daily rotation of such validators (which is a similar parameter. fairly conservative—weekly or even monthly may be ac- So we can imagine our Polkadot-side Ethereum- ceptable), then the cost to the network of maintaining interface to have some simple functions: to be able to this Ethereum-forwarding bridge would be around 540,000 accept a new header from the Ethereum network and val- gas per day or, at present gas prices, $45 per year. A ba- idate the PoW, to be able to accept some proof that a sic transaction forwarded alone over the bridge would cost particular log was emitted by the Ethereum-side break- around $0.11; additional contract computation would cost out contract for a header of sufficient depth (and forward more, of course. By buffering and bundling transactions the corresponding message within Polkadot) and finally together, the break-in authorisation costs can easily be to be able to accept proofs that a previously accepted but shared, reducing the cost per transaction substantially; not-yet-enacted header contains an invalid receipt root. if 20 transactions were required before forwarding, then To actually get the Ethereum header data itself (and the cost for forwarding a basic transaction would fall to any SPV proofs or validity/canonicality refutations) into around $0.01. the Polkadot network, an incentivisation for forwarding In this model, Polkadot’s validator nodes would have data is needed. This could be as simple as a payment to do little other than sign messages. To get the trans- (funded from fees collected on the Ethereum side) paid actions actually routed onto the Ethereum network, we to anyone able to forward a useful block whose header is assume either validators themselves would also reside on valid. Validators would be called upon to retain informa- the Ethereum network or, more likely, that small bounties tion relating to the last few thousand blocks in order to be offered to the first actor who forwards the message on be able to manage forks, either through some protocol- to the network (the bounty could trivially be paid to the intrinsic means or through a contract maintained on the transaction originator). relay chain. 5.5.2. Ethereum to Polkadot. Getting transactions to be 5.6. Polkadot and Bitcoin. Bitcoin interoperation forwarded from Ethereum to Polkadot uses the simple no- presents an interesting challenge for Polkadot: a so-called tion of logs. When an Ethereum contract wishes to dis- “two-way peg” would be a useful piece of infrastructure patch a transaction to a particular parachain of Polkadot, to have on the side of both networks. However, due to 6 SPV refers to Simplified Payment Verification in Bitcoin and describes a method for clients to verify transactions while keeping only a copy of all blocks headers of the longest PoW chain.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 9 7 the limitations of Bitcoin, providing such a peg securely is what amount of stake in the system. There will be no- a non-trivial undertaking. Delivering a transaction from table differences, though: Bitcoin to Polkadot can in principle be done with a pro- • Contracts cannot be deployed through transac- cess similar to that for Ethereum; a “break-out address” tions; following from the desire to avoid applica- controlled in some way by the Polkadot validators could tion functionality on the relay-chain, it will not receive transferred tokens (and data sent alongside them). support public deployment of contracts. SPVproofs could be provided by incentivised oracles and, • Computeresourceusage(“gas”) is not accounted; together with a confirmation period, a bounty given for since the only functions available for public usage identifying non-canonical blocks implying the transaction will be fixed, the rationale behind gas accounting has been “double-spent”. Any tokens then owned in the no longer holds. As such, a flat fee will apply in “break-out address” would then, in principle, be con- all cases, allowing for more performance from any trolled by those same validators for later dispersal. dynamiccodeexecutionthatmayneedtobedone The problem however is how the deposits can be se- and a simpler transaction format. curely controlled from a rotating validator set. Unlike • Special functionality is supported for listed con- Ethereum which is able to make arbitrary decisions based tracts that allows for auto-execution and network- upon combinations of signatures, Bitcoin is substantially message outputs. more limited, with most clients accepting only multi- In the event that the relay-chain has a VM and it be signature transactions with a maximum of 3 parties. Ex- based around the EVM, it would have a number of mod- tending this to 36, or indeed thousands as might ulti- ifications to ensure maximal simplicity. It would likely mately be desired, is impossible under the current pro- have a number of built-in contracts (similar to those at tocol. One option is to alter the Bitcoin protocol to en- addresses 1-4 in Ethereum) to allow for platform-specific able such functionality, however so-called “hard forks” in duties to be managed including a consensus contract, a the Bitcoin world are difficult to arrange to say the least. validator contract and a parachain contract. One possibility is the use of threshold signatures, crypto- If not the EVM, then a Web-Assembly (Wasm) back- graphic schemes to allow a singly identifiable public key to end is the most likely alternative; in this case the overall be effectively controlled by multiple secret “parts”, some structure would be similar, but there would be no need or all of which must be utilised to create a valid signa- for the built-in contracts with Wasm being a viable target ture. Unfortunately, threshold signatures compatible with for general purpose languages rather than the immature Bitcoin’s ECDSA are computationally expensive to create and limited languages for the EVM. and of polynomial complexity. Other likely deviations from the present Ethereum pro- Since the ultimate security of the deposits rests with tocol are quite possible, for example a simplification of the a number of bonded validators, one other option is to transaction-receipt format allowing for the parallel execu- reduce the multi-signature key-holders to only a heavily tion of non-conflicting transactions within the same block, bonded subset of the total validators such that threshold as proposed for the Serenity series of changes. signatures being feasible (or, at worst, Bitcoin’s native It is possible, though unlikely, that a Serenity-like multi-signature is possible). This of course reduces the “pure” chain be deployed as the relay-chain, allowing for a total amount of bonds that could be deducted in repara- particular contract to manage things like the staking token tions should the validators behave illegally, however this balances rather than making that a fundamental part of is a graceful degradation, simply setting an upper limit of the chain’s protocol. At present, we feel it is unlikely this the amount of funds that can securely run between the will offer a sufficiently great protocol simplification to be two networks (or indeed, on the % losses should an attack worth the additional complexity and uncertainty involved from the validators succeed). in developing it. As such we believe it not unrealistic to place a reason- There are a number of small pieces of functionality re- ably secure Bitcoin interoperability “virtual parachain” quired for administrating the consensus mechanism, val- between the two networks, though nonetheless a substan- idator set, validation mechanism and parachains. These tial effort with an uncertain timeline and quite possibly could be implemented together under a monolithic proto- requiring the cooperation of the stakeholders within that col. However, for reasons of auguring modularity, we de- network. scribe these as “contracts” of the relay-chain. This should 6. Protocol in Depth be taken to mean that they are objects (in the sense of object-orientated programming) managed by the relay- The protocol can be roughly broken down into three chain’s consensus mechanism, but not necessarily that parts: the consensus mechanism, the parachain interface they are defined as programs in EVM-like opcodes, nor and interchain transaction routing. even that they be individually addressable through the account-system. 6.1. Relay-chain Operation. The relay-chain will likely be a chain broadly similar to Ethereum in that it 6.2. Staking Contract. Thiscontractmaintainstheval- is state-based with the state mapping address to account idator set. It manages: information, mainly balances and (to prevent replays) a • which accounts are currently validators; transaction counter. Placing accounts here fulfils one pur- • which are available to become validators at short pose: to provide accounting for which identity possess notice; 7 As a means of representing the amount a given holder is responsible for the overall security of the system, these stake accounts will inevitably encode some economic value. However, it should be understood that since there is no intention that such values be used in any way for the purpose of exchanging for real-world goods and services, it should be accordingly noted that the tokens not be likened to currency and as such the relay-chain retain its nihilistic philosophy regarding applications.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 10 • which accounts have placed stake nominating to Each session, nominators’ bonds are dispersed to be a validator; represented by one or more validators. The dispersal al- • properties of each including staking volume, ac- gorithm optimises for a set of validators of equivalent total ceptable payout-rates and addresses and short- bonds. Nominators’ bonds become under the effective re- term (session) identities. sponsibility of the validator and gain interest or suffer a It allows an account to register a desire to become a punishment-reduction accordingly. bonded validator (along with its requirements), to nom- inate to some identity, and for preexisting bonded val- 6.2.3. Bond Confiscation/Burning. Certain validator be- idators to register their desire to exit this status. It also haviour results in a punitive reduction of their bond. If includes the machinery itself for the validation and canon- the bond is reduced below the allowable minimum, the icalisation mechanism. session is prematurely ended and another started. A non- exhaustive list of punishable validator misbehaviour in- 6.2.1. Stake-token Liquidity. It is generally desirable to cludes: have as much of the total staking tokens as possible to be • Being part of a parachain group unable to provide staked within the network maintenance operations since consensus over the validity of a parachain block; this directly ties the network security to the overall “mar- • actively signing for the validity of an invalid ket capitalisation” of the staking token. This can easily parachain block; be incentivised through inflating the currency and hand- • inability to supply egress payloads previously ing out the proceeds to those who participate as valida- voted as available; tors. However, to do so presents a problem: if the token • inactivity during the consensus process; is locked in the Staking Contract under punishment of re- • validating relay-chain blocks on competing forks. duction, how can a substantial portion remain sufficiently liquid in order to allow price discovery? Some cases of misbehaviour threaten the network’s in- One answer to this is allowing a straight-forward de- tegrity (such as signing invalid parachain blocks and val- rivative contract, securing fungible tokens on an underly- idating multiple sides of a fork) and as such result in ef- ing staked token. This is difficult to arrange in a trust- fective exile through the total reduction of the bond. In free manner. Furthermore, these derivative tokens can- other, less serious cases (e.g. inactivity in the consensus not be treated equally for the same reason that differ- process) or cases where blame cannot be precisely allot- ent Eurozone government’s bonds are not fungible: there ted (being part of an ineffective group), a small portion is a chance of the underlying asset failing and becoming of the bond may instead be fined. In the latter case, this worthless. With Eurozone governments, there could be a works well with sub-group churn to ensure that malicious default. With validator-staked tokens, the validator may nodes suffer substantially more loss than the collaterally- act maliciously and be punished. damaged benevolent nodes. Keeping with our tenets, we elect for the simplest so- In some cases (e.g. multi-fork validation and invalid lution: not all tokens be staked. This would mean that sub-block signing) validators cannot themselves easily de- some proportion (perhaps 20%) of tokens will forcibly re- tect each others’ misbehaviour since constant verification main liquid. Though this is imperfect from a security per- of each parachain block would be too arduous a task. Here spective, it is unlikely to make a fundamental difference in it is necessary to enlist the support of parties external to the security of the network; 80% of the reparations possi- the validation process to verify and report such misbe- ble from bond-confiscations would still be able to be made haviour. The parties get a reward for reporting such ac- compared to the “perfect case” of 100% staking. tivity; their term, “fishermen” stems from the unlikeliness The ratio between staked and liquid tokens can be tar- of such a reward. geted fairly simply through a reverse auction mechanism. Since these cases are typically very serious, we envi- Essentially, token holders interested in being a validator sion that any rewards can easily be paid from the con- would each post an offer to the staking contract stating fiscated bond. In general we prefer to balance burning the minimum payout-rate that they would require to take (i.e. reduction to nothing) with reallocation, rather than part. At the beginning of each session (sessions would attempting wholesale reallocation. This has the effect of happen regularly, perhaps as often as once per hour) the increasing the overall value of the token, compensating the validator slots would be filled according to each would-be network in general to some degree rather than the specific validator’s stake and payout rate. One possible algorithm party involved in discovery. This is mainly as a safety for this would be to take those with the lowest offers who mechanism: the large amounts involved could lead to ex- represent a stake no higher than the total stake targeted treme and acute behaviour incentivisation were they all divided by the number of slots and no lower than a lower- bestowed on a single target. bound of half that amount. If the slots cannot be filled, In general, it is important that the reward is suffi- the lower bound could be repeatedly reduced by some fac- ciently large to make verification worthwhile for the net- tor in order to satisfy. work, yet not so large as to offset the costs of fronting a well-financed, well-orchestrated ”industrial-level” criminal 6.2.2. Nominating. It is possible to trustlessly nominate hacking attack on some unlucky validator to force misbe- ones staking tokens to an active validator, giving them haviour. the responsibility of validators duties. Nominating works In this way, the amount claimed should generally be no through an approval-voting system. Each would-be nomi- greater than the direct bond of the errant validator, lest a nator is able to post an instruction to the staking contract perverse incentive arise of misbehaving and reporting one- expressing one or more validator identities under whose self for the bounty. This can be combated either explicitly responsibility they are prepared to entrust their bond. through a minimum direct bond requirement for being a

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 11 validator or implicitly by educating nominators that val- consensus-system. The grace period would likely be of idators with little bonds deposited have no great incentive the order of months and is likely to be set out on a per- to behave well. chain basis in the parachain registry in order that different parachains can enjoy different grace periods according to 6.3. Parachain Registry. This is the component of the their need. system which records what each of the parachains are. It is a relatively simple database-like construct and holds 6.4. Sealing Relay Blocks. Sealing refers, in essence, both static and dynamic information on each chain. to the process of canonicalisation; that is, a basic data Static information includes the chain index (a simple transform which maps the original into something funda- integer), along with the validation protocol identity, a mentally singular and meaningful. Under a PoW chain, means of distinguishing between the different classes of sealing is effectively a synonym for mining. In our case, parachain so that the correct validation algorithm can be it involves the collection of signed statements from val- runbyvalidatorsconsignedtoputtingforwardavalidcan- idators over the validity, availability and canonicality of a didate. An initial proof-of-concept would focus on placing particular relay-chain block and the parachain blocks that the new validation algorithms into clients themselves, ef- it represents. fectively requiring a hard fork of the protocol each time an The mechanics of the underlying BFT consensus al- additional class of chain were added. Ultimately, though, gorithm is out of scope for the present work. We will it may be possible to specify the validation algorithm in instead describe it using a primitive which assumes a a way both rigorous and efficient enough that clients are consensus-creating state-machine. Ultimately we expect able to effectively work with new parachains without a to be inspired by a number of promising BFT consensus hard-fork. One possible avenue to this would be to specify algorithms in the core; Tangaora [9] (a BFT variant of the parachain validation algorithm in a well-established, Raft [15]), Tendermint [11] and HoneyBadgerBFT [13]. natively-compiled, platform-neutral language such as We- The algorithm will have to reach an agreement on mul- bAssembly [2]. Additional research is necessary to deter- tiple parachains in parallel, thus differing from the usual mine whether this is truly feasible, however if so, it could blockchain consensus mechanisms. We assume that once bring with it the tremendous advantage of banishing hard- consensus is reached, we are able to record the consensus forks for good. in an irrefutable proof which can be provided by any of Dynamic information includes aspects of the transac- the participants to it. We also assume that misbehaviour tion routing system that must have global agreement such within the protocol can be generally reduced to a small as the parachain’s ingress queue (described in a later sec- group containing misbehaving participants to minimise tion). the collateral damage when dealing out punishment.8 The registry is able to have parachains added only The proof, which takes the form of our signed state- through full referendum voting; this could be managed ments, is placed in the relay-chain block’s header together internally but would more likely be placed in an external with certain other fields not least the relay-chain’s state- referendum contract in order to facilitate re-usage under trie root and transaction-trie root. more general governance components. The parameters to The sealing process takes place under a single voting requirements (e.g. any quorum required, majority consensus-generating mechanism addressing both the required) for registration of additional chains and other, relay-chain’s block and the parachains’ blocks which make less formal system upgrades will be set out in a “master up part of the relay’s content: parachains are not sepa- constitution” but are likely to follow a fairly traditional rately “committed” by their sub-groups and then collated path, at least initially. The precise formulation is out of later. This results in a more complex process for the relay- scope for the present work, but e.g. a two thirds super- chain, but allows us to complete the entire system’s con- majority to pass with more than one third of total system sensus in a single stage, minimising latency and allowing stake voting positively may be a sensible starting point. for quite complex data-availability requirements which are Additional operations include the suspension and re- helpful for the routing process below. moval of parachains. Suspension would hopefully never The state of each participant’s consensus machine may happen, however it is designed to be a safeguard least be modelled as a simple (2-dimensional) table. Each par- there be some intractable problem in a parachain’s vali- ticipant (validator) has a set of information, in the form dation system. The most obvious instance where it might of signed-statements (“votes”) from other participants, re- be needed is a consensus-critical difference between im- garding each parachain block candidate as well the relay- plementations leading validators to be unable to agree on chain block candidate. The set of information is two pieces validity or blocks. Validators would be encouraged to use of data: multiple client implementations in order that they are able Availability: does this validator have egress to spot such a problem prior to bond confiscation. transaction-post information from this block so Since suspension is an emergency measure, it would be they are able to properly validate parachain can- under the auspices of the dynamic validator-voting rather didates on the following block? They may vote than a referendum. Re-instating would be possible both either 1(known) or 0 (not yet known). Once they from the validators or a referendum. vote 1, they are committed to voting similarly for The removal of parachains altogether would come only the rest of this process. Later votes that do not after a referendum and with which would be required a respect this are grounds for punishment. substantial grace period to allow an orderly transition to Validity: is the parachain block valid and is all either a standalone chain or to become part of some other externally-referenced data (e.g. transactions) 8 Existing PoS-based BFT consensus schemes such as Tendermint BFT and the original Slasher fulfill these assertions.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 12 available? This is only relevant for validators as- task of guaranteeing availability with the validators pro- signed to the parachain on which they are voting. viding a portion of their interest/income in payment. They may vote either 1 (valid), -1 (invalid) or 0 However, while this might buy some intermediate scal- (not yet known). Once they vote non-zero, they ability, it still doesn’t help the underlying problem; since are committed to voting this way for the rest of adding more chains will in general require additional val- the process. Later votes that do not respect this idators, the ongoing network resource consumption (par- are grounds for punishment. ticularly in terms of bandwidth) grows with the square of All validators must submit votes; votes may be resub- the chains, an untenable property in the long-term. mitted, qualified by the rules above. The progression of Ultimately, we are likely to keep bashing our heads consensusmaybemodelledasmultiplestandardBFTcon- against the fundamental limitation which states that for sensus algorithms over each parachain happening in par- a consensus network to be considered available safe, the allel. Since these are potentially thwarted by a relatively ongoing bandwidth requirements are of the order of total small minority of malicious actors being concentrated in validators times total input information. This is due to a single parachain group, the overall consensus exists to the inability of an untrusted network to properly distrib- establish a backstop, limiting the worst-case scenario from ute the task of data storage across many nodes, which sits deadlocktomerelyoneormorevoidparachainblocks(and apart from the eminently distributable task of processing. a round of punishment for those responsible). 6.5.1. Introducing Latency. One means of softening this The basic rules for validity of the individual blocks rule is to relax the notion of immediacy. By requir- (that allow the total set of validators as a whole to come to ing 33%+1 validators voting for availability only eventu- consensus on it becoming the unique parachain candidate ally, and not immediately, we can better utilise exponen- to be referenced from the canonical relay): tial data propagation and help even out peaks in data- • must have at least two thirds of its validators vot- interchange. A reasonable equality (though unproven) ing positively and none voting negatively; may be: • must have over one third validators voting posi- tively to the availability of egress queue informa- (1) latency = participants×chains tion. Under the current model, the size of the system scales If there is at least one positive and at least one nega- with the number of chains to ensure that processing is tive vote on validity, an exceptional condition is created distributed; since each chain will require at least one val- and the whole set of validators must vote to determine idator and we fix the availability attestation to a constant if there are malicious parties or if there is an accidental proportion of validators, then participants similarly grows fork. Aside from valid and invalid, a third kind of votes with the number of chains. We end up with: are allowed, equivalent to voting for both, meaning that the node has conflicting opinions. This could be due to the 2 node’s owner running multiple implementations which do (2) latency = size not agree, indicating a possible ambiguity in the protocol. Meaning that as the system grows, the bandwidth re- After all votes are counted from the full validator set, if quired and latency until availability is known across the the losing opinion has at least some small proportion (to network, which might also be characterised as the number be parameterised; at most half, perhaps significantly less) of blocks before finality, increases with its square. This is of the votes of the winning opinion, then it is assumed to a substantial growth factor and may turn out to be a no- be an accidental parachain fork and the parachain is au- table road blocker and force us into “non-flat” paradigms tomatically suspended from the consensus process. Oth- such as composing several “Polkadotes” into a hierarchy erwise, we assume it is a malicious act and punish the for multi-level routing of posts through a tree of relay- minority who were voting for the dissenting opinion. chains. The conclusion is a set of signatures demonstrating canonicality. The relay-chain block may then be sealed 6.5.2. Public Participation. One more possible direction and the process of sealing the next block begun. is to enlist public participation in the process through a micro-complaints system. Similar to the fishermen, there couldbeexternalpartiestopolicethevalidatorswhoclaim 6.5. Improvements for Sealing Relay Blocks. While availability. Their task is to find one who appears un- this sealing method gives strong guarantees over the sys- able to demonstrate such availability. In doing so they tem’s operation, it does not scale out particularly well can lodge a micro-complaint to other validators. PoW or since every parachain’s key information must have its a staked bond may be used to mitigate the sybil attack availability guaranteed by over one-third of all validators. which would render the system largely useless. This means that every validator’s responsibility footprint grows as more chains are added. 6.5.3. Availability Guarantors. A final route would be to Whiledataavailability within open consensus networks nominateasecondsetofbondedvalidatorsas“availability is essentially an unsolved problem, there are ways of miti- guarantors”. These would be bonded just as with the nor- gating the overhead placed on validator nodes. One simple mal validators, and may even be taken from the same set solution is to realise that while validators must shoulder (though if so, they would be chosen over a long-term pe- the responsibility for data availability, they need not actu- riod, at least per session). Unlike normal validators, they ally store, communicate or replicate the data themselves. would not switch between parachains but rather would Secondary data silos, possibly related to (or even the very form a single group to attest to the availability of all im- same) collators who compile this data, may manage the portant interchain data.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 13 This has the advantage of relaxing the equivalence be- execute the block within some limit (e.g. 50% of the to- tween participants and chains. Essentially, chains can tal time allowed between blocks). Another is that the grow (along with the original chain validator set), whereas block is definitely overweight—this would be if more than the participants, and specifically those taking part in data- two-thirds declare that they could not execute the block availability testament, can remain at the least sub-linear within said limit. One final possibility is a fairly equal and quite possibly constant. split of opinion between validators. In this case, we may choose to do some proportionate punishment. 6.5.4. Collator Preferences. One important aspect of this To ensure validators can predict when they may be system is to ensure that there is a healthy selection of proposing an overweight block, it may be sensible to re- collators creating the blocks in any given parachain. If a quire them to publish information on their own perfor- single collator dominated a parachain then some attacks mance for each block. Over a sufficient period of time, become more feasible since the likelihood of the lack of this should allow them to profile their processing speed availability of external data would be less obvious. relative to the peers that would be judging them. One option is to artificially weight parachain blocks in a pseudo-random mechanism in order to favour a wide va- 6.5.6. Collator Insurance. One issue remains for valida- riety of collators. In the first instance, we would require tors: unlike with PoW networks, to check a collator’s as part of the consensus mechanism that validators favour block for validity, they must actually execute the trans- parachain block candidates determined to be “heavier”. actions in it. Malicious collators can feed invalid or over- Similarly, we must incentivise validators to attempt to weight blocks to validators causing them grief (wasting suggest the weightiest block they can find—this could be their resources) and exacting a potentially substantial op- done through making a portion of their reward propor- portunity cost. tional to the weight of their candidate. To mitigate this, we propose a simple strategy on the To ensure that collators are given a reasonable fair part of validators. Firstly, parachain block candidates sent chance of their candidate being chosen as the winning to validators must be signed from a relay chain account candidate in consensus, we make the specific weight of a with funds; if they are not, then the validator should drop parachain block candidate determinate on a random func- it immediately. Secondly, such candidates should be or- tion connected with each collator. For example, taking dered in priority by a combination (e.g. multiplication) of the XOR distance measure between the collator’s address the amount of funds in the account up to some cap, the andsomecryptographically-secure pseudorandom number number of previous blocks that the collator has success- determined close to the point of the block being created fully proposed in the past (not to mention any previous (a notional “winning ticket”). This effectively gives each punishments), and the proximity factor to the winning collator (or, more specifically, each collator’s address) a ticket as discussed previously. The cap should be the same random chance of their candidate block “winning” over as the punitive damages paid to the validator in the case all others. of them sending an invalid block. To mitigate the sybil attack of a single collator “min- Todisincentivise collators from sending invalid or over- ing” an address close to the winning ticket and thus being weight block candidates to validators, any validator may a favourite each block, we would add some inertia to a col- place in the next block a transaction including the offend- lator’s address. This may be as simple as requiring them ing block alleging misbehaviour with the effect of transfer- to have a baseline amount of funds in the address. A more ring some or all of the funds in the misbehaving collator’s elegant approach would be to weight the proximity to the account to the aggrieved validator. This type of trans- winning ticket with the amount of funds parked at the action front-runs any others to ensure the collator cannot address in question. While modelling has yet to be done, remove the funds prior to the punishment. The amount of it is quite possible that this mechanism enables even very funds transferred as damages is a dynamic parameter yet small stakeholders to contribute as a collator. to be modelled but will likely be a proportion of the val- idator block reward to reflect the level of grief caused. To 6.5.5. Overweight Blocks. If a validator set is compro- prevent malicious validators arbitrarily confiscating colla- mised, they may create and propose a block which though tors’ funds, the collator may appeal the validator’s deci- valid, takes an inordinate amount of time to execute and sion with a jury of randomly chosen validators in return validate. This is a problem since a validator group could for placing a small deposit. If they find in the valida- reasonably form a block which takes a very long time to tor’s favour, the deposit is consumed by them. If not, the execute unless some particular piece of information is al- deposit is returned and the validator is fined (since the ready known allowing a short cut, e.g. factoring a large validator is in a much more vaulted position, the fine will prime. If a single collator knew that information, then likely be rather hefty). they would have a clear advantage in getting their own candidates accepted as long as the others were busy pro- 6.6. Interchain Transaction Routing. Interchain cessing the old block. We call these blocks overweight. transaction routing is one of the essential maintenance Protection against validators submitting and validat- tasks of the relay-chain and its validators. This is the ing these blocks largely falls under the same guise as for logic which governs how a posted transaction (often short- invalid blocks, though with an additional caveat: Since ened to simply “post”) gets from being a desired output the time taken to execute a block (and thus its status as from one source parachain to being a non-negotiable in- overweight) is subjective, the final outcome of a vote on put of another destination parachain without any trust misbehaviour will fall into essentially three camps. One requirements. possibility is that the block is definitely not overweight— We choose the wording above carefully; notably we in this case more than two-thirds declare that they could don’t require there to have been a transaction in the source

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 14 parachaintohaveexplicitlysanctionedthispost. Theonly ensure that each next-block destination subgroup’s mem- constraints we place upon our model is that parachains bers are informed of the egress from the present block. must provide, packaged as a part of their overall block Validators are incentivised only to form a consensus on a processing output, the posts which are the result of the (parachain) block, as such they care little about which col- block’s execution. lator’s block ultimately becomes canonical. In principle, a These posts are structured as several FIFO queues; the validator could form an allegiance with a collator and con- number of lists is known as the routing base and may be spire to reduce the chances of other collators’ blocks be- around 16. Notably, this number represents the quantity coming canonical, however this is both difficult to arrange of parachains we can support without having to resort to due to the random selection of validators for parachains multi-phase routing. Initially, Polkadot will support this and could be defended against with a reduction in fees kind of direct routing, however we will outline one possible payable for parachain blocks which hold up the consensus multi-phase routing process (“hyper-routing”) as a means process. of scaling out well past the initial set of parachains. We assume that all participants know the sub- 6.6.1. External Data Availability. Ensuring a parachain’s groupings for next two blocks n, n + 1. In summary, the external data is actually available is a perennial issue with routing system follows these stages: decentralised systems aiming to distribute workload across the network. At the heart of the issue is the availability • CollatorS: Contact members of Validators[n][S] problem which states that since it is neither possible to • CollatorS: FOR EACH subgroup s: ensure at make a non-interactive proof of availability nor any sort least 1 member of Validators[n][s] in contact of proof of non-availability, for a BFT system to properly • CollatorS: FOR EACH subgroup s: assume validate any transition whose correctness relies upon the egress[n−1][s][S] is available (all incoming post availability of some external data, the maximum number data to ‘S‘ from last block) of acceptably Byzantine nodes, plus one, of the system • CollatorS: Compose block candidate b for S: must attest to the data being available. (b.header,b.ext,b.proof,b.receipt,b.egress) For a system to scale out properly, like Polkadot, this • CollatorS: Send proof information invites a problem: if a constant proportion of validators proof[S] = (b.header,b.ext,b.proof,b.receipt) to must attest to the availability of the data, and assuming Validators[n][S] that validators will want to actually store the data be- • CollatorS: Ensure external transaction data b.ext fore asserting it is available, then how do we avoid the is made available to other collators and validators problem of the bandwidth/storage requirements increas- • CollatorS: FOR EACH subgroup s: ing with the system size (and therefore number of valida- Send egress information egress[n][S][s] = tors)? Onepossible answer would be to have a separate set (b.header,b.receipt,b.egress[s]) to the re- of validators (availability guarantors), whose order grows ceiving sub-group’s members of next block sublinearly with the size of Polkadot as a whole. This is Validators[n+1][s] described in 6.5.3. • ValidatorV: Pre-connect all same-set members We also have a secondary trick. As a group, colla- for next block: let N = Chain[n+1][V]; connect tors have an intrinsic incentive to ensure that all data is all validators v such that Chain[n +1][v] = N available for their chosen parachain since without it they • ValidatorV: Collate all data ingress for this are unable to author further blocks from which they can block: FOR EACH subgroup s: Retrieve collect transaction fees. Collators also form a group, mem- egress[n−1][s][Chain[n][V]], get from other val- bership of which is varied (due to the random nature of idators v such that Chain[n][v] = Chain[n][V]. parachain validator groups) non-trivial to enter and easy Possibly going via randomly selected other val- to prove. Recent collators (perhaps of the last few thou- idators for proof of attempt. sand blocks) are therefore allowed to issue challenges to • ValidatorV: Accept candidate proofs for this the availability of external data for a particular parachain block proof[Chain[n][V]]. Vote block validity block to validators for a small bond. • ValidatorV: Accept candidate egress data for Validators must contact those from the apparently of- next block: FOR EACH subgroup s, accept fending sub-group who testified and either acquire and re- egress[n][s][N]. Vote block egress availability; re- turn the data to the collator or escalate the matter by tes- publish among interested validators v such that tifying to the lack of availability (direct refusal to provide Chain[n+1][v] = Chain[n+1][V]. the data counts as a bond-confiscating offence, therefore • ValidatorV: UNTIL CONSENSUS the misbehaving validator will likely just drop the connec- tion) and contacting additional validators to run the same Where: egress[n][from][to] is the current egress queue test. In the latter case, the collator’s bond is returned. information for posts going from parachain ‘from‘, to Once a quorum of validators who can make such non- parachain ‘to‘ in block number ‘n‘. Collator is a col- S availability testimonials is reached, they are released, the lator for parachain S. Validators[n][s] is the set of val- misbehaving sub-group is punished, and the block re- idators for parachain s at block number n. Conversely, verted. Chain[n][v] is the parachain to which validator v is as- signed on block number n. block.egress[to] is the egress 6.6.2. Posts Routing. Each parachain header includes an queue of posts from some parachain block block whose egress-trie-root; this is the root of a trie containing the destination parachain is to. routing-base bins, each bin being a concatenated list Since collators collect (transaction) fees based upon of egress posts. Merkle proofs may be provided across their blocks becoming canonical they are incentivised to parachain validators to prove that a particular parachain’s

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 15 block had a particular egress queue for a particular desti- Routing itself is deterministic and simple. We begin by nation parachain. limiting the number of bins in the ingress/egress queues; At the beginning of processing a parachain block, each rather than being the total number of parachains, they other parachain’s egress queue bound for said block is are the routing-base (b) . This will be fixed as the number merged into our block’s ingress queue. We assume strong, of parachains changes, with the routing-exponent (e) in- 9 probably CSPR , sub-block ordering to achieve a deter- stead being raised. Under this model, our message volume e ministic operation that offers no favouritism between any grows with O(b ), with the pathways remaining constant parachainblockpairing. Collatorscalculatethenewqueue andthelatency(ornumberofblocksrequiredfordelivery) and drain the egress queues according to the parachain’s with O(e). logic. Our model of routing is a hypercube of e dimensions, The contents of the ingress queue is written explicitly with each side of the cube having b possible locations. into the parachain block. This has two main purposes: Each block, we route messages along a single axis. We firstly, it means that the parachain can be trustlessly syn- alternate the axis in a round-robin fashion, thus guaran- chronised in isolation from the other parachains. Secondly, teeing worst-case delivery time of e blocks. it simplifies the data logistics should the entire ingress As part of the parachain processing, foreign-bound queue not be able to be processed in a single block; val- messages found in the ingress queue are routed imme- idators and collators are able to process following blocks diately to the appropriate egress queue’s bin, given the without having to source the queue’s data specially. current block number (and thus routing dimension). This If the parachain’s ingress queue is above a threshold process necessitates additional data transfer for each hop amount at the end of block processing, then it is marked on the delivery route, however this is a problem itself saturated on the relay-chain and no further messages may which may be mitigated by using some alternative means be delivered to it until it is cleared. Merkle proofs are of data payload delivery and including only a reference, used to demonstrate fidelity of the collator’s operation in rather than the full payload of the post in the post-trie. the parachain block’s proof. An example of such a hyper-cube routing for a system with 4 parachains, b = 2 and e = 2 might be: Phase 0, on each message M: 6.6.3. Critique. One minor flaw relating to this basic • sub : if M ∈{2,3} then sendTo(2) else keep 0 dest mechanism is the post-bomb attack. This is where all • sub : if M ∈{2,3} then sendTo(3) else keep 1 dest parachains send the maximum amount of posts possible • sub : if M ∈{0,1} then sendTo(0) else keep 2 dest to a particular parachain. While this ties up the target’s • sub : if M ∈{0,1} then sendTo(1) else keep 3 dest ingress queue at once, no damage is done over and above Phase 1, on each message M: a standard transaction DoS attack. • sub : if M ∈{1,3} then sendTo(1) else keep Operatingnormally, withasetofwell-synchronisedand 0 dest • sub : if M ∈{0,2} then sendTo(0) else keep non-malicious collators and validators, for N parachains, 1 dest • sub : if M ∈{1,3} then sendTo(3) else keep N×Mtotalvalidators and L collators per parachain, we 2 dest • sub : if M ∈{0,2} then sendTo(2) else keep can break down the total data pathways per block to: 3 dest Validator: M−1+L+L: M−1fortheothervalidators The two dimensions here are easy to see as the first in the parachain set, L for each collator providing a can- two bits of the destination index; for the first block, the didate parachain block and a second L for each collator higher-order bit alone is used. The second block deals of the next block requiring the egress payloads of the pre- with the low-order bit. Once both happen (in arbitrary vious block. (The latter is actually more like worst-case order) then the post will be routed. operation since it is likely that collators will share such Maximising Serendipity. One alteration of the basic pro- 2 data.) posal would see a fixed total of c −c validators, with c−1 Collator: M+kN: M for a connection to each relevant validators in each sub-group. Each block, rather than parachain block validator, kN for seeding the egress pay- there being an unstructured repartitioning of validators loads to some subset of each parachain validator group for among parachains, instead for each parachain sub-group, the next block (and possibly some favoured collator(s)). each validator would be assigned to a unique and different As such, the data path ways per node grow linearly parachain sub-group on the following block. This would with the overall complexity of the system. While this is lead to the invariant that between any two blocks, for any reasonable, as the system scales into hundreds or thou- two pairings of parachain, there exists two validators who sands of parachains, some communication latency may be have swapped parachain responsibilities. While this can- absorbed in exchange for a lower complexity growth rate. not be used to gain absolute guarantees on availability In this case, a multi-phase routing algorithm may be used (a single validator will occasionally drop offline, even if in order to reduce the number of instantaneous pathways benevolent), it can nonetheless optimise the general case. at a cost of introducing storage buffers and latency. This approach is not without complications. The addi- Hyper-cube Routing. Hyper-cube routing is a mechanism tion of a parachain would also necessitate a reorganisation which can mostly be build as an extension to the basic of the validator set. Furthermore the number of valida- routing mechanism described above. Essentially, rather tors, being tied to the square of the number of parachains, than growing the node connectivity with the number of would start initially very small and eventually grow far parachains and sub-group nodes, we grow only with the too fast, becoming untenable after around 50 parachains. logarithm of parachains. Posts may transit between sev- Noneof these are fundamental problems. In the first case, eral parachains’ queues on their way to final delivery. reorganisation of validator sets is something that must be 9 cryptographically secure pseudo-random

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 16 done regularly anyway. Regarding the size of the validator enacted, balanced according to chain’s specification. (A set, when too small, multiple validators may be assigned sensible default might be to require all ingress posts be to the same parachain, applying an integer factor to the processed before external transactions be serviced, how- overall total of validators. A multi-phase routing mecha- ever this should be for the parachain’s logic to decide.) nism such as Hypercube Routing, discussed in 6.6.3 would Through this enactment, a series of egress posts will be alleviate the requirement for large number of validators created and it will be verified that these do indeed match when there is a large number of chains. the collator’s candidate. Finally, the properly populated header will be checked against the candidate’s header. 6.7. Parachain Validation. A validator’s main purpose With a fully validated candidate block, the validator is to testify, as a well-bonded actor, that a parachain’s can then vote for the hash of its header and send all requi- block is valid, including but not limited to any state tran- site validation information to the co-validators in its sub- sition, any external transactions included, the execution of group. any waiting posts in the ingress queue and the final state 6.7.1. Parachain Collators. Parachain collators are un- of the egress queue. The process itself is fairly simple. bonded operators who fulfill much of the task of miners Once the validator sealed the previous block they are free on the present-day blockchain networks. They are specific to begin working to provide a candidate parachain block to a particular parachain. In order to operate they must candidate for the next round of consensus. maintain both the relay-chain and the fully synchronised Initially, the validator finds a parachain block candi- parachain. date through a parachain collator (described next) or one The precise meaning of “fully synchronised” will de- of its co-validators. The parachain block candidate data pend on the class of parachain, though will always in- includes the block’s header, the previous block’s header, clude the present state of the parachain’s ingress queue. any external input data included (for Ethereum and Bit- In Ethereum’s case it also involves at least maintaining coin, such data would be referred to as transactions, how- a Merkle-tree database of the last few blocks, but might ever in principle they may include arbitrary data struc- also include various other data structures including Bloom tures for arbitrary purposes), egress queue data and inter- filters for account existence, familial information, logging nal data to prove state-transition validity (for Ethereum outputs and reverse lookup tables for block number. this would be the various state/storage trie nodes re- In addition to keeping the two chains synchronised, it quired to execute each transaction). Experimental evi- mustalso“fish”fortransactions by maintaining a transac- dence shows this full dataset for a recent Ethereum block tion queue and accepting properly validated transactions to be at the most a few hundred KiB. from the public network. With the queue and chain, it is Simultaneously, if not yet done, the validator will be able to create new candidate blocks for the validators cho- attempting to retrieve information pertaining to the pre- sen at each block (whose identity is known since the relay- vious block’s transition, initially from the previous block’s chain is synchronised) and submit them, together with the validators and later from all validators signing for the various ancillary information such as proof-of-validity, via availability of the data. the peer network. Oncethevalidator has received such a candidate block, For its trouble, it collects all fees relating to the trans- they then validate it locally. The validation process is con- actions it includes. Various economics float around this tained within the parachain class’s validator module, a arrangement. In a heavily competitive market where there consensus-sensitive software module that must be written is a surplus of collators, it is possible that the transaction for any implementation of Polkadot (though in principle fees be shared with the parachain validators to incentivise a library with a C ABI could enable a single library to the inclusion of a particular collator’s block. Similarly, be shared between implementations with the appropriate some collators may even raise the required fees that need reduction in safety coming from having only a single “ref- to be paid in order to make the block more attractive to erence” implementation). validators. In this case, a natural market should form The process takes the previous block’s header and ver- with transactions paying higher fees skipping the queue ifies its identity through the recently agreed relay-chain and having faster inclusion in the chain. block in which its hash should be recorded. Once the par- ent header’s validity is ascertained, the specific parachain 6.8. Networking. Networkingontraditionalblockchains class’s validation function may be called. This is a sin- like Ethereum and Bitcoin has rather simple requirements. gle function accepting a number of data fields (roughly All transactions and blocks are broadcast in a simple undi- those given previously) and returning a simple Boolean rected gossip. Synchronisation is more involved, especially proclaiming the validity of the block. with Ethereum but in reality this logic was contained in Most such validation functions will first check the the peer strategy rather than the protocol itself which re- header-fields which are able to be derived directly from solved around a few request and answer message types. the parent block (e.g. parent hash, number). Following While Ethereum made progress on current protocol of- this, they will populate any internal data structures as ferings with the devp2p protocol, which allowed for many necessary in order to process transactions and/or posts. subprotocols to be multiplexed over a single peer connec- For an Ethereum-like chain this amounts to populating a tion and thus have the same peer overlay support many trie database with the nodes that will be needed for the p2p protocols simultaneously, the Ethereum portion of full execution of transactions. Other chain types may have the protocol still remained relatively simple and the p2p other preparatory mechanisms. protocol as a while remains unfinished with important Once done, the ingress posts and external transac- functionality missing such as QoS support. Sadly, a de- tions (or whatever the external data represents) will be sire to create a more ubiquitous “web 3” protocol largely

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 17 failed, with the only projects using it being those explicitly To ensure an efficient transport mechanism, a “flat” funded from the Ethereum crowd-sale. overlay network—like Ethereum’s devp2p—where each The requirements for Polkadot are rather more sub- node does not (non-arbitrarily) differentiate fitness of its stantial. Rather then a wholly uniform network, Polkadot peers is unlikely to be suitable. A reasonably extensible has several types of participants each with different re- peer selection and discovery mechanism will likely need quirements over their peer makeup and several network to be included within the protocol as well as aggressive “avenues” whose participants will tend to converse about planning an lookahead to ensure the right sort of peers particular data. This means a substantially more struc- are “serendipitously” connected at the right time. tured network overlay—and a protocol supporting that— The precise strategy of peer make-up will be differ- will likely be necessary. Furthermore, extensibility to fa- ent for each class of participant: for a properly scaled-out cilitate future additions such as new kinds of “chain” may multi-chain, collators will either need to be continuously themselves require a novel overlay structure. reconnecting to the accordingly elected validators, or will While an in-depth discussion of how the networking need on-going agreements with a subset of the validators protocol may look is outside of the scope of this docu- to ensure they are not disconnected during the vast ma- ment, some requirements analysis is reasonable. We can jority of the time that they are useless for that valida- roughly break down our network participants into two sets tor. Collators will also naturally attempt to maintain one (relay-chain, parachains) each of three subsets. We can or more stable connections into the availability guarantor also state that each of the parachain participants are only set to ensure swift propagation of their consensus-sensitive interested in conversing between themselves as opposed to data. participants in other parachains: Availability guarantors will mostly aim to maintain a • Relay-chain participants: stable connection to each other and to validators (for con- • Validators: P, split into subsets P[s] for each sensus and the consensus-critical parachain data to which parachain they attest), as well as to some collators (for the parachain • Availability Guarantors: A (this may be repre- data) and some fishermen and full clients (for dispersing sented by Validators in the basic form of the pro- information). Validators will tend to look for other val- tocol) idators, especially those in the same sub-group and any • Relay-chain clients: M (note members of each collators that can supply them with parachain block can- parachain set will also tend to be members of M) didates. • Parachain participants: Fishermen, as well as general relay-chain and parachain • Parachain Collators: C[0], C[1], ... clients will generally aim to keep a connection open to a • Parachain Fishermen: F[0], F[1], ... validator or guarantor, but plenty of other nodes similar • Parachain clients: S[0], S[1], ... to themselves otherwise. Parachain light clients will simi- • Parachain light-clients: L[0], L[1], ... larly aim to be connected to a full client of the parachain, if not just other parachain light-clients. In general we name particular classes of communication will tend to take place between members of these sets: • P | A <-> P | A: The full set of valida- 6.8.1. The Problem of Peer Churn. In the basic proto- tors/guarantors must be well-connected to col proposal, each of these subsets constantly alter ran- achieve consensus. domly with each block as the validators assigned to verify • P[s] <-> C[s] | P[s]: Each validator as a mem- the parachain transitions are randomly elected. This can ber of a given parachain group will tend to gossip be a problem should disparate (non-peer) nodes need to with other such members as well as the collators pass data between each other. One must either rely on of that parachain to discover and share block can- a fairly-distributed and well-connected peer network to didates. ensure that the hop-distance (and therefore worst-case la- • A <-> P[s] | C | A: Each availability guarantor tency) only grows with the logarithm of the network size will need to collect consensus-sensitive cross-chain (a Kademlia-like protocol may help here), or one must data from the validators assigned to it; collators introduce longer block times to allow the necessary con- mayalsooptimisethechanceofconsensusontheir nection negotiation to take place to keep a peer-set that block by advertising it to availability guarantors. reflects the node’s current communication needs. Once they have it, the data will be disbursed to Neither of these are great solutions: long block times other such guarantor to facilitate consensus. being forced upon the network may render it useless for • P[s] <-> A | P[s']: Parachain validators will particular applications and chains. Even a perfectly fair needtocollect additional input data from the pre- and connected network will result in substantial wastage vious set of validators or the availability guaran- of bandwidth as it scales due to uninterested nodes having tors. to forward data useless to them. • F[s]<->P:Whenreporting,fishermenmayplace While both directions may form part of the solution, a claim with any participant. a reasonable optimisation to help minimise latency would • M <-> M | P | A: General relay-chain clients dis- be to restrict the volatility of these parachain validator burse data from validators and guarantors. sets, either reassigning the membership only between se- • S[s] <-> S[s] | P[s] | A: Parachain clients dis- ries of blocks (e.g. in groups of 15, which at a 4 second burse data from the validator/guarantors. block time would mean altering connections only once per • L[s] <-> L[s] | S[s]: Parachain light clients minute)orbyrotatingmembershipinanincrementalfash- disburse data from the full clients. ion, e.g. changing by one member at a time (e.g. if there

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 18 are 15 validators assigned to each parachain, then on av- higher degree of latency due to the mechanics of the un- erage it would be a full minute between completely unique derlying consensus method. Furthermore each parachain sets). By limiting the amount of peer churn, and ensur- brings with it the potential to grief validators with an ing that advantageous peer connections are made well in over-burdensome validation algorithm. advance through the partial predictability of parachain As such, there will be some “price” that validators sets, we can help ensure each node keep a permanently and/or the stake-holding community will extract for the serendipitous selection of peers. addition of a new parachain. This market for chains will 6.8.2. Path to an Effective Network Protocol. Likely the possibly see the addition of either: most effective and reasonable development effort will fo- • Chains that likely have zero net contribution pay- cus on utilising a pre-existing protocol rather than rolling ing (in terms of locking up or burning staking to- our own. Several peer-to-peer base protocols exist that kens) to be made a part (e.g. consortium chains, wemayuseoraugmentincludingEthereum’s own devp2p Doge-chains, app-specific chains); [21], IPFS’s libp2p [1] and GNU’s GNUnet [4]. A full re- • chains that deliver intrinsic value to the network view of these protocols and their relevance for building a through adding particular functionality difficult modular peer network supporting certain structural guar- to get elsewhere (e.g. confidentiality, internal scal- antees, dynamicpeersteeringandextensiblesub-protocols ability, service tie-ins). is well beyond the scope of this document but will be an Essentially, the community of stakeholders will need to important step in the implementation of Polkadot. be incentivized to add child chains—either financially or through the desire to add featureful chains to the relay. 7. Practicalities of the Protocol It is envisioned that new chains added will have a very 7.1. Interchain Transaction Payment. While a great short notice period for removal, allowing for new chains to amount of freedom and simplicity is gained through drop- be experimented with without any risk of compromising ping the need for a holistic computation resource account- the medium or long-term value proposition. ing framework like Ethereum’s gas, this does raise an im- 8. Conclusion portant question: without gas, how does one parachain avoid another parachain from forcing it to do computa- Wehave outlined a direction one may take to author a tion? While we can rely on transaction-post ingress queue scalable, heterogeneous multi-chain protocol with the po- buffers to prevent one chain from spamming another with tential to be backwards compatible to certain, pre-existing transaction data, there is no equivalent mechanism pro- blockchain networks. Under such a protocol, participants vided by the protocol to prevent the spamming of trans- work in enlightened self-interest to create an overall sys- action processing. tem which can be extended in an exceptionally free man- This is a problem left to the higher level. Since chains ner and without the typical cost for existing users that are free to attach arbitrary semantics on to the incoming comes from a standard blockchain design. We have given transaction-post data, we can ensure that computation a rough outline of the architecture it would take including must be paid-for before started. In a similar vein to the the nature of the participants, their economic incentives model espoused by Ethereum Serenity, we can imagine andtheprocessesunderwhichtheymustengage. Wehave a “break-in” contract within a parachain which allows a identified a basic design and discussed its strengths and validator to be guaranteed payment in exchange for the limitations; accordingly we have further directions which provision of a particular volume of processing resources. may ease those limitations and yield further ground to- These resources may be measured in something like gas, wards a fully scalable blockchain solution. but could also be some entirely novel model such as sub- jective time-to-execute or a Bitcoin-like flat-fee model. 8.1. Missing Material and Open Questions. Net- On its own this isn’t so useful since we cannot read- work forking is always a possibility from divergent im- ily assume that the off-chain caller has available to them plementations of the protocol. The recovery from such an whatever value mechanism is recognised by the break-in exceptional condition was not discussed. Given the net- contract. However, we can imagine a secondary “break- workwillnecessarily have a non-zero period of finalisation, out” contract in the source chain. The two contracts to- it should not be a large issue to recover from the relay- gether would form a bridge, recognising each other and chain forking, however will require careful integration into providing value-equivalence. (Staking-tokens, available to the consensus protocol. each, could be used to settle up the balance-of-payments.) Bond-confiscation and conversely reward provision has Calling into another such chain would mean proxying not been deeply explored. At present we assume rewards through this bridge, which would provide the means of are provided under a winner-takes-all basis: this may not negotiating the value transfer between chains in order to give the best incentivisation model for fishermen. A short- pay for the computation resources required on the desti- period commit-reveal process would allow many fishermen nation parachain. to claim the prize giving a fairer distribution of rewards, however the process could lead to additional latency in the 7.2. Additional Chains. While the addition of a discovery of misbehaviour. parachain is a relatively cheap operation, it is not free. More parachains means fewer validators per parachain 8.2. Acknowledgments. Many thanks to all of the and, eventually, a larger number of validators each with a proof-readers who have helped get this in to a vaguely reduced average bond. While the issue of a smaller coer- presentable shape. In particular, Peter Czaban, Ken cion cost for attacking a parachain is mitigated through Kappler, Robert Habermeier, Vitalik Buterin, Reto Trin- fishermen, the growing validator set essentially forces a kler and Jack Petersson. Thanks to all the people who

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 19 have contributed ideas or the beginnings thereof, Marek [10] Ethan Buchman Jae Kwon. Cosmos: A network of Kotewicz and Aeron Buchanan deserve especial mention. distributed ledgers. https://github.com/cosmos/cosmos/blob/ And thanks to everyone else for their help along the way. master/WHITEPAPER.md, 2016. [11] Jae Kwon. Tendermint: Consensus without mining. http: All errors are my own. //tendermint.com/docs/tendermint.pdf, 2014. Portions of this work, including initial research into [12] Daniel Larimer. Bitshares. http://docs.bitshares.org/ bitshares/history.html, 2013. consensus algorithms, was funded in part by the British [13] Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Government under the Innovate UK programme. Song. The honey badger of bft protocols. Technical report, Cryptology ePrint Archive 2016/199, 2016. References [14] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash sys- tem. https://bitcoin.org/bitcoin.pdf, 2008. [1] The specs for libp2p and associated submodules. https:// [15] Diego Ongaro and John Ousterhout. In search of an un- github.com/libp2p/specs. derstandable consensus algorithm. In 2014 USENIX Annual [2] Webassembly. http://webassembly.org/, 2016. Technical Conference (USENIX ATC 14), pages 305–319, [3] Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, 2014. Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Ti- [16] Parity. Parity ethereum client. https://parity.io, 2016. mon, and Pieter Wuille. Enabling blockchain innovations with [17] Serguei Popov. The tangle. https://www.iotatoken.com/IOTA_ pegged sidechains. 2014. Whitepaper.pdf, 2016. [4] Krista Bennett, Christian Grothoff, Tzvetan Horozov, Ioana [18] Youcai Qian. Randao. https://github.com/randao/randao, Patrascu, and Tiberiu Stef. Gnunet-a truly anonymous net- 2015. workinginfrastructure. In In: Proc. Privacy Enhancing Tech- [19] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, nologies Workshop (PET. Citeseer, 2002. Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. [5] Richard Gendal Brown, James Carlyle, Ian Zerocash: Decentralized anonymous payments from bitcoin. Grigg, and Mike Hearn. Corda: An introduc- In 2014 IEEE Symposium on Security and Privacy, pages tion. https://static1.squarespace.com/static/ 459–474. IEEE, 2014. 55f73743e4b051cfcc0b02cf/t/57bda2fdebbd1acc9c0309b2/ [20] Paul Snow, Brian Deery, Jack Lu, David Johnston, and Peter 1472045822585/corda-introductory-whitepaper-final.pdf, Kirb. Factom: Business processes secured by immutable audit 2016. trails on the blockchain. https://raw.githubusercontent. [6] Vitalik Buterin. Ethereum: A next-generation smart contract com/FactomProject/FactomDocs/master/Factom_Whitepaper.pdf, and decentralized application platform. https://github.com/ 2014. ethereum/wiki/wiki/White-Paper, 2013. [21] Gavin Wood. Devp2p wire protocol. https://github.com/ [7] Vitalik Buterin. Ethereum 2.0 mauve paper. 2016. ethereum/wiki/wiki/libp2p-Whitepaper, 2014. [8] Nxt community. Whitepaper: Nxt. http://wiki.nxtcrypto. [22] Gavin Wood. Ethereum: a secure decentralised generalised org/wiki/Whitepaper:Nxt, 2013. transaction ledger. http://gavwood.com/paper.pdf, 2014. [9] Christopher Copeland and Hongxia Zhong. Tangaroa: a [23] Gavin Wood. Yellow paper committee. https://github.com/ byzantine fault tolerant raft. http://www.scs.stanford.edu/ gavofyork/curly-engine, 2016. 14au-cs244b/labs/projects/copeland_zhong.pdf, 2016. Appendix A. Functional Components Seen from a high-level, the Parity Polkadot Platform stack has a number of functional components and any develop- ment of it will require a substantial amount of research and development prior to it being completed. Somecomponentsaredependentonothersexisting, others are independent. Some are very important for the platform to function properly, others are nice-to-haves. Some are of indeterminate complexity and have not yet been deemed feasible, others are relatively straight-forward. Here we’ll try to list as many such components as possible along with where they would fit into our development roadmap. Networking subsystem: Thisisthemeansbywhichapeernetworkisformedandmaintained. Simplealterations of existing peer-to-peer networking libraries (devp2p most likely) will be sufficient for an initial system. However, additional research and development will be necessary to ensure that as the network grows, the network topology becomes increasingly structured allowing for optimal data logistics. For the final deployment, adaptations of libp2p, devp2p and GNUnet should be first considered. If requirements are not likely to be met then a new protocol should be considered. Consensus mechanism: Proof-of-authority consensus mechanism supporting rich validator statements and al- lowing multiple independent items to be agreed upon under a single series based upon subjective reception of the partial set of validator statements. The mechanism should allow the proof of misbehaviour for the dismissal of malicious validators but need not involve any staking mechanism. A substantial amount of research and prototyping will precede the development of this component. Proof-of-stake chain: Extending the consensus mechanism into proof-of-stake territory; this module includes staking tokens, managing entry and exit from the validator pool, a market mechanism for determining validator rewards, finalising the approval-voting nomination mechanism and managing bond-confiscation and dismissal. It includes a substantial amount of research and prototyping prior to final development. Parachain implementation: Afirstparachainimplementation,likelytobebasedheavilyonanexistingblockchain protocol such as Bitcoin or (more likely, since it provides for rich transactions) Ethereum. This will include an integration with the proof-of-stake chain, allowing the parachain to gain consensus without its own internal consensus mechanism. Transaction processing subsystem: An evolution of the parachain and relay-chain, this will allow for trans- actions to be sent, received and propagated. It includes the designs of transaction queuing and optimised transaction routing on the network layer. Transaction-routing subsystem: This introduces more specifics into the relay-chain’s behaviour. Initially, adding transactability into parachains will be needed. Following that, with two parachains hard-coded into the relay-chain, it will include the management of the ingress/egress queues. Eventually this will develop along

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 20 with the network protocol into a means of directed transaction propagation, ensuring independent parachain collators are not overly exposed to transactions that are not of interest. Relay chain: This is the final stage of the relay-chain, allowing the dynamic addition, removal and emergency pausing of parachains, the reporting of bad behaviour and includes implementation of the “fisherman” function- ality. Independent collators: This is the delivery of an alternative chain-specific collator functionality. It includes proof creation (for collators), parachain misbehaviour detection (for fishermen) and the validation function (for validators). It also includes any additional networking required to allow the two to discover and communicate. Network dynamics modelling and research: Theoverall dynamics of this protocol should be researched thor- oughly. This can happen both through offline network modelling and through empirical evidence through simu- lated nodes. The latter is dependent on the relay-chain and will include the development of a structured logging protocol allowing nodes to submit detailed reports on their actions to a central hub for collation. Network intelligence: As a complex decentralised multi-party network, a network intelligence hub similar to http://ethstats.netisneededtomonitorthelife-signs of the network as a whole and flag potentially disruptive behaviour. Structured logging should be used to generate and visualise this data in real-time for maximum efficiency. It is dependent on the relay-chain being in a reasonably complete state. Information publication platform: This is a mechanism for publishing data relating to the blockchain, and effectively means a decentralised content-discovery network. Initially it can be handled by basic peer-to-peer lookups but for deployment will likely require a more structured and robust solution since availability will become a critical piece of information. IPFS integration may be the most sensible means of achieving these goals. Javascript interaction bindings: The main means of interacting with the network will likely follow the example of Ethereumandassuchhigh-qualityJavascriptbindingsarecritical to have. Our bindings will cover interactions with the relay-chain and the initial parachain and as such depends on them. Governance: Initially, this will be a meta-protocol on the relay-chain for managing exceptional events such as hard-forks, soft-forks and protocol reparameterisation. It will include a modern structure to help manage conflict and prevent live-lock. Ultimately, this may become a full meta-protocol layer able to enact changes normally reserved for hard-forks. Requires the relay chain. Interaction platform: A platform by which “typical” users are able to interact with the system, along with minimalfunctionalitytofacilitate commontaskssuchasenteringthebondprocess, voting, nomination, becoming a validator, fisherman or collator and staking token transfer. Depends upon having a functional relay-chain. Light clients: Light-client technology for both the relay-chain and any parachains developed. This will allow clients to be able to gain information regarding activity on the chains with a high degree of trust-freedom and without any substantial requirement of storage or bandwidth. Depends upon the relay-chain. Parachain UI: A multi-chain, multi-token wallet and identity management system. It requires light-client tech- nology and the interaction platform. This is not needed for any initial network deployment. On-chain Dapp services: There may be various services that will need to be deployed on any initial parachains such as registration hubs for APIs, names, natural-language specifications and code. This depends on the parachain but is not strictly needed for any initial network deployment. Application development tools: This includes various bits of software required to help developers. Examples include compilers, key management tools, data archivers and VM simulators. Many others exist. These will need to be developed as required. Technologies will be chosen partly to minimise the need for such tools. Many will not be strictly required. Ethereum-as-a-parachain: Trust-free bridge to Ethereum and back again, allowing posted transactions to be routed from parachains into Ethereum (and treated like any other transaction of external origin) and allow Ethereum contracts to be able to post transactions to parachains and the accounts therein. Initially, this will be modelled to ascertain feasibility and get any structural limitations based around the number of validators required by the consensus process, a component on which it is dependent. A proof-of-concept can be built following this and final development will be dependent on the relay-chain itself. Bitcoin-RPC compatibility layer: AsimpleRPCcompatibilitylayer for the relay-chain allowing infrastructure already built using that protocol to be interoperable with Polkadot and as such minimise effort for support. A stretch goal requiring the relay-chain. Web 2.0 bindings: Bindings into common Web 2.0 technology stacks to facilitate the usage of Polkadot infras- tructure with legacy systems. A stretch goal dependent on the initial parachains and any on-chain infrastructure to be exposed. zk-SNARK parachain example: Aparachainutilisingthepropertiesofzk-SNARKsinordertoensureidentities of transactors on it are kept private. A stretch goal dependent on the relay-chain. Encrypted parachain example: A parachain that keeps each item of state encrypted and signed. These ensure the enforcement of access controls over inspection and modification of the data therein allowing commercial regulated operations to conform as necessary. Would include proof-of-authority mechanisms to allow Polkadot validators to guarantee some degree of correctness of state transitions without gaining exposure to the underlying information. A stretch goal depending on the relay-chain. Trust-free Bitcoin bridge: Trust-free Bitcoin “two-way-peg” functionality. This would possibly use threshold signatures or alternatively an n of m multi-signature Bitcoin account together with SPV proofs & specialised

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 21 fishermen. Development is predicated on an initial feasibility analysis giving a favourable result. Some additional functionality may need to be added to (or unlocked from) the Bitcoin protocol to support this functionality. Abstract/low-level decentralised applications: Trust-freetokenexchange,asset-trackinginfrastructure, crowd- sale infrastructure. Contract language: Certainly not an integral part of the project, but a nice stretch-goal nonetheless. Would include a safe contract language together with tutorials, guidelines and educational tools. It may include means of making formal proofs as per the original Solidity language vision or could be based around some other programmingparadigmwhichhelpsminimisecriticalprocesserrorssuchasfunctionalprogrammingorcondition- orientated programming. IDE: Based on the contract language, this would facilitate editing, collaboration, publication and debugging of contracts on the parachains. A far stretch goal. Appendix B. Frequently Asked Questions Is Polkadot designed to replace (insert blockchain here): No. The goal of Polkadot is to provide a frame- work under which new blockchains may be created and to which existing blockchains can, if their communities desire, be transitioned. Is Polkadot designed to replace (insert crypto-currency here): No. Polkadot tokens are neither intended nor designed to be used as a currency. They would make a bad currency: most will remain illiquid in the staking system and those that are liquid will face substantial fees for transfer of ownership. Rather, the purpose of Polkadot tokens is to be a direct representation of stake in the Polkadot network. What is the inflation rate for Polkadot staking tokens: The Polkadot staking token base expansion is un- limited. It rises and lowers according to market effects in order to target a particular proportion of tokens held under long-term bond in the validation process. Whydoes staking token ownership reflect stakeholding: Thisisamechanismrealisedbythefactthatthey underpin the network’s security. As such their value is tied to the overall economic value that Polkadot provides. Any actors who gain overall value from Polkadot operating correctly are incentivised to ensure it continues to do so. The best means of doing so is to take part in the validation process. This generally implies ownership of staking tokens.