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