Polkadot : vision d'un cadre multi-chaînes hétérogène

Polkadot: Vision for a Heterogeneous Multi-Chain Framework

作者 Gavin Wood · 2016

🇺🇸 English (原文)

🇫🇷 Français (译文)

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

Résumé

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 DR. GAVIN BOIS FONDATEUR, ETHEREUM & PARITÉ [email protected] Résumé. Les architectures blockchain actuelles souffrent toutes d'un certain nombre de problèmes, notamment les moyens pratiques d'extensibilité et d'évolutivité. Nous pensons que cela découle du fait de lier deux parties très importantes de l'architecture du consensus, à savoir canonicité et validité, trop étroitement liées. Cet article présente une architecture, la multi-chaîne hétérogène, ce qui distingue fondamentalement les deux. En compartimentant ces deux parties et en gardant la fonctionnalité globale fournie au minimum absolu de sécurité et de transport, nous introduisons des moyens pratiques d’extensibilité du noyau in situ. L'évolutivité est abordée via une approche « diviser pour mieux régner » sur ces deux fonctions, en s'éloignant de son noyau solidaire grâce à l'incitation des nœuds publics non fiables. La nature hétérogène de cette architecture permet à de nombreux types très divergents de systèmes de consensus d'interagir dans une « fédération » sans confiance et entièrement décentralisée, permettant aux réseaux ouverts et fermés d'avoir un accès sans confiance à les uns les autres. Nous proposons un moyen d'assurer une rétrocompatibilité avec un ou plusieurs réseaux préexistants tels que Ethereum. Nous pensons qu'un tel système constitue un élément de base utile dans la recherche globale d'un système implémentable capable d’atteindre les niveaux d’évolutivité et de confidentialité du commerce mondial. 1. Préface Ceci est destiné à être un résumé technique de la « vision » d'une direction possible qui pourrait être prise pour développer davantage le paradigme blockchain, ainsi que quelques justifications expliquant pourquoi cette direction est judicieuse. Il s'étend dans autant de détails que possible à ce stade de développement un système qui peut apporter une amélioration concrète sur un nombre d'aspects de la technologie blockchain. Il ne s’agit pas d’une spécification, formelle ou autre. Il n'est pas destiné à être exhaustif ni à être un conception finale. Il n’est pas destiné à couvrir les aspects non essentiels du framework tels que les API, les liaisons, les langages et utilisation. Ceci est particulièrement expérimental ; où les paramètres sont précisés, ils sont susceptibles de changer. Les mécanismes être ajouté, affiné et supprimé en réponse aux besoins de la communauté idées et critiques. De grandes parties de ce document seront probablement être révisé à mesure que les preuves expérimentales et le prototypage le donnent nous des informations sur ce qui fonctionnera et ce qui ne fonctionnera pas. Ce document comprend une description de base du protocole ainsi que des idées d'orientations qui peuvent être prises pour améliorer divers aspects. Il est prévu que le noyau description servira de point de départ à une première série de preuves de concept. Une dernière « version 1.0 » serait basé sur ce protocole raffiné ainsi que sur les idées supplémentaires qui ont fait leurs preuves et sont déterminées à nécessaires pour que le projet atteigne ses objectifs. 1.1. Histoire. • 10/09/2016 : 0.1.0-proof1 • 20/10/2016 : 0.1.0-proof2 • 01/11/2016 : 0.1.0-proof3 • 11/10/2016 : 0.1.0 2. Présentation Les blockchains se sont révélées très prometteuses dans plusieurs domaines, notamment celui de « l’Internet des objets ». (IoT), finance, gouvernance, gestion des identités, décentralisation du Web et suivi des actifs. Cependant, malgré le promesse technologique et grand discours, nous n'avons pas encore vu déploiement significatif dans le monde réel de la technologie actuelle. Nous pensons que cela est dû à cinq échecs majeurs du système actuel. piles technologiques : Évolutivité : combien de ressources sont dépensées à l'échelle mondiale sur le traitement, la bande passante et le stockage pour que le système puisse traiter une seule transaction et combien les transactions peuvent être raisonnablement traitées sous conditions de pointe ? Isolatabilité : les besoins divergents de plusieurs les parties et les demandes soient-elles traitées à un degré quasi optimal dans le même cadre ? Développabilité : dans quelle mesure les outils fonctionnent-ils ? Faire les API répondent-elles aux besoins des développeurs ? Des supports pédagogiques sont-ils disponibles ? Les bonnes intégrations sont-elles là ? Gouvernance : le réseau peut-il rester ﬂexible évoluer et s'adapter au fil du temps ? Les décisions peuvent-elles être fait avec suffisamment d’inclusivité, de légitimité et transparence pour assurer un leadership efficace d’un système décentralisé ? Applicabilité : la technologie répond-elle réellement à elle seule à un besoin pressant ? Un autre « middleware » est-il nécessaire pour combler le fossé entre applications réelles ? Dans le présent travail, nous visons à aborder les deux premiers enjeux : évolutivité et isolabilité. Cela dit, nous croyons le cadre Polkadot peut apporter des améliorations significatives dans chacune de ces classes de problèmes. Des implémentations blockchain modernes et efficaces telles que le client Parité Ethereum [17] peut déclencheress au-delà de 3 000 transactions par seconde lors de l'exécution sur du matériel grand public performant. Cependant, le monde réel actuel Les réseaux blockchain sont pratiquement limités à une trentaine de transactions par seconde. Cette limitation provient principalement du fait que les mécanismes actuels de consensus synchrone nécessitent de larges marges de sécurité temporelles sur le délai de traitement prévu, qui est exacerbé par le 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.

Introduction

