POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 20 with the network protocol into a means of directed transaction propagation, ensuring independent parachain collators are not overly exposed to transactions that are not of interest. Relay chain: This is the final stage of the relay-chain, allowing the dynamic addition, removal and emergency pausing of parachains, the reporting of bad behaviour and includes implementation of the “fisherman” function- ality. Independent collators: This is the delivery of an alternative chain-specific collator functionality. It includes proof creation (for collators), parachain misbehaviour detection (for fishermen) and the validation function (for validators). It also includes any additional networking required to allow the two to discover and communicate. Network dynamics modelling and research: Theoverall dynamics of this protocol should be researched thor- oughly. This can happen both through offline network modelling and through empirical evidence through simu- lated nodes. The latter is dependent on the relay-chain and will include the development of a structured logging protocol allowing nodes to submit detailed reports on their actions to a central hub for collation. Network intelligence: As a complex decentralised multi-party network, a network intelligence hub similar to http://ethstats.netisneededtomonitorthelife-signs of the network as a whole and flag potentially disruptive behaviour. Structured logging should be used to generate and visualise this data in real-time for maximum efficiency. It is dependent on the relay-chain being in a reasonably complete state. Information publication platform: This is a mechanism for publishing data relating to the blockchain, and effectively means a decentralised content-discovery network. Initially it can be handled by basic peer-to-peer lookups but for deployment will likely require a more structured and robust solution since availability will become a critical piece of information. IPFS integration may be the most sensible means of achieving these goals. Javascript interaction bindings: The main means of interacting with the network will likely follow the example of Ethereumandassuchhigh-qualityJavascriptbindingsarecritical to have. Our bindings will cover interactions with the relay-chain and the initial parachain and as such depends on them. Governance: Initially, this will be a meta-protocol on the relay-chain for managing exceptional events such as hard-forks, soft-forks and protocol reparameterisation. It will include a modern structure to help manage conflict and prevent live-lock. Ultimately, this may become a full meta-protocol layer able to enact changes normally reserved for hard-forks. Requires the relay chain. Interaction platform: A platform by which “typical” users are able to interact with the system, along with minimalfunctionalitytofacilitate commontaskssuchasenteringthebondprocess, voting, nomination, becoming a validator, fisherman or collator and staking token transfer. Depends upon having a functional relay-chain. Light clients: Light-client technology for both the relay-chain and any parachains developed. This will allow clients to be able to gain information regarding activity on the chains with a high degree of trust-freedom and without any substantial requirement of storage or bandwidth. Depends upon the relay-chain. Parachain UI: A multi-chain, multi-token wallet and identity management system. It requires light-client tech- nology and the interaction platform. This is not needed for any initial network deployment. On-chain Dapp services: There may be various services that will need to be deployed on any initial parachains such as registration hubs for APIs, names, natural-language specifications and code. This depends on the parachain but is not strictly needed for any initial network deployment. Application development tools: This includes various bits of software required to help developers. Examples include compilers, key management tools, data archivers and VM simulators. Many others exist. These will need to be developed as required. Technologies will be chosen partly to minimise the need for such tools. Many will not be strictly required. Ethereum-as-a-parachain: Trust-free bridge to Ethereum and back again, allowing posted transactions to be routed from parachains into Ethereum (and treated like any other transaction of external origin) and allow Ethereum contracts to be able to post transactions to parachains and the accounts therein. Initially, this will be modelled to ascertain feasibility and get any structural limitations based around the number of validators required by the consensus process, a component on which it is dependent. A proof-of-concept can be built following this and final development will be dependent on the relay-chain itself. Bitcoin-RPC compatibility layer: AsimpleRPCcompatibilitylayer for the relay-chain allowing infrastructure already built using that protocol to be interoperable with Polkadot and as such minimise effort for support. A stretch goal requiring the relay-chain. Web 2.0 bindings: Bindings into common Web 2.0 technology stacks to facilitate the usage of Polkadot infras- tructure with legacy systems. A stretch goal dependent on the initial parachains and any on-chain infrastructure to be exposed. zk-SNARK parachain example: Aparachainutilisingthepropertiesofzk-SNARKsinordertoensureidentities of transactors on it are kept private. A stretch goal dependent on the relay-chain. Encrypted parachain example: A parachain that keeps each item of state encrypted and signed. These ensure the enforcement of access controls over inspection and modification of the data therein allowing commercial regulated operations to conform as necessary. Would include proof-of-authority mechanisms to allow Polkadot validators to guarantee some degree of correctness of state transitions without gaining exposure to the underlying information. A stretch goal depending on the relay-chain. Trust-free Bitcoin bridge: Trust-free Bitcoin “two-way-peg” functionality. This would possibly use threshold signatures or alternatively an n of m multi-signature Bitcoin account together with SPV proofs & specialised