POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 7 of this document but would likely be based either around Account sends post: Account receives post: a commit-reveal framework similar to the RanDAO [18] or entry placed in entry removed from use data combined from previous blocks of each parachain egress Merkle tree ingress Merkle tree under a cryptographically secure hash. for destination parachain Such subsets of validators are required to provide a parachain block candidate which is guaranteed valid (on Source: shares egress Destination: gets pain of bond confiscation). Validity revolves around two data with next block’s data from prior important points; firstly that it is intrinsically valid—that validators ingress block’s validators. all state transitions were executed faithfully and that all external data referenced (i.e. transactions) is valid for in- clusion. Secondly, that any data which is extrinsic to its proof-of-post stored in routed reference placed candidate, such as those external transactions, has suffi- parachain egress Merkle in destination parachain’s ciently high availability so that participants are able to tree ingress Merkle tree 5 download it and execute the block manually. Valida- tors may provide only a “null” block containing no ex- Figure 3. A basic schematic showing ternal “transactions” data, but may run the risk of get- the main parts of routing for posted ting a reduced reward if they do. They work alongside transactions (”posts”). a parachain gossip protocol with collators—individuals who collate transactions into blocks and provide a non- To ensure minimal implementation complexity, min- interactive, zero-knowledge proof that the block consti- imal risk and minimal straight-jacketing of future tutes a valid child of its parent (and taking any transaction parachain architectures, these interchain transactions are fees for their trouble). effectively indistinguishable from standard externally- It is left to parachain protocols to specify their own signed transactions. The transaction has an origin seg- means of spam-prevention: there is no fundamental no- ment, providing the ability to identify a parachain, and tion of “compute-resource metering” or “transaction fee” an address which may be of arbitrary size. Unlike com- imposed by the relay-chain. There is also no direct en- mon current systems such as Bitcoin and Ethereum, in- forcement on this by the relay-chain protocol (though it terchain transactions do not come with any kind of “pay- is unlikely that the stakeholders would choose to adopt ment” of fee associated; any such payment must be man- a parachain which didn’t provide a decent mechanism). aged through negotiation logic on the source and desti- This is an explicit nod to the possibility of chains unlike nation parachains. A system such as that proposed for Ethereum, e.g. a Bitcoin-like chain which has a much sim- Ethereum’s Serenity release [?] would be a simple means pler fee model or some other, yet-to-be-proposed spam- of managing such a cross-chain resource payment, though prevention model. we assume others may come to the fore in due course. Polkadot’s relay-chain itself will probably exist as an Interchain transactions are resolved using a simple Ethereum-likeaccountsandstatechain, possiblyanEVM- queuing mechanism based around a Merkle tree to ensure derivative. Since the relay-chain nodes will be required to fidelity. It is the task of the relay-chain maintainers to do substantial other processing, transaction throughput move transactions on the output queue of one parachain will be minimised partly through large transaction fees into the input queue of the destination parachain. The and, should our research models require, a block size limit. passedtransactionsgetreferencedontherelay-chain, how- ever are not relay-chain transactions themselves. To pre- vent a parachain from spamming another parachain with transactions, for a transaction to be sent, it is required that the destination’s input queue be not too large at the time of the end of the previous block. If the input queue is too large after block processing, then it is con- sidered “saturated” and no transactions may be routed to it within subsequent blocks until reduced back below the limit. These queues are administered on the relay-chain allowing parachains to determine each other’s saturation 5.4. Interchain Communication. The critical final in- status; this way a failed attempt to post a transaction gredient of Polkadot is interchain communication. Since to a stalled destination may be reported synchronously. parachains can have some sort of information channel be- (Though since no return path exists, if a secondary trans- tween them, we allow ourselves to consider Polkadot a action failed for that reason, it could not be reported back scalable multi-chain. In the case of Polkadot, the commu- to the original caller and some other means of recovery nication is as simple as can be: transactions executing in a would have to take place.) parachain are (according to the logic of that chain) able to 5.5. Polkadot and Ethereum. Due to Ethereum’s Tur- effect the dispatch of a transaction into a second parachain ing completeness, we expect there is ample opportu- or, potentially, the relay-chain. Like external transactions nity for Polkadot and Ethereum to be interoperable with on production blockchains, they are fully asynchronous each other, at least within some easily deducible secu- and there is no intrinsic ability for them to return any rity bounds. In short, we envision that transactions from kind of information back to its origin. Polkadot can be signed by validators and then fed into 5 Such a task might be shared between validators or could become the designate task of a set of heavily bonded validators known as availability guarantors.