Polkadot: Heterojen Çok Zincirli Çerçeve Vizyonu

Polkadot: Vision for a Heterogeneous Multi-Chain Framework

Yazan Gavin Wood · 2016

🇺🇸 English (Orijinal)

🇹🇷 Türkçe (Çeviri)

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

Özet

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 DR. GAVİN AHŞAP KURUCU, ETHEREUM & PARİTE [email protected] Özet. Günümüzün blockchain mimarilerinin tümü, özellikle pratik genişletilebilirlik ve ölçeklenebilirlik araçlarının yanı sıra bir dizi sorundan muzdariptir. Bunun, fikir birliği mimarisinin çok önemli iki parçasını birbirine bağlamasından kaynaklandığına inanıyoruz: kanoniklik ve geçerlilik birbirine çok yakındır. Bu makale, heterojen çoklu zincir mimarisini tanıtmaktadır. bu ikisini temelde birbirinden ayırıyor. Bu iki parçayı bölümlere ayırarak ve sağlanan genel işlevselliği mutlak minimumda tutarak Güvenlik ve ulaşım açısından, çekirdeğin yerinde genişletilebilirliğine yönelik pratik araçlar sunuyoruz. Ölçeklenebilirlik şu şekilde ele alınır: bu iki işleve böl ve yönet yaklaşımı, bağlı çekirdeğin ölçeğini, teşvik yoluyla genişletiyor güvenilmeyen genel düğümler. Bu mimarinin heterojen doğası, çok farklı türden konsensüs sistemlerinin güvene dayalı olmayan, tamamen merkezi olmayan bir "federasyon" içinde birlikte çalışmasına olanak tanıyarak, açık ve kapalı ağların güvensiz erişime sahip olmasına olanak tanır. Birbirimiz. Aşağıdakiler gibi önceden var olan bir veya daha fazla ağ ile geriye dönük uyumluluk sağlamanın bir yolunu ortaya koyduk: Ethereum. Böyle bir sistemin pratik olarak genel arayışta temel düzeyde yararlı bir bileşen sağladığına inanıyoruz. Küresel ticarette ölçeklenebilirlik ve gizlilik düzeylerine ulaşabilen uygulanabilir bir sistem. 1. Önsöz Bunun teknik bir “vizyon” özeti olması amaçlanmıştır blockchain paradigmasını daha da geliştirmek için alınabilecek olası bir yön ve bu yönün neden mantıklı olduğuna dair bazı gerekçeler. Şurada yer alıyor: Gelişimin bu aşamasında mümkün olduğu kadar fazla ayrıntı somut bir iyileşme sağlayabilecek bir sistem blockchain teknolojisinin çeşitli yönleri. Resmi veya başka türlü bir spesifikasyon olması amaçlanmamıştır. Kapsamlı olması ya da bir olması amaçlanmamıştır. son tasarım. Temel olmayan hususları kapsaması amaçlanmamıştır. API'ler, bağlamalar, diller ve kullanım. Bu özellikle deneyseldir; nerede parametreler belirtilirse, değişmeleri muhtemeldir. Mekanizmalar topluluğa yanıt olarak eklenebilir, geliştirilebilir ve kaldırılabilir fikirler ve eleştiriler. Bu makalenin büyük bir kısmı muhtemelen Deneysel kanıt ve prototiplemenin sağladığı gibi revize edilebilir Neyin işe yarayıp neyin yaramayacağına dair bize bilgi verin. Bu belge, protokolün temel bir tanımını ve alınabilecek talimatlara ilişkin fikirleri içerir. çeşitli yönleri geliştirmek. Çekirdek olması öngörülüyor açıklama bir başlangıç için başlangıç noktası olarak kullanılacaktır bir dizi kavram kanıtı. Son bir “versiyon 1.0” şu şekilde olacaktır: kanıtlanmış ve kararlı hale gelen ek fikirlerle birlikte bu rafine protokole dayanmaktadır. Projenin hedeflerine ulaşması için gerekli olan 1.1. Tarih. • 09/10/2016: 0.1.0'a dayanıklı1 • 20/10/2016: 0.1.0'a dayanıklı2 • 01/11/2016: 0.1.0'a dayanıklı3 • 10/11/2016: 0.1.0 2. Giriş Blok zincirleri, “Nesnelerin İnterneti” de dahil olmak üzere birçok alanda büyük fayda vaat ediyor (IoT), finans, yönetişim, kimlik yönetimi, web merkezi olmayanlaştırma ve varlık takibi. Ancak buna rağmen teknolojik vaat ve büyük konuşma, henüz göremedik mevcut teknolojinin önemli gerçek dünyaya yayılması. Bunun günümüzün beş önemli başarısızlığından kaynaklandığına inanıyoruz. teknoloji yığınları: Ölçeklenebilirlik: Küresel olarak ne kadar kaynak harcanıyor? sistemin tek bir işlemi işlemesi için işleme, bant genişliği ve depolama ve kaç tane işlemler makul bir şekilde gerçekleştirilebilir zirve koşulları? Yalıtılabilirlik: Çoklu bireylerin farklı ihtiyaçları Taraflar ve başvurular aynı çerçeve altında optimuma yakın bir düzeyde ele alınabiliyor mu? Geliştirilebilirlik: Araçlar ne kadar iyi çalışıyor? Yap API'ler geliştiricilerin ihtiyaçlarını karşılıyor mu? Eğitim materyalleri mevcut mu? Doğru entegrasyonlar mevcut mu? Yönetişim: Ağ esnek kalabilir mi? zaman içinde gelişip uyum sağlıyor mu? Kararlar olabilir mi Yeterli kapsayıcılık, meşruluk ve etkili bir liderlik sağlamak için şeffaflık merkezi olmayan sistem? Uygulanabilirlik: Teknoloji gerçekten kendi başına yakıcı bir ihtiyacı karşılıyor mu? Aradaki boşluğu kapatmak için başka bir "ara katman yazılımı" gerekli mi? gerçek uygulamalar? Bu çalışmamızda ilk ikisini ele almayı amaçlıyoruz. Sorunlar: ölçeklenebilirlik ve yalıtılabilirlik. Bununla birlikte, inanıyoruz Polkadot çerçevesi bu sorun sınıflarının her birinde anlamlı iyileştirmeler sağlayabilir. Modern, verimli blockchain uygulamalar gibi Eşlik Ethereum istemcisi [17] işlem yapabilirfazla Performanslı tüketici donanımı üzerinde çalışırken saniyede 3.000 işlem. Ancak mevcut gerçek dünya blockchain ağlar pratik olarak yaklaşık 30 ile sınırlıdır saniye başına işlemler. Bu sınırlama temel olarak mevcut eşzamanlı konsensüs mekanizmalarının geniş zamanlama güvenlik marjları gerektirmesinden kaynaklanmaktadır. nedeniyle daha da kötüleşen beklenen işlem süresi 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.

giriiş

Blok zincirleri, “Nesnelerin İnterneti” de dahil olmak üzere birçok alanda büyük fayda vaat ediyor (IoT), finans, yönetişim, kimlik yönetimi, web merkezi olmayanlaştırma ve varlık takibi. Ancak buna rağmen teknolojik vaat ve büyük konuşma, henüz göremedik mevcut teknolojinin önemli gerçek dünyaya yayılması. Bunun günümüzün beş önemli başarısızlığından kaynaklandığına inanıyoruz. teknoloji yığınları: Ölçeklenebilirlik: Küresel olarak ne kadar kaynak harcanıyor? sistemin tek bir işlemi işlemesi için işleme, bant genişliği ve depolama ve kaç tane işlemler makul bir şekilde gerçekleştirilebilir zirve koşulları? Yalıtılabilirlik: Çoklu bireylerin farklı ihtiyaçları Taraflar ve başvurular aynı çerçeve altında optimuma yakın bir düzeyde ele alınabiliyor mu? Geliştirilebilirlik: Araçlar ne kadar iyi çalışıyor? Yap API'ler geliştiricilerin ihtiyaçlarını karşılıyor mu? Eğitim materyalleri mevcut mu? Doğru entegrasyonlar mevcut mu? Yönetişim: Ağ esnek kalabilir mi? zaman içinde gelişip uyum sağlıyor mu? Kararlar olabilir mi Yeterli kapsayıcılık, meşruluk ve etkili bir liderlik sağlamak için şeffaflık merkezi olmayan sistem? Uygulanabilirlik: Teknoloji gerçekten kendi başına yakıcı bir ihtiyacı karşılıyor mu? Aradaki boşluğu kapatmak için başka bir "ara katman yazılımı" gerekli mi? gerçek uygulamalar? Bu çalışmamızda ilk ikisini ele almayı amaçlıyoruz. Sorunlar: ölçeklenebilirlik ve yalıtılabilirlik. Bununla birlikte, inanıyoruz Polkadot çerçevesi bu sorun sınıflarının her birinde anlamlı iyileştirmeler sağlayabilir. Modern, verimli blockchain uygulamalar gibi Eşlik Ethereum istemcisi [17] şunu aşabilir: Performanslı tüketici donanımı üzerinde çalışırken saniyede 3.000 işlem. Ancak mevcut gerçek dünya blockchain ağlar pratikte yaklaşık 30 ile sınırlıdır saniye başına işlemler. Bu sınırlama temel olarak mevcut eşzamanlı konsensüs mekanizmalarının geniş zamanlama güvenlik marjları gerektirmesinden kaynaklanmaktadır. nedeniyle daha da kötüleşen beklenen işlem süresiPOLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 2 Daha yavaş uygulamaları destekleme arzusu. Bunun nedeni altta yatan fikir birliği mimarisi: durum geçiş mekanizması veya tarafların bir araya geldiği araçlar ve işlemleri yürütür, mantığı temelden birbirine bağlıdır fikir birliğine varılmış “kanonikleştirme” mekanizmasına veya Tarafların çeşitli seçeneklerden biri üzerinde anlaşmaya vardıkları araç mümkün, geçerli, geçmişler. Bu, hem Bitcoin [15] ve Ethereum [5,23] gibi proof-of-work (PoW) sistemleri hem de NXT [8] ve Bitshares [12] gibi stake kanıtı (PoS) sistemleri için eşit derecede geçerlidir: sonuçta hepsi aynı handikaptan muzdariptir. Bu basit bir blockchains'nin başarıya ulaşmasına yardımcı olan strateji. Ancak, bu iki mekanizmayı tek bir ünitede sıkı bir şekilde birleştirerek protokolün yanı sıra birden fazla farklı öğeyi de bir araya getiriyoruz farklı risk profillerine, farklı ölçeklenebilirlik gereksinimlerine ve farklı gizlilik ihtiyaçlarına sahip aktörler ve uygulamalar. Tek beden herkese uymaz. Çoğu zaman durum böyledir Geniş bir kitleye ulaşma arzusunda olan bir ağ, en düşük ortak paydayla sonuçlanan bir muhafazakarlık derecesini benimser optimal olarak az sayıda kişiye hizmet vermek ve sonuçta başarısızlığa yol açmak Bazen yenilik yapma, performans gösterme ve uyum sağlama yeteneğinde dramatik bir şekilde öyle. Örneğin bazı sistemler. Factom [21] durum geçiş mekanizmasını tamamen bırakın. Ancak çoğu Arzuladığımız fayda, geçiş durumuna geçme yeteneğini gerektirir paylaşılan bir durum makinesine göre. Bırakmak çözer alternatif bir sorun; bir alternatif sunmuyor çözüm. Bu nedenle, makul bir yönün olduğu açık görünüyor ölçeklenebilir merkezi olmayan bir bilişime giden yolu keşfetmek platform, fikir birliği mimarisini birbirinden ayırmaktır. durum geçiş mekanizması. Ve belki de şaşırtıcı olmayan bir şekilde bu, Polkadot'nın ölçeklenebilirliğe çözüm olarak benimsediği stratejidir. 2.1. Protokol, Uygulama ve Ağ. Beğen Bitcoin ve Ethereum, Polkadot aynı anda bir ağ protokolüne ve (şimdiye kadar varsayılan) birincil ağ protokolüne atıfta bulunur Bu protokolü çalıştıran genel ağ. Polkadot ücretsiz ve açık bir proje olarak tasarlanmıştır; protokol spesifikasyonu Creative Commons lisansı altındadır ve kod FLOSS lisansı altına yerleştiriliyor. Proje açık bir şekilde geliştirildi ve katkıları kabul etti nerede faydalı olurlarsa olsunlar. RFC'lerden oluşan bir sistem, pek de farklı değil Python Geliştirme Önerileri, bir araç sağlayacaktır Protokol değişiklikleri ve yükseltmeleri üzerinde kamuya açık işbirliği yapmak. Polkadot protokolünü ilk uygulamamız Parite Polkadot Platformu olarak bilinecek ve API ile birlikte tam bir protokol uygulamasını içerir bağlamalar. Diğer Eşlik blockchain uygulamalarında olduğu gibi, PPP, genel amaçlı bir blockchain teknoloji yığını olacak şekilde tasarlanmıştır; ne yalnızca genel bir ağ için ne de özel/konsorsiyum operasyonu. Gelişimi bu şekilde far dahil olmak üzere çeşitli taraflarca finanse edildi İngiliz hükümetinden bir hibe. Yine de bu belgede Polkadot şu şekilde açıklanmaktadır: halka açık bir ağın bağlamı. Genel bir ağda öngördüğümüz işlevsellik, gerekli olanın bir üst kümesidir. alternatif (örn. özel ve/veya konsorsiyum) ayarlar. Ayrıca bu bağlamda Polkadot'nin tam kapsamı daha net bir şekilde tanımlanıp tartışılacaktır. Bu şu anlama geliyor okuyucu belirli mekanizmaların olabileceğinin farkında olmalıdır. Polkadot ile doğrudan alakalı olmayan şekilde tanımlanmalı (örneğin diğer genel ağlarla birlikte çalışma) kamuya açık olmayan (“izin verilen”) durumlarda konuşlandırıldığında. 2.2. Önceki çalışma. Temel fikir birliğinin devlet geçişinden ayrılması gayri resmi olarak önerildi en az iki yıl boyunca özel olarak - Max Kaye, devrimin ilk günlerinde böyle bir stratejinin savunucusuydu. Ethereum. Zincir olarak bilinen daha karmaşık ölçeklenebilir bir çözüm tarihi Haziran 2014'e kadar uzanan ve ilk kez daha sonra yayınlanan lifler o yıl1, şeffaf bir zincirler arası yürütme mekanizması sağlayan tek bir aktarma zinciri ve birden fazla homojen zincirin gerekliliği ortaya çıktı. Uyumsuzluğun bedeli ödendi işlem gecikmesi yoluyla - işlem gerektiren işlemler sistemin farklı bölümlerinin koordinasyonu işlenmesi daha uzun sürer. Polkadot mimarisinin çoğunu bundan ve takip eden görüşmelerden alıyor Tasarımı ve hükümleri açısından büyük farklılıklar gösterse de çeşitli insanlar tarafından tercih edilir. Polkadot ile karşılaştırılabilecek bir sistem olmasa da aslında üretimde, bazı alakalı birkaç sistem önemli düzeyde az da olsa önerilmiştir. detay. Bu öneriler şunlar olabilir:sistemlere ayrılmış küresel olarak tutarlılık kavramını düşüren veya azaltan küresel bir hizmet sağlamaya çalışan devlet makinesi homojen parçalar aracılığıyla tutarlı tekli makine ve yalnızca heterojenliği hedefleyenler. 2.2.1. Küresel Devleti olmayan sistemler. Factom [21], uygun olmayan şekilde kanoniklik gösteren bir sistemdir geçerlilik, verilerin kronikleştirilmesine etkili bir şekilde izin verir. Küresel devletten kaçınma ve zorluklar nedeniyle bunun getirdiği ölçeklendirme ile ölçeklenebilir bir çözüm sayılabilir. Ancak daha önce de belirtildiği gibi set çözdüğü problemlerin sayısı kesinlikle ve önemli ölçüde daha azdır. Tangle [18] fikir birliği sistemlerine yeni bir yaklaşımdır. İşlemleri bloklar halinde düzenlemek ve durum değişikliklerine küresel olarak kanonik bir sıralama vermek için sıkı bir şekilde bağlantılı bir liste üzerinde fikir birliği oluşturmak yerine, yoğun şekilde yapılandırılmış bir sıralama fikrinden büyük ölçüde vazgeçilir ve bunun yerine daha önceki öğelerin kanonikleştirilmesine yardımcı olan daha sonraki öğelerle birlikte bağımlı işlemlerin yönlendirilmiş, döngüsel olmayan bir grafiğini zorlar açık referans yoluyla. Keyfi durum değişiklikleri için, bu bağımlılık grafiği hızla kontrol edilemez hale gelecektir, ancak çok daha basit olan UTXO model2 için bu şu şekilde olur: oldukça makul. Çünkü sistem sadece gevşek bir şekilde tutarlıdır ve işlemler genellikle birbirinden bağımsızdır. Öte yandan, büyük miktarda küresel paralellik oldukça doğal. UTXO modelini kullanmanın etkisi var Tangle'ı tamamen değer aktarımı sağlayan bir "para birimi" ile sınırlamak daha genel veya genişletilebilir bir şey yerine sistem. Üstelik katı küresel tutarlılık olmadan, mutlak bir kontrole ihtiyaç duyma eğiliminde olan diğer sistemlerle etkileşim Sistem durumu hakkında derece bilgisi pratik hale gelir. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2harcanmamış işlem çıktısı, Bitcoin'nin kullandığı model, burada durum etkin olarak bir değerle ilişkili adres kümesidir; işlemler bu tür adresleri bir araya getirir ve bunları toplamı eşdeğer olan yeni bir adres kümesi halinde yeniden düzenler

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 3 2.2.2. Heterojen Zincir Sistemleri. Yan zincirler [3] bir ana Bitcoin zinciri arasında güvenilmez etkileşime izin verecek Bitcoin protokolüne önerilen ekleme ve ek yan zincirler. Herhangi bir hüküm bulunmamaktadır Yan zincirler arasındaki 'zengin' etkileşimin derecesi: etkileşim, yan zincirlerin birbirine bağlanmasına izin vermekle sınırlı olacaktır. yerel düzeyde birbirlerinin varlıklarının koruyucuları jargon—iki yönlü sabit 3. Nihai vizyon, Bitcoin para biriminin sağlanabileceği bir çerçeveye yöneliktir. sabitleme yoluyla ek, eğer çevresel ise, işlevsellik daha egzotik durum geçişiyle diğer bazı zincirlere Bitcoin protokolünün izin verdiği sistemler. Bu anlamda, Yan zincirler ölçeklenebilirlikten ziyade genişletilebilirliğe yöneliktir. Aslında yan zincirlerin geçerliliğine ilişkin temelde hiçbir hüküm yoktur; Bir zincirden tokens (ör. Bitcoin) bir yan zincir adına tutulanlar yalnızca Yan zincirin madencileri kanonikleştirmeye teşvik etme yeteneği geçerli geçişler Bitcoin ağının güvenliği başkaları adına çalışmaya kolaylıkla geçiş yapılamaz blockchains. Ayrıca Bitcoin sağlanmasına yönelik bir protokol Madenciler madeni birleştiriyor (yani kanonikleştirme güçlerini yan zincirinkine kopyalıyorlar) ve daha da önemlisi, yan zincirin geçişlerinin yan zincirin dışında olduğunu doğruluyorlar bu teklifin kapsamı. Cosmos [10] önerilen bir çok zincirli sistemdir. Yan zincirlerle aynı damar, Nakamoto PoW'u değiştiriyor Jae Kwon'un Tendermint algoritması için fikir birliği yöntemi. Esasen birden fazla zinciri tanımlar (birbirinde faaliyet gösteren) bölgeleri) her biri ayrı ayrı Tendermint örneklerini ve bir ağ üzerinden güven gerektirmeyen iletişim aracını kullanıyor ana göbek zinciri. Bu zincirler arası iletişim, keyfi bilgilerden ziyade dijital varlıkların (“özellikle tokens hakkında”) aktarımıyla sınırlıdır, ancak bu tür zincirler arası iletişimin veriler için bir dönüş yolu vardır, örneğin Göndericiye aktarımın durumu hakkında rapor vermek. Bölgelere ayrılmış zincirler için doğrulayıcı kümeler ve özellikle onları teşvik etmenin araçları yan zincirler gibi bırakıldı çözülmemiş bir sorun olarak Genel varsayım şudur her bölgeli zincirin kendisi token değerinde bir değere sahip olacak ve bu değerin enflasyonu validators'yi ödemek için kullanılacak. Hala erken aşamalarda Tasarım konusunda şu anda teklif, ölçeklenebilir hedefe ulaşmanın ekonomik araçlarına ilişkin kapsamlı ayrıntılardan yoksundur. Küresel geçerliliğin kesinliği. Ancak bölgeler ile merkez arasında gereken gevşek tutarlılık, bölgelere ayrılmış parametreler üzerinde ilave esneklik için daha güçlü bir sistem uygulayan bir sistemle karşılaştırıldığında zincirler tutarlılık. 2.2.3. Casper. Casper [6] ve Polkadot arasında henüz kapsamlı bir inceleme veya yan yana karşılaştırma yok oldukça kapsamlı bir inceleme yapılabilir ancak ikisinin (ve buna bağlı olarak yanlış) karakterizasyonu. Casper, PoS konsensüs algoritmasının nasıl yeniden tasarlandığını gösteriyor katılımcıların hangi çatala dair bahis oynadıkları temeline dayanabilir. sonuçta kanonik hale gelecektir. Ağa karşı dayanıklı olmasını sağlamak için büyük önem verildi çatallar, uzatıldığında bile ve temel Ethereum modelinin üzerinde bir miktar ek ölçeklenebilirliğe sahiptir. olarak Casper bugüne kadar önemli ölçüde daha fazla olma eğilimindeydi. Polkadot ve atalarından daha karmaşık bir protokol ve temel blockchain biçiminden önemli sapma. o Casper'ın gelecekte nasıl yineleneceği henüz bilinmiyor ve nihayet konuşlandırıldığında neye benzeyeceği. Casper ve Polkadot her ikisi de ilginç yeni protokolleri ve bir anlamda Ethereum, aralarında önemli farklar var Nihai hedefler ve dağıtım yolları. Casper bir Ethereum Orijinal olarak tasarlanmış temel merkezli proje istemeden protokolde PoS değişikliği yapmak temelde ölçeklenebilir bir blockchain oluşturun. Önemli olan, daha kapsamlı bir şey olmaktan ziyade bir hard fork olacak şekilde tasarlandı ve bu nedenle tüm Ethereum istemcileri ve kullanıcıları Yükseltilmesi veya belirsiz bir benimseme çatalında kalması gerekiyor. Bu nedenle, sıkı kuralların olduğu merkezi olmayan bir projenin doğasında olduğu gibi dağıtım önemli ölçüde daha zor hale gelir. koordinasyon gereklidir. Polkadot birkaç açıdan farklılık gösterir; her şeyden önce, Polkadot tamamen genişletilebilir ve ölçeklenebilir olacak şekilde tasarlanmıştır blockchain geliştirme, dağıtım ve etkileşim testi yatak. Büyük ölçüde geleceğe yönelik bir emniyet kemeri olacak şekilde inşa edilmiştir. yeni blockchain asimile etaşırı karmaşık merkezi olmayan koordinasyon olmadan kullanılabilir hale gelen teknoloji veya sert çatallar. Halihazırda bunun gibi çeşitli kullanım senaryolarını öngörüyoruz. şifrelenmiş konsorsiyum zincirleri ve yüksek frekanslı zincirler olarak yapılması gerçekçi olmayan çok düşük blok süreleriyle Ethereum'nin şu anda öngörülen gelecekteki herhangi bir sürümü. Son olarak, onunla Ethereum arasındaki bağlantı son derece yüksektir gevşek; Ethereum tarafından herhangi bir işlem yapılmasına gerek yoktur. ikisi arasında güvenilir işlem iletimini etkinleştir ağlar. Kısacası Casper/Ethereum 2.0 ve Polkadot Nihai hedeflerine inandığımız bazı geçici benzerlikleri paylaşıyoruz önemli ölçüde farklıdır ve rekabet etmek yerine, iki protokolün sonuçta bir arada var olması muhtemeldir öngörülebilir gelecek için karşılıklı yarar sağlayan ilişkiler.

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.

