Polkadot: Visi untuk Kerangka Multi-Rantai yang Heterogen

Polkadot: Vision for a Heterogeneous Multi-Chain Framework

โดย Gavin Wood · 2016

🇺🇸 English (ต้นฉบับ)

🇮🇩 Bahasa Indonesia (คำแปล)

Abstract

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 DR. GAVIN WOOD FOUNDER, ETHEREUM & PARITY [email protected] Abstract. Present-day blockchain architectures all suﬀer from a number of issues not least practical means of extensibility 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 interoperating 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 This is intended to be a technical “vision” summary of one possible direction that may be taken in further developing the blockchain paradigm together with some rationale as to why this direction is sensible. It lays out in as much detail as is possible at this stage of development a system which may give a concrete improvement on a number of aspects of blockchain technology. It is not intended to be a speciﬁcation, formal or otherwise. It is not intended to be comprehensive nor to be a ﬁnal design. It is not intended to cover non-core aspects of the framework such as APIs, bindings, languages and usage. This is notably experimental; where parameters are speciﬁed, they are likely to change. Mechanisms will be added, reﬁned and removed in response to community ideas and critiques. Large portions of this paper will likely be revised as experimental evidence and prototyping gives us information about what will work and what not. This document includes a core description of the protocol together with ideas for directions that may be taken to improve various aspects. It is envisioned that the core description will be used as the starting point for an initial series of proofs-of-concept. A ﬁnal “version 1.0” would be based around this reﬁned protocol together with the additional ideas that become proven and are determined to be required for the project to reach its goals. 1.1. History. • 09/10/2016: 0.1.0-proof1 • 20/10/2016: 0.1.0-proof2 • 01/11/2016: 0.1.0-proof3 • 10/11/2016: 0.1.0 2. Introduction Blockchains have demonstrated great promise of utility over several ﬁelds including “Internet of Things” (IoT), ﬁnance, governance, identity management, webdecentralisation and asset-tracking. However, despite the technological promise and grand talk, we have yet to see signiﬁcant real-world deployment of present technology. We believe that this is down to ﬁve key failures of present technology stacks: Scalability: How much resources are spent globally on processing, bandwidth and storage for the system to process a single transaction and how many transactions can be reasonably processed under peak conditions? Isolatability: Can the divergent needs of multiple parties and applications be addressed to a nearoptimal degree under the same framework? Developability: How well do the tools work? Do the APIs address the developers’ needs? Are educational materials available? Are the right integrations there? Governance: Can the network remain ﬂexible to evolve and adapt over time? Can decisions be made with suﬃcient inclusivity, legitimacy and transparency to provide eﬀective leadership of a decentralised system? Applicability: Does the technology actually address a burning need on its own? Is other “middleware” required in order to bridge the gap to actual applications? In the present work, we aim to address the ﬁrst two issues: scalability and isolatability. That said, we believe the Polkadot framework can provide meaningful improvements in each of these classes of problems. Modern, eﬃcient blockchain implementations such as the Parity Ethereum client [17] can process in excess of 3,000 transactions per second when running on performant consumer hardware. However, current real-world blockchain networks are practically limited to around 30 transactions per second. This limitation mainly originates from the fact that the current synchronous consensus mechanisms require wide timing margins of safety on the expected processing time, which is exacerbated by the 1

Abstrak

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 dr. KAYU GAVIN PENDIRI, ETHEREUM & PARITAS [email protected] Abstrak. Arsitektur blockchain saat ini semuanya mengalami sejumlah masalah, paling tidak dalam hal praktik ekstensibilitas dan skalabilitas. Kami percaya hal ini berasal dari pengikatan dua bagian yang sangat penting dari arsitektur konsensus, yaitu: kanonikalitas dan validitas, terlalu erat hubungannya. Makalah ini memperkenalkan arsitektur, multi-rantai heterogen, yang pada dasarnya membedakan keduanya. Dengan mengelompokkan kedua bagian ini, dan dengan menjaga keseluruhan fungsi yang disediakan seminimal mungkin keamanan dan transportasi, kami memperkenalkan sarana praktis perluasan inti di lokasi. Skalabilitas diatasi melalui pendekatan bagi-dan-taklukkan kedua fungsi ini, dengan memperluas fungsi inti yang terikat melalui insentif node publik yang tidak tepercaya. Sifat heterogen dari arsitektur ini memungkinkan banyak jenis sistem konsensus yang sangat berbeda untuk saling beroperasi dalam “federasi” yang tidak dapat dipercaya dan sepenuhnya terdesentralisasi, memungkinkan jaringan terbuka dan tertutup untuk memiliki akses bebas kepercayaan ke satu sama lain. Kami mengedepankan sarana untuk menyediakan kompatibilitas mundur dengan satu atau lebih jaringan yang sudah ada seperti Ethereum. Kami percaya bahwa sistem seperti itu menyediakan komponen tingkat dasar yang berguna dalam pencarian keseluruhan secara praktis sistem yang dapat diterapkan yang mampu mencapai tingkat skalabilitas dan privasi perdagangan global. 1. Kata Pengantar Hal ini dimaksudkan sebagai ringkasan “visi” teknis satu kemungkinan arah yang dapat diambil dalam mengembangkan lebih lanjut paradigma blockchain beserta beberapa alasan mengapa arah ini masuk akal. Itu diatur dalam sedetail mungkin pada tahap pengembangan ini suatu sistem yang dapat memberikan perbaikan nyata pada a sejumlah aspek teknologi blockchain. Hal ini tidak dimaksudkan sebagai spesifikasi, formal atau lainnya. Hal ini tidak dimaksudkan untuk menjadi komprehensif atau a desain akhir. Hal ini tidak dimaksudkan untuk mencakup aspek-aspek non-inti kerangka kerja seperti API, binding, bahasa, dan penggunaan. Ini terutama bersifat eksperimental; di mana parameter ditentukan, kemungkinan besar akan berubah. Mekanisme akan melakukannya ditambahkan, disempurnakan, dan dihapus sebagai respons terhadap komunitas ide dan kritik. Kemungkinan besar sebagian besar makalah ini akan membahasnya direvisi sesuai bukti eksperimental dan pemberian prototipe kami informasi tentang apa yang akan berhasil dan apa yang tidak. Dokumen ini mencakup uraian inti protokol beserta gagasan arah yang dapat diambil untuk memperbaiki berbagai aspek. Hal ini dibayangkan sebagai inti deskripsi akan digunakan sebagai titik awal untuk inisial serangkaian pembuktian konsep. “Versi 1.0” terakhir adalah didasarkan pada protokol yang disempurnakan ini bersama dengan ide-ide tambahan yang telah terbukti dan bertekad untuk itu diperlukan agar proyek dapat mencapai tujuannya. 1.1. Sejarah. • 09/10/2016: 0.1.0-bukti1 • 20/10/2016: 0.1.0-bukti2 • 01/11/2016: 0.1.0-bukti3 • 11/10/2016: 0.1.0 2. Pendahuluan Blockchain telah menunjukkan manfaat yang besar di beberapa bidang termasuk “Internet of Things” (IoT), keuangan, tata kelola, manajemen identitas, desentralisasi web, dan pelacakan aset. Namun, meskipun demikian janji teknologi dan pembicaraan besar, kita belum melihatnya penyebaran teknologi saat ini yang signifikan di dunia nyata. Kami percaya bahwa hal ini disebabkan oleh lima kegagalan utama yang terjadi saat ini tumpukan teknologi: Skalabilitas: Berapa banyak sumber daya yang dihabiskan secara global pada pemrosesan, bandwidth dan penyimpanan agar sistem dapat memproses satu transaksi dan berapa banyak transaksi dapat diproses secara wajar berdasarkan kondisi puncak? Isolatabilitas: Dapat memenuhi kebutuhan yang berbeda-beda pihak dan permohonan ditangani hingga tingkat yang mendekati optimal dalam kerangka yang sama? Pengembangan: Seberapa baik alat tersebut bekerja? Lakukan apakah API memenuhi kebutuhan pengembang? Apakah materi pendidikan tersedia? Apakah ada integrasi yang tepat? Tata Kelola: Dapatkah jaringan tetap fleksibel terhadap berevolusi dan beradaptasi seiring berjalannya waktu? Bisakah keputusan menjadi dibuat dengan inklusivitas, legitimasi dan transparansi untuk memberikan kepemimpinan yang efektif a sistem desentralisasi? Penerapan: Apakah teknologi tersebut benar-benar mampu menjawab kebutuhan yang mendesak? Apakah “perangkat perantara” lain diperlukan untuk menjembatani kesenjangan tersebut aplikasi sebenarnya? Dalam penelitian ini, kami bertujuan untuk mengatasi dua hal pertama masalah: skalabilitas dan isolasi. Meski begitu, kami percaya kerangka Polkadot dapat memberikan perbaikan yang berarti pada setiap kelompok masalah ini. Implementasi blockchain yang modern dan efisien seperti klien Paritas Ethereum [17] dapat memproseses lebih dari 3.000 transaksi per detik saat dijalankan pada perangkat keras konsumen yang berkinerja baik. Namun, dunia nyata saat ini blockchain jaringan praktis dibatasi sekitar 30 transaksi per detik. Keterbatasan ini terutama berasal dari kenyataan bahwa mekanisme konsensus sinkron yang ada saat ini memerlukan batas waktu keselamatan yang besar waktu pemrosesan yang diharapkan, yang diperburuk oleh 1

Introduction

Blockchains have demonstrated great promise of utility over several ﬁelds including “Internet of Things” (IoT), ﬁnance, governance, identity management, webdecentralisation and asset-tracking. However, despite the technological promise and grand talk, we have yet to see signiﬁcant real-world deployment of present technology. We believe that this is down to ﬁve key failures of present technology stacks: Scalability: How much resources are spent globally on processing, bandwidth and storage for the system to process a single transaction and how many transactions can be reasonably processed under peak conditions? Isolatability: Can the divergent needs of multiple parties and applications be addressed to a nearoptimal degree under the same framework? Developability: How well do the tools work? Do the APIs address the developers’ needs? Are educational materials available? Are the right integrations there? Governance: Can the network remain ﬂexible to evolve and adapt over time? Can decisions be made with suﬃcient inclusivity, legitimacy and transparency to provide eﬀective leadership of a decentralised system? Applicability: Does the technology actually address a burning need on its own? Is other “middleware” required in order to bridge the gap to actual applications? In the present work, we aim to address the ﬁrst two issues: scalability and isolatability. That said, we believe the Polkadot framework can provide meaningful improvements in each of these classes of problems. Modern, eﬃcient blockchain implementations such as the Parity Ethereum client [17] can process in excess of 3,000 transactions per second when running on performant consumer hardware. However, current real-world blockchain networks are practically limited to around 30 transactions per second. This limitation mainly originates from the fact that the current synchronous consensus mechanisms require wide timing margins of safety on the expected processing time, which is exacerbated by the

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 2 desire to support slower implementations. This is due to the underlying consensus architecture: the state transition mechanism, or the means by which parties collate and execute transactions, has its logic fundamentally tied into the consensus “canonicalisation” mechanism, or the means by which parties agree upon one of a number of possible, valid, histories. This applies equally to both proof-of-work (PoW) systems such as Bitcoin [15] and Ethereum [5,23] and proofof-stake (PoS) systems such as NXT [8] and Bitshares [12]: all ultimately suﬀer from the same handicap. It is a simple strategy that helped make blockchains a success. However, by tightly coupling these two mechanisms into a single unit of the protocol, we also bundle together multiple diﬀerent actors and applications with diﬀerent risk proﬁles, diﬀerent scalability requirements and diﬀerent privacy needs. One size does not ﬁt all. Too often it is the case that in a desire for broad appeal, a network adopts a degree of conservatism which results in a lowest-common-denominator optimally serving few and ultimately leading to a failing in the ability to innovate, perform and adapt, sometimes dramatically so. Some systems such as e.g. Factom [21] drop the statetransition mechanism altogether. However, much of the utility that we desire requires the ability to transition state according to a shared state-machine. Dropping it solves an alternative problem; it does not provide an alternative solution. It seems clear, therefore, that one reasonable direction to explore as a route to a scalable decentralised compute platform is to decouple the consensus architecture from the state-transition mechanism. And, perhaps unsurprisingly, this is the strategy that Polkadot adopts as a solution to scalability. 2.1. Protocol, Implementation and Network. Like Bitcoin and Ethereum, Polkadot refers at once to a network protocol and the (hitherto presupposed) primary public network that runs this protocol. Polkadot is intended to be a free and open project, the protocol speciﬁcation being under a Creative Commons license and the code being placed under a FLOSS license. The project is developed in an open manner and accepts contributions where ever they are useful. A system of RFCs, not unlike the Python Enhancement Proposals, will allow a means of publicly collaborating over protocol changes and upgrades. Our initial implementation of the Polkadot protocol will be known as the Parity Polkadot Platform and will include a full protocol implementation together with API bindings. Like other Parity blockchain implementations, PPP is designed to be a general-purpose blockchain technology stack, neither uniquely for a public network nor for private/consortium operation. The development of it thus far has been funded by several parties including through a grant from the British government. This paper nonetheless describes Polkadot under the context of a public network. The functionality we envision in a public network is a superset of that required in alternative (e.g. private and/or consortium) settings. Furthermore, in this context, the full scope of Polkadot can be more clearly described and discussed. This does mean the reader should be aware that certain mechanisms may be described (for example interoperation with other public networks) which are not directly relevant to Polkadot when deployed under non-public (“permissioned”) situations. 2.2. Previous work. Decoupling the underlying consensus from the state-transition has been informally proposed in private for at least two years—Max Kaye was a proponent of such a strategy during the very early days of Ethereum. A more complex scalable solution known as Chain ﬁbers, dating back to June 2014 and ﬁrst published later that year1, made the case for a single relay-chain and multiple homogeneous chains providing a transparent interchain execution mechanism. Decoherence was paid for through transaction latency—transactions requiring the coordination of disparate portions of the system would take longer to process. Polkadot takes much of its architecture from that and the follow-up conversations with various people, though it diﬀers greatly in much of its design and provisions. While there are no systems comparable to Polkadot actually in production, several systems of some relevance have been proposed, though few in any substantial level of detail. These proposals can be broken down into systems which drop or reduce the notion of a globally coherent state machine, those which attempt to provide a globally coherent singleton machine through homogeneous shards and those which target only heterogeneity. 2.2.1. Systems without Global State. Factom [21] is a system that demonstrates canonicality without the according validity, eﬀectively allowing the chronicling of data. Because of the avoidance of global state and the diﬃculties with scaling which this brings, it can be considered a scalable solution. However, as mentioned previously, the set of problems it solves is strictly and substantially smaller. Tangle [18] is a novel approach to consensus systems. Rather than arranging transactions into blocks and forming consensus over a strictly linked list to give a globally canonical ordering of state-changes, it largely abandons the idea of a heavily structured ordering and instead pushes for a directed acyclic graph of dependent transactions with later items helping canonicalise earlier items through explicit referencing. For arbitrary state-changes, this dependency graph would quickly become intractable, however for the much simpler UTXO model2 this becomes quite reasonable. Because the system is only loosely coherent and transactions are generally independent of each other, a large amount of global parallelism becomes quite natural. Using the UTXO model does have the eﬀect of limiting Tangle to a purely value-transfer “currency” system rather than anything more general or extensible. Furthermore without the hard global coherency, interaction with other systems—which tend to need an absolute degree knowledge over the system state—becomes impractical. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2unspent transaction output, the model that Bitcoin uses whereby the state is eﬀectively the set of address associated with some value; transactions collate such addresses and reform them into a new set of addresses whose sum total is equivalent

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 3 2.2.2. Heterogeneous Chain Systems. Side-chains [3] is a proposed addition to the Bitcoin protocol which would allow trustless interaction between the main Bitcoin chain and additional side-chains. There is no provision for any degree of ‘rich’ interaction between side-chains: the interaction would be limited to allowing side-chains to be custodians of each other’s assets, eﬀecting—in the local jargon—a two-way peg 3. The end vision is for a framework where the Bitcoin currency could be provided with additional, if peripheral, functionality through pegging it onto some other chains with more exotic state transition systems than the Bitcoin protocol allows. In this sense, side-chains addresses extensibility rather than scalability. Indeed, there is fundamentally no provision for the validity of side-chains; tokens from one chain (e.g. Bitcoin) held on behalf of a side-chain are secured only by the side-chain’s ability to incentivise miners to canonicalise valid transitions. The security of the Bitcoin network cannot easily be transitioned to work on behalf of other blockchains. Furthermore, a protocol for ensuring Bitcoin miners merge-mine (that is duplicate their canonicalisation power onto that of the side-chain) and, more importantly, validate the side-chain’s transitions is outside the scope of this proposal. Cosmos [10] is a proposed multi-chain system in the same vein as side-chains, swapping the Nakamoto PoW consensus method for Jae Kwon’s Tendermint algorithm. Essentially, it describes multiple chains (operating in zones) each using individual instances of Tendermint, together with a means for trust-free communication via a master hub chain. This interchain communication is limited to the transfer of digital assets (“speciﬁcally about tokens”) rather than arbitrary information, however such interchain communication does have a return path for data, e.g. to report to the sender on the status of the transfer. Validator sets for the zoned chains, and in particular the means of incentivising them, are, like side-chains, left as an unsolved problem. The general assumption is that each zoned chain will itself hold a token of value whose inﬂation is used to pay for validators. Still in the early stages of design, at present the proposal lacks comprehensive details over the economic means of achieving the scalable certainty over global validity. However, the loose coherence required between the zones and the hub will allow for additional ﬂexibility over the parameters of the zoned chains compared to that of a system enforcing stronger coherence. 2.2.3. Casper. As yet no comprehensive review or sideby-side comparison between Casper [6] and Polkadot have been made, though one can make a fairly sweeping (and accordingly inaccurate) characterisation of the two. Casper is a reimagining of how a PoS consensus algorithm could be based around participants betting on which fork would ultimately become canonical. Substantial consideration was given to ensuring that it be robust to network forks, even when prolonged, and have some additional degree of scalability on top of the basic Ethereum model. As such, Casper to date has tended to be a substantially more complex protocol than Polkadot and its forebears, and a substantial deviation from the basic blockchain format. It remains unseen as to how Casper will iterate in the future and what it will look like should it ﬁnally be deployed. While Casper and Polkadot both represent interesting new protocols and, in some sense, augmentations of Ethereum, there are substantial diﬀerences between their ultimate goals and paths to deployment. Casper is an Ethereum Foundation-centered project originally designed to be a PoS alteration to the protocol with no desire to create a fundamentally scalable blockchain. Crucially, it is designed to be a hard-fork, rather than anything more expansive and thus all Ethereum clients and users would be required to upgrade or remain on a fork of uncertain adoption. As such, deployment is made substantially more difﬁcult as is inherent in a decentralised project where tight coordination is necessary. Polkadot diﬀers in several ways; ﬁrst and foremost, Polkadot is designed to be a fully extensible and scalable blockchain development, deployment and interaction test bed. It is built to be a largely future-proof harness able to assimilate new blockchain technology as it becomes available without over-complicated decentralised coordination or hard forks. We already envision several use cases such as encrypted consortium chains and high-frequency chains with very low block times that are unrealistic to do in any future version of Ethereum currently envisioned. Finally, the coupling between it and Ethereum is extremely loose; no action on the part of Ethereum is necessary to enable trustless transaction forwarding between the two networks. In short, while Casper/Ethereum 2.0 and Polkadot share some ﬂeeting similarities we believe their end goal is substantially diﬀerent and that rather than competing, the two protocols are likely to ultimately co-exist under a mutually beneﬁcial relationship for the foreseeable future.

Perkenalan

Blockchain telah menunjukkan manfaat yang besar di beberapa bidang termasuk “Internet of Things” (IoT), keuangan, tata kelola, manajemen identitas, desentralisasi web, dan pelacakan aset. Namun, meskipun demikian janji teknologi dan pembicaraan besar, kita belum melihatnya penyebaran teknologi saat ini yang signifikan di dunia nyata. Kami percaya bahwa hal ini disebabkan oleh lima kegagalan utama yang terjadi saat ini tumpukan teknologi: Skalabilitas: Berapa banyak sumber daya yang dihabiskan secara global pada pemrosesan, bandwidth dan penyimpanan agar sistem dapat memproses satu transaksi dan berapa banyak transaksi dapat diproses secara wajar berdasarkan kondisi puncak? Isolatabilitas: Dapat memenuhi kebutuhan yang berbeda-beda pihak dan permohonan ditangani hingga tingkat yang mendekati optimal dalam kerangka yang sama? Pengembangan: Seberapa baik alat tersebut bekerja? Lakukan apakah API memenuhi kebutuhan pengembang? Apakah materi pendidikan tersedia? Apakah ada integrasi yang tepat? Tata Kelola: Dapatkah jaringan tetap fleksibel terhadap berevolusi dan beradaptasi seiring berjalannya waktu? Bisakah keputusan menjadi dibuat dengan inklusivitas, legitimasi dan transparansi untuk memberikan kepemimpinan yang efektif a sistem desentralisasi? Penerapan: Apakah teknologi tersebut benar-benar mampu menjawab kebutuhan yang mendesak? Apakah “perangkat perantara” lain diperlukan untuk menjembatani kesenjangan tersebut aplikasi sebenarnya? Dalam penelitian ini, kami bertujuan untuk mengatasi dua hal pertama masalah: skalabilitas dan isolasi. Meski begitu, kami percaya kerangka Polkadot dapat memberikan perbaikan yang berarti pada setiap kelompok masalah ini. Implementasi blockchain yang modern dan efisien seperti klien Paritas Ethereum [17] dapat memproses lebih dari 3.000 transaksi per detik saat dijalankan pada perangkat keras konsumen yang berkinerja baik. Namun, dunia nyata saat ini blockchain jaringan praktis dibatasi sekitar 30 transaksi per detik. Keterbatasan ini terutama berasal dari kenyataan bahwa mekanisme konsensus sinkron yang ada saat ini memerlukan batas waktu keselamatan yang besar waktu pemrosesan yang diharapkan, yang diperburuk olehPOLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 2 keinginan untuk mendukung implementasi yang lebih lambat. Hal ini disebabkan oleh arsitektur konsensus yang mendasarinya: mekanisme transisi negara, atau cara para pihak berkolaborasi dan mengeksekusi transaksi, logikanya terikat secara fundamental ke dalam mekanisme “kanonikalisasi” konsensus, atau cara yang digunakan para pihak untuk menyepakati salah satu dari beberapa hal mungkin, valid, sejarah. Hal ini berlaku sama untuk sistem proof-of-work (PoW) seperti Bitcoin [15] dan Ethereum [5,23] dan sistem proof-of-stake (PoS) seperti NXT [8] dan Bitshares [12]: semua pada akhirnya menderita cacat yang sama. Ini sederhana strategi yang membantu membuat blockchains sukses. Namun, dengan menggabungkan kedua mekanisme ini secara erat menjadi satu unit protokol, kami juga menggabungkan beberapa protokol yang berbeda aktor dan aplikasi dengan profil risiko berbeda, persyaratan skalabilitas berbeda, dan kebutuhan privasi berbeda. Satu ukuran tidak cocok untuk semua. Seringkali terjadi bahwa dalam a keinginan untuk mendapatkan daya tarik yang luas, suatu jaringan mengadopsi tingkat konservatisme yang menghasilkan kesamaan yang paling rendah secara optimal hanya melayani segelintir orang dan pada akhirnya berujung pada kegagalan dalam kemampuan untuk berinovasi, melakukan dan beradaptasi, terkadang secara dramatis begitu. Beberapa sistem seperti mis. Factom [21] menghilangkan mekanisme transisi status sama sekali. Namun, sebagian besar utilitas yang kita inginkan memerlukan kemampuan keadaan transisi menurut mesin negara bersama. Menjatuhkannya menyelesaikan masalah masalah alternatif; itu tidak memberikan alternatif solusi. Oleh karena itu, tampak jelas bahwa satu arah yang masuk akal untuk dijelajahi sebagai rute menuju komputasi terdesentralisasi yang dapat diskalakan platform adalah untuk memisahkan arsitektur konsensus dari mekanisme transisi negara. Dan, mungkin tidak mengejutkan, ini adalah strategi yang Polkadot terapkan sebagai solusi terhadap skalabilitas. 2.1. Protokol, Implementasi dan Jaringan. Suka Bitcoin dan Ethereum, Polkadot merujuk sekaligus ke protokol jaringan dan protokol utama (yang sampai sekarang dianggap) jaringan publik yang menjalankan protokol ini. Polkadot dimaksudkan sebagai proyek yang bebas dan terbuka, spesifikasi protokol berada di bawah lisensi Creative Commons dan kode ditempatkan di bawah lisensi FLOSS. Proyeknya adalah dikembangkan secara terbuka dan menerima kontribusi dimanapun mereka berguna. Sebuah sistem RFC, tidak berbeda dengan Proposal Peningkatan Python, akan memungkinkan sarana berkolaborasi secara publik atas perubahan dan peningkatan protokol. Implementasi awal kami terhadap protokol Polkadot akan dikenal sebagai Platform Paritas Polkadot dan akan menyertakan implementasi protokol lengkap bersama dengan API ikatan. Seperti implementasi Paritas blockchain lainnya, PPP dirancang untuk menjadi tumpukan teknologi blockchain yang bertujuan umum, tidak khusus untuk jaringan publik maupun untuk operasi swasta/konsorsium. Perkembangannya demikian sejauh ini telah didanai oleh beberapa pihak termasuk melalui hibah dari pemerintah Inggris. Namun makalah ini menjelaskan Polkadot di bawah konteks jaringan publik. Fungsionalitas yang kami bayangkan dalam jaringan publik adalah superset dari apa yang diperlukan dalam jaringan publik pengaturan alternatif (misalnya swasta dan/atau konsorsium). Selanjutnya dalam konteks ini, seluruh cakupan Polkadot bisa diuraikan dan didiskusikan dengan lebih jelas. Ini berarti pembaca harus menyadari bahwa mekanisme tertentu mungkin terjadi dijelaskan (misalnya interoperasi dengan jaringan publik lainnya) yang tidak relevan secara langsung dengan Polkadot ketika digunakan dalam situasi non-publik (“diizinkan”). 2.2. Pekerjaan sebelumnya. Pemisahan konsensus mendasar dari transisi negara telah diusulkan secara informal secara pribadi selama setidaknya dua tahun—Max Kaye adalah pendukung strategi semacam itu pada masa-masa awal Ethereum. Solusi terukur yang lebih kompleks dikenal sebagai Chain fibers, sejak Juni 2014 dan pertama kali diterbitkan kemudian pada tahun 1, mengajukan kasus untuk satu rantai relai dan beberapa rantai homogen yang menyediakan mekanisme eksekusi antar rantai yang transparan. Dekoherensi dibayar melalui latensi transaksi—transaksi yang memerlukan koordinasi bagian-bagian yang berbeda dari sistem akan membutuhkan waktu lebih lama untuk diproses. Polkadot mengambil sebagian besar arsitekturnya dari itu dan percakapan lanjutannya berbagai orang, meskipun desain dan ketentuannya sangat berbeda. Meskipun tidak ada sistem yang sebanding dengan Polkadot sebenarnya dalam produksi, beberapa sistem yang memiliki relevansi tertentu telah diusulkan, meskipun hanya sedikit pada tingkat substansial detail. Proposal ini bisa sajadipecah menjadi sistem yang menjatuhkan atau mengurangi gagasan koheren secara global mesin negara, mereka yang berupaya menyediakan solusi global mesin tunggal yang koheren melalui pecahan homogen dan yang hanya menargetkan heterogenitas. 2.2.1. Sistem tanpa Negara Global. Factom [21] adalah sistem yang menunjukkan kanonikalitas tanpa penyesuaian validitas, secara efektif memungkinkan pencatatan data. Karena penghindaran keadaan global dan kesulitannya dengan penskalaan yang dihasilkannya, ini dapat dianggap sebagai solusi yang terukur. Namun, seperti disebutkan sebelumnya, himpunan masalah yang dipecahkannya jauh lebih kecil dan ketat. Tangle [18] adalah pendekatan baru terhadap sistem konsensus. Daripada mengatur transaksi-transaksi ke dalam blok-blok dan membentuk konsensus mengenai daftar yang saling terkait untuk memberikan tatanan perubahan negara yang kanonik secara global, mereka lebih banyak meninggalkan gagasan tatanan yang sangat terstruktur dan sebaliknya mendorong grafik asiklik terarah dari transaksi dependen dengan item-item selanjutnya yang membantu mengkanonikalisasi item-item sebelumnya melalui referensi eksplisit. Untuk perubahan keadaan yang sewenang-wenang, grafik ketergantungan ini akan dengan cepat menjadi sulit diselesaikan, namun untuk UTXO model2 yang lebih sederhana ini menjadi cukup masuk akal. Karena sistemnya hanya koheren secara longgar dan transaksi pada umumnya independen satu sama lain Di sisi lain, sejumlah besar paralelisme global menjadi hal yang cukup serius alami. Menggunakan model UTXO memang memiliki efek membatasi Tangle pada “mata uang” transfer nilai murni sistem daripada sesuatu yang lebih umum atau diperluas. Terlebih lagi tanpa koherensi global yang sulit, interaksi dengan sistem lain—yang cenderung membutuhkan hal yang mutlak tingkat pengetahuan atas keadaan sistem—menjadi tidak praktis. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2output transaksi yang tidak terpakai, model yang digunakan Bitcoin dimana status secara efektif adalah kumpulan alamat yang terkait dengan beberapa nilai; transaksi menyusun alamat tersebut dan mengubahnya menjadi kumpulan alamat baru yang jumlah totalnya setara

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 3 2.2.2. Sistem Rantai Heterogen. Rantai samping [3] adalah a mengusulkan penambahan protokol Bitcoin yang akan memungkinkan interaksi tanpa kepercayaan antara rantai Bitcoin utama dan rantai samping tambahan. Tidak ada ketentuan untuk apapun tingkat interaksi 'kaya' antar rantai samping: interaksi akan dibatasi hanya pada rantai samping yang memungkinkan adanya penjaga aset masing-masing, yang berdampak—di tingkat lokal jargon—pasak dua arah 3. Visi akhirnya adalah kerangka kerja di mana mata uang Bitcoin dapat disediakan tambahan, jika bersifat periferal, fungsionalitas melalui mengelompokkannya ke beberapa rantai lain dengan transisi keadaan yang lebih eksotis sistem daripada yang diizinkan oleh protokol Bitcoin. Dalam pengertian ini, rantai samping membahas ekstensibilitas daripada skalabilitas. Memang benar, pada dasarnya tidak ada ketentuan mengenai validitas rantai samping; tokens dari satu rantai (misalnya Bitcoin) yang dipegang atas nama rantai samping hanya diamankan oleh kemampuan rantai samping untuk memberi insentif kepada penambang agar melakukan kanonikalisasi transisi yang valid. Keamanan jaringan Bitcoin tidak dapat dengan mudah dialihkan untuk bekerja atas nama orang lain blockchains. Selanjutnya, protokol untuk memastikan Bitcoin penambang menggabungkan-menambang (yaitu menduplikasi kekuatan kanonikalisasi mereka ke dalam rantai samping) dan, yang lebih penting, memvalidasi transisi rantai samping berada di luar ruang lingkup proposal ini. Cosmos [10] adalah sistem multi-rantai yang diusulkan di nada yang sama seperti rantai samping, menukar PoW Nakamoto metode konsensus untuk algoritma Tendermint Jae Kwon. Pada dasarnya, ini menggambarkan banyak rantai (beroperasi di zona) masing-masing menggunakan contoh Tendermint individual, bersama dengan sarana komunikasi bebas kepercayaan melalui a rantai hub utama. Komunikasi antarrantai ini terbatas pada transfer aset digital (“khususnya tentang tokens”) dan bukan informasi sewenang-wenang, namun komunikasi antarrantai tersebut memiliki jalur balik untuk data, misalnya untuk melaporkan kepada pengirim tentang status transfer. Set validator untuk rantai yang dikategorikan, dan khususnya sarana untuk memberikan insentif kepada mereka, seperti rantai samping, masih tersisa sebagai masalah yang belum terselesaikan. Asumsi umumnya adalah demikian setiap rantai yang dikategorikan akan memiliki nilai sebesar token yang inflasinya digunakan untuk membayar validators. Masih dalam tahap awal dari segi desain, saat ini proposal tersebut kurang memiliki rincian komprehensif mengenai cara ekonomi untuk mencapai skalabel kepastian validitas global. Namun, koherensi longgar yang diperlukan antara zona dan hub akan memungkinkan hal ini untuk fleksibilitas tambahan atas parameter yang dikategorikan rantai dibandingkan dengan sistem yang menegakkan lebih kuat koherensi. 2.2.3. Casper. Belum ada tinjauan komprehensif atau perbandingan berdampingan antara Casper [6] dan Polkadot telah dibuat, meskipun seseorang dapat melakukan penyisiran yang cukup besar (dan karenanya tidak akurat) karakterisasi keduanya. Casper adalah konsep ulang tentang bagaimana algoritma konsensus PoS dapat didasarkan pada peserta yang bertaruh pada garpu yang mana pada akhirnya akan menjadi kanonik. Pertimbangan substansial diberikan untuk memastikan bahwa jaringan tersebut kuat fork, meskipun diperpanjang, dan memiliki tingkat skalabilitas tambahan di atas model dasar Ethereum. Sebagai demikian, Casper hingga saat ini cenderung jauh lebih baik protokol yang kompleks dari Polkadot dan pendahulunya, dan a penyimpangan substansial dari format dasar blockchain. Itu masih belum terlihat bagaimana Casper akan mengulanginya di masa depan dan seperti apa tampilannya jika akhirnya diterapkan. Meskipun Casper dan Polkadot keduanya mewakili protokol baru yang menarik dan, dalam beberapa hal, penambahan Ethereum, ada perbedaan besar di antara keduanya tujuan akhir dan jalur menuju penerapan. Casper adalah seorang Ethereum Proyek yang berpusat pada yayasan awalnya dirancang menjadi perubahan PoS pada protokol tanpa keinginan untuk melakukannya buat blockchain yang secara fundamental dapat diskalakan. Yang terpenting, itu benar dirancang untuk menjadi hard-fork, bukan sesuatu yang lebih ekspansif dan dengan demikian semua Ethereum klien dan pengguna akan menjadi diperlukan untuk meningkatkan atau tetap berada pada jalur adopsi yang tidak pasti. Oleh karena itu, penerapannya menjadi lebih sulit karena hal ini melekat pada proyek yang terdesentralisasi koordinasi sangat diperlukan. Polkadot berbeda dalam beberapa hal; pertama dan terpenting, Polkadot dirancang agar dapat diperluas dan diperluas sepenuhnya blockchain uji pengembangan, penerapan, dan interaksi tempat tidur. Ini dibangun untuk menjadi alat pengaman yang mampu bertahan di masa depan mengasimilasi blockchain baruteknologi yang tersedia tanpa koordinasi desentralisasi yang terlalu rumit atau garpu keras. Kami sudah membayangkan beberapa kasus penggunaan seperti itu seperti rantai konsorsium terenkripsi dan rantai frekuensi tinggi dengan waktu blok yang sangat rendah sehingga tidak realistis untuk dilakukan versi masa depan apa pun dari Ethereum yang saat ini direncanakan. Terakhir, hubungan antara itu dan Ethereum sangatlah luar biasa longgar; tidak diperlukan tindakan apa pun dari Ethereum memungkinkan penerusan transaksi tanpa kepercayaan antara keduanya jaringan. Singkatnya, sementara Casper/Ethereum 2.0 dan Polkadot berbagi beberapa kesamaan sekilas yang kami yakini sebagai tujuan akhirnya sangat berbeda dan daripada bersaing, kedua protokol tersebut kemungkinan besar akan hidup berdampingan di bawah a hubungan yang saling menguntungkan di masa mendatang.

