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