Chainlink : un réseau Oracle décentralisé

Résumé

Dans ce livre blanc, nous exprimons une vision de l'évolution de Chainlink au-delà de sa conception initiale dans le livre blanc original Chainlink. Nous prévoyons un rôle de plus en plus étendu pour les réseaux oracle, dans lequel ils complètent et améliorent les blockchain existants et nouveaux en fournissant des services rapides, fiables et Connectivité universelle préservant la confidentialité et calcul hors chaîne pour smart contracts. La base de notre plan est ce que nous appelons les réseaux Oracle décentralisés, ou DONs pour faire court. Un DON est un réseau entretenu par un comité de Chainlink nœuds. Il prend en charge n'importe laquelle d'une gamme illimitée de fonctions oracle choisies pour déploiement par le comité. Un DON agit ainsi comme une puissante couche d'abstraction, offrant des interfaces pour les smart contract vers des ressources hors chaîne étendues et hautement Ressources informatiques hors chaîne efficaces mais décentralisées au sein du DON lui-même. Avec DONs comme tremplin, Chainlink prévoit de se concentrer sur les avancées dans sept domaines clés : • smart contract hybrides : offrant un cadre général puissant pour augmenter les capacités smart contract existantes en composant en toute sécurité en chaîne et des ressources informatiques hors chaîne dans ce que nous appelons des smart contract hybrides. • Faire abstraction de la complexité : présenter aux développeurs et aux utilisateurs des la fonctionnalité élimine le besoin de se familiariser avec des sous-jacents complexes protocoles et limites du système. • Mise à l'échelle : garantir que les services oracle atteignent les latences et les débits exigé par les systèmes décentralisés hautes performances. • Confidentialité : permettre des systèmes de nouvelle génération qui combinent les blockchain transparence innée avec de nouvelles protections de confidentialité solides pour les informations sensibles données. • Équité des ordres pour les transactions : prise en charge du séquençage des transactions de différentes manières qui sont équitables pour les utilisateurs finaux et empêchent les attaques frontales et autres par robots et mineurs exploiteurs. • Minimisation de la confiance : création d'une couche de support hautement fiable pour smart contracts et autres systèmes dépendants de oracle par décentralisation, ancrage fort dans des blockchain de haute sécurité, cryptographie techniques et garanties cryptoéconomiques. • Sécurité (cryptoéconomique) basée sur des incitations : concevoir rigoureusement et déployer de manière robuste des mécanismes qui garantissent que les nœuds dans les DONs ont de fortes incitations économiques à se comporter de manière fiable et correcte, même face à des adversaires disposant de ressources suffisantes. Nous présentons les innovations préliminaires et en cours de la communauté Chainlink dans chacun de ces domaines, donnant une image de l'élargissement et de la croissance croissante capacités puissantes prévues pour le réseau Chainlink.

Introduction

Les blockchains oracle sont souvent considérées aujourd’hui comme des services décentralisés avec un seul objectif : pour transférer les données des ressources hors chaîne vers des blockchain. Mais c'est un petit pas, du transfert de données au calcul, au stockage ou à la transmission bidirectionnelle. Cette observation justifie une notion beaucoup plus large de la fonctionnalité des oracle. Alors aussi répondre aux exigences de service croissantes des smart contract et de plus en plus multiformes technologies qui s'appuient sur les réseaux oracle. En bref, un oracle peut et devra être une interface de calcul à usage général, bidirectionnelle et entre et parmi les systèmes en chaîne et hors chaîne. Le rôle des Oracles dans l'écosystème blockchain est d'améliorer les performances, les fonctionnalités et l'interopérabilité des smart contract afin qu'ils puissent apporter de nouveaux modèles de confiance et de transparence à une multiplicité d’industries. Cette transformation passera par l’élargissement de l’utilisation des smart contract hybrides, qui fusionnent Les propriétés spéciales de blockchain avec les capacités uniques des systèmes hors chaîne tels que oracle réseaux et obtenez ainsi une portée et une puissance bien supérieures à celles des systèmes en chaîne en isolement. Dans ce livre blanc, nous exprimons une vision pour ce que nous appelons Chainlink 2.0, une évolution de Chainlink au-delà de sa conception initiale dans le livre blanc original Chainlink [98]. Nous prévoyons un rôle de plus en plus étendu pour les réseaux oracle, dans lequel ils complètent et améliorent les blockchain existants et nouveaux en fournissant une connectivité et un calcul universels rapides, fiables et préservant la confidentialité pour les systèmes hybrides. smart contracts. Nous pensons que les réseaux oracle évolueront même pour devenir des services publics pour exporter des données de haute intégrité de niveau blockchain vers des systèmes au-delà du blockchain écosystème. Aujourd'hui, les nœuds Chainlink gérés par un ensemble diversifié d'entités se réunissent dans des réseaux oracle pour relayer les données vers les smart contract dans ce que l'on appelle des rapports. Nous pouvons voir un tel oracle nœuds en tant que comité similaire à celui d'un consensus classique blockchain [72], mais dans le but de prendre en charge les blockchain existants, plutôt que de fournir des fonctionnalités autonomes. Avec fonctions aléatoires vérifiables (VRF) et reporting hors chaîne (OCR), Chainlink évolue déjà vers un cadre et une infrastructure à usage général pour fournir les ressources informatiques dont smart contract ont besoin pour fonctionnalité avancée. La base de notre plan pour Chainlink 2.0 est ce que nous appelons Oracle décentralisé. Réseaux, ou DONs en abrégé. Depuis que nous avons introduit le terme « réseau oracle » dans le livre blanc original Chainlink [98], oracles ont développé des fonctionnalités et des fonctionnalités toujours plus riches étendue d'application. Dans cet article, nous proposons une nouvelle définition du terme selon à notre vision future de l’écosystème Chainlink. Dans cette vue, un DON est un réseau maintenu par un comité de nœuds Chainlink. Ancré dans un protocole consensuel, il prend en charge n'importe laquelle d'une gamme illimitée de fonctions oracle choisies pour le déploiement par le comité. Un DON agit ainsi comme une couche d'abstraction blockchain, fournissant des interfaces aux ressources hors chaîne pour les smart contract et d'autres systèmes. Il fournit également accès à des ressources informatiques hors chaîne hautement efficaces mais décentralisées. En général, a DON prend en charge les opérations sur une chaîne principale. Son objectif est de permettre desbles hybrides smart contracts, qui combinent le calcul en chaîne et hors chaîne avec connexion à des ressources externes. Nous soulignons que même avec le recours aux comités dans les DON, Chainlink lui-même reste intrinsèquement sans autorisation. Les DON servent de fondement à un système sans autorisation cadre dans lequel les nœuds peuvent se réunir pour implémenter des réseaux oracle personnalisés avec leurs propres régimes d'inclusion de nœuds, qui peuvent être autorisés ou non. Avec DONs comme base, nous prévoyons de nous concentrer dans Chainlink 2.0 sur les avancées dans sept domaines clés : les smart contract hybrides, faisant abstraction de la complexité, de la mise à l'échelle, de la confidentialité, de l'équité des ordres pour les transactions, de la minimisation de la confiance et de la sécurité (cryptoéconomique) basée sur des incitations. Dans l'introduction de cet article, nous présentons un aperçu de la décentralisation Oracle Networks dans la section 1.1, puis nos sept domaines clés d'innovation dans la section 1.2. Nous décrivons l’organisation du reste de cet article dans la section 1.3. 1.1 Réseaux Oracle décentralisés Les réseaux Oracle décentralisés sont conçus pour améliorer et étendre les capacités de smart contracts sur une cible blockchain ou une chaîne principale via des fonctions qui sont non disponible nativement. Pour ce faire, ils fournissent les trois ressources de base trouvées dans systèmes informatiques : mise en réseau, stockage et calcul. Un DON vise à offrir ces ressources avec de fortes propriétés de confidentialité, d’intégrité et de disponibilité,1 ainsi que ainsi que la responsabilité. Les DON sont formés par des comités de nœuds oracle qui coopèrent pour remplir un objectif spécifique. un emploi ou choisir d'établir une relation à long terme afin de fournir des services persistants aux clients. Les DON sont conçus de manière indépendante de blockchain. Ils promettent de servir de un outil puissant et flexible permettant aux développeurs d'applications de créer un support hors chaîne pour leurs smart contracts sur n’importe quelle chaîne principale prise en charge. Deux types de fonctionnalités réalisent les capacités d'un DON : les exécutables et adaptateurs. Les exécutables sont des programmes qui s'exécutent en continu et de manière décentralisée sur le DON. Bien qu'ils ne stockent pas directement les actifs de la chaîne principale, ils présentent des avantages importants, notamment des performances élevées et la capacité d'effectuer des transactions confidentielles. calcul. Les exécutables s'exécutent de manière autonome sur un DON et effectuent des tâches déterministes opérations. Ils fonctionnent en synergie avec des adaptateurs qui relient le DON à des ressources externes et peut être appelé par des exécutables. Les adaptateurs, tels que nous les envisageons pour les DON, sont un généralisation des adaptateurs externes en Chainlink aujourd'hui. Alors que les adaptateurs existants généralement, ils ne récupèrent que les données des sources de données, les adaptateurs peuvent fonctionner de manière bidirectionnelle ; dans DONs, ils peuvent en outre exploiter le calcul conjoint par les nœuds DON pour obtenir fonctionnalités supplémentaires, telles que le cryptage des rapports pour une consommation respectueuse de la confidentialité par un exécutable. Pour donner une idée du fonctionnement de base d'un DON, la figure 1 montre conceptuellement comment un DON peut être utilisé pour envoyer des rapports à un blockchain et ainsi obtenir la fonctionnalité oracle traditionnelle et existante. Les DON peuvent cependant fournir de nombreuses fonctionnalités supplémentaires, au-delà 1La « triade CIA » de la sécurité de l’information [123, p. 26, §2.3.5].Les réseaux existants de Chainlink. Par exemple, dans la structure générale de la figure 1, l'exécutable pourrait enregistrer les données récupérées sur le prix des actifs sur le DON, en utilisant ces données pour calculer, par exemple, une moyenne finale pour ses rapports. Figure 1 : Figure conceptuelle montrant à titre d'exemple comment un réseau Oracle décentralisé peut réaliser la fonctionnalité de base oracle, c'est-à-dire relayer des données hors chaîne vers un contrat. Un l'exécutable utilise des adaptateurs pour récupérer les données hors chaîne, sur lesquelles il calcule, envoyant la sortie via un autre adaptateur vers une cible blockchain. (Les adaptateurs sont initiés par le code dans le DON, représenté par des petites cases bleues ; les flèches indiquent la direction du flux de données pour cette exemple particulier.) L'exécutable peut en outre lire et écrire sur le DON local stockage pour conserver l’état et/ou communiquer avec d’autres exécutables. La mise en réseau, le calcul et le stockage flexibles dans les DON, tous représentés ici, permettent une multitude de nouvelles candidatures. Un avantage majeur des DON est leur capacité à démarrer de nouveaux services blockchain. DONs sont un véhicule grâce auquel les réseaux oracle existants peuvent rapidement mettre en place des applications de service cela nécessiterait aujourd’hui la création de réseaux spécialement conçus. Nous donnons un certain nombre de des exemples de telles applications dans la section 4. Dans la section 3, nous fournissons plus de détails sur les DON, décrivant leurs capacités dans termes de l'interface qu'ils présentent aux développeurs et aux utilisateurs. 1.2 Sept objectifs de conception clés Nous passons ici brièvement en revue les sept axes clés énumérés ci-dessus pour l’évolution de Chainlink, à savoir :Hybrid smart contracts: Au cœur de notre vision pour Chainlink se trouve l'idée d'une sécurité sécurisée combinant des composants en chaîne et hors chaîne dans des smart contract. We refer to contracts concrétiser cette idée sous la forme de smart contract hybrides ou de contrats hybrides.2 Les blockchains jouent et continueront de jouer deux rôles essentiels dans les services décentralisés écosystèmes : ils sont tous deux les lieux où la propriété des cryptomonnaies est représentée. et des points d’ancrage solides pour les services décentralisés. Les contrats intelligents doivent donc être représentés ou exécutés en chaîne, mais leurs capacités en chaîne sont sévèrement limitées. Purely le code des contrats en chaîne est lent, coûteux et insulaire, incapable de bénéficier du monde réel données et une variété de fonctionnalités qui sont intrinsèquement irréalisables sur la chaîne, y compris diverses formes de calcul confidentiel, la génération de (pseudo) hasard sécurisé contre mineur / manipulation validator, etc. Pour que les smart contract réalisent leur plein potentiel, il faut donc des smart contract. être architecturé en deux parties : une partie en chaîne (que nous désignons généralement par SC) et une partie hors chaîne, un exécutable exécuté sur un DON (que nous désignons généralement par exec). L'objectif est de parvenir à une composition sécurisée de fonctionnalités en chaîne avec le multiplicité de services hors chaîne que DON visent à fournir. Together, the two parts constituer un contrat hybride. Nous présentons l'idée conceptuellement dans la figure 2. Déjà aujourd'hui, Les services Chainlink3 tels que les flux de données et les VRF permettent des performances autrement irréalisables smart contract applications, allant des DeFi aux NFT générés équitablement jusqu'à l'assurance décentralisée, comme premiers pas vers un cadre plus général. As Chainlink services développez-vous et devenez plus performant selon notre vision dans ce livre blanc, tout comme sera la puissance des systèmes smart contract sur tous les blockchain. Nos six autres objectifs clés de ce livre blanc peuvent être considérés comme agissant dans le service du premier, celui des contrats hybrides. Ces focus consistent à supprimer les éléments visibles complexité des contrats hybrides, créant des services hors chaîne supplémentaires qui permettent construction de contrats hybrides toujours plus performants et, dans le cas d’une minimisation de la confiance, renforcement des propriétés de sécurité obtenues par les contrats hybrides. We leave the idea de contrats hybrides implicites dans une grande partie du document, mais toute combinaison de La logique MAINCHAIN avec un DON peut être considérée comme un contrat hybride. Faire abstraction de la complexité : Les DON sont conçus pour utiliser des systèmes décentralisés des systèmes faciles pour les développeurs et les utilisateurs en éliminant les machines souvent complexes derrière la gamme de services puissante et flexible de DON. Services Chainlink existants ont déjà cette fonctionnalité. Par exemple, les flux de données dans Chainlink présentent aujourd'hui des interfaces en chaîne qui n'obligent pas les développeurs à se soucier des détails au niveau du protocole, comme les moyens par lesquels l'OCR applique les rapports de consensus entre un 2L'idée d'une composition de contrat en chaîne/hors chaîne est apparue précédemment dans divers contextes contraints. formulaires, par exemple, les systèmes de couche 2, les blockchains [80] basés sur TEE, etc. Notre objectif est de prendre en charge et de généraliser ces approches et garantir qu'elles peuvent englober l'accès aux données hors chaîne et d'autres oracle clés services. Les services 3Chainlink comprennent une variété de services et de fonctionnalités décentralisés disponibles via le réseau. Ils sont proposés par les nombreux opérateurs de nœuds regroupés en différents réseaux oracle across the ecosystem.Figure 2 : Figure conceptuelle illustrant la composition des contrats en chaîne/hors chaîne. Un hybride smart contract 3⃝se compose de deux composants complémentaires : un en chaîne composant SC 1⃝, résident sur un blockchain, et un composant hors chaîne exec 2⃝ qui s'exécute sur un DON. Le DON sert également de pont entre les deux composants comme connecter le contrat hybride à des ressources hors chaîne telles que des services Web, d'autres blockchains, stockage décentralisé, etc. ensemble décentralisé de nœuds. Les DON vont encore plus loin dans le sens où ils élargissent la gamme de services pour lesquels Chainlink peut offrir aux développeurs une couche d'abstraction avec accompagnant des interfaces rationalisées pour des services de haut niveau. Nous présentons plusieurs exemples d'application dans la section 4 qui mettent en évidence cette approche. Nous envisageons, par exemple, que les entreprises utilisent les DON comme forme de middleware sécurisé pour connecter leurs systèmes existants aux blockchain. (Voir la section 4.2.) Cette utilisation des DON élimine la complexité de la dynamique générale blockchain (frais, réorganisations, etc.). C'est aussi supprime les fonctionnalités de blockchain spécifiques, permettant ainsi aux entreprises de connecter leurs systèmes existants à une gamme toujours plus large de systèmes blockchain sans un besoin d'expertise spécialisée dans ces systèmes ou, plus généralement, dans le développement de systèmes décentralisés. A terme, notre ambition est de pousser le degré d'abstraction atteint par Chainlink au point de mettre en œuvre ce que nous appelons une métacouche décentralisée. Une telle couche ferait abstraction de la distinction en chaîne/hors chaîne pour toutes les classes de développeurs et les utilisateurs de DApps, permettant une création et une utilisation transparentes de services décentralisés.Pour simplifier le processus de développement, les développeurs pourraient spécifier la fonctionnalité DApp dans la métacouche en tant qu'application virtuelle dans un modèle de machine unifié. Ils pourraient puis utilisez un compilateur metallayer décentralisé pour instancier automatiquement le DApp comme un ensemble de fonctionnalités décentralisées interopérables couvrant blockchains, DONs et prestations externes. (L'un de ces services externes pourrait être un système d'entreprise, ce qui rendrait la couche méta utile pour les applications impliquant des systèmes d'entreprise existants.) la compilation s'apparente à la façon dont les compilateurs et les kits de développement logiciel (SDK) modernes aider les programmeurs généralistes à utiliser tout le potentiel du matériel hétérogène des architectures composées d'un CPU à usage général et de matériel spécialisé comme des GPU, des accélérateurs d’apprentissage automatique ou des enclaves de confiance. La figure 3 présente cette idée à un niveau conceptuel. Les smart contract hybrides sont une première étape vers cette vision et vers un concept que nous appelons méta-contrats. Les méta-contrats sont des applications codées de manière décentralisée métacouche et englobent implicitement la logique en chaîne (smart contract), ainsi que le calcul hors chaîne et la connectivité entre divers blockchain et hors chaîne existants prestations. Étant donné le besoin de prise en charge du langage et du compilateur, de nouveaux modèles de sécurité et harmonisation conceptuelle et technique de technologies disparates, mais réalisation d'un véritable métacouche décentralisé est un objectif ambitieux auquel nous aspirons depuis longtemps horizon temporel. Il s’agit néanmoins d’un modèle idéal utile à garder à l’esprit lors de la lecture ce document, non détaillé ici, mais sur lequel nous prévoyons de nous concentrer dans nos futurs travaux sur Chainlink. Mise à l'échelle : Un objectif d'une importance primordiale dans nos conceptions évolutives est de permettre au Réseau Chainlink pour répondre aux besoins d’évolutivité croissants de l’écosystème blockchain. La congestion du réseau devenant un problème récurrent dans les systèmes sans autorisation existants. blockchains [86], de nouvelles conceptions blockchain plus performantes entrent en service, par exemple, [103, 120, 203], ainsi que des technologies complémentaires de mise à l'échelle de couche 2, par exemple [5, 12, 121, 141, 169, 186, 187]. Les services Oracle doivent atteindre des latences et des débits qui répondent aux exigences de performances de ces systèmes tout en minimisant les frais en chaîne (par exemple, les coûts du gaz) pour les opérateurs contractuels et les utilisateurs ordinaires. Avec DONs, Chainlink la fonctionnalité vise à aller plus loin et à offrir des performances suffisamment élevées pour les systèmes purement Web. Les DON tirent une grande partie de leurs gains de performances de leur utilisation de protocoles de consensus rapides, basés sur des comités ou sans autorisation, qu'ils combinent avec les blockchain. ils soutiennent. Nous nous attendons à ce que de nombreux DON avec des configurations différentes fonctionnent en parallèle ; différents DApp et utilisateurs peuvent naviguer dans les compromis dans les choix consensuels sous-jacents selon les exigences de leur application. Les DON peuvent être considérés en fait comme des technologies de couche 2. Nous nous attendons à ce que parmi d'autres services, DONs prendront en charge le Transaction Execution Framework (TEF), qui facilite l'intégration efficace des DON et donc des oracle avec d'autres systèmes de couche 2 : par exemple, rollups, systèmes qui regroupent les transactions hors chaîne pour atteindre améliorations des performances. Nous introduisons le TEF dans la section 6.