Summary

Polkadot is a scalable heterogeneous multi-chain. This means that unlike previous blockchain implementations which have focused on providing a single chain of varying degrees of generality over potential applications, Polkadot itself is designed to provide no inherent application functionality at all. Rather, Polkadot provides the bedrock “relay-chain” upon which a large number of validatable, globally-coherent dynamic data-structures may be hosted side-by-side. We call these data-structures “parallelised” chains or parachains, though there is no speciﬁc need for them to be blockchain in nature. In other words, Polkadot may be considered equivalent to a set of independent chains (e.g. the set containing Ethereum, Ethereum Classic, Namecoin and Bitcoin) except for two very important points: • Pooled security; • trust-free interchain transactability. These points are why we consider Polkadot to be “scalable”. In principle, a problem to be deployed on Polkadot may be substantially parallelised—scaled out—over a large number of parachains. Since all aspects of each parachain may be conducted in parallel by a diﬀerent segment of the Polkadot network, the system has some ability to scale. Polkadot provides a rather bare-bones piece of 3as opposed to a one-way peg which is essentially the action of destroying tokens in one chain to create tokens in another without the mechanism to do the converse in order to recover the original tokens

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 4 infrastructure leaving much of the complexity to be addressed at the middleware level. This is a conscious decision intended to reduce development risk, enabling the requisite software to be developed within a short time span and with a good level of conﬁdence over its security and robustness. 3.1. The Philosophy of Polkadot. Polkadot should provide an absolute rock-solid foundation on which to build the next wave of consensus systems, right through the risk spectrum from production-capable mature designs to nascent ideas. By providing strong guarantees over security, isolation and communication, Polkadot can allow parachains to select from a range of properties themselves. Indeed, we foresee various experimental blockchains pushing the properties of what could be considered sensible today. We see conservative, high-value chains similar to Bitcoin or Z-cash [20] co-existing alongside lower-value “theme-chains” (such marketing, so fun) and test-nets with zero or near-zero fees. We see fully-encrypted, “dark”, consortium chains operating alongside—and even providing services to—highly functional and open chains such as those like Ethereum. We see experimental new VM-based chains such as a subjective time-charged wasm chain being used as a means of outsourcing diﬃcult compute problems from a more mature Ethereum-like chain or a more restricted Bitcoin-like chain. To manage chain upgrades, Polkadot will inherently support some sort of governance structure, likely based on existing stable political systems and having a bicameral aspect similar to the Yellow Paper Council [24]. As the ultimate authority, the underlying stakable token holders would have “referendum” control. To reﬂect the users’ need for development but the developers’ need for legitimacy, we expect a reasonable direction would be to form the two chambers from a “user” committee (made up of bonded validators) and a “technical” committee made up of major client developers and ecosystem players. The body of token holders would maintain the ultimate legitimacy and form a supermajority to augment, reparameterise, replace or dissolve this structure, something we don’t doubt the eventual need for: in the words of Twain “Governments and diapers must be changed often, and for the same reason”. Whereas reparameterisation is typically trivial to arrange within a larger consensus mechanism, more qualitative changes such as replacement and augmentation would likely need to be either non-automated “soft-decrees” (e.g. through the canonicalisation of a block number and the hash of a document formally specifying the new protocol) or necessitate the core consensus mechanism to contain a suﬃciently rich language to describe any aspect of itself which may need to change. The latter is an eventual aim, however, the former more likely to be chosen in order to facilitate a reasonable development timeline. Polkadot’s primary tenets and the rules within which we evaluate all design decisions are: Minimal: Polkadot should have as little functionality as possible. Simple: no additional complexity should be present in the base protocol than can reasonably be oﬄoaded into middleware, placed through a parachain or introduced in a later optimisation. General: no unnecessary requirement, constraint or limitation should be placed on parachains; Polkadot should be a test bed for consensus system development which can be optimised through making the model into which extensions ﬁt as abstract as possible. Robust: Polkadot should provide a fundamentally stable base-layer. In addition to economic soundness, this also means decentralising to minimise the vectors for high-reward attacks.

Ringkasan

Polkadot adalah multi-rantai heterogen yang dapat diskalakan. Ini artinya tidak seperti implementasi blockchain sebelumnya yang berfokus pada penyediaan satu rantai yang bervariasi tingkat keumuman atas penerapan potensial, Polkadot itu sendiri dirancang untuk tidak menyediakan fungsionalitas aplikasi bawaan sama sekali. Sebaliknya, Polkadot menyediakan batuan dasar "rantai relai" yang menjadi dasar sejumlah besar validasi, struktur data dinamis yang koheren secara global dapat dihosting berdampingan. Kami menyebut struktur data ini “paralel” rantai atau parachain, meskipun tidak ada kebutuhan khusus untuk itu mereka menjadi blockchain di alam. Dengan kata lain, Polkadot dapat dianggap setara dengan himpunan rantai independen (misalnya himpunan yang berisi Ethereum, Ethereum Klasik, Namecoin dan Bitcoin) kecuali dua poin yang sangat penting: • Keamanan gabungan; • kemampuan transaksi antar rantai yang bebas kepercayaan. Poin-poin inilah yang menjadi alasan kami menganggap Polkadot “dapat diskalakan”. Pada prinsipnya, masalah yang akan diterapkan pada Polkadot mungkin secara substansial diparalelkan—diperluas—di atas sejumlah besar parachain. Karena semua aspek masing-masing parachain dapat dilakukan secara paralel oleh segmen berbeda dari jaringan Polkadot, sistem memiliki beberapa kemampuan untuk menskalakan. Polkadot memberikan gambaran yang sederhana 3sebagai lawan dari pasak satu arah yang pada dasarnya adalah tindakan menghancurkan tokens dalam satu rantai untuk membuat tokens di rantai lain tanpa mekanisme untuk melakukan kebalikannya untuk memulihkan tokens yang asliPOLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 4 infrastruktur meninggalkan banyak kompleksitas yang harus ditangani pada tingkat middleware. Ini adalah keputusan sadar yang dimaksudkan untuk mengurangi risiko pembangunan, sehingga memungkinkan perangkat lunak yang diperlukan untuk dikembangkan dalam rentang waktu singkat dan dengan tingkat keyakinan yang baik atas keamanannya dan ketahanan. 3.1. Filosofi Polkadot. Polkadot seharusnya memberikan landasan yang kuat untuk melakukan hal tersebut membangun gelombang sistem konsensus berikutnya spektrum risiko dari desain matang yang mampu berproduksi pada ide-ide yang baru lahir. Dengan memberikan jaminan yang kuat atas keamanan, isolasi dan komunikasi, Polkadot dapat memungkinkan parachains untuk memilih dari berbagai properti itu sendiri. Memang benar, kami memperkirakan berbagai blockchain eksperimental mendorong sifat-sifat yang dianggap masuk akal hari ini. Kami melihat konservatif, rantai bernilai tinggi serupa dengan Bitcoin atau Z-cash [20] hidup berdampingan dengan nilai yang lebih rendah “rantai tema” (pemasaran seperti itu, sangat menyenangkan) dan jaringan pengujian dengan biaya nol atau mendekati nol. Kami melihat terenkripsi sepenuhnya, “gelap”, rantai konsorsium yang beroperasi berdampingan—dan bahkan menyediakan layanan ke—rantai yang sangat fungsional dan terbuka seperti yang seperti Ethereum. Kami melihat eksperimen baru Rantai berbasis VM seperti wasm bermuatan waktu subjektif rantai digunakan sebagai sarana untuk melakukan outsourcing masalah komputasi yang sulit dari rantai yang lebih matang seperti Ethereum atau rantai mirip Bitcoin yang lebih terbatas. Untuk mengelola peningkatan rantai, Polkadot akan secara inheren mendukung semacam struktur tata kelola, yang mungkin berbasis pada sistem politik stabil yang ada dan memiliki aspek bikameral yang mirip dengan Dewan Kertas Kuning [24]. Sebagai otoritas tertinggi, pemegang saham token yang mendasarinya akan memiliki kendali “referendum”. Untuk mencerminkan pengguna kebutuhan akan pembangunan namun kebutuhan pengembang akan legitimasi, kami berharap akan terbentuknya arah yang masuk akal dua kamar dari komite "pengguna" (terdiri dari terikat validators) dan komite “teknis” dibentuk pengembang klien besar dan pemain ekosistem. Itu badan pemegang token akan mempertahankan legitimasi tertinggi dan membentuk mayoritas super untuk menambah, mengubah parameter, mengganti atau membubarkan struktur ini, sesuatu yang kami jangan meragukan kebutuhan akhir akan hal ini: seperti kata Twain “Pemeran dan popok harus sering diganti, dan untuk itu alasan yang sama”. Meskipun reparameterisasi biasanya mudah dilakukan dalam mekanisme konsensus yang lebih besar, perubahan yang lebih kualitatif seperti penggantian dan augmentasi dapat dilakukan mungkin perlu berupa “keputusan lunak” yang tidak otomatis (mis. melalui kanonikalisasi nomor blok dan hash dari dokumen yang secara resmi menetapkan protokol baru) atau mengharuskan mekanisme konsensus inti untuk memuat a bahasa yang cukup kaya untuk menggambarkan aspek apa pun dari dirinya sendiri yang mungkin perlu diubah. Yang terakhir adalah tujuan akhirnya, Namun, yang pertama lebih mungkin untuk dipilih memfasilitasi jadwal pengembangan yang masuk akal. Prinsip utama Polkadot dan aturan di dalamnya kami mengevaluasi semua keputusan desain adalah: Minimal: Polkadot harus memiliki fungsionalitas sesedikit mungkin. Sederhana: tidak ada kerumitan tambahan yang harus ada dalam protokol dasar daripada yang seharusnya dimuat ke dalam middleware, ditempatkan melalui a parachain atau diperkenalkan dalam optimasi selanjutnya. Umum: tidak ada persyaratan yang tidak perlu, kendala atau pembatasan harus diterapkan pada parachain; Polkadot harus menjadi tempat uji coba untuk pengembangan sistem konsensus yang dapat dioptimalkan melalui membuat model yang sesuai dengan ekstensinya se-abstrak mungkin. Kuat: Polkadot harus memberikan dasar yang mendasar lapisan dasar yang stabil. Selain kesehatan ekonomi, hal ini juga berarti desentralisasi untuk meminimalkan vektor untuk serangan dengan imbalan tinggi.

Participation in Polkadot

There are four basic roles in the upkeep of an Polkadot network: collator, ﬁsherman, nominator and validator. In one possible implementation of Polkadot, the latter role may actually be broken down into two roles: basic validator and availability guarantor; this is discussed in section 6.5.3. Collator Fisherman Validators (this group) Validators (other groups) approves becomes monitors reports bad behaviour to provides block candidates for Nominator Figure 1. The interaction between the four roles of Polkadot. 4.1. Validators. A validator is the highest charge and helps seal new blocks on the Polkadot network. The validator’s role is contingent upon a suﬃciently high bond being deposited, though we allow other bonded parties to nominate one or more validators to act for them and as such some portion of the validator’s bond may not necessarily be owned by the validator itself but rather by these nominators. A validator must run a relay-chain client implementation with high availability and bandwidth. At each block the node must be ready to accept the role of ratifying a new block on a nominated parachain. This process involves receiving, validating and republishing candidate blocks. The nomination is deterministic but virtually unpredictable much in advance. Since the validator cannot reasonably be expected to maintain a fully-synchronised database of all parachains, it is expected that the validator will nominate the task of devising a suggested new parachain block to a third-party, known as a collator. Once all new parachain blocks have been properly ratiﬁed by their appointed validator subgroups, validators must then ratify the relay-chain block itself. This involves updating the state of the transaction queues (essentially moving data from a parachain’s output queue to another parachain’s input queue), processing the transactions of the ratiﬁed relay-chain transaction set and ratifying the ﬁnal block, including the ﬁnal parachain changes.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 5 A validator not fulﬁlling their duty to ﬁnd consensus under the rules of our chosen consensus algorithm is punished. For initial, unintentional failures, this is through withholding the validator’s reward. Repeated failures result in the reduction of their security bond (through burning). Provably malicious actions such as double-signing or conspiring to provide an invalid block result in the loss of the entire bond (which is partially burnt but mostly given to the informant and the honest actors). In some sense, validators are similar to the mining pools of current PoW blockchains. 4.2. Nominators. A nominator is a stake-holding party who contributes to the security bond of a validator. They have no additional role except to place risk capital and as such to signal that they trust a particular validator (or set thereof) to act responsibly in their maintenance of the network. They receive a pro-rata increase or reduction in their deposit according to the bond’s growth to which they contribute. Together with collators, next, nominators are in some sense similar to the miners of the present-day PoW networks. 4.3. Collators. Transaction collators (collators for short) are parties who assist validators in producing valid parachain blocks. They maintain a “full-node” for a particular parachain; meaning that they retain all necessary information to be able to author new blocks and execute transactions in much the same way as miners do on current PoW blockchains. Under normal circumstances, they will collate and execute transactions to create an unsealed block, and provide it, together with a zero-knowledge proof, to one or more validators presently responsible for proposing a parachain block. The precise nature of the relationship between collators, nominators and validators will likely change over time. Initially, we expect collators to work very closely with validators, since there will be only a few (perhaps only one) parachain(s) with little transaction volume. The initial client implementation will include RPCs to allow a parachain collator node to unconditionally supply a (relaychain) validator node with a provably valid parachain block. As the cost of maintaining a synced version of all such parachains increases, we expect to see additional infrastructure in place which will help separate out the duties to independent, economically-motivated, parties. Eventually, we expect to see collator pools who vie to collect the most transaction fees. Such collators may become contracted to serve particular validators over a period of time for an on-going share in the reward proceeds. Alternatively, “freelance” collators may simply create a market oﬀering valid parachain blocks in return for a competitive share of the reward payable immediately. Similarly, decentralised nominator pools would allow multiple bonded participants to coordinate and share the duty of a validator. This ability to pool ensures open participation leading to a more decentralised system. 4.4. Fishermen. Unlike the other two active parties, ﬁshermen are not directly related to the block-authoring process. Rather they are independent “bounty hunters” motivated by a large one-oﬀreward. Precisely due to the existence of ﬁshermen, we expect events of misbehaviour to happen seldom, and when they do only due to the bonded party being careless with secret key security, rather than through malicious intent. The name comes from the expected frequency of reward, the minimal requirements to take part and the eventual reward size. Fishermen get their reward through a timely proof that at least one bonded party acted illegally. Illegal actions include signing two blocks each with the same ratiﬁed parent or, in the case of parachains, helping ratify an invalid block. To prevent over-rewarding or the compromise and illicit use of a session’s secret key, the base reward for providing a single validator’s illegally signed message is minimal. This reward increases asymptotically as more corroborating illegal signatures from other validators are provided implying a genuine attack. The asymptote is set at 66% following our base security assertion that at least two-thirds of the validators act benevolently. Fishermen are somewhat similar to “full nodes” in present-day blockchain systems that the resources needed are relatively small and the commitment of stable uptime and bandwidth is not necessary. Fishermen diﬀer in so much as they must post a small bond. This bond prevents sybil attacks from wasting validators’ time and compute resources. It is immediately withdrawable, probably no more than the equivalent of a few dollars and may lead to reaping a hefty reward from spotting a misbehaving validator.

Partisipasi dalam Polkadot

Ada empat peran dasar dalam pemeliharaan Polkadot jaringan: kolator, nelayan, nominator dan validator. Di satu kemungkinan penerapan Polkadot, peran terakhir sebenarnya dapat dipecah menjadi dua peran: validator dasar dan penjamin ketersediaan; ini dibahas di bagian 6.5.3. Pengumpul Nelayan Validator (grup ini) Validator (kelompok lain) menyetujui menjadi monitor laporan buruk perilaku ke menyediakan blok kandidat untuk Nominator Gambar 1. Interaksi antar empat peran Polkadot. 4.1. Validator. validator adalah tagihan tertinggi dan membantu menyegel blok baru di jaringan Polkadot. Peran validator bergantung pada ikatan yang cukup tinggi dititipkan, meskipun kami mengizinkan pihak lain yang terikat untuk itu mencalonkan satu atau lebih validator untuk bertindak mewakili mereka dan sebagai sebagian dari obligasi validator tersebut belum tentu dimiliki oleh validator itu sendiri melainkan oleh mereka nominasi. validator harus menjalankan implementasi klien rantai relai dengan ketersediaan dan bandwidth tinggi. Di setiap blok node harus siap menerima peran ratifikasi blok baru pada parachain yang dinominasikan. Proses ini melibatkan penerimaan, validasi, dan penerbitan ulang kandidat blok. Pencalonannya bersifat deterministik namun hampir tidak dapat diprediksi sebelumnya. Karena validator tidak bisa cukup diharapkan untuk mempertahankan sinkronisasi penuh database semua parachain, diharapkan validator akan menominasikan tugas merancang usulan baru blok parachain ke pihak ketiga, yang dikenal sebagai collator. Setelah semua blok parachain baru telah diratifikasi dengan benar oleh subkelompok validator yang ditunjuk, validators kemudian harus meratifikasi blok rantai relai itu sendiri. Ini melibatkan memperbarui keadaan antrian transaksi (pada dasarnya memindahkan data dari antrean keluaran parachain ke antrean keluaran lainnya antrian input parachain), memproses transaksi rangkaian transaksi rantai relai yang diratifikasi dan meratifikasinya blok terakhir, termasuk perubahan parachain terakhir.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 5 validator tidak memenuhi tugas mereka untuk menemukan konsensus berdasarkan aturan algoritma konsensus yang kami pilih akan dihukum. Untuk kegagalan awal yang tidak disengaja, ini sudah selesai menahan hadiah validator. Kegagalan yang berulang mengakibatkan berkurangnya jaminan keamanan mereka (melalui pembakaran). Tindakan yang terbukti berbahaya seperti penandatanganan ganda atau bersekongkol untuk memberikan blok yang tidak valid mengakibatkan hilangnya seluruh obligasi (yang sebagian terbakar tetapi sebagian besar diberikan kepada informan dan pelaku yang jujur). Dalam beberapa hal, validator mirip dengan kumpulan penambangan dari PoW saat ini blockchains. 4.2. Nominator. Nominator adalah pihak yang memegang saham yang berkontribusi pada jaminan keamanan validator. Mereka tidak mempunyai peran tambahan kecuali menempatkan modal risiko dan sebagai seperti itu untuk menandakan bahwa mereka memercayai validator tertentu (atau kumpulannya) untuk bertindak secara bertanggung jawab dalam pemeliharaannya jaringan. Mereka menerima kenaikan atau pengurangan pro-rata dalam deposito mereka sesuai dengan pertumbuhan obligasi yang mana mereka berkontribusi. Bersama dengan kolator, selanjutnya ada nominator di beberapa mirip dengan para penambang jaringan PoW saat ini. 4.3. Kolator. Pengumpul transaksi (disingkat pengumpul) adalah pihak-pihak yang membantu validators dalam memproduksi sah blok parachain. Mereka mempertahankan “simpul penuh” untuk parachain tertentu; artinya mereka menyimpan semua yang diperlukan informasi untuk dapat menulis blok baru dan mengeksekusi transaksi dengan cara yang hampir sama seperti yang dilakukan penambang pada PoW blockchains saat ini. Dalam keadaan normal, mereka akan menyusun dan mengeksekusi transaksi untuk membuat yang tidak tersegel memblokir, dan menyediakannya, bersama dengan pengetahuan nol buktinya, kepada satu atau lebih validator yang saat ini menjadi tanggung jawabnya mengusulkan blok parachain. Sifat sebenarnya dari hubungan antara kolator, nominator, dan validator kemungkinan akan berubah seiring berjalannya waktu. waktu. Awalnya, kami mengharapkan kolator bekerja sangat erat dengan validators, karena hanya akan ada sedikit (mungkin hanya satu) parachain dengan volume transaksi kecil. Itu implementasi klien awal akan mencakup RPC untuk memungkinkan a node pengumpul parachain untuk memasok node (relaychain) validator tanpa syarat dengan parachain yang terbukti valid blok. Sebagai biaya pemeliharaan versi yang disinkronkan semua parachain tersebut meningkat, kami memperkirakan akan ada peningkatan tambahan infrastruktur yang ada yang akan membantu memisahkan kewajiban kepada pihak-pihak yang independen dan bermotivasi ekonomi. Pada akhirnya, kami berharap untuk melihat kumpulan kolator yang bersaing mengumpulkan biaya transaksi terbanyak. Kolektor tersebut dapat dikontrak untuk melayani validator tertentu selama jangka waktu tertentu untuk mendapatkan bagian berkelanjutan dari hasil hadiah. Alternatifnya, kolator “freelance” mungkin saja membuat a pasar menawarkan blok parachain yang valid dengan imbalan bagian kompetitif dari hadiah yang dibayarkan segera. Demikian pula, kumpulan nominator yang terdesentralisasi akan memungkinkan banyak nominasi peserta terikat untuk berkoordinasi dan berbagi tugas a validator. Kemampuan untuk menyatukan ini memastikan partisipasi terbuka mengarah pada sistem yang lebih terdesentralisasi. 4.4. Nelayan. Berbeda dengan dua partai aktif lainnya, nelayan tidak mempunyai hubungan langsung dengan pembuat blok proses. Sebaliknya mereka adalah “pemburu hadiah” yang mandiri. termotivasi oleh imbalan satu kali yang besar. Justru karena keberadaan nelayan, kami perkirakan kejadian-kejadian buruk jarang terjadi, dan bila hal itu terjadi hanya karena pihak yang terikat ceroboh dengan pengamanan kunci rahasia, bukan melalui niat jahat. Nama itu datang mulai dari frekuensi imbalan yang diharapkan, persyaratan minimal untuk ikut serta, dan besaran imbalan pada akhirnya. Nelayan mendapatkan imbalannya melalui bukti yang tepat waktu setidaknya satu pihak yang terikat bertindak secara ilegal. Tindakan ilegal termasuk menandatangani dua blok masing-masing dengan induk yang sama yang telah diratifikasi atau, dalam kasus parachains, membantu meratifikasi perjanjian yang tidak sah blok. Untuk mencegah pemberian imbalan yang berlebihan atau kompromi dan penggunaan kunci rahasia suatu sesi secara tidak sah, yang merupakan imbalan dasar memberikan satu pesan validator yang ditandatangani secara ilegal adalah minimal. Hadiah ini meningkat secara asimtotik seiring bertambahnya jumlah menguatkan tanda tangan ilegal dari validator lainnya asalkan menyiratkan serangan asli. Asimtotnya sudah diatur setidaknya sebesar 66% mengikuti pernyataan keamanan dasar kami dua pertiga dari validator bertindak baik hati. Nelayan agak mirip dengan “simpul penuh” di sistem blockchain saat ini yang membutuhkan sumber daya relatif kecil dan komitmen uptime yang stabil dan bandwidth tidak diperlukan. Nelayan berbeda dalam hal ini sebanyak mereka harus mengirimkan obligasi kecil.Ikatan ini mencegah serangan sybil karena membuang-buang waktu dan komputasi validators sumber daya. Ini dapat segera ditarik, mungkin tidak lebih dari setara dengan beberapa dolar dan dapat menyebabkan untuk menuai imbalan besar karena menemukan perilaku buruk validator.

