POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 19 have contributed ideas or the beginnings thereof, Marek [10] Ethan Buchman Jae Kwon. Cosmos: A network of Kotewicz and Aeron Buchanan deserve especial mention. distributed ledgers. https://github.com/cosmos/cosmos/blob/ And thanks to everyone else for their help along the way. master/WHITEPAPER.md, 2016. [11] Jae Kwon. Tendermint: Consensus without mining. http: All errors are my own. //tendermint.com/docs/tendermint.pdf, 2014. Portions of this work, including initial research into [12] Daniel Larimer. Bitshares. http://docs.bitshares.org/ bitshares/history.html, 2013. consensus algorithms, was funded in part by the British [13] Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Government under the Innovate UK programme. Song. The honey badger of bft protocols. Technical report, Cryptology ePrint Archive 2016/199, 2016. References [14] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash sys- tem. https://bitcoin.org/bitcoin.pdf, 2008. [1] The specs for libp2p and associated submodules. https:// [15] Diego Ongaro and John Ousterhout. In search of an un- github.com/libp2p/specs. derstandable consensus algorithm. In 2014 USENIX Annual [2] Webassembly. http://webassembly.org/, 2016. Technical Conference (USENIX ATC 14), pages 305–319, [3] Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, 2014. Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Ti- [16] Parity. Parity ethereum client. https://parity.io, 2016. mon, and Pieter Wuille. Enabling blockchain innovations with [17] Serguei Popov. The tangle. https://www.iotatoken.com/IOTA_ pegged sidechains. 2014. Whitepaper.pdf, 2016. [4] Krista Bennett, Christian Grothoff, Tzvetan Horozov, Ioana [18] Youcai Qian. Randao. https://github.com/randao/randao, Patrascu, and Tiberiu Stef. Gnunet-a truly anonymous net- 2015. workinginfrastructure. In In: Proc. Privacy Enhancing Tech- [19] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, nologies Workshop (PET. Citeseer, 2002. Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. [5] Richard Gendal Brown, James Carlyle, Ian Zerocash: Decentralized anonymous payments from bitcoin. Grigg, and Mike Hearn. Corda: An introduc- In 2014 IEEE Symposium on Security and Privacy, pages tion. https://static1.squarespace.com/static/ 459–474. IEEE, 2014. 55f73743e4b051cfcc0b02cf/t/57bda2fdebbd1acc9c0309b2/ [20] Paul Snow, Brian Deery, Jack Lu, David Johnston, and Peter 1472045822585/corda-introductory-whitepaper-final.pdf, Kirb. Factom: Business processes secured by immutable audit 2016. trails on the blockchain. https://raw.githubusercontent. [6] Vitalik Buterin. Ethereum: A next-generation smart contract com/FactomProject/FactomDocs/master/Factom_Whitepaper.pdf, and decentralized application platform. https://github.com/ 2014. ethereum/wiki/wiki/White-Paper, 2013. [21] Gavin Wood. Devp2p wire protocol. https://github.com/ [7] Vitalik Buterin. Ethereum 2.0 mauve paper. 2016. ethereum/wiki/wiki/libp2p-Whitepaper, 2014. [8] Nxt community. Whitepaper: Nxt. http://wiki.nxtcrypto. [22] Gavin Wood. Ethereum: a secure decentralised generalised org/wiki/Whitepaper:Nxt, 2013. transaction ledger. http://gavwood.com/paper.pdf, 2014. [9] Christopher Copeland and Hongxia Zhong. Tangaroa: a [23] Gavin Wood. Yellow paper committee. https://github.com/ byzantine fault tolerant raft. http://www.scs.stanford.edu/ gavofyork/curly-engine, 2016. 14au-cs244b/labs/projects/copeland_zhong.pdf, 2016. Appendix A. Functional Components Seen from a high-level, the Parity Polkadot Platform stack has a number of functional components and any develop- ment of it will require a substantial amount of research and development prior to it being completed. Somecomponentsaredependentonothersexisting, others are independent. Some are very important for the platform to function properly, others are nice-to-haves. Some are of indeterminate complexity and have not yet been deemed feasible, others are relatively straight-forward. Here we’ll try to list as many such components as possible along with where they would fit into our development roadmap. Networking subsystem: Thisisthemeansbywhichapeernetworkisformedandmaintained. Simplealterations of existing peer-to-peer networking libraries (devp2p most likely) will be sufficient for an initial system. However, additional research and development will be necessary to ensure that as the network grows, the network topology becomes increasingly structured allowing for optimal data logistics. For the final deployment, adaptations of libp2p, devp2p and GNUnet should be first considered. If requirements are not likely to be met then a new protocol should be considered. Consensus mechanism: Proof-of-authority consensus mechanism supporting rich validator statements and al- lowing multiple independent items to be agreed upon under a single series based upon subjective reception of the partial set of validator statements. The mechanism should allow the proof of misbehaviour for the dismissal of malicious validators but need not involve any staking mechanism. A substantial amount of research and prototyping will precede the development of this component. Proof-of-stake chain: Extending the consensus mechanism into proof-of-stake territory; this module includes staking tokens, managing entry and exit from the validator pool, a market mechanism for determining validator rewards, finalising the approval-voting nomination mechanism and managing bond-confiscation and dismissal. It includes a substantial amount of research and prototyping prior to final development. Parachain implementation: Afirstparachainimplementation,likelytobebasedheavilyonanexistingblockchain protocol such as Bitcoin or (more likely, since it provides for rich transactions) Ethereum. This will include an integration with the proof-of-stake chain, allowing the parachain to gain consensus without its own internal consensus mechanism. Transaction processing subsystem: An evolution of the parachain and relay-chain, this will allow for trans- actions to be sent, received and propagated. It includes the designs of transaction queuing and optimised transaction routing on the network layer. Transaction-routing subsystem: This introduces more specifics into the relay-chain’s behaviour. Initially, adding transactability into parachains will be needed. Following that, with two parachains hard-coded into the relay-chain, it will include the management of the ingress/egress queues. Eventually this will develop along