Polkadot: Visi untuk Kerangka Multi-Rantai yang Heterogen

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 flexible é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

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 flexible é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'effet 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, effectuant – 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 flexibilité 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.

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 diffé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 confiance 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 à 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 suffisamment é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 ratifié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 ratifié 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.

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 efficace 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 suffisant, 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 suffisante (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 confirmation, 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 efficacement 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 effort conséquent avec un calendrier incertain et très probablement exigeant la coopération des parties prenantes au sein de ce réseau.

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 diffé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 offrera une simplification protocolaire suffisamment 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 suffisamment 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 difficile à 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 offre 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 effet 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éfinie 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 efficace 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 différents les parachains peuvent bénéficier de diffé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écifique 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écifiquement, 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 suffisante, 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 effet 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 reflé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 difficile à 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 fixé 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 fixe 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 diffé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 diffé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 efficace, 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 diffé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.