Design Overview

This section is intended to give a brief overview of the system as a whole. A more thorough exploration of the system is given in the section following it. 5.1. Consensus. On the relay-chain, Polkadot achieves low-level consensus over a set of mutually agreed valid blocks through a modern asynchronous Byzantine faulttolerant (BFT) algorithm. The algorithm will be inspired by the simple Tendermint [11] and the substantially more involved HoneyBadgerBFT [14]. The latter provides an eﬃcient and fault-tolerant consensus over an arbitrarily defective network infrastructure, given a set of mostly benign authorities or validators. For a proof-of-authority (PoA) style network, this alone would be suﬃcient, however Polkadot is imagined to be also deployable as a network in a fully open and public situation without any particular organisation or trusted authority required to maintain it. As such we need a means of determining a set of validators and incentivising them to be honest. For this we utilise PoS based selection criteria. 5.2. Proving the Stake. We assume that the network will have some means of measuring how much “stake” any particular account has. For ease of comparison to pre-existing systems, we will call the unit of measurement “tokens”. Unfortunately the term is less than ideal for a number of reasons, not least that being simply a scalar value associated with an account, there is no notion of individuality. We imagine validators be elected, infrequently (at most once per day but perhaps as seldom as once per quarter), through a Nominated Proof-of-Stake (NPoS) scheme. Incentivisation can happen through a pro-rata allocation of

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 6 Relay chain Validator swarm (each coloured by its designated parachain) Transaction (submitted by external actor) Parachain bridge Virtual parachain (e.g. Ethereum) Parachain Parachain queues and I/O Propagated transactions Block candidate submission 2nd order Relay-chain Parachain community Account Inbound transaction Outbound transaction Interchain transactions (managed by validators) Collator Propagated block Fisherman Figure 2. A summary schematic of the Polkadot system. This shows collators collecting and propagating user-transactions, as well as propagating block candidates to ﬁshermen and validators. It also shows how an account can post a transaction which is carried out of its parachain, via the relay-chain and on into another parachain where it can be interpreted as a transaction to an account there. funds coming from a token base expansion (up to 100% per year, though more likely around 10%) together with any transaction fees collected. While monetary base expansion typically leads to inﬂation, since all token owners would have a fair opportunity at participation, no tokenholder would need to suﬀer a reduction in value of their holdings over time provided they were happy to take a role in the consensus mechanism. A particular proportion of tokens would be targeted for the staking process; the eﬀective token base expansion would be adjusted through a market-based mechanism to reach this target. Validators are bonded heavily by their stakes; exiting validators’ bonds remain in place long after the validators’ duties cease (perhaps around 3 months). This long bond-liquidation period allows future misbehaviour to be punished up until the periodic checkpointing of the chain. Misbehaviour results in punishment, such as reduction of reward or, in cases which intentionally compromise the network’s integrity, the validator losing some or all of its stake to other validators, informants or the stakeholders as a whole (through burning). For example, a validator who attempts to ratify both branches of a fork (sometimes known as a “short-range” attack) may be identiﬁed and punished in the latter way. Long-range “nothing-at-stake” attacks4 are circumvented through a simple “checkpoint” latch which prevents a dangerous chain-reorganisation of more than a particular chain-depth. To ensure newly-syncing clients are not able to be fooled onto the wrong chain, regular “hard forks” will occur (of at most the same period of the validators’ bond liquidation) that hard-code recent checkpoint block hashes into clients. This plays well with a further footprint-reducing measure of “ﬁnite chain length” or periodic reseting of the genesis-block. 5.3. Parachains and Collators. Each parachain gets similar security aﬀordances to the relay-chain: the parachains’ headers are sealed within the relay-chain block ensuring no reorganisation, or “double-spending”, is possible following conﬁrmation. This is a similar security guarantee to that oﬀered by Bitcoin’s side-chains and mergemining. Polkadot, however, also provides strong guarantees that the parachains’ state transitions are valid. This happens through the set of validators being cryptographically randomly segmented into subsets; one subset per parachain, the subsets potentially diﬀering per block. This setup generally implies that parachains’ block times will be at least as long as that of the relay-chain. The speciﬁc means of determining the partitioning is outside the scope 4Such an attack is where the adversary forges an entirely new chain of history from the genesis block onwards. Through controlling a relatively insigniﬁcant portion of stake at the oﬀset, they are able to incrementally increase their portion of the stake relative to all other stakeholders as they are the only active participants in their alternative history. Since no intrinsic physical limitation exists on the creation of blocks (unlike PoW where quite real computational energy must be spent), they are able to craft a chain longer than the real chain in a relatively short timespan and potentially make it the longest and best, taking over the canonical state of the network.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 7 of this document but would likely be based either around a commit-reveal framework similar to the RanDAO [19] or use data combined from previous blocks of each parachain under a cryptographically secure hash. Such subsets of validators are required to provide a parachain block candidate which is guaranteed valid (on pain of bond conﬁscation). Validity revolves around two important points; ﬁrstly that it is intrinsically valid—that all state transitions were executed faithfully and that all external data referenced (i.e. transactions) is valid for inclusion. Secondly, that any data which is extrinsic to its candidate, such as those external transactions, has suﬃciently high availability so that participants are able to download it and execute the block manually.5 Validators may provide only a “null” block containing no external “transactions” data, but may run the risk of getting a reduced reward if they do. They work alongside a parachain gossip protocol with collators—individuals who collate transactions into blocks and provide a noninteractive, zero-knowledge proof that the block constitutes a valid child of its parent (and taking any transaction fees for their trouble). It is left to parachain protocols to specify their own means of spam-prevention: there is no fundamental notion of “compute-resource metering” or “transaction fee” imposed by the relay-chain. There is also no direct enforcement on this by the relay-chain protocol (though it is unlikely that the stakeholders would choose to adopt a parachain which didn’t provide a decent mechanism). This is an explicit nod to the possibility of chains unlike Ethereum, e.g. a Bitcoin-like chain which has a much simpler fee model or some other, yet-to-be-proposed spamprevention model. Polkadot’s relay-chain itself will probably exist as an Ethereum-like accounts and state chain, possibly an EVMderivative. Since the relay-chain nodes will be required to do substantial other processing, transaction throughput will be minimised partly through large transaction fees and, should our research models require, a block size limit. 5.4. Interchain Communication. The critical ﬁnal ingredient of Polkadot is interchain communication. Since parachains can have some sort of information channel between them, we allow ourselves to consider Polkadot a scalable multi-chain. In the case of Polkadot, the communication is as simple as can be: transactions executing in a parachain are (according to the logic of that chain) able to eﬀect the dispatch of a transaction into a second parachain or, potentially, the relay-chain. Like external transactions on production blockchains, they are fully asynchronous and there is no intrinsic ability for them to return any kind of information back to its origin. Destination: gets data from prior block’s validators. Account receives post: entry removed from ingress Merkle tree Account sends post: entry placed in egress Merkle tree for destination parachain egress Source: shares data with next block’s validators proof-of-post stored in parachain egress Merkle tree routed reference placed in destination parachain’s ingress Merkle tree ingress Figure 3. A basic schematic showing the main parts of routing for posted transactions (”posts”). To ensure minimal implementation complexity, minimal risk and minimal straight-jacketing of future parachain architectures, these interchain transactions are eﬀectively indistinguishable from standard externallysigned transactions. The transaction has an origin segment, providing the ability to identify a parachain, and an address which may be of arbitrary size. Unlike common current systems such as Bitcoin and Ethereum, interchain transactions do not come with any kind of “payment” of fee associated; any such payment must be managed through negotiation logic on the source and destination parachains. A system such as that proposed for Ethereum’s Serenity release [7] would be a simple means of managing such a cross-chain resource payment, though we assume others may come to the fore in due course. Interchain transactions are resolved using a simple queuing mechanism based around a Merkle tree to ensure ﬁdelity. It is the task of the relay-chain maintainers to move transactions on the output queue of one parachain into the input queue of the destination parachain. The passed transactions get referenced on the relay-chain, however are not relay-chain transactions themselves. To prevent 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 considered “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 status; this way a failed attempt to post a transaction to a stalled destination may be reported synchronously. (Though since no return path exists, if a secondary transaction failed for that reason, it could not be reported back to the original caller and some other means of recovery would have to take place.) 5.5. Polkadot and Ethereum. Due to Ethereum’s Turing completeness, we expect there is ample opportunity for Polkadot and Ethereum to be interoperable with each other, at least within some easily deducible security bounds. In short, we envision that transactions from Polkadot can be signed by validators and then fed into 5Such a task might be shared between validators or could become the designate task of a set of heavily bonded validators known as availability guarantors.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 8 Ethereum where they can be interpreted and enacted by a transaction-forwarding contract. In the other direction, we foresee the usage of specially formatted logs (events) coming from a “break-out contract” to allow a swift veriﬁcation that a particular message should be forwarded. 5.5.1. Polkadot to Ethereum. Through the choice of a BFT consensus mechanism with validators formed from a set of stakeholders determined through an approval voting mechanism, we are able to get a secure consensus with an infrequently changing and modest number of validators. In a system with a total of 144 validators, a block time of 4 seconds and a 900-block ﬁnality (allowing for malicious behaviour such as double-votes to be reported, punished and repaired), the validity of a block can reasonably be considered proven through as little as 97 signatures (twothirds of 144 plus one) and a following 60-minute veriﬁcation period where no challenges are deposited. Ethereum is able to host a “break-in contract” which can maintain the 144 signatories and be controlled by them. Since elliptic curve digital signature (ECDSA) recovery takes only 3,000 gas under the EVM, and since we would likely only want the validation to happen on a super-majority of validators (rather than full unanimity), the base cost of Ethereum conﬁrming that an instruction was properly validated as coming from the Polkadot network would be no more than 300,000 gas—a mere 6% of the total block gas limit at 5.5M. Increasing the number of validators (as would be necessary for dealing with dozens of chains) inevitably increases this cost, however it is broadly expected for Ethereum’s transaction bandwidth to grow over time as the technology matures and infrastructure improves. Together with the fact that not all validators need to be involved (e.g. only the highest staked validators may be called upon for such a task) the limits of this mechanism extend reasonably well. Assuming a daily rotation of such validators (which is fairly conservative—weekly or even monthly may be acceptable), then the cost to the network of maintaining this Ethereum-forwarding bridge would be around 540,000 gas per day or, at present gas prices, $45 per year. A basic transaction forwarded alone over the bridge would cost around $0.11; additional contract computation would cost more, of course. By buﬀering and bundling transactions together, the break-in authorisation costs can easily be shared, reducing the cost per transaction substantially; if 20 transactions were required before forwarding, then the cost for forwarding a basic transaction would fall to around $0.01. One interesting, and cheaper, alternative to this multisignature contract model would be to use threshold signatures in order to achieve the multi-lateral ownership semantics. While threshold signature schemes for ECDSA are computationally expensive, those for other schemes such as Schnorr signatures are very reasonable. Ethereum plans to introduce primitives which would make such schemes cheap to use in the upcoming Metropolis hardfork. If such a means were able to be utilised, the gas costs for forwarding a Polkadot transaction into the Ethereum network would be dramatically reduced to a near zero overhead over and above the basic costs for validating the signature and executing the underlying transaction. In this model, Polkadot’s validator nodes would have to do little other than sign messages. To get the transactions actually routed onto the Ethereum network, we assume either validators themselves would also reside on the Ethereum network or, more likely, that small bounties be oﬀered to the ﬁrst actor who forwards the message on to the network (the bounty could trivially be paid to the transaction originator). 5.5.2. Ethereum to Polkadot. Getting transactions to be forwarded from Ethereum to Polkadot uses the simple notion of logs. When an Ethereum contract wishes to dispatch a transaction to a particular parachain of Polkadot, it need simply call into a special “break-out contract”. The break-out contract would take any payment that may be required and issue a logging instruction so that its existence may be proven through a Merkle proof and an assertion that the corresponding block’s header is valid and canonical. Of the latter two conditions, validity is perhaps the most straightforward to prove. In principle, the only requirement is for each Polkadot node needing the proof (i.e. appointed validator nodes) to be running a fully synchronised instance of a standard Ethereum node. Unfortunately, this is itself a rather heavy dependency. A more lightweight method would be to use a simple proof that the header was evaluated correctly through supplying only the part of Ethereum’s state trie needed to properly execute the transactions in the block and check that the logs (contained in the block receipt) are valid. Such “SPV-like”6 proofs may yet require a substantial amount of information; conveniently, they would typically not be needed at all: a bond system inside Polkadot would allow bonded third-parties to submit headers at the risk of losing their bond should some other third-party (such as a “ﬁsherman”, see 6.2.3) provide a proof that the header is invalid (speciﬁcally that the state root or receipt roots were impostors). On a non-ﬁnalising PoW network like Ethereum, the canonicality is impossible to proof conclusively. To address this, applications that attempt to rely on any kind of chain-dependent cause-eﬀect wait for a number of “conﬁrmations”, or until the dependent transaction is at some particular depth within the chain. On Ethereum, this depth varies from 1 block for the least valuable transactions with no known network issues to 1200 blocks as was the case during the initial Frontier release for exchanges. On the stable “Homestead” network, this ﬁgure sits at 120 blocks for most exchanges, and we would likely take a similar parameter. So we can imagine our Polkadot-side Ethereuminterface to have some simple functions: to be able to accept a new header from the Ethereum network and validate the PoW, to be able to accept some proof that a particular log was emitted by the Ethereum-side breakout contract for a header of suﬃcient depth (and forward the corresponding message within Polkadot) and ﬁnally to be able to accept proofs that a previously accepted but not-yet-enacted header contains an invalid receipt root. To actually get the Ethereum header data itself (and any SPV proofs or validity/canonicality refutations) into the Polkadot network, an incentivisation for forwarding 6SPV refers to Simpliﬁed Payment Veriﬁcation in Bitcoin and describes a method for clients to verify transactions while keeping only a copy of all blocks headers of the longest PoW chain.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 9 data is needed. This could be as simple as a payment (funded from fees collected on the Ethereum side) paid to anyone able to forward a useful block whose header is valid. Validators would be called upon to retain information relating to the last few thousand blocks in order to be able to manage forks, either through some protocolintrinsic means or through a contract maintained on the relay chain. 5.6. Polkadot and Bitcoin. Bitcoin interoperation presents an interesting challenge for Polkadot: a so-called “two-way peg” would be a useful piece of infrastructure to have on the side of both networks. However, due to the limitations of Bitcoin, providing such a peg securely is a non-trivial undertaking. Delivering a transaction from Bitcoin to Polkadot can in principle be done with a process similar to that for Ethereum; a “break-out address” controlled in some way by the Polkadot validators could receive transferred tokens (and data sent alongside them). SPV proofs could be provided by incentivised oracles and, together with a conﬁrmation period, a bounty given for identifying non-canonical blocks implying the transaction has been “double-spent”. Any tokens then owned in the “break-out address” would then, in principle, be controlled by those same validators for later dispersal. The problem however is how the deposits can be securely controlled from a rotating validator set. Unlike Ethereum which is able to make arbitrary decisions based upon combinations of signatures, Bitcoin is substantially more limited, with most clients accepting only multisignature transactions with a maximum of 3 parties. Extending this to 36, or indeed thousands as might ultimately be desired, is impossible under the current protocol. One option is to alter the Bitcoin protocol to enable such functionality, however so-called “hard forks” in the Bitcoin world are diﬃcult to arrange judging by recent attempts. One possibility is the use of threshold signatures, cryptographic schemes to allow a singly identiﬁable public key to be eﬀectively controlled by multiple secret “parts”, some or all of which must be utilised to create a valid signature. Unfortunately, threshold signatures compatible with Bitcoin’s ECDSA are computationally expensive to create and of polynomial complexity. Other schemes such a Schnorr signatures provide far lower costs, however the timeline on which they may be introduced into the Bitcoin protocol is uncertain. Since the ultimate security of the deposits rests with a number of bonded validators, one other option is to reduce the multi-signature key-holders to only a heavily bonded subset of the total validators such that threshold signatures become feasible (or, at worst, Bitcoin’s native multi-signature is possible). This of course reduces the total amount of bonds that could be deducted in reparations should the validators behave illegally, however this is a graceful degradation, simply setting an upper limit of the amount of funds that can securely run between the two networks (or indeed, on the % losses should an attack from the validators succeed). As such we believe it not unrealistic to place a reasonably secure Bitcoin interoperability “virtual parachain” between the two networks, though nonetheless a substantial eﬀort with an uncertain timeline and quite possibly requiring the cooperation of the stakeholders within that network.

Ikhtisar Desain

