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.