Les blockchains se sont révélées très prometteuses dans plusieurs domaines, notamment celui de « l’Internet des objets ». (IoT), finance, gouvernance, gestion des identités, décentralisation du Web et suivi des actifs. Cependant, malgré le promesse technologique et grand discours, nous n'avons pas encore vu déploiement significatif dans le monde réel de la technologie actuelle. Nous pensons que cela est dû à cinq échecs majeurs du système actuel. piles technologiques : Évolutivité : combien de ressources sont dépensées à l'échelle mondiale sur le traitement, la bande passante et le stockage pour que le système puisse traiter une seule transaction et combien les transactions peuvent être raisonnablement traitées sous conditions de pointe ? Isolatabilité : les besoins divergents de plusieurs les parties et les demandes soient-elles traitées à un degré quasi optimal dans le même cadre ? Développabilité : dans quelle mesure les outils fonctionnent-ils ? Faire les API répondent-elles aux besoins des développeurs ? Des supports pédagogiques sont-ils disponibles ? Les bonnes intégrations sont-elles là ? Gouvernance : le réseau peut-il rester ﬂexible évoluer et s'adapter au fil du temps ? Les décisions peuvent-elles être fait avec suffisamment d’inclusivité, de légitimité et transparence pour assurer un leadership efficace d’un système décentralisé ? Applicabilité : la technologie répond-elle réellement à elle seule à un besoin pressant ? Un autre « middleware » est-il nécessaire pour combler le fossé entre applications réelles ? Dans le présent travail, nous visons à aborder les deux premiers enjeux : évolutivité et isolabilité. Cela dit, nous croyons le cadre Polkadot peut apporter des améliorations significatives dans chacune de ces classes de problèmes. Des implémentations blockchain modernes et efficaces telles que le client Parité Ethereum [17] peut traiter au-delà de 3 000 transactions par seconde lors de l'exécution sur du matériel grand public performant. Cependant, le monde réel actuel Les réseaux blockchain sont pratiquement limités à une trentaine de transactions par seconde. Cette limitation provient principalement du fait que les mécanismes actuels de consensus synchrone nécessitent de larges marges de sécurité temporelles sur le délai de traitement prévu, qui est exacerbé par lePOLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 2 désir de prendre en charge des mises en œuvre plus lentes. Ceci est dû à l’architecture consensuelle sous-jacente : le mécanisme de transition étatique, ou les moyens par lesquels les parties se rassemblent et exécuter des transactions, a sa logique fondamentalement liée dans le mécanisme de « canonisation » du consensus, ou moyen par lequel les parties conviennent d'un certain nombre de des histoires possibles et valides. Cela s'applique également aux systèmes proof-of-work (PoW) tels que Bitcoin [15] et Ethereum [5,23] et aux systèmes de preuve de participation (PoS) tels que NXT [8] et Bitshares [12] : tous souffrent finalement du même handicap. C'est un simple stratégie qui a contribué au succès de blockchain. Cependant, en couplant étroitement ces deux mécanismes en une seule unité du protocole, nous regroupons également plusieurs des acteurs et des applications présentant différents profils de risque, différentes exigences d’évolutivité et différents besoins en matière de confidentialité. Une taille unique ne convient pas à tout le monde. Trop souvent, il arrive que dans un désir d'attirer un large public, un réseau adopte un certain degré de conservatisme qui se traduit par un plus petit dénominateur commun servir de manière optimale quelques-uns et conduire finalement à un échec dans la capacité à innover, à performer et à s'adapter, parfois dramatiquement. Certains systèmes tels que par ex. Factom [21] abandonne complètement le mécanisme de transition d'état. Cependant, une grande partie des l'utilité que nous désirons nécessite la capacité de passer d'un état à l'autre selon une machine à états partagée. Le laisser tomber résout un problème alternatif ; cela ne fournit pas d'alternative solution. Il semble donc clair qu'une direction raisonnable à explorer comme voie vers un calcul décentralisé évolutif plateforme est de dissocier l’architecture de consensus de le mécanisme de transition d’État. Et, sans surprise, c’est la stratégie adoptée par Polkadot comme solution d’évolutivité. 2.1. Protocole, mise en œuvre et réseau. Comme Bitcoin et Ethereum, Polkadot font à la fois référence à un protocole réseau et au protocole principal (jusqu'ici présupposé) réseau public qui exécute ce protocole. Polkadot se veut un projet libre et ouvert, la spécification du protocole étant sous licence Creative Commons et le le code étant placé sous une licence FLOSS. Le projet est développé de manière ouverte et accepte les contributions partout où ils sont utiles. Un système de RFC, un peu comme les propositions d'amélioration de Python, permettront de collaborer publiquement sur les modifications et les mises à niveau du protocole. Notre mise en œuvre initiale du protocole Polkadot sera connue sous le nom de Plateforme Parity Polkadot et inclure une implémentation complète du protocole avec l'API liaisons. Comme les autres implémentations de Parity blockchain, PPP est conçu pour être une pile technologique blockchain à usage général, ni uniquement pour un réseau public ni pour opération privée/consortium. Son développement donc jusqu'à présent, a été financé par plusieurs parties, notamment à travers une subvention du gouvernement britannique. Cet article décrit néanmoins Polkadot sous le contexte d’un réseau public. La fonctionnalité que nous envisageons dans un réseau public est un surensemble de celle requise dans contextes alternatifs (par exemple privés et/ou consortium). De plus, dans ce contexte, la portée complète de Polkadot peut être décrit et discuté plus clairement. Cela veut dire le lecteur doit être conscient que certains mécanismes peuvent être décrits (par exemple l'interfonctionnement avec d'autres réseaux publics) qui ne concernent pas directement Polkadot lorsqu'ils sont déployés dans des situations non publiques (« autorisées »). 2.2. Travaux antérieurs. Il a été proposé de manière informelle de dissocier le consensus sous-jacent de la transition étatique. en privé pendant au moins deux ans – Max Kaye était partisan d’une telle stratégie dès les premiers jours de Ethereum. Une solution évolutive plus complexe connue sous le nom de Chain fibres, datant de juin 2014 et publié pour la première fois plus tard cette année-là1, a plaidé en faveur d’une chaîne de relais unique et de plusieurs chaînes homogènes fournissant un mécanisme d’exécution inter-chaînes transparent. La décohérence a été payée via la latence des transactions (transactions nécessitant le la coordination de parties disparates du système serait prendre plus de temps à traiter. Polkadot tire une grande partie de son architecture de cela et des conversations de suivi avec diverses personnes, bien qu'il diffère grandement dans une grande partie de sa conception et de ses dispositions. Bien qu'il n'existe aucun système comparable à Polkadot actuellement en production, plusieurs systèmes d'une certaine pertinence ont été proposés, bien que peu nombreux et à un niveau substantiel de détail. Ces propositions peuvent êtredécomposé en systèmes qui abandonnent ou réduisent la notion de cohérence globale machine à états, celles qui tentent de fournir un système global machine singleton cohérente à travers des fragments homogènes et celles qui ciblent uniquement l’hétérogénéité. 2.2.1. Systèmes sans état global. Factom [21] est un système qui démontre la canonicité sans les validité, permettant effectivement la chronique des données. En raison de la nécessité d'éviter l'état mondial et les difficultés avec la mise à l'échelle que cela apporte, cela peut être considéré comme une solution évolutive. Cependant, comme mentionné précédemment, l'ensemble Le nombre de problèmes qu’il résout est strictement et sensiblement moindre. Tangle [18] est une nouvelle approche des systèmes de consensus. Plutôt que d'organiser les transactions en blocs et de former un consensus sur une liste strictement liée pour donner un ordre globalement canonique des changements d'état, il abandonne largement l'idée d'un ordre fortement structuré et préfère plutôt pousse à un graphique acyclique dirigé des transactions dépendantes avec des éléments ultérieurs aidant à canoniser les éléments antérieurs grâce à des références explicites. Pour les changements d'état arbitraires, ce graphe de dépendance deviendrait vite insoluble, cependant, pour le modèle UTXO2 beaucoup plus simple, cela devient tout à fait raisonnable. Parce que le système n’est que vaguement cohérent et que les transactions sont généralement indépendantes les unes des autres. d'autre part, une grande partie du parallélisme mondial devient tout à fait naturel. L'utilisation du modèle UTXO a l'eﬀet de limiter Tangle à une « monnaie » purement de transfert de valeur système plutôt que quelque chose de plus général ou extensible. De plus, sans la stricte cohérence globale, l'interaction avec d'autres systèmes, qui ont tendance à nécessiter une cohérence absolue, une connaissance approfondie de l’état du système devient peu pratique. 1https://github.com/ethereum/wiki/wiki/Chain-Fibers-Redux 2sortie de transaction non dépensée, le modèle utilisé par Bitcoin dans lequel l'état est en fait l'ensemble d'adresses associé à une certaine valeur ; les transactions rassemblent ces adresses et les reforment en un nouvel ensemble d'adresses dont la somme totale est équivalente

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 3 2.2.2. Systèmes de chaînes hétérogènes. Les chaînes latérales [3] sont un ajout proposé au protocole Bitcoin qui permettrait une interaction sans confiance entre la chaîne principale Bitcoin et des chaînes latérales supplémentaires. Aucune disposition n'est prévue pour degré d’interaction « riche » entre les chaînes latérales : l’interaction se limiterait à permettre aux chaînes latérales d’être gardiens des actifs de chacun, eﬀectuant – au niveau local jargon - une ancrage à double sens 3. La vision finale est celle d'un cadre dans lequel la monnaie Bitcoin pourrait être dotée de fonctionnalité supplémentaire, bien que périphérique, grâce à son rattachement sur d'autres chaînes avec une transition d'état plus exotique systèmes que le protocole Bitcoin ne le permet. En ce sens, les chaînes latérales abordent l’extensibilité plutôt que l’évolutivité. En effet, il n’existe fondamentalement aucune disposition relative à la validité des side-chains ; tokens d'une chaîne (par exemple Bitcoin) détenus au nom d'une side-chain sont garantis uniquement par le la capacité de la chaîne latérale à inciter les mineurs à canoniser transitions valides. La sécurité du réseau Bitcoin ne peut pas facilement être transféré pour travailler pour le compte d’autres blockchains. De plus, un protocole pour assurer Bitcoin les mineurs fusionnent le mien (c'est-à-dire dupliquent leur pouvoir de canonisation sur celui de la side-chain) et, plus important encore, valident que les transitions de la side-chain sont en dehors du portée de cette proposition. Cosmos [10] est un système multi-chaîne proposé dans le même veine que les side-chains, en échangeant le Nakamoto PoW méthode de consensus pour l’algorithme Tendermint de Jae Kwon. Essentiellement, il décrit plusieurs chaînes (opérant dans zones) chacune utilisant des instances individuelles de Tendermint, ainsi qu'un moyen de communication sans confiance via un chaîne de moyeu principale. Cette communication inter-chaînes est limitée au transfert d'actifs numériques (« en particulier sur tokens ») plutôt qu'à des informations arbitraires, mais une telle communication inter-chaînes a un chemin de retour pour les données, par ex. informer l'expéditeur de l'état du transfert. Ensembles de validateurs pour les chaînes zonées, et en particulier les moyens de les inciter sont, comme les chaînes latérales, laissés comme un problème non résolu. L'hypothèse générale est que chaque chaîne zonée détiendra elle-même un token de valeur dont l'inflation est utilisée pour payer les validator. Encore au début de conception, à l'heure actuelle, la proposition manque de détails complets sur les moyens économiques permettant d'atteindre l'évolutivité certitude sur la validité globale. Cependant, la faible cohérence requise entre les zones et le hub permettra pour une ﬂexibilité supplémentaire sur les paramètres du zonage chaînes par rapport à celle d’un système imposant des cohérence. 2.2.3. Casper. Pour l'instant, aucun examen complet ni comparaison côte à côte entre Casper [6] et Polkadot ont été faites, même si l'on peut faire une analyse assez radicale (et par conséquent inexacte) caractérisation des deux. Casper est une réinvention de la façon dont un algorithme de consensus PoS pourrait être basé sur des participants pariant sur quelle fourchette deviendrait finalement canonique. Une attention considérable a été accordée à la garantie qu'il soit robuste pour le réseau forks, même lorsqu'ils sont prolongés, et ont un certain degré d'évolutivité supplémentaire en plus du modèle de base Ethereum. Comme Ainsi, Casper à ce jour a eu tendance à être beaucoup plus protocole complexe que Polkadot et ses ancêtres, et un écart substantiel par rapport au format de base blockchain. Il on ne sait toujours pas comment Casper va itérer à l'avenir et à quoi il ressemblera s’il est finalement déployé. Alors que Casper et Polkadot représentent tous deux de nouveaux protocoles intéressants et, dans un certain sens, des augmentations de Ethereum, il existe des différences substantielles entre leurs objectifs ultimes et voies de déploiement. Casper est un Ethereum Projet centré sur la fondation initialement conçu être une modification PoS du protocole sans volonté de créer un blockchain fondamentalement évolutif. Fondamentalement, c'est conçu pour être un hard-fork, plutôt que quelque chose de plus expansif et donc tous les clients et utilisateurs Ethereum seraient nécessaire pour mettre à niveau ou rester sur un fork d’adoption incertaine. En tant que tel, le déploiement est rendu beaucoup plus difficile, ce qui est inhérent à un projet décentralisé où des une coordination est nécessaire. Polkadot diffère de plusieurs manières ; avant tout, Polkadot est conçu pour être un système entièrement extensible et évolutif. blockchain test de développement, de déploiement et d'interaction lit. Il est conçu pour être un harnais largement évolutif, capable de assimiler le nouveau blockchainla technologie dès qu’elle devient disponible sans coordination décentralisée trop compliquée ou des fourches dures. Nous envisageons déjà plusieurs cas d'utilisation tels comme chaînes de consortium cryptées et chaînes à haute fréquence avec des temps de blocage très faibles, irréalistes à réaliser toute version future de Ethereum actuellement envisagée. Enfin, le couplage entre celui-ci et Ethereum est extrêmement lâche; aucune action de la part de Ethereum n'est nécessaire pour activer le transfert de transactions sans confiance entre les deux réseaux. En bref, alors que Casper/Ethereum 2.0 et Polkadot partagent quelques similitudes éphémères, nous pensons que leur objectif final est sensiblement différent et que plutôt que de rivaliser, les deux protocoles finiront probablement par coexister dans le cadre d’un relation mutuellement bénéfique dans un avenir prévisible.

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.

Résumé

Polkadot est une multi-chaîne hétérogène évolutive. Ceci signifie que contrairement aux implémentations précédentes de blockchain qui se sont concentrés sur la fourniture d'une chaîne unique de différents degrés de généralité sur les applications potentielles, Polkadot lui-même est conçu pour fournir aucune fonctionnalité d’application inhérente. Au lieu de cela, Polkadot fournit le fondement « chaîne relais » sur laquelle un grand nombre de données validables, des structures de données dynamiques globalement cohérentes peuvent être hébergées côte à côte. Nous appelons ces structures de données « parallélisées » chaînes ou parachaines, bien qu'il n'y ait pas de besoin spécifique de ils doivent être de nature blockchain. En d'autres termes, Polkadot peut être considéré comme équivalent à un ensemble de chaînes indépendantes (par exemple l'ensemble contenant Ethereum, Ethereum Classic, Namecoin et Bitcoin) sauf deux points très importants : • Sécurité mutualisée ; • Transactabilité inter-chaînes sans confiance. Ces points sont la raison pour laquelle nous considérons Polkadot comme étant « évolutif ». En principe, un problème à déployer sur Polkadot peut être considérablement parallélisé (évolué) sur un grand nombre de parachaines. Puisque tous les aspects de chacun la parachain peut être conduite en parallèle par un segment diﬀérent du réseau Polkadot, le système a une certaine capacité à l'échelle. Polkadot fournit un élément plutôt simple de 3par opposition à un ancrage à sens unique qui consiste essentiellement à détruire les token dans une chaîne pour créer des token dans une autre sans que mécanisme pour faire l'inverse afin de récupérer les token d'originePOLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 4 infrastructure laissant une grande partie de la complexité à résoudre au niveau du middleware. Il s'agit d'une décision consciente destinée à réduire les risques de développement, permettant au logiciel requis à développer dans un court laps de temps et avec un bon niveau de conﬁance quant à sa sécurité et robustesse. 3.1. La philosophie de Polkadot. Polkadot devrait fournir une base solide comme le roc sur laquelle construire la prochaine vague de systèmes de consensus, tout au long le spectre des risques des conceptions matures capables de production aux idées naissantes. En offrant de solides garanties en matière de sécurité, d'isolement et de communication, Polkadot peut permettre parachains pour choisir eux-mêmes parmi une gamme de propriétés. En effet, nous prévoyons diverses blockchain expérimentales poussant les propriétés de ce qui pourrait être considéré comme raisonnable. aujourd'hui. Nous voyons des conservateurs, chaînes à haute valeur similaires à Bitcoin ou Z-cash [20] coexistant avec des valeurs de moindre valeur « chaînes thématiques » (tel le marketing, si amusant) et réseaux de test avec des frais nuls ou quasi nuls. Nous voyons entièrement crypté, « sombres », des chaînes de consortium opérant aux côtés – et même fournir des services à des chaînes hautement fonctionnelles et ouvertes comme ceux comme Ethereum. Nous voyons de nouvelles expériences Chaînes basées sur des machines virtuelles telles qu'un wasm subjectif chargé en temps chaîne utilisée comme moyen d'externalisation de problèmes de calcul difficiles à partir d'une chaîne de type Ethereum plus mature ou une chaîne de type Bitcoin plus restreinte. Pour gérer les mises à niveau de la chaîne, Polkadot sera intrinsèquement soutenir une sorte de structure de gouvernance, probablement basée sur les systèmes politiques stables existants et ayant un aspect bicaméral similaire au Conseil du Livre Jaune [24]. Comme l'autorité ultime, les détenteurs sous-jacents de token jalonnables auraient un contrôle « référendaire ». Pour refléter les attentes des utilisateurs besoin de développement mais le besoin de légitimité des développeurs, nous nous attendons à ce qu'une direction raisonnable soit de se former les deux chambres d’un comité « usagers » (composé de cautionnés validators) et un comité « technique » composé de grands clients développeurs et acteurs de l’écosystème. Le un corps de détenteurs de token conserverait la légitimité ultime et formerait une majorité qualifiée pour augmenter, reparamétrer, remplacer ou dissoudre cette structure, ce que nous ne doutez pas de la nécessité éventuelle de : selon les mots de Twain « Les gouvernements et les couches doivent être changés souvent, et pour la même raison ». Alors que le reparamétrage est généralement simple à organiser dans le cadre d'un mécanisme de consensus plus large, des changements plus qualitatifs tels que le remplacement et l'augmentation seraient nécessaires. il faudra probablement soit des « décrets souples » non automatisés (par ex. par la canonisation d'un numéro de bloc et le hash d'un document précisant formellement le nouveau protocole) ou nécessiter que le mécanisme de consensus principal contienne un langage suffisamment riche pour décrire n’importe quel aspect de lui-même qui devra peut-être changer. Ce dernier est un objectif éventuel, cependant, les premiers sont plus susceptibles d'être choisis afin de faciliter un calendrier de développement raisonnable. Les principes fondamentaux de Polkadot et les règles dans lesquelles nous évaluons que toutes les décisions de conception sont : Minimal : Polkadot doit avoir le moins de fonctionnalités possible. Simple : aucune complexité supplémentaire ne devrait être présente dans le protocole de base que ce qui peut raisonnablement être déchargé dans le middleware, placé à travers un parachain ou introduit dans une optimisation ultérieure. Général : pas d'exigence, de contrainte inutile ou une limitation devrait être imposée aux parachaines ; Polkadot devrait être un banc d'essai pour le développement d'un système de consensus qui peut être optimisé grâce à rendre le modèle dans lequel les extensions s'intègrent aussi abstrait que possible. Robuste : Polkadot devrait fournir fondamentalement couche de base stable. Outre la solidité économique, cela signifie également décentraliser pour minimiser les vecteurs d’attaques à haute récompense.

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.

Participation à Polkadot

Il y a quatre rôles de base dans l'entretien d'un Polkadot réseau : assembleur, pêcheur, proposant et validator. Dans une implémentation possible de Polkadot, ce dernier rôle peut en fait se décomposer en deux rôles : validator de base et garant de disponibilité ; ceci est discuté dans la section 6.5.3. Assembleur Pêcheur Validateurs (ce groupe) Validateurs (autres groupes) approuve devient moniteurs rapports mauvais comportement à fournit un bloc candidats pour Proposant Figure 1. L'interaction entre le quatre rôles de Polkadot. 4.1. Validateurs. A validator est la charge la plus élevée et aide à sceller les nouveaux blocs sur le réseau Polkadot. Le rôle du validator dépend d’une liaison suﬃsamment élevée en cours de dépôt, bien que nous autorisons d'autres parties cautionnées à nommer un ou plusieurs validator pour agir en leur nom et en tant que une telle partie de l'obligation de validator n'appartient pas nécessairement à validator lui-même, mais plutôt à ceux-ci. proposants. Un validator doit exécuter une implémentation client de chaîne de relais avec une disponibilité et une bande passante élevées. A chaque bloc le nœud doit être prêt à accepter le rôle de ratification un nouveau bloc sur une parachain nommée. Ce processus consiste à recevoir, valider et republier les candidats blocs. La nomination est déterministe mais pratiquement imprévisible longtemps à l’avance. Puisque le validator ne peut pas on peut raisonnablement s'attendre à ce qu'il maintienne un système entièrement synchronisé base de données de toutes les parachaines, il est prévu que le validator désignera la tâche de concevoir une nouvelle suggestion bloc parachain à un tiers, connu sous le nom d’assembleur. Une fois que tous les nouveaux blocs de parachain ont été correctement ratiﬁés par leurs sous-groupes validator désignés, validators devra alors ratifier lui-même le bloc de la chaîne relais. Cela implique mettre à jour l'état des files d'attente de transactions (essentiellement déplacer les données de la file d'attente de sortie d'une parachain vers une autre file d'attente d'entrée de parachain), traitant les transactions de l’ensemble des transactions en chaîne relais ratifié et ratifiant le bloc final, y compris les changements finaux de parachain.POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 5 A validator ne remplissant pas son devoir de trouver un consensus selon les règles de l’algorithme de consensus choisi, est puni. Pour les pannes initiales involontaires, cela passe par retenir la récompense du validator. Les échecs répétés entraînent la réduction de leur caution (par brûlage). Actions manifestement malveillantes telles que la double signature ou conspirer pour fournir un bloc invalide entraîne la perte de la totalité du lien (qui est partiellement brûlé mais en grande partie donné à l'informateur et aux acteurs honnêtes). Dans un certain sens, les validator sont similaires aux pools miniers du PoW actuel blockchains. 4.2. Les proposants. Un proposant est une partie prenante qui contribue au cautionnement d'un validator. Ils n'ont aucun rôle supplémentaire, sauf celui de placer du capital-risque et, tels pour signaler qu'ils font confiance à un validator particulier (ou ensemble de ceux-ci) à agir de manière responsable dans leur entretien du réseau. Ils bénéficient d'une majoration ou d'une réduction au prorata dans leur dépôt en fonction de la croissance de l’obligation à laquelle ils contribuent. Avec les assembleurs, les proposants sont ensuite dans certains sens similaire aux mineurs des réseaux PoW actuels. 4.3. Collateurs. Assembleurs de transactions (assembleurs en abrégé) sont des parties qui aident les validator à produire des blocs de parachaine. Ils maintiennent un « nœud complet » pour une parachain particulière ; ce qui signifie qu'ils conservent tous les éléments nécessaires informations pour pouvoir créer de nouveaux blocs et exécuter transactions de la même manière que les mineurs le font sur les PoW actuels blockchain. Dans des circonstances normales, ils rassemblera et exécutera des transactions pour créer un compte non scellé bloquer et le fournir, avec une connaissance nulle preuve, à un ou plusieurs validator actuellement responsables de proposant un bloc parachain. La nature précise de la relation entre les assembleurs, les proposants et les validator changera probablement au fil du temps. le temps. Dans un premier temps, nous attendons des assembleurs qu'ils travaillent en étroite collaboration avec validators, puisqu'il n'y en aura que quelques-uns (peut-être une seule) parachain(s) avec un faible volume de transactions. Le la mise en œuvre initiale du client inclura des RPC pour permettre un nœud de collecte de parachain pour fournir inconditionnellement un nœud (relaychain) validator avec une parachain dont la validité est prouvée bloquer. Comme le coût de maintenance d'une version synchronisée de toutes ces parachaines augmentent, nous nous attendons à voir des infrastructure en place qui aidera à séparer les obligations envers des partis indépendants et motivés par l’économie. À terme, nous nous attendons à voir des pools d'assembleurs rivaliser pour perçoivent le plus de frais de transaction. Ces assembleurs peuvent être engagés par contrat pour servir des validator particuliers pendant un certain temps en échange d'une part continue du produit de la récompense. Alternativement, les assembleurs « indépendants » peuvent simplement créer un marché offrant des blocs de parachain valides en échange d'une part compétitive de la récompense payable immédiatement. De même, les pools de proposants décentralisés permettraient à plusieurs participants liés pour coordonner et partager le devoir d’un validator. Cette capacité de mutualisation garantit une participation ouverte conduisant à un système plus décentralisé. 4.4. Pêcheurs. Contrairement aux deux autres partis actifs, les pêcheurs ne sont pas directement liés à la création des blocs processus. Ce sont plutôt des « chasseurs de primes » indépendants. motivé par une grande récompense unique. Justement à cause de En raison de l'existence des pêcheurs, nous nous attendons à ce que les cas de mauvaise conduite se produisent rarement, et lorsqu'ils se produisent uniquement à cause de la partie cautionnée étant négligente avec la sécurité de la clé secrète, plutôt que par intention malveillante. Le nom vient de la fréquence attendue de la récompense, des exigences minimales pour participer et du montant éventuel de la récompense. Les pêcheurs reçoivent leur récompense en fournissant en temps opportun la preuve que au moins une partie cautionnée a agi illégalement. Actions illégales inclure la signature de deux blocs chacun avec le même parent ratiﬁé ou, dans le cas des parachains, aider à ratifier un invalide bloquer. Pour éviter la récompense excessive ou le compromis et utilisation illicite de la clé secrète d’une session, la récompense de base pour fournir un seul message signé illégalement de validator est minime. Cette récompense augmente asymptotiquement à mesure que des signatures illégales corroborantes d'autres validator sont à condition d'impliquer une véritable attaque. L'asymptote est définie à 66 % suite à notre affirmation de sécurité de base selon laquelle au moins les deux tiers des validator agissent avec bienveillance. Les pêcheurs ressemblent quelque peu aux « nœuds complets » dans systèmes blockchain actuels dont les ressources nécessaires sont relativement petits et l'engagement d'une disponibilité stable et la bande passante n'est pas nécessaire. Les pêcheurs diffèrent tellement d'autant qu'ils doivent déposer une petite caution.Ce lien empêche Sybil attaque en faisant perdre du temps et du calcul à validators ressources. Il est immédiatement retirable, probablement non plus que l'équivalent de quelques dollars et peut conduire à récolter une lourde récompense en repérant un mauvais comportement 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.

Aperçu de la conception

Cette section a pour but de donner un bref aperçu de système dans son ensemble. Une exploration plus approfondie du Le système est donné dans la section qui le suit. 5.1. Consensus. Sur la chaîne-relais, Polkadot réalise consensus de bas niveau sur un ensemble de critères valables mutuellement convenus bloque grâce à un algorithme byzantin asynchrone moderne de tolérance aux pannes (BFT). L'algorithme s'inspirera par le simple Tendermint [11] et le nettement plus impliqué HoneyBadgerBFT [14]. Ce dernier fournit un consensus eﬃcace et tolérant aux pannes sur un infrastructure de réseau défectueuse, étant donné un ensemble d’autorités pour la plupart inoffensives ou validators. Pour un réseau de type preuve d'autorité (PoA), cela seul serait suﬃsant, mais Polkadot est supposé être également déployable en réseau dans un environnement entièrement ouvert et public situation sans organisation particulière ni confiance autorité nécessaire à son entretien. En tant que tel, nous avons besoin d'un moyens de déterminer un ensemble de validator et d'inciter eux pour être honnête. Pour cela, nous utilisons une sélection basée sur PoS critères. 5.2. Prouver l'enjeu. Nous supposons que le réseau aura des moyens de mesurer le montant de la « mise » n'importe quel compte particulier a. Pour faciliter la comparaison avec systèmes préexistants, nous appellerons l'unité de mesure « tokens ». Malheureusement, le terme est loin d'être idéal pour un un certain nombre de raisons, notamment le fait qu'il s'agit simplement d'un scalaire valeur associée à un compte, il n'y a aucune notion de individualité. Nous imaginons que les validator soient élus, rarement (au plus une fois par jour mais peut-être aussi rarement qu'une fois par trimestre), via un système de preuve de participation nommée (NPoS). L'incitation peut se faire par le biais d'une allocation au prorata dePOLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 6 Relais chaîne Essaim de validateurs (chacun coloré par son parachaîne désignée) Transaction (soumis par acteur externe) Parachaine pont Parachaine virtuelle (par exemple Ethereum) Parachaine Parachaine files d'attente et E/S Transactions propagées Bloquer la soumission des candidats 2ème commande Chaîne relais Communauté Parachain Compte Transaction entrante Transaction sortante Transactions inter-chaînes (géré par validators) Assembleur Bloc propagé Pêcheur Figure 2. Un schéma récapitulatif du système Polkadot. Cela montre les assembleurs collectant et propageant les transactions des utilisateurs, ainsi que la propagation des candidats au bloc aux pêcheurs et aux validator. C'est aussi montre comment un compte peut poster une transaction qui est effectuée depuis sa parachain, via la chaine-relais et ensuite dans une autre parachain où cela peut être interprété comme une transaction sur un compte là-bas. fonds provenant d'une expansion de base token (jusqu'à 100 % par an, mais plus probablement autour de 10 %), ainsi que tous les frais de transaction perçus. Alors que l’expansion de la base monétaire conduit généralement à l’inflation, puisque tous les propriétaires de token aurait une chance équitable de participer, aucun titulaire de token n'aurait besoin de subir une réduction de la valeur de son avoirs au fil du temps, à condition qu'ils soient heureux de prendre un rôle dans le mécanisme de consensus. Une proportion particulière des token seraient ciblés pour le processus staking ; le l’expansion effective de la base token serait ajustée grâce à un mécanisme basé sur le marché pour atteindre cet objectif. Les validateurs sont fortement liés par leurs enjeux ; sortir Les obligations des validator restent en place longtemps après la fin des fonctions des validator (peut-être environ 3 mois). Ce long la période de liquidation des obligations permet à une mauvaise conduite future d'être sanctionné jusqu'au contrôle périodique de la chaîne. Une mauvaise conduite entraîne des sanctions, telles qu'une réduction de récompense ou, dans les cas qui compromettent intentionnellement la l'intégrité du réseau, le validator perdant tout ou partie de son l'enjeu à d'autres validators, informateurs ou parties prenantes dans son ensemble (par brûlage). Par exemple, un validator qui tente de ratifier les deux branches d'une fourchette (parfois connue sous le nom d’attaque « à courte portée ») peut être identifiée et puni de cette dernière manière. Les attaques à longue portée « sans enjeu »4 sont contournées grâce à un simple « point de contrôle » qui empêche une dangereuse réorganisation en chaîne de plus d’un profondeur de chaîne particulière. Pour garantir la synchronisation des clients ne peuvent pas se laisser tromper par la mauvaise chaîne, régulier des « hard forks » se produiront (au plus pendant la même période du liquidation des obligations de validators) qui code en dur le bloc de point de contrôle récent hashes dans les clients. Cela s’accorde bien avec une mesure supplémentaire de réduction de l’empreinte de « longueur de chaîne finie » ou réinitialisation périodique du bloc de genèse. 5.3. Parachains et assembleurs. Chaque parachain obtient des conditions de sécurité similaires à celles de la chaîne relais : le les en-têtes des parachains sont scellés dans le bloc de chaîne de relais s’assurer qu’aucune réorganisation, ou « double dépense », n’est possible après confirmation. Il s’agit d’une garantie de sécurité similaire à celle offerte par les side-chains et la fusion de Bitcoin. Polkadot, cependant, fournit également de fortes garanties que les transitions d'état des parachains sont valides. Ceci cela se produit lorsque l'ensemble des validator est segmenté de manière cryptographique aléatoire en sous-ensembles ; un sous-ensemble par parachain, les sous-ensembles potentiellement différents par bloc. Ceci la configuration implique généralement que les temps de blocage des parachains seront être au moins aussi longue que celle de la chaîne-relais. Le spécifique les moyens permettant de déterminer le partage ne relèvent pas du champ d'application 4Une telle attaque est le moment où l’adversaire forge une chaîne historique entièrement nouvelle à partir du bloc de genèse. En contrôlant un part de participation relativement insignifiante au départ, ils sont capables d'augmenter progressivement leur part de participation par rapport à tous les autres parties prenantes car ils sont les seuls participants actifs à leur histoire alternative. Puisqu'il n'existe aucune limitation physique intrinsèque à la création de blocs (contrairement à PoW où une énergie de calcul assez réelle doit être dépensée), ils sont capables de créer une chaîne plus longue que la chaîne réelle dans un une période de temps relativement courte et en fera potentiellement la plus longue et la meilleure, reprenant l'état canonique du réseau.POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 7 de ce document mais serait probablement basé soit sur un cadre de validation-révélation similaire au RanDAO [19] ou utiliser les données combinées des blocs précédents de chaque parachain sous un hash cryptographiquement sécurisé. De tels sous-ensembles de validator sont nécessaires pour fournir un candidat de bloc parachain qui est garanti valide (sur peine de confiscation de la caution). La validité s'articule autour de deux points importants; d’abord qu’il est intrinsèquement valable – que toutes les transitions d'état ont été exécutées fidèlement et que tout les données externes référencées (c'est-à-dire les transactions) sont valables pour l'inclusion. Deuxièmement, que toute donnée extrinsèque à son Le candidat, comme ces transactions externes, a une disponibilité suffisamment élevée pour que les participants puissent téléchargez-le et exécutez le bloc manuellement.5 Les validateurs peuvent fournir uniquement un bloc « nul » ne contenant aucune donnée de « transactions » externe, mais peuvent courir le risque d'obtenir une récompense réduite s'ils le font. Ils travaillent aux côtés un protocole de potins en parachain avec des assembleurs – des particuliers qui rassemblent les transactions en blocs et fournissent une preuve non interactive et sans connaissance que le bloc constitue un enfant valide de son parent (et prend toute transaction frais pour leurs ennuis). Il appartient aux protocoles de parachain de spécifier les leurs moyens de prévention du spam : il n'existe pas de notion fondamentale de « mesure des ressources de calcul » ou de « frais de transaction » imposée par la chaîne-relais. Il n'y a pas non plus d'application directe à ce sujet par le protocole de chaîne de relais (bien qu'il Il est peu probable que les parties prenantes choisissent d'adopter une parachain qui ne fournissait pas un mécanisme décent). Il s’agit d’un clin d’œil explicite à la possibilité de chaînes contrairement à Ethereum, par ex. une chaîne de type Bitcoin qui a un modèle de frais beaucoup plus simple ou un autre modèle de prévention du spam, qui n'a pas encore été proposé. La chaîne de relais de Polkadot elle-même existera probablement en tant que Comptes et chaîne d'état de type Ethereum, éventuellement un dérivé EVM. Puisque les nœuds de la chaîne relais devront effectuer d'autres traitements substantiels, débit de transaction sera minimisé en partie grâce à des frais de transaction importants et, si nos modèles de recherche l'exigent, une limite de taille de bloc. 5.4. Communication inter-chaînes. Le dernier ingrédient essentiel de Polkadot est la communication inter-chaînes. Depuis les parachains peuvent avoir une sorte de canal d'information entre elles, nous nous permettons de considérer Polkadot un multi-chaîne évolutive. Dans le cas de Polkadot, la communication est aussi simple que possible : des transactions s'exécutant dans un les parachain sont (selon la logique de cette chaîne) capables de effectuer l'envoi d'une transaction dans une deuxième parachain ou, potentiellement, la chaîne relais. Comme les transactions externes sur les blockchain de production, ils sont entièrement asynchrones et il n'y a aucune capacité intrinsèque pour eux de rendre quoi que ce soit type d'information jusqu'à son origine. Destination : obtient données antérieures les validators du bloc. Le compte reçoit la publication : entrée supprimée de entrée Merkle tree Le compte envoie le message : entrée placée dans sortie Merkle tree pour destination parachaine sortie Source : partages données avec le bloc suivant validators preuve de courrier stockée dans sortie de parachain Merkle arbre référence routé placée dans les parachaines de destination entrée Merkle tree entrée Figure 3. Un schéma de base montrant les principales parties du routage pour posté transactions (« posts »). Pour garantir une complexité de mise en œuvre minimale, un minimum risque et minime camisole de force de avenir architectures parachain, ces transactions interchaînes sont en fait impossible à distinguer des transactions standard signées en externe. La transaction a un segment d'origine, offrant la possibilité d'identifier une parachain, et une adresse qui peut être de taille arbitraire. Contrairement aux systèmes actuels courants tels que Bitcoin et Ethereum, les transactions inter-chaînes ne s'accompagnent d'aucun type de « paiement » de frais associés ; tout paiement de ce type doit être géré via une logique de négociation sur les parachains source et de destination. Un système tel que celui proposé pour La version Serenity de Ethereum [7] serait un moyen simple de gérer un tel paiement de ressources inter-chaînes, bien que nous supposons que d’autres pourraient apparaître en temps voulu. Les transactions interchaînes sont résolues à l'aide d'un simple mécanisme de file d'attente basé sur un Merkle tree pour garantir fidélité. C'est la tâche des mainteneurs de la chaîne de relais de déplacer les transactions sur la file d'attente de sortie d'une parachain dans la file d’attente d’entrée de la parachain de destination. Le les transactions passées sont référencées sur la chaîne de relais, mais ne sont pas pertinentestransactions en chaîne elles-mêmes. Pour empêcher une parachain de spammer une autre parachain avec transactions, pour qu'une transaction soit envoyée, il est nécessaire que la file d'attente d'entrée de la destination ne soit pas trop grande à l'heure de fin du bloc précédent. Si l'entrée est trop grande après le traitement des blocs, elle est alors considérée comme « saturée » et aucune transaction ne peut être acheminée vers dans les blocs suivants jusqu'à ce qu'il soit réduit en dessous du limite. Ces files d'attente sont administrées sur la chaîne-relais permettre aux parachains de déterminer la saturation de chacun statut ; de cette façon, une tentative infructueuse de publier une transaction vers une destination bloquée peut être signalé de manière synchrone. (Mais comme aucun chemin de retour n'existe, si une transaction secondaire échouait pour cette raison, elle ne pourrait pas être signalée. à l'appelant d'origine et à d'autres moyens de récupération devrait avoir lieu.) 5.5. Polkadot et Ethereum. En raison de l'exhaustivité de Turing de Ethereum, nous pensons qu'il existe de nombreuses possibilités pour Polkadot et Ethereum d'être interopérables avec les uns les autres, du moins dans certaines limites de sécurité facilement déductibles. En bref, nous envisageons que les transactions de Polkadot peut être signé par validators puis introduit dans 5Une telle tâche pourrait être partagée entre les validator ou pourrait devenir la tâche désignée d'un ensemble de validator fortement liés, connu sous le nom de garants de disponibilité.

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 8 Ethereum où ils peuvent être interprétés et mis en œuvre par un contrat de transmission de transactions. Dans l'autre sens, nous prévoyons l'utilisation de journaux (événements) spécialement formatés provenant d’un « contrat de rupture » pour permettre une vérification rapide qu’un message particulier doit être transmis. 5.5.1. Polkadot à Ethereum. Grâce au choix d'un BFT mécanisme de consensus avec validators formés à partir d'un ensemble de parties prenantes déterminées par un vote d'approbation mécanisme, nous sommes en mesure d’obtenir un consensus sûr avec un changement peu fréquent et nombre modeste de validator. Dans un système avec un total de 144 validators, un temps de bloc de 4 secondes et une finalité de 900 blocs (permettant des attaques malveillantes) les comportements tels que les doubles votes doivent être signalés et punis et réparé), la validité d'un blocage peut raisonnablement être est considérée comme prouvée par seulement 97 signatures (les deux tiers de 144 plus une) et une période de vérification ultérieure de 60 minutes au cours de laquelle aucune contestation n'est déposée. Ethereum est en mesure d'héberger un « contrat de rodage » qui peut maintenir les 144 signataires et être contrôlé par eux. Étant donné que la récupération de la signature numérique à courbe elliptique (ECDSA) ne nécessite que 3 000 gaz sous le EVM, et depuis nous voudrions probablement que la validation n'ait lieu que sur un majorité qualifiée de validator (plutôt que l'unanimité totale), le coût de base de Ethereum confirmant qu'une instruction a été correctement validé car provenant du réseau Polkadot ne représenterait pas plus de 300 000 gaz, soit seulement 6 % du la limite totale de gaz du bloc à 5,5 M. Augmenter le nombre de validator (ce qui serait nécessaire pour faire face aux des dizaines de chaînes) augmente inévitablement ce coût, mais on s'attend généralement à ce que la bande passante de transaction de Ethereum augmente au fil du temps à mesure que la technologie évolue et les infrastructures s’améliorent. Avec le fait que non tous les validator doivent être impliqués (par exemple, seul le niveau le plus élevé les validator jalonnés peuvent être sollicités pour une telle tâche), le les limites de ce mécanisme s’étendent raisonnablement bien. En supposant une rotation quotidienne de ces validator (ce qui est assez conservateur (une fréquence hebdomadaire ou même mensuelle peut être acceptable), alors le coût pour le réseau de maintenance ce pont de transfert Ethereum serait d'environ 540 000 gaz par jour ou, aux prix actuels du gaz, 45 $ par an. Une transaction de base transmise seule via le pont coûterait environ 0,11 $ ; le calcul supplémentaire du contrat coûterait plus, bien sûr. En tamponnant et en regroupant les transactions ensemble, les coûts d'autorisation d'effraction peuvent facilement être partagé, réduisant considérablement le coût par transaction ; si 20 transactions étaient nécessaires avant la transmission, alors le coût de transmission d'une transaction de base tomberait à environ 0,01 $. Une alternative intéressante et moins coûteuse à ce modèle de contrat multisignature serait d’utiliser des signatures à seuil afin d’obtenir la sémantique de propriété multilatérale. Alors que les schémas de signature à seuil pour l'ECDSA sont coûteux en calcul, ceux des autres schémas comme les signatures Schnorr sont très raisonnables. Ethereum envisage d'introduire des primitives qui rendraient un tel des schémas bon marché à utiliser dans le prochain hardfork de Metropolis. Si un tel moyen pouvait être utilisé, les coûts du gaz pour transférer une transaction Polkadot vers le Ethereum le réseau serait considérablement réduit à un niveau proche de zéro frais généraux qui s'ajoutent aux coûts de base liés à la validation du signature et exécution de la transaction sous-jacente. Dans ce modèle, les nœuds validator de Polkadot auraient faire peu d'autre que signer des messages. Pour que les transactions soient réellement acheminées sur le réseau Ethereum, nous supposons que les validator eux-mêmes résideraient également sur le réseau Ethereum ou, plus probablement, que de petites primes être proposé au premier acteur qui transmet le message sur au réseau (la prime pourrait trivialement être versée au initiateur de la transaction). 5.5.2. Ethereum à Polkadot. Faire en sorte que les transactions soient transmis de Ethereum à Polkadot utilise la simple notion de logs. Lorsqu'un contrat Ethereum souhaite envoyer une transaction vers une parachain particulière de Polkadot, il suffit de faire appel à un « contrat de rupture » spécial. Le contrat de rupture accepterait tout paiement qui pourrait être requis et émettre une instruction de journalisation afin que son existence puisse être prouvée par une preuve Merkle et une affirmation que l'en-tête du bloc correspondant est valide et canonique. Parmi ces deux dernières conditions, la validité est peut-être la le plus simple à prouver. En principe, la seule exigence estpour chaque nœud Polkadot nécessitant la preuve (c'est-à-dire des nœuds validator désignés) pour exécuter une instance entièrement synchronisée d'un nœud Ethereum standard. Malheureusement, il s’agit en soi d’une dépendance assez lourde. Un plus méthode légère consisterait à utiliser une preuve simple que le l'en-tête a été évalué correctement en fournissant uniquement le une partie du test d'état de Ethereum nécessaire pour s'exécuter correctement les transactions du bloc et vérifier que les logs (contenus dans le reçu de bloc) sont valides. Un tel « SPV-like »6 les preuves peuvent pourtant nécessiter une quantité substantielle d'informations ; commodément, ils ne seraient généralement pas nécessaires à tous : un système de liaison à l'intérieur de Polkadot permettrait les tiers à soumettre des en-têtes au risque de perdre leur caution si un autre tiers (tel qu’un « pêcheur », voir 6.2.3) fournit la preuve que l’en-tête n’est pas valide (en particulier que la racine de l'État ou la racine du reçu étaient des imposteurs). Sur un réseau PoW non finalisant comme Ethereum, le la canonicité est impossible à prouver de manière concluante. Pour résoudre ce problème, les applications qui tentent de s'appuyer sur n'importe quel type de cause à effet dépendant d’une chaîne, attendez un certain nombre de « confirmations » ou jusqu’à ce que la transaction dépendante soit à un certain point. profondeur particulière au sein de la chaîne. Le Ethereum, ceci la profondeur varie de 1 bloc pour les transactions les moins précieuses sans problème de réseau connu à 1 200 blocs comme c'était le cas ce fut le cas lors de la première version de Frontier pour les échanges. Sur le réseau stable « Homestead », ce chiffre se situe à 120 blocs pour la plupart des échanges, et nous prendrions probablement un paramètre similaire. Alors nous peut imaginer notre Côté Polkadot Ethereuminterface pour avoir quelques fonctions simples : pouvoir acceptez un nouvel en-tête du réseau Ethereum et validez le PoW, pour pouvoir accepter une preuve qu'un un journal particulier a été émis par le contrat de rupture côté Ethereum pour un en-tête de profondeur suﬃsante (et vers l'avant le message correspondant dans Polkadot) et enfin être capable d'accepter des preuves qu'un document précédemment accepté mais l'en-tête non encore adopté contient une racine de reçu non valide. Pour obtenir réellement les données d'en-tête Ethereum elles-mêmes (et toutes preuves SPV ou réfutations de validité/canonicité) dans le réseau Polkadot, une incitation à la réexpédition 6SPV fait référence à la vérification simplifiée des paiements dans Bitcoin et décrit une méthode permettant aux clients de vérifier les transactions tout en ne conservant que une copie de tous les en-têtes de blocs de la plus longue chaîne PoW.POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 9 des données sont nécessaires. Cela pourrait être aussi simple qu'un paiement (financé par les frais perçus du côté Ethereum) payé à toute personne capable de transmettre un bloc utile dont l'en-tête est valide. Les validateurs seraient appelés à conserver les informations relatives aux derniers milliers de blocs afin de être capable de gérer les forks, soit par des moyens protocolaires intrinsèques, soit par le biais d'un contrat maintenu sur le chaîne de relais. 5.6. Polkadot et Bitcoin. Bitcoin interopération présente un défi intéressant pour Polkadot : un soi-disant un « ancrage bidirectionnel » serait une infrastructure utile avoir du côté des deux réseaux. Cependant, en raison de les limites de Bitcoin, à condition qu'une telle cheville soit solidement une entreprise non triviale. Réaliser une transaction depuis Bitcoin à Polkadot peut en principe être réalisé avec un processus similaire à celui de Ethereum ; une « adresse en petits groupes » contrôlé d'une manière ou d'une autre par les Polkadot validator pourraient recevoir les token transférés (et les données envoyées avec eux). Les preuves SPV pourraient être fournies par des oracle incités et, accompagné d'une période de conﬁrmation, une prime accordée pour identifier les blocs non canoniques impliquant la transaction a été « dépensé deux fois ». Tous les token alors possédés dans le « l'adresse de rupture » serait alors, en principe, contrôlée par ces mêmes validator pour une dispersion ultérieure. Le problème est cependant de savoir comment les dépôts peuvent être contrôlés en toute sécurité à partir d'un ensemble validator rotatif. Contrairement à Ethereum qui est capable de prendre des décisions arbitraires basées sur sur des combinaisons de signatures, Bitcoin est substantiellement plus limité, la plupart des clients n'acceptant que les transactions multisignatures avec un maximum de 3 parties. Étendre ce chiffre à 36, voire à des milliers comme on pourrait le souhaiter en fin de compte, est impossible dans le cadre du protocole actuel. Une option consiste à modifier le protocole Bitcoin pour activer une telle fonctionnalité, mais ce qu'on appelle des « hard forks » dans le Le monde Bitcoin est difficile à organiser à en juger par les tentatives récentes. Une possibilité est l'utilisation de signatures à seuil, schémas cryptographiques pour permettre à un public identifiable une seule fois clé pour être contrôlée eﬀicacement par plusieurs « parties » secrètes dont tout ou partie doit être utilisé pour créer une signature valide. Malheureusement, les signatures de seuil sont compatibles avec l'ECDSA de Bitcoin sont coûteux en calcul créer et de complexité polynomiale. D'autres schémas tels a Les signatures Schnorr offrent des coûts bien inférieurs, mais le calendrier sur lequel ils peuvent être introduits dans le Bitcoin le protocole est incertain. Puisque la sécurité ultime des dépôts repose sur un certain nombre de validator liés, une autre option consiste à réduire les détenteurs de clés multi-signatures à seulement un nombre important sous-ensemble lié du total de validators tel que ce seuil les signatures deviennent réalisables (ou, au pire, les signatures natives de Bitcoin la multi-signature est possible). Cela réduit bien sûr le montant total des obligations qui pourraient être déduites à titre de réparations si les validator se comportaient illégalement, mais cela est une dégradation gracieuse, fixant simplement une limite supérieure de le montant des fonds qui peuvent circuler en toute sécurité entre le deux réseaux (ou encore, sur le % de pertes en cas d'attaque des validator réussissent). En tant que tel, nous pensons qu’il n’est pas irréaliste de placer une « parachain virtuelle » d’interopérabilité Bitcoin raisonnablement sécurisée. entre les deux réseaux, mais néanmoins un eﬀort conséquent avec un calendrier incertain et très probablement exigeant la coopération des parties prenantes au sein de ce réseau.

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.

Protocole en détail

Le protocole peut être grossièrement décomposé en trois parties : le mécanisme de consensus, l'interface parachain et le routage des transactions inter-chaînes. 6.1. Chaîne relais Opération. Le chaîne-relais va il s'agit probablement d'une chaîne globalement similaire à Ethereum dans la mesure où elle est basé sur l'état avec l'adresse de mappage d'état au compte informations, principalement les soldes et (pour éviter les rediffusions) un compteur de transactions. Placer les comptes ici répond à un seul objectif : rendre compte de ce que possède l’identité. quel montant de participation dans le système.7 Il y aura cependant des diﬀérences notables : • Les contrats ne peuvent pas être déployés via des transactions ; suite à la volonté d’éviter les fonctionnalités applicatives sur la chaîne relais, il ne sera pas accompagner le déploiement public des contrats. • L'utilisation des ressources de calcul (« gaz ») n'est pas comptabilisée ; puisque les seules fonctions disponibles pour un usage public sera corrigée, la justification de la comptabilisation du gaz ne tient plus. A ce titre, un tarif forfaitaire s'appliquera en tous les cas, permettant plus de performances dans tous les cas exécution de code dynamique qui peut être nécessaire et un format de transaction plus simple. • Une fonctionnalité spéciale est prise en charge pour les contrats répertoriés qui permet l'exécution automatique et la sortie de messages réseau. Dans le cas où la chaîne de relais possède une VM et que ce soit basé sur le EVM, il comporterait un certain nombre de modifications pour assurer une simplicité maximale. Ce serait probablement avoir un certain nombre de contrats intégrés (similaires à ceux de adresses 1 à 4 dans Ethereum) pour permettre des tâches à gérer, y compris un contrat consensuel, un Contrat validator et un contrat parachain. Si ce n’est pas le EVM, alors un backend WebAssembly [2] (wasm) est l’alternative la plus probable ; dans ce cas, l'ensemble la structure serait similaire, mais il ne serait pas nécessaire pour que les contrats intégrés avec Wasm soient une cible viable pour les langages à usage général plutôt que pour les langages immatures et langues limitées pour le EVM. D'autres écarts probables par rapport au protocole actuel Ethereum sont tout à fait possibles, par exemple une simplification du format de reçu de transaction permettant l'exécution parallèle de transactions non conflictuelles au sein d'un même bloc, comme proposé pour la série de changements Serenity. Il est possible, bien que peu probable, qu'un chaîne « pure » soit déployée comme chaîne-relais, permettant une contrat particulier pour gérer des choses comme le staking token équilibres plutôt que d’en faire un élément fondamental de le protocole de la chaîne. À l'heure actuelle, nous estimons qu'il est peu probable que cela oﬀrera une simplification protocolaire suﬃsamment grande pour être cela vaut la complexité et l'incertitude supplémentaires impliquées en le développant. 7Afin de représenter le montant qu'un détenteur donné est responsable de la sécurité globale du système, ces comptes de participation seront codent inévitablement une certaine valeur économique. Toutefois, il convient de comprendre que, puisqu'il n'est pas prévu que de telles valeurs soient utilisées dans de quelque manière que ce soit dans le but d'échanger contre des biens et services du monde réel, il convient par conséquent de noter que les token ne doivent pas être assimilés à monnaie et à ce titre la chaîne-relais conserve sa philosophie nihiliste en matière d'applications.POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 10 Il existe un certain nombre de petites fonctionnalités requises pour administrer le mécanisme de consensus, l'ensemble validator, le mécanisme de validation et les parachains. Ces pourraient être mis en œuvre ensemble dans le cadre d’un protocole monolithique. Cependant, pour des raisons de modularité augure, nous les qualifions de « contrats » de la chaîne-relais. Cela devrait être interprété comme signifiant qu'ils sont des objets (au sens de programmation orientée objet) gérée par le mécanisme de consensus de la relaychain, mais pas nécessairement cela ils sont définis comme des programmes dans des opcodes de type EVM, ni même qu'ils soient adressables individuellement via le système de compte. 6.2. Contrat de jalonnement. Ce contrat maintient l'ensemble validator. Il gère : • quels comptes sont actuellement des validator ; • qui sont disponibles pour devenir validators en bref avis ; • quels comptes ont placé une participation en nominant à un validator ; • les propriétés de chacun, y compris le volume staking, les taux de paiement et adresses acceptables et les identités (session) à court terme. Il permet à un compte d'enregistrer une envie de devenir les validator liés (avec ses exigences), pour désigner une certaine identité, et pour les validator liés préexistants, d'enregistrer leur désir de quitter ce statut. C'est aussi comprend le mécanisme lui-même pour le mécanisme de validation et de canonisation. 6.2.1. Mise-token Liquidité. Il est généralement souhaitable de avoir autant que possible du total de staking token jalonné dans les opérations de maintenance du réseau depuis cela lie directement la sécurité du réseau à la « capitalisation boursière » globale du staking token. Cela peut facilement être encouragé en gonflant la monnaie et en distribuant les bénéfices à ceux qui participent en tant que validators. Cependant, cela pose un problème : si le token est bloqué dans le Contrat de Staking sous peine de réduction, comment une partie substantielle peut-elle rester suﬃsamment liquide afin de permettre la découverte des prix ? Une réponse à cela consiste à autoriser un contrat dérivé simple, garantissant des token fongibles sur un token sous-jacent jalonné. C’est diﬃcile à organiser sans confiance. De plus, ces dérivés token ne peuvent pas être traités de la même manière pour la même raison que les différentes obligations d’État de la zone euro ne sont pas fongibles : il est une chance que l'actif sous-jacent échoue et devienne sans valeur. Avec les gouvernements de la zone euro, il pourrait y avoir un par défaut. Avec validator jalonnés de token, les validator peuvent agir de manière malveillante et être puni. Conformément à nos principes, nous optons pour la solution la plus simple : tous les token ne sont pas jalonnés. Cela voudrait dire que une certaine proportion (peut-être 20 %) des token resteront forcément liquides. Bien que cela soit imparfait du point de vue de la sécurité, il est peu probable que cela fasse une différence fondamentale en termes de sécurité. la sécurité du réseau ; 80 % des réparations possibles grâce aux confiscations de cautions pourraient encore être effectuées par rapport au « cas parfait » de 100 % staking. Le rapport entre les token mis en jeu et les token liquides peut être ciblé assez simplement grâce à un mécanisme d'enchères inversées. Essentiellement, les titulaires de token intéressés à devenir validator chacun publierait une oﬀre pour le contrat staking indiquant le taux de paiement minimum dont ils auraient besoin pour prendre partie. Au début de chaque séance (les séances seraient se produisent régulièrement, peut-être aussi souvent qu'une fois par heure), le validator créneaux seraient pourvus en fonction de chaque candidat La mise et le taux de paiement de validator. Un algorithme possible car ce serait prendre ceux qui ont les offres les plus basses et qui représenter une mise ne dépassant pas la mise totale visée divisé par le nombre d'emplacements et ne doit pas être inférieur à une limite inférieure égale à la moitié de ce montant. Si les créneaux ne peuvent pas être pourvus, la limite inférieure pourrait être réduite à plusieurs reprises d'un certain facteur afin de satisfaire. 6.2.2. Nomination. Il est possible de nommer en toute confiance ceux staking tokens à un validator actif, leur donnant la responsabilité des fonctions de validator. Œuvres en nomination grâce à un système de vote d’approbation. Chaque proposant potentiel peut publier une instruction sur le contrat staking exprimant une ou plusieurs identités validator sous lesquelles responsabilité qu'ils sont prêts à confier à leur caution. À chaque séance, les liens des proposants sont dispersés pour être représenté par un ou plusieurs validator. L'algorithme de dispersion optimise pour un ensemble de validators de total équivalent obligations. Les cautions des proposants deviennent sous la responsabilité effective du validator aet susciter de l'intérêt ou subir un réduction de la peine en conséquence. 6.2.3. Confiscation/incendie des obligations. Certains comportements validator entraînent une réduction punitive de leur caution. Si la caution est réduite en dessous du minimum autorisé, le une session est terminée prématurément et une autre démarre. Une liste non exhaustive de comportements répréhensibles validator punissables comprend : • Faire partie d'un groupe parachain incapable de fournir consensus sur la validité d’un bloc parachain ; • signer activement pour la validité d'un invalide bloc de parachaine ; • incapacité à fournir des charges utiles de sortie auparavant voté comme disponible ; • inactivité pendant le processus de consensus ; • valider les blocs relais-chaînes sur les fourches concurrentes. Certains cas de mauvais comportement menacent l’intégrité du réseau (comme la signature de blocs de parachain invalides et la validation de plusieurs côtés d’un fork) et entraînent ainsi un exil effectif par la réduction totale de la liaison. Dans d'autres cas moins graves (par exemple inactivité dans le consensus processus) ou dans les cas où le blâme ne peut être attribué avec précision (faire partie d'un groupe inefficace), une petite partie de la caution peut en revanche être condamné à une amende. Dans ce dernier cas, cela fonctionne bien avec le désabonnement des sous-groupes pour garantir que les messages malveillants les nœuds subissent beaucoup plus de pertes que les nœuds bienveillants endommagés collatéralement. Dans certains cas (par exemple, validation multi-fork et invalide signature de sous-bloc) validators ne peuvent pas eux-mêmes détecter facilement le mauvais comportement de chacun car une vérification constante de chaque bloc de parachain serait une tâche trop ardue. Ici il est nécessaire d'obtenir le soutien de parties extérieures à le processus de validation pour vérifier et signaler un tel comportement inapproprié. Les parties reçoivent une récompense pour avoir signalé une telle activité ; leur terme, « pêcheurs », vient de l’improbabilité d'une telle récompense. Étant donné que ces cas sont généralement très graves, nous envisageons que toute récompense puisse facilement être payée à partir de la caution confisquée. En général, nous préférons équilibrer la combustion (c'est-à-dire réduction à néant) avec réaffectation, plutôt que tenter une réallocation globale. Cela a pour eﬀet de

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 11 augmentant la valeur globale du token, compensant le réseau en général dans une certaine mesure plutôt que le réseau spécifique partie impliquée dans la découverte. C'est principalement par mesure de sécurité mécanisme : les sommes importantes impliquées pourraient conduire à des incitations comportementales extrêmes et aiguës si elles étaient toutes accordé à une seule cible. En général, il est important que la récompense soit suffisamment importante pour que la vérification soit utile pour le réseau, mais pas au point de compenser les coûts liés à la mise en place d'un système de vérification. une criminalité « de niveau industriel » bien financée et bien orchestrée attaque de piratage informatique contre un validator malchanceux pour forcer un mauvais comportement. De cette façon, le montant réclamé ne devrait généralement pas être supérieur au lien direct du validator errant, de peur qu'un une incitation perverse survient à se comporter mal et à se dénoncer pour obtenir la prime. Cela peut être combattu soit explicitement grâce à une exigence minimale de cautionnement direct pour être un validator ou implicitement en informant les proposants que les validator avec peu d'obligations déposées ne sont pas très incitées de bien se comporter. 6.3. Registre Parachain. Chaque parachain est déﬁnie dans ce registre. Il s'agit d'une construction de type base de données relativement simple qui contient à la fois des informations statiques et dynamiques sur chaque chaîne. Les informations statiques incluent l'index de chaîne (un simple entier), ainsi que l'identité du protocole de validation, un moyen de distinguer les différentes classes de parachain afin que l'algorithme de validation correct puisse être dirigé par des validator chargés de présenter un candidat valable. Une première preuve de concept se concentrerait sur la mise en place les nouveaux algorithmes de validation dans les clients eux-mêmes, nécessitant effectivement un hard fork du protocole à chaque fois qu'un une classe supplémentaire de chaîne a été ajoutée. Mais en fin de compte, il peut être possible de spécifier l'algorithme de validation dans une manière à la fois rigoureuse et suffisamment eﬃcace pour que les clients soient capable de travailler efficacement avec de nouvelles parachaines sans fourchette dure. Une piste possible pour y parvenir serait de préciser l'algorithme de validation de la parachain dans un système bien établi, langage compilé nativement et indépendant de la plate-forme, tel que WebAssembly. Des recherches supplémentaires sont nécessaires pour déterminer si cela est vraiment réalisable, mais si c'est le cas, cela pourrait apporter avec lui l'énorme avantage de bannir les hard-forks pour de bon. Les informations dynamiques incluent des aspects du système de routage des transactions qui doivent faire l'objet d'un accord global, tel que comme file d’attente d’entrée de la parachain (décrite dans la section 6.6). Le registre ne peut ajouter que des parachaines par un vote référendaire complet ; cela pourrait être géré en interne mais serait plus probablement placé dans un environnement externe contrat référendaire afin de faciliter la réutilisation dans le cadre des éléments de gouvernance plus généraux. Les paramètres à conditions de vote (par exemple, quorum requis, majorité requis) pour l'enregistrement de chaînes supplémentaires et autres, des mises à niveau moins formelles du système seront définies dans un « constitution » mais sont susceptibles de suivre un modèle assez traditionnel. chemin, du moins au début. La formulation précise est hors de portée du présent travail, mais par ex. une majorité qualifiée des deux tiers sera adoptée avec plus d'un tiers du système total Un vote positif peut être un point de départ judicieux. Les opérations supplémentaires incluent la suspension et la suppression des parachaines. Nous espérons que la suspension ne sera jamais se produire, mais il est conçu pour être une protection au moins il y a un problème insoluble dans le système de validation d’une parachain. Le cas le plus évident où cela pourrait Ce qui est nécessaire, c'est une différence critique par consensus entre les implémentations, ce qui conduit les validator à ne pas pouvoir s'entendre sur validité ou blocages. Les validateurs seraient encouragés à utiliser plusieurs implémentations client afin qu'ils puissent détecter un tel problème avant la confiscation de la caution. La suspension étant une mesure d'urgence, il serait sous les auspices de la dynamique validator-vote plutôt qu'un référendum. La réintégration serait possible à la fois des validators ou un référendum. La suppression totale des parachaines n’interviendrait que après un référendum et avec lequel serait exigé un période de grâce substantielle pour permettre une transition ordonnée vers soit une chaîne autonome, soit pour faire partie d'une autre système de consensus. Le délai de grâce serait probablement de l'ordre des mois et est susceptible d'être défini sur une base par chaîne dans le registre des parachaines afin que les diﬀérents les parachains peuvent bénéficier de diﬀérents délais de grâce selon leur besoin. 6.4. Scellement des blocs relais. Le scellement fait essentiellement référence à au processus de canonisation ; c'est-à-dire une donnée de base transformer quimappe l’original en quelque chose de fondamentalement singulier et significatif. Sous une chaîne PoW, l’étanchéité est en fait synonyme d’exploitation minière. Dans notre cas, cela implique la collecte de déclarations signées de validator sur la validité, la disponibilité et la canonique d'un bloc de chaîne de relais particulier et les blocs de parachain qui cela représente. La mécanique de l’algorithme de consensus BFT sous-jacent est hors de portée du présent travail. Nous allons décrivez-le plutôt en utilisant une primitive qui suppose un machine à états créatrice de consensus. En fin de compte, nous nous attendons s'inspirer d'un certain nombre de consensus BFT prometteurs algorithmes au cœur ; Tangaora [9] (une variante BFT de Raft [16]), Tendermint [11] et HoneyBadgerBFT [14]. L'algorithme devra parvenir à un accord sur plusieurs parachains en parallèle, différant ainsi de l'habituel blockchain mécanismes de consensus. Nous supposons qu'une fois le consensus est atteint, nous sommes en mesure d'enregistrer le consensus dans une preuve irréfutable qui peut être fournie par n'importe lequel des les participants à celui-ci. Nous supposons également qu'un mauvais comportement au sein du protocole peut être généralement réduit à un petit groupe contenant des participants qui se comportent mal pour minimiser les dommages collatéraux en infligeant une punition.8 La preuve, qui prend la forme de nos déclarations signées, est placée ensemble dans l’en-tête du bloc relais-chaîne. avec certains autres champs, notamment la racine statetrie de la chaîne relais et la racine transaction-trie. Le étanchéité processus prend endroit sous un célibataire générer un consensus mécanisme adressage les deux le le bloc de la chaîne relais et les blocs des parachains qui font une partie du contenu du relais : les parachains ne sont pas « engagées » séparément par leurs sous-groupes puis rassemblées plus tard. Cela se traduit par un processus plus complexe pour la chaîne de relais, mais nous permet de parvenir à un consensus sur l'ensemble du système en une seule étape, minimisant ainsi la latence et permettant pour des exigences de disponibilité de données assez complexes qui sont utile pour le processus de routage ci-dessous. 8Les systèmes de consensus existants basés sur PoS BFT tels que Tendermint BFT et le Slasher original répondent à ces affirmations.

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 12 L’état de la machine à consensus de chaque participant peut être modélisé comme un simple tableau (2 dimensions). Chaque participant (validator) dispose d'un ensemble d'informations, sous la forme de déclarations signées (« votes ») des autres participants, concernant chaque candidat au bloc parachain ainsi que le candidat au bloc relaychain. L'ensemble des informations est composé de deux éléments de données : Disponibilité : oui ceci validator avoir sortie informations de publication de transaction de ce bloc afin sont-ils capables de valider correctement les candidats parachain sur le bloc suivant ? Ils peuvent voter soit 1 (connu) ou 0 (pas encore connu). Une fois qu'ils vote 1, ils s'engagent à voter de la même manière pour le reste de ce processus. Votes ultérieurs qui ne le font pas respectez, ce sont des motifs de punition. Validité : le bloc parachain est-il valide et c'est tout données référencées en externe (par ex. opérations) disponible ? Ceci ne concerne que les validator attribués à la parachain sur laquelle ils votent. Ils peuvent voter soit 1 (valide), -1 (invalide) ou 0 (pas encore connu). Une fois qu'ils votent non zéro, ils nous nous engageons à voter de cette façon pour le reste de le processus. Des votes ultérieurs qui ne respectent pas cela sont des motifs de punition. Tous les validator doivent soumettre des votes ; les votes peuvent être soumis à nouveau, qualifiés par les règles ci-dessus. La progression de le consensus peut être modélisé comme plusieurs algorithmes de consensus standard BFT sur chaque parachain se produisant en parallèle. Puisque ceux-ci sont potentiellement contrecarrés par un petite minorité d’acteurs malveillants concentrés dans un seul groupe de parachain, le consensus global existe pour établir un filet de sécurité, limitant le pire des cas impasse à simplement un ou plusieurs blocs de parachain vides (et une série de sanctions pour les responsables). Les règles de base pour la validité des blocs individuels (qui permettent à l'ensemble total de validator dans son ensemble d'arriver à consensus sur le fait qu'il devienne le candidat unique de la parachain à référencer depuis le relais canonique) : • doit avoir au moins les deux tiers de ses validator votant positivement et aucun votant négativement ; • doit avoir plus d'un tiers de validator votant positivement sur la disponibilité des informations sur la file d'attente de sortie. S'il y a au moins un vote positif et au moins un vote négatif sur la validité, une condition exceptionnelle est créée et l'ensemble des validator doivent voter pour déterminer s'il y a des parties malveillantes ou s'il y a un accident fourchette. Outre les votes valides et invalides, un troisième type de votes sont autorisés, ce qui équivaut à voter pour les deux, ce qui signifie que le nœud a des opinions contradictoires. Cela pourrait être dû au le propriétaire du nœud exécutant plusieurs implémentations qui le font pas d’accord, ce qui indique une possible ambiguïté dans le protocole. Une fois que tous les votes ont été comptés à partir de l'ensemble complet validator, si l'opinion perdante a au moins une petite proportion (à être paramétré ; au plus la moitié, peut-être beaucoup moins) des votes de l'opinion gagnante, alors il est supposé être un fork accidentel de parachain et la parachain est automatiquement suspendue du processus de consensus. Dans le cas contraire, nous considérerons qu'il s'agit d'un acte malveillant et punirons le minorité qui votait pour l’opinion dissidente. La conclusion est un ensemble de signatures démontrant canonicité. Le bloc relais-chaîne peut alors être scellé et le processus de scellement du bloc suivant a commencé. 6.5. Améliorations de l'étanchéité des blocs relais. Tandis que cette méthode de scellement donne de fortes garanties sur le fonctionnement du système, elle n’est pas particulièrement évolutive puisque les informations clés de chaque parachain doivent avoir leur disponibilité garantie par plus d'un tiers de tous les validator. Cela signifie que l’empreinte de responsabilité de chaque validator grandit à mesure que d’autres chaînes sont ajoutées. Alors que la disponibilité des données au sein de réseaux de consensus ouverts est essentiellement un problème non résolu, il existe des moyens d'atténuer la surcharge imposée aux nœuds validator. Un simple La solution est de réaliser que même si les validator doivent assumer étant responsables de la disponibilité des données, ils n’ont pas besoin de stocker, de communiquer ou de répliquer eux-mêmes les données. Des silos de données secondaires, éventuellement liés (voire au tout même) les assembleurs qui compilent ces données, peuvent gérer les tâche de garantir la disponibilité, les validator fournissant une partie de leurs intérêts/revenus en paiement. Cependant, même si cela permet d’acquérir une certaine évolutivité intermédiaire, cela ne résout toujours pas le problème sous-jacent ; depuis l'ajout de chaînes supplémentaires nécessitera en général des validator supplémentaires, la consommation continue des ressources du réseau (notamment en termes de bande passante) augmente avec le carré de lechaînes, une propriété intenable à long terme. En fin de compte, nous continuerons probablement à nous cogner la tête contre la limitation fondamentale qui stipule que pour un réseau de consensus pour être considéré comme disponible en toute sécurité, le les besoins continus en bande passante sont de l’ordre du total validators fois le total des informations saisies. Ceci est dû à l'incapacité d'un réseau non fiable à répartir correctement la tâche de stockage des données sur de nombreux nœuds, ce qui en dehors de la tâche de traitement éminemment distribuable. 6.5.1. Présentation de la latence. Un moyen d'atténuer cela La règle est d’assouplir la notion d’immédiateté. En exigeant que 33 % + 1 validator votent pour la disponibilité seulement à terme, et non immédiatement, nous pouvons mieux utiliser la propagation exponentielle des données et aider à égaliser les pics d'échange de données. Une égalité raisonnable (bien que non prouvée) peut-être : (1) latence = participants × chaînes Dans le modèle actuel, la taille du système évolue avec le nombre de chaînes pour garantir que le traitement est distribué; puisque chaque chaîne nécessitera au moins un validator et que nous fixons l'attestation de disponibilité à une constante proportion de validators, alors les participants augmentent de la même manière avec le nombre de chaînes. On se retrouve avec : (2) latence = taille2 Cela signifie qu'à mesure que le système se développe, la bande passante requise et la latence jusqu'à la disponibilité sont connues sur l'ensemble du réseau. réseau, qui pourrait également être caractérisé comme le nombre de blocs avant la finalité, augmente avec son carré. C'est un facteur de croissance substantiel et pourrait s’avérer être un obstacle notable et nous contraindre à des paradigmes « non plats » comme composer plusieurs « Polkadotes » dans une hiérarchie pour le routage à plusieurs niveaux des publications à travers une arborescence de chaînes de relais.

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 13 6.5.2. Participation publique. Une autre direction possible est d'obtenir la participation du public au processus à travers un système de micro-réclamations. Comme les pêcheurs, il y a pourraient être des parties externes pour contrôler les validator qui prétendent disponibilité. Leur tâche est de trouver quelqu'un qui semble incapable de démontrer une telle disponibilité. Ce faisant, ils peut déposer une micro-réclamation auprès d'autres validator. PoW ou une obligation mise en jeu peut être utilisée pour atténuer l'attaque sybil ce qui rendrait le système largement inutile. 6.5.3. Garants de disponibilité. Une dernière voie serait de désigner un deuxième ensemble de validator liés comme « disponibilité » garants ». Ceux-ci seraient liés comme avec les validator normaux, et pourraient même provenir du même ensemble. (mais si tel est le cas, ils seraient choisis sur une période à long terme, au moins par session). Contrairement aux validator normaux, ils ne basculerait pas entre les parachains mais plutôt former un seul groupe pour attester de la disponibilité de toutes les données interchaînes importantes. Cela présente l’avantage d’assouplir l’équivalence entre participants et chaînes. Essentiellement, les chaînes peuvent grandir (avec l'ensemble de chaîne d'origine validator), alors que les participants, et particulièrement ceux qui participent au testament de disponibilité des données, peuvent rester pour le moins sous-linéaires et très probablement constant. 6.5.4. Préférences de l'assembleur. Un aspect important de cela système est de garantir qu’il existe une sélection saine de les assembleurs créant les blocs dans une parachain donnée. Si un un seul assembleur a dominé une parachain puis quelques attaques devenir plus réalisable puisque la probabilité de l'absence de la disponibilité de données externes serait moins évidente. Une option consiste à pondérer artificiellement les blocs de parachaine dans un mécanisme pseudo-aléatoire afin de favoriser une grande variété de assembleurs. Dans le premier cas, nous aurions besoin dans le cadre du mécanisme de consensus favorisé par validator Les candidats au bloc parachain ont été déterminés comme étant « plus lourds ». De même, nous devons inciter les validator à tenter de suggérer le bloc le plus lourd qu'ils peuvent trouver - cela pourrait être cela en rendant une partie de leur récompense proportionnelle au poids de leur candidat. Pour garantir que les assembleurs reçoivent une rémunération équitable et raisonnable chance que leur candidat soit choisi comme gagnant candidat en consensus, nous faisons le poids spéciﬁque d'un Le candidat au bloc parachain est déterminé sur une fonction aléatoire connectée à chaque assembleur. Par exemple, en prenant la mesure de distance XOR entre l’adresse de l’assembleur et un numéro pseudo-aléatoire cryptographiquement sécurisé déterminé à proximité du point de création du bloc (un « ticket gagnant » fictif). Cela donne effectivement à chacun assembleur (ou, plus spéciﬁquement, l’adresse de chaque assembleur) chance aléatoire que leur bloc candidat « gagne » tous les autres. Pour atténuer l'attaque sybil d'un seul assembleur « extrayant » une adresse proche du ticket gagnant et étant ainsi un favori pour chaque bloc, nous ajouterions une certaine inertie à l'adresse d'un assembleur. Cela peut être aussi simple que de les exiger avoir un montant de base de fonds à l'adresse. Un plus une approche élégante serait de pondérer la proximité du billet gagnant avec le montant des fonds garés au adresse en question. Même si la modélisation reste à faire, il est fort possible que ce mécanisme permette même à des les petites parties prenantes à contribuer en tant que rassembleur. 6.5.5. Blocs en surpoids. Si un ensemble validator est compromis, ils peuvent créer et proposer un bloc qui, bien que valide, prend un temps excessif à exécuter et valider. C'est un problème puisqu'un groupe validator pourrait former raisonnablement un bloc qui prend beaucoup de temps à exécuter à moins qu'une information particulière soit déjà connue permettant un raccourci, par ex. en prenant en compte un grand premier. Si un seul assembleur connaissait cette information, alors ils auraient un net avantage à obtenir le leur les candidats acceptaient tant que les autres étaient occupés à traiter l'ancien bloc. Nous appelons ces blocs en surpoids. La protection contre les validator soumettant et validant ces blocs relève en grande partie du même couvert que pour blocs invalides, mais avec une mise en garde supplémentaire : puisque le temps nécessaire à l'exécution d'un bloc (et donc son statut de surpoids) est subjectif, le résultat final d’un vote sur la mauvaise conduite se divise essentiellement en trois camps. Un Il est possible que le bloc ne soit définitivement pas en surpoids. dans ce cas, plus des deux tiers déclarent qu'ils pourraient exécuter le bloc dans une certaine limite (par exemple 50 % du temps total autorisé entre les blocs). Une autre est que le le bloc est ddéfinitivement en surpoids - ce serait le cas si plus de les deux tiers déclarent qu'ils n'ont pas pu exécuter le blocage dans ladite limite. Une dernière possibilité est une divergence d’opinion entre les validator. Dans ce cas, nous pouvons choisir d'infliger une punition proportionnée. Pour garantir que les validator peuvent prédire quand ils pourraient être proposant un bloc en surpondération, il peut être judicieux de leur demander de publier des informations sur leurs propres performances pour chaque bloc. Sur une période de temps suﬃsante, cela devrait leur permettre de profiler leur vitesse de traitement par rapport aux pairs qui les jugeraient. 6.5.6. Assurance assembleur. Un problème demeure pour les validator : contrairement aux réseaux PoW, pour vérifier les informations d'un assembleur bloc pour la validité, ils doivent réellement y exécuter les transactions. Des assembleurs malveillants peuvent fournir des blocs invalides ou en surpoids aux validator, ce qui leur cause des problèmes (gaspillage leurs ressources) et exigeant un coût d’opportunité potentiellement substantiel. Pour atténuer cela, nous proposons une stratégie simple sur le fait partie des validators. Premièrement, les candidats au bloc parachain envoyés aux validators doivent être signés depuis un compte de chaîne de relais avec des fonds ; si ce n'est pas le cas, alors le validator devrait tomber immédiatement. Deuxièmement, ces candidats doivent être classés en priorité par une combinaison (par exemple multiplication) de le montant des fonds sur le compte jusqu'à un certain plafond, le nombre de blocs précédents que l'assembleur a proposés avec succès dans le passé (sans parler des blocs précédents punitions), et le facteur de proximité avec le gagnant billet comme indiqué précédemment. La casquette devrait être la même comme les dommages punitifs payés au validator dans le cas d'entre eux envoyant un bloc invalide. Pour dissuader les assembleurs d'envoyer des candidats de bloc invalides ou en surpoids aux validator, tout validator peut placer dans le bloc suivant une transaction incluant le bloc incriminé alléguant un mauvais comportement avec pour eﬀet de transférer tout ou partie des fonds dans le compte de l'assembleur qui se comporte mal compte au validator lésé. Ce type de transaction précède tous les autres pour garantir que l'assembleur ne puisse pas retirer les fonds avant la punition. Le montant de les fonds transférés à titre de dommages et intérêts sont encore un paramètre dynamique

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 14 à modéliser, mais représentera probablement une proportion de la récompense globale validator pour reﬂéter le niveau de chagrin causé. À empêcher que des validator malveillants confisquent arbitrairement les fonds des collectionneurs, ce dernier peut faire appel de la décision du validator auprès d'un jury composé de validator choisis au hasard en échange. pour effectuer un petit dépôt. S’ils trouvent en faveur du validator, le dépôt est consommé par celui-ci. Sinon, le la caution est restituée et le validator est sanctionné (puisque le validator est dans une position beaucoup plus voûtée, l'amende sera probablement plutôt lourd). 6.6. Interchaîne Transaction Routage. Interchaîne le routage des transactions est l'un des éléments de maintenance essentiels tâches de la chaîne-relais et de ses validator. C'est le logique qui régit la façon dont une transaction publiée (souvent abrégée simplement en « post ») devient un résultat souhaité d'une parachain source à être une entrée non négociable d'une autre parachain de destination sans aucune confiance exigences. Nous choisissons soigneusement la formulation ci-dessus ; notamment nous ne nécessite pas qu'il y ait eu une transaction dans la source parachain d'avoir explicitement sanctionné ce post. Le seul Les contraintes que nous imposons à notre modèle sont que les parachaines doivent fournir, emballés dans le cadre de leur bloc global sortie du traitement, les postes qui sont le résultat du l’exécution du bloc. Ces publications sont structurées en plusieurs files d'attente FIFO ; le Le nombre de listes est appelé base de routage et peut être autour de 16. Ce nombre représente notamment la quantité de parachains que nous pouvons prendre en charge sans avoir à recourir à routage multiphase. Dans un premier temps, Polkadot prendra en charge cela type de routage direct, mais nous allons en décrire un possible processus de routage multiphase (« hyper-routage ») comme moyen d’évoluer bien au-delà de l’ensemble initial de parachains. Nous supposer que tout participants sais le sous-groupes pour les deux blocs suivants n, n + 1. En résumé, le Le système de routage suit ces étapes : • CollatorS : contacter les membres des V alidators[n][S] • Assembleurs : POUR CHAQUE sous-groupes : s'assurer au moins 1 membre des Validateurs[n][s] en contact • Assembleurs : POUR CHAQUE sous-groupes : supposer egress[n −1][s][S] est disponible (tous les messages entrants données vers 'S' du dernier bloc) • Assembleurs : Composez le bloc candidat b pour S : (b.header, b.ext, b.proof, b.receipt, b.egress) • Assembleurs : Envoyer preuve informations proof[S] = (b.header, b.ext, b.proof, b.receipt) à V alidateurs[n][S] • CollatorS : garantir que les données de transaction externes sont b.ext est mis à la disposition des autres assembleurs et validators • Assembleurs : POUR CHACUN sous-groupe s : Envoyer sortie informations sortie[n][S][s] = (b.header, b.receipt, b.egress[s]) à le recevoir sous-groupes membres de suivant bloquer V alidateurs[n + 1][s] • V alidatorV : pré-connecter tous les membres du même ensemble pour le bloc suivant : soit N = Chain[n + 1][V ]; connecter tous les validators v tels que Chain[n + 1][v] = N • V alidateurV : Rassemblez toutes les entrées de données pour cela bloquer : POUR CHACUN sous-groupe s : Récupérer egress[n −1][s][Chain[n][V ]], récupère d'autres validators v tels que Chain[n][v] = Chain[n][V ]. Peut-être en passant par d'autres validator sélectionnés au hasard pour une preuve de tentative. • V alidateurV : Acceptez les épreuves de candidat pour cela preuve de bloc[Chain[n][V ]]. Validité du blocage des votes • V alidateurV : Accepter les données de sortie des candidats pour bloc suivant : POUR CHAQUE sous-groupes, accepter sortie[n][s][N]. Disponibilité de sortie du bloc de vote ; republier parmi les validators intéressés v de telle sorte que Chaîne[n + 1][v] = Chaîne[n + 1][V ]. • V alidateurV : JUSQU'À CONSENSUS Où : egress[n][from][to] est la file d'attente de sortie actuelle informations pour les publications allant de la parachain « de » à parachain 'à' dans le bloc numéro 'n'. CollatorS est un assembleur pour les parachaines S. V alidators[n][s] est l'ensemble des validators pour les parachaines au numéro de bloc n. A l'inverse, Chain[n][v] est la parachain à laquelle validator v est attribué sur le bloc numéro n. block.egress[to] est la sortie file d'attente de messages provenant d'un bloc de bloc parachain dont la parachain de destination est à destination. Étant donné que les assembleurs perçoivent des frais (de transaction) basés sur leurs blocs deviennent canoniques, ils sont incités à le faire assurez-vous que pour chaque destination du bloc suivant, le sous-groupe les membres sont informés de la file d'attente de sortie du présent bloquer. Les validateurs sont incités uniquement à former un consensus sur un bloc (parachain), en tant que tels, ils se soucient peu de quel bloc de l’assembleur devient finalement canonique. Dans principe, un validator pourrait former une alliance avec un assembleur et conspirer pour réduire les chances que d’autres assembleurs les blocs deviennent canoniques, mais cela est à la fois diﬃcile à organiser en raison de la sélection aléatoirection de validators pour parachains et pourrait être défendu avec une réduction des frais payables pour les blocs de parachain qui résistent le processus de consensus. 6.6.1. Disponibilité des données externes. Assurer une parachain les données externes sont réellement disponibles est un problème récurrent avec systèmes décentralisés visant à répartir la charge de travail entre le réseau. Au cœur du problème se trouve la disponibilité problème qui stipule que puisqu'il n'est ni possible de faire une preuve de disponibilité non interactive ni aucune sorte de preuve d'indisponibilité, pour qu'un système BFT fonctionne correctement valider toute transition dont l'exactitude dépend de la disponibilité de certaines données externes, le nombre maximum de nœuds byzantins acceptables, plus un, du système doit attester de la disponibilité des données. Pour qu'un système puisse évoluer correctement, comme Polkadot, ceci pose un problème : si une proportion constante de validators doit attester de la disponibilité des données, et en supposant que les validator voudront réellement stocker les données avant d'affirmer qu'elles sont disponibles, alors comment pouvons-nous éviter le problème des besoins en bande passante/stockage augmentant avec la taille du système (et donc le nombre de validator) ? Une réponse possible serait d'avoir un ensemble séparé de validators (garants de disponibilité), dont la commande s'accroît de manière sublinéaire avec la taille de Polkadot dans son ensemble. C'est décrit en 6.5.3. Nous avons également une astuce secondaire. En tant que groupe, les assembleurs sont intrinsèquement incités à garantir que toutes les données sont disponible pour la parachain de leur choix puisque sans elle, ils sont incapables de créer d'autres blocs à partir desquels ils peuvent percevoir les frais de transaction. Les assembleurs forment également un groupe dont la composition est variée (en raison du caractère aléatoire des groupes parachain validator) non trivial à saisir et facile

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 15 à prouver. Les assembleurs récents (peut-être les derniers milliers de blocs) sont donc autorisés à lancer des défis à la disponibilité de données externes pour une parachain particulière bloquez sur validators pour une petite caution. Les validateurs doivent contacter ceux du sous-groupe validator apparemment incriminé qui ont témoigné et soit acquérir et restituer les données à l'assembleur, soit faire remonter le problème. en témoignant du manque de disponibilité (le refus direct de fournir les données compte comme un délit de confiscation de caution, donc le mauvais comportement de validator sera probablement simplement interrompre la connexion) et contacter des validator supplémentaires pour exécuter le même test. Dans ce dernier cas, la caution du collecteur est retourné. Une fois atteint le quorum de validator pouvant faire de tels témoignages d'indisponibilité, ils sont libérés, le Le sous-groupe qui se comporte mal est puni et le blocage est annulé. 6.6.2. Routage des publications. Chaque en-tête de parachain comprend un sortie-trie-root ; c'est la racine d'un trie contenant le bacs de base de routage, chaque bac étant une liste concaténée des postes de sortie. Les preuves Merkle peuvent être fournies partout parachain validators pour prouver qu'une parachain particulière le bloc avait une file d’attente de sortie particulière pour une parachain de destination particulière. Au début du traitement d'un bloc de parachain, chaque la file d'attente de sortie d'une autre parachain à destination dudit bloc est fusionné dans la file d’attente d’entrée de notre bloc. Nous supposons fort, probablement CSPR9, sous-bloc ordonnant de réaliser une opération déterministe qui n'offre aucun favoritisme entre aucun appariement de blocs de parachain. Les assembleurs calculent la nouvelle file d'attente et vidanger les files d'attente de sortie selon les paramètres de la parachain logique. Le contenu de la file d'attente d'entrée est écrit explicitement dans le bloc parachain. Cela a deux objectifs principaux : Premièrement, cela signifie que la parachain peut être synchronisée en toute confiance, indépendamment des autres parachains. Deuxièmement, cela simplifie la logistique des données en cas d'entrée complète la file d'attente ne peut pas être traitée en un seul bloc ; Les validator et les assembleurs sont capables de traiter les blocs suivants sans avoir à rechercher spécialement les données de la file d’attente. Si la file d'attente d'entrée de la parachain est supérieure à un seuil montant à la fin du traitement du bloc, il est alors marqué saturé sur la chaîne relais et aucun autre message ne peut lui être livré jusqu'à ce qu'il soit dégagé. Les preuves Merkle sont utilisé pour démontrer la fidélité du fonctionnement de l’assembleuse dans la preuve du bloc parachain. 6.6.3. Critique. Un défaut mineur relatif à cette base Le mécanisme est l’attentat post-bombe. C'est là que tout les parachains envoient le maximum de messages possible à une parachain particulière. Bien que cela bloque la cible file d'attente d'entrée en même temps, aucun dommage n'est causé au-delà une attaque DoS de transaction standard. Fonctionnant normalement, avec un ensemble de fonctions bien synchronisées et assembleurs non malveillants et validators, pour N parachains, N × M total validators et L assembleurs par parachain, nous peut décomposer le total des chemins de données par bloc pour : Validateur : M −1+L+L : M −1 pour les autres validators dans l'ensemble de parachain, L pour chaque assembleur fournissant un bloc de parachain candidat et un deuxième L pour chaque assembleur du bloc suivant nécessitant les charges utiles de sortie du bloc précédent. (Ce dernier cas ressemble en fait plutôt au pire des cas opération puisqu’il est probable que les assembleurs partageront ces données.) Collator : M +kN : M pour une connexion à chaque élément pertinent bloc parachain validator, kN pour amorcer les charges utiles de sortie vers un sous-ensemble de chaque groupe parachain validator pour le bloc suivant (et éventuellement certains assembleurs préférés). En tant que tel, les chemins de données par nœud augmentent de manière linéaire avec la complexité globale du système. Alors que c'est raisonnable, à mesure que le système évolue en centaines ou en milliers de parachains, une certaine latence de communication peut être absorbée en échange d’un taux de croissance de complexité plus faible. Dans ce cas, un algorithme de routage multiphase peut être utilisé afin de réduire le nombre de parcours instantanés au prix de l'introduction de tampons de stockage et de latence. 6.6.4. Routage hyper-cube. Le routage hyper-cube est un mécanisme qui peut principalement être construit comme une extension du mécanisme de routage de base décrit ci-dessus. Essentiellement, plutôt que d'augmenter la connectivité des nœuds avec le nombre de parachains et de nœuds de sous-groupes, nous grandissons uniquement avec le logarithme des parachaines. Les messages peuvent transiter entre plusieurs files d’attente de parachaines en route vers la livraison finale. Le routage lui-même est déterministe et simple. Nous commençons par limiter le nombre de casiers dans les files d'attente d'entrée/sortie ; plutôt que d'être le nombre total de parachains, ils sont lesbase de routage (b) . Celui-ci sera ﬁxé comme le nombre des parachains changent, l'exposant de routage (e) étant plutôt augmenté. Sous ce modèle, notre volume de messages grandit avec O(be), les voies restant constantes et la latence (ou nombre de blocs requis pour la livraison) avec O(e). Notre modèle de routage est un hypercube de e dimensions, chaque côté du cube ayant b emplacements possibles. À chaque bloc, nous acheminons les messages le long d'un seul axe. Nous alternez les axes de manière circulaire, garantissant ainsi le délai de livraison des blocs électroniques dans le pire des cas. Dans le cadre du traitement de la parachain, à destination de l'étranger Les messages trouvés dans la file d'attente d'entrée sont immédiatement acheminés vers le bac de la file d'attente de sortie approprié, compte tenu de la numéro de bloc actuel (et donc dimension de routage). Ceci le processus nécessite un transfert de données supplémentaire pour chaque saut sur l'itinéraire de livraison, mais c'est un problème en soi qui peut être atténué en utilisant des moyens alternatifs de livraison de données utiles et comprenant uniquement une référence, plutôt que la charge utile complète du message dans le post-trie. Un exemple d'un tel routage hyper-cube pour un système avec 4 parachaines, b = 2 et e = 2 pourraient être : Phase 0, sur chaque message M : • sub0 : si Mdest ∈{2, 3} alors sendTo(2) sinon garder • sub1 : si Mdest ∈{2, 3} alors sendTo(3) sinon garder • sub2 : si Mdest ∈{0, 1} alors sendTo(0) sinon garder • sub3 : si Mdest ∈{0, 1} alors sendTo(1) sinon garder Phase 1, sur chaque message M : • sub0 : si Mdest ∈{1, 3} alors sendTo(1) sinon garder • sub1 : si Mdest ∈{0, 2} alors sendTo(0) sinon garder • sub2 : si Mdest ∈{1, 3} alors sendTo(3) sinon garder • sub3 : si Mdest ∈{0, 2} alors sendTo(2) sinon garder Les deux dimensions ici sont faciles à considérer comme la première deux bits de l'index de destination ; pour le premier bloc, le seul le bit d’ordre supérieur est utilisé. Le deuxième bloc traite avec le bit de poids faible. Une fois que les deux se produisent (de manière arbitraire commande) alors le courrier sera acheminé. 9cryptographiquement sécurisé pseudo-aléatoire

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 16 6.6.5. Maximiser le hasard. Une modification de la base la proposition verrait un total ﬁxe de c2 −c validators, avec c−1 validators dans chaque sous-groupe. Chaque bloc, plutôt que il y a une répartition non structurée des validators parmi les parachaines, au lieu de cela pour chaque sous-groupe de parachaines, chaque validator serait attribué à un utilisateur unique et diﬀérent. sous-groupe parachain sur le bloc suivant. Ce serait conduire à l'invariant qu'entre deux blocs quelconques, pour tout deux paires de parachain, il existe deux validator qui ont échangé les responsabilités de la parachain. Bien que cela ne puisse pas être utilisé pour obtenir des garanties absolues sur la disponibilité (un seul validator tombera occasionnellement hors ligne, même si bienveillant), il peut néanmoins optimiser le cas général. Cette approche n'est pas sans complications. L'ajout d'une parachain nécessiterait également une réorganisation de l'ensemble validator. De plus le nombre de validators, étant lié au carré du nombre de parachains, commencerait très petit au début et finirait par grandir loin trop rapide, devenant intenable après environ 50 parachains. Aucun de ces problèmes ne constitue un problème fondamental. Dans le premier cas, la réorganisation des ensembles validator est quelque chose qui doit être fait régulièrement de toute façon. Concernant la taille du validator défini, lorsqu'il est trop petit, plusieurs validator peuvent être attribués à la même parachain, en appliquant un facteur entier au total global de validators. Un mécanisme de routage multiphase tel que le routage Hypercube, discuté en 6.6.4 alléger l'exigence d'un grand nombre de validator lorsqu'il y a un grand nombre de chaînes. 6.7. Validation de la parachaine. L'objectif principal d'un validator est de témoigner, en tant qu’acteur soudé, que le le bloc est valide, y compris, mais sans s'y limiter, toute transition d'état, toutes transactions externes incluses, l'exécution de tous les messages en attente dans la file d'attente d'entrée et l'état final de la file d’attente de sortie. Le processus lui-même est assez simple. Une fois que le validator a scellé le bloc précédent, il est libre commencer à travailler pour fournir un bloc de parachain candidat candidat au prochain tour de consensus. Initialement, le validator trouve un candidat de bloc de parachain via un assembleur de parachain (décrit ci-dessous) ou un de ses co-validators. Les données candidates au bloc parachain inclut l’en-tête du bloc, l’en-tête du bloc précédent, toutes les données d'entrée externes incluses (pour Ethereum et Bitcoin, ces données seraient appelées transactions, mais en principe elles peuvent inclure des structures de données arbitraires à des fins arbitraires), des données de file d'attente de sortie et des données internes pour prouver la validité de la transition d'état (pour Ethereum il s'agirait des différents nœuds d'état/de stockage requis pour exécuter chaque transaction). Des preuves expérimentales montrent cet ensemble de données complet pour un bloc Ethereum récent être au maximum de quelques centaines de KiB. Simultanément, si ce n'est pas encore fait, le validator sera tenter de récupérer des informations relatives à la transition du bloc précédent, initialement à partir du bloc précédent validators et plus tard de tous les validators signant pour le disponibilité des données. Une fois que le validator a reçu un tel bloc candidat, ils le valident ensuite localement. Le processus de validation est contenu dans le module validator de la classe parachain, un module logiciel sensible au consensus qui doit être écrit pour toute implémentation de Polkadot (bien qu'en principe une bibliothèque avec un C ABI pourrait permettre à une seule bibliothèque de être partagé entre les implémentations avec les réduction de la sécurité due au fait de n’avoir qu’une seule implémentation « de référence »). Le processus prend l'en-tête du bloc précédent et vérifie son identité via la chaîne de relais récemment convenue. bloc dans lequel son hash doit être enregistré. Une fois la validité de l'en-tête parent vérifiée, la parachain spécifique La fonction de validation de la classe peut être appelée. Il s'agit d'une fonction unique acceptant un certain nombre de champs de données (environ ceux donnés précédemment) et renvoyant un simple booléen proclamant la validité du blocage. La plupart de ces fonctions de validation vérifieront d'abord des champs d'en-tête qui peuvent être dérivés directement de le bloc parent (par exemple parent hash, numéro). Suite cela, ils rempliront toutes les structures de données internes comme nécessaires au traitement des transactions et/ou des publications. Pour une chaîne de type Ethereum, cela revient à remplir un trie base de données avec les nœuds qui seront nécessaires pour le exécution complète des transactions. D'autres types de chaînes peuvent avoir autre pmécanismes de réparation. Une fois cela fait, les publications d'entrée et les transactions externes (ou tout ce que représentent les données externes) seront édictés, équilibrés selon les spécifications de la chaîne. (Un Une valeur par défaut raisonnable pourrait être d'exiger que toutes les publications entrantes soient traitées avant que les transactions externes ne soient traitées, mais cela devrait appartenir à la logique de la parachain de décider.) Grâce à ce texte, une série de postes de sortie seront créés et il sera vérifié que ceux-ci correspondent bien le candidat du assembleur. Enfin, le formulaire correctement renseigné l’en-tête sera vérifié par rapport à l’en-tête du candidat. Avec un bloc candidat entièrement validé, le validator peut alors voter pour le hash de son en-tête et envoyer toutes les informations de validation requises aux co-validator de son sous-groupe. 6.7.1. Collateurs Parachain. Les assembleurs de parachain sont des opérateurs non cautionnés qui remplissent une grande partie de la tâche des mineurs sur les réseaux blockchain actuels. Ils sont spécifiques à une parachain particulière. Pour fonctionner, ils doivent maintenir à la fois la chaîne de relais et le système entièrement synchronisé parachaine. La signification précise de « entièrement synchronisé » dépendra de la classe de la parachain, mais inclura toujours l'état actuel de la file d'attente d'entrée de la parachain. Dans le cas de Ethereum, cela implique également au moins de maintenir une base de données Merkle-tree des derniers blocs, mais pourrait incluent également diverses autres structures de données, notamment Bloom filtres pour l'existence du compte, les informations familiales, la journalisation sorties et tables de recherche inversée pour le numéro de bloc. En plus de maintenir les deux chaînes synchronisées, il doit également « pêcher » les transactions en maintenant une file d’attente des transactions et en acceptant les transactions correctement validées du réseau public. Avec la file d'attente et la chaîne, c'est capable de créer de nouveaux blocs candidats pour les validator choisis à chaque bloc (dont l'identité est connue puisque la chaîne de relais est synchronisée) et de les soumettre, avec les diverses informations annexes telles que la preuve de validité, via le réseau de pairs. Pour sa peine, il perçoit tous les frais relatifs aux transactions qu'il inclut. Diverses théories économiques flottent autour de cela arrangement. Dans un marché fortement concurrentiel où il existe s'il y a un surplus de collecteurs, il est possible que la transaction les frais seront partagés avec les parachain validators pour inciter l’inclusion d’un bloc d’assemblage particulier. De la même manière,

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 17 certains assembleurs peuvent même augmenter les frais requis à payer afin de rendre le bloc plus attractif pour validators. Dans ce cas, un marché naturel devrait se former avec des transactions payant des frais plus élevés, évitant la file d'attente et avoir une inclusion plus rapide dans la chaîne. 6.8. Réseautage. Réseautage sur les blockchain traditionnels comme Ethereum et Bitcoin a des exigences plutôt simples. Toutes les transactions et tous les blocages sont diffusés dans de simples potins non dirigés. La synchronisation est plus complexe, notamment avec Ethereum mais en réalité cette logique était contenue dans la stratégie des pairs plutôt que le protocole lui-même qui se résolvait autour de quelques types de messages de requête et de réponse. Alors que Ethereum a progressé sur les offres de protocoles actuelles avec le protocole devp2p, qui a permis de nombreuses les sous-protocoles doivent être multiplexés sur une seule connexion homologue et avoir ainsi la même superposition homologue prenant en charge de nombreux protocoles p2p simultanément, la partie Ethereum de le protocole restait encore relativement simple et le p2p le protocole reste pour l’instant inachevé avec d’importants fonctionnalités manquantes telles que la prise en charge de la QoS. Malheureusement, le désir de créer un protocole « Web 3 » plus omniprésent a échoué, les seuls projets qui l'utilisent étant ceux explicitement financé par la vente participative Ethereum. Les exigences pour Polkadot sont un peu plus substantielles. Plutôt qu'un réseau totalement uniforme, Polkadot compte plusieurs types de participants, chacun ayant des exigences diﬀérentes quant à la composition de leurs pairs et plusieurs réseaux. des « pistes » dont les participants auront tendance à discuter données particulières. Cela signifie une superposition de réseau beaucoup plus structurée – et un protocole prenant en charge cela – sera probablement nécessaire. En outre, l'extensibilité pour faciliter les ajouts futurs tels que de nouveaux types de « chaînes » peut eux-mêmes nécessitent une nouvelle structure de superposition. Lors d'une discussion approfondie sur la façon dont le réseautage Si le protocole peut paraître hors du champ d'application de ce document, certaines analyses des exigences sont raisonnables. Nous pouvons diviser grossièrement les participants de notre réseau en deux ensembles (chaîne relais, parachains) chacun des trois sous-ensembles. Nous pouvons indiquent également que chacun des participants à la parachain n'est que intéressés à converser entre eux plutôt que participants à d'autres parachains : • Acteurs de la chaîne relais : • Validateurs : P, divisé en sous-ensembles P[s] pour chacun parachaine • Garants de disponibilité : A (cela peut être représenté par des validateurs dans la forme de base du protocole) • Clients relais-chaîne : M (notez les membres de chaque l'ensemble de parachain aura également tendance à être membre de M) • Participants à la Parachain : • Collateurs Parachain : C[0], C[1], . . . • Pêcheurs Parachain : F[0], F[1], . . . • Clients Parachain : S[0], S[1], . . . • Clients légers Parachain : L[0], L[1], . . . En général, nous nommons des classes particulières de communication aura tendance à avoir lieu entre les membres de ces ensembles : • P | Un <-> P | R : Le plein ensemble de validators/garants doit être bien connecté à parvenir à un consensus. • P[s] <-> C[s] | P[s] : Chaque validator en tant que membre d'un groupe de parachain donné aura tendance à bavarder avec d'autres membres ainsi qu'avec les assembleurs de cette parachain pour découvrir et partager des candidats de bloc. • Un <-> P[s] | C | R : Chaque garant de disponibilité devra collecter des données inter-chaînes sensibles au consensus les données des validator qui lui sont attribués ; assembleurs peut également optimiser les chances de consensus sur leur bloquer en l'annonçant aux garants de disponibilité. Une fois qu'ils les auront, les données seront versées à autre garant pour faciliter le consensus. • P[s] <-> A | P[s'] : les Parachain validators seront Vous devez collecter des données d'entrée supplémentaires à partir de l'ensemble précédent de validator ou des garants de disponibilité. • F[s] <-> P : Lors de la déclaration, les pêcheurs peuvent placer une réclamation auprès de tout participant. • M <-> M | P | R : Les clients généraux de la chaîne de relais décaissent les données des validator et des garants. • S[s] <-> S[s] | P[s] | R : Les clients Parachain décaissent les données des validator/garants. • L[s] <-> L[s] | S[s] : clients légers Parachain décaisser les données des clients complets. Pour assurer un mécanisme de transport eﬃcace, un « plat » réseau superposé, comme le devp2p de Ethereum, où chaque le nœud ne différencie pas (de manière non arbitraire) l’aptitude de ses Il est peu probable que les pairs conviennent. Un raisonnablement extensible le mécanisme de sélection et de découverte par les pairs nécessitera probablement à inclure dans le protocole ainsi que agressif planifier une analyse prospective pour garantir le bon type de pairs sont « par hasard » connecté au bon moment. La stratégie précise de composition par les pairs sera diﬀérente pour chaque classe de participants : pour une multi-chaînes, les assembleuses devront soit être continuellement se reconnecter aux validator élus en conséquence, ou besoin d'accords continus avec un sous-ensemble des validator pour s'assurer qu'ils ne sont pas déconnectés pendant la grande majorité du temps où ils sont inutiles pour ce validator. Les assembleurs tenteront aussi naturellement de maintenir un ou des connexions plus stables au garant de disponibilité mis en place pour assurer une propagation rapide de leurs messages sensibles au consensus données. Les garants de disponibilité viseront principalement à maintenir un connexion stable entre eux et avec les validator (pour le consensus et les données parachain critiques au consensus auxquelles ils l'attestent), ainsi qu'à certains assembleurs (pour la parachain données) et certains pêcheurs et clients à part entière (pour disperser informations). Les validateurs auront tendance à rechercher d'autres validator, en particulier ceux du même sous-groupe et tout autre validator. des assembleurs qui peuvent leur fournir des candidats au bloc parachain. Les pêcheurs, ainsi que les relais généralistes et parachaines les clients viseront généralement à maintenir une connexion ouverte à un validator ou garant, mais plein d'autres nœuds similaires à eux-mêmes autrement. Les clients légers de la Parachain viseront de la même manière à être connectés à un client complet de la parachain, sinon seulement d’autres clients légers parachain. 6.8.1. Le problème du désabonnement des pairs. Dans la proposition de protocole de base, chacun de ces sous-ensembles change constamment de manière aléatoire avec chaque bloc en tant que validators assignés pour vérifier les transitions de parachain sont élues au hasard. Cela peut être un problème si des nœuds disparates (non homologues) doivent transmettre des données entre eux. Il faut soit s'appuyer sur un réseau de pairs équitablement réparti et bien connecté pour

POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 18 garantir que la distance de saut (et donc la latence dans le pire des cas) n'augmente qu'avec le logarithme de la taille du réseau (un protocole de type Kademlia [13] peut aider ici), ou il faut introduire des temps de blocage plus longs pour permettre la négociation de connexion nécessaire afin de conserver un ensemble d'homologues qui reflète les besoins de communication actuels du nœud. Aucune de ces solutions n’est excellente : de longs temps de blocage être imposé au réseau peut le rendre inutile pour applications et chaînes particulières. Même un parfaitement juste et le réseau connecté entraînera un gaspillage important de bande passante à mesure qu'elle évolue en raison des nœuds non intéressés ayant pour leur transmettre des données inutiles. Même si les deux directions peuvent faire partie de la solution, une optimisation raisonnable pour aider à minimiser la latence serait être de restreindre la volatilité de ces parachain validator ensembles, soit en réaffectant l'appartenance uniquement entre des séries de blocs (par exemple, en groupes de 15, qui à 4 secondes le temps de blocage signifierait modifier les connexions une seule fois par minute) ou en faisant tourner les membres de manière progressive, par ex. changeant par un membre à la fois (par exemple s'il y a y a-t-il 15 validator attribués à chaque parachain, alors en moyenne, cela prendrait une minute complète entre des ensembles). En limitant le taux de désabonnement des pairs et en garantissant que les connexions entre pairs avantageuses sont établies correctement dans avancer grâce à la prévisibilité partielle de la parachain ensembles, nous pouvons contribuer à garantir que chaque nœud conserve en permanence un sélection fortuite de pairs. 6.8.2. Chemin vers un protocole réseau efficace. Probablement le L'effort de développement le plus efficace et le plus raisonnable se concentrera sur l'utilisation d'un protocole préexistant plutôt que sur un protocole continu. le nôtre. Il existe plusieurs protocoles de base peer-to-peer qui nous pouvons utiliser ou augmenter, y compris le propre devp2p de Ethereum [22], libp2p [1] d'IPFS et GNUnet [4] de GNU. Un examen complet de ces protocoles et de leur pertinence pour construire un réseau de pairs modulaire prenant en charge certaines garanties structurelles, un pilotage dynamique par les pairs et des sous-protocoles extensibles dépasse largement la portée de ce document mais constituera un étape importante dans la mise en œuvre de Polkadot. 7. Aspects pratiques du Protocole 7.1. Paiement des transactions interchaînes. Alors qu'un grand Une certaine quantité de liberté et de simplicité est obtenue en supprimant le besoin d'un cadre de comptabilité holistique des ressources de calcul comme le gaz de Ethereum, cela soulève une question importante : sans gaz, comment peut-on parachain éviter qu'une autre parachain la force à faire du calcul ? Bien que nous puissions compter sur la file d'attente d'entrée après la transaction tampons pour empêcher une chaîne de spammer une autre avec données de transaction, il n'existe aucun mécanisme équivalent fourni par le protocole pour empêcher le spam du traitement des transactions. C'est un problème laissé au niveau supérieur. Depuis les chaînes sont libres d'attacher une sémantique arbitraire aux éléments entrants données post-transaction, nous pouvons garantir que le calcul doit être payé avant de commencer. Dans la même veine que le modèle épousé par Ethereum Serenity, nous pouvons imaginer un contrat de « rodage » au sein d’une parachain qui permet un validator pour garantir le paiement en échange du mise à disposition d'un volume particulier de ressources de traitement. Ces ressources peuvent être mesurées en quelque chose comme le gaz, mais il pourrait également s'agir d'un modèle entièrement nouveau tel qu'un délai d'exécution subjectif ou un modèle forfaitaire de type Bitcoin. En soi, cela n'est pas très utile car nous ne pouvons pas facilement supposer que l'appelant hors chaîne dispose de quel que soit le mécanisme de valeur reconnu par le cambriolage contrat. Cependant, on peut imaginer un contrat secondaire « en petits groupes » dans la chaîne d’approvisionnement. Les deux contrats ensemble formeraient un pont, se reconnaissant et fournissant une équivalence de valeur. (Jalonnement-tokens, disponible pour chacun, pourrait être utilisé pour régler la balance des paiements.) Faire appel à une autre chaîne de ce type signifierait utiliser un proxy par ce pont, qui fournirait les moyens de négocier le transfert de valeur entre les chaînes afin de payer les ressources de calcul requises sur la parachain de destination. 7.2. Supplémentaire Chaînes. Tandis que le ajout de un la parachain est une opération relativement bon marché, elle n’est pas gratuite. Plus de parachaines signifie moins de validators par parachaine et, éventuellement, un plus grand nombre de validator chacun avec un obligation moyenne réduite. Alors que le problème d'un coût de coercition moindre pour attaquer une parachain est atténué grâce à pêcheurs, l’ensemble croissant de validator force essentiellement un degré de latence plus élevé en raison de la mécanique du consensus sous-jacentthod. De plus, chaque parachain apporte avec lui le potentiel de chagriner les validator avec un algorithme de validation trop lourd. En tant que tel, il y aura un « prix » qui validators et/ou la communauté des parties prenantes extraira pour le ajout d'une nouvelle parachaine. Ce marché des chaînes va voir éventuellement l'ajout de soit : • Les chaînes qui n'ont probablement aucune contribution nette à payer (en termes de verrouillage ou de brûlage de staking token) à en faire partie (par exemple, les chaînes de consortium, Doge-chains, chaînes spécifiques à une application) ; • des chaînes qui apportent une valeur intrinsèque au réseau en ajoutant des fonctionnalités particulières difficiles pour aller ailleurs (par exemple, confidentialité, évolutivité interne, liens de service). Essentiellement, la communauté des parties prenantes devra être incité à ajouter des chaînes enfants – que ce soit financièrement ou par la volonté d'ajouter des chaînes fonctionnelles au relais. Il est prévu que les nouvelles chaînes ajoutées auront un effet très délai de préavis court pour le retrait, permettant aux nouvelles chaînes de être expérimenté sans aucun risque de compromis la proposition de valeur à moyen ou long terme. 8. Conclusion Nous avons décrit une direction que l'on peut prendre pour rédiger un protocole multi-chaînes évolutif et hétérogène avec le potentiel d'être rétrocompatible avec certains protocoles préexistants Réseaux blockchain. Dans le cadre d'un tel protocole, les participants travailler dans un intérêt personnel éclairé pour créer un système global qui peut être étendu d'une manière exceptionnellement libre et sans le coût typique pour les utilisateurs existants qui provient d'une conception standard blockchain. Nous avons donné un aperçu de l'architecture qu'il faudrait, y compris la nature des participants, leurs incitations économiques et les processus dans lesquels ils doivent s'engager. Nous avons identifié une conception de base et discuté de ses points forts et limites; en conséquence, nous avons d'autres instructions qui peut atténuer ces limitations et céder du terrain vers une solution blockchain entièrement évolutive.POLKADOT : VISION D'UN CADRE MULTI-CHAÎNES HÉTÉROGÈNE PROJET 1 19 8.1. Matériel manquant et questions ouvertes. La bifurcation du réseau est toujours une possibilité en raison d'implémentations divergentes du protocole. La guérison d'un tel la condition exceptionnelle n’a pas été discutée. Étant donné que le réseau aura nécessairement une période de finalisation non nulle, la récupération après la bifurcation de la chaîne de relais ne devrait pas poser de problème majeur, mais cela nécessitera une intégration minutieuse dans le protocole de consensus. La disposition relative à la confiscation des cautions et, à l'inverse, à la récompense a été n’a pas été exploré en profondeur. À l'heure actuelle, nous supposons des récompenses sont fournis selon le principe du gagnant qui remporte tout : cela peut ne pas offrir le meilleur modèle d’incitation aux pêcheurs. Un processus d'engagement-révélation de courte durée permettrait à de nombreux pêcheurs réclamer le prix en donnant une répartition plus équitable des récompenses, cependant, le processus pourrait entraîner une latence supplémentaire dans le découverte d'une mauvaise conduite. 8.2. Remerciements. Un grand merci à tous les les correcteurs qui ont aidé à mettre cela dans une vague forme présentable. En particulier, Peter Czaban, Bjorn Wagner, Ken Kappler, Robert Habermeier, Vitalik Buterin, Reto Trinkler et Jack Petersson. Merci à tous les personnes qui ont apporté des idées ou les débuts parmi eux, Marek Kotewicz et Aeron Buchanan méritent une mention particulière. Et merci à tous les autres pour leur aide en cours de route. Toutes les erreurs sont les miennes. Certaines parties de ce travail, y compris la recherche initiale sur algorithmes de consensus, a été financé en partie par les Britanniques Gouvernement dans le cadre du programme Innovate UK.