Bagian ini dimaksudkan untuk memberikan gambaran singkat tentang sistem secara keseluruhan. Eksplorasi yang lebih menyeluruh terhadap sistem diberikan pada bagian berikutnya. 5.1. Konsensus. Pada rantai relai, Polkadot tercapai konsensus tingkat rendah atas seperangkat valid yang disepakati bersama blok melalui algoritma toleransi kesalahan Bizantium asinkron (BFT) modern. Algoritmanya akan terinspirasi dengan Tendermint sederhana [11] dan masih banyak lagi melibatkan HoneyBadgerBFT [14]. Yang terakhir menyediakan konsensus yang efisien dan toleran terhadap kesalahan atas keputusan yang sewenang-wenang infrastruktur jaringan yang rusak, mengingat sebagian besar otoritas yang baik atau validators. Untuk jaringan bergaya proof-of-authority (PoA), ini saja akan mencukupi, namun Polkadot dibayangkan juga dapat digunakan sebagai jaringan secara terbuka dan publik situasi tanpa organisasi tertentu atau terpercaya wewenang yang diperlukan untuk memeliharanya. Oleh karena itu kita memerlukan a cara untuk menentukan serangkaian validator dan pemberian insentif mereka jujur. Untuk ini kami menggunakan seleksi berbasis PoS kriteria. 5.2. Membuktikan Taruhannya. Kami berasumsi bahwa jaringan akan memiliki beberapa cara untuk mengukur berapa banyak “taruhan” dimiliki oleh akun tertentu. Untuk kemudahan perbandingan dengan sistem yang sudah ada sebelumnya, kita sebut satuan pengukuran “tokens”. Sayangnya istilah tersebut kurang ideal untuk a sejumlah alasan, paling tidak karena hanya skalar nilai yang terkait dengan akun, tidak ada gagasan tentangnya individualitas. Kami membayangkan validators terpilih, jarang sekali (paling banyak sekali per hari tetapi mungkin jarang sekali per kuartal), melalui skema Nominated Proof-of-Stake (NPoS). Insentivisasi dapat terjadi melalui alokasi pro-rataPOLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 6 Relai rantai Kawanan validator (masing-masing diwarnai menurut warnanya parachain yang ditunjuk) Transaksi (dikirim oleh aktor eksternal) Parachain jembatan Parachain virtual (misalnya Ethereum) Parachain Parachain antrian dan I/O Transaksi yang disebarkan Blokir pengajuan kandidat pesanan ke-2 Rantai relai Komunitas parachain Akun Transaksi masuk Transaksi keluar Transaksi antar rantai (dikelola oleh validators) Pengumpul Blok yang disebarkan Nelayan Gambar 2. Skema ringkasan sistem Polkadot. Hal ini menunjukkan kolektor mengumpulkan dan menyebarkan transaksi pengguna, serta menyebarkan kandidat blok ke nelayan dan validators. Itu juga menunjukkan bagaimana sebuah akun dapat memposting transaksi yang dilakukan dari parachainnya, melalui rantai relai dan masuk ke parachain lain yang bisa diartikan sebagai transaksi ke akun disana. dana yang berasal dari perluasan basis token (hingga 100% per tahun, meskipun kemungkinan besar sekitar 10%) bersama dengan biaya transaksi apa pun yang dikumpulkan. Meskipun ekspansi basis moneter biasanya menyebabkan inflasi, karena semua pemilik token akan memiliki kesempatan yang adil untuk berpartisipasi, tidak ada pemegang token yang perlu mengalami pengurangan nilai kepemilikan dari waktu ke waktu asalkan mereka senang untuk mengambil a peran dalam mekanisme konsensus. Proporsi tertentu dari tokens akan ditargetkan untuk proses staking; itu perluasan basis token yang efektif akan disesuaikan mekanisme berbasis pasar untuk mencapai target ini. Validator sangat terikat dengan taruhannya; keluar Obligasi validators tetap berlaku lama setelah tugas validators dihentikan (mungkin sekitar 3 bulan). Selama ini periode likuidasi obligasi memungkinkan terjadinya perilaku buruk di masa depan dihukum sampai pos pemeriksaan berkala rantai. Perilaku buruk menghasilkan hukuman, seperti pengurangan imbalan atau, dalam kasus yang dengan sengaja membahayakan integritas jaringan, validator kehilangan sebagian atau seluruhnya kepentingan kepada validator lain, informan atau pemangku kepentingan secara keseluruhan (melalui pembakaran). Misalnya, validator yang mencoba untuk meratifikasi kedua cabang percabangan (terkadang dikenal sebagai serangan “jarak pendek”) dapat diidentifikasi dan dihukum dengan cara yang terakhir. Serangan jangka panjang “tidak ada yang dipertaruhkan”4 dapat dielakkan melalui kaitan “pos pemeriksaan” sederhana yang mencegah terjadinya reorganisasi berantai yang berbahaya selama lebih dari satu tahun. kedalaman rantai tertentu. Untuk memastikan klien yang baru disinkronkan tidak bisa tertipu ke rantai yang salah, biasa “hard fork” akan terjadi (paling lama pada periode yang sama). validators (likuidasi obligasi) yang memblok pos pemeriksaan terbaru dengan kode keras hashes ke klien. Hal ini cocok dengan ukuran “panjang rantai terbatas” yang dapat mengurangi jejak lebih lanjut pengaturan ulang blok genesis secara berkala. 5.3. Parachain dan Collator. Setiap parachain mendapat perlengkapan keamanan serupa dengan rantai relai: itu header parachain disegel di dalam blok rantai relai memastikan tidak ada reorganisasi, atau “pembelanjaan ganda”, yang mungkin terjadi setelah konfirmasi. Ini adalah jaminan keamanan serupa dengan yang ditawarkan oleh rantai samping dan penggabungan Bitcoin. Namun, Polkadot juga memberikan jaminan kuat bahwa transisi status parachain adalah valid. Ini terjadi melalui himpunan validator yang disegmentasikan secara kriptografis secara acak menjadi himpunan bagian; satu subset per parachain, subset berpotensi berbeda per blok. Ini pengaturan umumnya menyiratkan bahwa waktu blok parachain akan demikian setidaknya sepanjang rantai relai. Yang spesifik cara menentukan partisi berada di luar cakupan 4Serangan seperti itu adalah saat musuh membentuk rantai sejarah yang benar-benar baru mulai dari blok genesis dan seterusnya. Melalui pengendalian a dengan porsi saham yang relatif kecil pada saat offset, mereka dapat secara bertahap meningkatkan porsi saham mereka dibandingkan dengan semua saham lainnya. pemangku kepentingan karena mereka adalah satu-satunya peserta aktif dalam sejarah alternatif mereka. Karena tidak ada batasan fisik yang hakiki dalam penciptaan blok (tidak seperti PoW di mana energi komputasi yang cukup nyata harus dikeluarkan), mereka mampu membuat rantai yang lebih panjang dari rantai sebenarnya dalam waktu singkat. rentang waktu yang relatif singkat dan berpotensi menjadikannya yang terlama dan terbaik, mengambil alih status kanonik jaringan.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 7 dokumen ini tetapi kemungkinan besar akan didasarkan pada hal tersebut kerangka komit-pengungkapan yang mirip dengan RanDAO [19] atau menggunakan data yang digabungkan dari blok sebelumnya dari setiap parachain di bawah hash yang aman secara kriptografis. Subkumpulan validators tersebut diperlukan untuk menyediakan a kandidat blok parachain yang dijamin valid (on rasa sakit karena penyitaan obligasi). Validitas berkisar pada dua poin penting; pertama bahwa hal itu secara intrinsik valid—itu semua transisi negara dilaksanakan dengan setia dan itu saja data eksternal yang direferensikan (yaitu transaksi) valid untuk dimasukkan. Kedua, data apa pun yang bersifat ekstrinsik kandidat, seperti transaksi eksternal tersebut, memiliki ketersediaan yang cukup tinggi sehingga peserta dapat melakukannya unduh dan jalankan blok secara manual.5 Validator mungkin hanya menyediakan blok “null” yang tidak berisi data “transaksi” eksternal, namun berisiko mendapatkan pengurangan reward jika mereka memberikannya. Mereka bekerja berdampingan protokol gosip parachain dengan kolator—individu yang menyusun transaksi ke dalam blok dan memberikan bukti non-interaktif dan tanpa pengetahuan bahwa blok tersebut merupakan anak sah dari induknya (dan melakukan transaksi apa pun biaya untuk masalah mereka). Terserah pada protokol parachain untuk menentukan protokolnya sendiri sarana pencegahan spam: tidak ada gagasan mendasar tentang “pengukuran sumber daya komputasi” atau “biaya transaksi” dikenakan oleh rantai relay. Juga tidak ada penegakan langsung terhadap hal ini melalui protokol rantai relai (meskipun demikian kecil kemungkinannya para pemangku kepentingan akan memilih untuk mengadopsinya parachain yang tidak menyediakan mekanisme yang layak). Ini adalah anggukan eksplisit terhadap kemungkinan rantai yang tidak sama Ethereum, mis. rantai mirip Bitcoin yang memiliki model biaya yang lebih sederhana atau model pencegahan spam lainnya yang belum diusulkan. Rantai relai Polkadot itu sendiri mungkin akan ada sebagai Akun dan rantai negara yang mirip Ethereum, kemungkinan merupakan turunan EVM. Karena node rantai relai akan diperlukan melakukan pemrosesan substansial lainnya, throughput transaksi akan diminimalkan sebagian melalui biaya transaksi yang besar dan, jika model penelitian kami memerlukannya, batas ukuran blok. 5.4. Komunikasi Antar Rantai. Bahan terakhir yang penting dari Polkadot adalah komunikasi antar rantai. Sejak parachain dapat memiliki semacam saluran informasi di antara mereka, kami membiarkan diri kami mempertimbangkan Polkadot a multi-rantai yang dapat diskalakan. Dalam kasus Polkadot, komunikasinya sesederhana mungkin: transaksi dijalankan dalam a parachain (menurut logika rantai itu) mampu mempengaruhi pengiriman transaksi ke parachain kedua atau, mungkin, rantai relai. Seperti transaksi eksternal pada produksi blockchains, keduanya sepenuhnya asinkron dan tidak ada kemampuan intrinsik bagi mereka untuk mengembalikannya jenis informasi kembali ke asalnya. Tujuan: mendapat data dari sebelumnya validators blok. Akun menerima kiriman: entri dihapus dari masuknya Merkle tree Akun mengirimkan kiriman: entri ditempatkan di jalan keluar Merkle tree untuk tujuan parachain jalan keluar Sumber: saham data dengan blok berikutnya validatordtk bukti kiriman disimpan di parachain jalan keluar Merkle pohon referensi yang diarahkan ditempatkan di parachain tujuan masuknya Merkle tree masuknya Gambar 3. Tampilan skema dasar bagian utama perutean untuk diposting transaksi (“postingan”). Untuk memastikan kompleksitas implementasi minimal, minimal risiko dan minimal jaket lurus dari masa depan arsitektur parachain, transaksi antar rantai ini secara efektif tidak dapat dibedakan dari transaksi standar yang ditandatangani secara eksternal. Transaksi memiliki segmen asal, memberikan kemampuan untuk mengidentifikasi parachain, dan alamat yang ukurannya mungkin berubah-ubah. Tidak seperti sistem umum saat ini seperti Bitcoin dan Ethereum, transaksi antar rantai tidak disertai dengan “pembayaran” biaya apa pun; pembayaran semacam itu harus dikelola melalui logika negosiasi pada parachain sumber dan tujuan. Sebuah sistem seperti yang diusulkan Rilisan Serenity Ethereum [7] akan menjadi cara yang sederhana Namun, cara mengelola pembayaran sumber daya lintas rantai tersebut kami berasumsi orang lain mungkin akan muncul pada waktunya. Transaksi antar rantai diselesaikan dengan menggunakan cara sederhana mekanisme antrian berdasarkan Merkle tree untuk memastikan kesetiaan. Ini adalah tugas pengelola rantai relai untuk melakukannya memindahkan transaksi pada antrian keluaran satu parachain ke dalam antrian input parachain tujuan. Itu transaksi yang diteruskan direferensikan pada rantai relai, namun tidak reltransaksi ay-chain itu sendiri. Untuk mencegah parachain mengirim spam ke parachain lain transaksi, agar suatu transaksi dapat dikirim, diperlukan agar antrian masukan tujuan tidak terlalu besar waktu akhir blok sebelumnya. Jika masukan antrian terlalu besar setelah pemrosesan blok, maka dianggap “jenuh” dan tidak ada transaksi yang dapat dialihkan itu dalam blok berikutnya sampai dikurangi kembali di bawah batas. Antrian ini dikelola pada rantai relai memungkinkan parachain untuk menentukan saturasi satu sama lain status; dengan cara ini upaya yang gagal untuk memposting transaksi ke tujuan yang terhenti dapat dilaporkan secara serempak. (Meskipun karena tidak ada jalur pengembalian, jika transaksi sekunder gagal karena alasan tersebut, transaksi tersebut tidak dapat dilaporkan kembali ke penelepon asli dan beberapa cara pemulihan lainnya harus terjadi.) 5.5. Polkadot dan Ethereum. Karena kelengkapan Turing Ethereum, kami berharap ada banyak peluang bagi Polkadot dan Ethereum untuk dapat dioperasikan dengan satu sama lain, setidaknya dalam batasan keamanan yang mudah dideduksi. Singkatnya, kami membayangkan transaksi dari Polkadot dapat ditandatangani oleh validators dan kemudian dimasukkan ke dalam 5Tugas seperti itu mungkin dibagi antara validators atau bisa menjadi tugas khusus dari sekumpulan validators yang dikenal sebagai penjamin ketersediaan.

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 8 Ethereum dimana hal tersebut dapat ditafsirkan dan diberlakukan oleh kontrak penerusan transaksi. Di arah lain, kami memperkirakan penggunaan log (peristiwa) yang diformat khusus berasal dari “kontrak terobosan” untuk memungkinkan verifikasi cepat bahwa pesan tertentu harus diteruskan. 5.5.1. Polkadot hingga Ethereum. Melalui pilihan a BFT mekanisme konsensus dengan validators terbentuk dari a sekelompok pemangku kepentingan yang ditentukan melalui pemungutan suara persetujuan mekanisme, kita bisa mendapatkan konsensus yang aman dengan jarang berubah dan jumlah validators sedikit. Dalam sistem dengan total 144 validators, waktu blok adalah 4 detik dan finalitas 900 blok (memungkinkan tindakan jahat perilaku seperti suara ganda untuk dilaporkan, dihukum dan diperbaiki), validitas suatu blok dapat dibenarkan dianggap terbukti melalui sedikitnya 97 tanda tangan (dua pertiga dari 144 ditambah satu) dan periode verifikasi 60 menit berikutnya dimana tidak ada keberatan yang diajukan. Ethereum dapat menjadi tuan rumah “kontrak pembobolan” yang dapat mempertahankan 144 penandatangan dan dikendalikan oleh mereka. Karena pemulihan tanda tangan digital kurva elips (ECDSA) hanya membutuhkan 3.000 gas di bawah EVM, dan sejak itu kami mungkin hanya ingin validasi terjadi pada a mayoritas super validators (bukan suara bulat penuh), biaya dasar Ethereum yang mengonfirmasi bahwa sebuah instruksi divalidasi dengan benar karena berasal dari jaringan Polkadot tidak lebih dari 300.000 gas—hanya 6% dari batas total blok gas pada 5,5M. Meningkatkan jumlah validator (sebagaimana diperlukan untuk menangani lusinan rantai) pasti akan meningkatkan biaya ini bandwidth transaksi Ethereum diperkirakan akan bertambah seiring waktu seiring dengan semakin matangnya teknologi dan infrastruktur membaik. Bersama dengan fakta bahwa tidak semua validator perlu dilibatkan (misalnya hanya yang tertinggi validators yang dipertaruhkan dapat dipanggil untuk tugas seperti itu) tersebut batasan mekanisme ini meluas dengan cukup baik. Dengan asumsi rotasi harian sebesar validators (yaitu cukup konservatif—mingguan atau bahkan bulanan mungkin dapat diterima), sehingga menimbulkan biaya pemeliharaan jaringan jembatan penerusan Ethereum ini akan berjumlah sekitar 540.000 gas per hari atau, pada harga gas saat ini, $45 per tahun. Transaksi dasar yang diteruskan sendiri melalui jembatan akan dikenakan biaya sekitar $0,11; perhitungan kontrak tambahan akan memakan biaya tentu saja lebih banyak lagi. Dengan buffering dan bundling transaksi bersama-sama, biaya otorisasi pembobolan dapat dengan mudah dikurangkan dibagikan, mengurangi biaya per transaksi secara signifikan; jika 20 transaksi diperlukan sebelum meneruskan, maka biaya untuk meneruskan transaksi dasar akan turun menjadi sekitar $0,01. Salah satu alternatif yang menarik dan lebih murah terhadap model kontrak multitanda tangan ini adalah dengan menggunakan tanda tangan ambang batas untuk mencapai semantik kepemilikan multilateral. Sedangkan skema tanda tangan ambang batas untuk ECDSA mahal secara komputasi, dibandingkan skema lainnya seperti tanda tangan Schnorr sangat masuk akal. Ethereum berencana untuk memperkenalkan primitif yang akan membuat seperti itu skema murah untuk digunakan di hardfork Metropolis yang akan datang. Jika cara seperti itu dapat dimanfaatkan, biaya gasnya akan mahal untuk meneruskan transaksi Polkadot ke Ethereum jaringan akan berkurang drastis hingga mendekati nol overhead melebihi biaya dasar untuk memvalidasi menandatangani dan melaksanakan transaksi yang mendasarinya. Dalam model ini, node validator Polkadot akan memiliki untuk melakukan apa pun selain menandatangani pesan. Agar transaksi benar-benar dirutekan ke jaringan Ethereum, kami asumsikan validator itu sendiri juga akan berada jaringan Ethereum atau, lebih mungkin, hadiah kecil itu ditawarkan kepada aktor pertama yang meneruskan pesan tersebut ke jaringan (hadiahnya bisa dengan mudah dibayarkan ke pencetus transaksi). 5.5.2. Ethereum hingga Polkadot. Menjadikan transaksi menjadi diteruskan dari Ethereum ke Polkadot menggunakan pengertian sederhana tentang log. Ketika kontrak Ethereum ingin mengirimkan transaksi ke parachain tertentu Polkadot, mereka hanya perlu mengadakan “kontrak break-out” khusus. Kontrak break-out akan menerima pembayaran berapa pun diperlukan dan mengeluarkan instruksi logging sehingga keberadaannya dapat dibuktikan melalui bukti Merkle dan pernyataan bahwa header blok terkait adalah valid dan kanonik. Dari dua syarat terakhir, validitas mungkin adalah yang utama paling mudah untuk dibuktikan. Pada prinsipnya, satu-satunya persyaratan adalahuntuk setiap node Polkadot yang memerlukan bukti (yaitu menunjuk validator node) untuk menjalankan instance node Ethereum standar yang sepenuhnya tersinkronisasi. Sayangnya, hal ini sendiri merupakan ketergantungan yang cukup berat. Lebih lanjut metode ringannya adalah dengan menggunakan bukti sederhana bahwa header dievaluasi dengan benar melalui penyediaan hanya bagian dari percobaan status Ethereum perlu dijalankan dengan benar transaksi di blok dan periksa apakah log (yang terdapat dalam tanda terima blok) valid. Seperti “SPV”6 pembuktian mungkin masih memerlukan sejumlah besar informasi; nyamannya, mereka biasanya tidak diperlukan semua: sistem ikatan di dalam Polkadot akan memungkinkan ikatan pihak ketiga untuk mengirimkan header dengan risiko kehilangannya jaminan jika pihak ketiga lainnya (seperti “nelayan”, lihat 6.2.3) memberikan bukti bahwa header tersebut tidak valid (khususnya akar negara atau akar penerimaan adalah penipu). Pada jaringan PoW yang belum terselesaikan seperti Ethereum, kanonikalitas tidak mungkin dibuktikan secara meyakinkan. Untuk mengatasi hal ini, aplikasi-aplikasi yang mencoba mengandalkan apapun jenisnya sebab-akibat yang bergantung pada rantai menunggu sejumlah “konfirmasi”, atau hingga transaksi dependen mencapai titik tertentu. kedalaman tertentu dalam rantai. Pada Ethereum, ini kedalamannya bervariasi dari 1 blok untuk transaksi yang paling tidak berharga tanpa masalah jaringan yang diketahui hingga 1200 blok seperti sebelumnya kasus ini selama rilis awal Frontier untuk pertukaran. Pada jaringan “Homestead” yang stabil, angka ini berada pada 120 blok untuk sebagian besar bursa, dan kemungkinan besar kami akan mengambilnya parameter serupa. Jadi kita bisa bayangkan milik kita Polkadot-sisi Ethereumantarmuka memiliki beberapa fungsi sederhana: untuk dapat menerima header baru dari jaringan Ethereum dan memvalidasi PoW, untuk dapat menerima beberapa bukti bahwa a log tertentu dikeluarkan oleh kontrak breakout sisi Ethereum untuk header dengan kedalaman yang cukup (dan meneruskan pesan terkait dalam Polkadot) dan terakhir untuk dapat menerima bukti-bukti yang sebelumnya diterima tetapi header yang belum diberlakukan berisi akar tanda terima yang tidak valid. Untuk benar-benar mendapatkan data header Ethereum itu sendiri (dan bukti SPV atau sanggahan validitas/kanonikalitas) ke dalam jaringan Polkadot, sebuah insentif untuk penerusan 6SPV mengacu pada Verifikasi Pembayaran yang Disederhanakan di Bitcoin dan menjelaskan metode bagi klien untuk memverifikasi transaksi sambil hanya menyimpan salinan semua header blok dari rantai PoW terpanjang.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 9 data diperlukan. Ini bisa sesederhana pembayaran (didanai dari biaya yang dikumpulkan di sisi Ethereum) dibayarkan kepada siapa pun yang dapat meneruskan blok berguna yang headernya sah. Validator akan diminta untuk menyimpan informasi terkait beberapa ribu blok terakhir dapat mengelola fork, baik melalui beberapa cara protokol intrinsik atau melalui kontrak yang dipertahankan di rantai relai. 5.6. Polkadot dan Bitcoin. Bitcoin interoperasi menghadirkan tantangan menarik untuk Polkadot: yang disebut “pasak dua arah” akan menjadi infrastruktur yang berguna untuk dimiliki di sisi kedua jaringan. Namun karena batasan Bitcoin, menyediakan pasak seperti itu dengan aman adalah sebuah usaha yang tidak sepele. Mengirimkan transaksi dari Bitcoin hingga Polkadot pada prinsipnya dapat dilakukan dengan proses serupa dengan Ethereum; sebuah “alamat pelarian” dikendalikan dalam beberapa cara oleh Polkadot validators bisa menerima tokens yang ditransfer (dan data dikirim bersamanya). Bukti SPV dapat diberikan dengan oracles yang diberi insentif dan, bersama dengan periode konfirmasi, hadiah yang diberikan mengidentifikasi blok non-kanonik yang menyiratkan transaksi telah “dibelanjakan ganda”. Setiap token yang kemudian dimiliki di “alamat pelarian” pada prinsipnya akan dikontrol oleh validator yang sama untuk penyebaran selanjutnya. Namun masalahnya adalah bagaimana deposit dapat dikontrol dengan aman dari set validator yang berputar. Berbeda dengan Ethereum yang mampu mengambil keputusan sewenang-wenang berdasarkan berdasarkan kombinasi tanda tangan, Bitcoin secara substansial lebih terbatas, sebagian besar klien hanya menerima transaksi multisignature dengan maksimal 3 pihak. Memperluasnya menjadi 36, atau bahkan ribuan seperti yang diinginkan, tidak mungkin dilakukan berdasarkan protokol saat ini. Salah satu opsinya adalah mengubah protokol Bitcoin menjadi aktif fungsionalitas seperti itu, namun apa yang disebut “hard fork” di dalamnya Bitcoin dunia sulit untuk diatur penilaiannya berdasarkan upaya baru-baru ini. Salah satu kemungkinannya adalah penggunaan tanda tangan ambang batas, skema kriptografi untuk memungkinkan publik yang dapat diidentifikasi secara tunggal kunci untuk dikontrol secara efektif oleh banyak “bagian” rahasia, sebagian atau seluruhnya harus dimanfaatkan untuk membuat tanda tangan yang sah. Sayangnya, tanda tangan ambang batas kompatibel dengan ECDSA Bitcoin secara komputasi mahal buat dan kompleksitas polinomial. Skema lain seperti itu Namun, tanda tangan Schnorr memberikan biaya yang jauh lebih rendah garis waktu di mana mereka dapat diperkenalkan ke Bitcoin protokol tidak pasti. Karena keamanan tertinggi dari simpanan ada pada sejumlah validator yang terikat, salah satu opsi lainnya adalah melakukannya mengurangi pemegang kunci multi-tanda tangan menjadi hanya banyak subset terikat dari total validators sedemikian rupa sehingga ambang batas tersebut tanda tangan menjadi layak (atau, paling buruk, tanda tangan asli Bitcoin multi-tanda tangan dimungkinkan). Hal ini tentu saja mengurangi jumlah total obligasi yang dapat dikurangi sebagai ganti rugi jika validator berperilaku ilegal, namun hal ini adalah degradasi yang baik, hanya dengan menetapkan batas atas jumlah dana yang dapat berjalan dengan aman di antara dua jaringan (atau bahkan, pada % kerugian jika terjadi serangan dari validators berhasil). Oleh karena itu, kami yakin tidak realistis untuk menempatkan “parachain virtual” interoperabilitas Bitcoin yang cukup aman antara kedua jaringan, meskipun tetap merupakan upaya besar dengan jangka waktu yang tidak pasti dan sangat mungkin terjadi memerlukan kerja sama dari para pemangku kepentingan di dalamnya jaringan.

Protocol in Detail

