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.