Polkadot: Vision for a Heterogeneous Multi-Chain Framework Draft 1
Total Page:16
File Type:pdf, Size:1020Kb
POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 DR. GAVIN WOOD FOUNDER, ETHEREUM & PARITY [email protected] Abstract. Present-day blockchain architectures all suffer from a number of issues not least practical means of extensi- bility and scalability. We believe this stems from tying two very important parts of the consensus architecture, namely canonicality and validity, too closely together. This paper introduces an architecture, the heterogeneous multi-chain, which fundamentally sets the two apart. In compartmentalising these two parts, and by keeping the overall functionality provided to an absolute minimum of security and transport, we introduce practical means of core extensibility in situ. Scalability is addressed through a divide-and-conquer approach to these two functions, scaling out of its bonded core through the incentivisation of untrusted public nodes. The heterogeneous nature of this architecture enables many highly divergent types of consensus systems interop- erating in a trustless, fully decentralised \federation", allowing open and closed networks to have trust-free access to each other. We put forward a means of providing backwards compatibility with one or more pre-existing networks such as Ethereum. We believe that such a system provides a useful base-level component in the overall search for a practically implementable system capable of achieving global-commerce levels of scalability and privacy. 1. Preface technological promise and grand talk, we have yet to see significant real-world deployment of present technology. This is intended to be a technical \vision" summary We believe that this is down to five key failures of present of one possible direction that may be taken in further de- technology stacks: veloping the blockchain paradigm together with some ra- tionale as to why this direction is sensible. It lays out in Scalability: How much resources are spent globally as much detail as is possible at this stage of development on processing, bandwidth and storage for the sys- a system which may give a concrete improvement on a tem to process a single transaction and how many number of aspects of blockchain technology. transactions can be reasonably processed under It is not intended to be a specification, formal or oth- peak conditions? erwise. It is not intended to be comprehensive nor to be a Isolatability: Can the divergent needs of multiple final design. It is not intended to cover non-core aspects parties and applications be addressed to a near- of the framework such as APIs, bindings, languages and optimal degree under the same framework? usage. This is notably experimental; where parameters Developability: How well do the tools work? Do are specified, they are likely to change. Mechanisms will the APIs address the developers' needs? Are ed- be added, refined and removed in response to community ucational materials available? Are the right inte- ideas and critiques. Large portions of this paper will likely grations there? be revised as experimental evidence and prototyping gives Governance: Can the network remain flexible to us information about what will work and what not. evolve and adapt over time? Can decisions be This document includes a core description of the pro- made with sufficient inclusivity, legitimacy and tocol together with ideas for directions that may be taken transparency to provide effective leadership of a to improve various aspects. It is envisioned that the core decentralised system? description will be used as the starting point for an initial Applicability: Does the technology actually ad- series of proofs-of-concept. A final \version 1.0" would be dress a burning need on its own? Is other \mid- based around this refined protocol together with the ad- dleware" required in order to bridge the gap to ditional ideas that become proven and are determined to actual applications? be required for the project to reach its goals. In the present work, we aim to address the first two 1.1. History. issues: scalability and isolatability. That said, we believe the Polkadot framework can provide meaningful improve- • 09/10/2016: 0.1.0-proof1 ments in each of these classes of problems. • 20/10/2016: 0.1.0-proof2 Modern, efficient blockchain implementations such as • 01/11/2016: 0.1.0-proof3 the Parity Ethereum client [17] can process in excess of • 10/11/2016: 0.1.0 3,000 transactions per second when running on perfor- mant consumer hardware. However, current real-world 2. Introduction blockchain networks are practically limited to around 30 Blockchains have demonstrated great promise of util- transactions per second. This limitation mainly origi- ity over several fields including \Internet of Things" nates from the fact that the current synchronous consen- (IoT), finance, governance, identity management, web- sus mechanisms require wide timing margins of safety on decentralisation and asset-tracking. However, despite the the expected processing time, which is exacerbated by the 1 POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 2 desire to support slower implementations. This is due to the reader should be aware that certain mechanisms may the underlying consensus architecture: the state transi- be described (for example interoperation with other pub- tion mechanism, or the means by which parties collate lic networks) which are not directly relevant to Polkadot and execute transactions, has its logic fundamentally tied when deployed under non-public (\permissioned") situa- into the consensus \canonicalisation" mechanism, or the tions. means by which parties agree upon one of a number of possible, valid, histories. This applies equally to both proof-of-work (PoW) sys- 2.2. Previous work. Decoupling the underlying consen- tems such as Bitcoin [15] and Ethereum [5,23] and proof- sus from the state-transition has been informally proposed of-stake (PoS) systems such as NXT [8] and Bitshares [12]: in private for at least two years|Max Kaye was a pro- all ultimately suffer from the same handicap. It is a simple ponent of such a strategy during the very early days of strategy that helped make blockchains a success. However, Ethereum. by tightly coupling these two mechanisms into a single unit A more complex scalable solution known as Chain of the protocol, we also bundle together multiple different fibers, dating back to June 2014 and first published later actors and applications with different risk profiles, differ- that year1, made the case for a single relay-chain and mul- ent scalability requirements and different privacy needs. tiple homogeneous chains providing a transparent inter- One size does not fit all. Too often it is the case that in a chain execution mechanism. Decoherence was paid for desire for broad appeal, a network adopts a degree of con- through transaction latency|transactions requiring the servatism which results in a lowest-common-denominator coordination of disparate portions of the system would optimally serving few and ultimately leading to a failing take longer to process. Polkadot takes much of its ar- in the ability to innovate, perform and adapt, sometimes chitecture from that and the follow-up conversations with dramatically so. various people, though it differs greatly in much of its de- Some systems such as e.g. Factom [21] drop the state- sign and provisions. transition mechanism altogether. However, much of the While there are no systems comparable to Polkadot utility that we desire requires the ability to transition state actually in production, several systems of some relevance according to a shared state-machine. Dropping it solves have been proposed, though few in any substantial level of an alternative problem; it does not provide an alternative detail. These proposals can be broken down into systems solution. which drop or reduce the notion of a globally coherent It seems clear, therefore, that one reasonable direction state machine, those which attempt to provide a globally to explore as a route to a scalable decentralised compute coherent singleton machine through homogeneous shards platform is to decouple the consensus architecture from and those which target only heterogeneity. the state-transition mechanism. And, perhaps unsurpris- ingly, this is the strategy that Polkadot adopts as a solu- tion to scalability. 2.2.1. Systems without Global State. Factom [21] is a sys- 2.1. Protocol, Implementation and Network. Like tem that demonstrates canonicality without the according Bitcoin and Ethereum, Polkadot refers at once to a net- validity, effectively allowing the chronicling of data. Be- work protocol and the (hitherto presupposed) primary cause of the avoidance of global state and the difficulties public network that runs this protocol. Polkadot is in- with scaling which this brings, it can be considered a scal- tended to be a free and open project, the protocol speci- able solution. However, as mentioned previously, the set fication being under a Creative Commons license and the of problems it solves is strictly and substantially smaller. code being placed under a FLOSS license. The project is Tangle [18] is a novel approach to consensus systems. developed in an open manner and accepts contributions Rather than arranging transactions into blocks and form- where ever they are useful. A system of RFCs, not unlike ing consensus over a strictly linked list to give a glob- the Python Enhancement Proposals, will allow a means of ally canonical ordering of state-changes, it largely aban- publicly collaborating over protocol changes and upgrades. dons the idea of a heavily structured ordering and instead Our initial implementation of the Polkadot protocol pushes for a directed acyclic graph of dependent trans- will be known as the Parity Polkadot Platform and will actions with later items helping canonicalise earlier items include a full protocol implementation together with API through explicit referencing. For arbitrary state-changes, bindings. Like other Parity blockchain implementations, this dependency graph would quickly become intractable, PPP is designed to be a general-purpose blockchain tech- however for the much simpler UTXO model2 this becomes nology stack, neither uniquely for a public network nor for quite reasonable.