Özet

Polkadot ölçeklenebilir, heterojen bir çoklu zincirdir. Bu önceki blockchain uygulamalarından farklı olduğu anlamına gelir değişen tek bir zincir sağlamaya odaklanmış olan potansiyel uygulamalara göre genellik dereceleri, Polkadot kendisi hiçbir şekilde doğal bir uygulama işlevselliği sağlamak üzere tasarlanmıştır. Aksine, Polkadot ana kayayı sağlar Çok sayıda doğrulanabilir bilginin yer aldığı “aktarma zinciri”, küresel olarak tutarlı dinamik veri yapıları barındırılabilir yan yana. Bu veri yapılarına “paralelleştirilmiş” diyoruz özel bir ihtiyaç olmasa da zincirler veya parachainler doğası gereği blockchain olmaları. Başka bir deyişle, Polkadot, bir dizi bağımsız zincire (ör. Ethereum, Ethereum Classic, Namecoin ve Bitcoin) çok önemli iki nokta hariç: • Havuzlanmış güvenlik; • güven gerektirmeyen zincirler arası işlem yapılabilirlik. Bu noktalar, Polkadot öğesinin "ölçeklenebilir" olduğunu düşünmemizin nedenidir. Prensip olarak, Polkadot üzerinde konuşlandırılacak bir sorun büyük ölçüde paralelleştirilebilir (ölçeği genişletilebilir) çok sayıda parachain. Çünkü her birinin tüm yönleri parachain Polkadot ağının farklı bir bölümü tarafından paralel olarak yürütülebilir, sistemin bazı yetenekleri vardır ölçeklendirmek için. Polkadot oldukça basit bir parça sağlar 3aslında bir zincirdeki tokens'yi yok ederek başka bir zincirde tokens'yi oluşturmadan oluşan tek yönlü sabitlemenin aksine Orijinal tokens'yi kurtarmak için bunun tersini yapacak mekanizmaPOLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 4 karmaşıklığın çoğunu ara yazılım düzeyinde ele almayı bırakan altyapı. Bu, kalkınma riskini azaltmayı amaçlayan bilinçli bir karardır. Kısa sürede geliştirilecek gerekli yazılımlar ve güvenliği konusunda iyi düzeyde bir güven ile sağlamlık. 3.1. Polkadot Felsefesi. Polkadot gerekir üzerine oturulacak mutlak kaya gibi sağlam bir temel sağlar. bir sonraki mutabakat sistemi dalgasını oluşturun üretim kapasitesine sahip olgun tasarımlardan kaynaklanan risk spektrumu yeni oluşan fikirlere. Polkadot, güvenlik, izolasyon ve iletişim konusunda güçlü garantiler sunarak aşağıdakilere izin verebilir: bir dizi özellik arasından seçim yapmak için parachainler. Aslında, çeşitli deneysel blockchain'lerin mantıklı kabul edilebilecek özellikleri zorladığını öngörüyoruz bugün. muhafazakar görüyoruz benzer yüksek değerli zincirler Bitcoin veya Z-cash [20] daha düşük değerle birlikte mevcut “Tema zincirleri” (böyle pazarlama, çok eğlenceli) ve test ağları sıfır veya sıfıra yakın ücretlerle. Tamamen şifrelenmiş görüyoruz, "karanlık", birlikte çalışan konsorsiyum zincirleri - ve hatta son derece işlevsel ve açık zincirlere hizmet sağlamak Ethereum gibi olanlar gibi. Deneysel yeni görüyoruz Sübjektif zaman yüklü wasm gibi VM tabanlı zincirler zincir, zorlu bilgi işlem sorunlarını daha olgun Ethereum benzeri bir zincirden dış kaynak olarak sağlama aracı olarak kullanılıyor veya daha kısıtlı Bitcoin benzeri bir zincir. Zincir yükseltmelerini yönetmek için Polkadot doğası gereği muhtemelen dayalı bir tür yönetim yapısını desteklemek mevcut istikrarlı siyasi sistemlere ilişkindir ve Sarı Kağıt Konseyi'ne benzer iki meclisli bir yapıya sahiptir [24]. olarak nihai otorite, temel stake edilebilir token sahipleri "referandum" kontrolüne sahip olacaktır. Kullanıcıların düşüncelerini yansıtmak için Geliştirme ihtiyacı ama geliştiricilerin meşruiyet ihtiyacı, makul bir yönlendirmenin oluşmasını bekliyoruz bir “kullanıcı” komitesinin iki odası (aşağıdakilerden oluşur) validators teminatlı) ve bir “teknik” komite oluşturuldu büyük müşteri geliştiricileri ve ekosistem oyuncularından oluşan bir ekip.

token sahiplerinden oluşan bir grup nihai meşruiyeti koruyacak ve bu yapıyı geliştirmek, yeniden parametrelendirmek, değiştirmek veya feshetmek için bir süper çoğunluk oluşturacaktır; Nihai ihtiyaçtan şüphe etmeyin: Twain'in sözleriyle “Hükümetler ve bebek bezleri sık sık değiştirilmeli ve aynı sebep”. Yeniden parametrelendirmenin daha geniş bir konsensüs mekanizması içinde düzenlenmesi tipik olarak önemsiz olsa da, değiştirme ve genişletme gibi daha niteliksel değişiklikler büyük ihtimalle otomatik olmayan “yumuşak kararnameler” (ör. Bir blok numarasının kanonikleştirilmesi yoluyla ve hash resmi olarak yeni protokolü belirten bir belge) veya bir temel konsensüs mekanizmasının bulunmasını gerektirir. kendisinin herhangi bir yönünü tanımlayacak kadar zengin bir dil bunun değişmesi gerekebilir. İkincisi nihai bir amaçtır, ancak birincisinin seçilme olasılığı daha yüksektir Makul bir geliştirme zaman çizelgesini kolaylaştırmak. Polkadot'nin temel ilkeleri ve içinde yer aldığı kurallar Tüm tasarım kararlarını değerlendiriyoruz: Minimal: Polkadot mümkün olduğunca az işlevselliğe sahip olmalıdır. Basit: Hiçbir ek karmaşıklık mevcut olmamalıdır temel protokolde makul olarak olabileceğinden ara yazılıma yüklenmiş, aracılığıyla yerleştirildi parachain veya daha sonraki bir optimizasyonda tanıtıldı. Genel: gereksiz gereksinim yok, kısıtlama veya parachainlere sınırlama getirilmeli; Polkadot, fikir birliği sistemi geliştirme için optimize edilebilecek bir test ortamı olmalıdır. Uzantıların yer aldığı modeli mümkün olduğunca soyut hale getirmek. Sağlam: Polkadot temel olarak bir sağlamalıdır kararlı taban katmanı. Ekonomik sağlamlığın yanı sıra bu aynı zamanda merkezi olmayan yönetim anlamına da gelir. yüksek ödüllü saldırıların vektörleri.

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.

Polkadot katılımı