Figure 3 : Figure conceptuelle montrant la réalisation idéale d'une métacouche décentralisée. Pour facilité de développement, un développeur spécifie une DApp, surlignée en rose, comme une application virtuelle. application dans un modèle de machine unifié. Un compilateur metallayer décentralisé génère automatiquement les fonctionnalités d'interopérabilité correspondantes : smart contracts (notées par SC), la logique (notée exec) sur les DON, les adaptateurs se connectant aux services externes cibles, etc., comme indiqué en surbrillance jaune. La figure 4 montre conceptuellement comment les DON améliorent la mise à l'échelle de blockchain (smart contract). en concentrant le traitement des transactions et des rapports oracle hors chaîne, plutôt que sur chaîne. Ce changement dans le lieu principal de calcul réduit la latence des transactions et frais tout en augmentant le débit des transactions. Confidentialité : Les blockchains offrent une transparence sans précédent pour les smart contract et les applications qu'elles réalisent. Mais il existe une tension fondamentale entre transparence et confidentialité. Aujourd’hui, par exemple, les échanges décentralisés des utilisateursFigure 4 : Figure conceptuelle montrant comment les réseaux Oracle décentralisés améliorent mise à l'échelle des smart contract compatibles blockchain. Figure A ⃝montre un oracle conventionnel architecture. Les transactions sont envoyées directement au blockchain, tout comme les rapports oracle. Ainsi, le blockchain, surligné en jaune, est le principal lieu de traitement des transactions. La figure B⃝montre l'utilisation d'un DON pour prendre en charge les contrats sur le blockchain. Un DON l'exécutable traite les transactions ainsi que les données provenant de systèmes externes et de transferts résultats (par exemple, transactions groupées ou changements d'état du contrat résultant des effets des transactions) vers le blockchain. Le DON, surligné en jaune, est donc le principal lieu de traitement des transactions. les actions sont enregistrées en chaîne, ce qui facilite le suivi du comportement d'échange, mais aussi rendre publiquement visibles les transactions financières des utilisateurs. De même, les données relayées vers smart les contrats restent en chaîne. Cela rend ces données facilement vérifiables, mais agit comme un élément dissuasif pour les fournisseurs de données souhaitant fournir aux smart contract des données sensibles ou données propriétaires. Nous pensons que les réseaux oracle joueront un rôle central dans le catalyseur de la prochaine génération des systèmes qui combinent la transparence innée des blockchain avec de nouvelles protections de confidentialité. Dans cet article, nous montrons comment ils y parviendront en utilisant trois approches principales : • Adaptateurs préservant la confidentialité : deux technologies avec déploiement planifié dans les réseaux de Chainlink, DECO [234] et Town Crier [233], permettent aux nœuds oracle de récupérer les données des systèmes hors chaîne de manière à protéger la confidentialité et les données des utilisateurs confidentialité. Ils joueront un rôle clé dans la conception des adaptateurs pour les DON. (Voir la section 3.6.2 pour plus de détails sur ces deux technologies.) • Calcul confidentiel : les DON peuvent simplement cacher leur calcul aux blockchain fiables. Grâce à des calculs multipartites sécurisés et/ou à des environnements d'exécution fiables, une confidentialité plus forte est également possible dans laquelle les nœuds DON calculer sur des données sur lesquelles ils n’ont eux-mêmes pas de visibilité.

• Prise en charge des systèmes confidentiels de couche 2 : le TEF est conçu pour prendre en charge une variété de systèmes de couche 2, dont beaucoup utilisent des preuves de connaissance nulle pour fournir diverses formes de confidentialité des transactions. Nous discutons de ces approches dans la section 3 (avec des détails supplémentaires dans la section 6, l'annexe B.1 et l'annexe B.2). La figure 5 présente une vue conceptuelle de la manière dont les données sensibles peuvent circuler depuis des sources externes vers un smart contract au moyen d'adaptateurs préservant la confidentialité et calcul confidentiel dans un DON. Figure 5 : Schéma conceptuel des opérations de préservation de la confidentialité dans un DON sur données sensibles (surlignées en jaune). Données sources sensibles (cercles noirs) sur le Web les serveurs sont extraits vers le DON à l'aide d'adaptateurs préservant la confidentialité (lignes bleues à double flèche). Le DON reçoit des données dérivées (cercles creux) de ces adaptateurs : le résultat de l'application d'une fonction ou, par exemple, du partage de secrets, à la source sensible données. Un exécutable sur le DON peut appliquer un calcul confidentiel aux données dérivées pour construire un rapport (double cercle), qu'il envoie via un adaptateur au blockchain. Nous pensons que des outils puissants de gestion des données confidentielles ouvriront la voie à toute une gamme d'applications. Parmi ceux-ci figurent la finance privée décentralisée (et centralisée), l'identité décentralisée, les prêts en chaîne basés sur le crédit et des solutions plus efficaces et plus efficaces. des protocoles conviviaux de connaissance du client et d’accréditation, comme nous l’expliquons dans la section 4. Équité des ordres pour les transactions : Les designs blockchain d'aujourd'hui ont un petit côté sale secret de polichinelle : Ils sont centralisés de manière éphémère. Les mineurs et les validator peuvent commander des trans-actions comme ils le souhaitent. L'ordre des transactions peut également être manipulé par les utilisateurs comme en fonction des frais de réseau qu'ils paient (par exemple, les prix du gaz en Ethereum) et à certains dans une large mesure en tirant parti de connexions réseau rapides. Une telle manipulation peut, par exemple par exemple, prendre la forme d'un front-running, dans lequel un acteur stratégique tel qu'un mineur observe la transaction d'un utilisateur et insère sa propre transaction d'exploitation dans une transaction antérieure position dans le même bloc – voler efficacement de l’argent à l’utilisateur en tirant parti de la connaissance préalable de la transaction de l’utilisateur. Par exemple, un robot peut passer un ordre d'achat avant celui d’un utilisateur. Elle peut alors profiter de la hausse du prix des actifs induite par la le métier de l’utilisateur. Certains robots sont à l'avant-garde et nuisent aux utilisateurs ordinaires (analogue à la haute fréquence) le trading à Wall Street – est déjà répandu et bien documenté [90], tout comme le sont les autres des attaques telles que le back-running [159] et la simulation de transactions automatisées [195]. Des propositions visant à systématiser l’exploitation des commandes par les mineurs ont même fait surface récemment [110]. Les technologies de couche 2 telles que les rollup ne résolvent pas le problème, mais se contentent de recentraliser commande, en le plaçant entre les mains de l'entité qui crée un rollup. L'un de nos objectifs est d'introduire dans Chainlink un service appelé Fair Sequencing. Services (FSS) [137]. FSS aide les concepteurs smart contract à garantir une commande équitable pour leurs transactions et éviter les attaques de front, de back-running et associées sur les transactions des utilisateurs ainsi que sur d'autres types de transactions, telles que la transmission de rapports oracle. FSS permet à un DON de mettre en œuvre des idées telles que la notion rigoureuse et temporelle d'ordre équitable introduite dans [144]. Comme avantage accessoire, le FSS peut également réduire la consommation du réseau des utilisateurs. frais (par exemple, les frais d’essence). En bref, dans FSS, les transactions passent par le DON, plutôt que de se propager directement vers une cible smart contract. Le DON commande les transactions puis les transmet les au contrat. Figure 6 : Exemple de la manière dont le FSS est bénéfique. Figure A ⃝montre comment un mineur, exploitant son pouvoir centralisé d'ordonner des transactions, peut échanger une paire de transactions : transaction 1⃝ arrive avant 2⃝, mais le mineur le séquence après 2⃝. En revanche, la figure B⃝montre comment un DON décentralise le processus de commande entre les nœuds DON. Si un quorum de les nœuds honnêtes reçoivent 1⃝avant 2⃝, le FSS fait apparaître 1⃝ avant 2⃝sur la chaîne— empêcher la réorganisation des mineurs en attachant des numéros de séquence exécutoires au contrat. La figure 6 compare l'exploitation minière standard avec FSS. Il montre comment dans le minage standard,le processus de commande des transactions est centralisé chez le mineur et donc soumis à manipulation, telle que réorganiser une paire de transactions par rapport à leur arrivée fois. En revanche, dans FSS, le processus est décentralisé entre les nœuds DON. En supposant un quorum de nœuds honnêtes, FSS aide à appliquer des politiques telles que l'ordre temporel des transactions, réduisant ainsi les possibilités de manipulation par les mineurs et d’autres entités. De plus, étant donné que les utilisateurs n'ont pas besoin de rivaliser pour obtenir des commandes préférentielles basées sur le prix du gaz, ils peuvent payer des prix du gaz relativement bas (alors que les transactions du DON peuvent être regroupées pour les économies de gaz). Minimisation de la confiance : Notre objectif général dans la conception des DON est de faciliter une couche de support fiable pour les smart contract et autres systèmes dépendants de oracle au moyen de la décentralisation, d’outils cryptographiques et de garanties cryptoéconomiques. Un DON lui-même est décentralisé et les utilisateurs peuvent choisir parmi n'importe quel DON disponible qui prend en charge la chaîne principale sur laquelle ils souhaitent opérer ou générer des DON supplémentaires avec des comités de nœuds en qui ils ont confiance. Cependant, pour certaines applications, en particulier les smart contract, les utilisateurs de Chainlink peuvent privilégier un modèle de confiance qui traite la chaîne principale soutenue par un DON comme plus digne de confiance que le DON lui-même. Pour ces utilisateurs, nous avons déjà ou prévoyons d'intégrer dans le architecture du réseau Chainlink un certain nombre de mécanismes permettant de conclure des contrats sur une chaîne principale pour renforcer les garanties de sécurité fournies par les DON, tandis qu'au en même temps, en appliquant également des protections contre la possibilité de sources de données corrompues tels que les serveurs Web à partir desquels le DON obtient des données. Nous décrivons ces mécanismes dans la section 7. Ils se répartissent en cinq rubriques principales : • Authentification de la source de données : outils permettant aux fournisseurs de données de signer numériquement leurs données et renforcer ainsi la chaîne de contrôle entre l'origine et contrat de confiance. • Rapports minoritaires DON : indicateurs émis par un sous-ensemble minoritaire de nœuds DON qui observe des malversations majoritaires dans le DON. • Garde-corps : logique sur une chaîne principale qui détecte les conditions anormales et les pauses ou interrompt l'exécution du contrat (ou invoque d'autres mesures correctives). • Gouvernance minimisant la confiance : utilisation de mises à jour à publication progressive pour faciliter l'inspection communautaire, ainsi que d'interventions d'urgence décentralisées pour des interventions rapides. réponse aux pannes du système. • Authentification d'entité décentralisée : utilisation d'une infrastructure à clé publique (PKI) pour identifier les entités du réseau Chainlink. La figure 7 présente un schéma conceptuel de nos objectifs de minimisation de la confiance. Sécurité (cryptoéconomique) incitative : La décentralisation de la génération de rapports sur les nœuds oracle permet de garantir la sécurité même lorsque certains nœuds sont corrompus.

Figure 7 : Représentation conceptuelle de l'objectif de minimisation de la confiance de Chainlink, qui consiste à minimiser le besoin des utilisateurs d'un comportement correct du DON et des sources de données telles que le Web serveurs. Les surlignages jaunes dans la figure indiquent des loci de minimisation de la confiance : le DON et ensembles individuels ou minoritaires de serveurs Web. Les surlignages roses indiquent les composants du système qui sont très fiables par hypothèse : des contrats sur le blockchain et une majorité de serveurs Web, c'est-à-dire les serveurs Web dans leur ensemble. Il est tout aussi important de s’assurer que les nœuds bénéficient d’une incitation financière à se comporter correctement. Jalonnement, c'est-à-dire exiger que les nœuds fournissent des dépôts de LINK et slashing (confiser) ces dépôts en cas de mauvaise conduite, jouera un rôle clé dans Chainlink. Il s'agit d'un modèle d'incitation important déjà utilisé dans un certain nombre de blockchain, par exemple, [81, 103, 120, 204]. Cependant, le jalonnement dans Chainlink semble très différent de celui de staking en mode autonome. blockchains. Le jalonnement dans blockchains vise à empêcher les attaques contre le consensus. Il a un objectif différent dans Chainlink : garantir la livraison en temps opportun de rapports oracle corrects. Un système staking bien conçu pour un réseau oracle devrait rendre les attaques telles que la corruption non rentable pour un adversaire, même lorsque la cible est un smart contract avec un valeur monétaire. Dans cet article, nous présentons une approche générale de staking en Chainlink avec trois clés innovations :1. Un modèle accusatoire puissant qui englobe les attaques négligées dans les approches. Un exemple est ce que nous appelons la corruption potentielle. C'est une forme de corruption qui détermine quels nœuds reçoivent des pots-de-vin sur une base conditionnelle, par exemple, offre des pots-de-vin garantis à l'avance aux nœuds qu'un mécanisme staking sélectionne à aléatoire pour des rôles particuliers (comme le déclenchement de l'évaluation du rapport). 2. Impact super-linéaire staking, signifiant officieusement que pour réussir, un adversaire doit disposer d'un budget de milliards de dollars supérieur aux dépôts combinés de tous les oracle. nœuds. Plus précisément, nous entendons qu'en fonction de n, \(B(n) ≫\)dn dans un réseau de n nœuds oracle chacun avec un montant de dépôt fixe $d (plus formellement, \(B(n) is asymptotically larger in n than \)dn). La figure 8 donne une vue conceptuelle de cette propriété. 3. Le cadre d'incitation implicite (IIF), un modèle d'incitation que nous avons conçu pour englober des incitations empiriquement mesurables au-delà des dépôts explicites staking fonds, y compris les futures opportunités de frais des nœuds. L'IIF étend la notion de mise au-delà des dépôts de nœuds explicites. Figure 8 : Diagramme conceptuel illustrant la mise à l'échelle super-linéaire dans Chainlink staking. Le le pot-de-vin $B(n) requis par un adversaire croît plus vite en n que les dépôts combinés $dn de tous les nœuds oracle. Nous montrons comment l'impact IIF et l'impact super-linéaire staking induisent ensemble ce que nous appeler un cercle vertueux de sécurité économique pour les réseaux oracle. Lorsque de nouveaux utilisateurs entrent

le système, augmentant les revenus potentiels futurs liés à l'exécution de nœuds Chainlink, le le coût marginal de la sécurité économique diminue pour les utilisateurs actuels et futurs. Dans un régime de demande élastique, cette diminution du coût incite des utilisateurs supplémentaires à utiliser le réseau, perpétuant continuellement l’adoption dans un cercle vertueux continu. Remarque : Bien que ce livre blanc présente des éléments importants de notre vision de l'évolution de Chainlink, il est informel et comprend peu de spécificités techniques détaillées. Nous prévoyons de publier des documents techniques ciblés sur des fonctionnalités et des approches supplémentaires au fur et à mesure de leur évolution. Par ailleurs, il est important de souligner que de nombreux éléments de la vision présentée ici (améliorations de mise à l'échelle, technologies de confidentialité, FSS, etc.) peuvent et seront déployé sous forme préliminaire avant même que les DON avancés ne deviennent une fonctionnalité de base de Chainlink. 1.3 Organisation de ce document Nous présentons notre modèle de sécurité et notre notation dans la section 2 et décrivons le système décentralisé. API Oracle Network dans la section 3. Dans la section 4, nous présentons un certain nombre d'exemples de applications pour lesquelles les DON fournissent une plate-forme de déploiement attrayante. Les lecteurs peuvent Apprenez la plupart des concepts clés de l'article en lisant jusqu'à présent. Le reste du document contient des détails supplémentaires. Nous décrivons le séquençage équitable Services (FSS) dans la section 5 et le Transaction-Execution Framework (TEF) dans la section 6. Nous décrivons notre approche de la minimisation de la confiance dans la section 7. Nous considérons certains exigences de déploiement importantes DON, à savoir le déploiement incrémentiel de fonctionnalités, l'adhésion dynamique au grand livre et la responsabilité dans la section 8. Enfin, dans la section 9, nous donnons un aperçu de notre approche en développement en matière de conception d’incitations. Nous concluons dans la section 10. Pour aider les lecteurs qui ont une familiarité limitée avec les concepts de cet article, nous fournir un glossaire à l'annexe A. Nous présentons plus de détails sur l'interface DON et les fonctionnalités dans l'Annexe B et présentent quelques exemples d'adaptateurs dans l'Annexe C. Dans l'Annexe D, nous décrivons une primitive cryptographique pour les sources de données à confiance minimisée. authentification appelée signatures fonctionnelles et introduire une nouvelle variante appelée signatures fonctionnelles discrétisées. Nous discutons de quelques considérations portant sur le comité sélection pour DONs à l’annexe F.

Modèle et objectifs de sécurité

Un réseau Oracle décentralisé est un système distribué distinct qui, nous l'espérons, être initialement mis en œuvre généralement – mais pas nécessairement – par un comité protocole de consensus et géré par un ensemble de nœuds oracle. Un DON est conçu principalement pour augmenter les capacités d'un smart contract sur une chaîne principale avec des rapports oracle et d'autres services, mais il peut fournir ces mêmes services de support à d'autres systèmes non blockchain, et n'a donc pas besoin d'être associé à une chaîne principale particulière.

Le modèle et les propriétés que nous considérons sont donc largement indépendants de l'utilisation de les applications particulières d'un DON. 2.1 Modèle architectural actuel Il est important de souligner que Chainlink n'est aujourd'hui pas un service monolithique, mais plutôt un cadre sans autorisation dans lequel il est possible de lancer des réseaux de oracle nœuds [77]. Les réseaux ont des ensembles hétérogènes d'opérateurs de nœuds et dessins. Ils peuvent également différer en termes de types de services qu'ils fournissent, ce qui peut inclure, par exemple, les flux de données, les preuves de réserves, le caractère aléatoire vérifiable, etc. Autre Les différences peuvent inclure le degré de décentralisation, la taille du réseau en termes de valeur verrouillée qu'il prend en charge et divers paramètres de niveau de service, tels que la fréquence des données et la précision. Le modèle sans autorisation de Chainlink encourage la croissance d'un écosystème dans lequel les prestataires se spécialisent dans les services qu’ils sont les plus à même de fournir à la communauté. Ceci Le modèle est susceptible d'entraîner des coûts inférieurs pour les utilisateurs et une qualité de service supérieure à celle d'un modèle. qui nécessite que tous les nœuds et réseaux fournissent une gamme complète de services, une approche qui peut facilement déboucher sur l’adoption à l’échelle du système des services représentant le moins dénominateur commun des ressources disponibles pour les nœuds. À mesure que Chainlink évolue vers des conceptions basées sur DON dans Chainlink 2.0, nous continuons à soutenir le modèle d'un cadre ouvert et sans autorisation, en gardant à l'esprit l'objectif de offrir aux utilisateurs une gamme de choix de services qui aboutissent globalement à la meilleure correspondance avec des exigences d'application particulières. 2.2 Hypothèses consensuelles Nous utilisons le terme réseau Oracle décentralisé pour englober toutes les fonctionnalités de le système oracle que nous décrivons : à la fois la structure de données que les nœuds oracle maintiennent et l'API principale superposée. Nous utilisons le terme grand livre (minuscules), noté L, pour désigner les données sous-jacentes structure maintenue par un DON et utilisée pour soutenir les services particuliers qu'elle fournit. Nous soulignons que notre framework DON ne traite pas L comme un système autonome comme a blockchain : son objectif est de prendre en charge les blockchain et d'autres systèmes. Les blockchains sont, bien sûr, une manière de réaliser un grand livre fiable, mais il en existe d’autres. Nous nous attendons DONs dans de nombreux cas pour réaliser leurs grands livres sous-jacents à l'aide de Byzantine Fault Tolerant (BFT), qui sont considérablement antérieurs aux blockchain tels que Bitcoin [174]. Nous utilisons notation et propriétés de type BFT tout au long du document pour plus de commodité, bien que nous soulignez que les DON peuvent être réalisés à l’aide de protocoles de consensus sans autorisation. Conceptuellement, un grand livre L est un tableau d'affichage sur lequel les données sont ordonnées de manière linéaire. Nous considérons généralement un grand livre comme ayant quelques propriétés clés communément attribuées à blockchains [115]. Un grand livre est : • Ajout uniquement : Les données, une fois ajoutées, ne peuvent pas être supprimées ou modifiées.• Public : Tout le monde peut lire son contenu, qui est cohérent dans le temps. vue de tous les utilisateurs.4 • Disponible : le grand livre peut toujours être écrit par des rédacteurs autorisés et lu par quiconque en temps opportun. Des propriétés alternatives sont possibles dans le grand livre pour un DON lorsqu'elles sont réalisées par un comité. Par exemple, l'accès en écriture au grand livre peut être restreint à certains utilisateurs, comme peut avoir un accès en lecture pour certaines applications, c'est-à-dire que le grand livre n'a pas besoin d'être public comme défini ci-dessus. De même, les règles du grand livre peuvent permettre la modification ou la suppression des données. Nous ne le faisons pas Cependant, nous considérons explicitement de telles variantes dans cet article. La conception modulaire des DON peut prendre en charge n'importe lequel d'une grande variété de BFT modernes protocoles, par exemple, Hotstuff[231]. Le choix exact dépendra des hypothèses de confiance et caractéristiques du réseau entre les nœuds oracle. Un DON pourrait en principe alternativement utiliser un blockchain sans autorisation hautement performant pour son grand livre dans son rôle de support d'un système de couche 2 ou blockchain également évolutif. De même, l'hybridation est également possible : Le DON pourrait en principe être composé de nœuds qui sont des validator dans un réseau existant. blockchain, par exemple, dans les systèmes de preuve de participation dans lesquels les comités sont sélectionnés pour exécuter transactions, par exemple [8, 81, 120, 146, 204]. Ce mode de fonctionnement particulier nécessite que les nœuds fonctionnent à double usage, c'est-à-dire fonctionnent à la fois en tant que nœuds blockchain et DON nœuds. (Voir la section 8.2 pour une discussion sur les techniques permettant d'assurer la continuité des changements. comités et l’annexe F pour quelques mises en garde sur la sélection aléatoire des comités.) En pratique, dans les algorithmes BFT modernes, les nœuds signent numériquement les messages sur le grand livre. Nous supposons par commodité que L est associé à une clé publique pkL et que son contenu sont signés par la clé privée correspondante. Cette notation générale s'applique même lorsque les données sur L sont signées à l’aide de signatures à seuil.5 Les signatures à seuil sont pratiques, car ils permettent une identité persistante pour un DON même avec des changements d'adhésion dans les nœuds qui l'exécutent. (Voir Annexe B.1.3.) Nous supposons donc que skL est partagé en secret d'une manière (k, n)-seuil pour certains paramètres de sécurité k, par exemple k = 2f + 1 et n = 3f + 1, où f est le nombre de nœuds potentiellement défectueux. (En choisissant k dans ce De cette manière, nous nous assurons que les nœuds défectueux ne peuvent ni apprendre skL ni monter un déni de service attaque empêchant son utilisation.) Un message sur L prend la forme M = (m, z), où m est une chaîne et z un unique numéro d'index séquentiel. Le cas échéant, nous écrivons les messages sous la forme m = ⟨MessageType : charge utile⟩. Le type de message MessageType est un sucre syntaxique qui indique la fonction d'un message particulier. 4Dans les cas où un blockchain sans finalité réalise un grand livre, l'incohérence est généralement abstraite en ignorant les blocs insuffisamment profonds ou en « élaguant » [115]. 5En pratique, certaines bases de code, par exemple LibraBFT [205], une variante de Hotstuff, ont actuellement adopté des signatures multiples, plutôt que des signatures à seuil, offrant une complexité de communication réduite pour une ingénierie plus simple. Moyennant un coût supplémentaire, les nœuds oracle peuvent ajouter des signatures de seuil aux messages écrits dans L même si le protocole de consensus utilisé pour L ne les emploie pas.2.3 Notation Nous notons l'ensemble des n nœuds oracle exécutant le grand livre par O = {Oi}n je = 1. Un tel un ensemble de nœuds est souvent appelé un comité. Pour simplifier, nous supposons que l’ensemble de oracles implémentant la fonctionnalité DON, c'est-à-dire les services au-dessus de L, est identique à cela maintenant L, mais ils peuvent être distincts. On laisse pki désigner la clé publique de joueur Oi, et skiez la clé privée correspondante. La plupart des algorithmes BFT nécessitent au moins n = 3f + 1 nœuds, où f est le nombre de nœuds potentiellement défectueux ; les nœuds restants sont honnêtes, dans le sens où ils suivent le protocole exactement comme spécifié. Nous qualifions le comité O d'honnête s'il répond à ces critères exigence, c'est-à-dire qu'elle comporte plus d'une fraction des 2/3 de nœuds honnêtes. Sauf autrement dit, nous supposons que O est honnête (et un modèle statique de corruption). Nous utilisons pkO / skO de manière interchangeable avec pkL / skL, selon le contexte. On laisse σ = Sigpk[m] désigner une signature sur le message m par rapport à pk, c'est-à-dire en utilisant clé privée correspondante sk. Soit verify(pk, σ, m) →{false, true} désignant un algorithme de vérification de signature correspondant. (Nous laissons la génération de clés implicite tout au long du document.) Nous utilisons la notation S pour désigner une source de données et S pour désigner l'ensemble complet de nS sources dans un contexte donné. Nous désignons par MAINCHAIN un contrat intelligent activé blockchain soutenu par un DON. Nous utilisons le terme contrat de confiance pour désigner tout contrat intelligent. contrat sur MAINCHAIN qui communique avec un DON, et utiliser la notation SC pour désigner un tel contrat. Nous supposons généralement qu'un DON prend en charge une seule chaîne principale MAINCHAIN, bien qu'il puisse prendre en charge plusieurs de ces chaînes, comme nous le montrons dans les exemples de la section 4. A DON peut et prendra généralement en charge plusieurs contrats dépendants de MAINCHAIN. (Comme Comme indiqué ci-dessus, un DON peut également prendre en charge des services non blockchain.) 2.4 Remarque sur les modèles de confiance Comme indiqué ci-dessus, les DON peuvent être construits sur des protocoles de consensus basés sur des comités, et nous s'attendre à ce qu'ils utilisent couramment de tels protocoles. Il existe de nombreux arguments solides selon lesquels l'une des deux alternatives, blockchains basées sur un comité ou sans autorisation, fournit sécurité plus forte que l’autre. Il est important de reconnaître que la sécurité des systèmes basés sur des comités ou sans autorisation les systèmes décentralisés sont incommensurables. Compromettre un PoW ou un PoS blockchain via une attaque à 51% nécessite qu'un adversaire obtienne des ressources majoritaires de manière éphémère et potentiellement de manière anonyme, par exemple en louant de l'énergie hash dans un système PoW. Tel les attaques en pratique ont déjà touché plusieurs blockchains [200, 34]. En revanche, compromettre un système basé sur des comités signifie corrompre un nombre seuil (généralement un tiers) de ses nœuds, lorsque ces nœuds peuvent être publiquement connus, bien dotés en ressources, et des entités dignes de confiance. D’un autre côté, les systèmes basés sur des comités (ainsi que les systèmes « hybrides » sans autorisation) systèmes qui soutiennent les comités) peuvent prendre en charge plus de fonctionnalités que ce qui est strictement prévu.systèmes sans mission. Cela inclut la capacité de conserver des secrets persistants, tels que clés de signature et/ou de chiffrement : une possibilité dans nos conceptions. Nous soulignons que les DON peuvent en principe être construits au sommet d'un comité ou d'un comité. protocole de consensus sans autorisation et les déployeurs DON peuvent finalement choisir d'adopter quelle que soit l’approche. Renforcer les modèles de confiance : Une fonctionnalité clé de Chainlink aujourd'hui est la possibilité pour les utilisateurs de sélectionner les nœuds en fonction des enregistrements décentralisés de leurs historiques de performances, comme indiqué à la section 3.6.4. Le mécanisme staking et le cadre d'incitation implicite que nous introduisons dans la section 9 constituent ensemble une conception de mécanisme rigoureuse et de grande envergure. qui donnera aux utilisateurs une capacité considérablement accrue d'évaluer la sécurité des DON. Ce même cadre permettra également aux DON eux-mêmes pour appliquer diverses exigences de sécurité sur les nœuds participants et assurer le fonctionnement dans le cadre de modèles de confiance solides. Il est également possible d'utiliser les outils décrits dans ce document pour les DON afin d'appliquer des exigences particulières du modèle de confiance, telles que la conformité aux exigences réglementaires. Pour Par exemple, en utilisant les techniques décrites à la section 4.3, les nœuds peuvent présenter des preuves de caractéristiques de l'opérateur de nœud, par exemple le territoire d'exploitation, qui peuvent être utilisées pour aider faire respecter, par exemple, l'article 3 du Règlement général sur la protection des données (RGPD) (« Champ d'application territorial ») [105]. Une telle conformité peut autrement être difficile à se réunissent dans des systèmes décentralisés [45]. De plus, dans la section 7, nous discutons des plans visant à renforcer la robustesse des DON. grâce à des mécanismes de minimisation de la confiance sur les principales chaînes qu’ils soutiennent.

Interface réseau Oracle décentralisée et Ca-

pabilités Ici, nous décrivons brièvement les capacités des DON en termes de fonctionnalités simples mais puissantes. interface pour laquelle ils sont conçus. Les applications sur un DON sont composées d'exécutables et d'adaptateurs. Un exécutable est un programme dont la logique de base est un programme déterministe, analogue à un smart contract. Un exécutable est également accompagné d'un certain nombre d'initiateurs, de programmes qui appellent l'entrée points dans la logique de l'exécutable lorsque des événements prédéterminés se produisent, par exemple à certains moments (comme une tâche cron), lorsqu'un prix franchit un seuil, etc., un peu comme Keepers (voir Section 3.6.3). Les adaptateurs fournissent des interfaces vers les ressources hors chaîne et peuvent être appelés par soit les initiateurs, soit la logique de base dans les exécutables. Comme leur comportement peut en dépendre des ressources externes, des initiateurs et des adaptateurs peuvent se comporter de manière non déterministe. Nous décrivons l'interface développeur DON et le fonctionnement des exécutables et adaptateurs en termes de trois ressources généralement utilisées pour caractériser les systèmes informatiques : mise en réseau, calcul et stockage. Nous donnons un bref aperçu de chacun d’eux ressources ci-dessous et fournissez plus de détails à l’annexe B.

3.1 Réseautage Les adaptateurs sont des interfaces via lesquelles les exécutables exécutés sur un DON peuvent envoyer et recevoir des données de systèmes hors-DON. Les adaptateurs peuvent être considérés comme une généralisation de les adaptateurs utilisés dans Chainlink aujourd'hui [20]. Les adaptateurs peuvent être bidirectionnels, c'est-à-dire qu'ils ne peut pas simplement extraire, mais transmettre les données d'un DON vers un serveur Web. Ils peuvent également tirer parti protocoles distribués ainsi que des fonctionnalités cryptographiques telles que le multipartite sécurisé calcul. Figure 9 : Adaptateurs connectant un DON, noté DON1, à une gamme de ressources différentes, dont un autre DON, noté DON2, un blockchain (chaîne principale) et son mempool, stockage externe, un serveur Web et des appareils IoT (via un serveur Web). Des exemples de ressources externes pour lesquelles des adaptateurs peuvent être créés sont présentés sur la figure 9. Ils comprennent : • Blockchains : un adaptateur peut définir comment envoyer des transactions à un blockchain et comment en lire des blocs, des transactions individuelles ou un autre état. Un adaptateur peut également être défini pour le pool de mémoire d’un blockchain. (Voir la section 3.5.) • Serveurs Web : les adaptateurs peuvent définir des API via lesquelles les données peuvent être récupérées. à partir de serveurs Web, y compris les systèmes existants qui ne sont pas spécialement adaptés pour interface avec les DON. De tels adaptateurs peuvent également inclure des API pour envoyer des données à de tels serveurs. Les serveurs Web auxquels se connecte un DON peuvent servir de passerelles à des ressources supplémentaires, telles que les appareils Internet des objets (IoT).• Stockage externe : un adaptateur peut définir des méthodes de lecture et d'écriture sur le stockage. services en dehors du DON, comme un système de fichiers décentralisé [40, 188] ou un cloud stockage. • Autres DON : les adaptateurs peuvent récupérer et transmettre des données entre DON. Nous prévoyons que les déploiements initiaux de DON incluront un ensemble de blocs de construction adaptateurs pour ces ressources externes couramment utilisées et permettra en outre à DON-spécifiques adaptateurs à publier par les nœuds DON. Alors que les développeurs smart contract écrivent des adaptateurs aujourd'hui, nous nous attendons à ce qu'ils construisent des adaptateurs encore plus puissants en utilisant cette avancée fonctionnalité. Nous espérons qu'à terme, il sera possible pour les utilisateurs de créer de nouveaux adaptateurs de manière simple. manière sans autorisation. Certains adaptateurs doivent être construits de manière à garantir la persistance et la disponibilité des ressources externes contrôlées par un DON. Par exemple, le stockage cloud peut nécessitent la maintenance d’un compte de services cloud. De plus, un DON peut effectuer gestion décentralisée des clés privées pour le compte des utilisateurs (comme dans, par exemple, [160]) et/ou exécutables. Par conséquent, le DON est capable de contrôler des ressources, telles que la cryptomonnaie, qui peuvent être utilisées, par exemple, pour envoyer des transactions sur une cible blockchain. Voir l'Annexe B.1 pour plus de détails sur les adaptateurs DON, ainsi que l'Annexe C pour quelques exemples d'adaptateurs. 3.2 Calcul Un exécutable est l'unité de code de base sur un DON. Un exécutable est une paire exec = (logique, initialisation). Ici, la logique est un programme déterministe avec un certain nombre d'entrées désignées points (logic1, logic2, . . . , logicℓ) et init est un ensemble d'initiateurs correspondants (init1, init2, . . . , inite). Pour garantir la pleine auditabilité du DON, la logique d'un exécutable utilise le grand livre sous-jacent L pour toutes les entrées et sorties. Ainsi, par exemple, tout adaptateur les données servant d’entrée à un exécutable doivent être stockées en premier sur L. Initiateurs : Les initiateurs de Chainlink provoquent aujourd'hui des exécutions de tâches dépendantes des événements sur Chainlink nœuds [21]. Les initiateurs des DON fonctionnent à peu près de la même manière. Un initiateur DON, cependant, est spécifiquement associé à un exécutable. Un initiateur peut dépendre sur un événement ou un état externe, sur l'heure actuelle ou sur un prédicat sur l'état DON. En raison de leur dépendance aux événements, les initiateurs peuvent bien entendu se comporter de manière non déterministe. (tout comme bien sûr les adaptateurs). Un initiateur peut s'exécuter au sein de nœuds DON individuels et il n'est donc pas nécessaire de compter sur un adaptateur. (Voir l'exemple 1 ci-dessous.) Les initiateurs sont une fonctionnalité importante qui distingue les exécutables des smart contract. Parce qu'un exécutable peut s'exécuter en réponse à un initiateur, il peut fonctionner efficacement de manière autonome, comme bien sûr par extension un contrat hybride intégrant l’exécutable. Aujourd'hui, une forme d'initiateurs sont les Chainlink Keepers, qui assurent les transactionsdes services d'automatisation, déclenchant l'exécution de smart contract, comme la liquidation de prêts sous-garantis et l'exécution de transactions à ordre limité, sur la base des rapports oracle. Idéalement, les initiateurs des DON peuvent également être considérés comme un moyen de spécifier le les contrats de service qui s'appliquent à un exécutable, car ils définissent les circonstances dans que le DON doit l'appeler. L'exemple suivant illustre le fonctionnement des initiateurs dans un exécutable : Exemple 1 (flux de prix déclenché par un écart). Un smart contract SC peut nécessiter un nouveau données d'information sur les prix (voir la section 3.6.3) chaque fois qu'il y a un changement substantiel, par exemple 1 %, dans le taux de change entre une paire d’actifs, par exemple ETH-USD. Prix sensible à la volatilité les flux sont pris en charge dans Chainlink aujourd'hui, mais il est instructif de voir comment ils peuvent être réalisé sur un DON au moyen d'un execfeed exécutable. L'exécutable execfeed maintient le prix ETH-USD le plus récent r sur L, dans le forme d'une séquence de ⟨NewPrice : j, r⟩entries, où j est un indice incrémenté de each price update. Un initiateur init1 amène chaque nœud Oi à surveiller le prix actuel ETH-USD pour des écarts d'au moins 1 % par rapport au prix r le plus récemment enregistré avec l'indice j. Upon détection d'un tel écart, Oi écrit sa vue actuelle ri du nouveau prix sur L en utilisant une entrée de la forme ⟨PriceView : i, j + 1, ri⟩. Un deuxième initiateur init2 se déclenche lorsqu'au moins k de telles entrées PriceView avec un nouveau prix les valeurs de l'index j + 1 créées par des nœuds distincts se sont accumulées sur L. Ensuite, init2 invoque une logique de point d'entrée2 pour calculer la médiane ρ des k premières valeurs priceview fraîches et valides et écrit une nouvelle valeur ⟨NewPrice : j + 1, ρ⟩to L . (Operationally, nodes peuvent se relayer en tant qu'écrivains désignés.) Un troisième initiateur, init3, surveille les entrées NewPrice sur L. Chaque fois qu'un nouveau rapport ⟨NewPrice : j, r⟩apparaît là, il invoque une logique de point d'entrée3 qui pousse (j, r) vers SC using an adapter. Comme nous l'avons noté, un exécutable est similaire dans ses capacités à un smart contract. Outre ses performances plus élevées, il diffère d'un contrat de chaîne principale typique. in two essential ways: 1. Confidentialité : un exécutable peut effectuer des calculs confidentiels, c'est-à-dire qu'un programme secret peut traiter des entrées en texte clair, ou qu'un programme publié peut traiter des entrées en texte clair. données d'entrée secrètes, ou une combinaison des deux. Dans un modèle simple, les données secrètes peuvent être accessible par les nœuds DON, qui masquent les résultats intermédiaires et ne divulguent que valeurs traitées et désinfectées vers MAINCHAIN. Il est également possible de dissimuler des données sensibles aux DON eux-mêmes : les DON sont destinés à prendre en charge des approches telles que comme le calcul multipartite, par exemple [42, 157], et les environnements d'exécution fiables (TEE) [84, 133, 152, 229] à cet effet.6 6Par extension, garder secrets les exécutables eux-mêmes vis-à-vis des nœuds DON est également possible, bien que cela ne soit pratique aujourd'hui que pour les exécutables non triviaux utilisant des TEE.2. Rôle de support : un exécutable est destiné à prendre en charge les smart contract sur un serveur principal. chaîne, plutôt que de les remplacer. Un exécutable a plusieurs limitations qu'un smart contract ne : (a) Modèle de confiance : un exécutable fonctionne dans le modèle de confiance défini par le DON : Sa bonne exécution repose sur le comportement honnête de O. (Un principal La chaîne peut cependant fournir des garde-fous contre les malversations DON, car discuté à la section 7.3.) (b) Accès aux actifs : un DON peut contrôler un compte sur un blockchain - et donc contrôler les actifs dessus via un adaptateur. Mais un DON ne peut pas faire autorité représentent les actifs créés sur une chaîne principale, par exemple Ether ou ERC20 tokens, puisque leur chaîne d'origine conserve le registre faisant autorité de leur propriété. (c) Cycle de vie : les DON peuvent être installés intentionnellement avec des durées de vie limitées, comme défini par des accords de niveau de service en chaîne entre DONs et les propriétaires de contrats de confiance. Les blockchains, en revanche, sont censées fonctionner comme systèmes d’archives permanentes. Voir l'annexe B.2 pour plus de détails sur le calcul DON. 3.3 Stockage En tant que système basé sur un comité, un DON peut stocker des quantités modérées de données de manière persistante sur L à un coût bien inférieur à un blockchain sans autorisation. De plus, via des adaptateurs, Les DON peuvent faire référence à des systèmes décentralisés externes pour le stockage de données, par exemple Filecoin [85], et peut ainsi connecter de tels systèmes aux smart contract. Cette option est particulièrement Les données en masse sont attrayantes comme moyen de résoudre le problème omniprésent du « ballonnement » dans Systèmes blockchain. Les DON peuvent ainsi stocker des données localement ou en externe pour les utiliser dans leurs services spécifiquement pris en charge. Un DON peut en outre utiliser ces données de manière confidentielle, calcul sur des données qui sont : (1) partagées en secret entre les nœuds DON ou cryptées sous une clé gérée par les nœuds DON de manière adaptée au calcul multipartite sécurisé ou un cryptage partiel ou totalement homomorphe ; ou (2) protégé à l'aide d'une exécution fiable environnement. Nous nous attendons à ce que les DON adoptent un modèle simple de gestion de la mémoire commun à Systèmes de contrats intelligents : un exécutable ne peut écrire que dans sa propre mémoire. Exécutables peut cependant lire dans la mémoire d'autres exécutables. Voir l'annexe B.3 pour plus de détails sur le stockage DON. 3.4 Cadre d'exécution de transactions (TEF) Les DON sont destinés à prendre en charge les contrats sur une chaîne principale MAINCHAIN (ou sur plusieurs chaînes principales). Le Transaction-Execution Framework (TEF), discuté en détaildans la section 6, est une approche générale de l’exécution efficace d’un contrat. SC sur MAINCHAIN et un DON. Le TEF est destiné à prendre en charge le FSS et la couche 2 technologies – simultanément, si vous le souhaitez. En effet, il est susceptible de servir de véhicule principal pour l'utilisation du FSS (et pour cette raison, nous ne discuterons pas davantage du FSS dans cette section). En bref, dans TEF un contrat cible original SC conçu ou développé pour MAINCHAIN est refactorisé dans un contrat hybride. Cette refactorisation produit les deux éléments du contrat hybride : un contrat MAINCHAIN SCa auquel nous faisons référence pour plus de clarté dans le cadre des TEF en tant que contrat d'ancrage et exécutable sur un DON. Le contract SCa conserve les actifs des utilisateurs, exécute des transitions d'état faisant autorité et également fournit des garde-corps (voir section 7.3) contre les défaillances du DON. Les exécutables séquence les transactions et fournit les données oracle associées à celles-ci. Il peut regrouper transactions pour SCa de différentes manières, par exemple en utilisant des preuves de validité ou des rollup optimistes, exécution confidentielle par les DON, etc. Nous prévoyons de développer des outils permettant aux développeurs de partager facilement un contrat. SC écrit dans un langage de haut niveau en morceaux de logique MAINCHAIN et DON, SCa et respectivement, qui composent de manière sécurisée et efficace. Utiliser TEF pour intégrer des schémas de transactions hautes performances avec des performances élevées oracles fait partie intégrante de notre approche de mise à l'échelle oracle. 3.5 Services de pool de mémoire Une fonctionnalité importante de la couche application que nous avons l'intention de déployer sur les DON en support du FSS et du TEF sont des services Mempool (MS). MS peut être considéré comme un adaptateur, mais avec un support de première classe. MS prend en charge le traitement des transactions compatible avec les anciens systèmes. Dans cette utilisation, MS ingère à partir du pool mémoire d'une chaîne principale les transactions destinées à un contrat cible SC sur MAINCHAIN. MS transmet ensuite ces transactions à un exécutable sur le DON, où ils sont traités de la manière souhaitée. Les données MS peuvent être utilisées par le DON pour composer des transactions qui peuvent ensuite être transmises directement au SC à partir du DON ou à un autre contrat qui appelle SC. Par exemple, le DON peut transférer des transactions récoltés via MS, ou il peut utiliser les données MS pour fixer les prix du gaz pour les transactions auxquelles il envoie CHAÎNE PRINCIPALE. Parce qu'il surveille le pool de mémoire, MS peut obtenir des transactions des utilisateurs interagissant directement avec SC. Ainsi les utilisateurs peuvent continuer à générer leurs transactions en utilisant logiciels hérités, c'est-à-dire des applications ignorant l'existence de MS et configurées par MS contrats. (Dans ce cas, SC doit être modifié pour ignorer les transactions d'origine et n'acceptez que ceux traités par le MS, afin d'éviter un double traitement.) A utiliser avec un contrat cible SC, MS peut être utilisé avec FSS et/ou le TEF.3.6 Tremplins : capacités Chainlink existantes 3.6.1 Rapports hors chaîne (OCR) Le reporting hors chaîne (OCR) [60] est un mécanisme dans Chainlink pour l'agrégation et la transmission des rapports oracle à un SC de contrat de confiance. Récemment déployé au prix de Chainlink réseaux d'alimentation, il représente une première étape sur la voie des DON complets. À la base, OCR est un protocole BFT conçu pour fonctionner de manière partiellement synchrone. réseau. Il assure la vivacité et l'exactitude en présence de f < n/3 arbitrairement nœuds défectueux, garantissant les propriétés de diffusion fiable byzantine, mais ce n'est pas le cas un protocole de consensus BFT complet. Les nœuds ne conservent pas de journaux de messages cohérent dans le sens de représenter un grand livre identique dans toutes leurs vues, et le leader du protocole peut tergiverser sans violer la sécurité. L'OCR est actuellement conçue pour un type de message particulier : l'agrégation médianisée de (au moins 2f +1) valeurs signalées par les nœuds participants. Il fournit une assurance clé sur les rapports qu'il produit pour SC, appelés rapports attestés : La valeur médiane dans un le rapport est égal ou se situe entre les valeurs rapportées par deux nœuds honnêtes. Cette propriété est la condition de sécurité clé pour l’OCR. Le leader peut avoir une certaine influence sur la médiane valeur dans un rapport attesté, mais uniquement sous cette condition d’exactitude. L'OCR peut être étendu aux types de messages qui regroupent les valeurs de différentes manières. Bien que les objectifs actuels de vivacité et d’exactitude du réseau Chainlink ne nécessitent pas Pour que l'OCR soit un protocole de consensus à part entière, ils nécessitent que l'OCR fournisse certaines formes supplémentaires de fonctionnalités non présentes dans les protocoles BFT conventionnels, notamment : 1. Diffusion de rapport hors chaîne tout ou rien : l'OCR garantit qu'un rapport attesté est rendu rapidement disponible à tous les nœuds honnêtes ou à aucun d'entre eux. C'est une question d'équité propriété qui permet de garantir que les nœuds honnêtes ont la possibilité de participer dans la transmission du rapport attesté. 2. Transmission fiable : l'OCR garantit, même en présence de composants défectueux ou malveillants nœuds, que tous les rapports et messages OCR sont transmis au SC dans un certain délai, intervalle de temps prédéfini. Il s'agit d'une propriété de vivacité. 3. Minimisation de la confiance basée sur le contrat : SC filtre les rapports générés par OCR potentiellement erronés, par exemple si leurs valeurs déclarées s'écartent de manière significative des autres. ceux récemment reçus. Il s’agit d’une forme d’application de l’exactitude hors protocole. Ces trois propriétés joueront un rôle naturel dans les DON. La diffusion hors chaîne tout ou rien (DON) est un élément important des garanties cryptoéconomiques autour d'une transmission fiable, qui est à son tour une propriété essentielle de l'adaptateur. Confiance la minimisation dans SC est un type de garde-corps, comme discuté dans la section 7.3. L'OCR fournit également une base pour le déploiement opérationnel et l'affinement des protocoles BFT dans les réseaux oracle de Chainlink et donc, comme indiqué ci-dessus, une voie vers la pleine fonctionnalité des DONs.3.6.2 DECO et Crieur public DECO [234] et Town Crier [233] sont deux technologies connexes actuellement en cours de développement. développé dans les réseaux Chainlink. La plupart des serveurs Web permettent aujourd'hui aux utilisateurs de se connecter via un canal sécurisé à l'aide d'un protocole appelé Transport Layer Security (TLS) [94]. (HTTPS indique une variante de HTTP qui est activé avec TLS, c'est-à-dire que les URL préfixées par « https » indiquent l'utilisation de TLS pour la sécurité.) La plupart des serveurs compatibles TLS ont cependant une limitation notable : ils ne signent pas numériquement. données. Par conséquent, un utilisateur ou un prouveur ne peut pas présenter les données qu'il reçoit d'un serveur à un tiers ou à un vérificateur, tel qu'un oracle ou smart contract, de manière à garantir l’authenticité des données. Même si un serveur signait numériquement les données, un problème de confidentialité demeurerait. Un prouveur peut souhaiter expurger ou modifier des données sensibles avant de les présenter à un Vérificateur. Cependant, les signatures numériques sont conçues spécifiquement pour invalider les données modifiées. Ils empêchent ainsi un prouveur d'apporter des modifications préservant la confidentialité. aux données. (Voir la section 7.1 pour plus de détails.) DECO et Town Crier sont conçus pour permettre à un prouveur d'obtenir des données à partir d'un site Web. serveur et le présenter à un vérificateur d'une manière qui garantit l'intégrité et la confidentialité. Les deux systèmes préservent l'intégrité dans le sens où ils garantissent que les données présentées par le prouveur au vérificateur provient authentiquement du serveur cible. Ils soutiennent confidentialité dans le sens de permettre au prouveur de caviarder ou de modifier les données (tout en préserver l’intégrité). Une caractéristique clé des deux systèmes est qu'ils ne nécessitent aucune modification d'un serveur Web cible. Ils peuvent fonctionner avec n’importe quel serveur compatible TLS existant. En fait, ils sont transparents pour le serveur : Du point de vue du serveur, le Prouveur est établir une connexion ordinaire. Les deux systèmes ont des objectifs similaires, mais diffèrent dans leurs modèles de confiance et leurs implémentations, comme nous l'expliquons maintenant brièvement. DECO utilise fondamentalement des protocoles cryptographiques pour assurer son intégrité et les propriétés de confidentialité. En établissant une session avec un serveur cible à l'aide de DECO, le Prover s'engage en même temps dans un protocole interactif avec le Vérificateur. Ce protocole permet au Prouveur de prouver au Vérificateur qu'il a reçu une donnée D donnée du serveur lors de sa session en cours. Le prouveur peut alternativement, présenter au vérificateur une preuve de connaissance nulle d'une propriété de D et donc ne pas révéler D directement. Dans une utilisation typique de DECO, un utilisateur ou un seul nœud peut exporter des données D depuis un serveur privé. session avec un serveur Web vers tous les nœuds d'un DON. En conséquence, le DON complet peut attester de l'authenticité de D (ou d'un fait dérivé de D via une preuve de connaissance nulle). En plus des exemples d'applications donnés plus loin dans ce document, cette fonctionnalité peut être utilisé pour amplifier l'accès de haute intégrité à une source de données par un DON. Même si un seul nœud a un accès direct à une source de données, grâce par exemple à un accord exclusif avec un fournisseur de données - il reste possible pour l'ensemble du DON d'attester de l'exactitude desrapports émis par ce nœud. Town Crier s'appuie sur l'utilisation d'un environnement d'exécution de confiance (TEE) tel qu'Intel SGX. En bref, un TEE fonctionne comme une sorte de boîte noire qui exécute des applications de manière de manière inviolable et confidentielle. En principe, même le propriétaire de l'hébergeur sur lequel le TEE est en cours d'exécution ne peut ni (indétectable) modifier une application protégée par TEE ni afficher l’état de l’application, qui peut inclure des données secrètes. Town Crier peut réaliser toutes les fonctionnalités de DECO et bien plus encore. DECO contraint le prouveur à interagir avec un seul vérificateur. En revanche, Town Crier permet un prouveur pour générer une preuve publiquement vérifiable sur les données D récupérées sur un serveur cible, c'est-à-dire une preuve que n'importe qui, même un smart contract, peut vérifier directement. Le crieur public peut ingérez et utilisez également en toute sécurité des secrets (par exemple, les informations d'identification des utilisateurs). La principale limitation de Town Crier est son recours aux TEE. Les TEE de production ont Il a récemment été démontré qu'elle présentait un certain nombre de vulnérabilités graves, même si la technologie en est à ses balbutiements et qu'elle arrivera sans aucun doute à maturité. Voir les annexes B.2.1 et B.2.2 pour discussion plus approfondie sur les TEE. Pour quelques exemples d'applications de DECO et Town Crier, voir les sections 4.3, 4.5. et 9.4.3 et l'Annexe C.1. 3.6.3 Services en chaîne Chainlink existants Les réseaux Chainlink oracle fournissent un certain nombre de services principaux à travers une multiplicité de blockchains et autres systèmes décentralisés aujourd'hui. Evolution ultérieure comme décrit dans ce livre blanc dotera ces services existants de capacités supplémentaires et atteindre. Trois exemples sont : Flux de données : Aujourd'hui, la majorité des utilisateurs Chainlink qui comptent sur smart contract font utilisation de flux de données. Il s'agit de rapports sur la valeur actuelle d'éléments de données clés selon à des sources hors chaîne faisant autorité. Par exemple, les flux de prix sont des flux signalant les prix d’actifs – crypto-monnaies, matières premières, forex, indices, actions, etc. – selon services d’échanges ou d’agrégation de données. De tels flux contribuent déjà aujourd’hui à sécuriser des milliards de dollars en valeur en chaîne grâce à leur utilisation dans des systèmes DeFi tels que Aave [147] et Synthétix [208]. D'autres exemples de flux de données Chainlink incluent des données météorologiques pour assurance-récolte paramétrique [75] et données électorales [93], entre autres. Le déploiement des DON et d'autres technologies décrites dans ce document améliorera la fourniture de flux de données dans les réseaux Chainlink de plusieurs manières, notamment : • Mise à l'échelle : l'OCR et, par la suite, les DON visent à permettre aux services Chainlink d'évoluer. de façon spectaculaire à travers les nombreux blockchain qu’ils soutiennent. Par exemple, nous nous attendons que DONs contribueront à augmenter le nombre de flux de données fournis par les nœuds utilisant Chainlink de 100 à 1000 et au-delà. Une telle mise à l'échelle aidera le Chainlink l’écosystème atteint son objectif de fournir des données pertinentes pour les smart contract de manière exhaustive et à la fois de répondre et d’anticiper les besoins existants et futurs.• Sécurité améliorée : en stockant les rapports intermédiaires, les DON conserveront les enregistrements. des comportements des nœuds pour une surveillance et une mesure haute fidélité de leurs performances et de leur précision, permettant une base empirique solide des systèmes de réputation pour les nœuds Chainlink. La FSS et le TEF permettront d'intégrer des flux de prix avec les données de transaction de manière flexible qui empêche les attaques telles que le front-running. (Explicite) staking renforcera la protection cryptoéconomique existante de la sécurité de flux de données. • Agilité des flux : en tant que systèmes agnostiques blockchain (en fait, plus largement, systèmes indépendants des consommateurs), les DON peuvent faciliter la fourniture de flux de données à une multiplicité des systèmes de confiance. Un seul DON peut pousser simultanément un flux donné vers un ensemble de différents blockchain, éliminant le besoin de réseaux oracle par chaîne et permettant un déploiement rapide des flux existants sur les nouveaux blockchain et des flux supplémentaires alimente les blockchain actuellement desservis. • Confidentialité : la possibilité d'effectuer des calculs généralisés dans un DON permet aux calculs sur des données sensibles d'avoir lieu hors chaîne, évitant ainsi les calculs en chaîne. exposition. De plus, en utilisant DECO ou Town Crier, il est possible d'obtenir une confidentialité encore plus forte, permettant la génération de rapports basés sur des données qui ne sont pas exposé même aux nœuds DON. Voir les sections 4.3 et 4.5 pour des exemples. Fonctions aléatoires vérifiables (VRF) : Plusieurs types de DApp nécessitent une source aléatoire vérifiable et correcte pour permettre la vérification de leur propre fonctionnement équitable. Les jetons non fongibles (NFTs) en sont un exemple. La rareté des fonctionnalités NFT dans Aavegotchi [23] et Axie Infinity [35] est déterminée par Chainlink VRF, tout comme la distribution de NFTs au moyen de tirages basés sur des tickets dans les Ether Cards [102] ; la grande variété de DApps de jeu dont les résultats sont randomisés ; et des instruments financiers non conventionnels, par exemple des jeux d'épargne sans perte tels que PoolTogether [89], qui allouent des fonds à gagnants aléatoires. D'autres applications blockchain et non-blockchain nécessitent également des sources de hasard, y compris la sélection des comités du système décentralisé et la exécution de loteries. Bien que les blocs hashes puissent servir de source de hasard imprévisible, ils sont vulnérables à la manipulation par des mineurs adverses (et dans une certaine mesure par les utilisateurs soumettant des transactions). Chainlink VRF [78] offre une alternative considérablement plus sécurisée. Un oracle a une paire de clés privée/publique associée (sk, pk) dont la clé privée est maintenue hors chaîne et dont la clé publique pk est publiée. Pour sortir une valeur aléatoire, il applique sk à une graine imprévisible x fournie par un contrat de confiance (par exemple, un bloc hash et paramètres spécifiques à DApp) en utilisant une fonction F, donnant y = Fsk(x) avec un preuve d'exactitude. (Voir [180] pour le VRF disponible sur Chainlink.) Qu'est-ce qui fait qu'un VRF vérifiable est le fait qu'avec la connaissance de pk, il est possible de vérifier l'exactitude de la preuve et donc de y. La valeur y est donc imprévisible pour un adversaire qui ne peut pas prédire x ou apprendre sk et impossible à manipuler pour le service.Chainlink VRF peut être considéré comme l'une d'une famille d'applications qui impliquent la garde de clés privées hors chaîne. Plus généralement, les DON peuvent offrir des services sécurisés, stockage décentralisé de clés individuelles pour les applications et/ou les utilisateurs, et combiner cette capacité avec le calcul généralisé. Le résultat est une multitude d'applications, de dont nous donnons quelques exemples dans cet article, y compris la gestion des clés pour la preuve de Réserves (voir section 4.1) et pour les informations d’identification décentralisées des utilisateurs (et autres actifs) (voir section 4.3). Gardiens : Chainlink Keepers [87] permettent aux développeurs d'écrire du code pour des applications décentralisées. l'exécution de tâches hors chaîne, généralement pour déclencher l'exécution de smart contract de confiance. Avant l'avènement de Keepers, il était courant que les développeurs exploitent de tels systèmes hors chaîne. logique elles-mêmes, créant des points de défaillance centralisés (ainsi qu’un effort de développement considérable en double). Les Keepers fournissent plutôt un cadre facile à utiliser pour externalisation décentralisée de ces opérations, permettant des cycles de développement plus courts et forte assurance de vivacité et autres propriétés de sécurité. Les gardiens peuvent soutenir n'importe qui d'une grande variété d'objectifs déclencheurs, y compris la liquidation de prêts en fonction des prix ou exécution de transactions financières, lancement de parachutages ou de paiements en fonction du temps dans les systèmes avec récolte de rendement, etc. Dans le cadre DON, les initiateurs peuvent être considérés comme une généralisation des Gardiens dans plusieurs sens. Les initiateurs peuvent utiliser des adaptateurs et peuvent ainsi tirer parti d'un bibliothèque modularisée d'interfaces vers les systèmes en chaîne et hors chaîne, permettant une développement de fonctionnalités sécurisées et sophistiquées. Les initiateurs lancent le calcul dans exécutables, qui eux-mêmes offrent toute la polyvalence des DON, permettant une large gamme de services décentralisés que nous présentons dans cet article pour les applications en chaîne et hors chaîne. 3.6.4 Réputation des nœuds/historique des performances L'écosystème Chainlink existant documente de manière native les historiques de performances des nœuds contributeurs sur la chaîne. Cette fonctionnalité a donné naissance à un ensemble de ressources axées sur la réputation qui ingèrent, filtrent et visualisent les données de performance sur des individus. opérateurs de nœuds et flux de données. Les utilisateurs peuvent référencer ces ressources pour informer décisions dans leur sélection de nœuds et pour surveiller le fonctionnement des réseaux existants. Des fonctionnalités similaires aideront les utilisateurs à choisir les DON. Par exemple, les marchés sans autorisation actuels, tels que market.link, autorisent node les opérateurs doivent répertorier leurs services oracle et attester de leur identité hors chaîne via des services tels que Keybase [4], qui lient le profil d'un nœud dans Chainlink à son les noms de domaine et les comptes de réseaux sociaux existants du propriétaire. De plus, les performances les outils d'analyse, tels que ceux disponibles sur market.link et Reputation.link, permettent utilisateurs pour afficher des statistiques sur les performances historiques des nœuds individuels, y compris leur latence de réponse moyenne, l'écart des valeurs dans leurs rapports par rapport aux valeurs consensuelles relayés en chaîne, les revenus générés, les emplois réalisés, et plus encore. Ces outils d'analyse également permettre aux utilisateurs de suivre l'adoption de divers réseaux oracle par d'autres utilisateurs, une forme deapprobation implicite des nœuds sécurisant ces réseaux. Le résultat est un « réseau de confiance »dans lequel, en utilisant des nœuds particuliers, des applications décentralisées de grande valeur créent un signal de leur confiance dans ces nœuds que les autres utilisateurs peuvent observer et prendre en compte dans leur propres décisions de sélection de nœuds. Avec les DON (et initialement avec l'OCR), s'accompagne d'un changement dans le traitement des transactions et activité contractuelle plus généralement hors chaîne. Un modèle décentralisé pour le nœud d'enregistrement la performance reste possible au sein du DON lui-même. En effet, les hautes performances et la capacité de données des DON permettent de construire des enregistrements de manière fine. manière et également d'effectuer des calculs décentralisés sur ces enregistrements, produisant des résumés fiables qui peuvent être consommés par les services de réputation et contrôlés sur CHAÎNE PRINCIPALE. Bien qu'il soit en principe possible pour un DON de déformer le comportement des nœuds constituants si une grande fraction des nœuds est corrompue, nous notons que le collectif les performances d'un DON lui-même dans la fourniture de données en chaîne sont visibles sur MAINCHAIN et ne peut donc pas être déformé. De plus, nous prévoyons d'explorer les mécanismes qui inciter à la création de rapports internes précis sur les comportements des nœuds dans un DON. Par exemple, en signalant le sous-ensemble de nœuds les plus performants qui renvoient le plus rapidement des données contribuant à un rapport relayé en chaîne, un DON crée une incitation pour les nœuds à contester les erreurs rapports : inclure incorrectement des nœuds dans ce sous-ensemble signifie exclure incorrectement des nœuds cela aurait dû être inclus et donc les pénaliser invalidement. Des échecs de reporting répétés par un DON inciteraient également les nœuds honnêtes à quitter le réseau. DON. Compilation décentralisée d'historiques de performances précis et les conséquences capacité des utilisateurs à identifier les nœuds les plus performants et pour les opérateurs de nœuds à créer les réputations sont des caractéristiques distinctives importantes de l’écosystème Chainlink. Nous montrer dans la section 9 comment nous pouvons raisonner à leur sujet en tant qu’élément clé d’une approche rigoureuse et vue élargie de la sécurité économique fournie par les DON.

Services décentralisés rendus possibles par la décentralisation

Réseaux Oracle Pour illustrer la polyvalence des DON et comment ils permettent une multitude de nouveaux services, nous présentons cinq exemples d'applications basées sur DON dans cette section et décrivons les contrats hybrides qui les réalisent : (1) Proof of Reserves, une forme de service cross-chain ; (2) Interfaçage avec les systèmes d'entreprise/anciens, c'est-à-dire création d'un système basé sur un middleware couche d'abstraction qui facilite le développement d'applications blockchain avec un minimum blockchain-code ou expertise spécifique ; (3) Identité décentralisée, outils permettant aux utilisateurs de obtenir et gérer leurs propres documents d'identité et informations d'identification ; (4) Chaînes prioritaires, un service qui garantit l'inclusion en temps opportun des transactions d'infrastructure critique (par exemple, oracle rapports) sur un blockchain ; et (5) DeFi préservant la confidentialité, c'est-à-dire les informations financières. smart contracts qui dissimulent les données sensibles des parties participantes. Ici, nous

utilisez SC pour désigner la partie MAINCHAIN d'un contrat hybride et décrivez le DON composant séparément ou en termes d'exécutable. 4.1 Preuve de réserves Pour de nombreuses applications, il est utile de relayer l’état entre ou parmi les blockchain. Un L’application populaire de ces services est le packaging de crypto-monnaie. Pièces emballées telles comme WBTC [15] deviennent un atout populaire dans la finance décentralisée (DeFi). Ils implique de déposer l'actif de support « enveloppé » sur sa source blockchain MAINCHAIN(1) et créer un token correspondant sur une cible différente blockchain MAINCHAIN(2). Par exemple, WBTC est un ERC20 token sur le Ethereum blockchain qui correspond à BTC le Bitcoin blockchain. Étant donné que les contrats sur MAINCHAIN(2) n'ont pas de visibilité directe sur MAINCHAIN(1), ils doivent s'appuyer explicitement ou implicitement sur un oracle pour déclarer les dépôts des objets emballés actif dans un smart contract, produisant ce que l'on appelle parfois une preuve de réserves. Dans WBTC [15], par exemple, le dépositaire BitGo détient du BTC et émet du WBTC, avec le Réseau Chainlink fournissant des preuves de réserve [76]. Un DON peut lui-même fournir une preuve de réserves. Cependant, avec un DON, il est possible pour aller plus loin. Un DON peut gérer les secrets et, grâce à l'utilisation d'adaptateurs appropriés, peut effectuer des transactions sur n'importe quel blockchain souhaité. Par conséquent, il est possible que le DON agisse comme l'un des nombreux dépositaires - ou même comme un dépositaire unique et décentralisé - pour un actif enveloppé. Les DONs peuvent ainsi servir de plate-forme pour améliorer la sécurité des les services existants qui utilisent des preuves de réserves. Par exemple, supposons que MAINCHAIN(1) soit Bitcoin et que MAINCHAIN(2) soit Ethereum. Sur MAINCHAIN(2), un contrat SC émet des token représentant des BTC enveloppés. Le DON contrôle une adresse BTC addr(1) DON. Pour envelopper BTC, un utilisateur U envoie X BTC depuis adresse(1) U à l'adresse (1) DON avec une adresse MAINCHAIN(2) addr(2) U. Les moniteurs DON adresse(1) DON via un adaptateur vers MAINCHAIN(1). En observant le dépôt de U, avec une confirmation de probabilité suffisamment élevée, il envoie un message à SC via un adaptateur pour CHAÎNE PRINCIPALE (2). Ce message demande à SC de créer X tokens pour addr(2) U. Pour que U libère X tokens, l’inverse se produit. Cependant, sur MAINCHAIN(1), adresse(1) DON envoie X BTC à l'adresse (1) U (ou à une autre adresse, si l'utilisateur le demande). Ces protocoles peuvent bien entendu être adaptés pour fonctionner avec les échanges, plutôt que directement avec les utilisateurs. 4.2 Interfaçage avec les systèmes d'entreprise/anciens Les DON peuvent servir de ponts entre et parmi les blockchain, comme dans l'exemple de Preuve des réserves, mais un autre objectif est qu'elles agissent comme des ponts bidirectionnels entre blockchains et systèmes existants [176] ou systèmes de type blockchain tels que la banque centrale monnaies numériques [30]. Les entreprises sont confrontées à un certain nombre de défis pour connecter leurs systèmes existants et processus vers des systèmes décentralisés, notamment :• Agilité de la blockchain : les systèmes de blockchain évoluent rapidement. Une entreprise peut être confrontée à la nouvelle apparition rapide ou à la montée en popularité de blockchain sur lesquels les contreparties souhaitent effectuer des transactions, mais pour lesquelles l'entreprise n'a pas soutien dans son infrastructure existante. En général, le dynamisme des blockchain fait il est difficile pour les entreprises individuelles de rester au courant de l’ensemble de l’écosystème. • Ressources de développement spécifiques à la blockchain : pour de nombreuses organisations, recruter ou incuber une expertise blockchain de pointe est difficile, en particulier compte tenu de la défi de l'agilité. • Gestion des clés privées : la gestion des clés privées des blockchain ou des cryptomonnaies nécessite une expertise opérationnelle distincte de celle de la cybersécurité traditionnelle. pratiques et inaccessibles à de nombreuses entreprises. • Confidentialité : les entreprises hésitent à exposer leurs données sensibles et exclusives. données sur chaîne. Pour résoudre les trois premières de ces difficultés, les développeurs peuvent simplement utiliser un DON en tant que couche middleware sécurisée pour permettre aux systèmes d'entreprise de lire ou d'écrire sur blockchains. Le DON peut faire abstraction de considérations techniques détaillées telles que dynamique des gaz, réorganisation de la chaîne, etc., tant pour les développeurs que pour les utilisateurs. Par présentant une interface blockchain rationalisée aux systèmes d'entreprise, un DON peut ainsi simplifie considérablement le développement d'applications d'entreprise compatibles blockchain, éliminant ainsi le fardeau des entreprises liées à l'acquisition ou à l'incubation de ressources de développement spécifiques à blockchain. Une telle utilisation des DONs est particulièrement intéressante dans la mesure où elle permet aux développeurs d'entreprise de créer des applications de contrats intelligents qui sont largement blockchain agnostiques. En conséquence, le plus grand l'ensemble des blockchain pour lesquels un DON est instrumenté pour agir comme middleware, le élargissez l'ensemble des blockchain auxquels les utilisateurs de l'entreprise peuvent accéder facilement. Développeurs peut porter des applications de blockchain existants vers de nouveaux avec un minimum de modifications à leurs applications développées en interne. Pour résoudre le problème supplémentaire de la confidentialité, les développeurs peuvent faire appel au outils que nous présentons dans cet article et que nous prévoyons de déployer pour prendre en charge les applications DON. Il s'agit notamment de DECO et du crieur public, section 3.6.2, ainsi que des règles de préservation de la confidentialité. Les modifications de l'API abordées dans la section 7.1.2 et un certain nombre d'approches spécifiques à l'application couvertes dans le reste de cette section. Ces systèmes DON peuvent fournir attestations en chaîne de haute intégrité sur l'état du système d'entreprise sans révéler données sources d'entreprise sensibles sur la chaîne. 4.3 Identité décentralisée L'identité décentralisée est un terme général désignant la notion selon laquelle les utilisateurs devraient pouvoir obtenir et gérer leurs propres informations d'identification, plutôt que de compter sur des tiers pour le faire donc. Les identifiants décentralisés sont des attestations d'attributs ou d'affirmations du titulaire,qui sont souvent appelés réclamations. Les informations d'identification sont signées numériquement par des entités, souvent appelées émetteurs, qui peuvent associer avec autorité les réclamations aux utilisateurs. Dans la plupart des schémas proposés, les réclamations sont associées à un identifiant décentralisé (DID), un identifiant universel pour un utilisateur donné. Les informations d'identification sont liées à une clé publique dont l'utilisateur détient la clé privée. L'utilisateur peut ainsi prouver la possession d'un titre grâce à sa clé privée. Aussi visionnaire que soit l'identité décentralisée, les projets existants et proposés, par exemple [14, 92, 129, 216], présentent trois limitations sévères : • Manque de compatibilité avec l'héritage : les systèmes d'identité décentralisés existants reposent sur un communauté d’autorités, appelées émetteurs, pour produire les identifiants DID. Parce que les services web existants ne signent généralement pas numériquement les données, les émetteurs doivent être lancés comme systèmes à usage spécial. Parce qu'il n'y a aucune incitation à le faire sans écosystème d’identité décentralisé, il en résulte un problème de la poule et de l’œuf. Dans d'autres En d’autres termes, on ne sait pas comment démarrer un écosystème d’émetteurs. • Gestion des clés irréalisable : les systèmes d'identité décentralisés exigent que les utilisateurs gérer les clés privées, ce que l'expérience avec la crypto-monnaie a montré être une responsabilité irréalisable. On estime que quelque 4 000 000 Bitcoin ont été perdu à jamais à cause d'échecs de gestion des clés [194], et de nombreux utilisateurs stockent leurs actifs cryptographiques avec des échanges [193], compromettant ainsi la décentralisation. • Manque de résistance Sybil préservant la confidentialité : une exigence de sécurité de base des applications telles que le vote, l'attribution équitable des token lors des ventes de token, etc. est que les utilisateurs ne pourront pas affirmer plusieurs identités. Les propositions d'identité décentralisées existantes exigent que les utilisateurs révèlent leur identité réelle afin d'atteindre un tel objectif. Sybil résiste, compromettant ainsi d’importantes garanties de confidentialité. Il est possible de résoudre ces problèmes en utilisant une combinaison d'un comité de nœuds effectuer des calculs distribués au sein d'un DON et utiliser des outils tels que DECO ou crieur public, comme indiqué dans un système appelé CanDID [160]. DECO ou Town Crier peuvent, de par leur conception, transformer des services Web existants sans modification en émetteurs de titres de créance préservant la confidentialité. Ils permettent à un DON d'exporter les données pertinentes données à cette fin dans un identifiant tout en masquant les données sensibles qui ne devraient pas apparaître dans l'identifiant. De plus, pour faciliter la récupération des clés pour les utilisateurs, abordant ainsi le problème de gestion des clés problème, un DON peut permettre aux utilisateurs de stocker des clés privées sous forme secrète partagée. Les utilisateurs peuvent récupérez leurs clés en prouvant aux nœuds du DON — de la même manière, en utilisant Town Crier ou DECO : la possibilité de se connecter à des comptes auprès d'un ensemble de fournisseurs Web prédéterminés (par exemple, Twitter, Google, Facebook). L’avantage d’utiliser Town Crier ou DECO, par opposition à OAUTH, c'est la confidentialité des utilisateurs. Ces deux outils permettent à un utilisateur d'éviter de révéler au DON un identifiant de fournisseur Web, à partir duquel des identités réelles peuvent souvent être dérivées. Enfin, pour fournir une résistance Sybil, comme indiqué dans [160], il est possible pour un DON de effectuer une transformation préservant la confidentialité des identifiants uniques du monde réel pour les utilisateurs (par exemple, les numéros de sécurité sociale (SSN)) en identifiants en chaîne lors de l'enregistrement de l'utilisateur.Le système peut ainsi détecter les enregistrements en double sans données sensibles telles que Les SSN sont révélés à des nœuds DON individuels.7 Un DON peut fournir n'importe lequel de ces services au nom d'une identité décentralisée externe systèmes sur des blockchain sans autorisation ou avec autorisation, par exemple, des instances d'Hyperledger Indy [129]. Exemple d'application : KYC : L'identité décentralisée est prometteuse comme moyen de rationaliser les exigences pour les applications financières sur blockchains tout en améliorant les utilisateurs vie privée. Deux défis qu'il peut aider à relever sont les obligations d'accréditation et de conformité en vertu des réglementations anti-blanchiment d'argent/connaissance du client (AML/KYC). Dans de nombreux pays, les réglementations LAB exigent que les institutions financières (et autres entreprises) établissent et vérifient l'identité des individus et des entreprises avec lesquels ils effectuent des transactions. Le KYC constitue une composante de la stratégie d’une institution financière. une politique AML plus large, qui implique également généralement de surveiller les comportements des utilisateurs et de surveiller les flux de fonds, entre autres choses. KYC implique généralement la présentation par l'utilisateur d'informations d'identification sous une forme quelconque (par exemple, entrée dans un formulaire Web en ligne, tenant un document d'identité devant le visage d'un utilisateur lors d'une séance vidéo, etc.). Création et présentation sécurisées d’informations d’identification décentralisées pourrait en principe être une alternative bénéfique à plusieurs égards, notamment en : (1) le processus KYC plus efficace pour les utilisateurs et les institutions financières, car une fois l'accréditation est obtenue, elle pourrait être présentée de manière transparente à n'importe quelle institution financière ; (2) Réduire la fraude en réduisant les possibilités de vol d'identité par compromission d'informations personnellement identifiables (PII) et d'usurpation d'identité lors de la vérification vidéo ; et (3) Réduire le risque de compromission des informations personnelles dans les institutions financières, car les utilisateurs conservent le contrôle de leurs propres données. Compte tenu des pénalités de plusieurs milliards de dollars payées par les institutions financières en cas de non-respect de la LBC et des nombreuses institutions financières qui dépensent des millions de dollars chaque année en KYC, des améliorations pourraient générer des économies considérables pour les institutions financières. et, par extension, pour les consommateurs [196]. Alors que le secteur financier traditionnel est lent pour adopter de nouveaux outils de conformité, les systèmes DeFi les adoptent de plus en plus [43]. Exemple d'application : Prêts sous-garantis : La plupart des applications DeFi qui Aujourd’hui, les prêts de soutien ne proviennent que de prêts entièrement garantis. Ce sont des prêts accordés aux emprunteurs qui déposent des actifs en cryptomonnaies d’une valeur supérieure à celle des prêts. Un intérêt est apparu récemment pour ce que la communauté DeFi appelle généralement des prêts sous-garantis. Il s'agit en revanche de prêts pour lesquels la garantie correspondante a une valeur inférieure à celle du principal du prêt. Prêts sous-garantis ressemblent à des prêts souvent accordés par des institutions financières traditionnelles. Plutôt que de compter sur les garanties déposées comme garantie du remboursement du prêt, ils basent plutôt les prêts décisions sur les antécédents de crédit des emprunteurs. 7Cette transformation s'appuie sur une fonction pseudo-aléatoire distribuée (PRF).Les prêts sous-garantis constituent une partie naissante mais croissante du marché des prêts DeFi. Ils s'appuient sur des mécanismes comme ceux employés par les institutions financières traditionnelles. institutions, telles que les contrats juridiques [91]. Une condition essentielle à leur croissance sera la capacité de fournir des données sur la solvabilité des utilisateurs (un facteur clé dans les décisions de prêt conventionnelles) aux systèmes DeFi d'une manière qui assure une forte intégrité, c'est-à-dire : l'assurance de données correctes. Un système d'identité décentralisé compatible DON permettrait aux emprunteurs potentiels de générer des références de haute assurance attestant de leur solvabilité tout en préservant la confidentialité des informations sensibles. Plus précisément, les emprunteurs peuvent générer ces informations d'identification basées sur des enregistrements provenant de sources en ligne faisant autorité tout en exposant uniquement les données attestées par le DON, sans exposer d'autres données potentiellement sensibles. Pour Par exemple, un emprunteur peut générer un justificatif indiquant que son pointage de crédit avec un l’ensemble des agences d’évaluation du crédit dépasse un seuil particulier (par exemple 750), sans le révéler score précis ou toute autre donnée dans ses dossiers. De plus, si vous le souhaitez, ces informations d'identification peut être généré de manière anonyme, c'est-à-dire que le nom de l'utilisateur peut être traité comme une donnée sensible et lui-même n'est pas exposé aux nœuds oracle ou dans ses informations d'identification décentralisées. L'accréditation lui-même peut être utilisé en chaîne ou hors chaîne, selon l'application. En résumé, un emprunteur peut fournir des informations essentielles aux prêteurs sur son crédit historiques avec une forte intégrité et sans risque d’exposition de données inutiles et sensibles données. Un emprunteur peut également fournir diverses autres informations d'identification préservant la confidentialité. utile dans la prise de décisions en matière de prêt. Par exemple, les informations d’identification peuvent attester de l’identité d’un emprunteur. possession d'actifs (hors chaîne), comme nous le montrons dans notre exemple suivant. Exemple de candidature : Accréditation : De nombreuses juridictions limitent la catégorie d'investisseurs à laquelle les titres non enregistrés peuvent être vendus. Par exemple, aux États-Unis, la SEC Le règlement D stipule que pour être accrédité pour de telles opportunités d'investissement, un l'individu doit posséder une valeur nette de 1 million de dollars, satisfaire à certaines exigences de revenu minimum ou posséder certaines qualifications professionnelles [209, 210]. Accréditation actuelle les processus sont lourds et inefficaces, nécessitant souvent une lettre d’attestation de un comptable ou une preuve similaire. Un système d'identité décentralisé permettrait aux utilisateurs de générer des informations d'identification à partir de comptes de services financiers en ligne existants qui prouvent leur conformité à l'accréditation réglementations, facilitant un processus KYC plus efficace et préservant la confidentialité. Le Les propriétés de protection de la vie privée de DECO et Town Crier permettraient en outre à ces les informations d’identification doivent être générées avec une forte assurance d’intégrité sans révéler directement les détails de la situation financière d’un utilisateur. Par exemple, un utilisateur peut générer un identifiant prouver qu'elle a une valeur nette d'au moins 1 million de dollars sans révéler aucun élément supplémentaire des informations sur sa situation financière. 4.4 Canaux prioritaires Les canaux prioritaires constituent un nouveau service utile et facile à créer à l'aide d'un DON. Leur

l'objectif est de livrer des transactions sélectionnées et hautement prioritaires en temps opportun sur MAINCHAIN pendant les périodes de congestion du réseau. Les chaînes prioritaires peuvent être considérées comme une forme de contrat à terme sur l'espace de blocs et donc en tant que cryptomarchandise, terme inventé dans le cadre du Projet Chicago [61, 136]. Les canaux prioritaires sont spécifiquement destinés aux mineurs pour permettre des services d'infrastructure, tels que les oracle, les fonctions de gouvernance pour les contrats, etc., et non pour les activités ordinaires au niveau des utilisateurs telles que les transactions financières. En fait, tel que conçu ici, une priorité Le canal mis en œuvre par moins de 100 % de la puissance minière du réseau ne peut que fournir des limites lâches sur les délais de livraison, empêchant son utilisation pour des produits très dépendants de la vitesse des objectifs tels que la course en avant. Figure 10 : Un canal prioritaire est une garantie d’un mineur M – ou plus généralement d’un ensemble de mineurs M – à un utilisateur U que sa transaction τ sera extraite dans D blocs d'inclusion dans le mempool. Un SC contractuel peut utiliser la surveillance DON pour faire respecter les conditions de service de la chaîne. Un canal prioritaire prend la forme d'un accord entre un mineur ou un ensemble de mineurs (ou pools miniers) M qui fournit le canal et un utilisateur U qui paie des frais d'accès. M convient que lorsque U soumet une transaction τ au mempool (avec n'importe quel prix du gaz,mais une limite de gaz préalablement convenue), M le placera en chaîne dans les prochains blocs D.8 L’idée est représentée schématiquement sur la figure 10. Description du contrat canal prioritaire : Un canal prioritaire peut être réalisé comme un hybride smart contract à peu près comme suit. On laisse SC désigner la logique sur MAINCHAIN et cela sur le DON par exec. SC accepte un dépôt/mise en jeu \(d from M and an advance payment \)p de U. A L'exécutable DON surveille le pool de mémoire et se déclenche lors du placement d'une transaction. par U. Il envoie un message de réussite à SC si U soumet une transaction que M exploite dans en temps opportun et un message d'échec en cas de panne de service. SC envoie le paiement $p à M suite à un message de réussite et envoie tous les fonds restants, y compris $d, à U s'il reçoit un message d'échec. En cas de résiliation réussie, il remet le dépôt $d à M. Le mineur M peut bien entendu fournir des canaux prioritaires simultanément à plusieurs utilisateurs et peut ouvrir un canal prioritaire avec U pour un nombre de messages préalablement convenu. 4.5 Préservation de la confidentialité DeFi / Mixicles Aujourd'hui, les applications DeFi [1] offrent peu ou pas de confidentialité aux utilisateurs : toutes les transactions sont visibles sur la chaîne. Diverses approches basées sur une connaissance nulle, par exemple [149, 217], peuvent assurer la confidentialité des transactions, et le TEF est suffisamment général pour les prendre en charge. Mais ces approches ne sont pas exhaustives et, par exemple, ne cachent généralement pas les actif sur lequel repose une transaction. Le large éventail d'outils informatiques que nous avons l'intention de prendre en charge dans DONs sera permettre la confidentialité de différentes manières qui peuvent combler de telles lacunes, contribuant ainsi à compléter les garanties de confidentialité d'autres systèmes. Par exemple, Mixicles, un instrument de préservation de la confidentialité DeFi proposé par les chercheurs de Chainlink Labs [135], peut dissimuler le type d'actif adossant un instrument financier, et s'intègre très naturellement dans le DON cadre. Les mixicles s'expliquent le plus facilement en termes de leur utilisation pour réaliser un binaire simple choix. Une option binaire est un instrument financier dans lequel deux utilisateurs, que nous allons référez-vous ici pour plus de cohérence avec [135] en tant que joueurs, pariez sur un événement avec deux possibilités résultats, par exemple, si un actif dépasse ou non un prix cible à un moment prédéfini. L’exemple suivant illustre l’idée. Exemple 2. Alice et Bob sont parties à une option binaire basée sur la valeur d'un actif appelé Carol’s Bubble Token (CBT). Alice parie que le CBT aura un prix de marché d'au au moins 250 USD à l'heure T = midi le 21 juin 2025 ; Bob parie l'inverse. Chaque joueur dépose 100 ETH dans un délai prédéfini. Le joueur avec la position gagnante reçoit 200 ETH (c'est-à-dire gagne 100 ETH). 8D doit bien sûr être suffisamment grand pour garantir que M puisse se conformer à une probabilité élevée. Pour Par exemple, si M contrôle 20 % de la puissance minière du réseau, il pourrait choisir D = 100, garantissant ainsi une probabilité de défaillance de ≈2 × 10−10, soit moins d'un sur un milliard.Étant donné un réseau O Chainlink oracle existant, il est facile de mettre en œuvre un système intelligent contrat SC qui réalise l'accord de l'exemple 2. Les deux joueurs déposent chacun 100 ETH en SC. Quelque temps après T, une requête q est envoyée à O demandant le prix r de CBT à l'instant T. O envoie un rapport r de ce prix à SC. SC envoie ensuite de l'argent à Alice si r ≥250 et Bob sinon. Cependant, cette approche révèle r sur la chaîne, ce qui facilite pour un observateur de déduire l’actif sous-jacent à l’option binaire. Dans la terminologie des Mixicles, il est utile de penser conceptuellement au résultat de SC en termes de Switch qui transmet une valeur binaire calculée comme prédicat interrupteur(r). Dans notre exemple, switch(r) = 0 si r ≥250 ; compte tenu de ce résultat, Alice gagne. Sinon switch(r) = 1 et Bob gagne. Un DON peut réaliser un Mixicle de base en tant que contrat hybride en exécutant un exécutable exec qui calcule switch(r) et le signale en chaîne à SC. Nous montrons cette construction sur la figure 11. Figure 11 : Schéma du Mixicle de base dans l'exemple 2. Pour assurer le secret en chaîne pour rapport r, et donc l'actif sous-jacent à l'option binaire, le oracle envoie au contractez SC via Switch uniquement le switch de valeur binaire (r). Nous spécifions un adaptateur ConfSwitch dans l'Annexe C.3 qui facilite la réalisation de cet objectif. objectif dans un DON. L'idée de base derrière ConfSwitch est assez simple. Au lieu de signaler la valeur r, ConfSwitch rapporte uniquement la valeur du commutateur binaire switch(r). SC peut être conçu pour effectuer un paiement correct basé sur le switch(r) seul, et le switch(r) seul ne révèle aucune information sur l’actif sous-jacent – CBT dans notre exemple. De plus, en plaçant un texte chiffré sur (q, r) sur le registre chiffré sous pkaud, la clé publique de un auditeur, l'adaptateur ConfSwitch crée une piste d'audit préservant la confidentialité. Le Mixicle de base que nous avons choisi par souci de simplicité pour décrire ici ne cache que le actif et pariez derrière l'option binaire dans notre exemple. Un Mixicle à part entière [135] peut fournir deux formes de confidentialité. Il cache aux observateurs : (1) Quel événement le les joueurs parient sur (c'est-à-dire q et r) mais aussi (2) Quel joueur a gagné le pari. Puisque les Mixicles sont exécutés sur MAINCHAIN, un joueur devra relayer switch(r) du DON vers MAINCHAIN, ou un exécutable pourrait être créé qui

est déclenché en sortie par ConfSwitch et appelle un autre adaptateur pour envoyer le switch(r) à CHAÎNE PRINCIPALE. Un troisième type de confidentialité, plus subtil, mérite également d’être pris en considération. Dans une implémentation de base de ConfSwitch, O exécute l'adaptateur sur le DON et apprend ainsi le actif – CBT dans notre exemple – et donc la nature de l’option binaire. Comme discuté à l'annexe C.3, il est toutefois possible d'utiliser en plus DECO ou Town Crier pour cacher même cette information à O. Dans ce cas, l'O n'apprend plus aucune information qu’un observateur public de SC. Pour plus de détails sur Mixicles, nous renvoyons les lecteurs à [135].

Services de séquençage équitables

Un service important que nous espérons que les DON offriront et qui exploite leurs capacités de mise en réseau, de calcul et de stockage est appelé Fair Sequencing Services (FSS). Bien que FSS puisse être considéré simplement comme une application réalisée dans le cadre DON, nous le soulignons comme un service qui, selon nous, sera très demandé dans l'ensemble du pays. blockchains, et que nous espérons que le réseau Chainlink soutiendra activement. Lorsqu'elles sont exécutées sur des réseaux publics blockchain, de nombreuses applications DeFi actuelles révéler des informations qui peuvent être exploitées par les utilisateurs à leur propre bénéfice, à l’instar de le type de fuites internes et d’opportunités de manipulation qui sont omniprésentes dans les systèmes existants. marchés [64, 155]. FSS ouvre plutôt la voie vers un écosystème DeFi équitable. FSS aide les développeurs à créer des contrats DeFi protégés contre les manipulations de marché résultant d’une fuite d’informations. Compte tenu des problèmes que nous soulignons ci-dessous, FSS est particulièrement attrayant pour les services de couche 2 et s'inscrit dans le cadre de tels services dont nous discutons dans la section 6. Le défi : Dans les systèmes sans autorisation existants, les transactions sont entièrement ordonnées à la discrétion des mineurs. Dans les réseaux autorisés, les nœuds validator peuvent exercer la même puissance. Il s’agit d’une forme de centralisation éphémère largement méconnue dans systèmes autrement décentralisés. Un mineur peut (temporairement) censurer les transactions pour son compte. propre bénéfice [171] ou les réorganiser pour maximiser son propre gain, une notion appelée valeur extractible par la mine (MEV) [90]. Le terme MEV est légèrement trompeur : il ne fait pas référence uniquement à la valeur que les mineurs peuvent capturer : certains MEV peuvent être capturés par les utilisateurs ordinaires. Cependant, étant donné que les mineurs ont plus de pouvoir que les utilisateurs ordinaires, le MEV représente une limite supérieure sur le montant de la valeur qu'une entité peut obtenir grâce à une réorganisation contradictoire. et insertion de transactions complémentaires. Même lorsque les mineurs commandent simplement des transactions basé sur des tarifs (gaz), sans manipulation, les utilisateurs eux-mêmes peuvent manipuler les prix du gaz pour avantager leurs transactions par rapport à celles moins sophistiquées. Daian et coll. [90] documente et quantifie les façons dont les robots (et non les mineurs) prennent avantage de la dynamique des gaz d'une manière qui nuit aux utilisateurs des systèmes DeFi aujourd'hui et comment MEV menace même la stabilité de la couche de consensus sous-jacente dans un blockchain. D’autres exemples de manipulation d’ordres de transaction font régulièrement surface, par exemple [50, 154].Les nouvelles méthodes de traitement des transactions telles que rollups constituent une approche très prometteuse aux problèmes de mise à l'échelle des blockchain à haut débit. Ils ne traitent cependant pas le problème du MEV. Au lieu de cela, ils le transfèrent vers l'entité qui génère le rollup. Cela entité, qu'il s'agisse de l'opérateur d'un smart contract ou d'un utilisateur fournissant à un (zk-)rollup une preuve de validité, a le pouvoir d'ordonner et d'insérer des transactions. En d'autres termes, rollups échangez MEV contre REV : valeur cumulable-extractible. MEV affecte les transactions à venir qui ont été soumises au mempool mais ne sont pas encore engagés sur chaîne. Les informations sur ces transactions sont largement disponible dans le réseau. Les mineurs, les validator et les participants ordinaires au réseau peuvent exploitez donc ces connaissances et créez des transactions dépendantes. De plus, les mineurs et les validator peuvent influencer l'ordre des transactions qu'ils effectuent. eux-mêmes et exploitent cela à leur avantage. Le problème de l’influence indue des dirigeants sur l’ordonnancement des transactions par consensus protocoles sont connus dans la littérature depuis les années 1990 [71, 190], mais aucun résultat satisfaisant des solutions ont été mises en pratique jusqu'à présent [97]. La principale raison est que les solutions proposées – du moins jusqu’à très récemment – ne peuvent pas être facilement intégrées aux politiques publiques. blockchains, car ils s'appuient sur le contenu des transactions qui reste secret jusqu'après leur ordre a été déterminé. Présentation des services de séquençage équitable (FSS) : DONs fournira des outils pour décentraliser l'ordre des transactions et le mettre en œuvre conformément à une politique spécifiée par un organisme de confiance. créateur de contrat, idéalement équitable et ne favorisant pas les acteurs qui souhaitent manipuler l’ordre des transactions. Collectivement, ces outils constituent FSS. FSS comprend trois composants. Le premier est le suivi des transactions. Dans la FSS, Les nœuds oracle en O surveillent tous deux le pool de mémoire de MAINCHAIN et (si vous le souhaitez) autorisent soumission hors chaîne des transactions via un canal spécialisé. La seconde est le séquençage des transactions. Les nœuds en O commandent des transactions pour un contrat de confiance selon une politique définie pour ce contrat. Le troisième est la comptabilisation des transactions. Une fois les transactions ordonnées, les nœuds en O envoient conjointement les transactions au chaîne principale. Les avantages potentiels du FSS comprennent : • Équité des commandes : FSS inclut des outils pour aider les développeurs à garantir que les transactions les contributions à un contrat particulier sont ordonnées de manière à ne pas donner lieu à un préjudice injuste avantage pour les utilisateurs disposant de ressources suffisantes et/ou techniquement avertis. Politiques de commande peuvent être spécifiés à cet effet. • Réduction ou élimination des fuites d'informations : en garantissant que les participants au réseau ne peuvent pas exploiter les informations sur les transactions à venir, le FSS peut réduire ou éliminer les attaques comme le front-running qui sont basées sur les informations disponibles dans le réseau avant que les transactions ne soient validées. Empêcher l’exploitation de ces les fuites garantissent que les transactions contradictoires qui dépendent de l'original en attente les transactions ne peuvent pas entrer dans le grand livre avant que les transactions originales ne soient validées.• Coût de transaction réduit : en éliminant le besoin de rapidité des joueurs lors de la soumission. leurs transactions vers un smart contract, FSS peut réduire considérablement le coût de traitement des transactions. • Ordre prioritaire : FSS peut automatiquement accorder une priorité spéciale aux transactions critiques. commande. Par exemple, afin de prévenir les attaques frontales contre oracle rapports, par exemple [79], FSS peut insérer un rapport oracle dans un flux de transactions rétroactivement. L'un des principaux objectifs du FSS dans les DONs est de permettre aux créateurs de DeFi de réaliser des les systèmes financiers, c’est-à-dire les systèmes qui ne profitent pas à des utilisateurs particuliers (ou à des mineurs) par rapport aux autres sur la base de la rapidité, des connaissances privilégiées ou de la capacité à exécuter des tâches techniques. manipulations. Même si une notion générale et précise d'équité est insaisissable, et l'équité parfaite dans tout sens raisonnable est irréalisable, FSS vise à fournir aux développeurs un outil puissant ensemble d'outils leur permettant d'appliquer des politiques qui les aident à atteindre leurs objectifs de conception pour DeFi. Nous notons que même si l'objectif principal du FSS est d'agir comme un service de séquençage équitable pour le MAINCHAIN que cible DON, certains des mêmes desiderata d'équité que FSS les garanties peuvent également être appropriées pour les protocoles (décentralisés) gérés entre DON fêtes. Ainsi, le SFS peut être considéré plus largement comme un service fourni par un sous-ensemble de nœuds DON pour séquencer équitablement non seulement les transactions envoyées par les utilisateurs de MAINCHAIN mais aussi des transactions (c'est-à-dire des messages) partagées entre d'autres nœuds DON. Dans cette rubrique, nous nous concentrerons principalement sur l’objectif de séquençage des transactions MAINCHAIN. Organisation de la section : dans la section 5.1, nous décrivons deux applications de haut niveau qui motivent la conception du FSS : empêcher le lancement en amont des rapports oracle et empêcher front-running des transactions des utilisateurs. Nous fournissons ensuite plus de détails sur la conception du FSS à la section 5.2. La section 5.3 décrit des exemples de garanties et de moyens de commande équitables pour les atteindre. Enfin, les sections 5.4 et 5.5 discutent des menaces au niveau du réseau pour ces politiques et moyens pour y remédier, respectivement pour l'inondation du réseau et Sybil attaques. 5.1 Le problème de premier plan Pour expliquer les objectifs et la conception du FSS, nous décrivons deux formes générales attaques et les limites des solutions existantes. Les leaders illustrent une classe des attaques par ordre de transactions : il existe un certain nombre d'attaques connexes telles que le backrunning et le sandwiching (front-running plus back-running) [237] que nous ne couvrons pas ici, mais que la FSS aide également à résoudre. 5.1.1 Oracle Front-Running Dans leur rôle traditionnel de fournir des données hors chaîne aux applications blockchain, oracles devenir une cible naturelle pour des attaques de premier plan.Considérez le modèle de conception courant consistant à utiliser un oracle pour fournir divers flux de prix. à un échange en chaîne : périodiquement (disons toutes les heures), le oracle collecte des données de prix pour différents actifs et les envoie à un contrat d'échange. Ces transactions de données sur les prix présentent des opportunités d'arbitrage évidentes : par exemple, si le rapport oracle le plus récent répertorie un prix beaucoup plus élevé pour certains actifs, un adversaire pourrait être en avance sur le rapport oracle pour acheter des actifs et les revendre immédiatement une fois le rapport de oracle traité. Ralentisseurs et tarification rétroactive : Une solution naturelle au problème initial oracle consiste à accorder aux rapports oracle une priorité particulière par rapport aux autres transactions. Pour Par exemple, les rapports oracle pourraient être envoyés avec des frais élevés pour encourager les mineurs à traiter eux en premier. Mais cela n’empêchera pas le front-running si l’opportunité d’arbitrage est élevée, cela ne peut pas non plus empêcher l’arbitrage des mineurs eux-mêmes. Certaines bourses ont donc eu recours à la mise en œuvre de « ralentisseurs » plus lourds, tels que la mise en file d'attente des transactions des utilisateurs pendant un certain nombre de blocs avant de les traiter. ou en ajustant rétroactivement les prix lorsqu'un nouveau rapport oracle arrive. Les inconvénients de ces solutions sont qu'elles ajoutent de la complexité à la mise en œuvre de l'échange, augmenter les besoins de stockage et donc les coûts de transaction, et perturber l'expérience utilisateur car les échanges d'actifs ne sont confirmés qu'après une période de temps significative. Ferroutage : Avant de passer au FSS, nous discutons du ferroutage, une solution assez simple et solution élégante au problème principal oracle. Il ne s'applique pas à l'adresse cependant, en tête dans d’autres scénarios. En bref, au lieu d'envoyer périodiquement des rapports au contrat en chaîne, oracles publier des rapports signés que les utilisateurs joignent à leurs transactions lors de l'achat ou de la vente actifs en chaîne. L'échange vérifie alors simplement que le rapport est valide et récent (par exemple, le oracle peut signer une plage de blocs pour lesquels le rapport est valide), et extrait le prix correspondant en découle. Cette approche simple présente un certain nombre d’avantages par rapport au « ralentisseur » ci-dessus. approche : (1) Le contrat d’échange n’a pas besoin de conserver l’état des flux de prix, qui devraient conduire à une baisse des coûts de transaction ; (2) Comme les rapports oracle sont publiés sur la chaîne selon les besoins, les oracle peuvent générer des mises à jour plus fréquentes (par exemple, toutes les minutes), ainsi minimiser les opportunités d’arbitrage lors de la publication d’un rapport9 ; (3) Les transactions peuvent être validés immédiatement, car ils incluent toujours un nouveau flux de prix. L’approche n’est cependant pas parfaite. Premièrement, cette solution de superposition met le il incombe aux utilisateurs de l'échange de récupérer des rapports oracle à jour et de les joindre à leur transactions. Deuxièmement, même si le recours au ferroutage minimise les opportunités d’arbitrage, il ne peut les empêcher complètement sans affecter la vivacité du contrat en chaîne. En effet, si un Le rapport oracle est valide jusqu'à un numéro de bloc n, puis une transaction soumise au bloc n + 1 nécessiterait un nouveau rapport valide. En raison des retards inhérents à la propagation de rapports de oracles aux utilisateurs, le nouveau rapport valable pour le bloc n + 1 aurait 9L’arbitrage ne vaut la peine que si la différence exploitable des prix des actifs dépasse les les frais requis pour acheter et vendre les actifs, par exemple ceux collectés par les mineurs et la bourse.être rendu public quelque temps avant que le bloc n + 1 ne soit extrait, disons au bloc n −k, ainsi créer une séquence de k blocs où existe une opportunité d'arbitrage de courte durée. Nous décrivez maintenant comment FSS contourne ces limitations. Priorisation des rapports oracle avec FSS : La FSS peut répondre au problème de premier plan oracle problème en s'appuyant sur la solution de ferroutage ci-dessus, mais en poussant les travail d'augmentation des transactions avec des rapports oracle au réseau Oracle décentralisé. À un niveau élevé, les nœuds oracle collectent les transactions destinées à un échange en chaîne, convenir d'un flux de prix en temps réel et publier le flux de prix ainsi que les transactions collectées sur le contrat de la chaîne principale. Conceptuellement, on peut considérer cette approche comme une « traitement par lots de transactions augmenté par les données », où le oracle garantit qu'un le flux de prix est toujours ajouté aux transactions. Les solutions FSS peuvent être mises en œuvre de manière transparente pour les utilisateurs de la bourse, et avec des changements minimes à la logique contractuelle, comme nous le décrivons plus en détail à la section 5.2. Assurer le fait que les nouveaux rapports oracle soient toujours prioritaires sur les transactions des utilisateurs n'est qu'un exemple d'une politique de commande que la FSS peut adopter et appliquer. Politiques de la FSS pour assurer l'ordre l’équité sont décrites de manière plus générale à la section 5.3. 5.1.2 Transactions utilisateur de premier plan Passons maintenant au front-running dans les applications génériques, où la méthode de défense ci-dessus ne fonctionne pas. Le problème peut être globalement capturé à travers le scénario suivant : Un adversaire voit une transaction utilisateur tx1 envoyée dans le réseau P2P et injecte sa propre transaction contradictoire tx2, de sorte que tx2 soit traitée avant tx1 (par exemple, en payant des frais de transaction plus élevés). Par exemple, ce type de front-running est courant parmi les des robots qui exploitent les opportunités d'arbitrage dans les systèmes DeFi [90] et qui ont affecté les utilisateurs de diverses applications décentralisées [101]. Imposer un ordre équitable entre les transactions traité sur le blockchain résout ce problème. Plus fondamentalement, voir les détails de tx1 n'est parfois même pas nécessaire et la simple connaissance de sa simple existence peut permettre à un adversaire de devancer tx1 à travers son posséder tx2 et frauder l'utilisateur innocent qui a créé tx1. Par exemple, l'utilisateur pourrait être connu pour négocier un actif particulier à des heures régulières. Prévenir de telles attaques nécessite des atténuations qui évitent également les fuites de métadonnées [62]. Quelques solutions à ce problème existent, mais ils introduisent des retards et des problèmes d’utilisabilité. De la commande réseau à la commande finalisée avec FSS : Des opportunités pour être en avance se produire parce que les systèmes existants ne disposent d’aucun mécanisme pour garantir que l’ordre dans lequel les transactions apparaissent sur la chaîne respecte l’ordre des événements et le flux d’informations en dehors du réseau. Cela représente un problème résultant de déficiences dans la mise en œuvre d'applications (par exemple, des plateformes de trading) sur un blockchain. Idéalement, on s'assurer que les transactions sont validées sur le blockchain dans le même ordre qu'elles l'étaient créé et envoyé au réseau P2P de blockchain. Mais puisque le réseau blockchain

est distribué, aucune commande de ce type ne peut être capturée. FSS introduit donc des mécanismes pour se prémunir contre les violations de l'équité, qui surviennent uniquement en raison de la distribution nature du réseau blockchain. 5.2 Détails du FSS Figure 12 : Un pool de mémoire équitable avec deux chemins de transaction différents : directe et basé sur mempool. La figure 12 montre un schéma général du FSS. Pour garantir l'équité, le DON fournissant le FSS doit interférer avec le flux des transactions lorsqu'elles entrent dans MAINCHAIN. Des ajustements aux clients, aux smart contract sur MAINCHAIN, ou aux deux, peuvent être nécessaires. À un niveau élevé, le traitement des transactions par FSS peut être décomposé en trois phases, décrites ci-dessous : (1) Surveillance des transactions ; (2) Séquençage des transactions ; et (3) Comptabilisation des transactions. En fonction de la méthode de classement utilisée pour le séquençage des transactions, des étapes de protocole supplémentaires sont nécessaires, comme décrit dans la section suivante. 5.2.1 Traitement des transactions Surveillance des transactions : Nous envisageons deux approches différentes pour que le FSS puisse surveiller transactions utilisateur destinées à un smart contract spécifique, directes et basées sur mempool : • Directe : L'approche directe est conceptuellement la plus simple, mais nécessite des changements clients utilisateurs afin que les transactions soient envoyées directement à l'Oracle décentraliséNœuds du réseau, plutôt qu'aux nœuds de la chaîne principale. Le DON collecte transactions utilisateur destinées à un smart contract SC spécifique et les commande en fonction sur une politique de commande. Le DON envoie ensuite les transactions commandées au smart contract sur la chaîne principale. Certains mécanismes de commande nécessitent également l'approche directe car l'utilisateur qui crée une transaction doit cryptographiquement protégez-le avant de l’envoyer à la FSS. • Basé sur Mempool : pour faciliter l'intégration de FSS avec les clients existants, le DON peut utiliser Mempool Services (MS) pour surveiller le pool de mémoire de la chaîne principale et collecter transactions. Le transport direct sera probablement la mise en œuvre privilégiée pour de nombreux contrats, et nous pensons que cela devrait être assez pratique dans de nombreux cas. Nous discutons brièvement de la manière dont les DApps existantes pourraient être modifiées de manière minimale pour prendre en charge transmission directe tout en préservant une bonne expérience utilisateur. Nous décrivons les approches en utilisant Ethereum et MetaMask [6] puisque ce sont les choix les plus populaires aujourd'hui, mais les techniques mentionnées devraient s'étendre à d'autres chaînes et portefeuilles. Un Ethereum récent Proposition d'amélioration, "EIP-3085 : Wallet ajoute la méthode RPC de chaîne Ethereum" [100], facilitera le ciblage des chaînes Ethereum personnalisées (en utilisant un ID CHAIN différent de celui celui de MAINCHAIN pour empêcher les attaques par relecture) de MetaMask et d'autres portefeuilles basés sur un navigateur. Après la mise en œuvre de cette proposition, un DApp cherchant à utiliser un DON ajouterait simplement un seul appel de méthode à leur front-end pour pouvoir transmettre directement transactions vers n’importe quel DON exposant une API compatible Ethereum. En attendant, "EIP-712 : Ethereum données structurées typées hashing et signature" [49] fournit un léger alternative plus impliquée mais déjà largement déployée, où un utilisateur de DApp peut utiliser MetaMask pour signer des données structurées spécifiant une transaction DON. Le DApp peut envoyer ces données structurées signées au DON. Notons enfin que des approches hybrides sont également possibles. Par exemple, l'héritage les clients peuvent continuer à envoyer des transactions dans le pool de mémoire de la chaîne principale, mais c'est essentiel les transactions (par exemple, les rapports oracle) sont envoyées directement aux nœuds DON (en particulier, le ensemble de nœuds fournissant des rapports oracle tels que des mises à jour de flux de prix et l'ensemble de nœuds à condition que le FSS puisse se chevaucher ou être identique). Séquençage des transactions : L'objectif principal de FSS est de garantir que les transactions des utilisateurs sont ordonnées selon une politique prédéfinie. La nature de cette politique dépendent des besoins de l’application et des types d’ordres de transactions déloyales qu’elle vise à prévenir. Étant donné que le FSS sur le DON est capable de traiter les données et de maintenir l'état local, ils peuvent imposer une politique de séquencement arbitraire basée sur les informations disponibles. disponible aux oracles. Les politiques de commande particulières et leur mise en œuvre sont discutées ultérieurement dans la section 5.3.Validation des transactions : Après avoir collecté et ordonné les transactions des utilisateurs, reçues soit directement des utilisateurs, soit collectées à partir du mempool, le DON envoie ces transactions à la chaîne principale. En tant que tel, les interactions d'un DON avec la chaîne principale restent soumis à un ordre de transaction (potentiellement injuste) régi par les mineurs de la chaîne principale. Pour exploiter les avantages de la commande décentralisée des transactions, la cible intelligente Le contrat SC doit donc être conçu pour traiter le DON comme un citoyen de « première classe ». Nous distinguer deux approches : • Contrats DON uniquement : l'option de conception la plus simple consiste à avoir la chaîne principale intelligente. contract SC n'accepte que les transactions qui ont été traitées par le DON. Ceci s'assure que le smart contract traite les transactions dans l'ordre proposé par le DON, mais restreint de facto le smart contract à fonctionner dans un système basé sur un comité (c'est-à-dire que le comité DON a désormais le pouvoir continu de déterminer le classement et inclusion des transactions). • Contrats à deux classes : une conception privilégiée, plus granulaire, rend la chaîne principale intelligente Le contrat SC accepte les transactions provenant à la fois du DON et de l'héritage utilisateurs,10 mais place des « ralentisseurs » traditionnels sur les transactions qui n’ont pas été traitées par le DON. Par exemple, les transactions du DON peuvent être traitées immédiatement, alors que les transactions existantes sont « mises en mémoire tampon » par le smart contract pour une période de temps déterminée. Autres mécanismes standards pour empêcher le front-running tels que les schémas de validation-révélation ou les VDF [53] pourraient également être appliqués aux anciens transactions. Cela garantit que les transactions commandées par DON seront traitées dans l'ordre convenu, sans donner au DON le pouvoir indésirable de censurer transactions. Comme l'imposition de l'ordre des transactions par FSS nécessite que les transactions soient agrégées « hors chaîne », cette solution est naturellement combinée avec d'autres techniques d'agrégation visant à réduire les coûts de traitement en chaîne. Par exemple, après avoir collecté et commandant des transactions, le DON peut envoyer ces transactions à la chaîne principale en tant que une seule « transaction groupée » (par exemple, un rollup), réduisant ainsi la transaction globale frais. Exécution de l'ordre de transaction : Que ce soit dans une conception DON uniquement ou à deux classes, la chaîne principale smart contract SC et le DON doivent être co-conçus de manière à garantir que l'ordre des transactions du DON est respecté. Ici aussi, nous envisageons différents options de conception : • Numéros de séquence : le DON peut ajouter un numéro de séquence à chaque transaction et envoyer ces transactions dans le pool mémoire de la chaîne principale. Le principal 10Si la surveillance des transactions du DON est basée sur le mempool, les transactions héritées doivent être distinctes des transactions DON afin qu'elles ne soient pas collectées par le DON, par exemple via une balise spéciale. intégré à la transaction ou en spécifiant un prix de gaz particulier, par ex. Les transactions DON contiennent du gaz prix inférieurs à un certain seuil.La chaîne smart contract SC ignore les transactions qui arrivent « hors séquence ». Nous notez que dans ce contexte, les mineurs de la chaîne principale peuvent décider d'ignorer les DON l'ordre des transactions, provoquant ainsi l'échec des transactions. Il est possible, en conservant l'état (coûteux), que SC applique un ordre correct des transactions, quelque peu de la même manière que TCP met en mémoire tampon les paquets dans le désordre jusqu'à ce que les paquets manquants soient supprimés. reçu. • Transaction nonces : Pour de nombreux blockchains, et en particulier pour Ethereum, le L'approche de numérotation séquentielle ci-dessus peut exploiter les transactions intégrées nonce pour imposer que la chaîne principale smart contract SC traite les transactions dans l'ordre. Ici, les nœuds DON envoient des transactions à la chaîne principale via un seul compte de chaîne principale, protégé par une clé partagée entre les nœuds DON. Le compte la transaction nonce garantit que les transactions sont extraites et traitées dans le bon ordre. • Regrouper les transactions : le DON peut regrouper plusieurs transactions dans un rollup. (ou dans un bundle similaire à un rollup). La chaîne principale smart contract doit être conçu pour gérer de telles transactions globales. • Regrouper les transactions avec un proxy de chaîne principale : ici, le DON regroupe de la même manière les transactions en une seule « méta-transaction » pour la chaîne principale, mais s'appuie sur un proxy personnalisé smart contract pour décompresser les transactions et les relayer vers le contrat cible SC. Cette technique peut être utile pour la compatibilité existante. Les métatransactions agissent comme les rollup mais diffèrent en ce sens qu'elles consistent en un contenu non compressé. liste des transactions publiées une fois sur la chaîne principale. Cette dernière conception présente l'avantage de prendre en charge de manière transparente les transactions des utilisateurs qui sont eux-mêmes mandatés par le biais d'un contrat de chaîne principale avant d'atteindre l'objectif de DON contrat SC. Par exemple, considérons un utilisateur qui envoie une transaction vers un portefeuille contrat, qui à son tour envoie une transaction interne à SC. Attribution d'une séquence à une telle transaction serait délicat, à moins que le contrat de portefeuille de l'utilisateur ne soit spécialement conçu pour transmettre le numéro de séquence à chaque transaction interne à SC. De même, ces transactions internes ne peuvent pas être facilement regroupées en une métatransaction envoyée directement au SC. Nous discutons d'autres considérations de conception pour ces transactions par procuration ci-dessous. 5.2.2 Atomicité des transactions Notre discussion jusqu’à présent a implicitement supposé que les transactions interagissent avec un seul en chaîne smart contract (par exemple, un utilisateur envoie une demande d'achat à un échange). Pourtant, dans Dans des systèmes tels que Ethereum, une seule transaction peut consister en plusieurs transactions internes, par exemple, une smart contract appelant une fonction dans un autre contrat. Ci-dessous, nous décrire deux stratégies de haut niveau pour séquencer les transactions « multi-contrats », tandis que préservant l'atomicité de la transaction (c'est-à-dire la séquence d'actions prescrite par les transactions sont toutes exécutées dans le bon ordre, voire pas du tout).Forte atomicité : La solution la plus simple consiste à appliquer le FSS, comme décrit ci-dessus, directement à des transactions « multi-contrats » entières. Autrement dit, les utilisateurs envoient leurs transactions dans le réseau et FSS surveille, séquence et publie ces transactions sur le chaîne principale. Cette approche est techniquement simple, mais présente une limite potentielle : si un utilisateur la transaction interagit avec deux contrats SC1 et SC2 qui veulent tous deux tirer parti d'un effet de levier équitable services de séquençage, alors la politique de séquençage de ces deux contrats doit être cohérente. Autrement dit, étant donné deux transactions différentes tx1 et tx2 avec lesquelles chacune interagit à la fois SC1 et SC2, il ne faut pas que la politique de SC1 commande tx1 avant tx2 alors que la politique du SC2 prescrit l’ordre inverse. Pour la grande majorité des scénarios d’intérêt, nous envisageons que les politiques de séquençage adoptées par les différents contrats seront cohérentes. Par exemple, SC1 et SC2 peut vouloir que les transactions soient classées en fonction de leur heure d'arrivée approximative dans le mempool, et SC1 peut en outre souhaiter que certains rapports oracle soient toujours livrés en premier. Comme le ces dernières oracle signalent que les transactions n'interagissent pas avec SC2, les politiques sont cohérentes. Faible atomicité : Dans toute sa généralité, le FSS pourrait être appliqué au niveau des individus. transactions internes. Considérons des transactions de la forme tx = { ˜txpre, ˜txSC, ˜txpost}, constituées de quelques transaction(s) ˜txpre, qui aboutit à une transaction interne ˜txSC à SC, qui à son tour émet des transactions internes ˜txpost. La politique de séquençage du SC pourrait déterminer comment la transaction interne ˜txSC doit être ordonnée par rapport aux autres transactions envoyées vers SC, mais laissez ouvert l’ordre de séquençage pour ˜txpre et ˜txpost. Compte tenu des caractéristiques intrinsèques du traitement des transactions dans des systèmes tels que Ethereum, développer un service de séquençage ciblant des transactions internes spécifiques n'est pas simple. Avec un contrat SC spécialement conçu, cela peut être réalisé comme suit : 1. La transaction tx est envoyée dans le réseau et extraite (sans aucun séquençage réalisée par la FSS). Le ˜txpre initial est exécuté et appelle ˜txSC. 2. SC n'exécute pas ˜txSC et retourne. 3. FSS surveille les transactions internes de SC, les séquence et les publie à SC (c'est-à-dire en envoyant des transactions ˜txSC directement à SC). 4. SC traite les transactions ˜txSC reçues de FSS et émet les transactions internes ˜txpost qui résultent de ˜txSC. Avec cette approche, les transactions ne sont pas exécutées de manière entièrement atomique (c'est-à-dire la transaction tx est divisée en plusieurs transactions en chaîne), mais l'ordre des les transactions internes sont préservées. Cette solution implique un certain nombre de contraintes de conception. Par exemple, ˜txpre ne peut pas supposons que ˜txSC et ˜txpost seront exécutés. De plus, SC doit être conçu de manière à exécuter les transactions ˜txSC et ˜txpost pour le compte d'un certain utilisateur, même si elles étaientenvoyé par la FSS. Pour ces raisons, la solution « Atomicité forte » plus grossière ci-dessus est probablement préférable dans la pratique. Pour respecter des dépendances plus complexes, impliquant plusieurs transactions et leurs transactions internes respectives, le planificateur de transactions de FSS peut contenir des fonctions élaborées qui ressemblent à celles trouvées dans les gestionnaires de transactions des relations gestionnaires de bases de données. 5.3 Séquençage équitable des transactions Nous discutons ici de deux notions d'équité pour le séquençage des transactions et des implémentations correspondantes, qui peuvent être réalisées par FSS : l'équité des ordres basée sur une politique imposé par FSS et la préservation sécurisée de la causalité, ce qui nécessite des méthodes cryptographiques supplémentaires dans FSS. Équité des commandes : L'équité de l'ordre est une notion d'équité temporelle dans les protocoles de consensus qui a été formellement introduit pour la première fois par Kelkar et al. [144]. Kelkar et coll. visent à parvenir à une forme de politique naturelle dans laquelle les transactions sont commandés en fonction de l'heure à laquelle ils sont reçus pour la première fois par le DON (ou le réseau P2P, dans le cas d'un FSS basé sur mempool). Cependant, dans un système décentralisé, les nœuds peuvent voir les transactions arriver dans un ordre différent. Etablir une commande totale sur toutes les transactions est le problème même résolu par le protocole de consensus qui sous-tend CHAÎNE PRINCIPALE. Kelkar et coll. [144] introduisent donc une notion plus faible qui peut être réalisé avec l’aide d’un réseau Oracle décentralisé, appelé « équité des commandes en bloc ». Il regroupe les transactions que le DON a reçues pendant un intervalle de temps dans un « bloquer » et insère toutes les transactions du bloc simultanément et à la même position (c'est-à-dire la hauteur) dans MAINCHAIN. Ils sont donc ordonnés ensemble et doivent être exécutables en parallèle, sans créer de conflits entre eux. En gros, l’équité de l’ordre stipule alors que si une grande fraction des nœuds voit la transaction τ1 avant τ2, alors τ1 sera séquencé avant ou dans le même bloc que τ2. En imposant une mesure aussi grossière la granularité de l'ordre des transactions, les possibilités d'attaques frontales et autres attaques liées à l'ordre sont considérablement réduites. Kelkar et coll. proposent une famille de protocoles appelée Aequitas [144], qui aborde différents modèles de déploiement, y compris les paramètres réseau synchrone, partiellement synchrone et asynchrone. Les protocoles Aequitas imposent une surcharge de communication importante par rapport au consensus de base BFT et ne sont donc pas idéaux pour une utilisation pratique. Nous pensons cependant que des variantes pratiques d'Aequitas apparaîtront et pourront être utilisées pour le séquençage des transactions dans FSS et d'autres applications. Certains régimes connexes ont déjà été proposés qui ont moins de formalisme d'accompagnement et des propriétés plus faibles, par exemple, [36, 151, 236], mais de meilleures performances pratiques. Ces programmes peuvent être soutenus en FSS également. Il convient également de noter que le terme « équité » apparaît ailleurs dans le blockchain littérature avec un sens différent, à savoir l'équité dans le sens d'opportunité pourmineurs proportionnellement à leurs ressources engagées [106, 181] ou pour validators en termes de l’égalité des chances [153]. Préservation sécurisée de la causalité : L'approche la plus connue pour empêcher le frontrunning et autres violations d'ordre sur les plates-formes distribuées repose sur la cryptographie. techniques. Leur caractéristique commune est de masquer les données de transaction elles-mêmes, en attendant l'ordre au niveau de la couche consensus a été établi et pour révéler les données de transaction plus tard pour le traitement. Cela préserve l'ordre causal entre les transactions qui sont exécuté par le blockchain. Les notions de sécurité et protocoles cryptographiques pertinents ont été considérablement développés avant l’avènement des blockchains [71, 190]. Les conditions de sécurité de la « causalité d'entrée » [190] et de la « préservation sécurisée de la causalité » [71, 97] exigent formellement qu'aucune information sur une transaction ne soit connue. avant que la position de cette transaction dans l’ordre global n’ait été déterminée. Un adversaire ne doit pas être en mesure de déduire aucune information avant ce moment, de manière cryptographique. sens fort. On peut distinguer quatre techniques cryptographiques pour préserver la causalité : • Protocoles de validation-révélation [29, 142, 145] : au lieu d'annoncer une transaction en clair, seul un engagement cryptographique sur la transaction est diffusé. Une fois que toutes les transactions validées mais cachées ont été ordonnées (au début du blockchain systèmes sur MAINCHAIN lui-même, mais ici par FSS), l'expéditeur doit ouvrir l'engagement et révéler les données de la transaction dans un intervalle de temps prédéterminé. Le réseau vérifie ensuite que l'ouverture satisfait à l'engagement antérieur. Le les origines de cette méthode datent d’avant l’avènement des blockchains. Bien qu’elle soit particulièrement simple, cette approche présente des inconvénients considérables et n’est pas facile à mettre en œuvre pour deux raisons. Premièrement, puisque seul l’engagement existe au niveau du protocole de commande, la sémantique de la transaction ne peut être validé lors du consensus. Un aller-retour supplémentaire chez le client est requis. Mais, plus sévèrement, la possibilité qu'aucune ouverture ne soit possible jamais arriver, ce qui pourrait équivaloir à une attaque par déni de service. De plus, il Il est difficile de déterminer si l’ouverture est valide dans un contexte cohérent et distribué. manière car tous les participants doivent se mettre d’accord sur le fait que l’ouverture soit arrivée dans le temps. • Protocoles de validation-révélation avec récupération retardée [145] : un défi avec le L’approche commit-reveal est qu’un client peut s’engager dans une transaction de manière spéculative et la révéler plus tard uniquement si les transactions ultérieures la rendent rentable. Un une variante récente de l'approche commit-reveal améliore la résilience contre cela une sorte de mauvaise conduite. En particulier, le protocole TEX [145] résout ce problème en utilisant une approche intelligente dans laquelle les transactions cryptées incluent une clé de déchiffrement pouvant être obtenu en calculant une fonction de retard vérifiable (VDF) [53, 221]. Si un client ne parvient pas à déchiffrer sa transaction en temps opportun, d'autres personnes dans le système déchiffreront en son nom en résolvant un casse-tête cryptographique moyennement difficile.• Chiffrement à seuil [71, 190] : cette méthode exploite ce que DON peut effectuer opérations cryptographiques à seuil. Supposons que FSS maintient un chiffrement public key pkO et les oracle partagent entre eux la clé privée correspondante. Les clients chiffrent ensuite les transactions sous pkO et les envoient au FSS. Commandes FSS transactions sur le DON, puis les décrypte, et enfin les injecte dans MAINCHAIN dans l’ordre fixe. Le cryptage garantit donc que la commande est non pas basé sur le contenu de la transaction, mais sur le fait que les données elles-mêmes sont disponibles lorsque nécessaire. Cette méthode a été initialement proposée par Reiter et Birman [190] et affinée plus tard par Cachin et al. [71], où il a été intégré avec un consensus autorisé protocole. Des travaux plus récents ont exploré l'utilisation de la cryptographie à seuil comme mécanisme de niveau consensus pour les messages génériques [33, 97] et pour les calculs généraux avec des données partagées [41]. Comparé aux protocoles de révélation de validation, le chiffrement à seuil empêche les simples attaques par déni de service (bien qu'il faille faire preuve de prudence étant donné le coût de calcul du décryptage). Il permet au DON d'avancer de manière autonome, à son rythme et sans en attendant d'autres actions du client. Les transactions peuvent être validées immédiatement après avoir été déchiffrées. De plus, les clients chiffrent toutes les transactions avec un seul clé pour le DON et le modèle de communication reste le même qu'avec les autres transactions. Gérer la clé de seuil en toute sécurité et avec des nœuds changeants dans O, cependant, peut poser des difficultés supplémentaires. • Partage de secret engagé [97] : au lieu de chiffrer les données de transaction sous une clé détenue par le DON, le client peut également la partager en secret pour les nœuds en O. Grâce à un système de partage de secrets hybride et informatiquement sécurisé, la transaction est d’abord chiffré à l’aide d’un chiffre symétrique avec une clé aléatoire. Seule la clé symétrique correspondante est partagée et le texte chiffré est soumis au DON. Le client doit envoyer un partage de clé à chaque nœud en O à l'aide d'un message chiffré séparément. Les étapes restantes du protocole sont les mêmes que pour le seuil cryptage, sauf que les données de transaction sont déchiffrées avec le chiffrement symétrique algorithme après avoir reconstruit la clé par transaction à partir de ses partages. Cette méthode ne nécessite pas la configuration ou la gestion d'un système de cryptographie à clé publique associé au DON. Cependant, les clients doivent connaître les nœuds dans O et communiquer dans un contexte sécurisé avec chacun d’eux, ce qui place charge supplémentaire pour les clients. Bien que les méthodes cryptographiques offrent une protection complète contre les informations fuyant les transactions soumises au réseau, ils ne cachent pas les métadonnées. Pour Par exemple, une adresse IP ou une adresse Ethereum de l'expéditeur pourrait toujours être utilisée par un adversaire pour effectuer des attaques de front et autres. Diverses mesures améliorant la confidentialité les techniques déployées au niveau de la couche réseau, par exemple [52, 95, 107], ou de la couche transaction, par exemple, [13, 65], serait nécessaire pour atteindre cet objectif. L'impact d'une pièce particulière des métadonnées, à savoir à quel contrat une transaction est envoyée, peuvent être (partiellement) masquéesen multiplexant de nombreux contrats sur le même DON. Dissimulation cryptographique des transactions en soi n’empêche pas non plus la priorisation des transactions par des entités corrompues. DON nœuds en collusion avec les expéditeurs de transactions. La causalité sécurisée garantie par les protocoles cryptographiques complète les garanties d'équité de l'ordre pour toute politique, et nous avons l'intention d'explorer une combinaison des deux. méthodes, lorsque cela est possible. Si un adversaire ne peut pas tirer un avantage significatif de en observant les métadonnées, les protocoles sécurisés de préservation de la causalité pourraient être utilisés parallèlement une approche de commande naïve également. Par exemple, les nœuds oracle peuvent écrire des transactions à L dès leur réception, sans duplication. Les transactions seraient alors classés en fonction de leur apparition sur L et ensuite décryptés. Nous prévoyons également d’envisager l’utilisation des TEE comme moyen de contribuer à faire respecter un ordre équitable ; pour Par exemple, Tesseract [44] peut être considéré comme réalisant une forme d'ordre causal, mais un renforcé par la capacité du TEE à traiter les transactions sous forme explicite tout en en gardant leur confidentialité. 5.4 Considérations relatives à la couche réseau Jusqu'à présent, notre description du FSS s'est principalement concentrée sur le problème de l'application du principe L’ordre finalisé des transactions correspond à leur ordre observé dans le réseau. Ci-après, nous considérons les problèmes d'équité qui pourraient survenir au niveau de la couche réseau elle-même. Les traders à haute fréquence sur les marchés électroniques conventionnels investissent des sommes considérables ressources pour obtenir une vitesse de réseau supérieure [64], et les traders sur les bourses de crypto-monnaie présentent un comportement similaire [90]. La vitesse du réseau confère un avantage à la fois observer les transactions des autres parties et soumettre des transactions concurrentes. Un remède déployé dans la pratique et popularisé dans le livre Flash Boys [155] est le « ralentisseur » introduit initialement dans l'échange IEX [128] et plus tard dans d'autres échanges [179] (avec résultats mitigés [19]). Ce mécanisme impose un délai (350 microsecondes en IEX) à l'accès au marché, dans le but de neutraliser les avantages en vitesse. Des preuves empiriques, par ex. [128], soutient son efficacité à diminuer certains échanges coûts pour les investisseurs ordinaires. FSS peut être utilisé simplement pour mettre en œuvre un système asymétrique. ralentisseur – celui qui retarde les transactions entrantes. Budish, Cramton et Shim [64] soutiennent que l'exploitation des avantages de la vitesse est incontournable sur les marchés en temps continu, et plaident en faveur d'un remède structurel dans le forme de marchés basés sur des enchères par lots. Mais cette approche n’a pas été largement adoptée sur les plateformes de trading existantes. Les systèmes commerciaux conventionnels sont centralisés et reçoivent généralement des transactions via une seule connexion réseau. En revanche, dans un système décentralisé, il est possible de observez la propagation des transactions à partir de plusieurs points de vue. Par conséquent, il est possible d’observer des comportements tels que l’inondation du réseau dans un réseau P2P. Nous avons l'intention explorer les approches de couche réseau du FSS qui aident les développeurs à spécifier des politiques interdire de tels comportements de réseau indésirables.5.5 Politiques d’équité au niveau de l’entité L’équité des ordres et la causalité sécurisée visent à imposer un ordre aux transactions qui respecte l’époque à laquelle ils ont été créés et soumis pour la première fois au réseau. Une limite de cette notion d'équité est qu'elle n'empêche pas les attaques dans lesquelles un adversaire obtient un avantage en inondant un système avec de nombreuses transactions, une stratégie observée dans la nature comme moyen d'effectuer des transactions efficaces dans les ventes token [159] et de créer une congestion entraînant la liquidation des positions de dette garantie (CDP) [48]. En d’autres termes, l’équité de l’ordre impose l’équité à l’égard des transactions, et non des joueurs. Tel que démontré dans le système CanDID [160], il est possible d'utiliser des outils oracle tels que DECO ou crieur public en collaboration avec un comité de nœuds (tels qu'un DON) pour atteindre diverses formes de résistance Sybil tout en protégeant la vie privée. Les utilisateurs peuvent enregistrer des identités et fournir la preuve de leur caractère unique sans divulguer leur identité. Les informations d’identification résistantes à Sybil offrent une approche possible pour enrichir l’ordre des transactions politiques de manière à limiter les possibilités d’attaques par inondations. Par exemple, un La vente token peut autoriser une seule transaction par utilisateur enregistré, lorsque l'inscription nécessite une preuve du caractère unique d'un identifiant national, tel qu'un numéro de sécurité sociale. Une telle approche n’est pas infaillible, mais peut s’avérer utile pour atténuer les attaques par inondation de transactions.

Le cadre d'exécution des transactions DON

(DON-TEF) DONs fournira oracle et un support de ressources décentralisées pour les solutions de couche 2 au sein ce que nous appelons le cadre d'exécution de transactions décentralisées du réseau Oracle (DONTEF) ou TEF en abrégé. Aujourd'hui, la fréquence des mises à jour des contrats DeFi est limitée par les latences de la chaîne principale, par exemple, l'intervalle de bloc moyen de 10 à 15 secondes dans Ethereum [104], ainsi que le coût de poussant de grandes quantités de données sur la chaîne et un débit de calcul/tx limité : des approches de mise à l'échelle motivantes telles que le partitionnement [148, 158, 232] et l'exécution de couche 2 [5, 12, 121, 141, 169, 186, 187]. Même les blockchain avec des temps de transaction beaucoup plus rapides, par exemple, [120], ont proposé des stratégies de mise à l'échelle qui impliquent un calcul hors chaîne [168]. TEF est censé agir comme une ressource de couche 2 pour de tels systèmes de couche 1/MAINCHAIN. Grâce à TEF, les DON peuvent prendre en charge des mises à jour plus rapides dans un contrat MAINCHAIN tout en conserver les principales assurances de confiance fournies par la chaîne principale. Le TEF peut accompagner l'un des nombreux paradigmes et techniques d'exécution de couche 2, y compris les rollups,11 rollup optimistes, Validium, etc., ainsi qu'un modèle de confiance à seuil dans lequel DON les nœuds exécutent des transactions. Le TEF est complémentaire du FSS et destiné à le soutenir. En d'autres termes, n'importe quel Les applications exécutées dans le TEF peuvent utiliser FSS. 11Souvent appelés « zk-rollups », un terme inapproprié, car ils n’ont pas nécessairement besoin de preuves de connaissance nulle.

6.1 Présentation du TEF Le TEF est un modèle de conception pour la construction et l'exécution d'un hybride performant smart contract SC. Conformément à l’idée principale des smart contract hybrides, le TEF implique un décomposition du SC en deux morceaux : (1) Ce que nous appelons dans le contexte du TEF une ancre contrat SCa sur MAINCHAIN et (2) DON exécution logique que nous appelons l'exécutable TEF. Nous utilisons ici SC pour désigner le contrat logique mis en œuvre par la combinaison de SCa et s'attendre. (Comme indiqué ci-dessus, nous prévoyons de développer des outils de compilation pour décomposer un contractez automatiquement SC dans ces composants.) L'exécutable TEF est le moteur qui traite les transactions des utilisateurs dans SC. Il peut s'exécuter de manière performante, car il s'exécute sur DON. Il a plusieurs fonctions : • Ingestion de transactions : exect reçoit ou récupère les transactions des utilisateurs. Cela peut le faire directement, c'est-à-dire via la soumission de transaction sur le DON, ou via le MAINCHAIN pool de mémoire utilisant MS. • Exécution rapide des transactions : exect traite les transactions impliquant des actifs au sein de SC. Il le fait localement, c'est-à-dire sur le DON. • Accès oracle/adaptateur rapide et peu coûteux : exect dispose d'un accès natif aux rapports oracle et d'autres données d'adaptateur conduisant, par exemple, à un actif plus rapide, moins cher et plus précis prix que l’exécution MAINCHAIN. De plus, l'accès hors chaîne oracle réduit le coût de fonctionnement du oracle, donc le coût d’utilisation du système, en évitant stockage en chaîne coûteux. • Synchronisation : exect envoie périodiquement les mises à jour de DON vers MAINCHAIN, mettant ainsi à jour SCa. Le contrat d’ancrage est le frontal MAINCHAIN ​​de SC. En tant que composant de confiance plus élevée de SC, il répond à plusieurs objectifs : • Conservation des actifs : les fonds des utilisateurs sont déposés, détenus et retirés de SCa. • Vérification de la synchronisation : SCa peut vérifier l'exactitude des mises à jour d'état lorsqu'elles sont exécutées. synchronise, par exemple, les SNARK attachés aux rollup. • Garde-corps : la SCa peut inclure des dispositions visant à protéger contre la corruption ou les défaillances. en exect. (Voir la section 7 pour plus de détails.) Dans TEF, les fonds des utilisateurs sont conservés sur MAINCHAIN, ce qui signifie que le DON n'est lui-même pas dépositaire. En fonction du choix du mécanisme de synchronisation (voir ci-dessous), les utilisateurs peuvent avoir besoin faire confiance au DON uniquement pour des rapports oracle précis et une synchronisation rapide avec MAINCHAIN. Le modèle de confiance qui en résulte est très similaire à celui des DEX basés sur un carnet de commandes, par exemple [2], qui comprennent aujourd'hui généralement un composant hors chaîne pour l'appariement des ordres et un composant en chaîne pour la compensation et le règlement.Pour reprendre le vocabulaire des systèmes de paiement, on peut considérer excet comme le composant de SC est responsable de la compensation, tandis que SCa s'occupe du règlement. Voir la Fig. 13 pour un schéma représentation du TEF. Figure 13 : Schéma du TEF. Dans cet exemple, les transactions transitent par le mempool de MAINCHAIN via MS au DON. Les avantages du TEF : Le TEF présente trois avantages principaux : • Hautes performances : SC hérite du débit beaucoup plus élevé du DON que celui du MAINCHAIN. pour les transactions et les rapports oracle. De plus, exect peut traiter les transactions plus rapidement et répondre aux rapports oracle plus rapidement qu'une implémentation sur MAINCHAIN ​​seule. • Frais réduits : le processus de synchronisation est moins sensible au temps que le traitement des transactions, et les transactions peuvent être envoyées du DON vers MAINCHAIN ​​par lots. Par conséquent, les frais en chaîne par transaction (par exemple, les coûts du gaz) avec cette approche sont bien inférieurs à ceux d'un contrat fonctionnant uniquement sur MAINCHAIN. • Confidentialité : Les mécanismes de confidentialité du DON peuvent être amenés à porter sur SC.

Limites du TEF : L'une des limites de TEF est qu'il ne prend pas en charge les retraits, car ils se produisent uniquement sur MAINCHAIN : lors de l'envoi d'une demande de retrait vers SCa, un utilisateur devra peut-être attendre qu'exect effectue une mise à jour d'état qui inclut le transaction de retrait avant qu’elle puisse être approuvée. Nous discutons de quelques remèdes partiels, cependant, à la section 6.2. Une autre limitation du TEF est qu'il ne prend pas en charge la composition atomique de DeFi. contrats sur MAINCHAIN, en particulier la possibilité d'acheminer les actifs via plusieurs DeFi contrats en une seule transaction. Le TEF peut cependant prendre en charge une telle atomicité entre Contrats DeFi exécutés sur le même DON. Nous discutons également de certaines façons de résoudre ce problème problème dans la section 6.2. 6.2 Routage des transactions Les transactions pour SC peuvent être envoyées par les utilisateurs directement au DON ou peuvent être acheminées via le mempool dans MAINCHAIN (via FSS). Il existe quatre types de transactions distincts, chacun dont nécessitent une manipulation différente : Opérations intra-contractuelles : Parce qu'il évite les complications de la dynamique des gaz, le TEF offre à SC plus de flexibilité dans la gestion des transactions qu'elle ne le ferait. disponible dans un contrat de couche 1. Par exemple, alors qu'une transaction mempool dans Ethereum peut être écrasé par une nouvelle transaction avec un prix du gaz plus élevé, SC peut traiter une transaction qui opère sur des actifs au sein de SC comme faisant autorité dès qu'elle devient visible dans le pool de mémoire. Par conséquent, SC n'a pas besoin d'attendre qu'une transaction soit confirmée dans un bloc, ce qui entraîne une latence considérablement réduite. Proxy : Un utilisateur peut souhaiter envoyer une transaction τ à SC via un contrat de portefeuille ou autre contrat sur MAINCHAIN. Il est possible pour le DON de simuler l'exécution de τ sur MAINCHAIN pour déterminer si cela entraîne une transaction ultérieure vers SC. Si tel est le cas, τ peut être séquencé avec d’autres transactions pour SC qui le font. Il y en a quelques-uns possibilités sur la manière dont le DON identifie de telles transactions : (1) Le DON peut simuler toutes les transactions dans le mempool (une approche coûteuse) ; (2) Certains contrats ou les types de contrats, par exemple les portefeuilles, peuvent être répertoriés pour être surveillés par le DON ; ou (3) les utilisateurs peuvent annoter les transactions pour l'inspection DON. Les choses se compliquent lorsqu’une seule transaction interagit avec deux contrats, SC1 et SC2, qui utilisent tous deux des services de séquençage équitable et ont des politiques de commande incompatibles. Le DON pourrait, par exemple, séquencer τ au plus tard qui est compatible avec les deux. Dépôts : Une transaction déposant un actif MAINCHAIN dans SC doit être confirmée dans un bloc avant que SC puisse la traiter comme valide. Lorsqu'il détecte l'exploitation minière d'un transaction qui envoie des actifs (par exemple, Ether) dans SCa, exect peut confirmer instantanément ledépôt. Par exemple, il peut appliquer un prix actuel déclaré oracle sur le DON au atout. Retraits : Comme indiqué ci-dessus, une limitation du TEF est que les retraits ne peuvent pas toujours être exécutés instantanément. Dans un modèle d'exécution de type rollup, le retrait La demande doit être séquencée avec d'autres transactions, c'est-à-dire cumulée, afin d'être traitée en toute sécurité. traité. Il existe cependant quelques solutions partielles à cette limitation. Si le DON peut calculer rapidement une preuve de validité rollup jusqu'à la transaction de retrait, alors l'observation de la transaction τ d'un utilisateur dans l'exécutable mempool peut envoyer une transaction de mise à jour d'état τ ′ pour τ à un prix du gaz plus élevé, une sorte de front-running bénéfique. À condition que τ ne soit pas extrait avant que τ ′ n'atteigne le mempool, τ ′ précédera τ, et τ entraînera un retrait approuvé. Dans une variante TEF où DON est utilisé pour calculer les mises à jour d'état (voir la variante de signature de seuil ci-dessous), le DON peut alternativement déterminer hors chaîne si τ doit être approuvé compte tenu de l'état du SC lors de son exécution. Le DON peut alors envoyer une transaction τ ′ qui approuve le retrait τ – sans effectuer de paiement complet. mise à jour de l'état. Si cette approche n'est pas possible, ou dans les cas où elle ne réussit pas, une procédure initiée par DON la transaction τ ′ peut envoyer des fonds à l'utilisateur en réponse à τ afin que l'utilisateur n'ait pas besoin lancer une transaction supplémentaire. 6.3 Synchronisation L'exécutable TEF envoie périodiquement les mises à jour de DON vers MAINCHAIN, mettre à jour l’état de SCa dans un processus que nous appelons synchronisation. La synchronisation peut être envisagée comme propagation des transactions de couche 2 vers la couche 1, de sorte que TEF peut s'appuyer sur n'importe lequel d'un certain nombre des techniques existantes à cet effet, y compris rollups [5, 12, 16, 69], optimistes rollups [10, 11, 141], Validium [201] ou signature de seuil de base, par exemple seuil BLS, Schnorr, ou ECDSA [24, 54, 116, 202]. En principe, les environnements d'exécution fiables peut également attester de l'exactitude des changements d'état, offrant un système beaucoup plus performant. alternative aux rollups, mais avec un modèle de confiance dépendant du matériel. (Voir, par exemple, [80].) Ci-dessous, nous comparons ces options de synchronisation par rapport à trois propriétés clés dans TEF : • Disponibilité des données : où l'état du SC est-il stocké ? Au moins trois options sont disponible en TEF : sur le MAINCHAIN, sur un DON, ou par un stockage tiers fournisseurs tels que IPFS. Ils obtiennent différentes garanties de sécurité, de disponibilité niveaux et profils de performance. En bref, le stockage de l'état sur le MAINCHAIN permet auditabilité en chaîne et élimine la dépendance à l'égard d'une quelconque partie pour la disponibilité de l'État ; d'un autre côté, le stockage hors chaîne peut réduire les coûts de stockage et améliorer débit, au prix de la confiance dans les fournisseurs de stockage (DON ou tiers) pour disponibilité des données. Bien entendu, des modèles flexibles combinant ces options sont également possible. Nous indiquons la forme requise de disponibilité des données dans le tableau 1.• Garanties d'exactitude : comment SCa vérifie-t-elle l'exactitude des mises à jour ? poussé par Exect ? Cela affecte la charge de calcul sur exect et SCa et le latence de synchronisation (voir ci-dessous). • Latence : la latence de synchronisation a trois facteurs contributifs : (1) Le temps nécessaire par exemple, générer une transaction de synchronisation τsync ; (2) Le temps nécessaire pour τsync à confirmer sur MAINCHAIN ; et (3) Le temps nécessaire à τsync pour prendre effet sur SCa. En TEF, la latence est particulièrement importante pour les retraits (mais moins pour les transactions intra-contractuelles) car les retraits nécessitent nécessairement un (au moins partielle) synchronisation d'état. Synchronisation choix Données disponibilité Exactitude garanties Latence Cumul [5, 12, 16, 69] En chaîne Preuves de validité Temps nécessaire à la génération preuves de validité (par exemple, procès-verbaux dans les systèmes actuels) Validium [201] Hors chaîne Preuves de validité Idem que ci-dessus Optimiste rollup [10, 11, 141] En chaîne Preuves de fraude Durée du défi période (par exemple, jours ou semaines) Signature de seuil [24, 54, 116, 202] Flexible Seuil de signatures par DON Instantané Environnements d'exécution fiables [80] Flexible Basé sur le matériel attestations Instantané Tableau 1 : Diverses options de synchronisation dans TEF et leurs propriétés. Le tableau 1 résume ces propriétés dans les cinq principales options de synchronisation dans TEF. (Remarque que nous n'avons pas l'intention de comparer ces technologies en tant que mise à l'échelle autonome de couche 2 solutions. Pour cela, nous renvoyons les lecteurs à, par exemple, [121].) Nous discutons maintenant de chaque option de synchronisation. Cumuls : Un rollup [69] est un protocole dans lequel la transition d'état effectuée par un le lot de transactions est calculé hors chaîne. Le changement d'état se propage ensuite sur MAINCHAIN. Pour implémenter rollups, l'ancre smart contract SCa stocke une représentation compacte Rstate (par exemple, une racine Merkle) de l'état réel. Pour synchroniser, exect envoie τsync = (T, R′ état) à SCa où T est l’ensemble des transactions qu’il a traitées depuis le derniersynchronisation et R′ state est la représentation compacte du nouvel état calculée en appliquant transactions en T vers l’état précédent Rstate. Il existe deux variantes populaires qui diffèrent dans la manière dont SCa vérifie les mises à jour d'état dans τsync. Le premier, (zk-)rollups, joint un argument succinct de justesse, parfois appelé une preuve de validité, pour la transition Rstate →R′ état. Pour implémenter cette variante, exécutez calcule et soumet la preuve de validité (par exemple, une preuve zk-SNARK) avec τsync, prouvant que R′ L’état est le résultat de l’application de T à l’état actuel de SCa. L'ancre Le contrat n'accepte la mise à jour de l'état qu'après avoir vérifié la preuve. Les rollup optimistes n'incluent pas d'arguments d'exactitude, mais ont staking et des procédures de contestation qui facilitent la vérification distribuée des transitions d’état. Pour cela Variante rollup, SCa accepte provisoirement τsync en supposant qu'il est correct (d'où l'optimisme) mais τsync ne prend effet qu'après une période de contestation, pendant laquelle toute partie la surveillance de MAINCHAIN peut identifier les mises à jour d'état erronées et informer SCa de prendre actions nécessaires (par exemple, pour restaurer l'état et infliger une pénalité en cas d'exécution). Les deux variantes rollup assurent la disponibilité des données en chaîne, au fur et à mesure que les transactions sont publiées en chaîne, à partir duquel l'état complet peut être construit. La latence des zk-rollups est dominé par le temps nécessaire pour générer des preuves de validité, qui est généralement au ordre de minutes dans les systèmes existants [16] et verra probablement des améliorations au fil du temps. Les rollup optimistes, en revanche, ont une latence plus élevée (par exemple, jours ou semaines) car la période de contestation doit être suffisamment longue pour que les preuves de fraude fonctionnent. Le L'implication d'une confirmation lente est subtile et parfois spécifique au schéma, de sorte que une analyse approfondie est hors de portée. Par exemple, certains régimes considèrent le paiement transactions comme « finales sans confiance » [109] avant que la mise à jour de l'état ne soit confirmée, car un un utilisateur régulier pourrait vérifier un rollup beaucoup plus rapidement que le MAINCHAIN. Validium : Validium est une forme de (zk-)rollup qui rend les données disponibles uniquement hors chaîne et ne conserve pas toutes les données sur MAINCHAIN. Plus précisément, exect envoie uniquement le nouveau l'état et la preuve mais pas les transactions à SCa. Avec la synchronisation de style Validium, exécutez et le DON qui l'exécute sont les seuls à stocker l'état complet et qui exécutent des transactions. Comme pour les zk-rollups, la latence de synchronisation est dominée par la validité temps de génération de preuve. Contrairement aux zk-rollups, cependant, la synchronisation de style Validium réduit le le coût de stockage et augmente le débit. Signature du seuil par DON : En supposant qu'un seuil de DON nœuds soit honnête, un L'option de synchronisation simple et rapide consiste à faire en sorte que les nœuds DON signent collectivement le nouvel état. Cette approche peut prendre en charge la disponibilité des données en chaîne et hors chaîne. Notez que si les utilisateurs font confiance à DON pour les mises à jour oracle, ils n'ont pas besoin de lui faire davantage confiance pour accepter mises à jour d'état, car elles le sont déjà dans un modèle de confiance à seuil. Un autre avantage de la signature à seuil est à faible latence. Prise en charge de nouveaux formats de signature de transaction proposé dans EIP-2938 [70] et connu sous le nom d'abstraction de compte établirait un seuil la signature est considérablement plus facile à mettre en œuvre, car elle éliminerait le besoin de seuil ECDSA, qui implique des protocoles considérablement plus complexes (par exemple, [116, 117, 118])que des alternatives telles que les signatures à seuil Schnorr [202] ou BLS [55]. Environnements d'exécution de confiance (TEE) : Les TEE sont des environnements d'exécution isolés (généralement réalisés par du matériel) qui visent à fournir de solides protections de sécurité. pour les programmes exécutés à l’intérieur. Certains TEE (par exemple, Intel SGX [84]) peuvent produire des preuves, connues sous le nom d'attestations, qu'une sortie est correctement calculée par un programme spécifique pour une entrée particulière12. Une variante de synchronisation TEF basée sur TEE peut être implémentée en remplacer les preuves en (zk-)rollups ou Validium par des attestations TEE en utilisant des techniques à partir de [80]. Comparés aux preuves sans connaissance utilisées dans les rollup et Validium, les TEE sont beaucoup plus performant. Par rapport à la signature à seuil, les TEE suppriment la complexité de générer des signatures ECDSA seuil car il ne doit en principe y avoir qu'un seul TEE impliqué. L'utilisation des TEE introduit cependant des hypothèses de confiance supplémentaires dépendant du matériel. On peut également combiner les TEE avec la signature de seuil pour créer de la résilience contre la compromission d'une fraction des instances TEE, bien que cette mesure de protection réintroduit la complexité de la génération de signatures ECDSA à seuil. Flexibilité supplémentaire : Ces options de synchronisation peuvent être affinées pour offrir plus de flexibilité des manières suivantes. • Déclenchement flexible : l'application TEF peut déterminer les conditions dans lesquelles la synchronisation est déclenchée. Par exemple, la synchronisation peut être basée sur des lots, par exemple après toutes les N transactions, basées sur le temps, par exemple tous les 10 blocs, ou basées sur des événements, par exemple, se produisent chaque fois que les prix cibles des actifs évoluent de manière significative. • Synchronisation partielle : elle est possible et dans certains cas souhaitable (par exemple, avec rollups, la synchronisation partielle peut réduire la latence), par exemple pour fournir une synchronisation rapide des petits quantités d'état, effectuant une synchronisation complète peut-être seulement périodiquement. Par exemple, exect peut approuver une demande de retrait en mettant à jour le solde d'un utilisateur dans SCa sans autrement mettre à jour l’état MAINCHAIN. 6.4 Réorganisations Réorganisations de la blockchain résultant de l'instabilité du réseau ou même d'attaques à 51 % peut constituer une menace pour l’intégrité d’une chaîne principale. En pratique, les adversaires ont utilisé pour qu'ils montent des attaques à double dépense [34]. Même si de telles attaques contre les grandes chaînes sont difficiles à monter, ils restent réalisables pour certaines chaînes [88]. Parce qu'il fonctionne indépendamment de MAINCHAIN, un DON offre l'intéressant possibilité d’observer et d’apporter quelques protections contre les réorganisations associées attaques. Par exemple, un DON peut signaler à un contrat SC de confiance sur MAINCHAIN ​​l'existence d'un fork concurrent d'une certaine longueur seuil τ. Le DON peut en outre 12Des détails supplémentaires peuvent être trouvés à l’annexe B.2.1. Ils ne sont pas nécessaires à la compréhension.

fournir la preuve, dans un contexte PoW ou PoS, de l'existence d'un tel fork. Le Le contrat SC peut mettre en œuvre des actions défensives appropriées, telles que la suspension de l'exécution de transactions ultérieures pendant un certain temps (par exemple, pour permettre aux échanges de mettre sur liste noire les transactions doublement dépensées). actifs). Notez que même si un adversaire lançant une attaque à 51% peut chercher à censurer rapports d'un DON, une contre-mesure en SC consiste à exiger des rapports périodiques du DON afin de traiter des transactions (c'est-à-dire un battement de cœur) ou d'exiger un nouveau rapport pour valider une transaction de grande valeur. Bien que de telles alertes de bifurcation soient en principe un service général, le DON peut fournir à diverses fins, notre plan est de les intégrer au TEF.

Minimisation de la confiance

En tant que système décentralisé avec la participation d'un ensemble hétérogène d'entités, le Le réseau Chainlink offre une protection solide contre les pannes, tant en termes de vivacité (disponibilité) que de sécurité (intégrité du rapport). La plupart des systèmes décentralisés varient cependant le degré de décentralisation de leurs éléments constitutifs. Ceci est vrai même pour les grands systèmes, où une décentralisation limitée parmi les mineurs [32] et les intermédiaires [51] sont présents depuis longtemps. Le but de tout effort de décentralisation est de minimiser la confiance : nous cherchons à réduire les effets néfastes de la corruption ou de la défaillance systémique au sein du réseau Chainlink, même si en raison d'un DON malveillant. Notre principe directeur est le principe du moindre privilège [197]. Les composants du système et les acteurs au sein du système doivent avoir des privilèges strictement limités pour permettre uniquement la réussite des rôles qui leur sont assignés. Nous présentons ici plusieurs mécanismes concrets que Chainlink doit adopter dans son entraînement vers une minimisation toujours plus grande de la confiance. Nous caractérisons ces mécanismes en termes des loci, c'est-à-dire les composants du système, dans lesquels ils sont enracinés, illustrés à la figure 14. Nous abordent chaque lieu dans une sous-section respective. 7.1 Authentification de la source de données Les modèles opérationnels actuels pour les oracle sont limités par le fait que peu de sources de données signer numériquement les données qu'ils omettent, en grande partie parce que TLS ne signe pas nativement données. TLS utilise des signatures numériques dans son protocole de « poignée de main » (pour établir une clé partagée entre un serveur et un client). Les serveurs compatibles HTTPS ont donc des certificats sur des clés publiques qui peuvent en principe servir à signer des données, mais elles n'utilisent généralement pas ces certificats pour prendre en charge la signature des données. Par conséquent, la sécurité d'un DON, comme dans les réseaux oracle d'aujourd'hui, s'appuie sur des nœuds oracle qui relayent fidèlement les données d'un système de données. source d’un contrat. Un élément important à long terme de notre vision de minimisation de la confiance dans Chainlink implique une authentification plus forte des sources de données grâce à la prise en charge d'outils et de normes pour la signature des données. La signature des données peut aider à renforcer les garanties d'intégrité de bout en bout. En principe, si un contrat accepte en entrée une donnée D signée directement par un data

Figure 14 : Locus des mécanismes de minimisation de la confiance abordés dans cette section. 1⃝Données les sources fournissent des données au 2⃝DON, qui relaie une fonction des données à un dépendant 3⃝smart contract. De plus, le réseau DON ou oracle comprend 4⃝nœuds gestion smart contracts sur MAINCHAIN pour, par exemple, les nœuds de compensation, la garde rails, etc. source, alors le réseau oracle ne peut pas altérer D. Divers encouragements Des efforts visant à permettre une telle signature de données ont vu le jour, notamment OpenID Connect, qui est conçu principalement pour l'authentification des utilisateurs [9], TLS-N, un projet académique visant à étendez TLS [191] en réutilisant les certificats TLS et les extensions de preuves TLS [63]. Même si OpenID Connect a connu une certaine adoption, les extensions de preuves TLS et TLS-N n’ont pas encore été adoptés. Une autre voie potentielle d’authentification de la source de données consiste à utiliser les propres Échanges HTTP signés (SXG) [230], qu'ils peuvent mettre en cache sur les réseaux de diffusion de contenu dans le cadre du protocole Accelerated Mobile Pages (AMP) [225]. Le navigateur mobile Chrome affiche le contenu des SXG mis en cache AMP comme s'ils étaient servis depuis les domaines réseau de leurs éditeurs au lieu du domaine du serveur de cache. Cette incitation à la marque, associée à la relative facilité de l'activer à l'aide de services tels que l'URL réelle [83] de CloudFlare et l'amppackager de Google [124], pourrait conduire à l'adoption généralisée des SXG dans le contenu d'actualités en cache, ce qui permettrait un accès simple et inviolable. moyen pour les Chainlink oracle de se déclencher sur des événements dignes d'intérêt signalés dans des SXG valides. Même si les SXG mis en cache par AMP provenant d'éditeurs de presse ne seraient pas utiles pour les applications telles que les rapports sur les données de trading, elles pourraient constituer une source sécurisée de données personnalisées. contrats relatifs à des événements du monde réel comme des conditions météorologiques extrêmes ou des résultats d'élections. Nous pensons qu'un déploiement simple, des outils matures et la flexibilité seront essentiels pour accélération de la signature des sources de données. Permettre aux fournisseurs de données d'utiliser les nœuds Chainlink comme un frontal API authentifié semble une approche prometteuse. Nous avons l'intention de créer unpossibilité pour les nœuds de fonctionner dans ce mode, avec ou sans participation au réseau comme un oracle à part entière. Nous appelons cette capacité l'origine de données authentifiées. (ADO). En utilisant les nœuds Chainlink avec ADO, les sources de données pourront bénéficier de l'expérience et des outils développés par la communauté Chainlink dans l'ajout du numérique capacités de signature à leur suite existante d'API hors chaîne. Devraient-ils choisir de courir leurs nœuds en tant que oracles, ils peuvent en outre ouvrir de nouvelles sources de revenus potentielles selon le même modèle que les fournisseurs de données existants, par exemple Kraken [28], Kaiko [140] et d'autres, qui exécutent des nœuds Chainlink pour vendre des données API en chaîne. 7.1.1 Les limites de l’origine des données authentifiées La signature numérique par source de données, même si elle peut contribuer à renforcer l'authentification, n'est pas suffisante en soi pour atteindre tous les objectifs naturels de sécurité ou opérationnels d'un oracle. réseau. Pour commencer, une donnée D donnée doit encore être relayée de manière robuste et opportune. depuis une source de données vers smart contract ou un autre consommateur de données. Autrement dit, même dans un cadre idéal dans lequel toutes les données sont signées à l'aide de clés préprogrammées en dépendance contrats, un DON serait toujours nécessaire pour communiquer les données de manière fiable à partir des sources aux contrats. De plus, il existe un certain nombre de cas dans lesquels des contrats ou d'autres données oracle les consommateurs veulent accéder à la sortie authentifiée de diverses fonctions calculées sur données sources pour deux raisons principales : • Confidentialité : une API de source de données peut fournir des données sensibles ou propriétaires. qui doit être expurgé ou nettoyé avant d'être rendu publiquement visible sur la chaîne. Toutefois, toute modification des données signées invalidait la signature. Mettez-en un autre D’une manière ou d’une autre, l’ADO naïve et la désinfection des données sont incompatibles. Nous montrons dans l'exemple 3 comment les deux peuvent être réconciliés grâce à une forme améliorée d’ADO. • Défauts de source de données : les erreurs et les échecs peuvent affecter les sources de données, et les signatures numériques ne résolvent aucun de ces problèmes. Depuis sa création [98], Chainlink a incluait déjà un mécanisme pour remédier à ces défauts : la redondance. Les rapports émis par les réseaux oracle représentent généralement les données combinées de plusieurs sources. Nous discutons maintenant des schémas que nous explorons dans le cadre ADO pour améliorer la confidentialité des données sources et combiner en toute sécurité les données provenant de plusieurs sources. 7.1.2 Confidentialité Les sources de données peuvent ne pas anticiper et mettre à disposition toute la gamme d'API souhaitées par les utilisateurs. Plus précisément, les utilisateurs peuvent souhaiter accéder à des données prétraitées pour garantir confidentialité. L'exemple suivant illustre le problème.Exemple 3. Alice souhaite obtenir un identifiant d'identité décentralisée (DID) indiquant qu'elle a plus de 18 ans (et peut donc, par exemple, contracter un emprunt). Faire elle doit donc prouver ce fait concernant son âge à un émetteur de titres de compétences DID. Alice espère utiliser les données du Département des véhicules automobiles (DMV) de son État site Web à cet effet. Le DMV a un enregistrement de sa date de naissance et émettra un une attestation A signée numériquement sur celle-ci et de la forme suivante : A = {Nom : Alice, Date de naissance : 16/02/1999}. Dans cet exemple, l'attestation A peut suffire à Alice pour prouver au DID émetteur de titres de compétences qu'elle a plus de 18 ans. Mais cela divulgue inutilement des informations sensibles : Alice's date de naissance exacte. Idéalement, ce qu'Alice souhaiterait du DMV, c'est une signature sur un simple déclaration A′ selon laquelle «Alice a plus de 18 ans». En d'autres termes, elle veut sortie d'une fonction G à sa date de naissance X, où (officieusement), A′ = G(X) = True si CurrentDate −X ≥18 ans ; sinon, G(X) = Faux. Pour généraliser, Alice aimerait pouvoir demander à la source de données un attestation A′ de la forme : A′ = {Nom : Alice, Func:G(X), Résultat : True}, où G(X) désigne une spécification d'une fonction G et de ses entrées X. Nous envisageons qu'un utilisateur devrait être en mesure de fournir un G(X) souhaité en entrée avec sa demande de attestation correspondante A′. Notez que l’attestation A′ de la source de données doit inclure la spécification G(X) pour s’assurer que A′ est correctement interprété. Dans l’exemple ci-dessus, G(X) définit la signification de la valeur booléenne dans A′ et donc que Vrai signifie le sujet de l'attestation est âgé de plus de 18 ans. Nous faisons référence à des requêtes flexibles dans lesquelles un utilisateur peut spécifier G(X) comme requêtes fonctionnelles. Afin de prendre en charge des cas d'utilisation comme celui de l'exemple 3, ainsi que ceux impliquant des requêtes directement à partir des contrats, nous avons l'intention d'inclure la prise en charge des requêtes fonctionnelles impliquant fonctions simples G dans le cadre d'ADO. 7.1.3 Combinaison des données sources Pour réduire les coûts en chaîne, les contrats sont généralement conçus pour consommer des données combinées à partir de plusieurs sources, comme illustré dans l’exemple suivant. Exemple 4 (médianisation des données de prix). Pour fournir un flux de prix, c'est-à-dire la valeur d'un actif (par exemple, ETH) par rapport à un autre (par exemple, USD), un réseau oracle sera généralement obtenir les prix courants à partir d’un certain nombre de sources, telles que les bourses. Le réseau oracle envoie généralement à un contrat dépendant SC la médiane de ces valeurs. Dans un environnement avec signature de données, un réseau oracle fonctionnant correctement obtient à partir des sources de données S = {S1, . . . , SnS} une séquence de valeurs V = {v1, v2, . . . , vnS} de nS sources accompagnées de signatures spécifiques à la source Σ = {σ1, σ2, . . . , σnS}. Sur vérifiant les signatures, il transmet le prix v = médian(V ) à SC.Malheureusement, il n'existe pas de moyen simple pour un réseau oracle de transmettre la médiane valeur v dans l'exemple 4 à SC avec une preuve succincte σ∗que v a été correctement calculé sur les entrées signées. Une approche naïve consisterait à encoder en SC les clés publiques de toutes les sources de données nS. Le réseau oracle relayerait alors (V, Σ) et permettrait à SC de calculer la médiane de V . Cependant, cela donnerait une preuve σ de taille O(nS) — c'est-à-dire que σ∗ ne serait pas succincte. Cela entraînerait également des coûts de gaz élevés pour SC, qui devrait vérifier toutes les signatures dans Σ. L’utilisation des SNARK, en revanche, permet une preuve succincte des valeurs sources authentifiées correctement combinées. Cela peut être réalisable dans la pratique, mais impose des des coûts de calcul sur le prouveur et des coûts de gaz quelque peu élevés sur la chaîne. Utilisation de Le crieur public est également une possibilité, mais nécessite l'utilisation de TEE, ce qui ne convient pas à tous. modèles de confiance des utilisateurs. Un concept utile pour encadrer les solutions au problème général de la signature de données combinées à partir de sources est un outil cryptographique connu sous le nom de signatures fonctionnelles [59, 132]. En bref, les signatures fonctionnelles permettent à un signataire de déléguer une capacité de signature, de telle sorte que le délégataire ne peut signer des messages que dans le cadre d'une fonction F choisie par le signataire. Nous montrons en Annexe D comment cette contrainte fonctionnelle peut servir à délimiter la gamme de valeurs de rapport émises par un DON en fonction des valeurs signées par les sources de données. Nous introduisons également une nouvelle primitive, appelée signature fonctionnelle discrétisée, qui inclut une exigence de précision assouplie, mais qui est potentiellement beaucoup plus performante. que les approches telles que les SNARK. Le problème de la combinaison de sources de données d'une manière qui inclut l'authentification de la source des résultats s'applique également aux agrégateurs de données, par exemple CoinCap, CoinMarketCap, CoinGecko, CryptoCompare, etc., qui obtiennent des données d'une multiplicité d'échanges, qu'ils pondération basée sur les volumes, en utilisant des méthodologies qu'ils rendent dans certains cas publiques et sont dans d'autres cas propriétaires. Un agrégateur qui souhaite publier une valeur avec l'authentification source est confrontée au même défi qu'un ensemble de nœuds regroupant données sources. 7.1.4 Traitement des données sources Les smart contract sophistiqués dépendront probablement de statistiques globales personnalisées sur sources de données primaires, telles que la volatilité de l'historique récent des prix sur de nombreux actifs, ou textes et photographies tirés de l'actualité sur des événements pertinents. Étant donné que le calcul et la bande passante sont relativement bon marché dans un DON, ces statistiques : même des modèles d'apprentissage automatique complexes avec de nombreuses entrées peuvent être traités de manière économique, à condition que toute valeur de sortie destinée à un blockchain soit suffisamment concise. Pour les tâches à forte intensité de calcul où les participants DON peuvent avoir des compétences différentes. points de vue sur des entrées complexes, des cycles de communication supplémentaires entre les participants DON peuvent être nécessaires pour établir un consensus sur les entrées avant de calculer le résultat. Tant que la valeur finale est entièrement déterminée par les entrées, une fois le consensus d'entrée établi, chaque participant peut simplement calculer la valeur et la diffuser à l'autre.participants avec leur signature partielle, ou l'envoyer à un agrégateur. 7.2 DON Minimisation de la confiance Nous envisageons deux manières principales de minimiser la confiance placée dans les composants du DON : clients de basculement et rapports minoritaires. 7.2.1 Clients de basculement Les modèles contradictoires dans la littérature sur la cryptographie et les systèmes distribués sont généralement considérons un adversaire capable de corrompre (c'est-à-dire de compromettre) un sous-ensemble de nœuds, par exemple, moins d'un tiers pour de nombreux protocoles BFT. On observe cependant couramment que si tous les nœuds exécutent un logiciel identique, un adversaire qui identifie un exploit fatal pourrait en principe, compromettre tous les nœuds plus ou moins simultanément. Ce paramètre est souvent appelée monoculture logicielle [47]. Diverses propositions visant à diversifier automatiquement les logiciels et les configurations logicielles ont été avancées pour résoudre le problème, par exemple [47, 113]. Comme indiqué dans [47], cependant, la diversité des logiciels est une question complexe et nécessite un examen attentif. La diversification des logiciels, par exemple, peut entraîner une sécurité pire qu'une monoculture si elle augmente la surface d’attaque d’un système et donc ses vecteurs d’attaque possibles au-delà de les avantages de sécurité qu’il offre. Nous pensons que la prise en charge de clients de basculement robustes, c'est-à-dire des clients vers quels nœuds peut changer face à un événement catastrophique – est une forme particulièrement attrayante de diversification des logiciels. Les clients de basculement n'augmentent pas le nombre de vecteurs potentiels d'attaque, car ils ne sont pas déployés en tant que logiciels principaux. Ils offrent des avantages évidents, cependant, comme deuxième ligne de défense. Nous avons l'intention de prendre en charge les clients de basculement dans les DON comme un moyen clé de réduire leur dépendance en matière de sécurité à l’égard d’un seul client. Chainlink dispose déjà d'un système robuste de clients de basculement. Notre approche implique de conserver les versions client précédentes et testées au combat. Aujourd'hui, par exemple, les nœuds Chainlink avec Off-Chain Reporting (OCR) comme client principal incluent la prise en charge pour le système FluxMonitor précédent de Chainlink si nécessaire. Ayant été utilisé pendant certains Au fil du temps, FluxMonitor a fait l'objet d'audits de sécurité et de tests sur le terrain. Il fournit la même chose des fonctionnalités telles que l'OCR, mais à un coût plus élevé, un coût uniquement encouru en fonction des besoins. 7.2.2 Rapports minoritaires Étant donné un ensemble minoritaire suffisamment important d’Ominorité – une fraction de nœuds honnêtes qui observent les malversations de la majorité – il peut être utile pour eux de générer une minorité. rapport. Il s'agit d'un rapport ou d'un indicateur parallèle, relayé vers un contrat dépendant SC en chaîne par Ominorité. SC peut utiliser ce drapeau conformément à sa propre politique spécifique au contrat. Par exemple, pour un contrat dans lequel la sécurité est plus importante que la vivacité ou la réactivité, un rapport minoritaire peut amener le contrat à demander des rapports supplémentaires. d'un autre DON, ou déclencher un disjoncteur (voir la section suivante).Les rapports minoritaires peuvent jouer un rôle important même lorsque la majorité est honnête, car tout schéma d'agrégation de rapports, même s'il utilise des signatures fonctionnelles, doit fonctionner de manière seuil, pour garantir la résilience contre oracle ou panne de données. Dans en d'autres termes, il doit être possible de produire un rapport valide basé sur les entrées de kS < nS oracles, pour un certain seuil kS. Cela signifie qu'un DON corrompu a des latitude dans la manipulation des valeurs du rapport en sélectionnant ses valeurs kS préférées parmi les nS rapporté en V par l'ensemble complet des oracle, même si toutes les sources sont honnêtes. Par exemple, supposons que nS = 10 et kS = 7 dans un système qui utilise un signature pour authentifier le calcul de la médiane sur V pour le prix en USD de l'ETH. Supposons que cinq sources rapportent un prix de \(500, while the other five report \)1000. Ensuite, en médianisant les 7 rapports les plus bas, le DON peut générer une valeur valide v = 500 $, et en médianisant le plus élevé, il peut produire v = 1 000 $. En améliorant le protocole DON afin que tous les nœuds sachent quelles données ont été disponibles et quelles données ont été utilisées pour construire un rapport, les nœuds pouvaient détecter et signaler tendances statistiquement significatives à privilégier un ensemble de rapports plutôt qu'un autre et à produire un rapport minoritaire en conséquence. 7.3 Garde-corps Notre modèle de confiance pour les DON traite MAINCHAIN comme un système de sécurité et de privilèges plus élevés. système que DONs. (Bien que ce modèle de confiance ne soit pas toujours vrai, il est plus facile d'adapter le mécanisme résultant aux situations où le DON est la sécurité la plus élevée plate-forme que l'inverse.) Une stratégie naturelle de minimisation de la confiance implique donc la mise en œuvre de mécanismes de surveillance et de sécurité dans les smart contract, soit dans un frontal MAINCHAIN pour un DON ou directement dans un contrat dépendant SC. Nous appelons ces mécanismes garde-corps, et énumérez ici quelques-uns des plus importants : • Disjoncteurs : le SC peut suspendre ou arrêter les mises à jour d'état en fonction des caractéristiques des mises à jour d'état elles-mêmes (par exemple, une grande variance au cours des mises à jour séquentielles). rapports) ou sur la base d’autres entrées. Par exemple, un disjoncteur peut se déclencher cas où les rapports oracle varient de manière invraisemblable au fil du temps. Un disjoncteur pourrait également être déclenché par un rapport minoritaire. Ainsi, les disjoncteurs peuvent empêcher les DONs de faire des rapports grossièrement erronés. Les disjoncteurs peuvent laisser le temps d’envisager des interventions supplémentaires ou exercé. L’une de ces interventions concerne les trappes de secours. • Trappes de secours : dans des circonstances défavorables, telles qu'identifiées par un ensemble de gardiens, de détenteurs de token communautaires ou d'autres organes d'administration, un contrat peut invoquer une installation d'urgence parfois appelée trappe d'évacuation [163]. Une trappe de secours provoque l'arrêt du SC d'une manière ou d'une autre et/ou se termine en attente et éventuellement transactions futures. Par exemple, il peut restituer les fonds déposés aux utilisateurs [17]),peut résilier les termes du contrat [162], ou annuler les transactions en cours et/ou futures [173]. Les trappes de secours peuvent être déployées dans tout type de contrat, pas seulement celui qui s'appuie sur un DON, mais ils sont intéressants en tant que tampon potentiel contre DON malversation. • Basculement : dans les systèmes où SC s'appuie sur DON pour les services essentiels, il est possible pour SC de fournir des mécanismes de basculement qui garantissent la continuité du service même en cas d'échec ou de mauvaise conduite DON. Par exemple, dans le TEF (Section 6), le contrat d'ancrage SCa peut fournir des interfaces doubles où à la fois en chaîne et les interfaces d'exécution hors chaîne sont prises en charge pour certaines opérations critiques (par exemple, retrait), ou pour les transactions ordinaires, avec un délai approprié pour éviter le frontrunning des transactions DON. Dans les cas où les sources de données signent des données, les utilisateurs peuvent fournir également des rapports à SCa lorsque le DON ne parvient pas à le faire. Les preuves de fraude, telles que proposées pour diverses formes de rollup optimistes (voir section 6.3), ont une saveur similaire et sont complémentaires aux mécanismes que nous avons énumérés ci-dessus. Ils fournissent également une forme de surveillance en chaîne et de protection contre les pannes potentielles dans composants du système hors chaîne. 7.4 Gouvernance minimisée par la confiance Comme tous les systèmes décentralisés, le réseau Chainlink nécessite des mécanismes de gouvernance pour ajuster les paramètres dans le temps, répondre aux urgences et guider son évolution. Certains de ces mécanismes résident actuellement sur MAINCHAIN et pourraient continuer à exister. faites-le même avec le déploiement de DONs. Un exemple est le mécanisme de paiement pour les fournisseurs de nœuds oracle (nœuds DON). DON contrats front-end sur MAINCHAIN contenir des mécanismes supplémentaires, tels que des garde-corps, qui peuvent être soumis à des contrôles périodiques. modification. Nous prévoyons deux classes de mécanismes de gouvernance : évolutifs et d’urgence. Gouvernance évolutive : De nombreuses modifications de l'écosystème Chainlink sont de sorte que leur mise en œuvre ne constitue pas une urgence : Amélioration des performances, améliorations des fonctionnalités, mises à niveau de sécurité (non urgentes), etc. À mesure que Chainlink s’oriente progressivement vers davantage de participants à sa gouvernance, nous nous attendons à ce que de nombreux ou la plupart de ces changements doivent être ratifiés par la communauté d'un DON spécifique concerné par ceux qui changements. Entre-temps, et peut-être à terme comme mécanisme parallèle, nous pensons qu'une notion de moindre privilège temporel peut être un moyen utile de mettre en œuvre une gouvernance évolutive. Très simplement, l'idée est que les changements se déploient progressivement, garantissant à la communauté une occasion d'y répondre. Par exemple, la migration vers un nouveau Le contrat MAINCHAIN peut être contraint afin que le nouveau contrat doive être déployé au moins trente jours avant l'activation.Gouvernance d’urgence : Vulnérabilités exploitables ou exploitées dans MAINCHAIN les contrats ou d’autres formes de défaillances de vivacité ou de sécurité peuvent nécessiter une intervention immédiate pour se prémunir contre des conséquences catastrophiques. Notre intention est de prendre en charge un multisig mécanisme d'intervention dans lequel, pour garantir contre les malversations de toute organisation, les signataires seront dispersés dans les organisations. Assurer une disponibilité constante des signataires et un accès rapide aux chaînes de commandement appropriées pour l'autorisation d'une situation d'urgence les changements nécessiteront clairement une planification opérationnelle minutieuse et un examen régulier. Ces les défis sont similaires à ceux impliqués dans les tests d’autres réponses aux incidents de cybersécurité capacités [134], avec un besoin similaire de lutter contre des problèmes courants tels que le décrément de vigilance [223]. La gouvernance des DON diffère de celle de nombreux systèmes décentralisés dans sa nature. degré potentiel d’hétérogénéité. Chaque DON peut avoir des sources de données, des exécutables, des exigences de niveau de service telles que la disponibilité et des utilisateurs distincts. Le réseau Chainlink les mécanismes de gouvernance doivent être suffisamment flexibles pour s’adapter à de telles variations objectifs et paramètres opérationnels. Nous explorons activement des idées de conception et prévoyons de publier des recherches sur ce sujet à l’avenir. 7.5 Infrastructure à clé publique La décentralisation progressive nécessitera une identification solide des participants au réseau, y compris les nœuds DON. En particulier, Chainlink nécessite une solide Infrastructure à clé publique (PKI). Une PKI est un système qui lie les clés aux identités. Pour Par exemple, une PKI sous-tend le système de connexions sécurisées (TLS) d’Internet : lorsque vous vous connectez à un site Web via HTTPS (par exemple, https://www.chainlinklabs.com) et un apparaît dans votre navigateur, cela signifie que la clé publique du propriétaire du domaine a été lié à ce propriétaire par une autorité, en particulier par le biais d'une signature numérique dans un soi-disant certificat. Un système hiérarchique d'autorités de certification (CA), dont les autorités racine de niveau supérieur sont intégrées dans les navigateurs populaires, permet de garantir que les certificats sont délivrés uniquement aux propriétaires légitimes des domaines. Nous prévoyons que Chainlink utilisera à terme des services de noms décentralisés, initialement le Ethereum Name Service (ENS) [22], comme base de notre PKI. Comme son nom l'indique, ENS est analogue au DNS, le système de noms de domaine qui mappe (lisibles par l'homme) aux adresses IP sur Internet. Cependant, ENS mappe à la place les noms Ethereum lisibles par l'homme aux adresses blockchain. Parce que l'ENS opère sur le Ethereum blockchain, sauf compromis clé, altération de son l’espace de noms est en principe aussi difficile que de falsifier le contrat qui l’administre et/ou le blockchain sous-jacent. (Le DNS, en revanche, a toujours été vulnérable à l'usurpation d'identité, au détournement et à d'autres attaques.) Nous avons enregistré data.eth auprès de l'ENS sur le réseau principal Ethereum et avons l'intention de établissez-le en tant qu'espace de noms racine sous lequel les identités des services de données oracle et d'autres entités du réseau Chainlink résident. Les domaines à l'ENS sont hiérarchiques, ce qui signifie que chaque domaine peut contenir des références à d'autres noms en dessous. Les sous-domaines de l'ENS peuvent servir à organiser etdéléguer la confiance. Le rôle principal de data.eth sera de servir de service d'annuaire en chaîne pour flux de données. Traditionnellement, les développeurs et les utilisateurs de oracle ont utilisé des sources hors chaîne (par exemple, des sites Web comme docs.chain.link ou data.chain.link, ou des réseaux sociaux tels que Twitter) pour publier et obtenir des adresses de flux de données oracle (telles que le prix ETH-USD nourrir). Avec un espace de noms racine hautement fiable tel que data.eth, il est possible d'établir un mappage de eth-usd.data.eth avec, par exemple, l'adresse smart contract. d'un agrégateur de réseau oracle en chaîne pour le flux de prix ETH-USD. Ce serait créer un chemin sécurisé permettant à quiconque de se référer au blockchain comme source de vérité pour ce flux de données de cette paire prix/nom (ETH-USD). Par conséquent, une telle utilisation de l’ENS réalise deux avantages non disponibles dans les sources de données hors chaîne : • Sécurité renforcée : toutes les modifications et mises à jour du domaine sont enregistrées de manière immuable et sécurisées par cryptographie, par opposition aux adresses texte sur un site Web, qui ne bénéficient d'aucune de ces deux propriétés de sécurité. • Propagation automatisée en chaîne : les mises à jour de l'adresse sous-jacente du smart contract d'un flux de données peuvent déclencher des notifications qui se propagent aux smart dépendants. contrats et peut, par exemple, mettre à jour automatiquement les contrats dépendants avec les nouvelles adresses.13 Cependant, les espaces de noms comme ENS ne valident pas automatiquement la propriété légitime de noms affirmés. Ainsi, par exemple, si l'espace de noms inclut l'entrée ⟨« Acme Oracle Node Co. », adresse⟩, alors un utilisateur obtient l'assurance que l'adresse appartient au demandeur du nom Acme Oracle Node Co. Sans mécanismes supplémentaires autour de l'administration des espaces de noms, cependant, elle n'obtient pas l'assurance que le nom appartient légitimement à une entité appelé Acme Oracle Node Co. dans un sens significatif du monde réel. Notre approche de la validation des noms, c'est-à-dire garantir leur propriété par des entités correspondantes et légitimes du monde réel, repose sur plusieurs éléments. Aujourd'hui, les laboratoires Chainlink agit efficacement en tant qu'autorité de certification pour le réseau Chainlink. Pendant que les Chainlink Labs continueront pour valider les noms, notre PKI évoluera vers un modèle plus décentralisé de deux manières : • Modèle de réseau de confiance : la contrepartie décentralisée d'une PKI hiérarchique est souvent appelée réseau de confiance.14 Des variantes ont été proposées depuis les années 1990, par exemple, [98], et un certain nombre de chercheurs ont observé que les blockchain peuvent faciliter l'utilisation de l'idée, par exemple, [227] en enregistrant les certificats dans un format globalement cohérent. grand livre. Nous explorons des variantes de ce modèle pour valider les identités des entités dans le réseau Chainlink de manière plus décentralisée. 13Un contrat dépendant peut éventuellement inclure un délai prédéterminé pour permettre une inspection manuelle et l'intervention des administrateurs de contrats dépendants. 14Terme inventé par Phil Zimmermann pour PGP [238].• Lien avec les données de validation : aujourd'hui, une quantité substantielle de données de performances des nœuds oracle est visible sur la chaîne, et donc liée de manière archivistique aux adresses des nœuds. Ces données peuvent être considérées comme enrichissant une identité au sein de l’IGC en fournissant des preuves historiques de sa participation (fiable) au réseau. De plus, des outils pour une identité décentralisée basée sur DECO et Town Crier [160] activer les nœuds pour accumuler des informations d'identification dérivées de données du monde réel. À titre d'exemple, un l'opérateur de nœud peut attacher un identifiant à son identité PKI qui prouve la possession d'une notation Dun et Bradstreet. Ces formes supplémentaires de validation peuvent compléter staking pour créer l'assurance de la sécurité du réseau. Un nœud oracle avec une identité réelle établie peut être considéré comme ayant un enjeu dans un système qui découle de sa réputation. (Voir les sections 4.3 et 9.6.3.) Une dernière exigence pour la PKI Chainlink est un amorçage sécurisé, c'est-à-dire un démarrage sécurisé. publiant le nom racine du réseau Chainlink, actuellement data.eth (de manière analogue au câblage des domaines de premier niveau dans les navigateurs). En d’autres termes, comment les utilisateurs Chainlink déterminer que data.eth est bien le domaine de premier niveau associé au Chainlink projet ? La solution à ce problème pour le réseau Chainlink est à plusieurs volets et peut impliquer: • Ajout d'un enregistrement TXT [224] à notre enregistrement de domaine pour chain.link qui spécifie data.eth comme domaine racine de l'écosystème Chainlink. (Chainlink exploite ainsi implicitement la PKI pour les domaines Internet pour valider son domaine ENS racine.) • Création d'un lien vers data.eth à partir du site Web existant de Chainlink, par exemple depuis https://docs.chain.link. (Une autre utilisation implicite de la PKI pour les domaines Internet.) • Faire connaître l'utilisation de data.eth via différents documents, dont ce livre blanc. • Publier data.eth publiquement sur nos réseaux sociaux, tels que Twitter, et le blog Chainlink [18]. • Placer une grande quantité de LINK sous le contrôle de la même adresse de déclarant comme data.eth.

DON Considérations relatives au déploiement

Bien que cela ne fasse pas partie de notre conception principale, il existe plusieurs considérations techniques importantes. dans la réalisation de DONs qui méritent d'être traités ici.

8.1 Approche de déploiement Cet article présente une vision ambitieuse des fonctionnalités avancées Chainlink dont sa réalisation nécessitera des solutions à de nombreux défis en cours de route. Ce livre blanc identifie certains défis, mais des défis imprévus surgiront certainement. Nous prévoyons de mettre en œuvre les éléments de cette vision de manière progressive sur une période période prolongée. Nous nous attendons à ce que les DONs soient initialement lancés avec prise en charge de composants prédéfinis spécifiques construits en collaboration par les équipes au sein du Communauté Chainlink. L'intention est que des utilisations plus larges des DON, par exemple la capacité de lancer des exécutables arbitraires, verra le support plus tard. L’une des raisons d’une telle prudence est que la composition des smart contract peut avoir des effets secondaires complexes, involontaires et dangereux, comme l’ont montré les récentes attaques basées sur les prêts flash. par exemple montré [127, 189]. De même, la composition des smart contracts, des adaptateurs et les exécutables nécessiteront une extrême prudence. Dans notre déploiement initial de DONs, nous prévoyons d'inclure uniquement un ensemble prédéfini d'exécutables et d'adaptateurs modélisés. Cela permettra d’étudier la sécurité compositionnelle de ces fonctionnalités en utilisant des méthodes formelles [46, 170] et d'autres approches. Ce sera simplifie également la tarification : la tarification des fonctionnalités peut être établie par les nœuds DON sur une base de fonctionnalité, plutôt que via un comptage généralisé, une approche adoptée dans, par exemple, [156]. Nous attendons également que la communauté Chainlink participe à la création de modèles supplémentaires, combinant divers adaptateurs et exécutables dans des formats de plus en plus services décentralisés utiles qui peuvent être gérés par des centaines, voire des milliers de personnes DONs. De plus, cette approche peut aider à prévenir la surcharge de l'État, c'est-à-dire le besoin de DON nœuds pour conserver une quantité d’état irréalisable dans la mémoire de travail. Ce problème est déjà apparue dans les blockchain sans autorisation, des approches motivantes telles que « apatrides clients » (voir, par exemple, [206]). Cela peut être plus aigu dans les systèmes à plus haut débit, motivant une approche dans laquelle un DON déploie uniquement des exécutables optimisés en termes de taille d'état. À mesure que les DON évoluent et mûrissent et incluent des garde-corps robustes, comme indiqué dans la section 7, des mécanismes de sécurité cryptoéconomiques et basés sur la réputation, comme indiqué dans la section 9, et d'autres fonctionnalités qui fournissent un degré élevé d'assurance aux utilisateurs de DON, nous nous espérons également développer un cadre et des outils pour faciliter un lancement et une utilisation plus larges de DONs par la communauté. Idéalement, ces outils permettront à un ensemble d'opérateurs de nœuds se réunir en un réseau oracle et lancer leurs propres DON dans un environnement sans autorisation ou en libre-service, ce qui signifie qu'ils peuvent le faire unilatéralement. 8.2 Adhésion dynamique DON L'ensemble de nœuds exécutant un DON donné peut changer au fil du temps. Il existe deux approches à la gestion des clés pour skL étant donné l'adhésion dynamique à O. La première consiste à mettre à jour les parts de skL détenues par les nœuds lors des changements d'adhésion, tout en gardant pkL inchangé. Cette approche, explorée dans [41, 161, 198], a le mérite de ne pas exiger que les parties utilisatrices mettent à jour pkL.La technique classique de repartage de partage, introduite dans [122], fournit un moyen simple et efficace de réaliser de telles mises à jour de partage. Il permet de transférer un secret entre un ensemble de nœuds O(1) et un second, éventuellement coupant un O(2). Dans ce approche, chaque nœud O(1) je effectue un partage secret (k(2), n(2)) de son partage secret à travers nœuds dans O(2) pour n(2) = |O(2)| et le seuil k(2) souhaité (éventuellement nouveau). Divers systèmes de partage de secrets vérifiables (VSS) [108] peuvent assurer la sécurité contre un adversaire qui corrompt activement les nœuds, c'est-à-dire introduit un comportement malveillant dans le protocole. Les techniques de [161] visent à le faire tout en réduisant la complexité de la communication et en fournissant résilience contre les échecs des hypothèses de dureté cryptographique. Une deuxième approche consiste à mettre à jour la clé du grand livre pkL. Cela a l'avantage d'avancer sécurité : la compromission des anciennes actions de pkL (c'est-à-dire les anciens nœuds de comité) ne serait pas entraîner une compromission de la clé actuelle. Les mises à jour de pkL présentent cependant deux inconvénients : (1) Les données chiffrées sous pkL doivent être rechiffrées lors d'une actualisation de clé et (2) Les mises à jour clés doivent être propagées aux parties utilisatrices. Nous avons l’intention d’explorer les deux approches, ainsi que les hybridations des deux. 8.3 DON Responsabilité Comme pour les réseaux Chainlink oracle existants, les DON incluront des mécanismes de responsabilité, c'est-à-dire l'enregistrement, la surveillance et l'application du comportement correct des nœuds. DONs auront capacité de données beaucoup plus importante que de nombreux blockchain sans autorisation existants, en particulier compte tenu de leur capacité à se connecter à un stockage décentralisé externe. Par conséquent, ils pourront enregistrer en détail l’historique des performances des nœuds, permettant des mécanismes de responsabilisation plus précis. Par exemple, le calcul hors chaîne de les prix des actifs peuvent impliquer des intrants qui sont rejetés avant qu'un résultat médian ne soit envoyé chaîne. Dans un DON, ces résultats intermédiaires pourraient être enregistrés. Un mauvais comportement ou des erreurs de performance de la part de nœuds individuels dans un DON peuvent ainsi être corrigés ou pénalisés sur le DON de manière fine. Nous avons également discuté des approches pour construire les garde-corps de la section 7.3 qui traitent de l'impact spécifique au contrat des défaillances systémiques. Cependant, il est également important de disposer de mécanismes de sécurité pour les DON eux-mêmes, c'est-à-dire des protections contre les défaillances systémiques et potentiellement catastrophiques DON, en particulier les échecs de fork/équivoque et d'accord de niveau de service (SLA), comme nous l'expliquons maintenant. Fourche / équivoque : Étant donné suffisamment de nœuds défectueux, un DON peut bifurquer ou équivoque, produisant deux blocs ou séquences de blocs distincts et incohérents dans L. Cependant, étant donné qu'un DON signe numériquement le contenu de L, il est possible d'exploiter un chaîne principale MAINCHAIN pour prévenir et/ou pénaliser les équivoques. Le DON peut vérifier périodiquement l'état du point de L dans un contrat d'audit sur MAINCHAIN. Si son état futur s'écarte d'un état de point de contrôle, un utilisateur/auditeur peut présenter une preuve de cette mauvaise conduite au contrat d'audit. Une telle preuve peut être utilisée pour générer une alerte ou pénaliser les nœuds DON en réduisant le contrat. Cette dernière approche introduit un problème de conception d'incitations similaire à celui des flux oracle spécifiques, et peut s'appuyer sur notre travail décrit à la section 9.Application des accords de niveau de service : Bien que les DON ne soient pas nécessairement destinés à fonctionnent indéfiniment, il est important qu’ils respectent les accords de niveau de service (SLA) avec leurs utilisateurs. L’application de base des SLA est possible sur une chaîne principale. Par exemple, Les nœuds DON peuvent s'engager à maintenir le DON jusqu'à une certaine date, ou à fournir un préavis de résiliation du service (par exemple, un préavis de trois mois). Un contrat sur MAINCHAIN peut assurer l’application de base des SLA cryptoéconomiques. Par exemple, le contrat SLA peut réduire considérablement les fonds déposés DON si les points de contrôle sont pas fournis aux intervalles requis. Un utilisateur peut déposer des fonds et contester le DON prouver qu'un point de contrôle représente correctement une séquence de blocs valides (de manière analogue, par ex. [141]). Bien entendu, production de blocs n’est pas synonyme de transaction. traitement, mais le contrat SLA peut également servir à faire respecter ce dernier. Par exemple, dans Dans la version compatible avec l'héritage de FSS dans laquelle les transactions sont extraites du mempool (voir Section 5.2), les transactions sont finalement extraites et placées sur la chaîne. Un utilisateur peut prouver un délit de DON en fournissant au contrat SLA une transaction qui a été extrait mais n'a pas été transmis par le DON pour traitement par le contrat cible dans un intervalle de temps approprié.15 Il est également possible de prouver l’existence et de sanctionner des SLA plus fins. échecs, y compris les erreurs de calcul utilisant les exécutables (via, par exemple, les mécanismes pour prouver l'exactitude des transactions d'état hors chaîne décrites dans la section 6.3) ou l'échec de l'exécution exécutables basés sur des initiateurs visibles sur un DON, échec du relais des données sur le DON vers MAINCHAIN en temps opportun, et ainsi de suite.

Économie et cryptoéconomie

Pour que le réseau Chainlink atteigne une sécurité renforcée dans un modèle de confiance décentralisé, il est essentiel que les nœuds présentent collectivement un comportement correct, c'est-à-dire qu'ils adhèrent la plupart du temps, exactement selon les protocoles DON. Dans cette section, nous discutons des approches pour aider à faire respecter un tel comportement au moyen d'incitations économiques, c'est-à-dire cryptoéconomiques incitations. Ces incitations se répartissent en deux catégories : explicites et implicites, réalisées respectivement via staking et l'opportunité de frais futurs (FFO). Jalonnement : Le jalonnement dans Chainlink, comme dans d'autres systèmes blockchain, implique les participants du réseau, c'est-à-dire les nœuds oracle, déposant des fonds bloqués sous la forme de LINK token. Ces les fonds, que nous appelons également participation ou participation explicite, sont une incitation explicite. Ils sont sujets à confiscation en cas de défaillance ou de malversation du nœud. Dans le contexte blockchain, cette procédure est souvent appelée « slashing ». Le jalonnement par les nœuds oracle dans Chainlink diffère cependant fondamentalement de celui de staking. par validators dans des blockchains sans autorisation. Les validateurs peuvent se comporter mal en équivoque ou en ordonnant des transactions de manière contradictoire. Le protocole de consensus sous-jacent dans un 15Comme les utilisateurs peuvent remplacer les transactions dans le mempool, il faut veiller à assurer une correspondance correcte entre les transactions extraites et les transactions soumises par DON.blockchain sans autorisation, cependant, utilise des règles de validation de bloc strictes et des primitives cryptographiques pour empêcher validator de générer des blocs invalides. En revanche, les protections programmatiques ne peuvent pas empêcher un réseau oracle tricheur de générer rapports invalides. La raison en est une différence clé entre les deux types de système : la validation des transactions dans blockchains est une propriété de cohérence interne, tandis que l'exactitude des rapports oracle sur un blockchain est une propriété de données externes, c'est-à-dire hors chaîne. Nous avons conçu un mécanisme préliminaire staking pour le réseau Chainlink basé sur sur un protocole interactif entre les nœuds oracle pouvant utiliser des données externes. Ceci Le mécanisme crée des incitations financières pour un comportement correct en utilisant des récompenses explicites et pénalités (tranchage). Le mécanisme étant économique, il est conçu pour empêcher le nœud corruption par un adversaire qui utilise des ressources financières pour corrompre les nœuds au moyen de corruption. (Un tel adversaire est très général et s’étend, par exemple, aux nœuds coopérant extraire de la valeur de leur mauvaise conduite collective.) Le mécanisme Chainlink staking que nous avons conçu possède des fonctionnalités puissantes et novatrices. caractéristiques.16 La principale de ces caractéristiques est l'impact super-linéaire staking (plus précisément quadratique). Un adversaire doit disposer de ressources considérablement supérieures aux fonds déposés par les nœuds dans afin de renverser le mécanisme. Notre mécanisme staking offre en outre une protection contre un adversaire plus fort que celui envisagé auparavant dans des systèmes similaires, à savoir un adversaire qui peut créer des pots-de-vin conditionnés au comportement futur des nœuds. De plus, nous discutons de la manière dont les outils Chainlink tels que DECO peuvent nous aider à renforcer notre staking mécanisme en facilitant une décision correcte en cas de comportement défectueux du nœud. Opportunité de frais futurs (FFO) : blockchains sans autorisation – des deux PoW et la variété des PoS – reposent aujourd’hui essentiellement sur ce que nous appelons des incitations implicites. Ce sont des incitations économiques pour un comportement honnête qui ne découlent pas de récompenses explicites, mais de la participation à la plateforme elle-même. Par exemple, la communauté minière Bitcoin est incitée à ne pas lancer une attaque à 51 % en raison du risque de saper la confiance dans Bitcoin, déprimant sa valeur et érodant par conséquent la valeur de leur collectif investissements en capital dans les infrastructures minières [150]. Le réseau Chainlink bénéficie d’une incitation implicite similaire à celle que nous appelons comme opportunité de frais futurs (FFO). Nœuds Oracle avec de solides historiques de performances ou les réputations attirent des frais de la part des utilisateurs. Le mauvais comportement d'un nœud oracle met en péril l'avenir paiements de frais et pénalise ainsi le nœud avec un coût d'opportunité en termes de potentiel revenus gagnés grâce à la participation au réseau. Par analogie avec l'enjeu explicite, Les FFO peuvent être considérés comme une forme d’enjeu implicite, une incitation à un comportement honnête qui découle de l’avantage partagé de maintenir la confiance dans la plateforme sur laquelle l’activité des opérateurs de nœuds dépend, c’est-à-dire de la performance positive et de la réputation du réseau. Cette incitation est inhérente mais n'est pas explicitement exprimée dans le réseau Chainlink protocoles. En Bitcoin, maintenir la valeur des opérations minières comme mentionné ci-dessus 16Le mécanisme staking que nous décrivons ici vise actuellement uniquement à imposer la livraison de rapports corrects. par les réseaux oracle. Nous espérons, dans les travaux futurs, l'étendre pour garantir la bonne exécution des nombreux d'autres fonctionnalités que DON fourniront.peut également être considérée comme une forme d’enjeu implicite. Nous soulignons que FFO existe déjà dans Chainlink et permet de sécuriser le réseau aujourd'hui. Notre principale contribution au développement ultérieur de Chainlink sera une approche fondée sur des principes et empirique pour évaluer les incitations implicites telles que les FFO à travers ce que nous appelons le cadre d’incitation implicite (IIF). Pour estimer des quantités telles que future opportunité de frais des nœuds, l'IIF s'appuiera en permanence sur l'ensemble des données de performance et de paiement collectées par le réseau Chainlink. De telles estimations permettra un paramétrage basé sur IIF des systèmes staking qui reflète les incitations des nœuds avec une plus grande précision que les modèles heuristiques et/ou statiques actuels. Pour résumer, donc, les deux principales incitations économiques pour un bon nœud oracle le comportement dans le réseau Chainlink en développement sera : • Staking (mise déposée) o Incitation explicite • Opportunité de frais futurs (FFO) o Incitation implicite Ces deux formes d'incitation sont complémentaires. Les nœuds Oracle peuvent simultanément participez au protocole Chainlink staking, profitez d'une source de revenus continue de utilisateurs et bénéficions collectivement de leur bon comportement continu. Ainsi, les deux incitations contribuer à la sécurité cryptoéconomique apportée par un réseau oracle. De plus, les deux incitations peuvent se renforcer et/ou être échangées l’une contre l’autre. Par exemple, un nouvel opérateur oracle sans historique de performances ni flux de revenus peut miser un une grande quantité de LINK comme garantie d'un comportement honnête, attirant ainsi les utilisateurs et les frais. À l’inverse, un opérateur oracle établi avec une longue expérience relativement sans problème l'historique des performances peut facturer des frais substantiels à une large base d'utilisateurs et donc s'appuyer sur plus lourdement sur ses FFO comme forme d’incitation implicite. En général, l'approche que nous considérons ici vise une quantité donnée de oracle-réseau ressource pour créer les plus grandes incitations économiques possibles en Chainlink pour une les agents – c’est-à-dire les nœuds maximisant leur utilité financière – se comportent honnêtement. Mettez-en un autre De cette manière, l’objectif est de maximiser les ressources financières nécessaires à un adversaire pour attaquer. le réseau avec succès. En formulant un protocole staking avec mathématiquement bien sécurité économique définie et en utilisant également l’IIF, nous visons à mesurer la force de les incitations de Chainlink aussi précisément que possible. Les créateurs de contrats de confiance alors être en mesure de déterminer avec une grande confiance si un réseau oracle répond leurs niveaux requis de sécurité cryptoéconomique. Le cercle vertueux de la sécurité économique : Les incitations dont nous discutons dans cette section, staking et FFO, ont un impact au-delà de leur renforcement de la sécurité des DONs. Ils promettent d’induire ce que nous appelons un cercle vertueux de sécurité économique. L'impact super-linéaire staking (et d'autres économies d'échelle) entraîne une réduction des coûts opérationnels. coût à mesure que la sécurité d’un DON augmente. Un coût inférieur attire des utilisateurs supplémentaires vers le DON,augmenter le paiement des frais. L’augmentation du paiement des frais continue de stimuler la croissance du réseau, qui perpétue le cycle vertueux. Nous pensons que le cercle vertueux de la sécurité économique n'est qu'un exemple d'une l’économie d’échelle et l’effet de réseau, entre autres, que nous aborderons plus loin dans cette section. Organisation des sections : le jalonnement présente des défis techniques et conceptuels notables pour pour lequel nous avons conçu un mécanisme doté de fonctionnalités inédites. Le jalonnement sera donc notre objectif principal dans cette section. Nous donnons un aperçu de l'approche staking que nous introduisons dans cet article dans la section 9.1, suivi d'une discussion détaillée dans les sections 9.2 à 9.5. Nous présentons l'IFF à la section 9.6. Nous présentons une vue récapitulative des incitations du réseau Chainlink dans la section 9.7. Dans la section 9.8, nous discutons du cercle vertueux de sécurité économique que notre approche staking proposée peut apporter aux réseaux oracle. Enfin, nous décrivons brièvement d’autres potentiels effets propulsant la croissance du réseau Chainlink dans la section 9.9. 9.1 Aperçu du jalonnement La conception du mécanisme staking que nous introduisons ici, comme indiqué ci-dessus, implique un protocole interactif entre les nœuds oracle permettant la résolution des incohérences dans le reporting des données externes. Le jalonnement vise à garantir un comportement honnête de la part des nœuds oracle rationnels. On peut donc modéliser un adversaire attaquant un protocole staking comme un pot-de-vin : la stratégie de l'adversaire consiste à corrompre les nœuds oracle en utilisant des incitations financières. L’adversaire peut tirer des ressources financières de manière prospective en altérant avec succès avec un rapport oracle, par exemple, proposez de partager le profit qui en résulte avec des nœuds corrompus. Dans la conception de notre mécanisme staking, nous visons simultanément deux objectifs ambitieux : 1. Résister à un adversaire puissant : Le mécanisme staking est conçu pour protéger oracle réseaux contre une large classe d'adversaires capables de complexes, les stratégies de corruption conditionnelle, y compris la corruption potentielle, qui offrent des pots-de-vin à des oracle dont l'identité est déterminée après coup (par exemple, offre des pots-de-vin à oracles sélectionnés au hasard pour les alertes hautement prioritaires). Alors que d'autres modèles oracle ont envisagé un ensemble restreint d'attaques sans toutes les capacités d'un système réaliste. adversaire, au meilleur de nos connaissances, le mécanisme contradictoire que nous introduisons voici le premier à aborder explicitement un large éventail de stratégies de corruption et à montrer résistance dans ce modèle. Notre modèle suppose que les nœuds autres que l'attaquant sont économiquement rationnel (par opposition à honnête), et nous supposons l'existence d'un source de vérité dont le coût est prohibitif pour une utilisation typique, mais qui est disponible en cas de désaccord (discuté plus loin). 2. Obtenir un impact staking super-linéaire : Notre objectif est de garantir qu'un réseau oracle composé d'agents rationnels rapporte honnêtement même en présence d'un attaquant avec un budget super-linéairedans la mise totale déposée par l'ensemble du réseau. Dans les systèmes staking existants, si chacun des n nœuds mise $d, un attaquant peut émettre un pot-de-vin crédible qui demande que les nœuds se comportent de manière malhonnête en échange d'un paiement légèrement supérieur à \(d to each node, using a total budget of about \)dn. C'est déjà une barre haute car l'attaquant doit disposer d'un budget liquide de l'ordre des dépôts combinés de tous les acteurs du réseau. Notre objectif est d'atteindre un degré de sécurité économique encore plus élevé que cet obstacle déjà important. Notre objectif est de concevoir le premier système staking qui peut assurer la sécurité d'un attaquant général avec un budget super-linéaire en n. Bien que des considérations pratiques puissent avoir un impact moindre, comme nous le discutons ci-dessous, notre conception préliminaire atteint une exigence budgétaire contradictoire supérieure à $dn2/2, c'est-à-dire une mise à l'échelle quadratique en n, rendant la corruption largement peu pratique, même lorsque les nœuds ne misent que des montants modérés. Atteindre ces deux objectifs nécessite une combinaison innovante de conception d'incitations et la cryptographie. Idées clés : Notre approche staking repose sur une idée que nous appelons la priorité de surveillance. Un rapport généré par un réseau Chainlink oracle et envoyé à un contrat de confiance (par exemple, sur le prix d'un actif) est agrégé à partir de rapports individuels fournis par les nœuds participants (par exemple, en prenant la médiane). Généralement un accord de niveau de service (SLA) spécifie les limites d'écart acceptables pour les rapports, c'est-à-dire dans quelle mesure le rapport d'un nœud peut s'écarter du rapport global et dans quelle mesure l'agrégat doit être autorisé à s'écarter de la valeur réelle pour être considéré comme correct. Dans notre système staking, pour un cycle de reporting donné, chaque nœud oracle peut agir comme un chien de garde pour déclencher une alerte s’il estime que le rapport global est incorrect. Dans chacun cycle de reporting, chaque nœud oracle se voit attribuer une priorité publique qui détermine le ordre dans lequel son alerte (le cas échéant) sera traitée. Notre mécanisme vise à récompenser concentration, ce qui signifie que le chien de garde le plus prioritaire pour déclencher une alerte gagne le récompense entière obtenue en confisquant les dépôts des nœuds défectueux. Nos conceptions de systèmes staking impliquent deux niveaux : le premier, niveau par défaut, et le second, niveau de soutien. Le premier niveau est le réseau oracle lui-même, un ensemble de n nœuds. (Pour simplifier, nous supposons que n est impair.) Si une majorité de nœuds signalent des valeurs incorrectes, un chien de garde dans le le premier niveau est fortement incité à déclencher une alerte. Si une alerte est déclenchée, le reporting La décision concernant le réseau est ensuite transmise à un deuxième niveau : un système coûteux et à fiabilité maximale qui peut être spécifié par l'utilisateur dans l'accord de niveau de service du réseau. Il peut s'agir d'un système qui, par exemple, est composé uniquement de nœuds à forte scores de fiabilité historiques, ou ceux qui ont un ordre de grandeur supérieur à oracles que le premier niveau. De plus, comme indiqué dans la section 9.4.3, DECO ou Town Crier peut servir comme des outils puissants pour contribuer à garantir une décision efficace et concluante au deuxième niveau. Par souci de simplicité, nous supposons donc que ce système de deuxième niveau parvient à un rapport correct. valeur. Même s'il peut sembler intéressant de s'appuyer uniquement sur le deuxième niveau pour générer tous les rapports, l'avantage de notre conception est qu'elle atteint systématiquement les propriétés de sécurité dusystème de deuxième niveau tout en ne payant que le coût de fonctionnement, dans le cas typique, du système de premier niveau. La priorité du chien de garde entraîne un impact super-linéaire staking de la manière suivante : si le Le réseau oracle de premier niveau génère un résultat incorrect et un certain nombre de nœuds de surveillance alerte, le mécanisme d'incitation staking récompense le chien de garde le plus prioritaire avec plus de $dn/2 tirés des dépôts des nœuds (majoritaires) qui se comportent mal. Le la récompense totale est ainsi concentrée entre les mains de ce chien de garde unique, qui détermine le minimum qu'un adversaire doit promettre à un chien de garde potentiel l’inciter à ne pas alerter. Puisque notre mécanisme garantit que chaque oracle obtient le possibilité d'agir en tant que chien de garde si les chiens de garde prioritaires ont accepté leurs pots-de-vin (et choisi de ne pas alerter), l’adversaire doit donc offrir un pot-de-vin de plus de $dn/2 à chaque nœud pour empêcher toute alerte. Puisqu’il y a n nœuds, le Le budget requis par l’adversaire pour un pot-de-vin réussi s’élève à plus de 2/2 dollars, ce qui est quadratique en nombre n de nœuds du réseau. 9.2 Contexte Notre approche de staking s'appuie sur des recherches dans les domaines de la théorie et des mécanismes des jeux. design (MD) (pour une référence de manuel, voir [177]). La théorie des jeux est mathématiquement étude formalisée de l’interaction stratégique. Dans ce contexte, un jeu est un modèle d'une telle une interaction, typiquement dans le monde réel, qui codifie des ensembles d'actions disponibles pour participants au jeu, appelés joueurs. Un jeu précise également les gains obtenus par les joueurs individuels - des récompenses qui dépendent des actions choisies par un joueur et de la actions des autres joueurs. Peut-être l'exemple le plus connu d'un jeu étudié en jeu La théorie est le dilemme du prisonnier [178]. Les théoriciens des jeux visent généralement à comprendre le ou les équilibres (le cas échéant) représentés dans un jeu donné. Un équilibre est un ensemble de stratégies (une pour chaque joueur) telles qu'aucun joueur ne puisse obtenir un score plus élevé gain en s’écartant unilatéralement de sa stratégie. La conception de mécanismes, quant à elle, est la science qui consiste à concevoir des incitations telles que l'équilibre d'une interaction (et de son jeu associé) possède une propriété souhaitable. MD peut être considéré comme l’inverse de la théorie des jeux : la question canonique dans le jeu La théorie est la suivante : « étant donné les incitations et le modèle, quel sera l’équilibre ? En MD, le La question est plutôt : « Quelles incitations donneront lieu à un jeu présentant un équilibre souhaitable ? » L'un des objectifs typiques d'un concepteur de mécanisme est de créer un mécanisme « compatible avec les incitations », ce qui signifie que les participants au mécanisme (par exemple, une vente aux enchères ou d'autres informations) système d'élicitation [228]) sont incités à rapporter la vérité sur un sujet (par exemple, comment ils apprécient beaucoup un article particulier). La vente aux enchères Vickrey (second prix) est peut-être la mécanisme compatible avec les incitations le plus connu, dans lequel les participants soumettent des offres scellées pour un article et le plus offrant remporte l'article mais paie le deuxième prix le plus élevé [214]. La cryptoéconomie est une forme de MD spécifique à un domaine qui exploite la cryptographie. techniques pour créer des équilibres souhaitables au sein des systèmes décentralisés. La corruption et la collusion créent des défis importants dans tout le domaine du MD. Presque tous les mécanismes se brisent en présence de collusion, définie comme des contrats parallèles.entre les parties participant à un mécanisme [125, 130]. La corruption, dans laquelle une partie externe introduit de nouvelles incitations dans le jeu, présente un problème encore plus difficile. que la collusion ; la collusion peut être considérée comme un cas particulier de corruption participants. Les systèmes blockchain peuvent souvent être conceptualisés comme des jeux avec des gains monétaires (basés sur des cryptomonnaies). Un exemple simple est le minage de preuve de travail : les mineurs disposent d'un espace d'action dans lequel ils peuvent choisir le taux hash avec lequel extraire des blocs. Le bénéfice du minage est une récompense négative garantie (coût de l'électricité et de l'équipement) plus un effet stochastique. récompense positive (subvention minière) qui dépend du nombre d'autres mineurs actifs [106, 172] et les frais de transaction. Les oracle participatifs comme SchellingCoin [68] sont un autre exemple : l'espace d'action est l'ensemble des rapports possibles qu'un oracle peut envoyer, tandis que le paiement est la récompense spécifiée par le mécanisme oracle, par exemple, le paiement peut dépendre sur la proximité du rapport d'un oracle par rapport à la médiane des autres rapports [26, 68, 119, 185]. Les jeux blockchain offrent de bonnes opportunités pour les attaques de collusion et de corruption ; en effet, Les smart contract peuvent même faciliter de telles attaques [96, 165]. Peut-être le plus connu L'attaque de corruption contre des oracle issus du crowdsourcing est l'attaque p-plus-epsilon [67]. Cette attaque se produit dans le contexte d'un mécanisme de type SchellingCoin dans lequel les joueurs soumettent des rapports de valeur booléenne (c'est-à-dire faux ou vrai) et sont récompensés par p s'ils sont d'accord avec le proposition majoritaire. Dans une attaque p-plus-epsilon, l'attaquant promet de manière crédible : par exemple, payez les utilisateurs $p + ϵ pour avoir voté faux si et seulement si la proposition majoritaire est vraie. Le résultat est un équilibre dans lequel tous les acteurs sont incités à signaler de fausses informations. indépendamment de ce que font les autres joueurs ; par conséquent, le corrupteur peut inciter les nœuds grâce à sa promesse de pot-de-vin pour signaler de fausses déclarations sans réellement payer le pot-de-vin (!). Cependant, l’exploration d’autres stratégies de corruption dans le contexte des oracle – et en particulier des oracle qui ne font pas l’objet d’un crowdsourcing – s’est limitée à des stratégies contradictoires assez faibles. modèles. Par exemple, dans le cadre du PoW, les chercheurs ont étudié les les pots-de-vin, c'est-à-dire les pots-de-vin versés uniquement si un message cible est censuré avec succès et ne apparaissent dans un bloc, quelle que soit l’action d’un mineur individuel [96, 165]. Dans le cas de oracles, cependant, autre que l'attaque p-plus-epsilon, nous sommes au courant uniquement du travail dans un modèle de corruption strictement limité dans lequel un corrupteur envoie un pot-de-vin conditionné à un l’action d’un joueur individuel, et non sur le résultat qui en résulte. Nous esquissons ici des conceptions de mécanismes d'obtention d'informations qui restent incitatifs compatible même dans un modèle fortement contradictoire, comme décrit dans la sous-section suivante. 9.3 Hypothèses de modélisation Dans cette sous-section, nous expliquons comment nous modélisons le comportement et les capacités des acteurs dans notre système, en particulier les nœuds oracle de premier niveau, les nœuds de deuxième niveau (arbitrage) couche et adversaires.9.3.1 Modèle d’incitation de premier niveau : acteurs rationnels De nombreux systèmes blockchain reposent pour leur sécurité sur l'hypothèse d'un certain nombre d'honnêtes nœuds participants. Les nœuds sont définis comme étant honnêtes s'ils suivent le protocole même lorsque cela n’est pas dans leur intérêt financier de le faire. Systèmes de preuve de travail généralement nécessitent la majorité du pouvoir hash pour être honnête, les systèmes de preuve de participation nécessitent généralement 2/3 ou plus de toutes les participations pour être honnêtes, et même les systèmes de couche 2 comme L'arbitrage [141] exige au moins un seul participant honnête. Lors de la modélisation de notre mécanisme staking, nous faisons une hypothèse beaucoup plus faible. (Être des hypothèses claires et plus faibles signifient des propriétés de sécurité plus fortes et sont donc préférables.) Nous supposons que l'adversaire a corrompu, c'est-à-dire les contrôles, une partie (minorité) fraction des nœuds oracle de premier niveau. Nous modélisons les nœuds restants non pas comme des agents honnêtes, mais en tant que maximisateurs rationnels de l'utilité attendue. Ces nœuds agissent entièrement selon des incitations financières intéressées, choisissant des actions qui aboutissent à un résultat financier attendu. gagner. Par exemple, si un nœud se voit offrir un pot-de-vin supérieur à la récompense résultant de comportement honnête, il acceptera le pot-de-vin. Remarque sur les nœuds contradictoires : Conformément à la modélisation de confiance commune pour systèmes décentralisés, nous supposons que tous les nœuds sont rationnels, c'est-à-dire cherchant à maximiser revenus nets, plutôt que contrôlés par un adversaire malveillant. Cependant, nos affirmations... impact staking spécifiquement super-linéaire ou quadratique - maintien asymptotiquement fourni que l’ensemble des nœuds contrôlés de manière contradictoire est au plus (1/2 −c)n, pour certains positifs constante c. 9.3.2 Modèle d’arbitrage de deuxième niveau : justesse par hypothèse Rappelez-vous qu'une fonctionnalité essentielle de notre mécanisme staking qui contribue à assurer la sécurité contre les nœuds rationnels se trouve son système de deuxième niveau. Dans notre mécanisme staking proposé, tout oracle peut déclencher une alerte indiquant que il pense que le résultat du mécanisme est incorrect. Une alerte entraîne une confiance élevée système de deuxième niveau activant et signalant le résultat correct. Ainsi, une modélisation clé L'exigence de notre approche est une décision correcte, c'est-à-dire un rapport correct par le système de deuxième niveau. Notre modèle staking suppose un système de deuxième niveau qui agit comme une source de vérité incorruptible et fiable au maximum. Un tel système risque d'être coûteux et lent, et donc inapproprié pour une utilisation dans le cas typique. Cependant, dans le cas d’équilibre, c’est-à-dire lorsque le système du premier niveau fonctionne correctement, le système du deuxième niveau ne sera pas invoqué. Au lieu de cela, son existence renforce la sécurité de l'ensemble du système oracle en fournissant un un filet de sécurité de haute assurance. L'utilisation d'une couche de décision hautement fiable et coûteuse ressemble au processus d'appel. au cœur de la plupart des systèmes judiciaires. C'est également déjà courant dans la conception de oracle systèmes, par exemple [119, 185]. Nous discutons brièvement des approches de réalisation du deuxième niveau dans notre mécanisme à la section 9.4.3.Notre protocole staking utilise la décision supposée correcte du système de deuxième niveau comme une menace crédible pour imposer des rapports corrects par les nœuds oracle. Le protocole confisque une partie ou la totalité de la participation des nœuds oracle qui génèrent des rapports identifiés par le système de deuxième niveau comme étant incorrect. Les nœuds Oracle sont ainsi dissuadés de se comporter mal par la pénalité financière qui en résulte. Cette approche est similaire en saveur à celle utilisée dans rollup optimistes, par exemple, [141, 10]. 9.3.3 Modèle contradictoire Notre mécanisme staking est conçu pour obtenir des informations véridiques tout en assurant la sécurité contre une classe large et bien définie d'adversaires. Il améliore les travaux antérieurs, qui soit omettent un modèle accusatoire explicite, soit se concentrent sur des sous-classes étroites d’adversaires, par exemple l’adversaire p-plus-epsilon évoqué ci-dessus. Notre objectif est de concevoir un staking mécanisme avec une sécurité formellement prouvée contre l’ensemble des adversaires probables à rencontrer dans la pratique. Nous modélisons notre adversaire comme ayant un budget fixe (paramétrable), noté G$. L'adversaire peut communiquer individuellement et de manière confidentielle avec chaque oracle dans le réseau, et peut secrètement offrir à tout individu oracle le paiement garanti d'un pot-de-vin dépend des résultats du mécanisme publiquement observables. Résultats déterminants les pots-de-vin peuvent inclure, par exemple, la valeur rapportée par le oracle, tout message public envoyées par n'importe quel oracle au mécanisme (par exemple, une alerte), les valeurs rapportées par d'autres oracles et la valeur émise par le mécanisme. Aucun mécanisme ne peut protéger contre un attaquant doté de capacités illimitées. Nous considérons donc certains comportements comme irréalistes ou hors de portée. Nous supposons que notre attaquant ne peut pas briser les primitives cryptographiques standards et, comme indiqué ci-dessus, a une valeur fixe (si potentiellement important) budget de G$. Nous supposons en outre que l'adversaire ne contrôle pas communication dans le réseau oracle, en particulier qu'il ne peut pas retarder considérablement trafic entre les nœuds de premier et/ou de deuxième niveau. (Le fait que l’adversaire puisse observer une telle communication dépend du mécanisme particulier, comme nous l’expliquons ci-dessous.) Cependant, de manière informelle, comme indiqué ci-dessus, nous supposons que l'adversaire peut : (1) Corrompre une fraction de oracle nœuds ((1/2 −c)-fraction pour une constante c), c'est-à-dire contrôler entièrement eux, et (2) Offrir des pots-de-vin à tous les nœuds souhaités, avec un paiement garanti conditionné sur les résultats spécifiés par l’adversaire, comme décrit ci-dessus. Bien que nous n’offrions pas de modèle formel ni de taxonomie complète de l’ensemble de l’adversaire. gamme de capacités de corruption dans ce livre blanc, voici des exemples des types de pots-de-vin englobés dans notre modèle. Pour plus de simplicité, nous supposons que les oracle émettent des booléens rapports dont la valeur correcte (w.l.o.g.) est vraie, et qu'un résultat final est calculé comme un ensemble de ces rapports à utiliser par un smart contract consommateur. Le corrupteur le but est que le résultat final soit incorrect, c’est-à-dire faux. • Pot-de-vin inconditionnel : le pot-de-vin offre un pot-de-vin de $b à tout oracle qui déclare de fausses informations. • Pot-de-vin probabiliste : le pot-de-vin propose un pot-de-vin $b avec une certaine probabilité q à n'importe quel oracle qui rapporte faux.• Pot-de-vin conditionné à un résultat faux : le pot-de-vin offre un pot-de-vin de $b à tout oracle qui déclare faux à condition que le résultat final soit faux. • Pot-de-vin sans condition d'alerte : le pot-de-vin offre un pot-de-vin de milliards $ à tout oracle qui signale false tant qu'aucune alerte n'est déclenchée. • Pot-de-vin p-plus-epsilon : le pot-de-vin offre un pot-de-vin de $b à tout oracle qui déclare faux comme tant que la majorité des oracle ne déclarent pas de faux. • Pot-de-vin potentiel : le pot-de-vin offre un pot-de-vin d'un montant de milliards $ à l'avance au oracle sélectionné. pour un rôle randomisé et des rapports faux. Dans notre protocole staking proposé, tous les nœuds agissent comme des chiens de garde potentiels, et nous sommes en mesure de montrer que la randomisation Les priorités des organismes de surveillance ne se prêtent pas à des pots-de-vin potentiels. De nombreux systèmes de preuve de travail, proof-of-stake et autorisés sont susceptibles de corruption, ce qui montre l’importance de la considérer dans notre débat contradictoire. modèle et en veillant à ce que nos protocoles staking y soient résilients. Voir l'Annexe E pour plus de détails. 9.3.4 Dans quelle mesure la sécurité cryptoéconomique est-elle suffisante ? Un adversaire rationnel ne dépensera de l’argent pour attaquer un système que s’il peut en tirer un profit. supérieur à ses dépenses. Ainsi pour notre modèle contradictoire et proposé staking mécanisme, $B peut être considéré comme une mesure du profit potentiel qu’un adversaire est en mesure de réaliser. pour extraire des smart contract fiables en corrompant un réseau oracle et en le provoquant pour générer un rapport ou un ensemble de rapports incorrect. Pour décider si un réseau oracle offre un degré suffisant de sécurité cryptoéconomique pour ses besoins, un utilisateur doit évaluer le réseau dans cette perspective. Pour les adversaires plausibles dans des contextes pratiques, nous nous attendons à ce que G$ soit généralement sensiblement inférieur à l'actif total en s'appuyant sur smart contracts. Dans la plupart des cas, il Il est impossible pour un adversaire d’extraire ces atouts dans leur totalité. 9.4 Mécanisme de jalonnement : croquis Nous présentons ici les idées principales et la structure générale du mécanisme staking que nous envisagent actuellement. Pour faciliter la présentation, nous décrivons un processus simple mais lent protocole (multi-tours) dans cette sous-section. Nous notons cependant que ce schéma est assez pratique. Compte tenu des garanties économiques fournies par le mécanisme, c'est-à-dire la pénalisation et l'incitation conséquente contre les nœuds défectueux, de nombreux utilisateurs pourraient être disposés à accepter les rapports avec optimisme. En d'autres termes, ces utilisateurs peuvent accepter les rapports avant arbitrage potentiel par le deuxième niveau. Les utilisateurs peu disposés à accepter les rapports avec optimisme peuvent choisir d'attendre que le protocole soit mis en œuvre. l'exécution se termine, c'est-à-dire jusqu'à ce qu'une escalade potentielle vers le deuxième niveau se produise. Ceci, cependant, cela peut ralentir considérablement le temps de confirmation des rapports. Nous avons donc brièvementFigure 15 : Schéma du schéma staking avec alerte. Dans cet exemple, 1⃝une majorité des nœuds sont corrompus / soudoyés et émettent une valeur incorrecte ˜r, plutôt que la bonne rapporter la valeur r. Le nœud de surveillance 2⃝envoie une alerte au comité de deuxième niveau, qui 3⃝détermine et émet la valeur de rapport correcte r, entraînant des nœuds corrompus perdant leurs dépôts - chaque $d au nœud de surveillance 4⃝. décrivent quelques optimisations qui se traduisent par un tour plus rapide (en un seul tour), voire un peu plus conception complexe à la section 9.5. Rappelons que le premier niveau de notre mécanisme staking se compose des éléments de base oracle réseau lui-même. La structure principale de notre mécanisme, telle que décrite ci-dessus, est qu'à chaque tour, chaque nœud peut agir comme un « chien de garde » avec une certaine priorité, et il a ainsi la capacité de déclencher une alerte si le mécanisme arrive à une sortie incorrecte ˜r, plutôt qu'à une sortie correcte un r. Cette alerte provoque une résolution de deuxième niveau, qui, nous supposons, aboutit à un résultat correct. rapport. Les nœuds avec des rapports incorrects sont punis, dans le sens où leurs enjeux sont réduit et attribué aux chiens de garde. Cette structure de base est courante dans les systèmes oracle, comme dans, par exemple, [119, 185]. L'innovation clé de notre conception, mentionnée brièvement ci-dessus, est que chaque nœud est s'est vu attribuer une priorité distincte dans l'ordre des chiens de garde potentiels. C'est-à-dire des chiens de garde ont la possibilité d’alerter par ordre de priorité. Rappelons que si un nœud a le priorité absolue pour déclencher une alerte, il reçoit le dépôt réduit $d de chaque mauvais comportement nœud, pour un total supérieur à \(dn/2 = \)d × n/2, car un rapport incorrect implique un majorité de nœuds défectueux. Par conséquent, l'adversaire doit payer au moins cette récompense à corrompre un nœud arbitraire. Ainsi, pour corrompre une majorité de nœuds, l’adversaire doit payer une somme un pot-de-vin important à une majorité de nœuds, à savoir strictement plus de $dn2/2. Nous montrons schématiquement comment fonctionnent les alertes et les escalades de surveillance dans la figure 15.9.4.1 Plus de détails sur le mécanisme Le système anti-corruption que nous décrivons maintenant plus en détail est une esquisse simplifiée de la construction à deux niveaux que nous avons l'intention de construire. Nous nous concentrerons principalement sur la description le réseau de premier niveau (désormais simplement « réseau » si cela ressort clairement du contexte) ainsi que avec son mécanisme d'incitation et la procédure de remontée au deuxième niveau. Considérons un réseau Chainlink composé de n nœuds oracle responsables de régulièrement (par exemple, une fois par minute) en signalant une valeur booléenne (par exemple, si le marché la capitalisation du BTC dépasse celle de l’ETH). Dans le cadre du mécanisme staking, les nœuds doit fournir deux cautions : une caution $d sujette à des coupures en cas de désaccord avec la majorité et un chien de garde, dépôt $dw susceptible d'être réduit en cas de défaut escalade. Nous supposons que les nœuds ne peuvent pas copier les soumissions d'autres nœuds, par exemple : via un système de validation-révélation comme discuté dans la section 5.3. A chaque tour, les nœuds en premier s'engager dans leur rapport, et une fois que tous les nœuds se sont engagés (ou qu'un délai d'attente a expiré), les nœuds révèlent leurs rapports. Pour chaque rapport à générer, chaque nœud reçoit également une priorité de surveillance comprise entre 1 et n choisie au hasard, 1 étant la priorité absolue. Cette priorité permet au concentration de la récompense entre les mains d'un seul chien de garde. Une fois que tous les rapports sont publics, une phase d’alerte s’ensuit. Sur une séquence de n tours (synchrones), le nœud avec priorité j'ai la possibilité d'alerter au premier tour. Considérons les résultats possibles du mécanisme une fois que les nœuds ont révélé leurs rapports. En supposant encore une fois un rapport binaire, supposons que la valeur correcte soit vraie et l'incorrect est faux. Supposons également que le mécanisme de premier niveau génère le valeur majoritaire sortie par les nœuds comme rapport final r. Il y a trois résultats possibles dans le mécanisme : • Accord complet : dans le meilleur des cas, les nœuds sont en accord complet : tous les nœuds sont disponibles et ont fourni en temps opportun un rapport de la même valeur r (soit vraie ou faux). Dans ce cas, le réseau n'a qu'à transmettre r aux contrats de confiance et récompensez chaque nœud avec un paiement fixe par tour $p, qui est beaucoup plus petit que $d. • Accord partiel : il est possible que certains nœuds soient hors ligne ou qu'il y ait un désaccord sur la valeur correcte, mais la plupart des nœuds rapportent vrai et seulement un les rapports minoritaires sont faux. Ce cas est également simple. La valeur majoritaire (vrai) est calculé, ce qui donne un rapport correct r. Tous les nœuds qui ont rapporté r sont récompensé par $p tandis que les oracle qui ont signalé des erreurs ont leurs dépôts modestement réduit, par exemple de 10 pence. • Alerte : dans le cas où un chien de garde estime que la sortie du réseau est incorrecte, il déclenche publiquement une alerte, faisant remonter le mécanisme au réseau de deuxième niveau. Il y a alors deux résultats possibles : – Alerte correcte : si le réseau de deuxième niveau confirme que la sortie duFigure 16 : Amplifier le coût des pots-de-vin grâce à des récompenses d’alerte concentrées. Une corruption l'adversaire doit soudoyer chaque nœud avec plus que la récompense qu'il peut gagner en alertant (représenté par une barre rouge). Si les récompenses d’alerte sont partagées, alors cette récompense peut être relativement petit. Les récompenses d'alerte concentrées augmentent la récompense que n'importe quel nœud peut obtenir (grande barre rouge). Par conséquent, le paiement total par l'adversaire pour un pot-de-vin viable (régions grises) est beaucoup plus grande avec des récompenses d'alerte concentrées que partagées. Le réseau de premier niveau était incorrect, le nœud de surveillance d'alerte reçoit une récompense constitué de tous les dépôts réduits, et donc de plus de $dn/2. – Alerte défectueuse : si les oracles de deuxième et de premier niveaux sont d'accord, l'escalade est est jugé défectueux et le nœud d'alerte perd son dépôt $dw. En cas d'acceptation optimiste des rapports, les alertes de surveillance ne provoquent pas tout changement dans l’exécution des contrats de confiance. Pour les contrats conçus pour attendre arbitrage potentiel par le comité de deuxième niveau, les alertes du chien de garde tardent mais ne gèlez pas l’exécution du contrat. Il est également possible que les contrats désignent un basculement DON pour les périodes d’arbitrage. 9.4.2 Impact du jalonnement quadratique La capacité de chaque nœud à agir comme un chien de garde, combinée à une priorité stricte des nœuds assurer des récompenses concentrées, permet au mécanisme d'atteindre le staking quadratique impact pour chaque type d’attaquant de corruption décrit à la section 9.3.3. Rappelons que ceci signifie spécifiquement dans notre cadre que, pour un réseau à n nœuds chacun avec un dépôt $d, un corrompu (de l’un des types ci-dessus) doit disposer d’un budget supérieur à $dn2/2. Pour être précis, le corrupteur doit corrompre au moins (n+1)/2 nœuds, puisque le corrupteur doit corrompre une majorité de n nœuds (pour n impair, par hypothèse). Ainsi, un organisme de surveillance doit gagnez une récompense de $d(n + 1)/2. Le corrupteur doit donc payer ce montant à chaquenœud pour garantir qu’aucun n’agit comme chien de garde. Nous travaillons à montrer formellement que si le corrupteur a un budget d'au plus $d(n2 + n)/2, alors l'équilibre parfait du sous-jeu du jeu entre les corrupteurs et les oracle – en d’autres termes, l’équilibre à à tout moment pendant le jeu - est pour le corrupteur de ne pas verser de pot-de-vin et pour chaque oracle rapporte honnêtement ses vraies valeurs. Nous avons expliqué ci-dessus comment il est possible qu'un corrompu qui réussisse exige une budget significativement plus grand que celui de la somme des dépôts des nœuds. Pour illustrer cela Résultat intuitif, la figure 16 montre graphiquement l'impact des récompenses d'alerte concentrées. Comme nous le voyons ici, si la récompense pour l'alerte du chien de garde, à savoir les dépôts de pots-de-vin, nœuds signalant faux) - ont été répartis entre toutes les alertes potentielles, le montant total qui auquel tout nœud d'alerte individuel pourrait s'attendre serait relativement petit, de l'ordre de $d. Un corrupteur, sachant qu’un paiement supérieur à d $ était improbable, pourrait utiliser un pot-de-vin conditionnel à faux résultat pour soudoyer chacun des n nœuds avec un peu plus de $d + ϵ. Contre-intuitivement, la figure 16 montre qu’un système qui distribue largement une récompense parmi les nœuds signalant une alerte est bien plus faible que celui qui concentre la récompense dans entre les mains d’un seul organisme de surveillance. Exemples de paramètres : Considérons un réseau (de premier niveau) avec n = 100 nœuds, chacun déposant \(d = \)20K. Ce réseau aurait un total de 2 M$ déposés mais être protégé contre un pot-de-vin avec le budget \(100M = \)dn2/2. Augmenter le nombre de oracles est bien sûr plus efficace que d'augmenter $d, et peut avoir un effet dramatique : un réseau avec n = 300 nœuds et des dépôts \(d = \)20K serait protégé contre un un pot-de-vin avec un budget allant jusqu'à 900 millions de dollars. Notez qu'un système staking peut dans de nombreux cas protéger les smart contract représentant plus de valeur que le niveau de protection contre la corruption offert. C'est parce qu'un adversaire Dans de nombreux cas, attaquer ces contrats ne peut pas en extraire la pleine valeur. Par exemple, un Un contrat alimenté par Chainlink garantissant une valeur de 1 milliard de dollars ne peut exiger qu'une garantie contre un un pot-de-vin avec 100 millions de dollars de ressources, car un tel adversaire peut vraisemblablement en tirer un profit de seulement 10% de la valeur du contrat. Remarque : L’idée selon laquelle la valeur d’un réseau peut croître de façon quadratique s’exprime dans la célèbre loi de Metcalfe [167, 235], qui stipule que la valeur d’un réseau croît quadratiquement en nombre d’entités connectées. Cependant, la loi de Metcalfe découle de la croissance du nombre de connexions réseau potentielles par paires, un phénomène différent de celui sous-jacent à l'impact quadratique staking de notre incitation mécanisme. 9.4.3 Réalisation du deuxième niveau Deux caractéristiques opérationnelles facilitent la réalisation d'un deuxième niveau de haute fiabilité : (1) L'arbitrage de deuxième niveau devrait être un événement rare dans les réseaux oracle et peut donc être significativement plus coûteux que le fonctionnement normal du premier niveau et (2) En supposantdes rapports acceptés avec optimisme – ou des contrats dont l’exécution peut attendre l’arbitrage – le deuxième niveau n'a pas besoin d'être exécuté en temps réel. Ces fonctionnalités se traduisent par une gamme de options de configuration pour le deuxième niveau afin de répondre aux exigences de DON particuliers. À titre d'exemple d'approche, un comité de deuxième niveau peut être composé de nœuds sélectionnés par un DON (c'est-à-dire, premier niveau) à partir des nœuds les plus anciens et les plus fiables du Chainlink réseau. En plus d'une expérience opérationnelle pertinente et considérable, les opérateurs de ces nœuds ont une incitation implicite considérable dans le FFO qui motive un désir pour garantir que le réseau Chainlink reste hautement fiable. Ils ont également publiquement des historiques de performances disponibles qui assurent la transparence de leur fiabilité. Il convient de noter que les nœuds de deuxième niveau ne doivent pas nécessairement participer au réseau de premier niveau, et peut évaluer les défauts sur plusieurs réseaux de premier niveau. Les nœuds dans un DON donné peuvent pré-désigner et s'engager publiquement sur un ensemble de n' tels nœuds comme constituant le comité de deuxième niveau pour ce DON. De plus, DON les nœuds publient un paramètre k′ ≤n′ qui détermine le nombre de votes de deuxième niveau nécessaire pour pénaliser un nœud de premier niveau. Lorsqu'une alerte est générée pour un rapport donné, les membres du deuxième niveau votent sur l'exactitude des valeurs fournies par chacun des nœuds de premier niveau. Tout nœud de premier niveau qui reçoit k' votes négatifs perd son statut. dépôts au nœud de surveillance. En raison de la rareté des jugements et de la possibilité d’une exécution prolongée Comme indiqué ci-dessus, contrairement au premier niveau, les nœuds du deuxième niveau peuvent : 1. Soyez hautement rémunéré pour la conduite de l’arbitrage. 2. S'appuyer sur des sources de données supplémentaires, au-delà même de l'ensemble diversifié utilisé par la première. 3. S'appuyer sur une inspection et une intervention manuelles et/ou expertes, par exemple pour identifier et concilier les erreurs dans les données sources et faire la distinction entre un relais de nœud honnête des données défectueuses et un nœud qui se comporte mal. Nous soulignons que l'approche que nous venons de décrire pour la sélection des nœuds de second niveau et la politique régissant l'arbitrage ne représente qu'un point dans un vaste ensemble. espace de conception des réalisations possibles du deuxième niveau. Notre mécanisme d’incitation offre une flexibilité totale quant à la manière dont le deuxième niveau est réalisé. Les DON individuels peuvent ainsi constituer et fixer des règles pour leurs deuxièmes niveaux qui répondent aux exigences particulières et les attentes des nœuds et des utilisateurs participants. DECO et Town Crier comme outils d’arbitrage : C'est essentiel pour le deuxième niveau dans notre mécanisme pour pouvoir distinguer les nœuds adverses de premier niveau qui produire intentionnellement des rapports incorrects et des nœuds honnêtes de premier niveau qui, involontairement, relayer des données incorrectes à la source. Ce n'est qu'alors que le deuxième niveau pourra mettre en œuvre couper pour décourager la triche, le but de notre mécanisme. DECO et Crieur public sont des outils puissants qui peuvent permettre aux nœuds de deuxième niveau de faire cette distinction critique de manière fiable.Les nœuds de deuxième niveau peuvent dans certains cas être en mesure d'interroger directement la source de données utilisée par un nœud de premier niveau ou utilisez la section ADO 7.1 afin de vérifier si un rapport incorrect résulte d'une source de données défectueuse. Dans d'autres cas, cependant, les nœuds de deuxième niveau peuvent manquer accès direct à la source de données d’un nœud de premier niveau. Dans de tels cas, une décision correcte serait semblent irréalisables ou nécessitent de s’appuyer sur un jugement subjectif. Précédent oracle Les systèmes de règlement des différends se sont appuyés sur des tours de scrutin inefficaces et de plus en plus nombreux pour résoudre ces problèmes. défis. Cependant, en utilisant DECO ou Town Crier, un nœud de premier niveau peut prouver un comportement correct. aux nœuds de deuxième niveau. (Voir la section 3.6.2 pour plus de détails sur les deux systèmes.) Plus précisément, si le nœud de deuxième niveau identifie un nœud de premier niveau comme ayant généré une valeur de rapport erronée ˜r, le nœud de premier niveau peut utiliser DECO ou Town Crier pour générer des preuves inviolables pour nœuds de deuxième niveau qu'il relaie correctement ou correctement à partir d'une source (compatible TLS) reconnu comme faisant autorité par le DON. Il est important de noter que le nœud de premier niveau peut le faire sans nœuds de deuxième niveau nécessitant un accès direct à la source de données.17 Par conséquent, une évaluation correcte est possible dans Chainlink pour toute source de données souhaitée. 9.4.4 Fausse déclaration d'assurance La forte résistance à la corruption obtenue grâce à notre mécanisme staking repose fondamentalement sur les fonds réduits accordés aux alerteurs. Sans récompense monétaire, les alerteurs n’ont aucune incitation directe à rejeter les pots-de-vin. En conséquence, toutefois, les fonds réduits ne sont pas disponible pour indemniser les utilisateurs lésés par des rapports incorrects, par exemple les utilisateurs qui perdent de l'argent lorsque des données de prix incorrectes sont transmises à un smart contract. Par hypothèse, les rapports incorrects ne posent pas de problème si les rapports sont acceptés par un contrat seulement après une éventuelle arbitrage, c'est-à-dire une action du deuxième niveau. Comme expliqué cependant, pour obtenir la meilleure performance possible, les contrats peuvent plutôt s'appuyer sur avec optimisme quant au mécanisme permettant d'imposer des rapports corrects, ce qui signifie qu'ils acceptent rapports avant une éventuelle décision de deuxième niveau. En effet, un tel comportement optimiste est sûr dans notre modèle en supposant des adversaires rationnels dont les budgets ne dépassent pas le staking impact du mécanisme. Les utilisateurs préoccupés par l'éventualité improbable d'une défaillance du mécanisme résultant, Par exemple, des adversaires disposant de ressources financières considérables pourraient souhaiter utiliser une couche supplémentaire de sécurité économique sous la forme d’une assurance contre les fausses déclarations. Nous connaissons plusieurs assureurs ont déjà l’intention de proposer des polices de ce type adossées à des contrats intelligents pour les protocoles sécurisés Chainlink dans un avenir proche, notamment via des mécanismes innovants tels que les DAO, par exemple [7]. L'existence d'un historique de performances pour Chainlink Les nœuds et d'autres données sur les nœuds, telles que les montants de leurs mises, fournissent une base exceptionnellement solide pour les évaluations actuarielles du risque, permettant ainsi de fixer le prix des politiques. d’une manière peu coûteuse pour les assurés mais durable pour les assureurs. 17Avec Town Crier, il est en outre possible pour les nœuds de premier niveau de générer localement des attestations. d'exactitude des rapports qu'ils génèrent et fournissent ces attestations aux nœuds de deuxième niveau sur un selon les besoins.Des formes de base d’assurance contre les fausses déclarations peuvent être mises en œuvre de manière fiable et fiable. de manière efficace en utilisant les smart contract. A titre d'exemple simple, une assurance paramétrique Les SCins contractuelles peuvent indemniser automatiquement les assurés si notre mécanisme d’incitation le deuxième niveau identifie une erreur dans un rapport généré au premier niveau. Un utilisateur U qui souhaite souscrire une police d'assurance, par exemple le créateur d'une cible contrat SC, peut introduire une demande auprès d'un assureur décentralisé pour un montant de police M$ sur le contrat. En approuvant U, l'assureur peut fixer un montant continu (par exemple mensuel) prime de $P en SCins. Pendant que U paie la prime, sa police reste active. Si un échec de reporting se produit dans SC, le résultat sera l'émission d'une paire (r1, r2) de rapports contradictoires pour SC, où r1 est signé par le premier niveau de notre mécanisme et r2, le rapport corrigé correspondant, est signé par le deuxième niveau. Si le U fournit une telle paire valide (r1, r2) à SCins, le contrat lui verse automatiquement M$, à condition ses paiements de primes sont à jour. 9.5 Variante à un tour Le protocole décrit dans la sous-section précédente exige que le comité de deuxième niveau attende plusieurs tours pour déterminer si un organisme de surveillance a déclenché une alerte. Ceci Cette exigence est valable même dans le cas optimiste, c'est-à-dire lorsque le premier niveau fonctionne. correctement. Pour les utilisateurs peu disposés à accepter les rapports avec optimisme, c'est-à-dire avant décision, les délais associés à cette approche seraient irréalisables. Pour cette raison, nous étudions également des protocoles alternatifs qui ne nécessitent qu'un seul rond. Dans cette approche, tous les nœuds oracle soumettent des bits secrets indiquant si oui ou non ils souhaitent lancer une alerte. Le comité de deuxième niveau vérifie ensuite ces valeurs ordre de priorité. Pour donner une idée générale, un tel schéma pourrait impliquer les éléments suivants étapes : 1. Soumission du bit de surveillance : chaque nœud Oi partage un secret avec une valeur de surveillance d'un bit. wi ∈{no alert, alert} parmi les nœuds du deuxième niveau pour chaque rapport qu'il génère. 2. Conseils anonymes : n'importe quel nœud oracle peut soumettre un conseil anonyme α au comité de deuxième niveau au cours du même cycle au cours duquel les bits de surveillance sont soumis. Cette astuce α est un message indiquant qu'une alerte a été déclenchée pour le rapport en cours. 3. Vérification des bits de surveillance : le comité de deuxième niveau révèle le chien de garde des nœuds oracle bits par ordre de priorité. Notez que les nœuds ne doivent envoyer aucun bit de surveillance d’alerte lorsqu’ils n’alertent pas : sinon, l’analyse du trafic révèle les bits de tous les nœuds. Le protocole révèle l'absence d'alerte bits de surveillance des nœuds avec une priorité plus élevée que le chien de garde d'alerte ayant la priorité la plus élevée. Observez que ce qui est révélé est identique à celui de notre protocole n-round. Les récompenses sont également distribuées de manière identique à ce système, c'est-à-dire le premier chien de garde identifié reçoit les dépôts réduits des nœuds qui ont soumis des rapports incorrects.L'utilisation de conseils anonymes permet au comité de deuxième niveau de rester non interactif dans les cas où aucune alerte n'a été déclenchée, réduisant ainsi la complexité de la communication. dans le cas commun. Notez que tout organisme de surveillance qui déclenche une alerte est économiquement incité à soumettre un signalement anonyme : si aucun signalement n'est soumis, aucune récompense n'est versée à quiconque. nœud. Pour garantir que l'expéditeur Oi d'un signalement anonyme α ne puisse pas être identifié par le adversaire basé sur les données du réseau, le conseil anonyme peut être envoyé via un canal, par exemple via Tor, ou, plus pratiquement, via un proxy via un fournisseur de services cloud. À authentifier la pointe comme provenant de O, Oi peut signer α en utilisant une signature en anneau [39, 192]. Alternativement, pour empêcher les attaques par déni de service non attribuables contre le comité de deuxième niveau par un nœud oracle malveillant, α peut être un identifiant anonyme avec anonymat révocable [73]. Ce protocole, bien que pratiquement réalisable, nécessite une ingénierie quelque peu lourde exigences (que nous étudions les moyens de réduire). Les nœuds de premier niveau, par exemple, doit communiquer directement avec les nœuds de deuxième niveau, nécessitant la maintenance d'un annuaire. Le besoin de canaux anonymes et de signatures en anneau s'ajoute à l'ingénierie complexité du schéma. Enfin, il existe une exigence particulière de confiance, brièvement évoquée dans la note ci-dessous. Nous étudions donc également des schémas plus simples qui permettent néanmoins d'atteindre impact super-linéaire staking, mais peut-être moins que quadratique, dans lequel un corrupteur a asymptotiquement besoin de ressources d'au moins $n log n, par exemple. Certains des régimes visés la considération implique la sélection aléatoire d'un sous-ensemble strict de nœuds pour agir en tant que chiens de garde, auquel cas la corruption éventuelle devient une attaque particulièrement puissante. Remarque : La sécurité de ce mécanisme staking à un tour nécessite des ressources inexploitables. canaux entre oracle et les nœuds de deuxième niveau - une exigence standard dans les systèmes résistants à la coercition, par exemple le vote [82, 138], et une exigence raisonnable dans la pratique. De plus, cependant, un nœud Oi qui cherche à coopérer avec un corrupteur peut construire ses secrets sont partagés de manière à montrer au corrupteur qu'il a codé un code particulier valeur. Par exemple, si Oi ne sait pas quels nœuds contrôle le corrupteur, alors Oi peut soumettre des actions de valeur 0 à tous les membres du comité. Le corrupteur peut alors vérifier les Oi conformité de manière probabiliste. Pour éviter ce problème dans tout protocole à un seul tour, nous exiger que Oi connaisse l’identité d’au moins un nœud honnête de deuxième niveau. Avec un protocole interactif dans lequel chaque nœud de deuxième niveau ajoute une randomisation facteur aux actions, le mieux que le corrupteur puisse faire est d'imposer la sélection par Oi d'un peu de chien de garde. 9.6 Cadre d'incitation implicite (IIF) Le FFO est une forme d'incitation implicite au comportement correct dans le réseau Chainlink. Il fonctionne comme une participation explicite, c’est-à-dire des dépôts, dans la mesure où elle contribue à renforcer la sécurité économique des le réseau. En d’autres termes, les FFO devraient être inclus dans le cadre du dépôt (efficace) $d d'un nœud du réseau.La question est : comment mesurer les FFO et d’autres formes d’incitations implicites ? au sein du réseau Chainlink ? Le cadre d'incitation implicite (IIF) est un ensemble de principes et techniques que nous envisageons de développer à cet effet. Systèmes de blockchain fournissent de nombreuses formes de transparence sans précédent et les enregistrements de haute confiance des nœuds Les performances qu’ils créent constituent un tremplin pour notre vision du fonctionnement de l’IIF. Nous esquissons ici très brièvement des idées sur les éléments clés du CII. L'IIF lui-même comprendra un ensemble de facteurs que nous identifions comme importants pour évaluer des incitations implicites, ainsi que des mécanismes de publication de données pertinentes sous une forme de haute assurance pour être utilisées par des algorithmes d'analyse. Différents utilisateurs Chainlink peuvent souhaitent utiliser l’IIF de différentes manières, par exemple en accordant une pondération différente à différents facteurs. Nous nous attendons à ce que des services d'analyse apparaissent dans la communauté pour aider les utilisateurs à appliquer l'IIF. en fonction de leurs préférences individuelles en matière d'évaluation des risques, et notre objectif est de faciliter ces services en garantissant leur accès à des données de support de haute assurance et en temps opportun, comme nous le discutons ci-dessous (section 9.6.4). 9.6.1 Opportunité de frais futurs Les nœuds participent à l'écosystème Chainlink pour gagner une part des frais que les réseaux paient pour l'un des différents services que nous avons décrits dans cet article, de les données ordinaires alimentent des services avancés tels que l'identité décentralisée, le séquençage équitable, et la préservation de la confidentialité DeFi. Les frais du réseau Chainlink prennent en charge les coûts des opérateurs de nœuds, par exemple pour l'exécution des serveurs, l'acquisition des licences de données nécessaires et la maintenance. une équipe mondiale pour garantir une disponibilité élevée. Le FFO désigne les frais de service, nets de frais, qu'un nœud a tout à gagner à l'avenir, ou à perdre s'il démontre un comportement défectueux. Le FFO est une forme de participation qui permet de sécuriser le réseau. Une caractéristique utile de FFO est le fait que les données en chaîne (complétées par des données hors chaîne) données) établissent un enregistrement de haute confiance de l’historique d’un nœud, permettant le calcul du FFO de manière transparente et empirique. Une mesure simple et de premier ordre des FFO peut être dérivée du revenu net moyen d'un nœud sur une période donnée (c’est-à-dire les revenus bruts moins les dépenses d’exploitation). FFO peut puis être calculé comme, par exemple, la valeur actuelle nette [114] des revenus nets futurs cumulés, en d’autres termes, la valeur actualisée dans le temps de tous les gains futurs. Les revenus des nœuds peuvent toutefois être volatils, comme le montre par exemple la figure 17. Plus important encore, les revenus des nœuds peuvent ne pas suivre une distribution stationnaire au fil du temps. Par conséquent, d’autres facteurs que nous prévoyons d’explorer dans l’estimation des FFO comprennent : • Historique des performances : l'historique des performances d'un opérateur, y compris l'exactitude et l'actualité de ses rapports, ainsi que sa disponibilité, fournit un objectif. pierre de touche permettant aux utilisateurs d'évaluer sa fiabilité. L'historique des performances sera ainsi fournir un facteur critique dans la sélection par les utilisateurs des nœuds oracle (ou, avec l'avènement de DONs, leur sélection de DONs). Un solide historique de performances est susceptible de sont en corrélation avec des revenus continus élevés.18 18Une question de recherche importante que nous entendons aborder est la détection des volumes de services falsifiés.Figure 17 : Revenus gagnés par les nœuds Chainlink sur un seul flux de données (ETH-USD) pendant une semaine représentative en mars 2021. • Accès aux données : même si les oracle peuvent obtenir de nombreuses formes de données à partir d'API ouvertes, certaines formes de données ou certaines sources de haute qualité peuvent être disponibles uniquement sur un par abonnement ou par le biais d'accords contractuels. Un accès privilégié à certains les sources de données peuvent jouer un rôle dans la création d’un flux de revenus stable. • Participation DON : avec l'avènement des DON, des communautés de nœuds viendront ensemble pour fournir des services particuliers. Nous nous attendons à ce que de nombreux DON incluent opérateurs sur une base sélective, établissant la participation dans des DON réputés en tant que position privilégiée sur le marché qui permet d’assurer une source de revenus constante. • Activité multiplateforme : certains opérateurs de nœuds peuvent avoir une présence bien établie et des antécédents de performances dans d'autres contextes, par exemple en tant que PoS validator ou fournisseurs de données dans des contextes non blockchain. Leurs performances dans ces autres systèmes (lorsque les données les concernant sont disponibles sous une forme fiable) peuvent éclairer l'évaluation. de leur historique de performances. De même, comportement défectueux dans le réseau Chainlink peut compromettre les revenus de ces autres systèmes en chassant les utilisateurs, c'est-à-dire les FFO peut s’étendre sur toutes les plateformes. 9.6.2 FFO spéculatifs Les opérateurs de nœuds participent au réseau Chainlink non seulement pour générer des revenus grâce à opérations, mais de créer et de se positionner pour profiter de nouvelles opportunités de gestion d'emplois. En d’autres termes, les dépenses des nœuds oracle du réseau sont également une déclaration positive sur l'avenir de DeFi et d'autres applications de contrats intelligents domaines ainsi que les applications émergentes non-blockchain des réseaux oracle. Les opérateurs de nœuds gagnent aujourd'hui les frais disponibles sur les réseaux Chainlink existants et simultanément Ceux-ci sont vaguement analogues aux faux avis sur les sites Internet, sauf que le problème est plus simple dans le oracle parce que nous avons un enregistrement définitif indiquant si les marchandises, c'est-à-dire les rapports, ont été commandées et livrés, par opposition aux biens physiques commandés dans les boutiques en ligne, par exemple. Autrement dit, dans le oracle Dans ce contexte, les performances peuvent être validées, même si la véracité du client ne le peut pas.bâtir une réputation, un historique de performance et une expertise opérationnelle qui positionneront avantageusement pour gagner des frais disponibles dans les futurs réseaux (sous réserve, bien sûr, sur un comportement honnête). Les nœuds opérant aujourd'hui dans l'écosystème Chainlink seront dans ce cadre sens d'avoir un avantage sur les nouveaux arrivants en gagnant les frais supplémentaires Chainlink les services deviennent disponibles. Cet avantage s'applique aux nouveaux opérateurs, ainsi qu'aux entreprises technologiques jouissant d'une réputation établie ; par exemple, T-Systems, une société traditionnelle fournisseur de technologie (filiale de Deutsche Telekom) et Kraken, une grande société centralisée échange, ont établi des présences précoces dans l’écosystème Chainlink [28, 143]. Une telle participation des nœuds oracle à des opportunités futures peut être considérée comme elle-même comme une sorte de FFO spéculatif, et constitue ainsi une forme de participation dans le Chainlink réseau. 9.6.3 Réputation externe L'IIF tel que nous l'avons décrit peut fonctionner en réseau avec des acteurs strictement pseudonymes. opérateurs, c’est-à-dire sans divulgation des personnes ou des entités du monde réel impliquées. Toutefois, un facteur potentiellement important dans la sélection des prestataires par les utilisateurs est l’externe. réputation. Par réputation externe, nous entendons la perception de fiabilité attachée aux identités du monde réel, plutôt qu’aux pseudonymes. Risque de réputation lié à les identités du monde réel peuvent être considérées comme une forme d’incitation implicite. Nous considérons la réputation à travers le prisme de l’IIF, c’est-à-dire, dans un sens cryptoéconomique, comme moyen d’établir activité multiplateforme qui peut être intégrée aux estimations des FFO. L’avantage d’utiliser la réputation externe comme facteur dans les estimations des FFO, par opposition au lien pseudonyme, c'est que la réputation externe lie la performance non seulement à un aux activités existantes de l’opérateur, mais également aux activités futures. Si, par exemple, une mauvaise réputation s’attache à un individu, il peut entacher les futures entreprises de cette personne. En d’autres termes, la réputation externe peut capter une part plus large des FFO que les pseudonymes. les dossiers de performance, comme l'impact d'un malversation attaché à une personne ou établi Il est plus difficile d’échapper à une entreprise que celle associée à une opération pseudonyme. Chainlink est compatible avec les technologies d'identité décentralisées (Section 4.3) qui peut fournir un soutien pour l’utilisation de la réputation externe au sein de l’IIF. De telles technologies peut valider et ainsi contribuer à garantir la véracité des affirmations du monde réel affirmées par les opérateurs. identités.19 9.6.4 Ouvrir l'analyse IIF L'IIF, comme nous l'avons noté, vise à fournir des données et des outils open source fiables pour analyses incitatives implicites. L'objectif est de permettre aux prestataires de la communauté développer des analyses adaptées aux besoins d’évaluation des risques des différentes parties du secteur Base d'utilisateurs Chainlink. 19Les identifiants décentralisés peuvent également, si désiré, embellir les pseudonymes avec des informations complémentaires. Par exemple, un opérateur de nœud pourrait en principe utiliser ces informations d'identification pour prouver qu'il s'agit d'une entreprise Fortune 500, sans révéler laquelle.Une quantité considérable de données historiques concernant les revenus et les performances des nœuds réside sur la chaîne sous une forme immuable et de haute confiance. Notre objectif est cependant de fournir le des données les plus complètes possibles, y compris des données sur les comportements visibles uniquement hors chaîne, comme le reporting hors chaîne (OCR) ou l'activité DON. De telles données peuvent potentiellement être volumineux. La meilleure façon de le conserver et d'assurer son intégrité, c'est-à-dire de le protéger des la falsification, nous pensons, se fera avec l'aide de DON, en utilisant les techniques discutées à la section 3.3. Certaines incitations se prêtent à des formes directes de mesure, telles que staking dépôts et FFO de base. D’autres, comme les FFO spéculatifs et la réputation, sont plus difficiles à évaluer. mesurer de manière objective, mais nous pensons que les formes de données de support, y compris croissance historique de l'écosystème Chainlink, mesures de réputation sur les réseaux sociaux, etc., peut prendre en charge les modèles d'analyse IIF même pour ces éléments plus difficiles à quantifier. Nous pouvons imaginer que des DON dédiés apparaissent spécifiquement pour surveiller, valider et enregistrer des données relatives aux enregistrements de performances hors chaîne des nœuds, ainsi que d'autres données utilisées dans l'IIF, telles que les informations d'identité validées. Ces DON peuvent fournir des données IIF uniformes et hautement fiables à tous les fournisseurs d'analyse desservant la communauté Chainlink. Ils fourniront également un record en or qui fait valoir les affirmations des fournisseurs d'analyses. vérifiable de manière indépendante par la communauté. 9.7 Rassembler tout cela : incitations pour les opérateurs de nœuds Synthèse de nos discussions ci-dessus sur les incitations explicites et implicites pour les opérateurs de nœuds fournit une vue globale de la manière dont les opérateurs de nœuds participent et bénéficient de le réseau Chainlink. À titre de guide conceptuel, nous pouvons exprimer le total des actifs en jeu par un Chainlink donné. opérateur de nœud $S sous une forme grossière et stylisée comme : \(S ≈\)D + \(F + \)FS + $R, où : • $D est la somme de toutes les mises explicitement déposées sur tous les réseaux dans lesquels l'opérateur participe ; • $F est la valeur actuelle nette de l'ensemble de tous les FFO sur tous les réseaux du pays. auquel l'opérateur participe ; • $FS est la valeur actuelle nette des FFO spéculatifs de l'opérateur ; et • $R est le capital de réputation de l'opérateur en dehors de l'écosystème Chainlink. qui pourrait être compromis par un mauvais comportement identifié dans ses nœuds oracle. Bien que largement conceptuelle, cette égalité approximative montre utilement qu'il existe une multiplicité de facteurs économiques favorisant les performances de haute fiabilité des nœuds Chainlink. Tous ces facteurs autres que $D sont présents dans les réseaux Chainlink d'aujourd'hui.9.8 Le cycle vertueux de la sécurité économique La combinaison de l'impact super-linéaire staking avec la représentation des paiements de frais car les opportunités de frais futurs (FFO) dans l'IIF peuvent conduire à ce que nous appelons le cercle vertueux de sécurité économique dans un réseau oracle. Cela peut être considéré comme une sorte d’économie d'échelle. À mesure que le montant total garanti par un réseau particulier augmente, le montant de l’enjeu supplémentaire qu’il faut pour ajouter un montant fixe de sécurité économique diminue tout comme le coût moyen par utilisateur. Il est donc moins cher, en termes de frais, pour un utilisateur d’adhérer un réseau déjà existant que d'obtenir la même augmentation de l'économie du réseau sécurité en créant un nouveau réseau. Il est important de noter que l'ajout de chaque nouvel utilisateur réduit le coût du service pour tous les utilisateurs précédents de ce réseau. Étant donné une structure de frais particulière (par exemple un taux de rendement particulier sur le montant misé), si le total des frais perçus par un réseau augmente, cela encourage le flux de revenus supplémentaires. participation dans le réseau pour le sécuriser à un taux plus élevé. Plus précisément, si la mise totale qu'un nœud individuel peut détenir dans le système est plafonné, puis lorsque de nouveaux paiements de frais entrez dans le système en augmentant son FFO, le nombre de nœuds n augmentera. Merci au impact super-linéaire staking de la conception de notre système d'incitation, la sécurité économique de le système augmentera plus vite que n, par exemple comme n2 dans le mécanisme que nous avons esquissé à la section 9.4. En conséquence, le coût moyen de la sécurité économique, c'est-à-dire le montant de la participation un dollar de sécurité économique va chuter. Le réseau peut donc facturer à ses utilisateurs des frais inférieurs. En supposant que la demande de services oracle est élastique (voir, par exemple, [31] pour un bref explication), la demande va augmenter, générant des frais et des FFO supplémentaires. Nous illustrons ce point avec l’exemple suivant. Exemple 5. Depuis la sécurité économique d'un réseau oracle avec notre incitation le programme est \(dn2 for stake \)dn, la sécurité économique apportée par un dollar de mise est n et donc le coût moyen par dollar de sécurité économique, c'est-à-dire le montant de la mise contribuer à un dollar de sécurité économique – est de 1/n. Considérons un réseau dans lequel les incitations économiques sont entièrement constituées de FFO, plafonnées à \(d ≤\)10K par nœud. Supposons que le réseau ait n = 3 nœuds. Alors le coût moyen par dollar de sécurité économique est d’environ 0,33 $. Supposons que le FFO total du réseau dépasse \(30K (e.g., to \)31K). Étant donné le plafond du FFO par nœud, le réseau s'étend jusqu'à (au moins) n = 4. Maintenant, le coût moyen par dollar de sécurité économique tombe à environ 0,25 dollar. Nous illustrons schématiquement le cycle vertueux complet de la sécurité économique dans les réseaux oracle sur la figure 18. Nous soulignons que le cercle vertueux de la sécurité économique découle de l’effet des utilisateurs mutualisant leurs tarifs. C'est leur FFO collectif qui œuvre en faveur d'un plus grand taille des réseaux et donc une plus grande sécurité collective. Nous notons également que le cercle vertueux de la sécurité économique favorise la réalisation de la viabilité financière des DON. Une fois créés, les DON qui répondent aux besoins des utilisateurs devraient se développer jusqu'au point où les revenus provenant des frais dépassent les coûts opérationnels des nœuds oracle.

Figure 18 : Schéma du cycle vertueux de Chainlink staking. Une hausse des frais d’utilisation les paiements à un réseau oracle 1⃝ provoquent sa croissance, entraînant une croissance de son économie sécurité 2⃝. Cette croissance super-linéaire réalise des économies d'échelle dans les réseaux Chainlink 3⃝. Plus précisément, cela signifie une réduction du coût moyen de la sécurité économique, c'est-à-dire la sécurité économique par dollar découlant du paiement de frais ou d’autres sources de participation augmente. Des coûts inférieurs, répercutés sur les utilisateurs, stimulent une demande accrue de oracle prestations 4⃝. 9.9 Facteurs supplémentaires qui stimulent la croissance du réseau Alors que l'écosystème Chainlink continue de se développer, nous pensons que son attractivité aux utilisateurs et leur importance à mesure que l’infrastructure pour l’économie blockchain va s’accélérer. La valeur fournie par les réseaux oracle est super-linéaire, ce qui signifie qu'elle croît plus rapidementque la taille des réseaux eux-mêmes. Cette croissance de la valeur provient à la fois des économies d’échelle (une plus grande rentabilité par utilisateur à mesure que les volumes de services augmentent) et effets de réseau : augmentation de l'utilité du réseau à mesure que les utilisateurs adoptent plus largement les DON. Alors que les smart contract existants continuent de voir davantage de valeur sécurisée et entièrement nouvelle Les candidatures smart contract sont rendues possibles par des services plus décentralisés, le total l'utilisation et les frais globaux payés aux DON devraient augmenter. Augmentation des pools de frais dans se traduire à son tour par les moyens et les incitations nécessaires pour créer des services encore plus décentralisés, ce qui crée un cercle vertueux. Ce cercle vertueux résout un problème critique de la poule et de l’œuf problème dans l’écosystème hybride smart contract : fonctionnalités innovantes smart contract nécessitent souvent des services décentralisés qui n'existent pas encore (par exemple, de nouveaux marchés DeFi souvent nécessitent de nouveaux flux de données) mais nécessitent une demande économique suffisante pour voir le jour. La mise en commun des frais par divers smart contract pour les DON existants signalera une demande de services décentralisés supplémentaires provenant d'une base d'utilisateurs croissante, donnant lieu à leur création par DONs et une activation continue de smart contract hybrides nouveaux et variés. En résumé, nous pensons que la croissance de la sécurité des réseaux portée par des Les cycles du mécanisme Chainlink staking illustrent des modèles de croissance plus larges qui le réseau Chainlink peut contribuer à créer une économie en chaîne pour la décentralisation prestations.

Conclusion

Dans cet article, nous avons présenté une vision de l’évolution de Chainlink. Le thème principal dans cette vision se trouve la capacité des réseaux oracle à fournir une gamme de services beaucoup plus large pour smart contracts que la simple livraison de données. En utilisant les DON comme base pour les services décentralisés du futur, Chainlink visera à fournir des fonctionnalités oracle performantes et à confidentialité améliorée. Ses réseaux oracle offriront une forte minimisation de la confiance grâce à une combinaison de mécanismes cryptoéconomiques fondés sur des principes tels que staking et des garde-corps soigneusement conçus et une application du niveau de service sur les chaînes principales fiables. DONs aidera également les systèmes de couche 2 à appliquer des politiques de commande flexibles et équitables sur les transactions, ainsi qu'à réduire les coûts de gaz pour les transactions acheminées par mempool. Pris ensemble, ces capacités vont toutes dans le sens d’une smart hybride sécurisée et richement fonctionnelle contrats. La flexibilité des DON améliorera les services Chainlink existants et donnera lieu à de nombreuses fonctionnalités et applications smart contract supplémentaires. Parmi ceux-ci sont sans couture connexion à une grande variété de systèmes hors chaîne, création d'identité décentralisée à partir de données existantes, canaux prioritaires pour garantir la livraison en temps opportun des infrastructures critiques transactions et instruments préservant la confidentialité DeFi. La vision que nous présentons ici est ambitieuse. À court terme, nous cherchons à responsabiliser contrats hybrides pour atteindre des objectifs hors de portée des smart contract aujourd'hui, tandis que à long terme, nous visons à réaliser une métacouche décentralisée. Heureusement, nous pouvons dessiner sur de nouveaux outils et idées, allant des algorithmes de consensus à la preuve sans connaissance systèmes – que la communauté développe à la suite d’une recherche en évolution rapide.

De même, nous prévoyons de donner la priorité à la mise en œuvre des idées contenues dans ce document en réponse aux besoins de la communauté d’utilisateurs de Chainlink. Nous attendons avec impatience la prochaine étape dans notre quête pour autonomiser les smart contract grâce à une connectivité universelle et établir les technologies décentralisées comme épine dorsale de la prochaine génération de systèmes financiers mondiaux et les systèmes juridiques. Remerciements Merci à Julian Alterini et Shawn Lee pour le rendu des figures dans cet article.