The protocol can be roughly broken down into three parts: the consensus mechanism, the parachain interface and interchain transaction routing. 6.1. Relay-chain Operation. The relay-chain will likely be a chain broadly similar to Ethereum in that it is state-based with the state mapping address to account information, mainly balances and (to prevent replays) a transaction counter. Placing accounts here fulﬁls one purpose: to provide accounting for which identity possesses what amount of stake in the system.7 There will be notable diﬀerences, though: • Contracts cannot be deployed through transactions; following from the desire to avoid application functionality on the relay-chain, it will not support public deployment of contracts. • Compute resource usage (“gas”) is not accounted; since the only functions available for public usage will be ﬁxed, the rationale behind gas accounting no longer holds. As such, a ﬂat fee will apply in all cases, allowing for more performance from any dynamic code execution that may need to be done and a simpler transaction format. • Special functionality is supported for listed contracts that allows for auto-execution and networkmessage outputs. In the event that the relay-chain has a VM and it be based around the EVM, it would have a number of modiﬁcations to ensure maximal simplicity. It would likely have a number of built-in contracts (similar to those at addresses 1-4 in Ethereum) to allow for platform-speciﬁc duties to be managed including a consensus contract, a validator contract and a parachain contract. If not the EVM, then a WebAssembly [2] (wasm) backend is the most likely alternative; in this case the overall structure would be similar, but there would be no need for the built-in contracts with Wasm being a viable target for general purpose languages rather than the immature and limited languages for the EVM. Other likely deviations from the present Ethereum protocol are quite possible, for example a simpliﬁcation of the transaction-receipt format allowing for the parallel execution of non-conﬂicting transactions within the same block, as proposed for the Serenity series of changes. It is possible, though unlikely, that a Serenity-like “pure” chain be deployed as the relay-chain, allowing for a particular contract to manage things like the staking token balances rather than making that a fundamental part of the chain’s protocol. At present, we feel it is unlikely this will oﬀer a suﬃciently great protocol simpliﬁcation to be worth the additional complexity and uncertainty involved in developing it. 7As a means of representing the amount a given holder is responsible for the overall security of the system, these stake accounts will inevitably encode some economic value. However, it should be understood that since there is no intention that such values be used in any way for the purpose of exchanging for real-world goods and services, it should be accordingly noted that the tokens not be likened to currency and as such the relay-chain retain its nihilistic philosophy regarding applications.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 10 There are a number of small pieces of functionality required for administrating the consensus mechanism, validator set, validation mechanism and parachains. These could be implemented together under a monolithic protocol. However, for reasons of auguring modularity, we describe these as “contracts” of the relay-chain. This should be taken to mean that they are objects (in the sense of object-orientated programming) managed by the relaychain’s consensus mechanism, but not necessarily that they are deﬁned as programs in EVM-like opcodes, nor even that they be individually addressable through the account-system. 6.2. Staking Contract. This contract maintains the validator set. It manages: • which accounts are currently validators; • which are available to become validators at short notice; • which accounts have placed stake nominating to a validator; • properties of each including staking volume, acceptable payout-rates and addresses and shortterm (session) identities. It allows an account to register a desire to become a bonded validator (along with its requirements), to nominate to some identity, and for preexisting bonded validators to register their desire to exit this status. It also includes the machinery itself for the validation and canonicalisation mechanism. 6.2.1. Stake-token Liquidity. It is generally desirable to have as much of the total staking tokens as possible to be staked within the network maintenance operations since this directly ties the network security to the overall “market capitalisation” of the staking token. This can easily be incentivised through inﬂating the currency and handing out the proceeds to those who participate as validators. However, to do so presents a problem: if the token is locked in the Staking Contract under punishment of reduction, how can a substantial portion remain suﬃciently liquid in order to allow price discovery? One answer to this is allowing a straight-forward derivative contract, securing fungible tokens on an underlying staked token. This is diﬃcult to arrange in a trustfree manner. Furthermore, these derivative tokens cannot be treated equally for the same reason that diﬀerent Eurozone government’s bonds are not fungible: there is a chance of the underlying asset failing and becoming worthless. With Eurozone governments, there could be a default. With validator-staked tokens, the validator may act maliciously and be punished. Keeping with our tenets, we elect for the simplest solution: not all tokens be staked. This would mean that some proportion (perhaps 20%) of tokens will forcibly remain liquid. Though this is imperfect from a security perspective, it is unlikely to make a fundamental diﬀerence in the security of the network; 80% of the reparations possible from bond-conﬁscations would still be able to be made compared to the “perfect case” of 100% staking. The ratio between staked and liquid tokens can be targeted fairly simply through a reverse auction mechanism. Essentially, token holders interested in being a validator would each post an oﬀer to the staking contract stating the minimum payout-rate that they would require to take part. At the beginning of each session (sessions would happen regularly, perhaps as often as once per hour) the validator slots would be ﬁlled according to each would-be validator’s stake and payout rate. One possible algorithm for this would be to take those with the lowest oﬀers who represent a stake no higher than the total stake targeted divided by the number of slots and no lower than a lowerbound of half that amount. If the slots cannot be ﬁlled, the lower bound could be repeatedly reduced by some factor in order to satisfy. 6.2.2. Nominating. It is possible to trustlessly nominate ones staking tokens to an active validator, giving them the responsibility of validators duties. Nominating works through an approval-voting system. Each would-be nominator is able to post an instruction to the staking contract expressing one or more validator identities under whose responsibility they are prepared to entrust their bond. Each session, nominators’ bonds are dispersed to be represented by one or more validators. The dispersal algorithm optimises for a set of validators of equivalent total bonds. Nominators’ bonds become under the eﬀective responsibility of the validator and gain interest or suﬀer a punishment-reduction accordingly. 6.2.3. Bond Conﬁscation/Burning. Certain validator behaviour results in a punitive reduction of their bond. If the bond is reduced below the allowable minimum, the session is prematurely ended and another started. A nonexhaustive list of punishable validator misbehaviour includes: • Being part of a parachain group unable to provide consensus over the validity of a parachain block; • actively signing for the validity of an invalid parachain block; • inability to supply egress payloads previously voted as available; • inactivity during the consensus process; • validating relay-chain blocks on competing forks. Some cases of misbehaviour threaten the network’s integrity (such as signing invalid parachain blocks and validating multiple sides of a fork) and as such result in effective exile through the total reduction of the bond. In other, less serious cases (e.g. inactivity in the consensus process) or cases where blame cannot be precisely allotted (being part of an ineﬀective group), a small portion of the bond may instead be ﬁned. In the latter case, this works well with sub-group churn to ensure that malicious nodes suﬀer substantially more loss than the collaterallydamaged benevolent nodes. In some cases (e.g. multi-fork validation and invalid sub-block signing) validators cannot themselves easily detect each others’ misbehaviour since constant veriﬁcation of each parachain block would be too arduous a task. Here it is necessary to enlist the support of parties external to the validation process to verify and report such misbehaviour. The parties get a reward for reporting such activity; their term, “ﬁshermen” stems from the unlikeliness of such a reward. Since these cases are typically very serious, we envision that any rewards can easily be paid from the conﬁscated bond. In general we prefer to balance burning (i.e. reduction to nothing) with reallocation, rather than attempting wholesale reallocation. This has the eﬀect of

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 11 increasing the overall value of the token, compensating the network in general to some degree rather than the speciﬁc party involved in discovery. This is mainly as a safety mechanism: the large amounts involved could lead to extreme and acute behaviour incentivisation were they all bestowed on a single target. In general, it is important that the reward is suﬃciently large to make veriﬁcation worthwhile for the network, yet not so large as to oﬀset the costs of fronting a well-ﬁnanced, well-orchestrated ”industrial-level” criminal hacking attack on some unlucky validator to force misbehaviour. In this way, the amount claimed should generally be no greater than the direct bond of the errant validator, lest a perverse incentive arise of misbehaving and reporting oneself for the bounty. This can be combated either explicitly through a minimum direct bond requirement for being a validator or implicitly by educating nominators that validators with little bonds deposited have no great incentive to behave well. 6.3. Parachain Registry. Each parachain is deﬁned in this registry. It is a relatively simple database-like construct and holds both static and dynamic information on each chain. Static information includes the chain index (a simple integer), along with the validation protocol identity, a means of distinguishing between the diﬀerent classes of parachain so that the correct validation algorithm can be run by validators consigned to putting forward a valid candidate. An initial proof-of-concept would focus on placing the new validation algorithms into clients themselves, effectively requiring a hard fork of the protocol each time an additional class of chain were added. Ultimately, though, it may be possible to specify the validation algorithm in a way both rigorous and eﬃcient enough that clients are able to eﬀectively work with new parachains without a hard-fork. One possible avenue to this would be to specify the parachain validation algorithm in a well-established, natively-compiled, platform-neutral language such as WebAssembly. Additional research is necessary to determine whether this is truly feasible, however if so, it could bring with it the tremendous advantage of banishing hard-forks for good. Dynamic information includes aspects of the transaction routing system that must have global agreement such as the parachain’s ingress queue (described in section 6.6). The registry is able to have parachains added only through full referendum voting; this could be managed internally but would more likely be placed in an external referendum contract in order to facilitate re-usage under more general governance components. The parameters to voting requirements (e.g. any quorum required, majority required) for registration of additional chains and other, less formal system upgrades will be set out in a “master constitution” but are likely to follow a fairly traditional path, at least initially. The precise formulation is out of scope for the present work, but e.g. a two thirds supermajority to pass with more than one third of total system stake voting positively may be a sensible starting point. Additional operations include the suspension and removal of parachains. Suspension would hopefully never happen, however it is designed to be a safeguard least there be some intractable problem in a parachain’s validation system. The most obvious instance where it might be needed is a consensus-critical diﬀerence between implementations leading validators to be unable to agree on validity or blocks. Validators would be encouraged to use multiple client implementations in order that they are able to spot such a problem prior to bond conﬁscation. Since suspension is an emergency measure, it would be under the auspices of the dynamic validator-voting rather than a referendum. Re-instating would be possible both from the validators or a referendum. The removal of parachains altogether would come only after a referendum and with which would be required a substantial grace period to allow an orderly transition to either a standalone chain or to become part of some other consensus-system. The grace period would likely be of the order of months and is likely to be set out on a perchain basis in the parachain registry in order that diﬀerent parachains can enjoy diﬀerent grace periods according to their need. 6.4. Sealing Relay Blocks. Sealing refers, in essence, to the process of canonicalisation; that is, a basic data transform which maps the original into something fundamentally singular and meaningful. Under a PoW chain, sealing is eﬀectively a synonym for mining. In our case, it involves the collection of signed statements from validators over the validity, availability and canonicality of a particular relay-chain block and the parachain blocks that it represents. The mechanics of the underlying BFT consensus algorithm is out of scope for the present work. We will instead describe it using a primitive which assumes a consensus-creating state-machine. Ultimately we expect to be inspired by a number of promising BFT consensus algorithms in the core; Tangaora [9] (a BFT variant of Raft [16]), Tendermint [11] and HoneyBadgerBFT [14]. The algorithm will have to reach an agreement on multiple parachains in parallel, thus diﬀering from the usual blockchain consensus mechanisms. We assume that once consensus is reached, we are able to record the consensus in an irrefutable proof which can be provided by any of the participants to it. We also assume that misbehaviour within the protocol can be generally reduced to a small group containing misbehaving participants to minimise the collateral damage when dealing out punishment.8 The proof, which takes the form of our signed statements, is placed in the relay-chain block’s header together with certain other ﬁelds not least the relay-chain’s statetrie root and transaction-trie root. The sealing process takes place under a single consensus-generating mechanism addressing both the relay-chain’s block and the parachains’ blocks which make up part of the relay’s content: parachains are not separately “committed” by their sub-groups and then collated later. This results in a more complex process for the relaychain, but allows us to complete the entire system’s consensus in a single stage, minimising latency and allowing for quite complex data-availability requirements which are helpful for the routing process below. 8Existing PoS-based BFT consensus schemes such as Tendermint BFT and the original Slasher fulﬁll these assertions.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 12 The state of each participant’s consensus machine may be modelled as a simple (2-dimensional) table. Each participant (validator) has a set of information, in the form of signed-statements (“votes”) from other participants, regarding each parachain block candidate as well the relaychain block candidate. The set of information is two pieces of data: Availability: does this validator have egress transaction-post information from this block so they are able to properly validate parachain candidates on the following block? They may vote either 1(known) or 0 (not yet known). Once they vote 1, they are committed to voting similarly for the rest of this process. Later votes that do not respect this are grounds for punishment. Validity: is the parachain block valid and is all externally-referenced data (e.g. transactions) available? This is only relevant for validators assigned to the parachain on which they are voting. They may vote either 1 (valid), -1 (invalid) or 0 (not yet known). Once they vote non-zero, they are committed to voting this way for the rest of the process. Later votes that do not respect this are grounds for punishment. All validators must submit votes; votes may be resubmitted, qualiﬁed by the rules above. The progression of consensus may be modelled as multiple standard BFT consensus algorithms over each parachain happening in parallel. Since these are potentially thwarted by a relatively small minority of malicious actors being concentrated in a single parachain group, the overall consensus exists to establish a backstop, limiting the worst-case scenario from deadlock to merely one or more void parachain blocks (and a round of punishment for those responsible). The basic rules for validity of the individual blocks (that allow the total set of validators as a whole to come to consensus on it becoming the unique parachain candidate to be referenced from the canonical relay): • must have at least two thirds of its validators voting positively and none voting negatively; • must have over one third validators voting positively to the availability of egress queue information. If there is at least one positive and at least one negative vote on validity, an exceptional condition is created and the whole set of validators must vote to determine if there are malicious parties or if there is an accidental fork. Aside from valid and invalid, a third kind of votes are allowed, equivalent to voting for both, meaning that the node has conﬂicting opinions. This could be due to the node’s owner running multiple implementations which do not agree, indicating a possible ambiguity in the protocol. After all votes are counted from the full validator set, if the losing opinion has at least some small proportion (to be parameterised; at most half, perhaps signiﬁcantly less) of the votes of the winning opinion, then it is assumed to be an accidental parachain fork and the parachain is automatically suspended from the consensus process. Otherwise, we assume it is a malicious act and punish the minority who were voting for the dissenting opinion. The conclusion is a set of signatures demonstrating canonicality. The relay-chain block may then be sealed and the process of sealing the next block begun. 6.5. Improvements for Sealing Relay Blocks. While this sealing method gives strong guarantees over the system’s operation, it does not scale out particularly well since every parachain’s key information must have its availability guaranteed by over one-third of all validators. This means that every validator’s responsibility footprint grows as more chains are added. While data availability within open consensus networks is essentially an unsolved problem, there are ways of mitigating the overhead placed on validator nodes. One simple solution is to realise that while validators must shoulder the responsibility for data availability, they need not actually store, communicate or replicate the data themselves. Secondary data silos, possibly related to (or even the very same) collators who compile this data, may manage the task of guaranteeing availability with the validators providing a portion of their interest/income in payment. However, while this might buy some intermediate scalability, it still doesn’t help the underlying problem; since adding more chains will in general require additional validators, the ongoing network resource consumption (particularly in terms of bandwidth) grows with the square of the chains, an untenable property in the long-term. Ultimately, we are likely to keep bashing our heads against the fundamental limitation which states that for a consensus network to be considered available safe, the ongoing bandwidth requirements are of the order of total validators times total input information. This is due to the inability of an untrusted network to properly distribute the task of data storage across many nodes, which sits apart from the eminently distributable task of processing. 6.5.1. Introducing Latency. One means of softening this rule is to relax the notion of immediacy. By requiring 33%+1 validators voting for availability only eventually, and not immediately, we can better utilise exponential data propagation and help even out peaks in datainterchange. A reasonable equality (though unproven) may be: (1) latency = participants × chains Under the current model, the size of the system scales with the number of chains to ensure that processing is distributed; since each chain will require at least one validator and we ﬁx the availability attestation to a constant proportion of validators, then participants similarly grows with the number of chains. We end up with: (2) latency = size2 Meaning that as the system grows, the bandwidth required and latency until availability is known across the network, which might also be characterised as the number of blocks before ﬁnality, increases with its square. This is a substantial growth factor and may turn out to be a notable road blocker and force us into “non-ﬂat” paradigms such as composing several “Polkadotes” into a hierarchy for multi-level routing of posts through a tree of relaychains.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 13 6.5.2. Public Participation. One more possible direction is to enlist public participation in the process through a micro-complaints system. Similar to the ﬁshermen, there could be external parties to police the validators who claim availability. Their task is to ﬁnd one who appears unable to demonstrate such availability. In doing so they can lodge a micro-complaint to other validators. PoW or a staked bond may be used to mitigate the sybil attack which would render the system largely useless. 6.5.3. Availability Guarantors. A ﬁnal route would be to nominate a second set of bonded validators as “availability guarantors”. These would be bonded just as with the normal validators, and may even be taken from the same set (though if so, they would be chosen over a long-term period, at least per session). Unlike normal validators, they would not switch between parachains but rather would form a single group to attest to the availability of all important interchain data. This has the advantage of relaxing the equivalence between participants and chains. Essentially, chains can grow (along with the original chain validator set), whereas the participants, and speciﬁcally those taking part in dataavailability testament, can remain at the least sub-linear and quite possibly constant. 6.5.4. Collator Preferences. One important aspect of this system is to ensure that there is a healthy selection of collators creating the blocks in any given parachain. If a single collator dominated a parachain then some attacks become more feasible since the likelihood of the lack of availability of external data would be less obvious. One option is to artiﬁcially weight parachain blocks in a pseudo-random mechanism in order to favour a wide variety of collators. In the ﬁrst instance, we would require as part of the consensus mechanism that validators favour parachain block candidates determined to be “heavier”. Similarly, we must incentivise validators to attempt to suggest the weightiest block they can ﬁnd—this could be done through making a portion of their reward proportional to the weight of their candidate. To ensure that collators are given a reasonable fair chance of their candidate being chosen as the winning candidate in consensus, we make the speciﬁc weight of a parachain block candidate determinate on a random function connected with each collator. For example, taking the XOR distance measure between the collator’s address and some cryptographically-secure pseudorandom number determined close to the point of the block being created (a notional “winning ticket”). This eﬀectively gives each collator (or, more speciﬁcally, each collator’s address) a random chance of their candidate block “winning” over all others. To mitigate the sybil attack of a single collator “mining” an address close to the winning ticket and thus being a favourite each block, we would add some inertia to a collator’s address. This may be as simple as requiring them to have a baseline amount of funds in the address. A more elegant approach would be to weight the proximity to the winning ticket with the amount of funds parked at the address in question. While modelling has yet to be done, it is quite possible that this mechanism enables even very small stakeholders to contribute as a collator. 6.5.5. Overweight Blocks. If a validator set is compromised, they may create and propose a block which though valid, takes an inordinate amount of time to execute and validate. This is a problem since a validator group could reasonably form a block which takes a very long time to execute unless some particular piece of information is already known allowing a short cut, e.g. factoring a large prime. If a single collator knew that information, then they would have a clear advantage in getting their own candidates accepted as long as the others were busy processing the old block. We call these blocks overweight. Protection against validators submitting and validating these blocks largely falls under the same guise as for invalid blocks, though with an additional caveat: Since the time taken to execute a block (and thus its status as overweight) is subjective, the ﬁnal outcome of a vote on misbehaviour will fall into essentially three camps. One possibility is that the block is deﬁnitely not overweight— in this case more than two-thirds declare that they could execute the block within some limit (e.g. 50% of the total time allowed between blocks). Another is that the block is deﬁnitely overweight—this would be if more than two-thirds declare that they could not execute the block within said limit. One ﬁnal possibility is a fairly equal split of opinion between validators. In this case, we may choose to do some proportionate punishment. To ensure validators can predict when they may be proposing an overweight block, it may be sensible to require them to publish information on their own performance for each block. Over a suﬃcient period of time, this should allow them to proﬁle their processing speed relative to the peers that would be judging them. 6.5.6. Collator Insurance. One issue remains for validators: unlike with PoW networks, to check a collator’s block for validity, they must actually execute the transactions in it. Malicious collators can feed invalid or overweight blocks to validators causing them grief (wasting their resources) and exacting a potentially substantial opportunity cost. To mitigate this, we propose a simple strategy on the part of validators. Firstly, parachain block candidates sent to validators must be signed from a relay chain account with funds; if they are not, then the validator should drop it immediately. Secondly, such candidates should be ordered in priority by a combination (e.g. multiplication) of the amount of funds in the account up to some cap, the number of previous blocks that the collator has successfully proposed in the past (not to mention any previous punishments), and the proximity factor to the winning ticket as discussed previously. The cap should be the same as the punitive damages paid to the validator in the case of them sending an invalid block. To disincentivise collators from sending invalid or overweight block candidates to validators, any validator may place in the next block a transaction including the oﬀending block alleging misbehaviour with the eﬀect of transferring some or all of the funds in the misbehaving collator’s account to the aggrieved validator. This type of transaction front-runs any others to ensure the collator cannot remove the funds prior to the punishment. The amount of funds transferred as damages is a dynamic parameter yet

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 14 to be modelled but will likely be a proportion of the validator block reward to reﬂect the level of grief caused. To prevent malicious validators arbitrarily conﬁscating collators’ funds, the collator may appeal the validator’s decision with a jury of randomly chosen validators in return for placing a small deposit. If they ﬁnd in the validator’s favour, the deposit is consumed by them. If not, the deposit is returned and the validator is ﬁned (since the validator is in a much more vaulted position, the ﬁne will likely be rather hefty). 6.6. Interchain Transaction Routing. Interchain transaction routing is one of the essential maintenance tasks of the relay-chain and its validators. This is the logic which governs how a posted transaction (often shortened to simply “post”) gets from being a desired output from one source parachain to being a non-negotiable input of another destination parachain without any trust requirements. We choose the wording above carefully; notably we don’t require there to have been a transaction in the source parachain to have explicitly sanctioned this post. The only constraints we place upon our model is that parachains must provide, packaged as a part of their overall block processing output, the posts which are the result of the block’s execution. These posts are structured as several FIFO queues; the number of lists is known as the routing base and may be around 16. Notably, this number represents the quantity of parachains we can support without having to resort to multi-phase routing. Initially, Polkadot will support this kind of direct routing, however we will outline one possible multi-phase routing process (“hyper-routing”) as a means of scaling out well past the initial set of parachains. We assume that all participants know the subgroupings for next two blocks n, n + 1. In summary, the routing system follows these stages: • CollatorS: Contact members of V alidators[n][S] • CollatorS: FOR EACH subgroup s: ensure at least 1 member of V alidators[n][s] in contact • CollatorS: FOR EACH subgroup s: assume egress[n −1][s][S] is available (all incoming post data to ‘S‘ from last block) • CollatorS: Compose block candidate b for S: (b.header, b.ext, b.proof, b.receipt, b.egress) • CollatorS: Send proof information proof[S] = (b.header, b.ext, b.proof, b.receipt) to V alidators[n][S] • CollatorS: Ensure external transaction data b.ext is made available to other collators and validators • CollatorS: FOR EACH subgroup s: Send egress information egress[n][S][s] = (b.header, b.receipt, b.egress[s]) to the receiving sub-group’s members of next block V alidators[n + 1][s] • V alidatorV : Pre-connect all same-set members for next block: let N = Chain[n + 1][V ]; connect all validators v such that Chain[n + 1][v] = N • V alidatorV : Collate all data ingress for this block: FOR EACH subgroup s: Retrieve egress[n −1][s][Chain[n][V ]], get from other validators v such that Chain[n][v] = Chain[n][V ]. Possibly going via randomly selected other validators for proof of attempt. • V alidatorV : Accept candidate proofs for this block proof[Chain[n][V ]]. Vote block validity • V alidatorV : Accept candidate egress data for next block: FOR EACH subgroup s, accept egress[n][s][N]. Vote block egress availability; republish among interested validators v such that Chain[n + 1][v] = Chain[n + 1][V ]. • V alidatorV : UNTIL CONSENSUS Where: egress[n][from][to] is the current egress queue information for posts going from parachain ‘from‘, to parachain ‘to‘ in block number ‘n‘. CollatorS is a collator for parachain S. V alidators[n][s] is the set of validators for parachain s at block number n. Conversely, Chain[n][v] is the parachain to which validator v is assigned on block number n. block.egress[to] is the egress queue of posts from some parachain block block whose destination parachain is to. Since collators collect (transaction) fees based upon their blocks becoming canonical they are incentivised to ensure that for each next-block destination, the subgroup’s members are informed of the egress queue from the present block. Validators are incentivised only to form a consensus on a (parachain) block, as such they care little about which collator’s block ultimately becomes canonical. In principle, a validator could form an allegiance with a collator and conspire to reduce the chances of other collators’ blocks becoming canonical, however this is both diﬃcult to arrange due to the random selection of validators for parachains and could be defended against with a reduction in fees payable for parachain blocks which hold up the consensus process. 6.6.1. External Data Availability. Ensuring a parachain’s external data is actually available is a perennial issue with decentralised systems aiming to distribute workload across the network. At the heart of the issue is the availability problem which states that since it is neither possible to make a non-interactive proof of availability nor any sort of proof of non-availability, for a BFT system to properly validate any transition whose correctness relies upon the availability of some external data, the maximum number of acceptably Byzantine nodes, plus one, of the system must attest to the data being available. For a system to scale out properly, like Polkadot, this invites a problem: if a constant proportion of validators must attest to the availability of the data, and assuming that validators will want to actually store the data before asserting it is available, then how do we avoid the problem of the bandwidth/storage requirements increasing with the system size (and therefore number of validators)? One possible answer would be to have a separate set of validators (availability guarantors), whose order grows sublinearly with the size of Polkadot as a whole. This is described in 6.5.3. We also have a secondary trick. As a group, collators have an intrinsic incentive to ensure that all data is available for their chosen parachain since without it they are unable to author further blocks from which they can collect transaction fees. Collators also form a group, membership of which is varied (due to the random nature of parachain validator groups) non-trivial to enter and easy

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 15 to prove. Recent collators (perhaps of the last few thousand blocks) are therefore allowed to issue challenges to the availability of external data for a particular parachain block to validators for a small bond. Validators must contact those from the apparently offending validator sub-group who testiﬁed and either acquire and return the data to the collator or escalate the matter by testifying to the lack of availability (direct refusal to provide the data counts as a bond-conﬁscating offence, therefore the misbehaving validator will likely just drop the connection) and contacting additional validators to run the same test. In the latter case, the collator’s bond is returned. Once a quorum of validators who can make such nonavailability testimonials is reached, they are released, the misbehaving sub-group is punished, and the block reverted. 6.6.2. Posts Routing. Each parachain header includes an egress-trie-root; this is the root of a trie containing the routing-base bins, each bin being a concatenated list of egress posts. Merkle proofs may be provided across parachain validators to prove that a particular parachain’s block had a particular egress queue for a particular destination parachain. At the beginning of processing a parachain block, each other parachain’s egress queue bound for said block is merged into our block’s ingress queue. We assume strong, probably CSPR9, sub-block ordering to achieve a deterministic operation that oﬀers no favouritism between any parachain block pairing. Collators calculate the new queue and drain the egress queues according to the parachain’s logic. The contents of the ingress queue is written explicitly into the parachain block. This has two main purposes: ﬁrstly, it means that the parachain can be trustlessly synchronised in isolation from the other parachains. Secondly, it simpliﬁes the data logistics should the entire ingress queue not be able to be processed in a single block; validators and collators are able to process following blocks without having to source the queue’s data specially. If the parachain’s ingress queue is above a threshold amount at the end of block processing, then it is marked saturated on the relay-chain and no further messages may be delivered to it until it is cleared. Merkle proofs are used to demonstrate ﬁdelity of the collator’s operation in the parachain block’s proof. 6.6.3. Critique. One minor ﬂaw relating to this basic mechanism is the post-bomb attack. This is where all parachains send the maximum amount of posts possible to a particular parachain. While this ties up the target’s ingress queue at once, no damage is done over and above a standard transaction DoS attack. Operating normally, with a set of well-synchronised and non-malicious collators and validators, for N parachains, N × M total validators and L collators per parachain, we can break down the total data pathways per block to: Validator: M −1+L+L: M −1 for the other validators in the parachain set, L for each collator providing a candidate parachain block and a second L for each collator of the next block requiring the egress payloads of the previous block. (The latter is actually more like worst-case operation since it is likely that collators will share such data.) Collator: M +kN: M for a connection to each relevant parachain block validator, kN for seeding the egress payloads to some subset of each parachain validator group for the next block (and possibly some favoured collator(s)). As such, the data path ways per node grow linearly with the overall complexity of the system. While this is reasonable, as the system scales into hundreds or thousands of parachains, some communication latency may be absorbed in exchange for a lower complexity growth rate. In this case, a multi-phase routing algorithm may be used in order to reduce the number of instantaneous pathways at a cost of introducing storage buﬀers and latency. 6.6.4. Hyper-cube Routing. Hyper-cube routing is a mechanism which can mostly be build as an extension to the basic routing mechanism described above. Essentially, rather than growing the node connectivity with the number of parachains and sub-group nodes, we grow only with the logarithm of parachains. Posts may transit between several parachains’ queues on their way to ﬁnal delivery. Routing itself is deterministic and simple. We begin by limiting the number of bins in the ingress/egress queues; rather than being the total number of parachains, they are the routing-base (b) . This will be ﬁxed as the number of parachains changes, with the routing-exponent (e) instead being raised. Under this model, our message volume grows with O(be), with the pathways remaining constant and the latency (or number of blocks required for delivery) with O(e). Our model of routing is a hypercube of e dimensions, with each side of the cube having b possible locations. Each block, we route messages along a single axis. We alternate the axis in a round-robin fashion, thus guaranteeing worst-case delivery time of e blocks. As part of the parachain processing, foreign-bound messages found in the ingress queue are routed immediately to the appropriate egress queue’s bin, given the current block number (and thus routing dimension). This process necessitates additional data transfer for each hop on the delivery route, however this is a problem itself which may be mitigated by using some alternative means of data payload delivery and including only a reference, rather than the full payload of the post in the post-trie. An example of such a hyper-cube routing for a system with 4 parachains, b = 2 and e = 2 might be: Phase 0, on each message M: • sub0: if $M_{\text{dest}} \in \{2, 3\}$ then sendTo(2) else keep • sub1: if $M_{\text{dest}} \in \{2, 3\}$ then sendTo(3) else keep • sub2: if $M_{\text{dest}} \in \{0, 1\}$ then sendTo(0) else keep • sub3: if $M_{\text{dest}} \in \{0, 1\}$ then sendTo(1) else keep Phase 1, on each message M: • sub0: if $M_{\text{dest}} \in \{1, 3\}$ then sendTo(1) else keep • sub1: if $M_{\text{dest}} \in \{0, 2\}$ then sendTo(0) else keep • sub2: if $M_{\text{dest}} \in \{1, 3\}$ then sendTo(3) else keep • sub3: if $M_{\text{dest}} \in \{0, 2\}$ then sendTo(2) else keep The two dimensions here are easy to see as the ﬁrst two bits of the destination index; for the ﬁrst block, the higher-order bit alone is used. The second block deals with the low-order bit. Once both happen (in arbitrary order) then the post will be routed. 9cryptographically secure pseudo-random

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 16 6.6.5. Maximising Serendipity. One alteration of the basic proposal would see a ﬁxed total of c2 −c validators, with c−1 validators in each sub-group. Each block, rather than there being an unstructured repartitioning of validators among parachains, instead for each parachain sub-group, each validator would be assigned to a unique and diﬀerent parachain sub-group on the following block. This would lead to the invariant that between any two blocks, for any two pairings of parachain, there exists two validators who have swapped parachain responsibilities. While this cannot be used to gain absolute guarantees on availability (a single validator will occasionally drop oﬄine, even if benevolent), it can nonetheless optimise the general case. This approach is not without complications. The addition of a parachain would also necessitate a reorganisation of the validator set. Furthermore the number of validators, being tied to the square of the number of parachains, would start initially very small and eventually grow far too fast, becoming untenable after around 50 parachains. None of these are fundamental problems. In the ﬁrst case, reorganisation of validator sets is something that must be done regularly anyway. Regarding the size of the validator set, when too small, multiple validators may be assigned to the same parachain, applying an integer factor to the overall total of validators. A multi-phase routing mechanism such as Hypercube Routing, discussed in 6.6.4 would alleviate the requirement for large number of validators when there is a large number of chains. 6.7. Parachain Validation. A validator’s main purpose is to testify, as a well-bonded actor, that a parachain’s block is valid, including but not limited to any state transition, any external transactions included, the execution of any waiting posts in the ingress queue and the ﬁnal state of the egress queue. The process itself is fairly simple. Once the validator sealed the previous block they are free to begin working to provide a candidate parachain block candidate for the next round of consensus. Initially, the validator ﬁnds a parachain block candidate through a parachain collator (described next) or one of its co-validators. The parachain block candidate data includes the block’s header, the previous block’s header, any external input data included (for Ethereum and Bitcoin, such data would be referred to as transactions, however in principle they may include arbitrary data structures for arbitrary purposes), egress queue data and internal data to prove state-transition validity (for Ethereum this would be the various state/storage trie nodes required to execute each transaction). Experimental evidence shows this full dataset for a recent Ethereum block to be at the most a few hundred KiB. Simultaneously, if not yet done, the validator will be attempting to retrieve information pertaining to the previous block’s transition, initially from the previous block’s validators and later from all validators signing for the availability of the data. Once the validator has received such a candidate block, they then validate it locally. The validation process is contained within the parachain class’s validator module, a consensus-sensitive software module that must be written for any implementation of Polkadot (though in principle a library with a C ABI could enable a single library to be shared between implementations with the appropriate reduction in safety coming from having only a single “reference” implementation). The process takes the previous block’s header and veriﬁes its identity through the recently agreed relay-chain block in which its hash should be recorded. Once the parent header’s validity is ascertained, the speciﬁc parachain class’s validation function may be called. This is a single function accepting a number of data ﬁelds (roughly those given previously) and returning a simple Boolean proclaiming the validity of the block. Most such validation functions will ﬁrst check the header-ﬁelds which are able to be derived directly from the parent block (e.g. parent hash, number). Following this, they will populate any internal data structures as necessary in order to process transactions and/or posts. For an Ethereum-like chain this amounts to populating a trie database with the nodes that will be needed for the full execution of transactions. Other chain types may have other preparatory mechanisms. Once done, the ingress posts and external transactions (or whatever the external data represents) will be enacted, balanced according to chain’s speciﬁcation. (A sensible default might be to require all ingress posts be processed before external transactions be serviced, however this should be for the parachain’s logic to decide.) Through this enactment, a series of egress posts will be created and it will be veriﬁed that these do indeed match the collator’s candidate. Finally, the properly populated header will be checked against the candidate’s header. With a fully validated candidate block, the validator can then vote for the hash of its header and send all requisite validation information to the co-validators in its subgroup. 6.7.1. Parachain Collators. Parachain collators are unbonded operators who fulﬁll much of the task of miners on the present-day blockchain networks. They are speciﬁc to a particular parachain. In order to operate they must maintain both the relay-chain and the fully synchronised parachain. The precise meaning of “fully synchronised” will depend on the class of parachain, though will always include the present state of the parachain’s ingress queue. In Ethereum’s case it also involves at least maintaining a Merkle-tree database of the last few blocks, but might also include various other data structures including Bloom ﬁlters for account existence, familial information, logging outputs and reverse lookup tables for block number. In addition to keeping the two chains synchronised, it must also “ﬁsh” for transactions by maintaining a transaction queue and accepting properly validated transactions from the public network. With the queue and chain, it is able to create new candidate blocks for the validators chosen at each block (whose identity is known since the relaychain is synchronised) and submit them, together with the various ancillary information such as proof-of-validity, via the peer network. For its trouble, it collects all fees relating to the transactions it includes. Various economics ﬂoat around this arrangement. In a heavily competitive market where there is a surplus of collators, it is possible that the transaction fees be shared with the parachain validators to incentivise the inclusion of a particular collator’s block. Similarly,

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 17 some collators may even raise the required fees that need to be paid in order to make the block more attractive to validators. In this case, a natural market should form with transactions paying higher fees skipping the queue and having faster inclusion in the chain. 6.8. Networking. Networking on traditional blockchains like Ethereum and Bitcoin has rather simple requirements. All transactions and blocks are broadcast in a simple undirected gossip. Synchronisation is more involved, especially with Ethereum but in reality this logic was contained in the peer strategy rather than the protocol itself which resolved around a few request and answer message types. While Ethereum made progress on current protocol offerings with the devp2p protocol, which allowed for many subprotocols to be multiplexed over a single peer connection and thus have the same peer overlay support many p2p protocols simultaneously, the Ethereum portion of the protocol still remained relatively simple and the p2p protocol as a while remains unﬁnished with important functionality missing such as QoS support. Sadly, a desire to create a more ubiquitous “web 3” protocol largely failed, with the only projects using it being those explicitly funded from the Ethereum crowd-sale. The requirements for Polkadot are rather more substantial. Rather then a wholly uniform network, Polkadot has several types of participants each with diﬀerent requirements over their peer makeup and several network “avenues” whose participants will tend to converse about particular data. This means a substantially more structured network overlay—and a protocol supporting that— will likely be necessary. Furthermore, extensibility to facilitate future additions such as new kinds of “chain” may themselves require a novel overlay structure. While an in-depth discussion of how the networking protocol may look is outside of the scope of this document, some requirements analysis is reasonable. We can roughly break down our network participants into two sets (relay-chain, parachains) each of three subsets. We can also state that each of the parachain participants are only interested in conversing between themselves as opposed to participants in other parachains: • Relay-chain participants: • Validators: P, split into subsets P[s] for each parachain • Availability Guarantors: A (this may be represented by Validators in the basic form of the protocol) • Relay-chain clients: M (note members of each parachain set will also tend to be members of M) • Parachain participants: • Parachain Collators: C[0], C[1], . . . • Parachain Fishermen: F[0], F[1], . . . • Parachain clients: S[0], S[1], . . . • Parachain light-clients: L[0], L[1], . . . In general we name particular classes of communication will tend to take place between members of these sets: • P | A <-> P | A: The full set of validators/guarantors must be well-connected to achieve consensus. • P[s] <-> C[s] | P[s]: Each validator as a member of a given parachain group will tend to gossip with other such members as well as the collators of that parachain to discover and share block candidates. • A <-> P[s] | C | A: Each availability guarantor will need to collect consensus-sensitive cross-chain data from the validators assigned to it; collators may also optimise the chance of consensus on their block by advertising it to availability guarantors. Once they have it, the data will be disbursed to other such guarantor to facilitate consensus. • P[s] <-> A | P[s']: Parachain validators will need to collect additional input data from the previous set of validators or the availability guarantors. • F[s] <-> P: When reporting, ﬁshermen may place a claim with any participant. • M <-> M | P | A: General relay-chain clients disburse data from validators and guarantors. • S[s] <-> S[s] | P[s] | A: Parachain clients disburse data from the validator/guarantors. • L[s] <-> L[s] | S[s]: Parachain light clients disburse data from the full clients. To ensure an eﬃcient transport mechanism, a “ﬂat” overlay network—like Ethereum’s devp2p—where each node does not (non-arbitrarily) diﬀerentiate ﬁtness of its peers is unlikely to be suitable. A reasonably extensible peer selection and discovery mechanism will likely need to be included within the protocol as well as aggressive planning an lookahead to ensure the right sort of peers are “serendipitously” connected at the right time. The precise strategy of peer make-up will be diﬀerent for each class of participant: for a properly scaled-out multi-chain, collators will either need to be continuously reconnecting to the accordingly elected validators, or will need on-going agreements with a subset of the validators to ensure they are not disconnected during the vast majority of the time that they are useless for that validator. Collators will also naturally attempt to maintain one or more stable connections into the availability guarantor set to ensure swift propagation of their consensus-sensitive data. Availability guarantors will mostly aim to maintain a stable connection to each other and to validators (for consensus and the consensus-critical parachain data to which they attest), as well as to some collators (for the parachain data) and some ﬁshermen and full clients (for dispersing information). Validators will tend to look for other validators, especially those in the same sub-group and any collators that can supply them with parachain block candidates. Fishermen, as well as general relay-chain and parachain clients will generally aim to keep a connection open to a validator or guarantor, but plenty of other nodes similar to themselves otherwise. Parachain light clients will similarly aim to be connected to a full client of the parachain, if not just other parachain light-clients. 6.8.1. The Problem of Peer Churn. In the basic protocol proposal, each of these subsets constantly alter randomly with each block as the validators assigned to verify the parachain transitions are randomly elected. This can be a problem should disparate (non-peer) nodes need to pass data between each other. One must either rely on a fairly-distributed and well-connected peer network to

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 18 ensure that the hop-distance (and therefore worst-case latency) only grows with the logarithm of the network size (a Kademlia-like protocol [13] may help here), or one must introduce longer block times to allow the necessary connection negotiation to take place to keep a peer-set that reﬂects the node’s current communication needs. Neither of these are great solutions: long block times being forced upon the network may render it useless for particular applications and chains. Even a perfectly fair and connected network will result in substantial wastage of bandwidth as it scales due to uninterested nodes having to forward data useless to them. While both directions may form part of the solution, a reasonable optimisation to help minimise latency would be to restrict the volatility of these parachain validator sets, either reassigning the membership only between series of blocks (e.g. in groups of 15, which at a 4 second block time would mean altering connections only once per minute) or by rotating membership in an incremental fashion, e.g. changing by one member at a time (e.g. if there are 15 validators assigned to each parachain, then on average it would be a full minute between completely unique sets). By limiting the amount of peer churn, and ensuring that advantageous peer connections are made well in advance through the partial predictability of parachain sets, we can help ensure each node keep a permanently serendipitous selection of peers. 6.8.2. Path to an Eﬀective Network Protocol. Likely the most eﬀective and reasonable development eﬀort will focus on utilising a pre-existing protocol rather than rolling our own. Several peer-to-peer base protocols exist that we may use or augment including Ethereum’s own devp2p [22], IPFS’s libp2p [1] and GNU’s GNUnet [4]. A full review of these protocols and their relevance for building a modular peer network supporting certain structural guarantees, dynamic peer steering and extensible sub-protocols is well beyond the scope of this document but will be an important step in the implementation of Polkadot. 7. Practicalities of the Protocol 7.1. Interchain Transaction Payment. While a great amount of freedom and simplicity is gained through dropping the need for a holistic computation resource accounting framework like Ethereum’s gas, this does raise an important question: without gas, how does one parachain avoid another parachain from forcing it to do computation? While we can rely on transaction-post ingress queue buﬀers to prevent one chain from spamming another with transaction data, there is no equivalent mechanism provided by the protocol to prevent the spamming of transaction processing. This is a problem left to the higher level. Since chains are free to attach arbitrary semantics on to the incoming transaction-post data, we can ensure that computation must be paid-for before started. In a similar vein to the model espoused by Ethereum Serenity, we can imagine a “break-in” contract within a parachain which allows a validator to be guaranteed payment in exchange for the provision of a particular volume of processing resources. These resources may be measured in something like gas, but could also be some entirely novel model such as subjective time-to-execute or a Bitcoin-like ﬂat-fee model. On its own this isn’t so useful since we cannot readily assume that the oﬀ-chain caller has available to them whatever value mechanism is recognised by the break-in contract. However, we can imagine a secondary “breakout” contract in the source chain. The two contracts together would form a bridge, recognising each other and providing value-equivalence. (Staking-tokens, available to each, could be used to settle up the balance-of-payments.) Calling into another such chain would mean proxying through this bridge, which would provide the means of negotiating the value transfer between chains in order to pay for the computation resources required on the destination parachain. 7.2. Additional Chains. While the addition of a parachain is a relatively cheap operation, it is not free. More parachains means fewer validators per parachain and, eventually, a larger number of validators each with a reduced average bond. While the issue of a smaller coercion cost for attacking a parachain is mitigated through ﬁshermen, the growing validator set essentially forces a higher degree of latency due to the mechanics of the underlying consensus method. Furthermore each parachain brings with it the potential to grief validators with an over-burdensome validation algorithm. As such, there will be some “price” that validators and/or the stake-holding community will extract for the addition of a new parachain. This market for chains will possibly see the addition of either: • Chains that likely have zero net contribution paying (in terms of locking up or burning staking tokens) to be made a part (e.g. consortium chains, Doge-chains, app-speciﬁc chains); • chains that deliver intrinsic value to the network through adding particular functionality diﬃcult to get elsewhere (e.g. conﬁdentiality, internal scalability, service tie-ins). Essentially, the community of stakeholders will need to be incentivized to add child chains—either ﬁnancially or through the desire to add featureful chains to the relay. It is envisioned that new chains added will have a very short notice period for removal, allowing for new chains to be experimented with without any risk of compromising the medium or long-term value proposition. 8. Conclusion We have outlined a direction one may take to author a scalable, heterogeneous multi-chain protocol with the potential to be backwards compatible to certain, pre-existing blockchain networks. Under such a protocol, participants work in enlightened self-interest to create an overall system which can be extended in an exceptionally free manner and without the typical cost for existing users that comes from a standard blockchain design. We have given a rough outline of the architecture it would take including the nature of the participants, their economic incentives and the processes under which they must engage. We have identiﬁed a basic design and discussed its strengths and limitations; accordingly we have further directions which may ease those limitations and yield further ground towards a fully scalable blockchain solution.

POLKADOT: VISION FOR A HETEROGENEOUS MULTI-CHAIN FRAMEWORK DRAFT 1 19 8.1. Missing Material and Open Questions. Network forking is always a possibility from divergent implementations of the protocol. The recovery from such an exceptional condition was not discussed. Given the network will necessarily have a non-zero period of ﬁnalisation, it should not be a large issue to recover from the relaychain forking, however will require careful integration into the consensus protocol. Bond-conﬁscation and conversely reward provision has not been deeply explored. At present we assume rewards are provided under a winner-takes-all basis: this may not give the best incentivisation model for ﬁshermen. A shortperiod commit-reveal process would allow many ﬁshermen to claim the prize giving a fairer distribution of rewards, however the process could lead to additional latency in the discovery of misbehaviour. 8.2. Acknowledgments. Many thanks to all of the proof-readers who have helped get this in to a vaguely presentable shape. In particular, Peter Czaban, Bj¨orn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler and Jack Petersson. Thanks to all the people who have contributed ideas or the beginnings thereof, Marek Kotewicz and Aeron Buchanan deserve especial mention. And thanks to everyone else for their help along the way. All errors are my own. Portions of this work, including initial research into consensus algorithms, was funded in part by the British Government under the Innovate UK programme.

Protokol secara Detail

Protokol secara kasar dapat dipecah menjadi tiga bagian: mekanisme konsensus, antarmuka parachain dan perutean transaksi antar rantai. 6.1. Rantai relai Operasi. Itu rantai relai akan kemungkinan besar merupakan rantai yang mirip dengan Ethereum di dalamnya berbasis negara bagian dengan alamat pemetaan negara bagian ke akun informasi, terutama saldo dan (untuk mencegah terulangnya kembali) a loket transaksi. Menempatkan akun di sini memenuhi satu tujuan: untuk menyediakan akuntansi yang dimiliki oleh identitas berapa jumlah taruhan dalam sistem tersebut.7 Namun, akan ada perbedaan yang mencolok: • Kontrak tidak dapat disebarkan melalui transaksi; karena keinginan untuk menghindari fungsionalitas aplikasi pada rantai relai, hal itu tidak akan terjadi mendukung penerapan kontrak secara publik. • Menghitung penggunaan sumber daya (“gas”) tidak diperhitungkan; karena satu-satunya fungsi yang tersedia untuk penggunaan umum akan diperbaiki, alasan di balik penghitungan gas tidak lagi berlaku. Oleh karena itu, biaya tetap akan berlaku semua kasus, memungkinkan kinerja lebih dari apa pun eksekusi kode dinamis yang mungkin perlu dilakukan dan format transaksi yang lebih sederhana. • Fungsi khusus didukung untuk kontrak terdaftar yang memungkinkan eksekusi otomatis dan keluaran pesan jaringan. Jika rantai relai memiliki VM dan itu adalah berdasarkan EVM, ia akan memiliki sejumlah modifikasi untuk memastikan kesederhanaan maksimal. Kemungkinan besar akan terjadi memiliki sejumlah kontrak bawaan (mirip dengan yang ada di alamat 1-4 di Ethereum) untuk memungkinkan spesifik platform tugas yang harus dikelola termasuk kontrak konsensus, a Kontrak validator dan kontrak parachain. Jika bukan EVM, maka backend WebAssembly [2] (wasm) adalah alternatif yang paling mungkin; dalam hal ini keseluruhan strukturnya akan serupa, tetapi tidak diperlukan untuk kontrak bawaan dengan Wasm menjadi target yang layak untuk bahasa tujuan umum daripada yang belum matang dan bahasa terbatas untuk EVM. Kemungkinan penyimpangan lain dari protokol Ethereum saat ini sangat mungkin terjadi, misalnya penyederhanaan format tanda terima transaksi yang memungkinkan eksekusi paralel transaksi yang tidak bertentangan dalam blok yang sama, seperti yang diusulkan untuk rangkaian perubahan Serenity. Ada kemungkinan, meskipun tidak mungkin, bahwa hal itu mirip dengan Serenity rantai "murni" digunakan sebagai rantai relai, memungkinkan a kontrak khusus untuk mengelola hal-hal seperti staking token keseimbangan daripada menjadikannya sebagai bagian mendasar protokol rantai. Saat ini, kami merasa hal tersebut tidak mungkin terjadi akan menawarkan penyederhanaan protokol yang cukup bagus sepadan dengan kompleksitas dan ketidakpastian tambahan yang terlibat dalam mengembangkannya. 7Sebagai sarana untuk mewakili jumlah tanggung jawab pemegang tertentu atas keamanan sistem secara keseluruhan, akun pasak ini akan mewakilinya pasti menyandikan beberapa nilai ekonomi. Namun perlu dipahami karena tidak ada niat untuk menggunakan nilai-nilai tersebut dengan cara apa pun untuk tujuan pertukaran barang dan jasa di dunia nyata, perlu dicatat bahwa token tidak bisa disamakan dengan mata uang dan dengan demikian rantai relai mempertahankan filosofi nihilistiknya mengenai penerapannya.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 10 Ada sejumlah fungsi kecil yang diperlukan untuk mengatur mekanisme konsensus, set validator, mekanisme validasi, dan parachain. Ini dapat diimplementasikan bersama-sama di bawah protokol monolitik. Namun, untuk alasan menambah modularitas, kami menggambarkannya sebagai “kontrak” rantai relai. Ini seharusnya diartikan bahwa mereka adalah objek (dalam arti pemrograman berorientasi objek) yang dikelola oleh mekanisme konsensus rantai relai, namun belum tentu demikian mereka didefinisikan sebagai program dalam opcode mirip EVM, juga tidak bahkan mereka dapat ditangani secara individual melalui sistem akun. 6.2. Kontrak Taruhan. Kontrak ini mempertahankan set validator. Ia mengelola: • akun mana yang saat ini validators; • yang tersedia untuk menjadi validators singkatnya pemberitahuan; • akun mana yang telah menempatkan nominasi saham sebuah validator; • properti masing-masing termasuk volume staking, tingkat pembayaran dan alamat yang dapat diterima, serta identitas (sesi) jangka pendek. Memungkinkan akun untuk mendaftarkan keinginan menjadi a terikat validator (bersama dengan persyaratannya), untuk mencalonkan beberapa identitas, dan untuk validator terikat yang sudah ada sebelumnya untuk mendaftarkan keinginannya untuk keluar dari status ini. Itu juga mencakup mekanisme itu sendiri untuk mekanisme validasi dan kanonikalisasi. 6.2.1. Taruhan-token Likuiditas. Umumnya diinginkan untuk melakukan hal tersebut memiliki sebanyak mungkin total staking tokens dipertaruhkan dalam operasi pemeliharaan jaringan sejak itu ini secara langsung menghubungkan keamanan jaringan dengan “kapitalisasi pasar” keseluruhan dari staking token. Ini bisa dengan mudah mendapatkan insentif melalui penggelembungan mata uang dan membagikan hasilnya kepada mereka yang berpartisipasi sebagai validators. Namun, melakukan hal ini menimbulkan masalah: jika token terkunci dalam Kontrak Staking di bawah hukuman pengurangan, bagaimana sebagian besar bisa tetap mencukupi likuid untuk memungkinkan penemuan harga? Salah satu jawabannya adalah dengan mengizinkan kontrak derivatif langsung, mengamankan token yang sepadan pada token yang dipertaruhkan. Hal ini sulit diatur dengan cara yang bebas kepercayaan. Selain itu, token derivatif ini tidak dapat diperlakukan sama karena alasan yang sama bahwa obligasi pemerintah Zona Euro yang berbeda tidak dapat dipertukarkan: ada adalah kemungkinan aset yang mendasarinya gagal dan menjadi rusak tidak berharga. Dengan pemerintahan zona Euro, mungkin ada a bawaan. Dengan validator yang dipertaruhkan tokens, validator mungkin bertindak jahat dan dihukum. Sesuai dengan prinsip kami, kami memilih solusi paling sederhana: tidak semua token dipertaruhkan. Ini berarti demikian sebagian (mungkin 20%) dari tokens akan tetap cair secara paksa. Meskipun hal ini tidak sempurna dari sudut pandang keamanan, hal ini sepertinya tidak akan membuat perbedaan mendasar keamanan jaringan; 80% dari kemungkinan reparasi akibat penyitaan obligasi masih dapat dilakukan dibandingkan dengan “kasus sempurna” 100% staking. Rasio antara token yang dipertaruhkan dan likuid dapat ditargetkan dengan cukup sederhana melalui mekanisme lelang terbalik. Pada dasarnya, pemegang token tertarik menjadi validator masing-masing akan mengirimkan penawaran ke kontrak staking yang menyatakan tingkat pembayaran minimum yang harus mereka ambil bagian. Di awal setiap sesi (sesi akan terjadi secara teratur, mungkin sesering satu kali per jam) tersebut validator slot akan diisi sesuai dengan calon masing-masing Tingkat taruhan dan pembayaran validator. Salah satu algoritma yang mungkin karena ini berarti mengambil orang-orang dengan penawaran terendah mewakili taruhan yang tidak lebih tinggi dari total taruhan yang ditargetkan dibagi dengan jumlah slot dan tidak lebih rendah dari batas bawah setengah jumlah tersebut. Jika slot tidak dapat diisi, batas bawah dapat dikurangi berulang kali oleh beberapa faktor untuk memenuhi. 6.2.2. Mencalonkan. Dimungkinkan untuk mencalonkan diri tanpa rasa percaya yang staking tokens ke validator aktif, memberi mereka tanggung jawab tugas validators. Menominasikan karya melalui sistem pemungutan suara persetujuan. Setiap calon nominator dapat mengirimkan instruksi ke kontrak staking mengekspresikan satu atau lebih validator identitas di bawah siapa tanggung jawab mereka siap untuk mempercayakan obligasi mereka. Setiap sesi, obligasi nominator disebarkan diwakili oleh satu atau lebih validators. Algoritme penyebaran mengoptimalkan kumpulan validators dengan total setara obligasi. Obligasi nominator menjadi tanggung jawab efektif validator adan mendapatkan minat atau menderita a pengurangan hukuman yang sesuai. 6.2.3. Penyitaan/Pembakaran Obligasi. Perilaku validator tertentu mengakibatkan pengurangan ikatan mereka sebagai hukuman. Jika obligasi tersebut dikurangi di bawah batas minimum yang diijinkan, yaitu sesi diakhiri sebelum waktunya dan sesi lainnya dimulai. Daftar lengkap validator perilaku buruk yang dapat dihukum meliputi: • Menjadi bagian dari kelompok parachain yang tidak mampu menyediakan kebutuhan konsensus mengenai validitas blok parachain; • aktif menandatangani keabsahan yang tidak valid blok parachain; • ketidakmampuan untuk memasok muatan keluar sebelumnya memilih jika tersedia; • ketidakaktifan selama proses konsensus; • memvalidasi blok rantai relai pada fork pesaing. Beberapa kasus perilaku buruk mengancam integritas jaringan (seperti menandatangani blok parachain yang tidak valid dan memvalidasi beberapa sisi dari sebuah fork) dan dengan demikian mengakibatkan pengasingan yang efektif melalui pengurangan total obligasi. Di kasus lain yang tidak terlalu serius (misalnya ketidakaktifan dalam konsensus proses) atau kasus-kasus di mana kesalahan tidak dapat dilimpahkan secara tepat (karena menjadi bagian dari kelompok yang tidak efektif), sebagian kecil obligasi tersebut malah dapat didenda. Dalam kasus terakhir, ini bekerja dengan baik dengan churn sub-grup untuk memastikan bahwa itu berbahaya node menderita kerugian yang jauh lebih besar dibandingkan node baik hati yang terkena dampak kerusakan. Dalam beberapa kasus (misalnya validasi multi-fork dan tidak valid penandatanganan sub-blok) validators tidak dapat dengan mudah mendeteksi perilaku buruk satu sama lain sejak verifikasi terus-menerus setiap blok parachain akan menjadi tugas yang terlalu sulit. Di sini perlu adanya dukungan dari pihak eksternal proses validasi untuk memverifikasi dan melaporkan perilaku buruk tersebut. Para pihak mendapat imbalan karena melaporkan kegiatan tersebut; istilah mereka, “nelayan” berasal dari ketidaksukaan dari imbalan seperti itu. Karena kasus-kasus ini biasanya sangat serius, kami membayangkan imbalan apa pun dapat dengan mudah dibayarkan dari obligasi yang disita. Secara umum kami lebih memilih untuk menyeimbangkan pembakaran (yaitu pengurangan menjadi tidak ada) dengan realokasi, bukan mencoba realokasi grosir. Hal ini mempunyai dampak

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 11 meningkatkan nilai keseluruhan token, mengkompensasi jaringan secara umum sampai tingkat tertentu, bukan secara spesifik pihak yang terlibat dalam penemuan. Hal ini terutama sebagai pengaman mekanismenya: jumlah besar yang terlibat dapat menyebabkan insentif perilaku yang ekstrem dan akut diberikan pada satu sasaran. Secara umum, imbalan yang diberikan harus cukup besar agar verifikasi bermanfaat bagi jaringan, namun tidak terlalu besar untuk mengimbangi biaya menghadapi tantangan. kriminal “tingkat industri” yang didanai dengan baik dan diatur dengan baik serangan peretasan pada validator yang tidak beruntung untuk memaksakan perilaku buruk. Dengan cara ini, jumlah yang diklaim umumnya tidak lebih besar dari jaminan langsung pihak yang bersalah validator, jangan sampai a timbul insentif buruk karena berperilaku buruk dan melaporkan diri sendiri atas karunia tersebut. Hal ini dapat diatasi secara eksplisit melalui persyaratan obligasi langsung minimum untuk menjadi a validator atau secara implisit dengan mengedukasi nominator bahwa validator yang memiliki sedikit obligasi yang disetorkan tidak memiliki insentif yang besar untuk berperilaku baik. 6.3. Registri Parachain. Setiap parachain didefinisikan dalam registri ini. Ini adalah konstruksi seperti database yang relatif sederhana dan menyimpan informasi statis dan dinamis setiap rantai. Informasi statis mencakup indeks rantai (sederhana integer), beserta identitas protokol validasi, a cara untuk membedakan kelas-kelas yang berbeda parachain sehingga algoritma validasi yang benar dapat diperoleh dijalankan oleh validators yang ditugaskan untuk mengajukan calon yang sah. Pembuktian konsep awal akan fokus pada penempatan algoritma validasi baru ke dalam klien itu sendiri, yang secara efektif memerlukan hard fork protokol setiap kali kelas rantai tambahan ditambahkan. Namun pada akhirnya, dimungkinkan untuk menentukan algoritma validasi di cara yang cukup ketat dan efisien seperti yang dilakukan klien mampu bekerja secara efektif dengan parachain baru tanpa a garpu keras. Salah satu jalan yang mungkin untuk melakukan hal ini adalah dengan menentukan algoritma validasi parachain dengan cara yang mapan dan bahasa yang dikompilasi secara asli dan netral platform seperti WebAssembly. Penelitian tambahan diperlukan untuk menentukan apakah hal ini benar-benar layak dilakukan, namun jika demikian, hal ini dapat membawa hasil dengan itu keuntungan luar biasa dari membuang hard-fork untuk selamanya. Informasi dinamis mencakup aspek sistem perutean transaksi yang harus memiliki kesepakatan global tersebut sebagai antrian masuknya parachain (dijelaskan di bagian 6.6). Registri hanya dapat menambahkan parachain melalui pemungutan suara referendum penuh; ini bisa dikelola secara internal tetapi lebih mungkin ditempatkan di eksternal kontrak referendum untuk memfasilitasi penggunaan kembali di bawah komponen tata kelola yang lebih umum. Parameter ke persyaratan pemungutan suara (misalnya kuorum yang diperlukan, mayoritas diperlukan) untuk pendaftaran rantai tambahan dan lainnya, peningkatan sistem yang kurang formal akan ditetapkan dalam “master konstitusi” namun cenderung mengikuti konstitusi yang cukup tradisional jalan, setidaknya pada awalnya. Formulasi tepatnya sudah keluar ruang lingkup untuk pekerjaan ini, tetapi mis. dua pertiga supermayoritas lolos dengan lebih dari sepertiga total sistem pemungutan suara secara positif mungkin merupakan titik awal yang masuk akal. Operasi tambahan termasuk penangguhan dan pelepasan parachain. Mudah-mudahan penangguhan tidak akan pernah terjadi terjadi, namun hal ini dirancang untuk menjadi tindakan pengamanan ada beberapa masalah yang sulit diselesaikan dalam sistem validasi parachain. Contoh paling jelas yang mungkin terjadi yang diperlukan adalah perbedaan penting antara implementasi yang menyebabkan validators tidak dapat menyepakati validitas atau blok. Validator akan didorong untuk menggunakan beberapa implementasi klien agar mereka mampu untuk menemukan masalah seperti itu sebelum penyitaan obligasi. Karena penangguhan adalah tindakan darurat, maka hal itu akan terjadi di bawah naungan pemungutan suara validator yang dinamis daripada referendum. Pengaktifan kembali keduanya dapat dilakukan dari validators atau referendum. Penghapusan parachain sama sekali hanya akan terjadi setelah referendum dan yang diperlukan a masa tenggang yang substansial untuk memungkinkan transisi yang tertib ke baik rantai yang berdiri sendiri atau menjadi bagian dari rantai lainnya sistem konsensus. Masa tenggang kemungkinan besar akan berlangsung selama urutan bulan dan kemungkinan besar akan ditetapkan berdasarkan perchain di registri parachain agar berbeda parachain dapat menikmati masa tenggang yang berbeda-beda sesuai dengan kebutuhan mereka. 6.4. Blok Relai Penyegelan. Penyegelan pada dasarnya mengacu pada pada proses kanonikalisasi; yaitu data dasar mengubah yang manamemetakan yang asli menjadi sesuatu yang pada dasarnya tunggal dan bermakna. Di bawah rantai PoW, penyegelan secara efektif merupakan sinonim dari penambangan. Dalam kasus kami, ini melibatkan pengumpulan pernyataan yang ditandatangani dari validators mengenai validitas, ketersediaan, dan kanonikalitas suatu blok rantai relai tertentu dan blok parachain itu itu mewakili. Mekanisme algoritma konsensus BFT yang mendasarinya berada di luar cakupan penelitian ini. Kami akan melakukannya alih-alih mendeskripsikannya menggunakan primitif yang mengasumsikan a mesin negara yang menciptakan konsensus. Pada akhirnya kami berharap terinspirasi oleh sejumlah konsensus BFT yang menjanjikan algoritma pada intinya; Tangaora [9] (varian BFT dari Rakit [16]), Tendermint [11] dan HoneyBadgerBFT [14]. Algoritmenya harus mencapai kesepakatan mengenai beberapa parachain secara paralel, sehingga berbeda dari biasanya blockchain mekanisme konsensus. Kami berasumsi bahwa sekali konsensus tercapai, kita dapat mencatat konsensus tersebut dalam bukti yang tak terbantahkan yang dapat diberikan oleh siapa pun para peserta di dalamnya. Kami juga berasumsi bahwa perilaku buruk itu dalam protokol umumnya dapat dikurangi menjadi kecil kelompok yang berisi peserta nakal untuk diminimalkan kerusakan tambahan ketika memberikan hukuman.8 Buktinya, yang berupa pernyataan yang kami tandatangani, ditempatkan di header blok rantai relai bersama-sama dengan bidang-bidang tertentu lainnya, tidak terkecuali akar keadaan rantai relai dan akar percobaan transaksi. Itu penyegelan proses dibutuhkan tempat di bawah sebuah lajang menghasilkan konsensus mekanisme menangani keduanya itu blok rantai relai dan blok parachain yang membuatnya bagian dari konten relai: parachain tidak “dikomit” secara terpisah oleh sub-grupnya dan kemudian disusun nanti. Hal ini menghasilkan proses yang lebih kompleks pada rantai relai, namun memungkinkan kami menyelesaikan konsensus seluruh sistem dalam satu tahap, meminimalkan latensi dan memungkinkan untuk persyaratan ketersediaan data yang cukup kompleks berguna untuk proses perutean di bawah ini. 8Skema konsensus BFT berbasis PoS yang ada seperti Tendermint BFT dan Slasher asli memenuhi pernyataan ini.

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 12 Keadaan mesin konsensus masing-masing peserta mungkin berbeda dimodelkan sebagai tabel sederhana (2 dimensi). Setiap peserta (validator) memiliki sekumpulan informasi berupa pernyataan yang ditandatangani (“suara”) dari peserta lain, mengenai setiap kandidat blok parachain serta kandidat blok relaychain. Kumpulan informasinya ada dua bagian data: Ketersediaan: tidak ini validator punya jalan keluar informasi transaksi-posting dari blok ini jadi mereka dapat memvalidasi kandidat parachain dengan benar di blok berikut? Mereka mungkin memilih baik 1 (diketahui) atau 0 (belum diketahui). Sekali mereka memilih 1, mereka berkomitmen untuk memberikan suara yang sama sisa proses ini. Nanti suara yang tidak hormat ini adalah dasar untuk hukuman. Validitas: apakah blok parachain valid dan semuanya data yang direferensikan secara eksternal (mis. transaksi) tersedia? Ini hanya relevan untuk validator yang ditugaskan pada parachain tempat mereka memberikan suara. Mereka dapat memilih 1 (sah), -1 (tidak sah) atau 0 (belum diketahui). Begitu mereka memilih bukan nol, mereka berkomitmen untuk memberikan suara dengan cara ini selama sisa pemilu prosesnya. Nanti ada suara yang tidak menghormati hal ini merupakan dasar untuk hukuman. Semua validator harus menyerahkan suara; suara dapat diserahkan kembali, memenuhi syarat berdasarkan peraturan di atas. Kemajuan dari konsensus dapat dimodelkan sebagai beberapa algoritma konsensus BFT standar pada setiap parachain yang terjadi secara paralel. Karena hal ini berpotensi digagalkan oleh relatif sebagian kecil aktor jahat terkonsentrasi di dalamnya satu kelompok parachain, konsensus keseluruhan ada untuk itu membangun penghalang, membatasi skenario terburuk kebuntuan hanya pada satu atau lebih blok parachain kosong (dan putaran hukuman bagi mereka yang bertanggung jawab). Aturan dasar untuk validitas masing-masing blok (yang memungkinkan total kumpulan validator secara keseluruhan diperoleh konsensus untuk menjadi kandidat parachain yang unik untuk direferensikan dari relai kanonik): • harus memiliki setidaknya dua pertiga dari validator yang memberikan suara positif dan tidak ada yang memberikan suara negatif; • harus memiliki lebih dari sepertiga validator yang memberikan suara positif terhadap ketersediaan informasi antrian keluar. Jika terdapat setidaknya satu suara positif dan setidaknya satu suara negatif mengenai validitas, kondisi luar biasa akan tercipta dan seluruh validator harus memberikan suara untuk menentukan jika ada pihak jahat atau jika ada yang tidak disengaja garpu. Selain sah dan tidak sah, ada pula jenis suara yang ketiga diperbolehkan, setara dengan memilih keduanya, artinya simpul tersebut memiliki pendapat yang bertentangan. Hal ini mungkin disebabkan oleh pemilik node menjalankan beberapa implementasi yang dapat melakukannya tidak setuju, menunjukkan kemungkinan ambiguitas dalam protokol. Setelah semua suara dihitung dari set validator penuh, jika opini yang kalah memiliki setidaknya sebagian kecil (untuk diparameterisasi; paling banyak setengahnya, mungkin jauh lebih sedikit) dari suara pendapat yang menang, maka diasumsikan demikian menjadi parachain fork yang tidak disengaja dan parachain secara otomatis ditangguhkan dari proses konsensus. Jika tidak, kami menganggapnya sebagai tindakan jahat dan akan menghukumnya kelompok minoritas yang memberikan suara dissenting opinion. Kesimpulannya adalah demonstrasi serangkaian tanda tangan kanonikalitas. Blok rantai relai kemudian dapat disegel dan proses penyegelan blok berikutnya dimulai. 6.5. Perbaikan pada Blok Relai Penyegelan. Sementara metode penyegelan ini memberikan jaminan yang kuat atas pengoperasian sistem, namun skalanya tidak terlalu baik karena informasi penting setiap parachain pasti ada ketersediaan dijamin oleh lebih dari sepertiga dari seluruh validators. Artinya, setiap jejak tanggung jawab validator tumbuh seiring bertambahnya rantai. Sedangkan ketersediaan data dalam jaringan konsensus terbuka pada dasarnya adalah masalah yang belum terpecahkan, ada cara untuk mengurangi overhead yang ditempatkan pada validator node. Satu yang sederhana solusinya adalah dengan menyadari bahwa sementara validators harus memikulnya tanggung jawab atas ketersediaan data, mereka tidak perlu menyimpan, mengomunikasikan, atau mereplikasi data itu sendiri. Silo data sekunder, mungkin terkait dengan (atau bahkan sangat terkait). sama) kolektor yang mengumpulkan data ini, dapat mengelola tugas menjamin ketersediaan dengan validators memberikan sebagian dari bunga/pendapatan mereka sebagai pembayaran. Namun, meskipun hal ini mungkin memerlukan skalabilitas menengah, hal ini tetap tidak membantu masalah mendasar; sejak itu menambahkan lebih banyak rantai secara umum akan memerlukan validator tambahan, konsumsi sumber daya jaringan yang berkelanjutan (khususnya dalam hal bandwidth) tumbuh seiring dengan bertambahnya kuadrat iturantai, properti yang tidak dapat dipertahankan dalam jangka panjang. Pada akhirnya, kita cenderung terus-terusan memukul kepala terhadap batasan mendasar yang menyatakan bahwa untuk jaringan konsensus dianggap tersedia aman, itu kebutuhan bandwidth yang sedang berlangsung berada pada urutan total validators kali total informasi masukan. Hal ini disebabkan oleh ketidakmampuan jaringan yang tidak tepercaya untuk mendistribusikan tugas penyimpanan data dengan benar ke banyak node yang berada terlepas dari tugas pemrosesan yang sangat dapat didistribusikan. 6.5.1. Memperkenalkan Latensi. Salah satu cara untuk melunakkannya aturannya adalah melonggarkan gagasan kesegeraan. Dengan mewajibkan 33%+1 validators memberikan suara untuk ketersediaan pada akhirnya, dan tidak segera, kita dapat memanfaatkan propagasi data eksponensial dengan lebih baik dan membantu meratakan puncak dalam pertukaran data. Kesetaraan yang wajar (meskipun tidak terbukti) mungkin: (1) latensi = peserta × rantai Di bawah model saat ini, ukuran sistem berskala dengan jumlah rantai untuk memastikan bahwa pemrosesan dilakukan didistribusikan; karena setiap rantai akan memerlukan setidaknya satu validator dan kami menetapkan pengesahan ketersediaan menjadi konstan proporsi validators, maka peserta juga bertambah dengan jumlah rantai. Kami berakhir dengan: (2) latensi = ukuran2 Artinya seiring pertumbuhan sistem, bandwidth yang dibutuhkan dan latensi hingga ketersediaan diketahui di seluruh sistem jaringan, yang mungkin juga dicirikan sebagai angka blok sebelum finalitas, bertambah seiring dengan kuadratnya. Ini adalah merupakan faktor pertumbuhan yang substansial dan mungkin menjadi penghalang utama serta memaksa kita menerapkan paradigma yang “tidak datar” seperti menyusun beberapa “Polkadotes” ke dalam hierarki untuk perutean postingan multi-level melalui pohon rantai relai.

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 13 6.5.2. Partisipasi Masyarakat. Satu lagi kemungkinan arah adalah untuk menarik partisipasi masyarakat dalam proses tersebut melalui a sistem pengaduan mikro. Mirip dengan nelayan, di sana bisa jadi pihak eksternal yang mengawasi validator yang mengklaim ketersediaan. Tugas mereka adalah menemukan orang yang tampaknya tidak mampu menunjukkan ketersediaan tersebut. Dengan melakukan hal itu mereka dapat mengajukan keluhan mikro ke validator lainnya. PoW atau obligasi yang dipertaruhkan dapat digunakan untuk mengurangi serangan sybil yang akan membuat sebagian besar sistem tidak berguna. 6.5.3. Penjamin Ketersediaan. Rute terakhirnya adalah ke menominasikan set kedua validator terikat sebagai “ketersediaan penjamin”. Ini akan terikat seperti dengan validators normal, dan bahkan dapat diambil dari set yang sama (walaupun jika demikian, mereka akan dipilih dalam jangka waktu yang panjang, setidaknya per sesi). Tidak seperti validator biasa, mereka tidak akan beralih antar parachain melainkan akan melakukannya membentuk satu kelompok untuk membuktikan ketersediaan semua data antar rantai yang penting. Hal ini mempunyai keuntungan dalam melonggarkan kesetaraan antara peserta dan rantai. Pada dasarnya, rantai bisa tumbuh (bersama dengan set rantai asli validator), sedangkan para peserta, dan khususnya mereka yang mengambil bagian dalam perjanjian ketersediaan data, setidaknya dapat tetap berada pada kondisi sub-linear dan sangat mungkin konstan. 6.5.4. Preferensi Pengumpul. Salah satu aspek penting dari hal ini sistem adalah untuk memastikan bahwa ada pilihan yang sehat kolator membuat blok di parachain mana pun. Jika sebuah kolator tunggal mendominasi parachain kemudian beberapa serangan menjadi lebih layak karena kemungkinan kurangnya ketersediaan data eksternal akan menjadi kurang jelas. Salah satu opsinya adalah dengan memberi bobot buatan pada blok parachain mekanisme pseudo-acak untuk mendukung berbagai macam kolator. Dalam contoh pertama, kita memerlukannya sebagai bagian dari mekanisme konsensus yang menguntungkan validator kandidat blok parachain bertekad untuk menjadi “lebih berat”. Demikian pula, kita harus memberi insentif kepada validators untuk mencoba melakukan hal tersebut menyarankan hambatan terberat yang bisa mereka temukan—bisa jadi ini adalah halangan dilakukan dengan membuat sebagian imbalannya sebanding dengan bobot kandidatnya. Untuk memastikan bahwa kolektor diberikan keadilan yang wajar peluang calonnya terpilih sebagai pemenang kandidat secara konsensus, kami membuat bobot spesifik a kandidat blok parachain ditentukan pada fungsi acak yang terhubung dengan setiap kolator. Misalnya saja mengambil ukuran jarak XOR antara alamat kolektor dan beberapa nomor pseudorandom yang aman secara kriptografis ditentukan dekat dengan titik blok yang dibuat (sebuah “tiket kemenangan”). Ini secara efektif memberi masing-masing pengumpul (atau, lebih khusus lagi, alamat masing-masing pengumpul) a peluang acak dari blok kandidat mereka untuk “menang”. semua yang lain. Untuk mengurangi serangan sybil dari seorang kolator tunggal yang “menambang” alamat yang dekat dengan tiket pemenang dan dengan demikian keberadaannya menjadi favorit di setiap blok, kami akan menambahkan beberapa inersia ke alamat collator. Ini mungkin sesederhana mengharuskan mereka untuk memiliki jumlah dana dasar di alamat tersebut. Lebih lanjut pendekatan yang elegan adalah dengan mempertimbangkan kedekatannya dengan tiket pemenang dengan jumlah dana yang diparkir di alamat yang dimaksud. Meskipun pemodelan belum dilakukan, sangat mungkin mekanisme ini bahkan sangat memungkinkan pemangku kepentingan kecil untuk berkontribusi sebagai kolator. 6.5.5. Blok Kelebihan Berat Badan. Jika kumpulan validator dikompromikan, mereka dapat membuat dan mengusulkan blok yang mana valid, membutuhkan banyak waktu untuk mengeksekusi dan memvalidasi. Ini merupakan masalah karena grup validator dapat melakukannya wajar saja membentuk sebuah blok yang membutuhkan waktu yang sangat lama untuk melakukannya mengeksekusi kecuali beberapa informasi tertentu sudah diketahui sehingga memungkinkan jalan pintas, misalnya memfaktorkan yang besar prima. Jika seorang kolator mengetahui informasi itu, maka mereka akan memiliki keuntungan yang jelas jika mendapatkan milik mereka sendiri calon diterima asalkan yang lain sibuk mengolah blok lama. Kami menyebut blok ini kelebihan berat badan. Perlindungan terhadap validator yang mengirimkan dan memvalidasi blok ini sebagian besar berada di bawah kedok yang sama seperti untuk blok tidak valid, meskipun dengan peringatan tambahan: Sejak waktu yang dibutuhkan untuk mengeksekusi sebuah blok (dan dengan demikian statusnya sebagai kelebihan berat badan) bersifat subyektif, hasil akhir dari pemungutan suara perilaku buruk pada dasarnya akan terbagi dalam tiga kubu. Satu kemungkinannya adalah blok tersebut pastinya tidak kelebihan berat badan— dalam hal ini lebih dari dua pertiga menyatakan mampu mengeksekusi blok dalam batas tertentu (misalnya 50% dari total waktu yang diperbolehkan antar blok). Hal lainnya adalah bahwa blok adalah dbenar-benar kelebihan berat badan—ini akan terjadi jika lebih dari dua pertiga menyatakan bahwa mereka tidak dapat mengeksekusi blok tersebut dalam batas tersebut. Satu kemungkinan terakhir adalah sama perpecahan pendapat antara validators. Dalam hal ini, kita mungkin memilih untuk melakukan hukuman yang proporsional. Untuk memastikan validators dapat memprediksi kapan hal tersebut mungkin terjadi mengusulkan blok yang kelebihan berat badan, mungkin masuk akal untuk meminta mereka mempublikasikan informasi tentang kinerja mereka sendiri untuk setiap blok. Dalam jangka waktu yang cukup, ini akan memungkinkan mereka untuk memprofilkan kecepatan pemrosesan mereka relatif terhadap rekan-rekan yang akan menghakimi mereka. 6.5.6. Asuransi Pengumpul. Satu masalah tersisa untuk validators: tidak seperti jaringan PoW, untuk memeriksa collator blok untuk validitas, mereka harus benar-benar mengeksekusi transaksi di dalamnya. Kolator jahat dapat memberi makan blok yang tidak valid atau kelebihan berat badan ke validator yang menyebabkan mereka sedih (terbuang sia-sia) sumber daya mereka) dan menuntut potensi biaya peluang yang besar. Untuk mengurangi hal ini, kami mengusulkan strategi sederhana di bagian dari validators. Pertama, kandidat blok parachain dikirim hingga validators harus ditandatangani dari akun rantai relai dengan dana; jika tidak, maka validator akan hilang segera. Kedua, kandidat tersebut harus diurutkan berdasarkan prioritas dengan kombinasi (misalnya perkalian). jumlah dana di rekening sampai batas tertentu, yaitu jumlah blok sebelumnya yang berhasil diusulkan oleh kolator di masa lalu (belum lagi blok sebelumnya hukuman), dan faktor kedekatan dengan pemenang tiket seperti yang dibahas sebelumnya. Tutupnya harus sama sebagai hukuman ganti rugi yang dibayarkan kepada validator dalam kasus tersebut di antaranya mengirimkan blok yang tidak valid. Untuk mendisinsentifkan kolator agar tidak mengirimkan kandidat blok yang tidak valid atau kelebihan berat badan ke validators, validator mana pun dapat tempatkan di blok berikutnya sebuah transaksi termasuk blok yang menyinggung dugaan perilaku buruk yang berdampak pada transfer sebagian atau seluruh dana ke dalam rekening kolator yang berperilaku buruk. akun kepada validator yang dirugikan. Jenis transaksi ini dijalankan terlebih dahulu oleh orang lain untuk memastikan kolator tidak dapat melakukannya mengeluarkan dana sebelum hukuman. Jumlah dana yang ditransfer sebagai ganti rugi masih merupakan parameter yang dinamis

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 14 untuk dimodelkan tetapi kemungkinan besar akan menjadi proporsi dari hadiah blok validator untuk mencerminkan tingkat kesedihan yang ditimbulkan. Untuk mencegah validator jahat secara sewenang-wenang menyita dana kolektor, kolator dapat mengajukan banding atas keputusan validator dengan juri yang terdiri dari validator yang dipilih secara acak sebagai imbalannya untuk menempatkan deposit kecil. Jika mereka menguntungkan validator, deposit tersebut akan dikonsumsi oleh mereka. Jika tidak, itu deposit dikembalikan dan validator didenda (sejak validator berada dalam posisi yang jauh lebih berkubah, dendanya akan lebih besar mungkin agak besar dan kuat). 6.6. Antar rantai Transaksi Perutean. Antar rantai perutean transaksi adalah salah satu pemeliharaan penting tugas rantai relai dan validatorsnya. Ini adalah logika yang mengatur bagaimana transaksi yang diposting (sering disingkat menjadi “posting”) mendapatkan output yang diinginkan dari satu parachain sumber menjadi masukan yang tidak dapat dinegosiasikan dari parachain tujuan lain tanpa kepercayaan apa pun persyaratan. Kami memilih kata-kata di atas dengan hati-hati; terutama kita tidak mengharuskan adanya transaksi di sumbernya parachain telah secara eksplisit menyetujui postingan ini. Satu-satunya Kendala yang kami tempatkan pada model kami adalah parachain harus disediakan, dikemas sebagai bagian dari keseluruhan bloknya output pemrosesan, postingan yang merupakan hasil dari eksekusi blok. Pos-pos ini disusun sebagai beberapa antrian FIFO; itu jumlah daftar dikenal sebagai basis perutean dan mungkin sekitar 16. Khususnya, angka ini mewakili kuantitas parachain yang dapat kami dukung tanpa harus menggunakan bantuan apa pun perutean multi-fase. Awalnya, Polkadot akan mendukung hal ini jenis perutean langsung, namun kami akan menguraikan satu kemungkinan proses routing multi-fase (“hyper-routing”) sebagai sarana untuk memperluas jangkauannya melewati rangkaian parachain awal. Kami berasumsi itu semua peserta tahu itu subkelompok untuk dua blok berikutnya n, n + 1. Singkatnya, the sistem routing mengikuti tahapan berikut: • CollatorS: Hubungi anggota Validator[n][S] • Kolator: UNTUK SETIAP subgrup: pastikan pada setidaknya 1 anggota Validator[n][s] dalam kontak • Pengumpul: UNTUK SETIAP subgrup s: berasumsi egress[n −1][s][S] tersedia (semua postingan masuk data ke 'S' dari blok terakhir) • Pengumpul: Tulis kandidat blok b untuk S: (b.header, b.ext, b.proof, b.receipt, b.egress) • Pengumpul: Kirim bukti informasi bukti[S] = (b.header, b.ext, b.proof, b.receipt) ke V alidator[n][S] • CollatorS: Pastikan data transaksi eksternal b.ext tersedia untuk kolator lain dan validators • Pengumpul: UNTUK SETIAP subgrup s: Kirim jalan keluar informasi jalan keluar[n][S][s] = (b.header, b.kwitansi, b.egress[s]) untuk itu menerima subkelompok anggota dari berikutnya blok V alidator[n + 1][s] • ValidatorV : Pra-sambungkan semua anggota set yang sama untuk blok selanjutnya: misalkan N = Chain[n + 1][V ]; menghubungkan semua validators v sedemikian rupa sehingga Chain[n + 1][v] = N • V alidatorV : Susun semua data yang masuk untuk ini blok: UNTUK SETIAP subgrup s: Ambil egress[n −1][s][Chain[n][V ]], dapatkan dari validators v lain sedemikian rupa sehingga Chain[n][v] = Chain[n][V ]. Mungkin melalui validator lain yang dipilih secara acak sebagai bukti percobaan. • V alidatorV : Terima bukti kandidat untuk ini bukti blok[Rantai[n][V ]]. Validitas blok suara • V alidatorV : Terima data jalan keluar kandidat untuk blok berikutnya: UNTUK SETIAP subgrup, terima jalan keluar[n][s][N]. Ketersediaan jalan keluar blok suara; publikasikan ulang di antara validators v yang tertarik sedemikian rupa Rantai[n + 1][v] = Rantai[n + 1][V ]. • ValidatorV : SAMPAI KONSENSUS Dimana: egress[n][from][to] adalah antrian egress saat ini informasi untuk postingan mulai dari parachain 'dari', ke parachain 'ke' di blok nomor 'n'. CollatorS adalah collator untuk parachain S. V alidators[n][s] adalah himpunan validators untuk parachain s di blok nomor n. Sebaliknya, Chain[n][v] adalah parachain yang validator v ditugaskan pada blok nomor n. block.egress[to] adalah jalan keluar antrian posting dari beberapa blok parachain yang parachain tujuan adalah untuk. Karena kolektor memungut biaya (transaksi) berdasarkan blok mereka menjadi kanonik dan mereka diberi insentif memastikan bahwa untuk setiap tujuan blok berikutnya, subgrupnya anggota diberitahu tentang antrian keluar dari sekarang blok. Validator diberi insentif hanya untuk membentuk konsensus pada blok (parachain), sehingga mereka tidak terlalu peduli blok kolator mana yang pada akhirnya menjadi kanonik. Di prinsipnya, seorang validator dapat membentuk kesetiaan dengan seorang kolator dan bersekongkol untuk mengurangi kemungkinan kolator lain blok menjadi kanonik, namun hal ini sulit untuk mengatur karena pemilihan acaktindakan validators untuk parachain dan dapat dilindungi dengan pengurangan biaya yang harus dibayar untuk blok parachain yang bertahan proses konsensus. 6.6.1. Ketersediaan Data Eksternal. Memastikan parachain data eksternal sebenarnya tersedia adalah masalah abadi sistem terdesentralisasi yang bertujuan untuk mendistribusikan beban kerja jaringan. Inti permasalahannya adalah ketersediaan masalah yang menyatakan bahwa karena itu tidak mungkin buatlah bukti ketersediaan non-interaktif atau jenis apa pun bukti ketidaktersediaan, agar sistem BFT berfungsi dengan baik memvalidasi setiap transisi yang kebenarannya bergantung pada ketersediaan beberapa data eksternal, jumlah maksimum dari node Bizantium yang dapat diterima, ditambah satu, dari sistem harus membuktikan data yang tersedia. Agar sistem dapat melakukan penskalaan dengan benar, seperti Polkadot, ini mengundang masalah: jika proporsi konstan validators harus membuktikan ketersediaan data, dan berasumsi bahwa validators ingin benar-benar menyimpan data sebelum menyatakannya tersedia, lalu bagaimana kita menghindarinya masalah kebutuhan bandwidth/penyimpanan yang meningkat seiring dengan ukuran sistem (dan karenanya jumlah validators)? Salah satu jawaban yang mungkin adalah dengan memiliki set terpisah dari validators (penjamin ketersediaan), yang pesanannya bertambah secara sublinear dengan ukuran Polkadot secara keseluruhan. Ini adalah dijelaskan dalam 6.5.3. Kami juga memiliki trik sekunder. Sebagai sebuah kelompok, pengumpul memiliki insentif intrinsik untuk memastikan bahwa semua data ada tersedia untuk parachain pilihan mereka karena tanpa itu mereka tidak dapat membuat blok lebih jauh dari yang mereka bisa mengumpulkan biaya transaksi. Kolator juga membentuk suatu kelompok, yang keanggotaannya bervariasi (karena sifat acaknya parachain validator grup) tidak sepele untuk dimasuki dan mudah

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 15 untuk membuktikan. Oleh karena itu, kolator baru-baru ini (mungkin dari beberapa ribu blok terakhir) diperbolehkan untuk mengajukan gugatan ketersediaan data eksternal untuk parachain tertentu blok ke validators untuk obligasi kecil. Validator harus menghubungi orang-orang dari subkelompok validator yang tampaknya melakukan pelanggaran yang memberikan kesaksian dan memperoleh serta mengembalikan data ke pengumpul atau mengeskalasi masalah dengan memberikan kesaksian tentang kurangnya ketersediaan (penolakan langsung untuk memberikan data dianggap sebagai pelanggaran penyitaan obligasi, oleh karena itu validator yang berperilaku buruk kemungkinan besar hanya akan putuskan sambungan) dan hubungi validator tambahan untuk menjalankan tes yang sama. Dalam kasus terakhir, obligasi kolator dikembalikan. Setelah kuorum validator yang dapat membuat kesaksian ketidaktersediaan tersebut tercapai, mereka dibebaskan, subkelompok yang berperilaku buruk akan dihukum, dan pemblokiran dikembalikan. 6.6.2. Perutean Postingan. Setiap header parachain menyertakan jalan keluar-trie-root; ini adalah akar dari percobaan yang mengandung bin berbasis perutean, setiap bin menjadi daftar gabungan dari pos-pos jalan keluar. Bukti merekle dapat diberikan di seluruh parachain validators untuk membuktikan bahwa parachain tertentu blok memiliki antrian keluar tertentu untuk parachain tujuan tertentu. Pada awal pemrosesan blok parachain, masing-masing antrian keluar parachain lain yang menuju blok tersebut adalah digabungkan ke dalam antrian masuknya blok kami. Kami berasumsi kuat, mungkin CSPR9, sub-blok yang memerintahkan untuk mencapai operasi deterministik yang tidak menawarkan pilih kasih di antara siapa pun pasangan blok parachain. Collator menghitung antrian baru dan menguras antrian jalan keluar sesuai dengan parachain logika. Isi antrian ingress ditulis secara eksplisit ke dalam blok parachain. Ini memiliki dua tujuan utama: pertama, ini berarti bahwa parachain dapat disinkronkan secara terpisah dari parachain lainnya. Kedua, ini menyederhanakan logistik data jika seluruh masuknya antrian tidak dapat diproses dalam satu blok; validators dan collator dapat memproses blok berikut tanpa harus mengambil data antrian secara khusus. Jika antrian masuknya parachain berada di atas ambang batas jumlah di akhir pemrosesan blok, kemudian ditandai jenuh pada rantai relai dan mungkin tidak ada pesan lebih lanjut dikirim ke sana sampai dibersihkan. Bukti Merkle adalah digunakan untuk menunjukkan kesetiaan operasi collator di bukti blok parachain. 6.6.3. Kritik. Satu kelemahan kecil yang berkaitan dengan dasar ini mekanismenya adalah serangan pasca bom. Di sinilah semuanya parachain mengirim postingan sebanyak mungkin ke parachain tertentu. Sementara ini mengikat targetnya antrian masuk sekaligus, tidak ada kerusakan yang terjadi berulang-ulang serangan DoS transaksi standar. Beroperasi secara normal, dengan serangkaian tersinkronisasi dengan baik dan collators tidak berbahaya dan validators, untuk N parachain, N × M total validators dan L kolator per parachain, kami dapat memecah total jalur data per blok menjadi: Validator: M −1+L+L: M −1 untuk validators lainnya di set parachain, L untuk setiap kolator menyediakan calon blok parachain dan L kedua untuk setiap kolator dari blok berikutnya yang memerlukan muatan keluar dari blok sebelumnya. (Yang terakhir ini sebenarnya lebih mirip kasus terburuk operasi karena kemungkinan besar kolator akan berbagi hal tersebut data.) Collator: M +kN: M untuk koneksi ke setiap relevan blok parachain validator, kN untuk menyemai muatan keluar ke beberapa subset dari setiap grup parachain validator untuk blok berikutnya (dan mungkin beberapa kolator favorit). Dengan demikian, jalur jalur data per node tumbuh secara linier dengan kompleksitas sistem secara keseluruhan. Sementara ini masuk akal, karena sistem berskala menjadi ratusan atau ribuan parachain, mungkin ada beberapa latensi komunikasi diserap dengan imbalan tingkat pertumbuhan kompleksitas yang lebih rendah. Dalam hal ini, algoritma perutean multi-fase dapat digunakan untuk mengurangi jumlah jalur sesaat dengan biaya memperkenalkan buffer penyimpanan dan latensi. 6.6.4. Perutean hiper-kubus. Perutean hyper-cube adalah mekanisme yang sebagian besar dapat dibangun sebagai perpanjangan dari mekanisme perutean dasar yang dijelaskan di atas. Intinya, daripada mengembangkan konektivitas node dengan jumlah parachain dan node sub-grup, kami hanya mengembangkannya logaritma parachain. Postingan mungkin transit di antara keduanya antrian beberapa penerjun payung dalam perjalanan menuju pengiriman akhir. Perutean itu sendiri bersifat deterministik dan sederhana. Kita mulai dengan membatasi jumlah sampah pada antrian masuk/keluar; bukannya jumlah total parachain, mereka adalahbasis perutean (b) . Ini akan ditetapkan sebagai nomornya perubahan parachain, dengan eksponen perutean (e) malah dinaikkan. Di bawah model ini, volume pesan kami tumbuh dengan O(be), dengan jalurnya tetap konstan dan latensi (atau jumlah blok yang diperlukan untuk pengiriman) dengan O(e). Model perutean kami adalah hypercube berdimensi e, dengan setiap sisi kubus memiliki b kemungkinan lokasi. Setiap blok, kami merutekan pesan sepanjang satu sumbu. Kami ganti sumbu dengan cara round-robin, sehingga menjamin waktu pengiriman blok e dalam kasus terburuk. Sebagai bagian dari pemrosesan parachain, terikat ke luar negeri pesan yang ditemukan dalam antrean masuk akan segera dirutekan ke tempat antrean keluar yang sesuai, mengingat nomor blok saat ini (dan dengan demikian dimensi perutean). Ini proses memerlukan transfer data tambahan untuk setiap hop pada jalur pengiriman, namun hal ini menjadi masalah tersendiri yang dapat dikurangi dengan menggunakan beberapa cara alternatif pengiriman muatan data dan hanya menyertakan referensi, daripada muatan penuh postingan di pasca-trie. Contoh perutean hyper-cube untuk suatu sistem dengan 4 parachain, b = 2 dan e = 2 mungkin: Fase 0, pada setiap pesan M: • sub0: jika Mdest ∈{2, 3} maka sendTo(2) lain tetap simpan • sub1: jika Mdest ∈{2, 3} maka sendTo(3) lain tetap simpan • sub2: jika Mdest ∈{0, 1} maka sendTo(0) lain tetap simpan • sub3: jika Mdest ∈{0, 1} maka sendTo(1) lain tetap simpan Fase 1, pada setiap pesan M: • sub0: jika Mdest ∈{1, 3} maka sendTo(1) lain tetap simpan • sub1: jika Mdest ∈{0, 2} maka sendTo(0) lain tetap simpan • sub2: jika Mdest ∈{1, 3} maka sendTo(3) lain tetap simpan • sub3: jika Mdest ∈{0, 2} maka sendTo(2) lain tetap simpan Dua dimensi di sini mudah dilihat sebagai yang pertama dua bit indeks tujuan; untuk blok pertama, itu bit tingkat tinggi saja yang digunakan. Penawaran blok kedua dengan bit orde rendah. Setelah keduanya terjadi (secara sewenang-wenang order) maka postingan akan dialihkan. 9pseudo-acak yang aman secara kriptografis

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 16 6.6.5. Memaksimalkan Kebetulan. Satu perubahan dasar proposal akan menghasilkan total tetap c2 −c validators, dengan c−1 validators di setiap subgrup. Setiap blok, bukan ada partisi ulang validators yang tidak terstruktur di antara parachain, sebagai gantinya untuk setiap subkelompok parachain, setiap validator akan ditugaskan ke yang unik dan berbeda sub-grup parachain di blok berikut. Ini akan terjadi mengarah ke invarian antara dua blok mana pun, untuk apa pun dua pasang parachain, ada dua validator yang telah bertukar tanggung jawab parachain. Meskipun hal ini tidak dapat digunakan untuk mendapatkan jaminan mutlak atas ketersediaan (satu validator kadang-kadang akan offline, meskipun demikian baik hati), namun tetap dapat mengoptimalkan kasus umum. Pendekatan ini bukannya tanpa komplikasi. Penambahan parachain juga memerlukan reorganisasi dari kumpulan validator. Selanjutnya jumlah validator, diikat dengan kuadrat jumlah parachain, awalnya akan sangat kecil dan akhirnya berkembang jauh terlalu cepat, menjadi tidak dapat dipertahankan setelah sekitar 50 parachain. Tidak ada satu pun dari masalah-masalah tersebut yang merupakan masalah mendasar. Dalam kasus pertama, reorganisasi set validator adalah sesuatu yang harus dilakukan tetap dilakukan secara rutin. Mengenai ukuran validator disetel, jika terlalu kecil, beberapa validator dapat ditetapkan ke parachain yang sama, menerapkan faktor bilangan bulat ke total keseluruhan validators. Mekanisme perutean multi-fase seperti Perutean Hypercube, yang dibahas di 6.6.4 akan membantu meringankan kebutuhan validator dalam jumlah besar ketika ada sejumlah besar rantai. 6.7. Validasi Parachain. Tujuan utama validator adalah untuk bersaksi, sebagai aktor yang mempunyai ikatan kuat, bahwa parachain itu blok tersebut valid, termasuk namun tidak terbatas pada transisi keadaan apa pun, termasuk transaksi eksternal apa pun, pelaksanaannya setiap pos tunggu di antrian masuk dan keadaan akhir dari antrian keluar. Prosesnya sendiri cukup sederhana. Setelah validator menyegel blok sebelumnya, mereka bebas untuk mulai bekerja menyediakan calon blok parachain kandidat untuk putaran konsensus berikutnya. Awalnya, validator menemukan kandidat blok parachain melalui kolator parachain (dijelaskan selanjutnya) atau satu dari rekannya-validators. Parachain memblokir data kandidat termasuk header blok, header blok sebelumnya, data masukan eksternal apa pun yang disertakan (untuk Ethereum dan Bitcoin, data tersebut akan disebut sebagai transaksi, namun pada prinsipnya data tersebut dapat mencakup struktur data arbitrer untuk tujuan arbitrer), data antrean keluar, dan data internal untuk membuktikan validitas transisi keadaan (untuk Ethereum ini akan menjadi berbagai node percobaan status/penyimpanan yang diperlukan untuk mengeksekusi setiap transaksi). Bukti eksperimental menunjukkan kumpulan data lengkap ini untuk blok Ethereum terbaru menjadi paling banyak beberapa ratus KiB. Secara bersamaan, jika belum dilakukan, validator akan menjadi mencoba mengambil informasi yang berkaitan dengan transisi blok sebelumnya, awalnya dari blok sebelumnya validators dan setelahnya dari semua validators yang menandatangani ketersediaan datanya. Setelah validator menerima blok kandidat tersebut, mereka kemudian memvalidasinya secara lokal. Proses validasi terdapat dalam modul validator kelas parachain, a modul perangkat lunak sensitif konsensus yang harus ditulis untuk setiap implementasi Polkadot (meskipun pada prinsipnya perpustakaan dengan C ABI dapat mengaktifkan satu perpustakaan dibagi antara implementasi dengan yang sesuai pengurangan keselamatan karena hanya memiliki satu implementasi “referensi”). Proses ini mengambil header blok sebelumnya dan memverifikasi identitasnya melalui rantai relai yang baru saja disepakati blok di mana hash-nya harus dicatat. Setelah validitas header induk dipastikan, parachain tertentu fungsi validasi kelas dapat dipanggil. Ini adalah fungsi tunggal yang menerima sejumlah bidang data (kira-kira yang diberikan sebelumnya) dan mengembalikan Boolean sederhana menyatakan keabsahan blok tersebut. Sebagian besar fungsi validasi tersebut akan memeriksa terlebih dahulu bidang header yang dapat diturunkan langsung darinya blok induk (misalnya induk hash, nomor). Mengikuti ini, mereka akan mengisi struktur data internal apa pun sebagai diperlukan dalam rangka proses transaksi dan/atau postingan. Untuk rantai mirip Ethereum, jumlah ini sama dengan mengisi a coba database dengan node yang akan diperlukan untuk eksekusi penuh transaksi. Jenis rantai lain mungkin memilikinya hal lainnyamekanisme perbaikan. Setelah selesai, postingan masuk dan transaksi eksternal (atau apa pun yang diwakili oleh data eksternal) akan ditampilkan diberlakukan, seimbang sesuai dengan spesifikasi rantai. (A default yang masuk akal mungkin mengharuskan semua postingan masuk diproses sebelum transaksi eksternal dilayani, namun hal ini harus ditentukan oleh logika parachain.) Melalui pemberlakuan ini, akan ada serangkaian posko keluar dibuat dan akan diverifikasi bahwa ini memang cocok calon kolator. Akhirnya, penduduknya cukup header akan diperiksa terhadap header kandidat. Dengan blok kandidat yang divalidasi sepenuhnya, validator kemudian dapat memilih hash dari headernya dan mengirimkan semua informasi validasi yang diperlukan ke co-validators di subgrupnya. 6.7.1. Kolator Parachain. Kolator parachain adalah operator tidak terikat yang memenuhi sebagian besar tugas penambang pada jaringan blockchain saat ini. Mereka spesifik ke parachain tertentu. Untuk beroperasi mereka harus pertahankan rantai relai dan sinkronisasi penuh parachain. Arti sebenarnya dari “disinkronkan sepenuhnya” akan bergantung pada kelas parachain, meskipun akan selalu mencakup keadaan antrean masuknya parachain saat ini. Dalam kasus Ethereum, hal ini juga melibatkan setidaknya pemeliharaan database Merkle-tree dari beberapa blok terakhir, tapi mungkin juga menyertakan berbagai struktur data lainnya termasuk Bloom filter untuk keberadaan akun, informasi keluarga, pencatatan output dan tabel pencarian terbalik untuk nomor blok. Selain menjaga kedua rantai tetap sinkron, itu juga harus “memancing” transaksi dengan menjaga antrian transaksi dan menerima transaksi yang divalidasi dengan benar dari jaringan publik. Dengan antrian dan rantai, itu benar mampu membuat kandidat blok baru untuk validator yang dipilih di setiap blok (yang identitasnya diketahui sejak rantai relai disinkronkan) dan mengirimkannya, bersama dengan berbagai informasi tambahan seperti bukti validitas, via jaringan rekan. Untuk masalahnya, ia memungut semua biaya yang berkaitan dengan transaksi yang disertakannya. Berbagai ilmu ekonomi beredar seputar hal ini pengaturan. Di pasar yang sangat kompetitif di mana ada jika kelebihan kolator, kemungkinan transaksinya biaya dibagikan dengan parachain validators untuk memberi insentif dimasukkannya blok kolator tertentu. Demikian pula,

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 17 beberapa kolator bahkan mungkin menaikkan biaya yang diperlukan harus dibayar agar blok tersebut lebih menarik validators. Dalam hal ini, pasar alami harus terbentuk dengan transaksi yang membayar biaya lebih tinggi melewati antrian dan memiliki inklusi yang lebih cepat dalam rantai. 6.8. Jaringan. Jaringan pada blockchains tradisional seperti Ethereum dan Bitcoin memiliki persyaratan yang cukup sederhana. Semua transaksi dan blokir disiarkan dalam gosip sederhana yang tidak terarah. Sinkronisasi lebih terlibat, khususnya dengan Ethereum tetapi kenyataannya logika ini terkandung di dalamnya strategi rekan daripada protokol itu sendiri yang menyelesaikan beberapa jenis pesan permintaan dan jawaban. Meskipun Ethereum membuat kemajuan pada penawaran protokol saat ini dengan protokol devp2p, yang memungkinkan banyak hal subprotokol yang akan dimultipleks melalui satu koneksi peer dan dengan demikian memiliki banyak dukungan peer overlay yang sama protokol p2p secara bersamaan, bagian Ethereum dari protokolnya masih relatif sederhana dan p2p protokol untuk sementara waktu masih belum selesai dengan hal-hal penting fungsionalitas hilang seperti dukungan QoS. Sayangnya, ada keinginan untuk membuat protokol “web 3” yang lebih umum gagal, dengan satu-satunya proyek yang menggunakannya secara eksplisit didanai dari penjualan massal Ethereum. Persyaratan untuk Polkadot lebih substansial. Daripada jaringan yang sepenuhnya seragam, Polkadot memiliki beberapa jenis peserta yang masing-masing memiliki persyaratan berbeda mengenai susunan rekannya dan beberapa jaringan “jalan” yang cenderung dibicarakan oleh peserta data tertentu. Ini berarti hamparan jaringan yang jauh lebih terstruktur—dan protokol yang mendukungnya— kemungkinan besar akan diperlukan. Selain itu, perluasan untuk memfasilitasi penambahan di masa depan seperti “rantai” jenis baru mungkin terjadi sendiri memerlukan struktur overlay baru. Sedangkan pembahasan mendalam tentang cara networking protokol mungkin terlihat berada di luar cakupan dokumen ini, beberapa analisis persyaratan masuk akal. Kita bisa secara kasar membagi peserta jaringan kami menjadi dua set (rantai relai, parachain) masing-masing dari tiga himpunan bagian. Kita bisa juga menyatakan bahwa masing-masing peserta parachain saja tertarik untuk berbicara di antara mereka sendiri dan bukannya peserta di parachain lainnya: • Peserta rantai relai: • Validator: P, dibagi menjadi himpunan bagian P[s] untuk masing-masingnya parachain • Penjamin Ketersediaan: A (ini dapat diwakili oleh Validator dalam bentuk dasar protokol) • Klien rantai relai: M (perhatikan anggota masing-masing set parachain juga akan cenderung menjadi anggota M) • Peserta Parachain: • Pengumpul Parachain: C[0], C[1], . . . • Nelayan Parachain: F[0], F[1], . . . • Klien Parachain: S[0], S[1], . . . • Klien ringan Parachain: L[0], L[1], . . . Secara umum kami menyebutkan kelas-kelas komunikasi tertentu akan cenderung terjadi di antara anggota himpunan ini: • P | SEBUAH <-> P | J: Itu penuh mengatur dari validators/penjamin harus menjadi terhubung dengan baik untuk mencapai konsensus. • P[s] <-> C[s] | P[s]: Setiap validator sebagai anggota grup parachain tertentu akan cenderung bergosip dengan anggota lainnya serta kolator parachain itu untuk menemukan dan berbagi kandidat blok. • A <-> P[s] | C | A: Setiap penjamin ketersediaan perlu mengumpulkan lintas rantai yang sensitif terhadap konsensus data dari validator yang ditugaskan padanya; kolator juga dapat mengoptimalkan peluang konsensus mengenai hal tersebut memblokir dengan mengiklankannya ke penjamin ketersediaan. Begitu mereka punya, datanya akan dicairkan ke penjamin lainnya untuk memfasilitasi konsensus. • P[s] <-> A | P[s']: Parachain validators akan perlu mengumpulkan data masukan tambahan dari kumpulan validator sebelumnya atau penjamin ketersediaan. • F[s] <-> P: Saat melaporkan, nelayan boleh menempatkan klaim dengan peserta mana pun. • M <-> M | P | J: Klien rantai relai umum menyalurkan data dari validator dan penjamin. • S[s] <-> S[s] | P[s] | A: Klien Parachain mencairkan data dari validator/penjamin. • L[s] <-> L[s] | S[s]: Klien ringan Parachain menyalurkan data dari klien penuh. Untuk memastikan mekanisme transportasi yang efisien, “flat” jaringan overlay—seperti devp2p Ethereum—di mana masing-masing node tidak (secara tidak sewenang-wenang) membedakan kebugarannya teman sebaya sepertinya tidak cocok. Cukup dapat diperluas mekanisme seleksi dan penemuan rekan mungkin diperlukan untuk dimasukkan dalam protokol serta agresif merencanakan tinjauan ke depan untuk memastikan jenis rekan yang tepat adalah conne yang “secara kebetulan”.diperiksa pada waktu yang tepat. Strategi tata rias teman yang tepat akan berbeda untuk setiap kelas peserta: untuk skala yang tepat multi-rantai, collator harus terus menerus menghubungkan kembali ke validator yang dipilih, atau wasiat memerlukan perjanjian berkelanjutan dengan subkumpulan validators untuk memastikan mereka tidak terputus selama sebagian besar waktu mereka tidak berguna untuk validator itu. Collator juga secara alami akan berusaha mempertahankannya atau koneksi yang lebih stabil menjadi penjamin ketersediaan ditetapkan untuk memastikan penyebaran cepat dari isu-isu yang sensitif terhadap konsensus data. Penjamin ketersediaan sebagian besar bertujuan untuk mempertahankan a koneksi yang stabil satu sama lain dan ke validators (untuk konsensus dan data parachain yang penting bagi konsensus mereka membuktikannya), serta beberapa kolator (untuk parachain data) dan beberapa nelayan dan klien penuh (untuk menyebar informasi). Validator akan cenderung mencari validator lain, terutama yang berada dalam subgrup yang sama dan apa pun collators yang dapat memasok mereka dengan kandidat blok parachain. Nelayan, serta rantai estafet umum dan parachain klien umumnya bertujuan untuk menjaga koneksi tetap terbuka untuk a validator atau penjamin, tetapi banyak node lain yang serupa untuk diri mereka sendiri sebaliknya. Klien ringan parachain juga bertujuan untuk terhubung ke klien penuh parachain, jika bukan hanya klien ringan parachain lainnya. 6.8.1. Masalah Peer Churn. Dalam proposal protokol dasar, masing-masing himpunan bagian ini terus-menerus berubah secara acak dengan setiap blok ketika validator ditugaskan untuk memverifikasi transisi parachain dipilih secara acak. Ini bisa menjadi masalah jika node yang berbeda (non-peer) memerlukannya meneruskan data antara satu sama lain. Kita harus mengandalkannya jaringan rekan yang terdistribusi secara adil dan terhubung dengan baik

POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 18 memastikan bahwa jarak hop (dan latensi terburuk) hanya bertambah seiring dengan logaritma ukuran jaringan (protokol seperti Kademlia [13] dapat membantu di sini), atau seseorang harus melakukannya memperkenalkan waktu blok yang lebih lama untuk memungkinkan negosiasi koneksi yang diperlukan berlangsung untuk mempertahankan kumpulan rekan itu mencerminkan kebutuhan komunikasi node saat ini. Tak satu pun dari solusi ini yang bagus: waktu blok yang lama dipaksakan pada jaringan dapat membuatnya tidak berguna aplikasi dan rantai tertentu. Bahkan sangat adil dan jaringan yang terhubung akan menghasilkan pemborosan yang besar bandwidth saat diskalakan karena adanya node yang tidak tertarik untuk meneruskan data yang tidak berguna bagi mereka. Meskipun kedua arah mungkin merupakan bagian dari solusi, pengoptimalan yang masuk akal untuk membantu meminimalkan latensi menjadi untuk membatasi volatilitas parachain ini validator set, baik menugaskan kembali keanggotaan hanya di antara rangkaian blok (misalnya dalam kelompok 15, yang dalam waktu 4 detik waktu blok berarti mengubah koneksi hanya sekali per menit) atau dengan merotasi keanggotaan secara bertahap, misalnya diubah oleh satu anggota pada satu waktu (misalnya jika ada adalah 15 validator yang ditugaskan ke setiap parachain, maka rata-rata akan memakan waktu satu menit penuh antara parachain yang benar-benar unik set). Dengan membatasi jumlah peer churn, dan memastikan bahwa koneksi peer yang menguntungkan terjalin dengan baik maju melalui prediktabilitas parsial parachain set, kami dapat membantu memastikan setiap node tetap permanen pemilihan rekan secara kebetulan. 6.8.2. Jalur menuju Protokol Jaringan yang Efektif. Kemungkinan besar upaya pembangunan yang paling efektif dan masuk akal akan fokus pada pemanfaatan protokol yang sudah ada milik kita sendiri. Ada beberapa protokol basis peer-to-peer yang ada kami dapat menggunakan atau menambah termasuk devp2p milik Ethereum [22], libp2p IPFS [1] dan GNUnet [4] GNU. Tinjauan lengkap mengenai protokol-protokol ini dan relevansinya untuk membangun a jaringan peer modular yang mendukung jaminan struktural tertentu, peer steering dinamis, dan sub-protokol yang dapat diperluas jauh di luar cakupan dokumen ini tetapi akan menjadi langkah penting dalam implementasi Polkadot. 7. Kepraktisan Protokol 7.1. Pembayaran Transaksi Antar Rantai. Meskipun bagus sejumlah besar kebebasan dan kesederhanaan diperoleh dengan menghilangkan kebutuhan akan kerangka akuntansi sumber daya komputasi holistik seperti gas Ethereum, hal ini menimbulkan pertanyaan penting: tanpa gas, bagaimana sebuah parachain bisa bekerja? menghindari parachain lain memaksanya melakukan komputasi? Sementara kita bisa mengandalkan antrian transaksi-pasca masuknya buffer untuk mencegah satu rantai mengirim spam ke rantai lainnya data transaksi, tidak ada mekanisme setara yang disediakan oleh protokol untuk mencegah spamming dalam pemrosesan transaksi. Ini adalah masalah yang diserahkan pada tingkat yang lebih tinggi. Sejak rantai bebas untuk melampirkan semantik sewenang-wenang ke yang masuk data transaksi-posting, kami dapat memastikan perhitungan itu harus dibayar sebelum memulai. Senada dengan itu model yang dianut oleh Ethereum Ketenangan, bisa kita bayangkan kontrak “pembobolan” dalam parachain yang memungkinkan a validator untuk mendapatkan jaminan pembayaran sebagai imbalan atas penyediaan sejumlah sumber daya pemrosesan tertentu. Sumber daya ini dapat diukur dalam bentuk seperti gas, namun bisa juga berupa model yang benar-benar baru seperti model waktu-untuk-eksekusi yang subyektif atau model biaya tetap seperti Bitcoin. Dengan sendirinya, hal ini tidak terlalu berguna karena kita tidak dapat langsung berasumsi bahwa penelepon off-chain telah tersedia untuk mereka mekanisme nilai apa pun yang dikenali oleh pembobolan tersebut kontrak. Namun, kita dapat membayangkan kontrak “breakout” sekunder dalam rantai sumber. Kedua kontrak tersebut bersama-sama akan membentuk jembatan, saling mengenal dan memberikan kesetaraan nilai. (Staking-tokens, tersedia untuk masing-masing, dapat digunakan untuk menyelesaikan neraca pembayaran.) Memanggil rantai lain seperti itu berarti melakukan proxy melalui jembatan ini, yang akan menyediakan sarana menegosiasikan transfer nilai antar rantai untuk membayar sumber daya komputasi yang diperlukan pada parachain tujuan. 7.2. Tambahan Rantai. Sementara itu tambahan dari sebuah parachain adalah operasi yang relatif murah, tidak gratis. Lebih banyak parachain berarti lebih sedikit validator per parachain dan, pada akhirnya, sejumlah validator yang lebih besar masing-masing dengan a obligasi rata-rata berkurang. Sementara masalah biaya paksaan yang lebih kecil untuk menyerang parachain dapat diatasi nelayan, pertumbuhan validator pada dasarnya memaksa a tingkat latensi yang lebih tinggi karena mekanisme konsensus yang mendasari sayaitu. Selanjutnya masing-masing parachain membawa serta potensi kesedihan validators dengan an algoritma validasi yang terlalu membebani. Dengan demikian, akan ada “harga” tertentu yang validators dan/atau komunitas pemangku kepentingan akan mengekstraksi untuk penambahan parachain baru. Pasar rantai ini akan melakukannya mungkin melihat penambahan: • Rantai yang kemungkinan besar tidak membayar kontribusi bersih (dalam hal mengunci atau membakar staking tokens) untuk dijadikan bagian (misalnya rantai konsorsium, Rantai Doge, rantai khusus aplikasi); • rantai yang memberikan nilai intrinsik pada jaringan melalui penambahan fungsionalitas tertentu yang sulit untuk mencapai tujuan lain (misalnya kerahasiaan, skalabilitas internal, ikatan layanan). Pada dasarnya, komunitas pemangku kepentingan perlu melakukan hal tersebut mendapatkan insentif untuk menambah rantai anak—baik secara finansial maupun melalui keinginan untuk menambahkan rantai fitur ke relai. Diharapkan bahwa penambahan rantai baru akan memberikan dampak yang sangat besar periode pemberitahuan singkat untuk penghapusan, memungkinkan rantai baru untuk melakukan penghapusan dapat dicoba tanpa risiko kompromi proposisi nilai jangka menengah atau panjang. 8. Kesimpulan Kami telah menguraikan arah yang mungkin diambil untuk penulis a protokol multi-rantai yang heterogen dan terukur dengan potensi untuk kompatibel dengan protokol tertentu yang sudah ada sebelumnya blockchain jaringan. Di bawah protokol seperti itu, para peserta bekerja demi kepentingan pribadi untuk menciptakan sistem keseluruhan yang dapat diperluas dengan cara yang sangat gratis dan tanpa biaya yang biasa bagi pengguna yang sudah ada. berasal dari desain standar blockchain. Kami telah memberi garis besar arsitektur yang diperlukan termasuk sifat peserta, insentif ekonomi mereka dan proses yang harus mereka ikuti. Kita punya mengidentifikasi desain dasar dan mendiskusikan kekuatannya dan keterbatasan; oleh karena itu kami memiliki petunjuk lebih lanjut yang mana dapat meringankan keterbatasan tersebut dan memberikan landasan lebih lanjut menuju solusi blockchain yang sepenuhnya dapat diskalakan.POLKADOT: VISI KERANGKA MULTI-RANTAI HETEROGEN DRAFT 1 19 8.1. Materi Hilang dan Pertanyaan Terbuka. Forking jaringan selalu merupakan kemungkinan dari implementasi protokol yang berbeda. Pemulihan dari hal seperti itu kondisi luar biasa tidak dibahas. Mengingat jaringan akan mempunyai periode penyelesaian yang bukan nol, pemulihan dari forking rantai relai seharusnya tidak menjadi masalah besar, namun memerlukan integrasi yang cermat protokol konsensus. Penyitaan obligasi dan sebaliknya pemberian imbalan telah terjadi belum dieksplorasi secara mendalam. Saat ini kami menerima imbalan disediakan berdasarkan prinsip pemenang mengambil semuanya: hal ini mungkin tidak berlaku memberikan model insentif terbaik bagi nelayan. Proses pengungkapan komitmen jangka pendek akan memungkinkan banyak nelayan untuk mengklaim hadiah dengan memberikan distribusi hadiah yang lebih adil, namun proses tersebut dapat menyebabkan latensi tambahan di penemuan perilaku buruk. 8.2. Ucapan Terima Kasih. Terima kasih banyak untuk semuanya pembaca bukti yang telah membantu menjelaskan hal ini secara samar-samar bentuk yang rapi. Secara khusus, Peter Czaban, Bj¨orn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler dan Jack Petersson. Terima kasih untuk semuanya orang-orang yang telah menyumbangkan ide atau permulaan Oleh karena itu, Marek Kotewicz dan Aeron Buchanan layak mendapat perhatian khusus. Dan terima kasih kepada semua orang atas bantuan mereka sepanjang jalan. Semua kesalahan adalah kesalahan saya sendiri. Bagian dari pekerjaan ini, termasuk penelitian awal algoritma konsensus, sebagian didanai oleh Inggris Pemerintah di bawah program Innovate UK.