Polkadot bakımında dört temel rol vardır ağ: derleyici, balıkçı, aday gösteren ve validator. içinde Polkadot'nin olası bir uygulaması, ikinci rol aslında iki role ayrılabilir: temel validator ve kullanılabilirlik garantörü; bu bölümde tartışılıyor 6.5.3. Harmanlayıcı Balıkçı Doğrulayıcılar (bu grup) Doğrulayıcılar (diğer gruplar) onaylıyor olur monitörler raporlar kötü davranış blok sağlar adaylar için Aday gösteren Şekil 1. Polkadot'nin dört rolü. 4.1. Doğrulayıcılar. validator en yüksek ücrettir ve Polkadot ağında yeni blokların kapatılmasına yardımcı olur. validator'nın rolü yeterince yüksek bir bağa bağlıdır diğer bağlı tarafların ödeme yapmasına izin vermemize rağmen yatırılıyor onlar adına hareket etmek üzere bir veya daha fazla validator aday gösterin ve validator tahvilinin bu tür bir kısmının mutlaka validator'ya ait olması gerekmeyebilir, bunun yerine bu kişilere ait olabilir aday gösterenler. Bir validator, yüksek kullanılabilirlik ve bant genişliğine sahip bir aktarma zinciri istemci uygulamasını çalıştırmalıdır. Her blokta düğüm onaylama rolünü kabul etmeye hazır olmalıdır aday gösterilen bir parachain üzerinde yeni bir blok. Bu süreç adayın alınmasını, doğrulanmasını ve yeniden yayınlanmasını içerir bloklar. Adaylık deterministiktir ancak çok önceden tahmin edilmesi neredeyse imkansızdır. validator yapamadığı için tam senkronizasyonu sürdürmesi makul olarak beklenebilir tüm parachain'lerin veri tabanına göre, validator'nin önerilen yeni bir zincir tasarlama görevini aday göstermesi bekleniyor Parachain bloğunu harmanlayıcı olarak bilinen üçüncü bir tarafa aktarır. Tüm yeni parachain blokları atanmış validator alt grupları tarafından uygun şekilde onaylandıktan sonra, validators daha sonra aktarma zinciri bloğunu kendisinin onaylaması gerekir. Bu şunları içerir: işlem kuyruklarının durumunun güncellenmesi (esasen verileri bir parachain'in çıktı kuyruğundan diğerine taşımak parachain'in giriş kuyruğu), işlemleri işleme Onaylanmış aktarma zinciri işlem seti ve onaylanması son parachain değişiklikleri de dahil olmak üzere son blok.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 5 validator fikir birliği bulma görevini yerine getirmiyor seçtiğimiz fikir birliği algoritmasının kurallarına göre cezalandırılır. Başlangıçtaki kasıtsız arızalar için bu, validator ödülünün durdurulması. Tekrarlanan arızalar güvenlik bağlarının azalmasına (yanma yoluyla) neden olur. Çift imzalama gibi muhtemelen kötü niyetli eylemler veya Geçersiz bir blok sağlamak için komplo kurmak, bağın tamamı (kısmen yanmış ancak çoğunlukla verilmiştir) muhbirlere ve dürüst aktörlere). Bir bakıma validator'ler madencilik havuzlarına benziyor mevcut PoW'un blockchains'si. 4.2. Aday gösterenler. Aday gösteren, hisse sahibi bir partidir validator'nin teminat tahviline katkıda bulunan kişi. onlar Risk sermayesi yerleştirmek dışında ek bir rolü yoktur ve belirli bir validator (veya bunların bakımında sorumlu bir şekilde hareket etmek ağ. Orantılı bir artış veya azalma alırlar tahvilin büyümesine göre mevduatlarında katkıda bulunurlar. Sıralayıcılarla birlikte aday gösterenler de bazı ülkelerde günümüz PoW ağlarındaki madencilere benzer bir his veriyor. 4.3. Harmanlayıcılar. İşlem harmanlayıcıları (kısaca harmanlayıcılar) validators'nin geçerli bilgiler üretmesine yardımcı olan taraflar mı? Parachain blokları. Belirli bir parachain için “tam düğüm” sağlarlar; gerekli olan her şeyi muhafaza ettikleri anlamına gelir Yeni bloklar yazabilmek ve yürütebilmek için gerekli bilgiler işlemler, madencilerin mevcut PoW blockchains üzerinde yaptıklarıyla hemen hemen aynı şekilde yapılır. Normal şartlarda onlar mühürsüz bir kayıt oluşturmak için işlemleri toplayacak ve yürütecek sıfır bilgiyle birlikte engelleyin ve sağlayın şu anda sorumlu olan bir veya daha fazla validators'ye kanıt bir parachain bloğu öneriyor. Düzenleyenler, aday gösterenler ve validator'ler arasındaki ilişkinin kesin niteliği muhtemelen değişecek zaman. Başlangıçta, derleyicilerin çok yakın çalışmasını bekliyoruz validators ile, çünkü yalnızca birkaç tane olacak (belki küçük işlem hacmine sahip yalnızca bir) parachain(ler). İlk istemci uygulaması, RPC'leri içerecektir. Parachain harmanlayıcı düğümü, bir (aktarma zinciri) validator düğümüne koşulsuz olarak geçerli olduğu kanıtlanabilen bir parachain sağlamak için Blok. Senkronize edilmiş bir sürümünü sürdürmenin maliyeti olarak bu tür parachainlerin tümü artıyor, ek görmeyi bekliyoruz ayırmaya yardımcı olacak altyapı mevcuttur. Bağımsız, ekonomik motivasyona sahip taraflara yönelik görevler. Sonunda, rekabet eden harmanlayıcı havuzlarını görmeyi bekliyoruz. En fazla işlem ücretini toplayın. Bu tür düzenleyicilerle, ödül gelirlerinden sürekli bir pay almak için belirli bir süre boyunca belirli validator'lere hizmet vermek üzere sözleşme yapılabilir. Alternatif olarak, "serbest" derleyiciler basitçe bir Piyasa, anında ödenecek ödülün rekabetçi bir payı karşılığında geçerli parachain blokları sunuyor. Benzer şekilde, merkezi olmayan aday havuzları birden fazla adaya izin verecektir. katılımcıları koordine etmek ve görevini paylaşmak üzere bir araya getirdi. validator. Bu havuzlama yeteneği açık katılımı garanti eder daha merkezi olmayan bir sisteme yol açmaktadır. 4.4. Balıkçılar. Diğer iki aktif partinin aksine, balıkçılar blok yazarlığıyla doğrudan ilişkili değil süreç. Daha ziyade bağımsız “ödül avcıları”dırlar büyük bir tek seferlik ödülle motive edildi. Tam olarak nedeniyle Balıkçıların varlığı nedeniyle, uygunsuz davranış olaylarının nadiren meydana gelmesini bekleriz ve bunlar yalnızca balıkçılar nedeniyle gerçekleştiğinde bağlı tarafın gizli anahtar güvenliği konusunda dikkatsiz olması, kötü niyetle değil. İsim geliyor Beklenen ödül sıklığından, katılım için gereken minimum gereksinimlerden ve nihai ödül boyutundan. Balıkçılar ödüllerini zamanında kanıtlayarak alıyorlar en az bir bağlı taraf yasa dışı hareket etti. Yasa dışı eylemler her biri aynı onaylı ebeveynle iki blok imzalamayı veya parachain durumunda geçersiz bir anlaşmanın onaylanmasına yardımcı olmayı içerir Blok. Aşırı ödüllendirmeyi veya taviz vermeyi önlemek ve bir oturumun gizli anahtarının yasa dışı kullanımı, temel ödül tek bir validator'nin yasa dışı olarak imzalanmış mesajını sağlamak minimum. Bu ödül asimptotik olarak arttıkça artar. diğer validator'lerden gelen yasa dışı imzaları doğrulamak gerçek bir saldırıyı ima ediyor. Asimptot ayarlandı en azından temel güvenlik iddiamızı takiben %66 oranında validator'ların üçte ikisi iyiliksever davranıyor. Balıkçılar bir bakıma “tam düğümlere” benzerler. kaynakların ihtiyaç duyduğu günümüz blockchain sistemleri nispeten küçüktür ve istikrarlı çalışma süresi taahhüdü ve bant genişliği gerekli değildir. Balıkçılar bu konuda farklılık gösteriyor küçük bir tahvil yatırmaları gerektiği kadar.Bu bağ engelliyor validators'nin zamanını ve hesaplamasını boşa harcayan sybil saldırıları kaynaklar. Hemen geri çekilebilir, muhtemelen hayır birkaç dolara eşdeğerden daha fazla ve yol açabilir yaramaz bir davranışı fark ederek büyük bir ödül elde etmek 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.

Tasarıma Genel Bakış

Bu bölüm, konuyla ilgili kısa bir genel bakış sunmayı amaçlamaktadır. bir bütün olarak sistem. Konunun daha kapsamlı bir araştırması Sistemi takip eden bölümde verilmiştir. 5.1. Konsensüs. Aktarma zincirinde Polkadot şunu başarır: karşılıklı olarak kabul edilen geçerli bir dizi karar üzerinde düşük düzeyde fikir birliği modern bir eşzamansız Bizans hataya dayanıklı (BFT) algoritması aracılığıyla bloklar. Algoritma ilham alacak basit Tendermint [11] ve çok daha fazlası ile HoneyBadgerBFT [14] dahil. İkincisi bir sağlar keyfi bir şekilde etkin ve hataya dayanıklı bir fikir birliği çoğunlukla zararsız otoriteler veya validators kümesi göz önüne alındığında kusurlu ağ altyapısı. Yetki kanıtı (PoA) tarzı bir ağ için yalnızca bu yeterli olacaktır, ancak Polkadot olduğu düşünülüyor tamamen açık ve halka açık bir ağ olarak da dağıtılabilir belirli bir kuruluş veya güvenilir olmayan durum sürdürmek için gerekli olan yetkidir. Bu nedenle bir ihtiyacımız var validators kümesini belirleme ve teşvik etme araçları dürüst olmaları. Bunun için PoS tabanlı seçimi kullanıyoruz Kriterler. 5.2. Bahsi Kanıtlamak. Ağın olduğunu varsayıyoruz ne kadar "bahis" olduğunu ölçmek için bazı araçlara sahip olacak herhangi bir hesabın olması. Karşılaştırma kolaylığı için önceden var olan sistemlere ölçü birimi diyeceğiz “tokens”. Ne yazık ki bu terim ideal olmaktan uzaktır. pek çok neden var, en azından bunun basit bir skaler olması bir hesapla ilişkili değer, hiçbir kavram yoktur bireysellik. validator'lerin nadiren (en fazla) seçildiğini hayal ediyoruz günde bir kez ama belki üç ayda bir kadar nadiren), Aday Hisse Kanıtı (NPoS) şeması aracılığıyla. Teşvik, oranlı bir tahsis yoluyla gerçekleşebilir.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 6 Röle zincir Doğrulayıcı sürüsü (her biri kendi rengine göre renklendirilmiştir) belirlenmiş parachain) İşlem (tarafından gönderildi dış aktör) Parachain köprü Sanal parachain (örneğin Ethereum) Parachain Parachain kuyruklar ve G/Ç Yayılan işlemler Aday gönderimini engelle 2. sıra Röle zinciri Parachain topluluğu Hesap Gelen işlem Giden işlem Zincirler arası işlemler (validators tarafından yönetilmektedir) Harmanlayıcı Yayılan blok Balıkçı Şekil 2. Polkadot sisteminin özet şeması. Bu, harmanlayıcıların kullanıcı işlemlerini toplayıp yaymasının yanı sıra blok adaylarını balıkçılara ve validator'lere yaydığını gösteriyor. Aynı zamanda bir hesabın kendi parachain'inden gerçekleştirilen bir işlemi aktarma zinciri aracılığıyla nasıl yayınlayabileceğini gösterir ve oradaki bir hesaba yapılan bir işlem olarak yorumlanabileceği başka bir parachain'e. token temel genişletmeden gelen fonlar (%100'e kadar) yılda, ancak daha büyük ihtimalle %10 civarındadır. toplanan işlem ücretleri. Tüm token sahipler olduğundan, para tabanı genişlemesi genellikle enflasyona yol açsa da katılımda adil bir fırsata sahip olacak, hiçbir tokensahibinin değerinin düşmesine maruz kalması gerekmeyecek almaktan mutlu olmaları koşuluyla, zaman içinde holdingleri Konsensüs mekanizmasındaki rolü. Belirli bir oran tokens sayısı staking süreci için hedeflenecektir; the etkili token temel genişletme şu şekilde ayarlanacaktır: Bu hedefe ulaşmak için piyasaya dayalı bir mekanizma. Doğrulayıcılar büyük ölçüde çıkarlarına bağlı; çıkıyor validators'nin tahvilleri, validators'nin görevleri sona erdikten uzun süre sonra (belki yaklaşık 3 ay) yerinde kalır. Bu uzun tahvil tasfiye süresi gelecekteki uygunsuz davranışlara izin verir zincirin periyodik kontrol noktasına kadar cezalandırılır. Kötü davranış, cezanın azaltılması gibi cezalarla sonuçlanır. Ödül veya kasıtlı olarak taviz veren durumlarda ağın bütünlüğünün bozulması, validator bağlantısının bir kısmını veya tamamını kaybetmesi diğer validator'lere, muhbirlere veya paydaşlara pay bir bütün olarak (yanma yoluyla). Örneğin, bir validator bir çatalın her iki dalını da onaylamaya çalışan kişi (bazen "kısa menzilli" saldırı olarak bilinir) tanımlanabilir ve ikinci şekilde cezalandırılır. Uzun menzilli "tehlikede olmayan" saldırılar4, basit bir "kontrol noktası" mandalı aracılığıyla atlatılır ve bu, zincirin tehlikeli bir şekilde yeniden düzenlenmesini engeller. özellikle zincir derinliği. İstemcilerin yeni senkronize edilmesini sağlamak için yanlış zincire aldanamazlar, düzenli olarak “Sert çatallanmalar” meydana gelecektir (en fazla validators'nin tahvil tasfiyesi), son kontrol noktası bloğunu hashes istemcilere sabit kodlayan. Bu, ayak izini azaltan başka bir "sonlu zincir uzunluğu" ölçüsüyle iyi bir uyum sağlar veya oluşum bloğunun periyodik olarak sıfırlanması. 5.3. Parachain'ler ve Harmanlayıcılar. Her parachain alır aktarma zincirine benzer güvenlik düzenlemeleri: the Parachain'lerin başlıkları röle zinciri bloğunun içinde mühürlenmiştir Onayın ardından yeniden düzenlemenin veya "çifte harcamanın" mümkün olmamasını sağlamak. Bu, Bitcoin'nin yan zincirleri ve birleştirme madenciliği tarafından sunulana benzer bir güvenlik garantisidir. Ancak Polkadot aynı zamanda parachainlerin durum geçişlerinin geçerli olduğuna dair güçlü garantiler de sağlar. Bu validator kümesinin kriptografik olarak rastgele alt kümelere bölünmesi yoluyla gerçekleşir; başına bir alt küme parachain'de alt kümeler blok başına potansiyel olarak farklılık gösterir. Bu kurulum genellikle parachainlerin blok sürelerinin artacağını ima eder en az röle zincirininki kadar uzun olmalıdır. spesifik bölümlendirmenin kapsam dışında olduğunu belirleme araçları 4Böyle bir saldırı, düşmanın başlangıç bloğundan itibaren tamamen yeni bir tarih zinciri oluşturduğu yerdir. Bir kontrol yoluyla dengede göreceli olarak önemsiz bir paya sahip olsalar da, diğer tüm paylara göre kendi paylarına düşen payı kademeli olarak artırabilirler Paydaşlar, alternatif tarihlerinin tek aktif katılımcılarıdır. Yaratılışta hiçbir içsel fiziksel sınırlama bulunmadığından (oldukça gerçek hesaplama enerjisinin harcanması gereken PoW'un aksine), gerçek zincirden daha uzun bir zincir oluşturabilirler. nispeten kısa bir zaman aralığına sahiptir ve ağın kanonik durumunu devralarak onu potansiyel olarak en uzun ve en iyi hale getirir.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 7 bu belgenin ancak muhtemelen aşağıdakilere dayalı olması muhtemeldir: RanDAO [19] benzeri bir taahhüt-açıklama çerçevesi veya her parachain'in önceki bloklarından birleştirilmiş verileri kullanın kriptografik olarak güvenli bir hash altında. validator'lerin bu tür alt kümelerinin aşağıdakileri sağlaması gerekir: Geçerliliği garanti edilen parachain blok adayı (açık) tahvillere el konulmasının acısı). Geçerlilik iki etrafında döner önemli noktalar; ilk olarak özünde geçerli olduğu - yani tüm durum geçişleri aslına sadık kalınarak gerçekleştirildi ve hepsi Referans verilen harici veriler (yani işlemler) dahil edilmek üzere geçerlidir. İkincisi, kendi dışsal olan herhangi bir verinin harici işlemler gibi adayın yeterince yüksek kullanılabilirliğe sahip olması, böylece katılımcıların indirin ve bloğu manuel olarak çalıştırın.5 Doğrulayıcılar yalnızca hiçbir harici "işlem" verisi içermeyen "boş" bir blok sağlayabilir, ancak bunu yapmaları halinde daha düşük bir ödül alma riskiyle karşı karşıya kalabilirler. Birlikte çalışıyorlar derleyiciler (bireyler) ile bir parachain dedikodu protokolü İşlemleri bloklar halinde toplayan ve bloğun ebeveyninin geçerli bir alt öğesi olduğuna dair etkileşimli olmayan, sıfır bilgili bir kanıt sağlayan (ve herhangi bir işlemi üstlenen) sıkıntıları için ücretler). Kendilerini belirlemek parachain protokollerine bırakılmıştır. Spam önleme araçları: "bilgi işlem kaynağı ölçümü" veya "işlem ücreti" gibi temel bir kavram yoktur röle zinciri tarafından empoze edilir. Aktarma zinciri protokolü tarafından da bu konuda doğrudan bir yaptırım bulunmamaktadır (gerçi Paydaşların benimsemeyi seçmesi pek olası değil düzgün bir mekanizma sağlamayan bir parachain). Bu, zincirlerin farklı olma ihtimaline açık bir işarettir. Ethereum, ör. çok daha basit bir ücret modeline veya henüz önerilmemiş başka bir spam önleme modeline sahip Bitcoin benzeri bir zincir. Polkadot'in aktarma zincirinin kendisi muhtemelen bir Ethereum-benzeri hesaplar ve durum zinciri, muhtemelen bir EVMtürevi. Röle zinciri düğümlerinin gerekli olacağından önemli miktarda başka işlem ve işlem hacmi yapmak büyük işlem ücretleri yoluyla kısmen en aza indirilecek ve araştırma modellerimizin gerektirmesi durumunda bir blok boyutu sınırı. 5.4. Zincirler Arası İletişim. Polkadot'nin kritik son bileşeni zincirler arası iletişimdir. O zamandan beri Parachain'ler aralarında bir tür bilgi kanalına sahip olabilir, biz de Polkadot a olarak düşünmemize izin veriyoruz. ölçeklenebilir çoklu zincir. Polkadot durumunda iletişim olabildiğince basittir: parachain (bu zincirin mantığına göre) yapabilir Bir işlemin ikinci bir parachain'e gönderilmesini sağlamak veya potansiyel olarak röle zinciri. Harici işlemler gibi blockchains üretiminde tamamen eşzamansızdırlar ve onların herhangi bir şeyi geri döndürme konusunda içsel bir yetenekleri yoktur. bir tür bilginin kökenine geri dönmesi. Hedef: alır önceki veriler bloğun validators. Hesap şu gönderiyi alır: giriş kaldırıldı giriş Merkle tree Hesap gönderi gönderir: giriş yerleştirildi çıkış Merkle tree hedef için paraşütle atlama çıkış Kaynak: paylaşımlar sonraki bloktaki veriler validators posta kanıtının saklandığı yer Parachain çıkışı Merkle ağaç yönlendirilmiş referans yerleştirildi hedef parachain'de giriş Merkle tree giriş Şekil 3. Temel şematik gösterim gönderilenler için yönlendirmenin ana bölümleri işlemler (“gönderiler”). Minimum uygulama karmaşıklığını sağlamak için minimum risk ve asgari düz ceket arasında gelecek Parachain mimarilerinde bu zincirler arası işlemler standart harici imzalı işlemlerden etkili bir şekilde ayırt edilemez. İşlemin bir parachain tanımlama yeteneği sağlayan bir kaynak segmenti vardır ve isteğe bağlı boyutta olabilecek bir adres. Bitcoin ve Ethereum gibi yaygın mevcut sistemlerin aksine, zincirler arası işlemler herhangi bir türde ücret "ödemesi" ile birlikte gelmez; Bu tür herhangi bir ödemenin kaynak ve hedef parachainler üzerindeki müzakere mantığı yoluyla yönetilmesi gerekir. Bunun için önerilene benzer bir sistem Ethereum'in Serenity sürümü [7] basit bir yöntem olabilir böyle bir zincirler arası kaynak ödemesini yönetme zamanı gelince başkalarının da öne çıkabileceğini varsayıyoruz. Zincirler arası işlemler basit bir çözüm kullanılarak çözülür sağlamak için Merkle tree temeline dayalı kuyruklama mekanizması sadakat. Röle zinciri bakımcılarının görevi işlemleri bir parachain'in çıkış kuyruğunda taşıyın hedef parachain'in giriş kuyruğuna. aktarılan işlemlere aktarma zincirinde başvurulur, ancak bunlar ilgili değildiray-chain işlemlerinin kendisi. Bir parachain'in başka bir parachain'e spam göndermesini önlemek için işlemler, bir işlemin gönderilebilmesi için gereklidir hedefin giriş kuyruğunun çok büyük olmaması önceki bloğun bitiş zamanı. Giriş ise Blok işleme sonrasında sıra çok büyükse, bu durumda "doymuş" olarak kabul edilir ve hiçbir işlem şu adrese yönlendirilemez: tekrar altına düşene kadar sonraki bloklar içinde Sınır. Bu kuyruklar aktarma zincirinde yönetilir Parachainlerin birbirlerinin doygunluğunu belirlemesine izin vermek durum; bu şekilde bir işlemi yayınlamak için başarısız bir girişim Durmuş bir varış noktasına eşzamanlı olarak rapor edilebilir. (Geri dönüş yolu bulunmadığından ikincil bir işlemin bu nedenle başarısız olması durumunda geri bildirim yapılamamaktadır.) ilk arayana ve diğer bazı kurtarma yollarına gerçekleşmesi gerekirdi.) 5.5. Polkadot ve Ethereum. Ethereum'nin Turing bütünlüğü nedeniyle, Polkadot ve Ethereum'nin birlikte çalışabilmesi için bol miktarda fırsat olmasını bekliyoruz en azından kolayca çıkarılabilecek bazı güvenlik sınırları dahilinde. Kısaca, işlemlerin şu andan itibaren gerçekleşmesini öngörüyoruz: Polkadot, validators tarafından imzalanıp daha sonra beslenebilir 5Böyle bir görev validator'ler arasında paylaşılabilir veya yoğun biçimde bağlı validator'ler kümesinin atanmış görevi haline gelebilir. kullanılabilirlik garantörleri.

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 8 Ethereum burada yorumlanıp yürürlüğe konulabilirler bir işlem yönlendirme sözleşmesi. Diğer yönde ise özel olarak biçimlendirilmiş günlüklerin (olayların) kullanımını öngörüyoruz belirli bir mesajın iletilmesi gerektiğinin hızlı bir şekilde doğrulanmasına olanak tanıyan bir "kaçış sözleşmesi"nden geliyor. 5.5.1. Polkadot - Ethereum arası. Bir seçim yoluyla BFT fikir birliği mekanizması, validator'lerin oluşturduğu bir Onay oylamasıyla belirlenen paydaşlar grubu mekanizma ile güvenli bir fikir birliğine varabiliriz. nadiren değişen ve mütevazı sayıda validators. Toplam 144 validators olan bir sistemde blok süresi 4 saniye ve 900 blokluk sonluluk (kötü amaçlı yazılımlara izin verir) Çift oy verme gibi davranışların bildirilmesi, cezalandırılması ve onarılmış), bir bloğun geçerliliği makul bir şekilde 97 kadar az imzayla (144'ün üçte ikisi artı bir) ve ardından hiçbir sorgulamanın yapılmadığı 60 dakikalık doğrulama süresiyle kanıtlanmış sayılır. Ethereum bir "zorla girme sözleşmesi" düzenleyebilir 144 imza sahibini koruyabilir ve onlar tarafından kontrol edilebilir onlar. Eliptik eğri dijital imza (ECDSA) kurtarma işlemi EVM altında yalnızca 3.000 gaz gerektirdiğinden ve muhtemelen doğrulamanın yalnızca bir tarihte gerçekleşmesini isteriz. validators'lik süper çoğunluk (tam oybirliği yerine), bir talimatın onaylandığını doğrulayan Ethereum tutarındaki taban maliyet Polkadot ağından gelen gazın 300.000'den fazla olmayacağı, yani gazın yalnızca %6'sı olacağı gerektiği şekilde doğrulandı toplam blok gaz limiti 5,5M'dir. validators sayısını artırmak (sorunlarla başa çıkmak için gerekli olacak şekilde) düzinelerce zincir) bu maliyeti kaçınılmaz olarak artırıyor ancak Ethereum'nin işlem bant genişliğinin teknoloji olgunlaştıkça ve zaman içinde büyümesi genel olarak bekleniyor altyapı iyileşiyor. Olmadığı gerçeğiyle birlikte tüm validator'lerin dahil olması gerekir (ör. yalnızca en yüksek stake edilen validator'ler böyle bir görev için çağrılabilir) Bu mekanizmanın sınırları oldukça geniştir. Bu tür validator'lerin günlük rotasyonunu varsayarsak (ki bu Oldukça ihtiyatlı (haftalık, hatta aylık kabul edilebilir), o zaman bakım ağının maliyeti bu Ethereum-yönlendirme köprüsünün sayısı 540.000 civarında olacaktır günlük gaz veya mevcut gaz fiyatlarıyla yıllık 45 dolar. Köprü üzerinden tek başına iletilen temel bir işlemin maliyeti yaklaşık 0,11 dolar; ek sözleşme hesaplamasının maliyeti olacaktır elbette daha fazlası. İşlemleri tamponlayarak ve paketleyerek birlikte, izinsiz girme yetkilendirme maliyetleri kolaylıkla karşılanabilir. paylaşılarak işlem başına maliyetin önemli ölçüde azaltılması; yönlendirmeden önce 20 işlem gerekiyorsa, o zaman temel bir işlemin iletilmesinin maliyeti yaklaşık 0,01 dolar. Bu çoklu imza sözleşme modeline ilginç ve daha ucuz bir alternatif, çok taraflı sahiplik semantiğine ulaşmak için eşik imzaların kullanılması olacaktır. ECDSA için eşik imza şemaları hesaplama açısından pahalıdır, diğer planlar için olanlar Schnorr imzaları gibi imzalar oldukça makul. Ethereum bunu sağlayacak ilkelleri tanıtmayı planlıyor Yaklaşan Metropolis hardfork'unda kullanımı ucuz planlar. Eğer böyle bir yöntem kullanılabilseydi, gaz maliyetleri Polkadot işlemini Ethereum'ye iletmek için ağ önemli ölçüde sıfıra yakın bir seviyeye düşecek doğrulama için temel maliyetlerin ötesinde genel giderler imza ve temel işlemin yürütülmesi. Bu modelde, Polkadot'nin validator düğümleri mesajları imzalamaktan başka çok az şey yapmak. İşlemlerin gerçekte Ethereum ağına yönlendirilmesini sağlamak için, validator'lardan herhangi birinin kendisinin de burada ikamet edeceğini varsayalım Ethereum ağı veya daha büyük ihtimalle o küçük ödüller mesajı ileten ilk aktöre sunulacaktır. ağa (ödül önemsiz bir şekilde ödenebilir) işlem yaratıcısı). 5.5.2. Ethereum - Polkadot arası. İşlemlerin gerçekleşmesi Ethereum'den Polkadot'ye iletilen basit günlük kavramını kullanır. Bir Ethereum sözleşmesi belirli bir Polkadot parachain'ine bir işlem göndermek istediğinde, sadece özel bir "ayrılma sözleşmesi" imzalaması yeterli. Ayrılma sözleşmesi olabilecek her türlü ödemeyi alacaktır. gerekli olmalı ve bir Merkle kanıtı ve karşılık gelen bloğun başlığının geçerli olduğuna dair bir iddia yoluyla varlığının kanıtlanabilmesi için bir kayıt talimatı yayınlayın ve kanonik. Son iki koşuldan geçerlilik belki de kanıtlamak en basiti. Prensip olarak tek şartkanıta ihtiyaç duyan her Polkadot düğüm için (yani atanmış validator düğümleri), standart bir Ethereum düğümünün tamamen senkronize edilmiş bir örneğini çalıştıracak şekilde. Ne yazık ki, bu oldukça ağır bir bağımlılıktır. bir daha hafif yöntem, basit bir kanıt kullanmak olacaktır. başlık yalnızca sağlanarak doğru şekilde değerlendirildi Ethereum'nin düzgün bir şekilde yürütülmesi için gereken durum denemesinin bir kısmı bloktaki işlemleri yapın ve günlüklerin (blok makbuzunda bulunan) geçerli olup olmadığını kontrol edin. Böyle “SPV benzeri”6 Kanıtlar henüz önemli miktarda bilgi gerektirebilir; uygun bir şekilde, genellikle bunlara ihtiyaç duyulmaz hepsi: Polkadot içindeki bir tahvil sistemi tahvillere izin verir üçüncü tarafların başlıklarını kaybetme riskiyle karşı karşıya kalmaları başka bir üçüncü tarafın (“balıkçı” gibi, bkz. 6.2.3) başlığın geçersiz olduğuna dair bir kanıt sunması durumunda tahvil (özellikle devlet kökü veya makbuz köklerinin sahtekar olduğu). Ethereum gibi sonlandırılmayan bir PoW ağında, kanonikliğin kesin olarak kanıtlanması imkansızdır. Bu sorunu çözmek için her türlü veriye güvenmeye çalışan uygulamalar Zincire bağlı neden-sonuç ilişkileri için bir dizi “onay” bekleyin veya bağımlı işlem belli bir seviyeye gelinceye kadar bekleyin. Zincir içindeki belirli derinlik. Ethereum tarihinde bu derinlik, bilinen ağ sorunu olmayan en az değerli işlemler için 1 bloktan, olduğu gibi 1200 bloğa kadar değişir borsalar için ilk Frontier sürümü sırasındaki durum. Sabit “Homestead” ağında bu rakam Çoğu borsa için 120 blok ve muhtemelen bunu alırız benzer bir parametre. Yani biz yapabilir hayal et bizim Polkadot tarafı Ethereumarayüzünün bazı basit işlevlere sahip olmasını sağlamak: Ethereum ağından yeni bir başlık kabul edin ve PoW'u doğrulayın; belirli bir günlük, yeterli derinliğe (ve ileriye doğru) sahip bir başlık için Ethereum tarafı koparma sözleşmesi tarafından yayınlandı Polkadot içindeki ilgili mesajı) ve son olarak daha önce kabul edilmiş ancak kabul edilmiş kanıtları kabul edebilmek henüz etkinleştirilmemiş başlık, geçersiz bir makbuz kökü içeriyor. Aslında Ethereum başlık verilerinin kendisini almak için (ve herhangi bir SPV kanıtı veya geçerlilik/kanoniklik reddi) Polkadot ağı, yönlendirme için bir teşvik 6SPV, Bitcoin'de Basitleştirilmiş Ödeme Doğrulamasına atıfta bulunur ve müşterilerin yalnızca tutarken işlemleri doğrulaması için bir yöntem açıklar. En uzun PoW zincirinin tüm blok başlıklarının bir kopyası.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 9 veriye ihtiyaç var. Bu bir ödeme kadar basit olabilir (Ethereum tarafında toplanan ücretlerden finanse edilir) ödendi başlığı olan yararlı bir bloğu iletebilen herkese geçerlidir. Doğrulayıcılardan son birkaç bin bloğa ilişkin bilgileri saklamaları istenecektir. bazı protokole özgü araçlarla veya üzerinde tutulan bir sözleşme aracılığıyla çatalları yönetebilme röle zinciri. 5.6. Polkadot ve Bitcoin. Bitcoin karşılıklı çalışma Polkadot için ilginç bir zorluk sunuyor: sözde “İki yönlü bağlantı” faydalı bir altyapı parçası olabilir her iki ağın da tarafında olmak. Ancak nedeniyle böyle bir sabitleyicinin güvenli bir şekilde sağlanması koşuluyla Bitcoin sınırlamaları önemsiz olmayan bir girişim. Bir işlemin teslim edilmesi Bitcoin ila Polkadot arası prensipte Ethereum için olana benzer bir işlemle yapılabilir; bir “çıkış adresi” Polkadot validator'ler tarafından bir şekilde kontrol ediliyor olabilir aktarılan token'leri (ve onlarla birlikte gönderilen verileri) alın. SPV kanıtları teşvikli oracle'ler tarafından sağlanabilir ve, bir onay süresiyle birlikte verilen bir ödül işlemi ima eden kanonik olmayan blokların tanımlanması “çifte harcandı”. Daha sonra sahip olunan tüm token'ler Bu durumda "kaçış adresi" prensipte daha sonra dağıtılmak üzere aynı validator'lar tarafından kontrol edilecektir. Ancak sorun, birikintilerin dönen bir validator setinden nasıl güvenli bir şekilde kontrol edilebileceğidir. aksine Ethereum dayalı olarak keyfi kararlar alabilen imza kombinasyonları üzerine Bitcoin büyük ölçüde çoğu müşteri yalnızca maksimum 3 tarafla çoklu imza işlemlerini kabul ettiğinden daha sınırlıdır. Bunu 36'ya, hatta istenildiği gibi binlerce kişiye çıkarmak mevcut protokol uyarınca imkansızdır. Seçeneklerden biri, etkinleştirmek için Bitcoin protokolünü değiştirmektir. bu tür işlevsellik, ancak buna "sert çatallar" da denir Bitcoin dünyasında son girişimlere göre değerlendirme yapmak zor. Olasılıklardan biri eşik imzaların kullanılmasıdır. tek olarak tanımlanabilir bir kamuya izin veren kriptografik şemalar birden fazla gizli "parça" tarafından etkin bir şekilde kontrol edilebilecek anahtar, geçerli bir imza oluşturmak için bunların bir kısmı veya tamamı kullanılmalıdır. Maalesef eşik imzaları uyumlu Bitcoin'nin ECDSA'sı hesaplama açısından pahalıdır polinom karmaşıklığı yaratır ve oluşturur. Bunun gibi diğer planlar a Schnorr imzaları çok daha düşük maliyetler sağlar, ancak Bitcoin'ya dahil edilebilecekleri zaman çizelgesi protokol belirsizdir. Mevduatın nihai güvenliği, bir dizi bağlı validators, diğer bir seçenek de Çoklu imza anahtar sahiplerini yalnızca büyük ölçüde azaltın toplam validators'nin bağlı alt kümesi öyle ki eşik imzalar mümkün hale gelir (veya en kötü ihtimalle Bitcoin'nin yerel imzası) çoklu imza mümkündür). Bu elbette azaltır validator'lerin yasa dışı davranması durumunda tazminatlardan düşülebilecek toplam teminat tutarı, ancak bu zarif bir bozulmadır, sadece bir üst sınır belirler arasında güvenli bir şekilde çalıştırılabilecek fon miktarı iki ağ (ya da aslında bir saldırı durumunda kayıp yüzdesi) validator'lerden başarılı). Bu nedenle, makul derecede güvenli bir Bitcoin birlikte çalışabilirlik “sanal parachain” yerleştirmenin gerçekçi olmadığına inanıyoruz. iki ağ arasında, yine de belirsiz bir zaman çizelgesine sahip önemli bir çaba ve büyük olasılıkla paydaşların işbirliğini gerektiren ağ.

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.

Ayrıntılı Protokol

Protokol kabaca üçe ayrılabilir Parçalar: fikir birliği mekanizması, parachain arayüzü ve zincirler arası işlem yönlendirme. 6.1. Röle zinciri Operasyon. röle zinciri irade büyük ihtimalle Ethereum'a genel olarak benzeyen bir zincir olabilir, çünkü hesaba durum eşleme adresi ile durum tabanlıdır bilgi, esas olarak bakiyeler ve (tekrar oynatmayı önlemek için) işlem sayacı. Hesapları buraya yerleştirmek tek bir amaca hizmet eder: Kimliğin sahip olduğu muhasebeyi sağlamak sistemdeki payın miktarı.7 Ancak dikkate değer farklılıklar olacaktır: • Sözleşmeler işlemler yoluyla dağıtılamaz; Aktarma zincirindeki uygulama işlevselliğinden kaçınma arzusundan dolayı, sözleşmelerin kamuya açık hale getirilmesini desteklemek. • Bilgi işlem kaynağı kullanımı (“gaz”) hesaba katılmaz; kamusal kullanıma açık tek işlevler olduğundan gaz muhasebesinin arkasındaki mantık düzeltilecek artık tutmuyor. Bu nedenle sabit bir ücret uygulanacaktır. her durumda daha fazla performansa olanak tanır yapılması gerekebilecek dinamik kod yürütme ve daha basit bir işlem formatı. • Listelenen sözleşmeler için otomatik yürütmeye ve ağ mesajı çıktılarına izin veren özel işlevsellik desteklenir. Aktarma zincirinin bir VM'ye sahip olması durumunda ve bu EVM temel alınarak, maksimum basitliği sağlamak için bir dizi değişiklik yapılacaktır. Muhtemelen bir dizi yerleşik sözleşmeye sahiptir (şu adrestekilere benzer) platforma özel izin vermek için Ethereum içindeki 1-4 adresleri) Bir fikir birliği sözleşmesi de dahil olmak üzere yönetilmesi gereken görevler, validator sözleşmesi ve parachain sözleşmesi. EVM değilse, WebAssembly [2] (wasm) arka ucu en olası alternatiftir; bu durumda genel yapı benzer olurdu ama gerek olmazdı Wasm'ın geçerli bir hedef olduğu yerleşik sözleşmeler için olgunlaşmamış diller yerine genel amaçlı diller için ve EVM için sınırlı diller. Mevcut Ethereum protokolünden diğer olası sapmalar da oldukça mümkündür; örneğin, protokolün basitleştirilmesi. Aynı blok içerisinde çakışmayan işlemlerin paralel olarak yürütülmesine olanak tanıyan işlem-makbuz formatı, Serenity değişiklik serisi için önerildiği gibi. Pek olası olmasa da, Serenity benzeri bir şeyin olması mümkündür. "saf" zincir, aktarma zinciri olarak konuşlandırılabilir ve staking token gibi şeyleri yönetmek için özel bir sözleşme bunu temel bir parçası haline getirmek yerine dengeler zincirin protokolü. Şu anda bunun pek olası olmadığını düşünüyoruz yeterince mükemmel bir protokol basitleştirmesi sunacak içerdiği ek karmaşıklık ve belirsizliğe değer onu geliştirmede. 7Sistemin genel güvenliğinden belirli bir sahibinin sorumlu olduğu tutarı temsil etmenin bir yolu olarak, bu hisse hesapları kaçınılmaz olarak bazı ekonomik değerleri kodlar. Ancak şunu da anlamak gerekir ki, bu tür değerlerin kullanılmasına yönelik bir niyet söz konusu değildir. herhangi bir şekilde gerçek dünya mal ve hizmetleriyle takas amacıyla token'lerin şunlara benzetilemeyeceği belirtilmelidir: para birimidir ve bu nedenle aktarma zinciri, uygulamalara ilişkin nihilist felsefesini korur.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 10 Konsensüs mekanizmasını, validator setini, doğrulama mekanizmasını ve parachainleri yönetmek için gereken bir dizi küçük işlevsellik vardır. Bunlar yekpare bir protokol altında birlikte uygulanabilir. Bununla birlikte, modülerliğin göstergesi olarak bunları aktarma zincirinin "sözleşmeleri" olarak tanımlıyoruz. Bu gerekir nesneler oldukları anlamına gelecek şekilde alınmalıdır (anlamında) nesne yönelimli programlama) aktarma zincirinin konsensüs mekanizması tarafından yönetilir, ancak bu zorunlu değildir. EVM benzeri işlem kodlarındaki programlar olarak tanımlanırlar veya aracılığıyla ayrı ayrı adreslenebilir olsalar bile hesap sistemi. 6.2. Bahis Sözleşmesi. Bu sözleşme validator kümesini korur. Şunları yönetir: • şu anda hangi hesapların validators olduğu; • kısaca validators olmaya müsait olanlar uyarı; • hangi hesaplara hisse adaylığı yerleştirildi bir validator; • staking hacmi, kabul edilebilir ödeme oranları ve adresleri ve kısa vadeli (oturum) kimliklerini içeren her birinin özellikleri. Bir hesabın üye olma arzusunu kaydetmesine olanak tanır. bağlı validator (gereksinimleriyle birlikte), bir kimliğe aday olmak ve önceden mevcut bağlı validators için bu durumdan çıkma isteklerini kaydetmek için. Aynı zamanda doğrulama ve kanonikleştirme mekanizması için makinenin kendisini içerir. 6.2.1. Stake-token Likidite. Genellikle arzu edilir toplam staking tokens'nin mümkün olduğu kadar çoğuna sahip olmak beri ağ bakım operasyonlarında görevlendirildi bu, ağ güvenliğini doğrudan staking token'nin genel "piyasa değerine" bağlar. Bu kolayca yapılabilir para biriminin şişirilmesi ve gelirlerin katılımcılara validators olarak dağıtılması yoluyla teşvik edilebilir. Ancak bunu yapmak bir sorun yaratır: token ise Staking Sözleşmesinde indirim cezasıyla kilitlenmişse, önemli bir kısmı nasıl yeterince kalabilir? Fiyat keşfine izin vermek için sıvı mı? Buna bir yanıt, temel hisseli token üzerinde değiştirilebilir token'leri güvence altına alan basit bir türev sözleşmesine izin vermektir. Bunu güvene dayalı olmayan bir şekilde düzenlemek zordur. Ayrıca, bu türev token'ler, farklı Avro Bölgesi hükümetlerinin tahvillerinin takas edilebilir olmaması nedeniyle aynı nedenle eşit olarak ele alınamaz: dayanak varlığın başarısızlığa uğraması ve yeniden oluşması ihtimalidir değersiz. Avro Bölgesi hükümetleri ile varsayılan. validator-bahisli tokens ile validator olabilir kötü niyetli davranın ve cezalandırılın. İlkelerimize sadık kalarak en basit çözümü seçiyoruz: token'ların tümü stake edilmeyecektir. Bu şu anlama gelir token'lerin bir kısmı (belki %20) zorunlu olarak sıvı kalacaktır. Bu, güvenlik açısından kusurlu olsa da, güvenlik açısından temel bir fark yaratması pek olası değildir. ağın güvenliği; Tahvillere el konulmasından kaynaklanabilecek tazminatların yüzde 80'i hala yapılabilecek %100 staking "mükemmel durum" ile karşılaştırıldığında. Stacked ve likit token'ler arasındaki oran, ters açık artırma mekanizması yoluyla oldukça basit bir şekilde hedeflenebilir. Temel olarak, token sahipleri validator olmakla ilgileniyorlar her biri staking sözleşmesine şunu belirten bir teklif gönderir: almaları gereken minimum ödeme oranı parçası. Her oturumun başında (oturumlar düzenli olarak, belki saatte bir kez kadar sıklıkta meydana gelir) validator yuva her isteğe göre doldurulacak validator'nın bahis miktarı ve ödeme oranı. Olası bir algoritma çünkü bu, en düşük teklifleri verenleri almak olacaktır. hedeflenen toplam hisseden daha yüksek olmayan bir hisseyi temsil eder yuva sayısına bölünür ve bu miktarın yarısının alt sınırından daha az olamaz. Yuvalar doldurulamıyorsa, alt sınır, tatmin etmek için bazı faktörlerle tekrar tekrar azaltılabilir. 6.2.2. Aday gösterme. Güvenle aday gösterilmek mümkündür staking tokens olanları aktif bir validator'ye bağlayarak onlara veririz validator'nin görevlerinin sorumluluğu. Eserlerin aday gösterilmesi onay-oylama sistemi aracılığıyla. Her aday aday staking sözleşmesine bir talimat gönderebilir altında bir veya daha fazla validator kimliği ifade eden sorumluluklarını emanet etmeye hazırdırlar. Her oturumda adayların tahvilleri dağıtılır. bir veya daha fazla validator ile temsil edilir. Dağıtma algoritması, eşdeğer toplamın validators kümesi için optimize eder tahviller. Aday gösterenlerin tahvilleri validator a'nın etkin sorumluluğu altına girer.ya faiz kazanırsın ya da acı çekersin buna göre ceza indirimi. 6.2.3. Senetlere El Koyma/Yakma. Belirli validator davranışları, teminatlarının cezai olarak azaltılmasıyla sonuçlanır. Eğer Tahvilin izin verilen minimum seviyenin altına düşürülmesi, oturum zamanından önce sonlandırıldı ve başka bir oturum başlatıldı. Cezalandırılabilir validator uygunsuz davranışların kapsamlı olmayan listesi şunları içerir: • Sağlayamayan bir parachain grubunun parçası olmak parachain bloğunun geçerliliği konusunda fikir birliği; • geçersiz bir belgenin geçerliliği için aktif olarak imza atmak parachain bloğu; • çıkış yüklerini önceden sağlayamama uygun olarak oylandı; • fikir birliği süreci sırasında hareketsizlik; • rakip çatallardaki aktarma zinciri bloklarının doğrulanması. Bazı hatalı davranış vakaları ağın bütünlüğünü tehdit eder (geçersiz parachain bloklarının imzalanması ve bir çatalın birden fazla tarafının doğrulanması gibi) ve dolayısıyla bağın tamamen azaltılması yoluyla etkili bir şekilde sürgüne yol açar. içinde diğer, daha az ciddi durumlar (örn. fikir birliğinde hareketsizlik) süreç) veya suçun kesin olarak dağıtılamadığı durumlarda (etkisiz bir grubun parçası olmak), küçük bir kısım Bunun yerine teminat para cezasına çarptırılabilir. İkinci durumda, bu kötü amaçlı olduğundan emin olmak için alt grup karmaşasıyla iyi çalışır düğümler, ikincil olarak hasar görmüş hayırsever düğümlerden önemli ölçüde daha fazla kayba uğrar. Bazı durumlarda (örneğin, çoklu çatal doğrulaması ve geçersiz alt blok imzalama) validator'ler sürekli doğrulama nedeniyle birbirlerinin hatalı davranışlarını kendileri kolayca tespit edemiyorlar Her bir parachain bloğunun kaldırılması çok zorlu bir görev olacaktır. Burada dışındaki tarafların desteğinin sağlanması gerekmektedir. Bu tür hatalı davranışları doğrulamak ve raporlamak için doğrulama süreci. Taraflar bu tür bir faaliyeti bildirdikleri için bir ödül alırlar; "Balıkçı" terimi, bu durumun pek mümkün olmamasından kaynaklanıyor böyle bir ödülden. Bu vakalar genellikle çok ciddi olduğundan, el konulan tahvilden her türlü ödülün kolayca ödenebileceğini öngörüyoruz. Genelde yanmayı dengelemeyi tercih ederiz (yani hiçbir şeye indirgeme) yerine yeniden tahsis ile toptan yeniden tahsis girişiminde bulunuldu. Bunun etkisi var

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 11 token'nin genel değerini artırarak, ağ belirli bir düzeyden ziyade genel olarak bir dereceye kadar keşifte yer alan taraf. Bu esas olarak bir güvenlik amaçlıdır Mekanizma: İlgili büyük miktarlar, hepsi aşırı ve akut davranış teşviklerine yol açabilir tek bir hedefe bahşedilmiştir. Genel olarak, ödülün ağ için doğrulamayı değerli kılacak kadar büyük olması, ancak bir doğrulamanın karşılanmasının maliyetini karşılayacak kadar da büyük olmaması önemlidir. iyi finanse edilmiş, iyi organize edilmiş “endüstriyel düzeyde” suç Kötü davranışlara zorlamak için bazı şanssız validator'ya hack saldırısı. Bu şekilde, talep edilen tutarın genellikle hatalı validator'nin doğrudan bağından daha büyük, öyle ki yaramazlık yapmaktan ve ödül için kendini ihbar etmekten kaynaklanan sapkın teşvikler. Bu durumla açıkça mücadele edilebilir olmak için asgari doğrudan tahvil şartı aracılığıyla validator veya dolaylı olarak aday gösterenleri, yatırılmış küçük tahvilleri olan validator'ların büyük bir teşvikinin olmadığı konusunda eğiterek iyi davranmak. 6.3. Parachain Kaydı. Her parachain şu şekilde tanımlanır: bu kayıt defteri. Nispeten basit bir veritabanı benzeri yapıdır ve hem statik hem de dinamik bilgileri tutar. her zincir. Statik bilgiler zincir indeksini (basit bir tamsayı), doğrulama protokolü kimliğiyle birlikte bir farklı sınıfları birbirinden ayırmanın bir yolu doğru doğrulama algoritmasının olabilmesi için parachain geçerli bir aday öne sürmekle görevli validators tarafından yönetiliyor. İlk kavram kanıtı yerleştirmeye odaklanacaktır. yeni doğrulama algoritmalarını istemcilerin kendilerine aktarır ve her seferinde protokolün sert bir şekilde çatallanmasını gerektirir. ek zincir sınıfı eklendi. Sonuçta yine de doğrulama algoritmasını belirtmek mümkün olabilir Müşterilerin kullanabileceği kadar titiz ve etkili bir yol yeni parachain'lerle etkili bir şekilde çalışabilmektedir. sert çatal. Bunun olası bir yolu şunu belirtmek olacaktır: köklü bir parachain doğrulama algoritması, WebAssembly gibi yerel olarak derlenmiş, platformdan bağımsız bir dil. Belirlemek için ek araştırma gereklidir bunun gerçekten mümkün olup olmadığı, ancak eğer öyleyse, bununla birlikte sert çatalları ortadan kaldırmanın muazzam avantajı kesinlikle. Dinamik bilgi, işlem yönlendirme sisteminin küresel anlaşmaya sahip olması gereken yönlerini içerir. Parachain'in giriş kuyruğu olarak (bölüm 6.6'da açıklanmıştır). Kayıt defteri yalnızca parachain'lerin eklenmesini sağlayabilir tam referandum oylaması yoluyla; bu yönetilebilir dahili olarak ancak daha büyük olasılıkla harici bir yere yerleştirilir kapsamında yeniden kullanımı kolaylaştırmak amacıyla referandum sözleşmesi daha genel yönetişim bileşenleri. Parametreler oylama gereklilikleri (örneğin gerekli yeter çoğunluk, çoğunluk ek zincirlerin ve diğerlerinin kaydı için gerekli) daha az resmi sistem yükseltmeleri bir “ana anayasa” ama muhtemelen oldukça geleneksel bir anayasayı takip edecekler. en azından başlangıçta yol. Kesin formülasyon bitti mevcut çalışmanın kapsamı, ancak ör. toplam sistemin üçte birinden fazlasıyla geçecek üçte ikilik bir çoğunluk Hisselerin olumlu oylanması mantıklı bir başlangıç noktası olabilir. Ek işlemler arasında parachainlerin askıya alınması ve kaldırılması yer alır. Uzaklaştırma umarım hiçbir zaman olmaz olur, ancak en azından bir koruma olacak şekilde tasarlanmıştır Parachain'in doğrulama sisteminde bazı zorlu problemler var. Bunun olabileceği en bariz örnek validators'nin üzerinde anlaşamamasına yol açan uygulamalar arasında fikir birliği açısından kritik bir farka ihtiyaç duyulmaktadır. geçerlilik veya bloklar. Doğrulayıcıların kullanması teşvik edilecektir. birden fazla istemci uygulamasını gerçekleştirebilmeleri için tahvillere el konulmadan önce böyle bir sorunu tespit etmek. Askıya alma acil bir tedbir olduğundan, dinamik validator-oylamanın himayesi altında referandumdan daha fazlası. Yeniden etkinleştirme her ikisi de mümkün olabilir validators'den veya referandumdan. Parachainlerin tamamen ortadan kaldırılması ancak referandumdan sonra gerekli olacak düzenli bir geçişe izin vermek için önemli miktarda ödemesiz süre ya bağımsız bir zincir ya da başka bir zincirin parçası olmak fikir birliği sistemi. Ek süre muhtemelen Ayların sırasına göre düzenlenir ve farklı sıralamaların yapılabilmesi için parachain kayıt defterinde her zincir bazında düzenlenmesi muhtemeldir. Parachain'ler duruma göre farklı ödemesiz sürelerden yararlanabilirler onların ihtiyacı. 6.4. Sızdırmazlık Rölesi Blokları. Sızdırmazlık, özünde, kanonikleştirme sürecine; yani temel bir veri hangisini dönüştürorijinali temelde tekil ve anlamlı bir şeye dönüştürür. PoW zinciri altında, mühürleme aslında madencilikle eşanlamlıdır. Bizim durumumuzda, validators'den bir belgenin geçerliliği, kullanılabilirliği ve kanonikliğine ilişkin imzalı ifadelerin toplanmasını içerir. belirli röle zinciri bloğu ve parachain blokları temsil ediyor. Temel BFT fikir birliği algoritmasının mekaniği mevcut çalışmanın kapsamı dışındadır. Yapacağız bunun yerine bunu varsayan bir ilkel kullanarak tanımlayın. fikir birliği yaratan devlet makinesi. Sonuçta bekliyoruz bir dizi umut verici BFT fikir birliğinden ilham almak çekirdekteki algoritmalar; Tangaora [9] (BFT çeşidi) Raft [16]), Tendermint [11] ve HoneyBadgerBFT [14]. Algoritmanın paralel olarak birden fazla parachain üzerinde anlaşmaya varması gerekecek, bu da alışılagelmiş olandan farklı olacaktır. blockchain fikir birliği mekanizmaları. Bir kez olduğunu varsayıyoruz fikir birliğine varıldığında fikir birliğini kaydedebiliriz herhangi biri tarafından sağlanabilecek reddedilemez bir kanıtla Katılımcılar buna. Ayrıca hatalı davranışı da varsayıyoruz. protokol dahilinde genellikle küçük bir miktara indirgenebilir en aza indirmek için yaramazlık yapan katılımcıları içeren grup cezayı verirken ikincil hasar.8 İmzalı ifadelerimizin şeklini alan kanıt, röle zinciri bloğunun başlığına birlikte yerleştirilir aktarma zincirinin durum kökü ve işlem deneme kökü başta olmak üzere bazı diğer alanlarla birlikte.

sızdırmazlık süreç alır yer altında bir bekar fikir birliği yaratan mekanizma adresleme ikisi de the röle zincirinin bloğu ve parachainlerin blokları aktarıcının içeriğinin bir kısmı: parachain'ler alt grupları tarafından ayrı ayrı "taahhüt edilmez" ve daha sonra harmanlanmaz daha sonra. Bu, aktarma zinciri için daha karmaşık bir süreçle sonuçlanır, ancak gecikmeyi en aza indirerek ve tüm sistemin fikir birliğini tek bir aşamada tamamlamamıza olanak tanır. oldukça karmaşık veri kullanılabilirliği gereksinimleri için aşağıdaki yönlendirme işlemi için faydalıdır. 8Tendermint BFT ve orijinal Slasher gibi mevcut PoS tabanlı BFT fikir birliği şemaları bu iddiaları karşılamaktadır.

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 12 Her katılımcının fikir birliği makinesinin durumu basit (2 boyutlu) bir tablo olarak modellenebilir. Her katılımcının (validator) formda bir dizi bilgisi vardır. Her bir parachain blok adayı ve aktarma zinciri blok adayı ile ilgili olarak diğer katılımcıların imzalı beyanlarının (“oyları”). Bilgi seti iki parçadan oluşmaktadır veri sayısı: Kullanılabilirlik: var bu validator sahip olmak çıkış bu bloktan işlem sonrası bilgiler Aşağıdaki blokta parachain adaylarını doğru şekilde doğrulayabiliyorlar mı? Oy verebilirler 1(bilinen) veya 0 (henüz bilinmiyor). Bir kez onlar 1 oy, benzer şekilde oy vermeye kararlılar bu sürecin geri kalanı. Daha sonra geçerli olmayan oylar buna saygı duymak cezanın gerekçesidir. Geçerlilik: parachain bloğu geçerli mi ve hepsi geçerli mi? harici referanslı veriler (ör. işlemler) müsait mi? Bu yalnızca oy verdikleri parachain'e atanan validator'ler için geçerlidir. 1 (geçerli), -1 (geçersiz) veya 0 şeklinde oy verebilirler. (henüz bilinmiyor). Sıfır dışında oy verdiklerinde, geri kalan süre boyunca bu şekilde oy kullanmaya kararlıyız süreç. Daha sonra buna saygı göstermeyen oylar ceza gerekçesidir. Tüm validator'ler oy vermelidir; Yukarıdaki kurallara uygun olarak oylar yeniden gönderilebilir. ilerlemesi Konsensüs, paralel olarak gerçekleşen her bir parachain üzerinde birden fazla standart BFT konsensüs algoritması olarak modellenebilir. Bunlar potansiyel olarak göreceli olarak engellendiğinden kötü niyetli aktörlerin küçük bir azınlığı yoğunlaşıyor tek bir parachain grubu için genel fikir birliği mevcuttur En kötü senaryoyu sınırlayan bir geri durdurma noktası oluşturun yalnızca bir veya daha fazla geçersiz parachain bloğuna kilitlenme (ve Sorumlulara bir dizi ceza). Bireysel blokların geçerliliği için temel kurallar (toplam validators kümesinin bir bütün olarak elde edilmesine olanak sağlar) benzersiz parachain adayı olma konusunda fikir birliği kanonik röleden referans alınacak): • validator üyelerinin en az üçte ikisinin olumlu oy kullanması ve hiçbirinin olumsuz oy kullanmaması gerekir; • çıkış kuyruğu bilgilerinin kullanılabilirliği konusunda üçte birden fazla validator olumlu oy kullanmalıdır. Geçerliliğe ilişkin en az bir olumlu ve en az bir olumsuz oy olması halinde istisnai bir durum yaratılır ve validator'lerden oluşan grubun tamamı karar vermek için oy kullanmalı kötü niyetli taraflar varsa veya kazara bir durum varsa çatal. Geçerli ve geçersiz oyların dışında üçüncü tür oylar izin veriliyor, her ikisine de oy vermeye eşdeğer, yani Düğümün çelişkili görüşleri var. Bunun nedeni şunlar olabilir: düğümün sahibi birden fazla uygulamayı çalıştırıyor katılmıyorum, bu da protokolde olası bir belirsizliğe işaret ediyor. Tüm oylar tam validator kümesinden sayıldıktan sonra, eğer kaybedilen görüşün en azından küçük bir oranı vardır ( parametrelendirilebilir; en fazla yarısı, belki de önemli ölçüde daha az) kazanan görüşün oylarının, o zaman olduğu varsayılır kazara bir parachain çatalı olursa, parachain otomatik olarak konsensüs sürecinden askıya alınır. Aksi takdirde bunun kötü niyetli bir davranış olduğunu varsayarız ve cezalandırırız. muhalif görüşe oy veren azınlık. Sonuç, aşağıdakileri gösteren bir dizi imzadır: kanoniklik. Röle zinciri bloğu daha sonra kapatılabilir ve bir sonraki bloğun mühürlenmesi süreci başladı. 6.5. Sızdırmazlık Röle Bloklarına yönelik iyileştirmeler. iken bu sızdırmazlık yöntemi sistemin çalışması konusunda güçlü garantiler verir, çok iyi ölçeklenmez çünkü her parachain'in anahtar bilgisinin kendine ait olması gerekir kullanılabilirlik, tüm validator'lerin üçte birinden fazlası tarafından garanti edilir. Bu, her validator'nin sorumluluk ayak izinin olduğu anlamına gelir daha fazla zincir eklendikçe büyür. Açık fikir birliği ağlarında veri kullanılabilirliği özünde çözülmemiş bir sorun olduğundan, validator düğümlerine yerleştirilen yükü azaltmanın yolları vardır. Basit bir çözüm, validators'nin omuz vermesi gerektiğini fark etmektir. Veri kullanılabilirliği sorumluluğu kendilerine ait olduğundan, verileri kendilerinin saklaması, iletmesi veya çoğaltması gerekmez. Muhtemelen ilişkili (ya da hatta tam olarak) ikincil veri siloları aynı) bu verileri derleyen derleyiciler şunları yönetebilir: validator'lerin faiz/gelirlerinin bir kısmını ödeme olarak sunarak kullanılabilirliği garanti etme görevi. Ancak bu, bir miktar orta düzeyde ölçeklenebilirlik satın alsa da, yine de altta yatan soruna yardımcı olmuyor; o zamandan beri daha fazla zincir eklemek genel olarak ek validator gerektirecektir; devam eden ağ kaynağı tüketimi (özellikle bant genişliği açısından) karesi ile birlikte artar. thezincirler uzun vadede savunulamaz bir özelliktir. Eninde sonunda kafamızı vurmaya devam edeceğiz şunu belirten temel sınırlamaya karşı: Güvenli olarak kabul edilebilecek bir fikir birliği ağı, devam eden bant genişliği gereksinimleri toplam mertebesindedir validators çarpı toplam giriş bilgisi. Bunun nedeni güvenilmeyen bir ağın, veri depolama görevini birçok düğüme düzgün bir şekilde dağıtamaması fazlasıyla dağıtılabilir işleme görevi dışında. 6.5.1. Gecikme ile tanışın. Bunu yumuşatmanın bir yolu Kural, aciliyet kavramını gevşetmektir. validators'nin %33+1 validators'nin kullanılabilirlik için oy vermesini hemen değil, yalnızca eninde sonunda zorunlu kılarak, üstel veri yayılımından daha iyi yararlanabilir ve veri alışverişindeki zirve noktaların dengelenmesine yardımcı olabiliriz. Makul bir eşitlik (kanıtlanmamış olsa da) şunlar olabilir: (1) gecikme = katılımcılar × zincirler Mevcut modelde sistemin boyutu ölçekleniyor İşlemenin yapılmasını sağlamak için zincir sayısıyla dağıtılmış; her zincir en az bir validator gerektireceğinden ve kullanılabilirlik kanıtını sabit bir değere sabitledik oranı validators ise katılımcılar da benzer şekilde büyür zincir sayısı ile. Sonuç olarak: (2) gecikme = boyut2 Bu, sistem büyüdükçe gerekli bant genişliğinin ve kullanılabilirliğe kadar olan gecikmenin tüm ağ genelinde bilindiği anlamına gelir. numara olarak da nitelendirilebilecek ağ kesinlikten önceki blok sayısı karesiyle birlikte artar. bu önemli bir büyüme faktörüdür ve önemli bir engel teşkil edebilir ve bizi “düz olmayan” paradigmalara zorlayabilir birkaç “Polkadotes”i bir hiyerarşi halinde oluşturmak gibi direklerin bir aktarma zinciri ağacı aracılığıyla çok seviyeli yönlendirilmesi için.

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 13 6.5.2. Halkın Katılımı. Bir olası yön daha sürece halkın katılımını sağlamaktır. Mikro şikayet sistemi. Balıkçılara benzer şekilde, iddia eden validator'leri denetleyen harici taraflar olabilir kullanılabilirlik. Görevleri bu tür bir uygunluğu gösteremeyen birini bulmaktır. Bunu yaparken onlar diğer validator'lere mikro şikayette bulunabilir. PoW veya Sybil saldırısını azaltmak için hisseli tahvil kullanılabilir bu da sistemi büyük ölçüde işe yaramaz hale getirecektir. 6.5.3. Kullanılabilirlik Garantörleri. Son bir rota şu olacaktır: ikinci bir bağlı validator kümesini "kullanılabilirlik" olarak aday gösterin garantörler”. Bunlar normal validator'lerde olduğu gibi bağlanır ve hatta aynı kümeden bile alınabilir. (eğer öyleyse, en azından oturum başına, uzun vadeli bir süre boyunca seçileceklerdir). Normal validator'lerin aksine, onlar Parachain'ler arasında geçiş yapmazdım ama bunun yerine Tüm önemli zincirler arası verilerin kullanılabilirliğini doğrulamak için tek bir grup oluşturun. Bunun katılımcılar ve zincirler arasındaki denkliği gevşetme avantajı vardır. Esas olarak zincirler büyür (orijinal zincir validator seti ile birlikte), oysa katılımcılar ve özellikle veri kullanılabilirliği vasiyetinde yer alanlar en azından alt doğrusal kalabilirler ve muhtemelen sabit. 6.5.4. Harmanlayıcı Tercihleri. Bunun önemli bir yönü Sistemin amacı sağlıklı seçim yapılmasını sağlamaktır. herhangi bir parachain'de blokları oluşturan harmanlayıcılar. eğer bir tek bir harmanlayıcı bir parachain'e hakim oldu, ardından bazı saldırılar oldu eksikliği olasılığı nedeniyle daha uygulanabilir hale gelir. dış verilerin mevcudiyeti daha az belirgin olacaktır. Bir seçenek parachain bloklarını yapay olarak ağırlıklandırmaktır. çok çeşitli derleyicileri tercih etmek için sözde rastgele bir mekanizma. İlk etapta şunu isteriz: validators'nin desteklediği fikir birliği mekanizmasının bir parçası olarak Parachain blok adaylarının “daha ağır” olduğu belirlendi. Benzer şekilde, validators'yi şunu yapmaya teşvik etmeliyiz: bulabilecekleri en ağır bloğu önerin; bu olabilir ödüllerinin bir kısmını adaylarının ağırlığına orantılı hale getirerek yapılır. Harmanlayıcılara makul bir adalet sağlanmasını sağlamak adaylarının kazanan olarak seçilme şansı Adayın fikir birliği içinde olması durumunda, belirli bir ağırlığı belirleriz. Parachain blok adayı, her bir harmanlayıcıya bağlı rastgele bir fonksiyon üzerinde belirlenir. Örneğin, alarak harmanlayıcının adresi arasındaki XOR mesafe ölçüsü ve bazı kriptografik olarak güvenli sahte rastgele numaralar oluşturulan bloğun noktasına yakın olarak belirlenir (kavramsal bir “kazanan bilet”). Bu, her birine etkili bir şekilde verir harmanlayıcı (veya daha spesifik olarak her harmanlayıcının adresi) aday bloğunun "kazanması" için rastgele şans diğerleri. Tek bir harmanlayıcının kazanan bilete yakın bir adresi "madencilik" yapmasının ve böylece her bloğun favorisi olsaydı, harmanlayıcının adresine bir miktar atalet eklerdik. Bu onları istemek kadar basit olabilir adreste temel miktarda para bulunması. bir daha Zarif yaklaşım, yakınlığa ağırlık vermek olacaktır. park edilen para miktarıyla bilet kazanma söz konusu adres. Modelleme henüz yapılmamışken, bu mekanizmanın çok fazla olanak sağlaması oldukça mümkündür. Küçük paydaşların derleyici olarak katkıda bulunmaları. 6.5.5. Aşırı Kilolu Bloklar. Bir validator kümesinin güvenliği ihlal edilirse, bir blok oluşturabilir ve önerebilirler. geçerlidir, yürütülmesi aşırı miktarda zaman alır ve doğrulayın. Bu bir validator grubunun yapabileceği bir sorundur. makul bir şekilde çok uzun zaman alan bir blok oluşturur Kısa yola izin veren belirli bir bilgi parçası zaten bilinmiyorsa, örneğin; büyük çarpanlara ayırma birinci sınıf. Eğer tek bir derleyici bu bilgiyi biliyorsa, o zaman kendilerininkini alma konusunda açık bir avantaja sahip olacaklar diğerleri eski bloğu işlemekle meşgul olduğu sürece adaylar kabul edildi. Bu bloklara fazla kilolu diyoruz. validator'lerin bu blokları göndermesine ve doğrulamasına karşı koruma, büyük ölçüde aşağıdakilerle aynı kisvenin altında kalır: geçersiz bloklar, ancak ek bir uyarıyla: Çünkü bir bloğun yürütülmesi için geçen süre (ve dolayısıyla durumu aşırı kilo) subjektiftir, oylamanın nihai sonucu Kötü davranışlar esasen üç kampa ayrılacaktır. Bir olasılık bloğun kesinlikle aşırı kilolu olmamasıdır. bu durumda üçte ikiden fazlası yapabileceklerini beyan ediyor bloğu belirli bir limit dahilinde yürütün (örneğin, bloklar arasında izin verilen toplam sürenin %50'si). Bir diğeri ise blok d'dirkesinlikle fazla kilolu - eğer daha fazlaysa bu olurdu üçte ikisi bloğu yürütemediklerini beyan ediyor söz konusu limit dahilinde. Son bir olasılık oldukça eşit validators arasında fikir ayrılığı. Bu durumda şunları yapabiliriz: orantılı bir ceza uygulamayı seçin. validators'nin ne zaman olabileceklerini tahmin edebilmelerini sağlamak için Aşırı ağırlıklı bir blok önerirken, her blok için kendi performanslarına ilişkin bilgi yayınlamalarını talep etmek mantıklı olabilir. Yeterli bir süre boyunca, bu onların işlem hızlarının profilini çıkarmalarına olanak sağlamalıdır onları yargılayacak akranlarına göre. 6.5.6. Harmanlayıcı Sigortası. validators için bir sorun kaldı: PoW ağlarından farklı olarak, bir harmanlayıcının bilgilerini kontrol etmek için Geçerlilik için bloğun içindeki işlemleri gerçekten yürütmeleri gerekir. Kötü niyetli harmanlayıcılar validator'lere geçersiz veya aşırı ağırlıklı bloklar besleyerek onların sıkıntı yaşamasına neden olabilir (boşa harcama) kaynakları) ve potansiyel olarak önemli bir fırsat maliyeti talep etmektedir. Bunu azaltmak için basit bir strateji öneriyoruz. validators'nin bir parçası. İlk olarak parachain blok adayları gönderildi validators'ye geçiş zinciri hesabından imza atılmalıdır fonlarla; değilse validator düşmelidir hemen. İkinci olarak, bu tür adaylar, aşağıdakilerin bir kombinasyonu (örneğin çarpma) yoluyla öncelik sırasına konmalıdır: belirli bir sınıra kadar hesaptaki fon miktarı, derleyicinin geçmişte başarılı bir şekilde önerdiği önceki blokların sayısı (önceki bloklardan bahsetmeye bile gerek yok) cezalar) ve kazanmaya yakınlık faktörü daha önce tartışıldığı gibi bilet. Kapak aynı olmalı davada validator'ye ödenen cezai tazminat olarak geçersiz bir blok gönderiyorlar. Düzenleyicileri geçersiz veya fazla kilolu blok adaylarını validators'ye göndermekten caydırmak için herhangi bir validator Bir sonraki bloğa, hatalı davranış iddiasında bulunan ve hatalı davranan toplayıcının hesabındaki fonların bir kısmının veya tamamının transfer edilmesi sonucunu doğuran kusurlu bloğu içeren bir işlem yerleştirir mağdur validator adına hesap verin. Bu tür işlemler, harmanlayıcının işlem yapamayacağını garantilemek için diğer işlemleri önden çalıştırır. cezadan önce fonları kaldırın. miktarı Hasar olarak aktarılan fonlar henüz dinamik bir parametredir

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 14 modellenecek ancak neden olunan kederin düzeyini yansıtacak şekilde muhtemelen validator blok ödülünün bir oranı olacaktır. Kime Kötü niyetli validator'lerin, toplayıcıların fonlarına keyfi olarak el koymasını önlemek için, düzenleyici, validator'nin kararına, karşılığında rastgele seçilmiş validator'lardan oluşan bir jüri ile itiraz edebilir. küçük bir depozito yatırmak için. validator'nin lehine karar verirlerse depozito onlar tarafından tüketilir. Değilse, depozito iade edilir ve validator para cezasına çarptırılır (çünkü validator çok daha kubbeli bir konumda, ceza kesilecek muhtemelen oldukça ağır olacaktır). 6.6. Zincirler arası İşlem Yönlendirme. Zincirler arası işlem yönlendirme temel bakımlardan biridir Aktarma zincirinin görevleri ve validator'leri. Bu Gönderilen bir işlemin (genellikle basitçe "göndermek" olarak kısaltılır) istenen çıktı olmaktan nasıl çıkacağını yöneten mantık bir kaynak parachain'den başka bir hedef parachain'in herhangi bir güven olmadan pazarlık edilemez girdisi olmaya gereksinimleri. Yukarıdaki ifadeleri dikkatle seçiyoruz; özellikle biz kaynakta bir işlem olmasını gerektirmez Parachain bu gönderiyi açıkça onayladı. Tek Modelimize koyduğumuz kısıtlamalar parachainlerin genel bloklarının bir parçası olarak paketlenmiş olarak sağlamalıdır işlem çıktısı, sonucu olan gönderiler bloğun yürütülmesi. Bu gönderiler birkaç FIFO kuyruğu olarak yapılandırılmıştır; the listelerin sayısı yönlendirme tabanı olarak bilinir ve 16 civarında. Özellikle bu sayı miktarı temsil ediyor başvurmak zorunda kalmadan destekleyebileceğimiz parachain sayısı çok fazlı yönlendirme. Başlangıçta Polkadot bunu destekleyecektir bir çeşit doğrudan yönlendirme, ancak biz olası bir yönlendirmeyi özetleyeceğiz bir araç olarak çok aşamalı yönlendirme süreci (“hiper yönlendirme”) Başlangıçtaki parachain setinin çok ötesine ölçeklendirme. Biz varsaymak bu hepsi katılımcılar biliyorum the sonraki iki blok için alt gruplamalar n, n + 1. Özetle, Yönlendirme sistemi şu aşamaları takip eder: • CollatorS: Doğrulayıcıların iletişim üyeleri[n][S] • Harmanlayıcılar: HER ALT GRUP İÇİN: Doğrulayıcıların[n][s] en az 1 üyesi temas halinde • Harmanlayıcılar: HER alt grup İÇİN: varsaymak çıkış[n −1][s][S] mevcut (tüm gelen gönderiler) verileri son bloktan 'S'ye aktarın) • Harmanlayıcılar: S için blok adayı b'yi oluşturun: (b.başlık, b.ext, b.kanıt, b.makbuz, b.çıkış) • Harmanlayıcılar: Gönder kanıt bilgi kanıt[S] = (b.başlık, b.ext, b.kanıt, b.makbuz) ila Doğrulayıcılar[n][S] • CollatorS: Harici işlem verilerinin b.ext olmasını sağlayın diğer derleyicilerin ve validator'lerin kullanımına sunulur • Harmanlayıcılar: İÇİN HER BİRİ alt grup s: Gönder çıkış bilgi çıkış[n][S][s] = (b.başlık, b.makbuz, b.çıkış[lar]) için the alma alt grup üyeler arasında sonraki blok Doğrulayıcılar[n + 1][s] • V alidatorV : Aynı kümedeki tüm üyeleri önceden bağlayın sonraki blok için: N = Zincir[n + 1][V ]; bağlanmak tüm validators v öyle ki Zincir[n + 1][v] = N • DoğrulayıcıV : Bunun için tüm veri girişlerini toplayın blok: İÇİN HER BİRİ alt grup s: Al çıkış[n −1][s][Zincir[n][V ]], diğer validators v'den Zincir[n][v] = Zincir[n][V ] olacak şekilde alın. Muhtemelen girişimin kanıtı için rastgele seçilmiş diğer validator'lerden geçiyoruz. • DoğrulayıcıV : Bunun için aday kanıtlarını kabul edin blok kanıtı[Zincir[n][V ]]. Oy bloğunun geçerliliği • DoğrulayıcıV : Şunun için aday çıkış verilerini kabul edin: sonraki blok: HER alt grup İÇİN, kabul et çıkış[n][s][N]. Oy engelleme çıkış kullanılabilirliği; ilgilenen validator'ler arasında yeniden yayınlayın, öyle ki Zincir[n + 1][v] = Zincir[n + 1][V ]. • DoğrulayıcıV : UZLAŞMAYA KADAR Burada: egress[n][from][to] geçerli çıkış kuyruğudur Parachain'den 'başlangıç'a giden gönderiler için bilgi 'n' blok numarasındaki parachain 'to'. CollatorS, parachain S için bir harmanlayıcıdır. V alidators[n][s], n blok numarasındaki parachain s için validators kümesidir. Tam tersine, Zincir[n][v], n numaralı blokta validator v'nin atandığı parachaindir. Block.egress[to] çıkıştır bazı parachain blok bloklarından gelen gönderi kuyruğu hedef parachain'dir. Harmanlayıcılar (işlem) ücretlerini topladıkları için blokları kanonik hale geliyor, teşvik ediliyorlar her bir sonraki blok hedefi için alt grubun üyeler mevcut çıkış kuyruğu hakkında bilgilendirilir Blok. Doğrulayıcılar yalnızca bir (parachain) blok üzerinde fikir birliği oluşturmaya teşvik edilir, bu nedenle pek umursamazlar hangi harmanlayıcının bloğu sonuçta kanonik hale gelir. içinde prensip olarak, bir validator bir derleyiciyle bağlılık oluşturabilir ve diğer derleyicilerin şansını azaltmak için komplo kurabilir blokların kanonik hale gelmesi, ancak bu hem zordur rastgele seçim nedeniyle düzenlemek içinvalidators'nin işlemi için Parachain'lere karşı, dayanıklı parachain blokları için ödenecek ücretlerde indirim yapılarak bu savunma yapılabilir. fikir birliği süreci. 6.6.1. Harici Veri Kullanılabilirliği. Parachain'in sağlanması harici verilerin aslında mevcut olması kalıcı bir sorundur İş yükünü dağıtmayı amaçlayan merkezi olmayan sistemler ağ. Sorunun merkezinde kullanılabilirlik var mümkün olmadığı için bunu belirten sorun etkileşimli olmayan bir kullanılabilirlik kanıtı veya herhangi bir türde ibraz etmek BFT sisteminin düzgün bir şekilde çalışması için kullanılabilir olmadığının kanıtı Doğruluğu aşağıdakilere dayanan herhangi bir geçişi doğrulamak bazı harici verilerin kullanılabilirliği, maksimum sayı kabul edilebilir Bizans düğümlerinin sayısı artı sistemin bir tanesi mevcut verilerin doğrulanması gerekir. Polkadot gibi bir sistemin ölçeğinin düzgün şekilde genişletilmesi için bu bir soruna davetiye çıkarıyor: eğer sabit bir oran validators ise Verilerin kullanılabilirliğini doğrulamalıdır ve varsayarak validators, verilerin mevcut olduğunu iddia etmeden önce verileri gerçekten depolamak isteyecekse, o zaman bu durumdan nasıl kaçınabiliriz? sistem boyutu (ve dolayısıyla validators sayısı) arttıkça bant genişliği/depolama gereksinimlerinin artması sorunu mu var? Olası bir cevap ayrı bir sete sahip olmak olabilir Siparişleri artan validators (kullanılabilirlik garantörleri) sayısı bir bütün olarak Polkadot boyutunda alt çizgisel olarak. bu 6.5.3'te açıklanmıştır. Ayrıca ikincil bir numaramız da var. Bir grup olarak derleyiciler, tüm verilerin doğrulanmasını sağlamak için içsel bir teşvike sahiptir. seçtikleri parachain için uygunlar çünkü onsuz yapabilecekleri başka bloklar yazamazlar işlem ücretlerini toplayın. Düzenleyiciler ayrıca üyelikleri değişkenlik gösteren bir grup oluşturur (rastgele doğası nedeniyle) parachain validator grupları) girişi önemsiz ve kolay

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 15 kanıtlamak. Bu nedenle son derleyicilerin (belki de son birkaç bin bloğun) meydan okumalarına izin veriliyor. belirli bir parachain için harici verilerin kullanılabilirliği küçük bir tahvil için validators'ye blok yapın. Doğrulayıcılar, açıkça suç teşkil eden validator alt grubundan ifade veren kişilerle iletişime geçmeli ve ya verileri alıp derleyiciye iade etmeli ya da durumu üst kademeye iletmelidir. mevcudiyetin bulunmadığına dair ifade vererek meseleyi ifade etmek (veri sayımlarını sağlamanın doğrudan reddedilmesi tahvillere el koyma suçu olarak kabul edilir, bu nedenle uygunsuz davranış validator muhtemelen sadece bağlantıyı kes) ve ek validator'lerle iletişim kurma aynı testi yapmak için. İkinci durumda, teminat verenin tahvili iade edilir. Bu tür müsaitlik durumu olmayan referansları sunabilecek validator yeter sayısına ulaşıldığında serbest bırakılırlar, yaramazlık yapan alt grup cezalandırılır ve engelleme geri alınır. 6.6.2. Mesaj Yönlendirme. Her parachain başlığı bir içerir çıkış-üçlü-kök; bu, şunu içeren bir try'nin köküdür yönlendirme tabanı bölmeleri, her bölme birleştirilmiş bir listedir çıkış direkleri. Merkle kanıtları her yerde sunulabilir belirli bir parachain'in olduğunu kanıtlamak için parachain validators bloğun belirli bir hedef parachain için belirli bir çıkış kuyruğu vardı. Bir parachain bloğunun işlenmesinin başlangıcında, her biri söz konusu bloğa bağlı diğer parachain'in çıkış kuyruğu: bloğumuzun giriş kuyruğuna birleştirildi. Güçlü sanıyoruz, muhtemelen CSPR9, herhangi biri arasında herhangi bir kayırmacılık sunmayan deterministik bir operasyon elde etmek için alt blok sıralaması Parachain blok eşleştirmesi. Harmanlayıcılar yeni kuyruğu hesaplar ve çıkış kuyruklarını parachain'in kurallarına göre boşaltın mantık. Giriş kuyruğunun içeriği açıkça yazılmıştır parachain bloğuna. Bunun iki ana amacı vardır: İlk olarak, bu, parachain'in diğer parachain'lerden ayrı olarak güvenilir bir şekilde senkronize edilebileceği anlamına gelir. İkincisi, tüm girişin gerçekleşmesi durumunda veri lojistiğini basitleştirir kuyruk tek bir blokta işlenemiyor; validator'ler ve harmanlayıcılar aşağıdaki blokları işleyebilir kuyruğun verilerini özel olarak kaynaklamak zorunda kalmadan. Parachain'in giriş kuyruğu bir eşiğin üzerindeyse blok işlemenin sonunda miktar, ardından işaretlenir Aktarma zinciri doygun hale gelir ve başka mesaj gönderilemez. temizlenene kadar kendisine teslim edilecektir. Merkle kanıtları harmanlayıcının işleminin doğruluğunu göstermek için kullanılır Parachain bloğunun kanıtı. 6.6.3. Eleştiri. Bu temelle ilgili küçük bir kusur Mekanizma bomba sonrası saldırıdır. Burası her şeyin olduğu yer Parachain'ler mümkün olan maksimum miktarda gönderi gönderir belirli bir parachain'e. Bu hedefin bağlantısını sağlarken giriş kuyruğuna tek seferde girer, tekrar tekrar hasar verilmez standart bir işlem DoS saldırısı. Bir dizi iyi senkronize edilmiş ve normal şekilde çalışıyor N parachain için kötü amaçlı olmayan harmanlayıcılar ve validator'ler, Parachain başına N × M toplam validators ve L harmanlayıcı, biz blok başına toplam veri yollarını şu şekilde parçalayabilir: Doğrulayıcı: M −1+L+L: diğer validator'ler için M −1 Parachain setinde, bir aday parachain bloğu sağlayan her bir harmanlayıcı için L ve her bir harmanlayıcı için ikinci bir L önceki bloğun çıkış yüklerini gerektiren sonraki bloğun. (İkincisi aslında daha çok en kötü duruma benziyor Harmanlayıcıların bu tür bilgileri paylaşması muhtemel olduğundan operasyon veriler.) Harmanlayıcı: M +kN: İlgili her bir bağlantı için M parachain bloğu validator, çıkış yüklerini her parachain validator grubunun bazı alt kümelerine dağıtmak için kN bir sonraki blok (ve muhtemelen bazı tercih edilen harmanlayıcı(lar)). Bu nedenle, düğüm başına veri yolu yolları doğrusal olarak büyür sistemin genel karmaşıklığı ile. Bu iken makul, sistem yüzlerce veya binlerce parachain'e ölçeklendiğinden bir miktar iletişim gecikmesi olabilir daha düşük bir karmaşıklık büyüme oranı karşılığında emilir. Bu durumda çok aşamalı bir yönlendirme algoritması kullanılabilir. anlık yolların sayısını azaltmak için depolama arabellekleri ve gecikmenin eklenmesi pahasına. 6.6.4. Hyper-cube Yönlendirme. Hyper-cube yönlendirme çoğunlukla bir uzantı olarak oluşturulabilen bir mekanizmadır. Yukarıda açıklanan temel yönlendirme mekanizması. Esasen, Parachain ve alt grup düğümlerinin sayısıyla düğüm bağlantısını artırmak yerine yalnızca Parachainlerin logaritması. Gönderiler şu tarihler arasında geçiş yapabilir: Birkaç parachain kuyruğu nihai teslimata doğru ilerliyor. Yönlendirmenin kendisi deterministik ve basittir. Şununla başlıyoruz: giriş/çıkış kuyruklarındaki kutu sayısının sınırlandırılması; toplam parachain sayısı yerine bunlaryönlendirme tabanı (b) . Bu numara olarak sabitlenecek Parachainlerin sayısı değişir, bunun yerine yönlendirme üssü (e) yükseltilir. Bu modelde mesaj hacmimiz O(be) ile büyür, yollar sabit kalır ve gecikme (veya teslimat için gereken blok sayısı) O(e) ile. Yönlendirme modelimiz e boyutlu bir hiperküptür, küpün her iki tarafı da b olası konuma sahiptir. Her blokta mesajları tek bir eksen boyunca yönlendiririz. Biz Ekseni sıralı olarak değiştirerek blokların en kötü durumda teslim süresini garanti altına alırsınız. Parachain işlemenin bir parçası olarak, yurtdışına bağlı Giriş kuyruğunda bulunan mesajlar, verilen gereklilik dikkate alınarak derhal uygun çıkış kuyruğunun bölmesine yönlendirilir. geçerli blok numarası (ve dolayısıyla yönlendirme boyutu). Bu süreç her atlama için ek veri aktarımı gerektirir teslimat rotasında, ancak bu başlı başına bir sorun bazı alternatif yöntemler kullanılarak hafifletilebilecek olan veri yükünün teslimi ve yalnızca bir referans içermesi, deneme sonrası gönderinin tam yükü yerine. Bir sistem için böyle bir hiper küp yönlendirme örneği 4 parachain ile b = 2 ve e = 2 şöyle olabilir: Aşama 0, her M mesajında: • sub0: eğer Mdest ∈{2, 3} ise sendTo(2) yoksa devam et • sub1: eğer Mdest ∈{2, 3} ise sendTo(3) yoksa devam et • sub2: eğer Mdest ∈{0, 1} ise sendTo(0) yoksa devam et • sub3: eğer Mdest ∈{0, 1} ise sendTo(1) yoksa devam et Aşama 1, her M mesajında: • sub0: eğer Mdest ∈{1, 3} ise sendTo(1) yoksa devam et • sub1: eğer Mdest ∈{0, 2} ise sendTo(0) yoksa devam et • sub2: eğer Mdest ∈{1, 3} ise sendTo(3) yoksa devam et • sub3: eğer Mdest ∈{0, 2} ise sendTo(2) yoksa devam et Buradaki iki boyutu ilk boyut olarak görmek kolaydır. hedef indeksin iki biti; ilk blok için yüksek dereceli bit tek başına kullanılır. İkinci blok anlaşmaları düşük dereceli bit ile. Her ikisi de gerçekleştiğinde (keyfi olarak sipariş) ardından gönderi yönlendirilecektir. 9kriptografik olarak güvenli sözde rastgele

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 16 6.6.5. Serendipity'yi en üst düzeye çıkarmak. Temelde bir değişiklik teklifte sabit toplam c2 −c validators görülecektir; her alt grupta c−1 validators. Her blok yerine validators'nin yapılandırılmamış bir yeniden bölümlenmesi var Parachain'ler arasında, bunun yerine her parachain alt grubu için, her validator benzersiz ve farklı bir numaraya atanacaktır Aşağıdaki blokta parachain alt grubu. Bu herhangi iki blok arasında herhangi bir değişken için değişmezliğe yol açar iki parachain çifti var, iki validators var Parachain sorumluluklarını değiştirdik. Bu, kullanılabilirlik konusunda mutlak garantiler elde etmek için kullanılamasa da (tek bir validator ara sıra devre dışı kalacaktır, hatta yardımsever), yine de genel durumu optimize edebilir. Bu yaklaşım komplikasyonsuz değildir. Parachain'in eklenmesi aynı zamanda yeniden yapılanmayı da gerektirecektir. validator kümesinin. Ayrıca validators sayısı parachain sayısının karesine bağlıdır, başlangıçta çok küçük başlayacak ve sonunda çok büyüyecekti çok hızlı, yaklaşık 50 parachain'den sonra savunulamaz hale geliyor. Bunların hiçbiri temel sorunlar değil. İlk durumda, validator kümelerinin yeniden düzenlenmesi olması gereken bir şeydir zaten düzenli olarak yapılıyor. validator boyutuyla ilgili olarak ayarlandı, çok küçük olduğunda birden fazla validator atanabilir aynı parachain'e bir tam sayı faktörü uygulayarak genel toplam validators. 6.6.4'te tartışılan Hypercube Routing gibi çok aşamalı bir yönlendirme mekanizması, çok sayıda validators gereksinimini hafifletmek çok sayıda zincir olduğunda. 6.7. Parachain Doğrulaması. A validator'in asıl amacı iyi ilişkilere sahip bir aktör olarak bir parachain'in Blok, herhangi bir durum geçişi, herhangi bir harici işlem dahil ancak bunlarla sınırlı olmamak üzere geçerlidir. giriş kuyruğundaki tüm bekleme noktaları ve son durum çıkış kuyruğundan. Sürecin kendisi oldukça basittir. validator önceki bloğu mühürledikten sonra özgürdürler aday parachain bloğu sağlamak için çalışmaya başlamak bir sonraki konsensüs turuna aday. Başlangıçta, validator bir parachain harmanlayıcı (sonraki bölümde anlatılacaktır) veya bir parachain harmanlayıcı aracılığıyla bir parachain blok adayını bulur. eş-validators. Parachain bloğu aday verileri bloğun başlığını, önceki bloğun başlığını içerir, dahil edilen tüm harici giriş verileri (Ethereum ve Bitcoin için, bu tür veriler işlemler olarak anılacaktır, ancak prensipte keyfi amaçlar için rastgele veri yapıları içerebilirler), çıkış kuyruğu verileri ve durum geçişi geçerliliğini kanıtlamak için dahili veriler (Ethereum için) bu, her bir işlemi yürütmek için gereken çeşitli durum/depolama düğümleri olacaktır). Deneysel kanıtlar, yeni bir Ethereum bloğu için bu tam veri kümesini gösteriyor en fazla birkaç yüz KiB olacaktır. Eş zamanlı olarak, henüz yapılmadıysa validator Başlangıçta önceki bloğun geçişinden önceki bloğun geçişine ilişkin bilgileri almaya çalışmak validators ve sonrası için imza atan tüm validators'den verilerin kullanılabilirliği. validator böyle bir aday bloğu aldığında, daha sonra bunu yerel olarak doğrularlar. Doğrulama işlemi parachain sınıfının validator modülünde bulunur; yazılması gereken fikir birliğine duyarlı yazılım modülü Polkadot'nin herhangi bir uygulaması için (prensipte olsa da) C ABI'ye sahip bir kütüphane, tek bir kütüphanenin uygulamalar arasında uygun şekilde paylaştırılmalıdır. yalnızca tek bir “referans” uygulamaya sahip olmaktan kaynaklanan güvenlik azalması). Süreç, önceki bloğun başlığını alır ve yakın zamanda üzerinde anlaşmaya varılan aktarma zinciri aracılığıyla kimliğini doğrular. hash kaydedilmesi gereken blok. Ana başlığın geçerliliği doğrulandıktan sonra özel parachain sınıfın doğrulama işlevi çağrılabilir. Bu, bir dizi veri alanını kabul eden tek bir işlevdir (kabaca daha önce verilenler) ve basit bir Boole değeri döndürmek bloğun geçerliliğini ilan ediyor. Bu tür doğrulama işlevlerinin çoğu ilk olarak doğrudan türetilebilen başlık alanları ana blok (örn. ebeveyn hash, sayı). Takip ediliyor bunu yaparak, herhangi bir dahili veri yapısını şu şekilde dolduracaklar: işlemleri ve/veya gönderileri işlemek için gerekli. Ethereum benzeri bir zincir için bu, bir için ihtiyaç duyulacak düğümleri içeren veritabanını deneyin. işlemlerin tam olarak yürütülmesi. Diğer zincir türlerinde şunlar olabilir: diğer ponarıcı mekanizmalar. İşlem tamamlandıktan sonra, giriş gönderileri ve harici işlemler (veya harici verilerin temsil ettiği şey) zincirin spesifikasyonuna göre dengelenmiş, yürürlüğe konmuştur. (Bir mantıklı varsayılan, tüm giriş gönderilerinin olmasını gerektirmek olabilir harici işlemlere hizmet verilmeden önce işlenir, ancak buna parachain mantığının karar vermesi gerekir.) Bu yasayla bir dizi çıkış noktası oluşturulacak. oluşturuldu ve bunların gerçekten eşleştiği doğrulanacak derleyicinin adayı. Son olarak, uygun şekilde doldurulmuş başlık, adayın başlığına göre kontrol edilecektir. Tamamen doğrulanmış bir aday blokla validator daha sonra başlığının hash'sına oy verebilir ve gerekli tüm doğrulama bilgilerini alt grubundaki ortak validator'lere gönderebilir. 6.7.1. Parachain Düzenleyicileri. Parachain harmanlayıcıları madencilerin görevlerinin çoğunu yerine getiren bağımsız operatörlerdir günümüzün blockchain ağlarında. Bunlar spesifiktir belirli bir parachain'e. Çalıştırmak için şunları yapmaları gerekir: hem röle zincirini hem de tam senkronizeyi koruyun Parachain. "Tam senkronize"nin kesin anlamı parachain sınıfına bağlı olacaktır ancak her zaman parachain giriş kuyruğunun mevcut durumunu içerecektir. Ethereum durumunda bu aynı zamanda en azından bakımı da içerir son birkaç bloğun Merkle ağacı veri tabanı, ancak ayrıca Bloom dahil çeşitli diğer veri yapılarını da içerir Hesabın varlığı, aile bilgileri, günlük kaydı için filtreler blok numarası için çıkışlar ve geriye doğru arama tabloları. İki zinciri senkronize tutmanın yanı sıra, ayrıca bir işlem kuyruğunu koruyarak ve uygun şekilde doğrulanmış işlemleri kabul ederek işlemler için "avlanmalı" halka açık ağdan. Sıra ve zincirle, her blokta seçilen validator'ler için (aktarma zinciri senkronize olduğundan kimliği bilinen) yeni aday bloklar oluşturabilir ve bunları geçerlilik kanıtı gibi çeşitli yardımcı bilgiler eş ağ. Zahmetine karşılık, içerdiği işlemlere ilişkin tüm ücretleri tahsil eder. Bunun etrafında çeşitli ekonomiler dönüyor düzenleme. Yoğun rekabetin olduğu bir piyasada teminat verenlerin fazlalığı varsa, işlemin gerçekleşmesi mümkündür ücretler teşvik amacıyla validators parachain ile paylaşılacaktır belirli bir harmanlayıcı bloğunun dahil edilmesi. Benzer şekilde,

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 17 bazı düzenleyiciler ihtiyaç duyulan ücretleri bile artırabilir bloğun daha çekici hale getirilmesi için ödeme yapılması validators. Bu durumda doğal bir pazarın oluşması gerekmektedir. daha yüksek ücretler ödeyen işlemler kuyruğu atlıyor ve zincire daha hızlı dahil olma. 6.8. Ağ oluşturma. Geleneksel blockchains üzerinde ağ oluşturma Ethereum ve Bitcoin gibi oldukça basit gereksinimlere sahiptir. Tüm işlemler ve bloklar basit, yönlendirilmemiş bir dedikoduyla yayınlanır. Senkronizasyon daha kapsamlıdır, özellikle Ethereum ile ancak gerçekte bu mantık şunun içinde yer alıyordu: birkaç istek ve yanıt mesajı türü etrafında çözümlenen protokolün kendisinden ziyade akran stratejisi. Ethereum devp2p protokolüyle mevcut protokol teklifleri konusunda ilerleme kaydederken, bu da birçok kişiye olanak sağladı alt protokoller tek bir eş bağlantı üzerinden çoğaltılacak ve dolayısıyla aynı eş katman paylaşımına sahip olacak ve birçok p2p protokolleri aynı anda, Ethereum kısmı protokol hala nispeten basit kaldı ve p2p protokol bir süredir önemli konularla tamamlanmamış durumda QoS desteği gibi işlevsellik eksik. Ne yazık ki, daha yaygın bir "web 3" protokolü oluşturma arzusu büyük ölçüde başarısız oldu, bunu kullanan tek proje açıkça bunlardı Ethereum toplu satıştan finanse edildi. Polkadot ile ilgili gereksinimler oldukça daha önemlidir. Tamamen tek tip bir ağ yerine, Polkadot her birinin akran yapısından ve çeşitli ağlardan farklı gereksinimleri olan çeşitli katılımcı türleri vardır Katılımcıların hakkında sohbet etme eğiliminde olacağı “yollar” özel veriler. Bu, önemli ölçüde daha yapılandırılmış bir ağ katmanı ve bunu destekleyen bir protokol anlamına gelir. muhtemelen gerekli olacaktır. Ayrıca, yeni tür “zincir” gibi gelecekteki eklemeleri kolaylaştıracak genişletilebilirlik, kendileri yeni bir katman yapısı gerektirir. Ağ oluşturmanın nasıl yapıldığına dair derinlemesine bir tartışma protokol bu belgenin kapsamı dışında görünebilir, bazı gereksinim analizleri makul olabilir. Yapabiliriz ağ katılımcılarımızı kabaca iki gruba ayırın (röle zinciri, parachainler) her biri üç alt kümeden oluşur. Yapabiliriz ayrıca parachain katılımcılarının her birinin yalnızca aksine kendi aralarında sohbet etmekle ilgileniyorlar diğer parachainlerdeki katılımcılar: • Aktarma zinciri katılımcıları: • Doğrulayıcılar: P, her biri için P[s] alt kümelerine bölünür paraşütle atlama • Kullanılabilirlik Garantörleri: A (bu, protokolün temel formunda Doğrulayıcılar tarafından temsil edilebilir) • Aktarma zinciri istemcileri: M (her birinin üyelerini not edin) Parachain seti aynı zamanda M'nin üyesi olma eğiliminde olacaktır) • Parachain katılımcıları: • Parachain Düzenleyicileri: C[0], C[1], . . . • Parachain Balıkçıları: F[0], F[1], . . . • Parachain istemcileri: S[0], S[1], . . . • Parachain ışık istemcileri: L[0], L[1], . . . Genel olarak belirli iletişim sınıflarını adlandırırız bu kümelerin üyeleri arasında gerçekleşme eğiliminde olacaktır: • P | bir <-> P | C:

dolu ayarlamak arasında validators/garantörler zorunluluk olmak iyi bağlantılara sahip için fikir birliğine varmak. • P[s] <-> C[s] | P[s]: Belirli bir parachain grubunun üyesi olan her validator dedikodu yapma eğiliminde olacaktır bu tür diğer üyelerle ve derleyicilerle Blok adaylarını keşfetmek ve paylaşmak için bu parachain'in. • A <-> P[s] | C | A: Her kullanılabilirlik garantörü fikir birliğine duyarlı çapraz zincirleri toplaması gerekecek kendisine atanan validator'lardan gelen veriler; derleyiciler aynı zamanda fikir birliği şansını da optimize edebilir kullanılabilirlik garantörlerine reklam vererek engelleyin. Ellerine geçtikten sonra veriler şu adrese dağıtılacak: fikir birliğini kolaylaştırmak için bu tür başka garantörler. • P[s] <-> A | P[s']: Parachain validators olacak önceki validator grubundan veya kullanılabilirlik garantörlerinden ek giriş verileri toplaması gerekiyor. • F[s] <-> P: Balıkçılar rapor verirken herhangi bir katılımcıyla ilgili bir hak talebi. • M <-> M | P | C: Genel aktarma zinciri istemcileri, verileri validator'lerden ve garantörlerden dağıtır. • S[s] <-> S[s] | P[ler] | C: Parachain istemcileri verileri validator/garantörlerden dağıtır. • L[s] <-> L[s] | S[s]: Parachain ışık istemcileri Verileri tam istemcilerden dağıtın. Verimli bir taşıma mekanizması sağlamak için “düz” bir yer paylaşımlı ağ (Ethereum'nin devp2p'si gibi) burada her biri düğüm, kendi uygunluk değerini (keyfi olmayan bir şekilde) farklılaştırmaz. akranlarının uygun olması muhtemel değildir. Makul ölçüde genişletilebilir akran seçimi ve keşif mekanizması muhtemelen ihtiyaç duyacaktır agresif olmasının yanı sıra protokole dahil edilecek Doğru türden akranları sağlamak için ileriye yönelik bir planlama planlamak "tesadüfen" bağlanıyorlardoğru zamanda harekete geçtik. Akran oluşturmanın kesin stratejisi her katılımcı sınıfı için farklı olacaktır: uygun şekilde ölçeklendirilmiş bir çoklu zincir, harmanlayıcıların ya sürekli olması gerekecek buna uygun olarak seçilen validator'lere yeniden bağlanılıyor veya validators alt kümesiyle devam eden anlaşmalara ihtiyaç var validator için işe yaramaz oldukları çoğu zaman bağlantılarının kesilmediğinden emin olmak için. Düzenleyiciler aynı zamanda doğal olarak bir tanesini korumaya çalışacaklardır. veya kullanılabilirlik garantörüne daha istikrarlı bağlantılar fikir birliğine duyarlı yaklaşımlarının hızlı bir şekilde yayılmasını sağlamak üzere kurulmuştur. veri. Kullanılabilirlik garantörleri çoğunlukla bir birbirleriyle ve validators ile istikrarlı bağlantı (konsensüs ve konsensüs açısından kritik parachain verileri için) onaylıyorlar) ve bazı derleyicilere (parachain için) veriler) ve bazı balıkçılar ve tam müşteriler (dağıtım için) bilgi). Doğrulayıcılar diğer validator'leri, özellikle de aynı alt gruptakileri ve herhangi bir onlara parachain blok adayları sağlayabilecek harmanlayıcılar. Balıkçılar ve genel bayrak zinciri ve parachain istemciler genellikle bağlantıyı açık tutmayı hedeflerler. validator veya garantör, ancak benzer birçok başka düğüm var aksi takdirde kendilerine. Parachain hafif istemcileri de benzer şekilde parachain'in tam istemcisine bağlanmayı hedefleyecektir. sadece diğer parachain ışık istemcileri olmasa da. 6.8.1. Akran Kaybı Sorunu. Temel protokol teklifinde, bu alt kümelerin her biri, doğrulama için atanan validator'ler olarak her blokta rastgele olarak değişir. Parachain geçişleri rastgele seçilir. Bu olabilir farklı (eş olmayan) düğümlerin bir sorun olması gerekir birbirleri arasında veri aktarımı. Ya güvenmek gerekir adil bir şekilde dağıtılmış ve iyi bağlanmış bir eş ağ

POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 18 Atlama mesafesinin (ve dolayısıyla en kötü durumdaki gecikmenin) yalnızca ağ boyutunun logaritmasıyla arttığından emin olun (Kademlia benzeri bir protokol [13] burada yardımcı olabilir) veya bir eş kümesini korumak için gerekli bağlantı anlaşmasının gerçekleşmesine izin vermek amacıyla daha uzun blok süreleri uygulayın. düğümün mevcut iletişim ihtiyaçlarını yansıtır. Bunların hiçbiri mükemmel çözüm değil: uzun blok süreleri ağa zorlanmak onu işe yaramaz hale getirebilir özel uygulamalar ve zincirler. Hatta mükemmel bir adil ve bağlı ağ önemli miktarda israfa neden olacaktır İlgisiz düğümlerin sahip olması nedeniyle ölçeklendikçe bant genişliği onlara faydası olmayan verileri iletmek. Her iki yön de çözümün bir parçasını oluştursa da, Gecikmeyi en aza indirmeye yardımcı olacak makul bir optimizasyon bu parachain'in volatilitesini kısıtlamak için validator üyeliği yalnızca blok serileri arasında yeniden atayarak (örneğin 15'li gruplar halinde, 4 saniyede bir blok süresi, bağlantıların yalnızca bir kez değiştirilmesi anlamına gelir dakika) veya üyeliği kademeli olarak değiştirerek, örn. bir seferde bir üye tarafından değiştiriliyor (örneğin eğer varsa) Her bir parachain'e 15 validator atanmışsa, bu durumda ortalama olarak tamamen benzersiz olanlarla arasında tam bir dakika olacaktır. setleri). Akran kaybının miktarını sınırlayarak ve avantajlı akran bağlantılarının iyi bir şekilde kurulmasını sağlayarak Parachain'in kısmi öngörülebilirliği yoluyla ilerlemek ayarlar, her düğümün kalıcı olarak korunmasına yardımcı olabiliriz tesadüfen akran seçimi. 6.8.2. Etkili Bir Ağ Protokolüne Giden Yol. Muhtemelen En etkili ve makul geliştirme çabası, yuvarlanmak yerine önceden var olan bir protokolün kullanılmasına odaklanacaktır. bizim. Çeşitli eşler arası temel protokoller mevcuttur Ethereum'nin kendi devp2p'sini kullanabilir veya artırabiliriz [22], IPFS'nin libp2p'si [1] ve GNU'nun GNUnet'i [4]. Bu protokollerin tam bir incelemesi ve bunların bir Belirli yapısal garantileri, dinamik eş yönlendirmeyi ve genişletilebilir alt protokolleri destekleyen modüler eş ağ bu belgenin kapsamı dışındadır ancak bir Polkadot'nin uygulanmasında önemli bir adım. 7. Protokolün Uygulanabilirliği 7.1. Zincirler Arası İşlem Ödemesi. Harika bir zaman Ethereum'nin gazı gibi bütünsel bir hesaplama kaynağı muhasebe çerçevesine olan ihtiyacın ortadan kaldırılmasıyla bir miktar özgürlük ve basitlik kazanılır, bu önemli bir soruyu gündeme getirir: Gaz olmadan bir parachain nasıl yapılır? Başka bir parachain'in onu hesaplama yapmaya zorlamasını önlemek mi istiyorsunuz? İşlem sonrası giriş kuyruğuna güvenebiliriz Bir zincirin diğerine spam göndermesini önlemek için tamponlar işlem verileri, işlem sırasında spam gönderilmesini önlemek için protokol tarafından sağlanan eşdeğer bir mekanizma yoktur. Bu daha üst seviyeye bırakılmış bir sorundur. Zincirlerden beri gelen mesajlara keyfi anlambilim eklemekte özgürdürler. işlem sonrası veriler, hesaplamanın yapılmasını sağlayabiliriz başlamadan önce ödenmesi gerekmektedir. Buna benzer bir şekilde Ethereum Serenity'nin benimsediği model, hayal edebiliyoruz izin veren bir parachain içindeki "zorla girme" sözleşmesi validator karşılığında ödeme garanti edilecek belirli bir hacimde işlem kaynağının sağlanması. Bu kaynaklar gaz gibi bir şeyle ölçülebilir, ancak aynı zamanda öznel uygulama süresi veya Bitcoin benzeri sabit ücret modeli gibi tamamen yeni bir model de olabilir. Bu tek başına o kadar da kullanışlı değil çünkü zincir dışı arayanın onlara ulaşabildiğini kolayca varsayamayız. Hırsızlık tarafından tanınan değer mekanizması ne olursa olsun sözleşme. Ancak kaynak zincirinde ikincil bir “kırılma” sözleşmesi hayal edebiliriz. İki sözleşme birlikte birbirini tanıyan bir köprü oluşturacak ve değer eşdeğerliği sağlar. (Stake etme-tokens, mevcut her biri ödemeler dengesini dengelemek için kullanılabilir.) Böyle başka bir zincire çağrı yapmak, vekillik yapmak anlamına gelir ulaşımı sağlayacak olan bu köprüden zincirler arasında değer aktarımının müzakere edilmesi Hedef parachain'de gereken hesaplama kaynakları için ödeme yapın. 7.2. Ek Zincirler. iken the ekleme arasında bir parachain nispeten ucuz bir işlemdir, ücretsiz değildir. Daha fazla parachain, parachain başına daha az validators anlamına gelir ve sonunda her biri bir değere sahip daha fazla sayıda validator azaltılmış ortalama tahvil. Parachain'e saldırmanın daha küçük bir zorlama maliyeti sorunu, balıkçılar, büyüyen validator grubu aslında bir altta yatan fikir birliğinin mekaniği nedeniyle daha yüksek gecikme derecesiama. Ayrıca her parachain validators'yi üzme potansiyelini de beraberinde getiriyor aşırı külfetli doğrulama algoritması. Bu nedenle, validators tutarında bir "fiyat" olacaktır. ve/veya paydaş topluluğunun çıkaracağı yeni bir parachain eklenmesi. Zincirlere yönelik bu pazar muhtemelen aşağıdakilerden birinin eklendiğini görebilirsiniz: • Bir parçası haline getirilecek net katkı payı ödemesi muhtemelen sıfır olan zincirler (staking tokens'nin kilitlenmesi veya yakılması açısından) (örn. konsorsiyum zincirleri, Doge zincirleri, uygulamaya özel zincirler); • ağa gerçek değer sağlayan zincirler belirli işlevlerin eklenmesi zor başka bir yere ulaşmak (örneğin gizlilik, dahili ölçeklenebilirlik, hizmet bağlantıları). Esasen, paydaş topluluğunun şunları yapması gerekecektir: finansal veya finansal olarak alt zincirler eklemeye teşvik edilebilir röleye özellikli zincirler ekleme arzusuyla. Eklenen yeni zincirlerin çok büyük bir etki yaratacağı öngörülüyor. yeni zincirlerin çıkarılmasına olanak tanıyan kısa bir çıkarma süresi taviz verme riski olmadan denenebilir orta veya uzun vadeli değer teklifi. 8. Sonuç Bir kişinin bir makale yazmak için izleyebileceği bir yönü özetledik önceden var olan belirli protokollerle geriye doğru uyumlu olma potansiyeline sahip, ölçeklenebilir, heterojen çok zincirli protokol blockchain ağlar. Böyle bir protokol kapsamında katılımcılar İstisnai derecede özgür bir şekilde genişletilebilecek ve mevcut kullanıcılar için tipik bir maliyet olmaksızın genişletilebilecek genel bir sistem oluşturmak için aydınlanmış kişisel çıkarlar doğrultusunda çalışın. standart bir blockchain tasarımından gelir. biz verdik dahil olacak mimarinin kaba bir taslağı katılımcıların doğası, ekonomik teşvikleri ve dahil olmaları gereken süreçler. bizde temel bir tasarım tanımladı ve onun güçlü yönlerini tartıştı ve sınırlamalar; buna göre başka talimatlarımız da var bu sınırlamaları hafifletebilir ve tamamen ölçeklenebilir bir blockchain çözümüne doğru daha fazla zemin sağlayabilir.POLKADOT: HETEROJEN ÇOK ZİNCİRLİ BİR ÇERÇEVE VİZYONU TASLAK 1 19 8.1. Eksik Materyal ve Açık Sorular. Ağ çatallanması, protokolün farklı uygulamalarından dolayı her zaman bir olasılıktır. Böyle bir durumdan iyileşme olağanüstü durum tartışılmadı. Ağın zorunlu olarak sıfırdan farklı bir sonuçlandırma periyoduna sahip olacağı göz önüne alındığında, Aktarım zinciri çatallanmasından kurtulmak büyük bir sorun olmasa da, dikkatli bir entegrasyon gerektirecektir. fikir birliği protokolü. Tahvillere el konulması ve bunun tersine ödül hükmü derinlemesine araştırılmamıştır. Şu anda ödülleri varsayıyoruz kazanan her şeyi alır esasına göre sağlanır: bu Balıkçılara en iyi teşvik modelini verin. Kısa süreli bir taahhüt-açıklama süreci birçok balıkçının Ödüllerin daha adil dağılımını sağlayarak ödülü talep etmek, ancak süreç ek gecikmeye yol açabilir uygunsuz davranışın tespiti. 8.2. Teşekkürler. Hepsine çok teşekkürler Bunu belli belirsiz bir hale getirmeye yardımcı olan düzeltmenler prezentabl şekil. Özellikle Peter Czaban, Bjorn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler ve Jack Petersson. Herkese teşekkürler Fikirlere veya başlangıçlara katkıda bulunan insanlar Bu konuda Marek Kotewicz ve Aeron Buchanan özel olarak anılmayı hak ediyor. Ve yardımları için herkese teşekkürler yol boyunca. Tüm hatalar bana aittir. Bu çalışmanın bazı bölümleri, ilk araştırmalar da dahil olmak üzere fikir birliği algoritmaları kısmen İngilizler tarafından finanse edildi Innovate UK programı kapsamında hükümet.