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.