Cosmos: сеть распределенных реестров

Introduction

Le succès combiné de l'écosystème open source, le partage de fichiers décentralisé et les crypto-monnaies publiques ont a inspiré une compréhension que les protocoles Internet décentralisés peut être utilisé pour améliorer radicalement les infrastructures socio-économiques. Nous avons vu des applications blockchain spécialisées comme Bitcoin [1] (un crypto-monnaie), Zerocash [2] (une crypto-monnaie pour la confidentialité), et plateformes smart contract généralisées telles que Ethereum [3], avec d'innombrables applications distribuées pour l'Etherium Virtual Machine (EVM) telle qu'Augur (un marché de prédiction) et TheDAO [4] (un club d'investissement). Cependant, à ce jour, ces blockchain ont souffert de plusieurs d'inconvénients, y compris leur inefficacité énergétique flagrante, leur mauvaise ou des performances limitées et des mécanismes de gouvernance immatures. Propositions visant à augmenter le débit des transactions de Bitcoin, telles que Les témoins séparés [5] et BitcoinNG [6] sont à mise à l'échelle verticale. des solutions qui restent limitées par la capacité d’un seul organisme physique machine, afin de garantir la propriété d'une auditabilité complète. Le Lightning Network [7] peut aider à faire évoluer la transaction Bitcoin

volume en laissant certaines transactions hors du grand livre, et est bien adapté aux micropaiements et à la préservation de la confidentialité rails de paiement, mais peuvent ne pas convenir à des applications plus généralisées besoins de mise à l’échelle. Une solution idéale est celle qui permet à plusieurs blockchain parallèles de interopérer tout en conservant leurs propriétés de sécurité. Cela a s'est avéré difficile, voire impossible, avec proof-of-work. Fusionné l'exploitation minière, par exemple, permet au travail effectué de sécuriser un parent chaîne à réutiliser sur une chaîne enfant, mais les transactions doivent toujours être validé, dans l'ordre, par chaque nœud, et un blockchain fusionné est vulnérable aux attaques si la majorité du pouvoir hashing sur le le parent ne fusionne pas activement l'enfant. Une revue académique d'architectures de réseau blockchain alternatives sont fournies contexte supplémentaire, et nous fournissons des résumés d’autres propositions et leurs inconvénients dans les travaux connexes. Nous présentons ici Cosmos, une nouvelle architecture réseau blockchain qui répond à tous ces problèmes. Cosmos est un réseau de nombreux des blockchain indépendants, appelés zones. Les zones sont alimentées par Tendermint Core [8], qui fournit une haute performance, moteur de consensus cohérent et sécurisé de type PBFT, où des garanties strictes de responsabilité fork s'appliquent au comportement des éléments malveillants. acteurs. L'algorithme de consensus BFT de Tendermint Core est bien adapté pour la mise à l'échelle des proof-of-stake blockchain publics. La première zone sur Cosmos est appelée le hub Cosmos. Le Cosmos Hub est une crypto-monnaie proof-of-stake multi-actifs avec un simple mécanisme de gouvernance qui permet au réseau de s’adapter et mise à niveau. De plus, le hub Cosmos peut être étendu de connecter d’autres zones. Le hub et les zones du réseau Cosmos communiquent avec entre eux via un protocole de communication inter-blockchain (IBC), une sorte d'UDP ou TCP virtuel pour les blockchain. Les jetons peuvent être transféré d’une zone à une autre de manière sécurisée et rapidesans qu’il soit nécessaire d’échanger des liquidités entre zones. Au lieu de cela, tous les transferts inter-zones token passent par le Hub Cosmos, qui garde une trace du montant total de tokens détenu par chaque zone. Le Le hub isole chaque zone de la défaillance des autres zones. Parce que n'importe qui peut connecter une nouvelle zone au hub Cosmos, les zones le permettent pour une compatibilité future avec les nouvelles innovations blockchain. Dans cette section, nous décrivons le protocole de consensus Tendermint et l'interface utilisée pour créer des applications avec. Pour plus détails, voir l'annexe. Dans les algorithmes byzantins classiques de tolérance aux pannes (BFT), chaque nœud a le même poids. Dans Tendermint, les nœuds ont une valeur non négative quantité de pouvoir de vote et nœuds qui ont un vote positif puissance sont appelés validators. Les validateurs participent au protocole de consensus en diffusant des signatures cryptographiques, ou votes, pour se mettre d’accord sur le prochain bloc. Les pouvoirs de vote des validateurs sont déterminés dès la genèse, ou sont modifié de manière déterministe par le blockchain, en fonction du demande. Par exemple, dans une application proof-of-stake telle que le Cosmos Hub, le pouvoir de vote peut être déterminé par le montant de staking tokens cautionné en garantie. REMARQUE : Les fractions telles que ⅔ et ⅓ font référence à des fractions du total des votes. puissance, jamais le nombre total de validator, à moins que tous les validator ont un poids égal. >⅔ signifie « plus de ⅔ », ≥⅓ signifie « au moins ⅓”. Tendermint est un protocole de consensus BFT partiellement synchrone dérivé de l'algorithme de consensus DLS [20]. La menthe tendre est

remarquable par sa simplicité, ses performances et sa responsabilité fork. Le protocole nécessite un ensemble connu et fixe de validator, où chaque validator est identifié par sa clé publique. Les validateurs tentent de parvenir à un consensus sur un bloc à la fois, où un bloc est une liste de transactions. Le vote pour le consensus sur un bloc se déroule dans tours. Chaque tour a un leader, ou proposant, qui propose un bloc. Les validator votent ensuite, par étapes, pour savoir si pour accepter le blocage proposé ou passer au tour suivant. Le le proposant pour un tour est choisi de manière déterministe parmi les liste des validator, proportionnellement à leur pouvoir de vote. Les détails complets du protocole sont décrits ici. La sécurité de Tendermint découle de son utilisation optimale du byzantin tolérance aux pannes via un vote à super majorité (>⅔) et un verrouillage mécanisme. Ensemble, ils veillent à ce que : ≥⅓ du pouvoir de vote doit être byzantin pour provoquer une violation de la sécurité, où plus de deux valeurs sont engagées. si un ensemble de validator réussit à violer la sécurité, ou même tente de le faire, ils peuvent être identifiés par le protocole. Ceci comprend à la fois le vote pour les blocs conflictuels et la diffusion votes injustifiés. Malgré ses fortes garanties, Tendermint offre des performances. Dans des benchmarks de 64 nœuds répartis sur 7 des datacenters sur les 5 continents, sur des instances cloud commodités, Le consensus Tendermint peut traiter des milliers de transactions par deuxièmement, avec des latences de validation de l’ordre d’une à deux secondes. Notamment, la performance de plus d'un millier de transactions par la seconde est maintenue même dans des conditions adverses difficiles, avec validators plante ou diffuse des votes frauduleux. Voir la figure ci-dessous pour plus de détails.

Un avantage majeur de l’algorithme de consensus de Tendermint est la simplification sécurité client légère, ce qui en fait un candidat idéal pour les applications mobiles et cas d'utilisation de l'Internet des objets. Alors qu'un client léger Bitcoin doit se synchroniser chaînes d'en-têtes de bloc et trouver celle avec le plus de preuves de fonctionnent, les clients légers de Tendermint n'ont qu'à suivre les changements à l'ensemble validator, puis vérifiez les >⅔ PreCommits dans le dernier bloc pour déterminer le dernier état. Des épreuves client légères et succinctes permettent également d'inter-blockchain communications. Tendermint dispose de mesures de protection pour empêcher certains attaques notables, comme les doubles dépenses à longue portée sans enjeu et la censure. Ceux-ci sont discutés plus en détail dans l’annexe.L'algorithme de consensus Tendermint est implémenté dans un programme appelé Tendermint Core. Tendermint Core est un « moteur de consensus » indépendant des applications, capable de transformer n'importe quelle application de boîte noire déterministe dans une application répliquée de manière distribuée blockchain. Tendermint Core se connecte aux applications blockchain via l'interface Application Blockchain (ABCI) [17]. Ainsi, ABCI permet de programmer des applications blockchain dans n'importe quel langage, pas seulement le langage de programmation que le consensus moteur est écrit. De plus, ABCI permet de facilement échangez la couche de consensus de toute pile blockchain existante. Nous faisons une analogie avec la célèbre crypto-monnaie Bitcoin. Bitcoin est une crypto-monnaie blockchain où chaque nœud conserve une base de données entièrement auditée sur les résultats des transactions non dépensées (UTXO). Si on voulait créer un système de type Bitcoin au-dessus de ABCI, Tendermint Core serait responsable de Partage de blocs et de transactions entre nœuds Établir un ordre canonique/immuable des transactions (le blockchain) Pendant ce temps, l'application ABCI serait chargée de Maintenance de la base de données UTXO Validation des signatures cryptographiques des transactions Empêcher les transactions de dépenser des fonds inexistants Autoriser les clients à interroger la base de données UTXO Tendermint est capable de décomposer la conception blockchain en offrant une API très simple entre le processus de candidature et processus de consensus.

Cosmos Architecture

Cosmos est un réseau de blockchain parallèles indépendants qui sont chacun alimenté par des algorithmes de consensus classiques BFT comme Menthe tendre 1. La première blockchain de ce réseau sera le Cosmos Hub. Le Cosmos Hub se connecte à de nombreux autres blockchain (ou zones) via un nouveau protocole de communication inter-blockchain. Le hub Cosmos suit de nombreux types token et conserve une trace du total nombre de token dans chaque zone connectée. Les jetons peuvent être transféré d’une zone à une autre de manière sécurisée et rapide sans avoir besoin d'un échange liquide entre zones, car tout les transferts de pièces inter-zones passent par le Hub Cosmos. Cette architecture résout de nombreux problèmes que l'espace blockchain auxquels sont confrontés aujourd'hui, tels que l'interopérabilité des applications, l'évolutivité et évolutivité transparente. Par exemple, les zones dérivées de Bitcoind, Go-Ethereum, CryptoNote, ZCash ou tout autre système blockchain peut être branché sur le hub Cosmos. Ces zones permettent à Cosmos de évoluer à l’infini pour répondre à la demande mondiale de transactions. Les zones sont également un excellent outil pour un échange distribué, qui sera pris en charge en tant que eh bien. Cosmos n'est pas qu'un seul grand livre distribué, et le Cosmos Hub n’est pas un jardin clos ni le centre de son univers. Nous sommes concevoir un protocole pour un réseau ouvert de registres distribués qui peut servir de nouvelle base aux futurs systèmes financiers, basé sur les principes de la cryptographie, d'une économie saine et du consensus théorie, transparence et responsabilité. Le Cosmos Hub est le premier blockchain public du Cosmos Réseau, alimenté par l'algorithme de consensus BFT de Tendermint. Le Le projet open source Tendermint est né en 2014 pour répondre au la vitesse, l'évolutivité et les problèmes environnementaux de l'algorithme de consensus de preuve de travail de Bitcoin. En utilisant et en améliorant des solutions éprouvées

BFT algorithmes développés au MIT en 1988 [20], le Tendermint L'équipe a été la première à démontrer conceptuellement un proof-of-stake crypto-monnaie qui résout le problème de l'enjeu nul subi par les crypto-monnaies proof-of-stake de première génération telles que comme NXT et BitShares1.0. Aujourd'hui, pratiquement tous les portefeuilles mobiles Bitcoin utilisent des serveurs de confiance pour fournissez-leur la vérification des transactions. En effet, la preuve de travail nécessite d'attendre de nombreuses confirmations avant qu'un la transaction peut être considérée comme irréversiblement engagée. Des attaques à double dépense ont déjà été démontrées sur des services comme CoinBase. Contrairement aux autres systèmes de consensus blockchain, Tendermint propose vérification instantanée et prouvée des paiements des clients mobiles. Puisque le Tendermint est conçu pour ne jamais bifurquer du tout, les appareils mobiles les portefeuilles peuvent recevoir une confirmation de transaction instantanée, ce qui rend les paiements sans confiance et pratiques sont une réalité sur les smartphones. Ceci a des implications importantes pour les applications de l'Internet des objets, car eh bien. Les validateurs de Cosmos ont un rôle similaire à celui des mineurs de Bitcoin, mais utilisez plutôt des signatures cryptographiques pour voter. Les validateurs sont des machines sécurisées et dédiées qui sont responsables de la validation blocs. Les non-validator peuvent déléguer leurs staking token (appelés "atomes") à n'importe quel validator pour gagner une partie des frais forfaitaires et des atomes récompenses, mais ils encourent le risque d'être punis (coupés) si le le délégué validator est piraté ou viole le protocole. Le éprouvé les garanties de sécurité du consensus Tendermint BFT et les garanties dépôt des parties prenantes – validators et délégants – fournir sécurité prouvable et quantifiable pour les nœuds et les clients légers. Les grands livres publics distribués devraient avoir une constitution et un système de gouvernance. Bitcoin s'appuie sur la Fondation Bitcoin etl'exploitation minière pour coordonner les mises à niveau, mais c'est un processus lent. Ethereum s'est divisé en ETH et ETC après avoir difficilement résolu Le DAO hack, en grande partie parce qu'il n'y avait pas de contrat social préalable ni aucun mécanisme pour prendre de telles décisions. Les validateurs et les délégués du hub Cosmos peuvent voter sur propositions qui peuvent modifier les paramètres prédéfinis du système automatiquement (comme la limite de gaz du bloc), coordonner les mises à niveau, comme ainsi que voter sur les amendements à la constitution lisible par l'homme qui régissent les politiques du Hub Cosmos. La Constitution permet une cohésion entre les parties prenantes sur des questions telles que le vol et les bugs (tels que l'incident TheDAO), permettant une intervention plus rapide et résolution plus propre. Chaque zone peut également avoir sa propre constitution et sa propre gouvernance mécanisme également. Par exemple, le hub Cosmos pourrait avoir un constitution qui impose l'immuabilité au Hub (pas de rollbacks, sauf pour les bogues de l'implémentation du nœud Hub Cosmos), tandis que chaque zone peut définir ses propres politiques concernant les restaurations. En permettant l'interopérabilité entre les différentes zones politiques, le Le réseau Cosmos offre à ses utilisateurs une liberté et un potentiel ultimes pour expérimentation sans autorisation. Nous décrivons ici un nouveau modèle de décentralisation et d'évolutivité. Cosmos est un réseau de nombreux blockchain alimentés par Menthe tendre. Alors que les propositions existantes visent à créer un « blockchain » avec l'ordre global total des transactions, Cosmos permet à plusieurs blockchain de s'exécuter simultanément les uns avec les autres tout en conservant l'interopérabilité. A la base, le Hub Cosmos gère de nombreux blockchains appelés « zones » (parfois appelés « fragments », en référence à la technique de mise à l’échelle de la base de données connue sous le nom de « sharding »).

Un flux constant de validations de blocs récentes provenant de zones publiées sur le Hub permet au Hub de suivre l'état de chaque zone. De même, chaque zone suit l'état du Hub (mais les zones ne se suivent pas, sauf indirectement à travers le Moyeu). Des paquets d'informations sont ensuite communiqués à partir d'un zone à une autre en affichant des preuves Merkle comme preuve que le les informations ont été envoyées et reçues. Ce mécanisme est appelé communication inter-blockchain, ou IBC pour faire court. N'importe laquelle des zones peut elle-même être des hubs pour former un graphe acyclique, mais par souci de clarté, nous décrirons uniquement le simple conyguration où il n'y a qu'un seul hub et de nombreux non-hub zones. Le Cosmos Hub est un blockchain qui héberge un multi-actifs grand livre distribué, où les token peuvent être détenus par des utilisateurs individuels ou par zones elles-mêmes. Ces token peuvent être déplacés d'une zone à un autre dans un paquet spécial IBC appelé « paquet de pièces ». Le moyeu est chargé de préserver l’invariance globale du total montant de chaque token dans les zones. IBC paquet de pièces les transactions doivent être validées par l'expéditeur, le hub et le destinataire blockchains.Étant donné que le hub Cosmos agit comme le grand livre central pour l'ensemble système, la sécurité du Hub est d’une importance primordiale. Tandis que chaque zone peut être un Tendermint blockchain sécurisé par seulement 4 (ou même moins si le consensus BFT n'est pas nécessaire), le Hub doit être sécurisé par un ensemble globalement décentralisé de validator qui peut résister aux scénarios d'attaque les plus sévères, tels qu'un partition du réseau continental ou attaque parrainée par un État-nation. Une zone Cosmos est une zone blockchain indépendante qui échange IBC messages avec le Hub. Du point de vue du Hub, une zone est un compte multi-signatures à adhésion dynamique multi-actifs qui peut envoyer et recevoir des token en utilisant des paquets IBC. Comme un compte de crypto-monnaie, une zone ne peut pas transférer plus de tokens que il l'a fait, mais peut recevoir des token d'autres personnes qui les possèdent. Une zone peut être désigné comme une « source » d'un ou plusieurs types token, lui accordant le pouvoir d'augmenter cet approvisionnement token. Les atomes du Hub Cosmos peuvent être jalonnés par les validator d'une zone connecté au Hub. Tandis que les attaques à double dépense sur ces zones entraînerait la réduction des atomes avec la responsabilité fork de Tendermint, une zone où >⅔ du pouvoir de vote sont Les Byzantins peuvent commettre un état invalide. Le hub Cosmos ne vérifier ou exécuter des transactions validées sur d'autres zones, il est donc la responsabilité des utilisateurs d’envoyer des token aux zones en lesquelles ils ont confiance. À l'avenir, le système de gouvernance du Hub Cosmos pourrait réussir des propositions d'amélioration qui tiennent compte des défaillances de zone. Pour Par exemple, les transferts sortants token depuis certaines (ou toutes) zones peuvent être étranglé pour permettre la coupure de circuit d'urgence des zones (un arrêt temporaire des transferts token) lorsqu'une attaque est détectée. Voyons maintenant comment le Hub et les zones communiquent entre eux. autre. Par exemple, s'il y a trois blockchain, "Zone1", "Zone2",

et « Hub », et nous souhaitons que « Zone1 » produise un paquet destiné pour « Zone2 » en passant par « Hub ». Pour déplacer un paquet d'un blockchain à un autre, un BAT est affiché sur la chaîne de réception. La preuve indique que la chaîne d'envoi a publié un paquet pour le destination présumée. Pour que la chaîne de réception puisse vérifier cette preuve, il doit être capable de suivre les en-têtes de bloc de l’expéditeur. Ceci Le mécanisme est similaire à celui utilisé par les sidechains, ce qui nécessite deux chaînes en interaction pour prendre conscience l'une de l'autre via un flux bidirectionnel de datagrammes de preuve d'existence (transactions). Le protocole IBC peut naturellement être défini à l'aide de deux types de transactions : une transaction  IBCBlockCommitTx , qui permet un blockchain pour prouver à tout observateur de son bloc le plus récent-hash, et une transaction  IBCPacketTx , qui permet à un blockchain de prouver à tout observateur que le paquet donné a bien été publié par l’application de l’expéditeur, via une preuve Merkle au récent bloc-hash. En divisant la mécanique IBC en deux transactions distinctes, nous permettre au mécanisme de marché des frais natifs de la chaîne de réception de déterminer quels paquets sont validés (c'est-à-dire reconnus), tandis que permettant une liberté totale sur la chaîne d'envoi quant à la manière dont de nombreux paquets sortants sont autorisés. Dans l'exemple ci-dessus, afin de mettre à jour le bloc-hash de "Zone1" sur « Hub » (ou de « Hub » sur « Zone2 »), un IBCBlockCommitTxla transaction doit être publiée sur « Hub » avec le bloc-hash de « Zone1 » (ou sur « Zone2 » avec le bloc-hash de « Hub »). Voir IBCBlockCommitTx et IBCPacketTx pour plus d'informations. sur les deux types de transactions IBC. De la même manière que Bitcoin est plus sécurisé en étant distribué, grand livre répliqué en masse, nous pouvons rendre les échanges moins vulnérables aux hacks externes et internes en l'exécutant sur le blockchain. Nous appelez cela un échange distribué. Ce que la communauté des cryptomonnaies appelle un système décentralisé Aujourd’hui, les échanges sont basés sur ce que l’on appelle des transactions « atomiques crosschain » (AXC). Avec une transaction AXC, deux utilisateurs sur deux chaînes différentes peuvent effectuer deux transactions de transfert qui sont engagés ensemble sur les deux registres, ou aucun (c'est-à-dire atomiquement). Par exemple, deux utilisateurs peuvent échanger des bitcoins contre de l'éther (ou deux token sur deux grands livres différents) en utilisant les transactions AXC, même si Bitcoin et Ethereum ne sont pas connectés l'un à l'autre autre. L'avantage d'exécuter un échange sur les transactions AXC est qu'aucun utilisateur n'a besoin de se faire confiance ni de se faire confiance service. L'inconvénient est que les deux parties doivent être en ligne pour le commerce ait lieu. Un autre type d'échange décentralisé est un échange répliqué en masse. échange distribué qui fonctionne tout seul blockchain. Utilisateurs sur ce type d'échange peut soumettre un ordre limité et transformer son ordinateur éteint, et la transaction peut s'exécuter sans que l'utilisateur soit en ligne. Le blockchain correspond et termine la transaction au nom du commerçant.

Applications

Un échange centralisé peut créer un carnet de commandes important et limité commandes et ainsi attirer plus de commerçants. La liquidité engendre plus liquidité dans le monde des changes, il existe donc un réseau solide effet (ou au moins un effet gagnant-prenant le plus) dans l'échange entreprise. Le leader actuel des échanges de crypto-monnaie aujourd'hui se trouve Poloniex avec un volume sur 24 heures de 20 millions de dollars, et en deuxième position se trouve Bitynex avec un volume sur 24 heures de 5 millions de dollars. Étant donné un réseau aussi solide effets, il est peu probable que les échanges décentralisés basés sur AXC gagner du volume sur les échanges centralisés. Pour une décentralisation bourse pour rivaliser avec une bourse centralisée, il lui faudrait pour prendre en charge des carnets de commandes importants avec des ordres limités. Seulement un distribué un échange sur un blockchain peut fournir cela. Tendermint offre des avantages supplémentaires d'une transaction plus rapide s'engage. En privilégiant la qualité rapide sans sacrifier cohérence, les zones de Cosmos peuvent ynaliser les transactions rapidement – par exemple les transactions d'ordres d'échange ainsi que les transferts IBC token vers et d'autres zones. Compte tenu de l’état actuel des échanges de crypto-monnaie, un grand l'application pour Cosmos est l'échange distribué (alias le Cosmos DEX). La capacité de débit des transactions ainsi que la latence de validation peut être comparable à celle des systèmes centralisés échanges. Les traders peuvent soumettre des ordres limités qui peuvent être exécutés sans que les deux parties n'aient besoin d'être en ligne. Et avec Tendermint, le hub Cosmos et IBC, les traders peuvent transférer des fonds vers et depuis l'échange vers et depuis d'autres zones avec rapidité. Une zone privilégiée peut agir comme source d'un token ponté de une autre crypto-monnaie. Un pont est semblable à la relation entre un hub et une zone Cosmos ; les deux doivent suivre le rythme derniers blocs de l'autre afin de vérifier les preuves que les token ont déplacé de l'un à l'autre. Une "zone-pont" sur le Cosmos le réseau suit le Hub ainsi que les autres

crypto-monnaie. L'indirection à travers la zone du pont permet la logique du Hub pour rester simple et agnostique par rapport aux autres Stratégies consensuelles de blockchain telles que proof-of-work de Bitcoin exploitation minière. Chaque zone de pont validator exécuterait un système alimenté par Tendermint blockchain avec une application de pont spéciale ABCI, mais aussi un nœud complet de l’« origine » blockchain. Lorsque de nouveaux blocs sont extraits à l'origine, la zone de pont validators parviendront à un accord sur les blocs engagés en signant et partageant leur vision locale respective du blockchain d’origine pointe. Lorsqu'une zone-pont reçoit un paiement à l'origine (et il a été convenu que des confirmations suffisantes avaient été vues dans le cas d'une chaîne PoW telle que Ethereum ou Bitcoin), un correspondant un compte est créé sur la zone pont avec ce solde. Dans le cas de Ethereum, la zone pont peut partager la même validator-défini comme hub Cosmos. Du côté Ethereum (le origine), un contrat-relais permettrait aux détenteurs d'éther d'envoyer de l'éther à la zone-pont en l'envoyant au contrat-pont le Ethereum. Une fois que l'éther est reçu par le contrat-pont, le l'éther ne peut pas être retiré à moins qu'un paquet IBC approprié ne soit reçu par le contrat-pont de la zone-pont. Le Le contrat de pont suit l'ensemble validator de la zone de pont, qui peut être identique à l’ensemble validator du Hub Cosmos. Dans le cas de Bitcoin, le concept est similaire sauf qu'au lieu de un seul contrat-relais, chaque UTXO serait contrôlé par un seuil multisignature publication P2SH. En raison des limites de le système P2SH, les signataires ne peuvent pas être identiques aux Cosmos Hub validator-set.L'éther sur la zone pont («bridged-ether») peut être transféré vers et depuis le Hub, puis être détruit avec une transaction qui l'envoie à une adresse de retrait particulière le Ethereum. Un IBC paquet prouvant que la transaction a eu lieu sur la zone pont peut être posté sur le contrat-relais Ethereum pour permettre à l'éther à retirer. Dans le cas de Bitcoin, le système de script restreint permet Il est difficile de reproduire le mécanisme de transfert de pièces IBC. Chaque UTXO a son propre pubscript indépendant, donc chaque UTXO doit être migré vers un nouveau UTXO lorsqu'il y a un changement dans l'ensemble des Bitcoin signataires du dépôt fiduciaire. Une solution consiste à compresser et décompressez l'ensemble UTXO si nécessaire pour conserver le nombre total des UTXOs en panne. Le risque d'un tel contrat de transition est un ensemble validator voyou. ≥⅓ Le pouvoir de vote byzantin pourrait provoquer un fork, retirant l'éther du contrat-pont sur Ethereum tout en gardant le bridgedether sur la zone-pont. Pire encore, >⅔ du pouvoir de vote byzantin peut voler de l'éther à ceux qui l'ont envoyé au contrat-pont en s'écartant de la logique de pontage originale de la zone-pont. Il est possible de résoudre ces problèmes en concevant le pont pour qu'il soit totalement responsable. Par exemple, tous les paquets IBC, provenant du hub et l'origine, pourrait nécessiter une reconnaissance par la zone de pont dans de telle sorte que toutes les transitions d'état de la zone de pont puissent être efficacement contesté et vérifié soit par le hub, soit par l'origine contrat-relais. Le Hub et l'origine devraient permettre aux zones de pont validator de déposer des garanties, et token les transferts hors de la zone de pont. le contrat-relais devrait être retardé (et le détachement des garanties période suffisamment longue) pour permettre d'éventuelles contestations auditeurs indépendants. Nous quittons la conception de la spécification et mise en œuvre de ce système ouvert comme un avenir Cosmos

proposition d'amélioration, à adopter par le Hub Cosmos système de gouvernance. La résolution du problème de mise à l’échelle est un problème ouvert pour Ethereum. Actuellement, les nœuds Ethereum traitent chaque transaction et stocker également tous les états. lien. Puisque Tendermint peut valider des blocs beaucoup plus rapidement que ceux de Ethereum Zones proof-of-work, EVM alimentées par le consensus Tendermint et fonctionnant sur de l'éther ponté peut fournir des performances plus élevées à Ethereum blockchains. De plus, bien que le hub Cosmos et La mécanique des paquets IBC ne permet pas une logique de contrat arbitraire exécution en soi, il peut être utilisé pour coordonner les mouvements token entre les contrats Ethereum fonctionnant sur des zones différentes, fournissant une base pour une mise à l'échelle token centrée sur Ethereum via partage. Les zones Cosmos exécutent une logique d'application arbitraire, définie à le début de la vie de la zone et peut éventuellement être mis à jour au fil du temps par la gouvernance. Une telle zexibilité permet aux zones Cosmos de agir comme des ponts vers d'autres crypto-monnaies telles que Ethereum ou Bitcoin, et il autorise également les dérivés de ces blockchain, en utilisant la même base de code mais avec un ensemble validator différent et distribution initiale. Cela permet à de nombreuses crypto-monnaies existantes frameworks, tels que ceux de Ethereum, Zerocash, Bitcoin, CryptoNote et ainsi de suite, à utiliser avec Tendermint Core, qui est un moteur de consensus plus performant, sur un réseau commun, ouvrant une formidable opportunité d’interopérabilité à travers plates-formes. De plus, en tant que blockchain multi-actifs, un seul La transaction peut contenir plusieurs entrées et sorties, où chacune l'entrée peut être n'importe quel type token, permettant à Cosmos de servir directement de une plateforme d'échange décentralisé, bien que les commandes soient assuméesà égaler via d'autres plateformes. Alternativement, une zone peut servir en tant qu'échange distribué tolérant aux pannes (avec carnets de commandes), qui peut être une amélioration stricte par rapport au système centralisé existant échanges de crypto-monnaie qui ont tendance à être piratés au fil du temps. Les zones peuvent également servir de versions d'entreprise soutenues par blockchain et les systèmes gouvernementaux, où les éléments d'un service particulier qui sont traditionnellement gérés par une organisation ou un groupe d’organisations sont plutôt exécutés en tant qu'application ABCI sur une certaine zone, ce qui lui permet d'hériter de la sécurité et de l'interopérabilité du public Cosmos réseau sans sacrifier le contrôle sur le sous-jacent service. Ainsi, Cosmos peut offrir le meilleur des deux mondes pour les organisations qui cherchent à utiliser la technologie blockchain mais qui sont se méfier de céder complètement le contrôle à un tiers distribué fête. Certains affirment qu'un problème majeur lié à la recherche de cohérence les algorithmes de consensus comme Tendermint sont que n'importe quel réseau partition qui fait qu'il n'y a pas de partition unique avec >⅔ le pouvoir de vote (par exemple ≥⅓ du magazine) mettra complètement fin au consensus. L'architecture Cosmos peut aider à atténuer ce problème en utilisant une plaque tournante mondiale avec des zones régionales autonomes, où le pouvoir de vote pour chaque zone sont répartis selon une répartition géographique commune région. Par exemple, un paradigme commun peut être celui d'un individu villes, ou régions, d'exploiter leurs propres zones tout en partageant un pôle commun (par exemple le Hub Cosmos), permettant à l'activité municipale de persister dans le cas où le hub s'arrête en raison d'un réseau temporaire partition. Notons que cela permet de réelles conséquences géologiques, politiques et caractéristiques topologiques de réseau à prendre en compte dans la conception de systèmes robustes systèmes fédérés tolérants aux pannes.

NameCoin a été l'un des premiers blockchain à tenter de résoudre le problème. problème de résolution de nom en adaptant le Bitcoin blockchain. Malheureusement, cette approche a posé plusieurs problèmes. Avec Namecoin, on peut vérifier que, par exemple, @satoshi était enregistré avec une clé publique particulière à un moment donné dans le passé, mais nous ne saurions pas si la clé publique a été mis à jour récemment sauf si nous téléchargeons tous les blocs depuis le dernier mise à jour de ce nom. Cela est dû à la limitation de Bitcoin UTXO modèle de Merkle-isation des transactions, où seul le les transactions (mais pas l'état d'application mutable) sont Merkle-isées dans le bloc-hash. Cela nous permet de prouver l'existence, mais pas la non-existence de mises à jour ultérieures d'un nom. Ainsi, nous ne pouvons pas savoir pour certain de la valeur la plus récente d'un nom sans faire confiance à un nœud, ou encourir des coûts importants en bande passante en téléchargeant le tout blockchain. Même si un arbre de recherche Merkle était implémenté dans NameCoin, sa dépendance à proof-of-work rend la vérification client légère problématique. Les clients légers doivent télécharger une copie complète du en-têtes pour tous les blocs de l'ensemble du blockchain (ou au moins de tous les en-têtes depuis la dernière mise à jour d'un nom). Cela signifie que le les besoins en bande passante évoluent de manière linéaire avec le temps [21]. De plus, les changements de nom sur un proof-of-work blockchain nécessite d'attendre des blocs de confirmation proof-of-work supplémentaires, ce qui peut prendre jusqu'à une heure le Bitcoin. Avec Tendermint, tout ce dont nous avons besoin est le bloc le plus récent -hash signé par un quorum de validators (par droit de vote) et un Merkle preuve à la valeur actuelle associée au nom. Cela fait possible d'avoir un client léger succinct, rapide et sécurisé vérification des valeurs de nom. Dans Cosmos, nous pouvons reprendre ce concept et l'étendre davantage. Chacun La zone d'enregistrement de nom dans Cosmos peut avoir un nom de domaine de premier niveau (TLD) associé tel que « .com » ou « .org », et chaque nom-

la zone d'enregistrement peut avoir sa propre gouvernance et son propre enregistrement règles.

Gouvernance et économie

Bien que le Cosmos Hub soit un grand livre distribué multi-actifs, il existe un token natif spécial appelé l'atome. Les atomes sont les seuls staking token du hub Cosmos. Les atomes sont une licence pour le détenteur de voter, valider ou déléguer à d'autres validator. Comme celui de Ethereum éther, les atomes peuvent également être utilisés pour payer les frais de transaction pour atténuer le spam. Atomes inzationnaires supplémentaires et transaction de bloc les honoraires sont récompensés aux validator et aux délégataires qui délèguent à validators. La transaction BurnAtomTx  peut être utilisée pour récupérer n'importe quel montant proportionnel de tokens provenant du pool de réserve. La distribution initiale des atomes token et validator sur Genesis ira aux donateurs de la collecte de fonds Cosmos (75 %), principaux donateurs (5 %), Cosmos Network Foundation (10 %) et ALL IN BITS, Inc. (10%). À partir de la genèse, 1/3 de la quantité totale d'atomes sera être récompensé chaque année par les validator et les délégués cautionnés. Consultez le plan Cosmos pour plus de détails. Contrairement à Bitcoin ou à d'autres proof-of-work blockchain, un Tendermint blockchain devient plus lent avec plus de validator en raison de l'augmentation complexité des communications. Heureusement, nous pouvons soutenir suffisamment validators pour créer un blockchain robuste distribué à l'échelle mondiale avec des temps de confirmation des transactions très rapides et, comme bande passante,

stockage et la capacité de calcul parallèle augmente, nous pourrons pour prendre en charge davantage de validator à l'avenir. Le jour de la genèse, le nombre maximum de validator sera fixé à 100, et ce nombre augmentera au rythme de 13% pendant 10 ans, et s'établir à 300 validators. Les détenteurs d'atomes qui ne le sont pas déjà peuvent devenir validator en signer et soumettre une transaction BondTx . Le montant de les atomes fournis en garantie doivent être différents de zéro. N'importe qui peut devenir un validator à tout moment, sauf lorsque la taille du courant L'ensemble validator est supérieur au nombre maximum de validator. autorisé. Dans ce cas, la transaction n'est valable que si le montant de Le nombre d’atomes est supérieur à la quantité d’atomes effectifs détenus par le le plus petit validator, où les atomes efficaces incluent les atomes délégués. Lorsqu'un nouveau validator remplace un validator existant de cette manière, le validator existant devient inactif et tous les atomes et les atomes délégués entrent dans l’état de déliaison. Une pénalité doit être imposée aux validator pour tout déviation intentionnelle ou non des règles sanctionnées protocole. Certaines preuves sont immédiatement recevables, comme une double signe à la même hauteur et rond, ou une violation de Année 0 : 100  Année 1 : 113  Année 2 : 127  Année 3 : 144  Année 4 : 163  Année 5 : 184  Année 6 : 208  Année 7 : 235  Année 8 : 265  Année 9 : 300  Année 10 : 300  ...

« empêcher le verrouillage » (une règle du protocole de consensus Tendermint). Une telle preuve entraînera la perte de la réputation du validator. et ses atomes liés ainsi que sa part proportionnelle de tokens dans le pool de réserve – collectivement appelé sa « mise » – sera réduit. Parfois, les validator ne seront pas disponibles, soit en raison de conditions régionales perturbations du réseau, panne de courant ou autres raisons. Si, à tout moment point dans les blocs  ValidatorTimeoutWindow passés, un validator le vote de validation n'est pas inclus dans le blockchain plus de  ValidatorTimeoutMaxAbsent fois, ce validator deviendra inactif et perdez  ValidatorTimeoutPenalty (DEFAULT 1 %) de son enjeu. Certains comportements « malveillants » ne produisent pas d’effets visiblement perceptibles. preuve sur le blockchain. Dans ces cas, les validator peuvent coordonner hors bande pour forcer l'expiration du délai d'attente de ces éléments malveillants validators, s'il existe un consensus à la grande majorité. Dans les situations où le Hub Cosmos s'arrête en raison d'une coalition ≥⅓ de le pouvoir de vote disparaît, ou dans des situations où une coalition ≥⅓ des pouvoirs de vote censurent les preuves de comportement malveillant de la part de en entrant dans le blockchain, le hub doit récupérer avec un hard-fork proposition de réorganisation. (Lien vers « Forks et attaques de censure »). Les hubs Cosmos validator peuvent accepter n'importe quel type ou combinaison de token de types comme frais de traitement d’une transaction. Chaque validator peut fixer subjectivement le taux de change qu'il souhaite et choisir quelles que soient les transactions souhaitées, à condition que le  BlockGasLimit  soit pas dépassé. Les frais perçus, déduction faite des éventuelles taxes précisées ci-dessous, sont redistribués aux parties prenantes cautionnées au prorata de leurs atomes liés, chaque  ValidatorPayoutPeriod  (DEFAULT 1 heure).Parmi les frais de transaction collectés,  ReserveTax  (2 % PAR DÉFAUT) sera allez vers la réserve pour augmenter la réserve et augmenter la sécurité et la valeur du réseau Cosmos. Ces les fonds peuvent également être distribués conformément aux décisions faite par le système de gouvernance. Détenteurs d'atomes qui délèguent leur pouvoir de vote à d'autres validator verser une commission au délégué validator. La commission peut être défini par chaque validator. La sécurité du hub Cosmos est fonction de la sécurité du sous-jacents aux validator et au choix de la délégation par les délégants. Afin d'encourager la découverte et la déclaration précoce des espèces trouvées vulnérabilités, le Cosmos Hub encourage les pirates à publier exploits réussis via une transaction  ReportHackTx qui dit : "Ceci validator a été piraté. Veuillez envoyer la prime à cette adresse ». Sur un tel exploit, le validator et les délégants deviendront inactifs,  HackPunishmentRatio  (par défaut 5 %) des atomes de chacun obtiendront réduit et  HackRewardRatio  (par défaut 5 %) des atomes de chacun sera récompensé à l’adresse de prime du pirate informatique. Le validator doit récupérer les atomes restants en utilisant leur clé de sauvegarde. Afin d'éviter que cette fonctionnalité ne soit utilisée de manière abusive pour transférer atomes non investis, la proportion d'atomes investis et non investis de Les validator et les délégants avant et après le  ReportHackTx  resteront les mêmes, et la prime des hackers inclura certains atomes non investis, le cas échéant. Le hub Cosmos est exploité par une organisation distribuée qui nécessite un mécanisme de gouvernance bien défini afin de coordonner divers changements au blockchain, comme la variable

paramètres du système, ainsi que les mises à niveau logicielles et amendements constitutionnels. Tous les validator sont responsables du vote sur toutes les propositions. A défaut de voter sur une proposition en temps opportun entraînera le validator étant automatiquement désactivé pendant une période de temps appelée  AbsenteeismPenaltyPeriod  (PAR DÉFAUT 1 semaine). Les délégués héritent automatiquement du vote du délégué validator. Ce vote peut être annulé manuellement. Atomes non liés n'obtenez aucun vote. Chaque proposition nécessite un dépôt de MinimumProposalDeposit  tokens, qui peuvent être une combinaison d'un ou plusieurs tokens y compris les atomes. Pour chaque proposition, les électeurs peuvent voter pour prendre le dépôt. Si plus de la moitié des électeurs choisissent de voter dépôt (par exemple parce que la proposition était du spam), le dépôt va à le pool de réserve, à l’exception des atomes brûlés. Pour chaque proposition, les électeurs peuvent voter avec les options suivantes : Ouais OuiAvecForce Non NonAvecForce S'abstenir Une stricte majorité de votes Oui ou OuiAvecForce (ou Non ou Votes NayWithForce) est requis pour que la proposition soit décidée comme réussi (ou décidé comme échec), mais 1/3+ peut opposer son veto à la majorité décision en votant « avec force ». Lorsqu'on oppose son veto à une majorité stricte, tout le monde est puni en perdant VetoPenaltyFeeBlocks  (PAR DÉFAUT 1 jour de blocs) de frais (sauf taxes qui ne sera pas affecté), et le parti qui a opposé son veto à la majorité

la décision sera en outre punie par la perte de VetoPenaltyAtoms  (PAR DÉFAUT 0,1%) de ses atomes. N'importe lequel des paramètres définis ici peut être modifié avec le transmission d'une ParameterChangeProposal . Les atomes peuvent être inzés et les fonds du pool de réserve dépensés avec le adoption d'une  BountyProposal . Toutes les autres propositions, comme une proposition de mise à niveau du protocole, sera coordonné via la  TextProposal générique. Voir le Plan. Il y a eu de nombreuses innovations dans le consensus blockchain et évolutivité au cours des deux dernières années. Cette section fournit un bref enquête sur un certain nombre de sujets importants. Le consensus en présence de participants malveillants est un problème datant du début des années 1980, lorsque Leslie Lamport a inventé le expression « faute byzantine » pour faire référence à un comportement de processus arbitraire qui s'écarte du comportement prévu, contrairement à un « défaut de crash », dans lequel un processus plante tout simplement. Des premières solutions ont été découvertes pour les réseaux synchrones où il existe une limite supérieure surlatence des messages, bien que l'utilisation pratique soit limitée à des environnements contrôlés tels que les contrôleurs d’avion et centres de données synchronisés via des horloges atomiques. Ce n'est que lorsque fin des années 90, la tolérance aux pannes byzantine pratique (PBFT) [11] était présenté comme un consensus efficace partiellement synchrone algorithme capable de tolérer jusqu'à ⅓ des processus se comportant arbitrairement. PBFT est devenu l'algorithme standard, engendrant de nombreuses variantes, dont la plus récente créée par IBM dans le cadre de leur contribution à Hyperledger. Le principal avantage du consensus Tendermint sur PBFT est que Tendermint a une structure sous-jacente améliorée et simplifiée, dont certains sont le résultat de l’adoption du paradigme blockchain. Les blocs Tendermint doivent être validés dans l'ordre, ce qui évite le complexité et surcharge de communication associées aux PBFT changements de vue. Dans Cosmos et dans de nombreuses crypto-monnaies, il n'y a pas il faut autoriser le bloc N+i où i >= 1 à valider, lorsque le bloc N lui-même ne s’est pas encore engagé. Si la bande passante est la raison pour laquelle le bloc N ne s'est pas engagé dans une zone Cosmos, alors cela ne sert à rien d'utiliser votes de partage de bande passante pour les blocs N+i. Si une partition réseau ou ofzine nodes est la raison pour laquelle le bloc N n'a pas été validé, alors N+je ne m’engagerai pas de toute façon. De plus, le regroupement des transactions en blocs permet Merkle-hashing régulier de l'état de l'application, plutôt que des résumés périodiques comme avec le schéma de points de contrôle de PBFT. Cela permet pour des validations de transactions prouvables plus rapides pour les clients légers et plus rapides communication inter-blockchain. Tendermint Core comprend également de nombreuses optimisations et fonctionnalités qui vont au-delà de ce qui est spécifié dans PBFT. Par exemple, les blocs proposés par validators sont découpés en parties, Merkle-isées, et bavardé d'une manière qui améliore la diffusion performances (voir LibSwift [19] pour l'inspiration). Aussi, menthe tendre Core ne fait aucune hypothèse sur le point à point

connectivité et fonctionne aussi longtemps que le réseau P2P est faiblement connecté. Bien que ce ne soit pas la première année à déployer proof-of-stake (PoS), BitShares1.0 [12] contribué considérablement à la recherche et à l’adoption du PoS blockchain, en particulier ceux dits PoS « délégués ». Dans BitShares, les actionnaires élisent des "témoins", chargés de passer commande et commettre des transactions, et des « délégués », chargés de coordonner les mises à jour logicielles et les modifications de paramètres. BitShares2.0 vise à atteindre des performances élevées (100 000 tx/s, 1 s latence) dans des conditions idéales, chaque bloc étant signé par un seul signataire et la qualité de la transaction prend un peu plus de temps que le intervalle de bloc. Une spécification canonique est encore en développement. Les parties prenantes peuvent supprimer ou remplacer les témoins qui se comportent mal lors d'une réunion. quotidiennement, mais il n'y a pas de garantie significative de témoins ou des délégataires à l'image de Tendermint PoS qui sont coupés le cas d’une attaque réussie à double dépense. S'appuyant sur une approche lancée par Ripple, Stellar [13] a créé un modèle d'accord byzantin fédéré dans lequel les processus la participation au consensus ne constitue pas un objectif fixe et global ensemble connu. Au lieu de cela, chaque nœud de processus gère un ou plusieurs des « tranches de quorum », chacune constituant un ensemble de processus de confiance. Un Le « quorum » dans Stellar est défini comme étant un ensemble de nœuds qui contiennent au au moins une tranche de quorum pour chaque nœud de l'ensemble, tel que un accord peut être trouvé. La sécurité du mécanisme Stellar repose sur l'hypothèse que l'intersection de deux quorums quelconques n'est pas vide, tandis que le la disponibilité d'un nœud nécessite au moins une de ses tranches de quorum pour se composent entièrement de nœuds corrects, créant un compromis entre en utilisant des tranches de quorum grandes ou petites qui peuvent être difficiles à équilibrer sans imposer d’hypothèses significatives sur la confiance. Finalement,les nœuds doivent d'une manière ou d'une autre choisir des tranches de quorum adéquates pour y parvenir. être suffisamment tolérant aux pannes (ou à tout « nœuds intacts », dont dont dépendent une grande partie des résultats de l'article), et le seul la stratégie fournie pour garantir qu'une telle conyguration est hiérarchique et similaire au Border Gateway Protocol (BGP), utilisé par les meilleurs FAI sur Internet pour établir des tables de routage globales, et par celui utilisé par les navigateurs pour gérer les certificats TLS ; tous deux notoires pour leur insécurité. Les critiques formulées dans l'article Stellar concernant les systèmes de preuve de participation basés sur Tendermint sont atténuées par la stratégie token décrite. ici, dans lequel un nouveau type de token appelé atome est émis qui représentent des réclamations sur des portions futures de frais et de récompenses. Le L'avantage de proof-of-stake basé sur Tendermint est donc son relatif simplicité, tout en offrant une sécurité suffisante et prouvable garanties. BitcoinNG est une amélioration proposée à Bitcoin qui permettrait pour les formes d'évolutivité verticale, telles que l'augmentation de la taille des blocs, sans les conséquences économiques négatives généralement associées avec un tel changement, comme l'impact disproportionné sur les petits mineurs. Cette amélioration est obtenue en séparant élection du leader à partir de la diffusion de la transaction : les dirigeants sont les premiers élu par proof-of-work en « micro-blocs », et pouvoir alors transactions de diffusion à valider jusqu'à un nouveau micro-bloc est trouvé. Cela réduit les besoins en bande passante nécessaires pour gagner la course PoW, permettant aux petits mineurs de concourir plus équitablement, et permettre que les transactions soient commises plus régulièrement par le dernier mineur à trouver un micro-bloc. Casper [16] est un algorithme de consensus proof-of-stake proposé pour Ethereum. Son principal mode de fonctionnement est le « consensus par pari ». Par laisser validators parier de manière itérative sur le bloc qui, selon eux, sera

s'engager dans le blockchain en fonction des autres paris qu'ils ont vu jusqu'à présent, la ynalité peut éventuellement être atteinte. lien. Il s’agit d’un domaine de recherche actif de l’équipe Casper. Le Le défi consiste à construire un mécanisme de pari qui puisse être s'est avérée être une stratégie évolutive stable. Le principal avantage de Casper, par rapport à Tendermint, pourrait offrir une « disponibilité » sur la cohérence » – le consensus n’exige pas un quorum >⅔ de pouvoir de vote – peut-être au détriment de la vitesse de validation ou complexité de mise en œuvre. Le protocole Interledger [14] n'est pas strictement une solution d'évolutivité. Il fournit une interopération ad hoc entre différents registres systèmes à travers un réseau de relations bilatérales faiblement couplées. À l'instar du Lightning Network, l'objectif d'ILP est de faciliter paiements, mais il se concentre spécifiquement sur les paiements à travers des types de grand livre et étend le mécanisme de transaction atomique à inclure non seulement des hash-serrures, mais également un quorum de notaires (appelé le Protocole de Transport Atomique). Ce dernier mécanisme pour l'application de l'atomicité dans les transactions inter-grands livres est similaire à Le mécanisme SPV client léger de Tendermint, donc une illustration du la distinction entre ILP et Cosmos/IBC est justifiée, et fournis ci-dessous. 1. Les notaires d'un connecteur en ILP ne prennent pas en charge l'adhésion changements et ne permettent pas une pondération zexible entre notaires. D'autre part, IBC est conçu spécifiquement pour blockchains, où validators peuvent avoir des poids différents, et où l'adhésion peut changer au cours de la blockchain. 2. Comme dans Lightning Network, le destinataire du paiement en ILP doit être en ligne pour renvoyer une confirmation à l'expéditeur. Dans untoken transfert via IBC, l'ensemble validator du récepteur blockchain est responsable de fournir la confirmation, et non le utilisateur récepteur. 3. La différence la plus frappante est que les connecteurs d'ILP ne sont pas responsable ou gardant l'autorité en matière de paiements, alors que dans Cosmos, les validator d'un hub sont l'autorité de l'état des transferts IBC token ainsi que l'autorité du montant de tokens détenu par chaque zone (mais pas le montant de tokens détenus par chaque compte dans une zone). C'est le innovation fondamentale qui permet une sécurité asymétrique transfert de token de zone en zone ; l'analogue des ILP Le connecteur dans Cosmos est un connecteur persistant et sécurisé au maximum. Grand livre blockchain, le hub Cosmos. 4. Les paiements inter-grand livre dans ILP doivent être garantis par un carnet d’ordres de change, car il n’y a pas de transfert asymétrique de pièces de monnaie d'un registre à un autre, seul le transfert de valeur ou équivalents du marché. Les sidechains [15] sont un mécanisme proposé pour faire évoluer le Bitcoin réseau via des blockchain alternatifs qui sont « rattachés dans les deux sens » à le Bitcoin blockchain. (L'ancrage bidirectionnel équivaut à pontage. Dans Cosmos, nous disons « bridging » pour distinguer le marketpegging). Les sidechains permettent aux bitcoins de passer efficacement du Bitcoin blockchain au sidechain et à l'arrière, et permettre expérimentation de nouvelles fonctionnalités sur la sidechain. Comme dans le Cosmos Hub, la sidechain et Bitcoin servent de clients légers de les uns les autres, en utilisant des preuves SPV pour déterminer quand les pièces doivent être transféré à la sidechain et inversement. Bien sûr, depuis Bitcoin utilise proof-of-work, les sidechains centrés autour de Bitcoin souffrent des nombreux problèmes et risques de proof-of-work en tant que mécanisme de consensus. De plus, c'est un Bitcoin-maximaliste solution qui ne prend pas en charge nativement une variété de token et

topologie de réseau inter-zones comme le fait Cosmos. Cela dit, le noyau le mécanisme de la cheville à double sens est en principe le même que celui employé par le réseau Cosmos. Ethereum recherche actuellement un certain nombre de stratégies différentes pour fragmenter l'état du Ethereum blockchain pour répondre besoins d’évolutivité. Ces efforts ont pour objectif de maintenir couche d'abstraction offerte par la machine virtuelle Ethereum actuelle à travers l’espace d’état partagé. De multiples efforts de recherche sont en cours à ce moment. [18][22] Cosmos et Ethereum 2.0 Mauve [22] ont des objectifs de conception différents. Cosmos concerne spécifiquement les token. Mauve est une question de mise à l'échelle calcul général. Cosmos n'est pas lié à EVM, donc même différentes machines virtuelles peuvent interopérer. Cosmos permet au créateur de la zone de déterminer qui valide la zone. N'importe qui peut créer une nouvelle zone dans Cosmos (sauf si la gouvernance en décide autrement). Le hub isole les défaillances de zone afin que les invariants globaux token soient préservé. Le réseau Lightning est un réseau de transfert proposé token fonctionnant à une couche au-dessus du Bitcoin blockchain (et d'autres blockchains), permettant une amélioration de plusieurs ordres de grandeur dans le débit des transactions en déplaçant la majorité des transactions en dehors du registre consensuel vers ce que l’on appelle les « canaux de paiement ».Ceci est rendu possible par les scripts de crypto-monnaie en chaîne, qui permettre aux parties de conclure des contrats étatiques bilatéraux dans lesquels l'état peut être mis à jour en partageant des signatures numériques et des contrats peut être clôturé en publiant ynally des preuves sur le blockchain, un mécanisme popularisé pour la première fois par les échanges atomiques inter-chaînes. Par ouvrir des canaux de paiement avec de nombreuses parties, participants au Lightning Network peut devenir des points focaux pour le routage des paiements de tiers, conduisant à un canal de paiement entièrement connecté réseau, au prix d’un capital immobilisé sur les canaux de paiement. Bien que le réseau Lightning puisse également s'étendre facilement sur plusieurs blockchain indépendants pour permettre le transfert de valeur via un marché des changes, il ne peut pas être utilisé pour transférer des token d'un blockchain à un autre. Le principal avantage du réseau Cosmos décrit ici est de permettre une telle token transferts. Cela dit, nous nous attendons à ce que les canaux de paiement et le Lightning Network sera largement adopté avec notre Mécanisme de transfert token, pour des raisons d'économie et de confidentialité. Le témoin séparé est un lien de proposition d'amélioration Bitcoin qui vise à augmenter le débit de transaction par bloc de 2X ou 3X, tout en accélérant simultanément la synchronisation des blocs pour les nouveaux nœuds. Le génie de cette solution réside dans la façon dont elle fonctionne au sein du limitations du protocole actuel de Bitcoin et permet un soft-fork mise à niveau (c'est-à-dire que les clients avec des versions plus anciennes du logiciel seront continuer à fonctionner après la mise à niveau). Tendermint, étant un nouveau protocole, n'a aucune restriction de conception, il a donc une mise à l'échelle différente priorités. Principalement, Tendermint utilise un algorithme round-robin BFT basé sur des signatures cryptographiques au lieu du minage, ce qui permet trivialement une mise à l'échelle horizontale à travers plusieurs parallèles blockchains, tandis que les validations de bloc régulières et plus fréquentes permettent mise à l'échelle verticale également.

Consensus et détails techniques

Un protocole de consensus bien conçu devrait fournir garanties en cas de dépassement de la capacité de tolérance et le consensus échoue. Ceci est particulièrement nécessaire dans le domaine économique systèmes, où le comportement byzantin peut avoir des conséquences financières substantielles récompense. La plus importante de ces garanties est une forme de responsabilité fork, où les processus qui ont conduit au consensus échouer (c'est-à-dire avoir amené les clients du protocole à accepter des valeurs différentes - un fourchette) peuvent être identifiés et sanctionnés selon les règles de la protocole ou, éventuellement, le système juridique. Lorsque le système juridique est peu fiables ou excessivement coûteux à invoquer, les validator peuvent être obligés de faire des dépôts de garantie pour pouvoir participer, et ceux les dépôts peuvent être révoqués ou réduits en cas de comportement malveillant détecté [10]. Notez que cela diffère de Bitcoin, où le forking est un phénomène régulier en raison de l'asynchronie du réseau et de la nature probabiliste du ynding collisions partielles hash. Puisque dans de nombreux cas, un fork malveillant est impossible à distinguer d'un fork en raison de l'asynchronie, Bitcoin ne peut pas mettre en œuvre de manière fiable la responsabilité fork, autre que la responsabilité implicite coût d’opportunité payé par les mineurs pour l’exploitation d’un bloc orphelin. Nous appelons les étapes de vote PreVote et PreCommit. Un vote peut être pour un bloc particulier ou pour Nil. Nous appelons une collection de >⅔ PreVotes pour un seul bloc dans le même tour, une Polka et une collection de >⅔ PreCommits pour un seul bloc au cours du même tour d’un Commit. Si >⅔ PreCommit pour Nil dans le même tour, ils passent au suivant rond. Notez qu’un déterminisme strict dans le protocole entraîne une faible hypothèse de synchronisation car les leaders défectueux doivent être détectés et

sauté. Ainsi, les validator attendent un certain temps, TimeoutPropose, avant de pré-voter Nil, et la valeur de TimeoutPropose augmente à chaque tour. Progression à travers le reste d'un tour est entièrement asynchrone, dans la mesure où la progression n'est que effectué une fois qu'un validator entend de >⅔ du réseau. En pratique, il faudrait un adversaire extrêmement puissant pour contrecarrer indéfiniment l'hypothèse de synchronisation faible (ce qui fait que le consensus ne parvient pas à jamais commettre un blocage), et cela peut être rendu encore plus difficile en utilisant des valeurs aléatoires de TimeoutPropose sur chaque validator. Un ensemble supplémentaire de contraintes, ou règles de verrouillage, garantit que le Le réseau finira par engager un seul bloc à chaque hauteur. N'importe lequel tentative malveillante de provoquer la validation de plusieurs blocs à une hauteur donnée peut être identifié. Tout d'abord, un PreCommit pour un bloc doit être accompagné d'une justification, sous la forme d'une Polka pour ce bloc. Si le validator a déjà PreCommit un bloc au tour R_1, nous disent qu'ils sont verrouillés sur ce bloc, et la Polka avait l'habitude de justifier le le nouveau PreCommit au tour R_2 doit arriver dans un tour R_polka où R_1 < R_polka <= R_2. Deuxièmement, les validator doivent proposer et/ou PréVote le bloc sur lequel ils sont verrouillés. Ensemble, ces conditions garantissent qu'un validator ne fait pas de PreCommit sans preuves suffisantes comme justification, et que validators qui ont PreCommit ne peut déjà pas contribuer aux preuves à PreCommit autre chose. Cela garantit à la fois la sécurité et la vivacité du algorithme de consensus. Les détails complets du protocole sont décrits ici. La nécessité de synchroniser tous les en-têtes de bloc est éliminée dans TendermintPoS car l'existence d'une chaîne alternative (un fork) signifie ≥⅓ de la mise sous caution peut être réduite. Bien sûr, puisque couper nécessite que quelqu'un partage la preuve d'un fork, les clients légers devraient stocker tout bloc-hash valide qu'il voit. De plus, les clients légerspourrait périodiquement rester synchronisé avec les modifications apportées à l'ensemble validator, dans afin d'éviter les attaques à longue portée (mais d'autres solutions sont possibles). Dans un esprit similaire à Ethereum, Tendermint permet aux applications de intégrer une racine Merkle globale hash dans chaque bloc, permettant facilement requêtes d'état vérifiables pour des éléments tels que les soldes des comptes, la valeur stocké dans un contrat, ou l’existence d’une transaction non dépensée sortie, en fonction de la nature de l’application. En supposant un ensemble de réseaux de diffusion suffisamment résilients et un ensemble validator statique, n'importe quelle fourchette du blockchain peut être détecté et les dépôts des validator incriminés réduits. Ceci l'innovation, suggérée pour la première fois par Vitalik Buterin début 2014, résout le problème sans enjeu des autres proof-of-stake crypto-monnaies (voir Travaux connexes). Cependant, puisque validator définit doit pouvoir modifier, sur une longue période de temps, l'original Les validator peuvent tous devenir déliés et seraient donc libres de créer une nouvelle chaîne à partir du bloc Genesis, sans aucun coût car ils n'ont plus de dépôts bloqués. Cette attaque a eu lieu connue sous le nom d'attaque à longue portée (LRA), par opposition à une attaque à courte portée. Attaque à distance, où les validator qui sont actuellement liés provoquent un fork et sont donc punissables (en supposant qu'un fork soit responsable BFT algorithme comme le consensus Tendermint). Les attaques à longue portée sont souvent considéré comme un coup critique porté à proof-of-stake. Heureusement, la LRA peut être atténuée comme suit. D'abord, pour un validator pour se désengager (récupérant ainsi leur dépôt de garantie et ne percevant plus de frais pour participer au consensus), le le dépôt doit être rendu intransférable pendant un certain temps connue sous le nom de « période de détachement », qui peut être de l’ordre de semaines ou mois. Deuxièmement, pour qu'un client léger soit sécurisé, la première année chaque fois qu'il se connecte au réseau, il doit vérifier un bloc récent-hash contre une source fiable, ou de préférence plusieurs sources. Ceci

Cette condition est parfois qualifiée de « subjectivité faible ». Enfin, pour rester sécurisé, il doit se synchroniser avec le dernier validator défini sur au moins aussi souvent que la durée de la période de détachement. Ceci garantit que le client léger est informé des modifications apportées au validator fixé avant qu'un validator voit son capital délié et donc plus en jeu, ce qui lui permettrait de tromper le client en effectuant une attaque à longue portée en créant de nouveaux blocs en commençant à un hauteur où il a été collé (en supposant qu'il contrôle suffisamment plusieurs des premières clés privées). Il convient de noter que vaincre la LRA de cette manière nécessite une refonte du système. le modèle de sécurité d'origine de proof-of-work. Dans PoW, c'est supposé qu'un client léger peut se synchroniser avec la hauteur actuelle à partir du bloc Genesis de confiance à tout moment simplement en traitant la preuve de travail dans chaque en-tête de bloc. Toutefois, pour vaincre la LRA, nous exiger qu'un client léger se connecte avec une certaine régularité pour suivre les modifications dans l'ensemble validator, et que la première fois qu'ils lorsqu'ils se connectent, ils doivent être particulièrement attentifs à s'authentifier ce qu'ils entendent du réseau par rapport à des sources fiables. De bien sûr, cette dernière exigence est similaire à celle de Bitcoin, où le protocole et le logiciel doivent également être obtenus auprès d'un source. La méthode ci-dessus pour prévenir l’ARL est bien adaptée aux validator et les nœuds complets d'un blockchain alimenté par Tendermint, car ceux-ci les nœuds sont censés rester connectés au réseau. Le La méthode convient également aux clients légers dont on peut s'attendre à synchronisez-vous fréquemment avec le réseau. Cependant, pour les clients légers qui ne sont pas censés avoir un accès fréquent à Internet ou au blockchain réseau, encore une autre solution peut être utilisée pour surmonter la LRA. Les non-titulaires de validator token peuvent publier leurs token comme garantie avec une période de détachement très longue (par exemple beaucoup plus longue que la période de détachement pour validators) et servir des clients légers avec une méthode secondaire d'attestation de la validité des informations actuelles et bloc passé-hashes. Bien que ces token ne comptent pas pour le sécurité du consensus du blockchain, ils peuvent néanmoinsoffrir de solides garanties aux clients légers. Si bloc historique-hash les requêtes étaient prises en charge dans Ethereum, n'importe qui pouvait lier son tokens dans un smart contract spécialement conçu et fournir services d'attestation payants, créant ainsi un marché pour la sécurité des clients légers LRA. En raison de la définition d’un block commit, toute coalition ≥⅓ de le pouvoir de vote peut arrêter le blockchain en sortant du zine ou non diffuser leurs votes. Une telle coalition peut également censurer transactions particulières en rejetant les blocs qui incluent ces transactions, même si cela entraînerait une proportion importante de propositions de blocs seraient rejetées, ce qui ralentirait le rythme de validations de bloc du blockchain, réduisant ainsi son utilité et sa valeur. La coalition malveillante pourrait également diffuser les votes au compte-goutte afin quant à broyer, le bloc blockchain s'engage à s'arrêter presque ou à s'engager dans toute combinaison de ces attaques. Enfin, cela peut provoquer le blockchain à fork, en double-signant ou en violant le verrouillage règles. Si un adversaire actif à l’échelle mondiale était également impliqué, il pourrait diviser le réseau de telle manière qu'il puisse sembler que le mauvais un sous-ensemble de validators était responsable du ralentissement. Ce n'est pas juste une limitation de Tendermint, mais plutôt une limitation de tous protocoles de consensus dont le réseau est potentiellement contrôlé par un adversaire actif. Pour ces types d'attaques, un sous-ensemble des validator doit se coordonner par des moyens externes pour signer une proposition de réorganisation qui choisit un fork (et toute preuve de celui-ci) et le sous-ensemble initial de validators avec leurs signatures. Les validateurs qui signent une telle proposition de réorganisation renoncent à leur garantie sur tous les autres forks. Les clients devraient vérifier les signatures sur la proposition de réorganisation, vérifier toute preuve, et porter un jugement ou demander à l'utilisateur final de prendre une décision. Pour Par exemple, une application de portefeuille téléphonique peut demander à l'utilisateur un code de sécurité

avertissement, alors qu'un réfrigérateur peut accepter toute proposition de réorganisation signé par +½ des validator originaux avec droit de vote. Aucun algorithme byzantin tolérant aux pannes non synchrone ne peut venir au consensus lorsque ≥⅓ des droits de vote sont malhonnêtes, mais une fourchette suppose que ≥⅓ des voix ont déjà été malhonnêtes par double signature ou changement de serrure sans justification. Alors, je signe la proposition de réorganisation est un problème de coordination qui ne peut pas être résolu par n'importe quel protocole non synchrone (c'est-à-dire automatiquement, et sans faire d'hypothèses sur la fiabilité du réseau sous-jacent). Pour l’instant, nous laissons le problème de la coordination des propositions de réorganisation à la coordination humaine via le consensus social. sur les médias Internet. Les validateurs doivent veiller à ce qu'il y ait il n'y a plus de partitions réseau avant la signature d'une proposition de réorganisation, afin d'éviter les situations dans lesquelles deux propositions de réorganisation contradictoires sont signées. En supposant que le support et le protocole de coordination externe soient robuste, il s'ensuit que les forks sont moins préoccupants que la censure attaques. En plus des forks et de la censure, qui nécessitent ≥⅓ byzantin pouvoir de vote, une coalition de >⅔ pouvoir de vote peut s'engager état arbitraire et invalide. Ceci est caractéristique de tout (BFT) système de consensus. Contrairement à la double signature, qui crée des forks avec des preuves facilement vérifiables, détectant l'engagement d'un un état invalide nécessite que des pairs non validateurs vérifient des blocs entiers, ce qui implique qu'ils conservent une copie locale de l'état et exécutent chaque transaction, calculant indépendamment la racine d'état pour eux-mêmes. Une fois détecté, la seule façon de gérer une telle panne passe par le consensus social. Par exemple, dans les situations où Bitcoin a échoué, que ce soit en raison de bugs logiciels (comme en mars 2013), ou commettant un état invalide en raison du comportement byzantin de mineurs (comme en juillet 2015), la communauté bien connectée de entreprises, développeurs, mineurs et autres organisations établi un consensus social sur les actions manuellesrequis par les participants pour guérir le réseau. De plus, puisque On peut s'attendre à ce que validators d'un Tendermint blockchain soient identifiable, l'engagement d'un état invalide peut même être punissable par la loi ou par une jurisprudence externe, si vous le souhaitez. ABCI se compose de 3 types de messages principaux qui sont transmis à partir de le cœur de l’application. L'application répond avec messages de réponse correspondants. Le message AppendTx est le cheval de bataille de l'application. Chacun La transaction dans le blockchain est livrée avec ce message. Le l'application doit valider chaque transaction reçue avec le Message AppendTx contre l'état actuel, le protocole d'application, et les informations d'identification cryptographiques de la transaction. Un validé la transaction doit ensuite mettre à jour l'état de l'application - en en liant une valeur dans un magasin de valeurs clés, ou en mettant à jour le UTXO base de données. Le message CheckTx est similaire à AppendTx, mais il est uniquement destiné à valider les transactions. Vérifications de l'année du pool de mémoire de Tendermint Core la validité d'une transaction avec CheckTx, et uniquement les relais valides transactions avec ses pairs. Les applications peuvent vérifier une incrémentation nonce dans la transaction et renvoie une erreur lors de CheckTx si le nonce est ancien. Le message Commit est utilisé pour calculer un chiffrement engagement envers l’état actuel de l’application, à placer dans le en-tête de bloc suivant. Cela a des propriétés pratiques. Les incohérences dans la mise à jour de cet état apparaîtront désormais sous la forme blockchain forks qui capture toute une classe de programmation erreurs. Cela simplifie également le développement de logiciels légers et sécurisés. clients, car les preuves Merkle-hash peuvent être vérifiées en vérifiant par rapport le bloc-hash, et le bloc-hash est signé par un quorum de validators (par droit de vote).

Des messages ABCI supplémentaires permettent à l'application de suivre et modifiez l'ensemble validator, et pour que l'application reçoive le bloquer les informations, telles que la hauteur et les votes de validation. Les requêtes/réponses ABCI sont de simples messages Protobuf. Vérifier le schéma yle. Arguments : Data ([]byte) : les octets de la transaction de la demande Retours : Code (uint32) : code de réponse Données ([]octet) : octets de résultat, le cas échéant Journal (chaîne) : message de débogage ou d'erreur Utilisation :

Ajoutez et exécutez une transaction. Si la transaction est valide, renvoie CodeType.OK Arguments : Data ([]byte) : les octets de la transaction de la demande Retours : Code (uint32) : code de réponse Données ([]octet) : octets de résultat, le cas échéant Journal (chaîne) : message de débogage ou d'erreur Utilisation :

Valider une transaction. Ce message ne doit pas muter le état. Les transactions sont exécutées pour la première fois via CheckTx avant diffusé aux pairs dans la couche mempool. Vous pouvez faire CheckTx semi-stateful et effacez l'état lors de la validation ou BeginBlock , pour permettre des séquences de transactions dépendantes dans le même bloc.

Retours : Données ([]octet) : racine Merkle hash Journal (chaîne) : message de débogage ou d'erreur Utilisation :

Renvoie une racine Merkle hash de l'état de l'application. Arguments : Data ([]byte) : les octets de la requête Retours : Code (uint32) : code de réponse Data ([]byte) : octets de réponse à la requête Journal (chaîne) : message de débogage ou d'erreur Utilisation :

Videz la file d'attente de réponses. Applications qui implémentent types.L’application n’a pas besoin d’implémenter ce message – c’est gérés par le projet. Retours : Data ([]byte) : les octets d'informations Utilisation :

Renvoie des informations sur l’état de l’application. Demande spécifique. Arguments : Clé (chaîne) : Clé à définir

Value (string) : valeur à définir pour la clé Retours : Journal (chaîne) : message de débogage ou d'erreur Utilisation :

Définissez les options de l'application. Par ex. Key="mode", Value="mempool" pour une connexion mempool, ou Key="mode", Value="consensus" pour une connexion consensuelle. Les autres options sont spécifiques à l'application. Arguments : Validateurs ([]Validator) : Genèse initiale-validators Utilisation :

Appelé une fois lors de la genèse Arguments : Height (uint64) : la hauteur du bloc qui commence Utilisation :

Signale le début d’un nouveau bloc. Appelé avant tout AppendTxs. Arguments : Height (uint64) : hauteur du bloc qui s'est terminé Retours : Validateurs ([]Validator) : validators modifiés par de nouveaux pouvoirs de vote (0 pour supprimer) Utilisation :

Signale la fin d’un bloc. Appelé avant chaque commit après tout opérations Consultez le référentiel ABCI pour plus de détails.Il existe plusieurs raisons pour lesquelles un expéditeur peut souhaiter que accusé de réception d'un paquet par la chaîne réceptrice. Par exemple, l'expéditeur peut ne pas connaître l'état du chaîne de destination, si l'on s'attend à ce qu'elle soit défectueuse. Ou bien, l'expéditeur peut souhaitez imposer un délai d'attente au paquet (avec le paramètre  MaxHeight  rendement des paquets), alors que n'importe quelle chaîne de destination peut souffrir d'une attaque par déni de service avec une augmentation soudaine du nombre de messages entrants. paquets. Dans ces cas, l'expéditeur peut exiger un accusé de réception en définissant l'état initial du paquet sur  AckPending . Ensuite, c'est le la responsabilité de la chaîne de réception de confirmer la livraison en incluant un en abrégé IBCPacket  dans l'application Merkle hash. Tout d'abord, un  IBCBlockCommit  et un  IBCPacketTx  sont publiés sur « Hub ». qui prouve l'existence d'un  IBCPacket  sur la « Zone1 ». Dis ça  IBCPacketTx a la valeur suivante : DeChainID : "Zone1" FromBlockHeight : 100 (disons) Paquet : un IBCPaquet :

En-tête : un IBCPacketHeader : SrcChainID : "Zone1" DstChainID : "Zone2" Nombre : 200 (disons) Statut : Accusé de réception en attente Type : « pièce de monnaie » MaxHeight : 350 (disons que « Hub » est actuellement à la hauteur de 300) Charge utile : Ensuite, un IBCBlockCommit et IBCPacketTx sont publiés sur « Zone2 ». qui prouve l'existence d'un  IBCPacket  sur « Hub ». Dis ça  IBCPacketTx a la valeur suivante : FromChainID : "Hub" FromBlockHeight : 300 Paquet : un IBCPaquet : En-tête : un IBCPacketHeader : SrcChainID : "Zone1" DstChainID : "Zone2" Numéro : 200 Statut : Accusé de réception en attente Type : « pièce de monnaie » Hauteur maximale : 350 Charge utile : Ensuite, « Zone2 » doit inclure dans son app-hash un paquet abrégé qui montre le nouveau statut de  AckSent . Un IBCBlockCommit et  IBCPacketTx sont republiés sur « Hub », ce qui prouve l'existence d'un  IBCPacket  abrégé sur "Zone2". Dites que  IBCPacketTx  a la valeur suivante : DeChainID : "Zone2"

FromBlockHeight : 400 (disons) Paquet : un IBCPacket : En-tête : un IBCPacketHeader : SrcChainID : "Zone1" DstChainID : "Zone2" Numéro : 200 Statut : AcquitEnvoyé Type : « pièce de monnaie » Hauteur maximale : 350 PayloadHash : Enfin, « Hub » doit mettre à jour l'état du paquet depuis  AckPending  à AckReceived . Preuve de ce nouveau statut ynalisé devrait revenir à "Zone2". Supposons que IBCPacketTx contienne les éléments suivants : valeur : FromChainID : "Hub" DeBlockHeight : 301 Paquet : un IBCPacket : En-tête : un IBCPacketHeader : SrcChainID : "Zone1" DstChainID : "Zone2" Numéro : 200 Statut : Accusé de réception Type : « pièce de monnaie » Hauteur maximale : 350 PayloadHash : Pendant ce temps, la « Zone 1 » peut, avec optimisme, supposer une livraison réussie. d'un paquet de « pièces » sauf preuve du contraire sur « Centre ». Dans l'exemple ci-dessus, si « Hub » n'a pas reçu de message AckSent

statut de "Zone2" par le bloc 350, il aurait défini le statut automatiquement sur  Timeout . Cette preuve d'un délai d'attente peut obtenir posté sur « Zone1 », et tous les token peuvent être renvoyés. Il existe deux types de Merkle tree pris en charge dans le Écosystème Tendermint/Cosmos : l'arbre simple et l'IAVL+ Arbre. L'arbre simple est un Merkle tree pour une liste statique d'éléments. Si le le nombre d'éléments n'est pas une puissance de deux, certaines feuilles seront à différents niveaux. Simple Tree essaie de garder les deux côtés de l'arbre même hauteur, mais la gauche peut être plus grande. Ce Merkle tree est utilisé pour Merkle-iser les transactions d'un bloc, et le niveau supérieur éléments de la racine de l’état de l’application.Le but de la structure de données IAVL+ est de fournir des stockage des paires clé-valeur dans l'état de l'application de telle sorte qu'un La racine déterministe de Merkle hash peut être calculée efficacement. Le l'arbre est équilibré à l'aide d'une variante de l'algorithme AVL, et tout les opérations sont O(log(n)). Dans un arbre AVL, les hauteurs des deux sous-arbres enfants de n'importe quel nœud diffèrent d’au plus un. Chaque fois que cette condition est violée lors d'un mise à jour, l'arborescence est rééquilibrée en créant O(log(n)) de nouveaux nœuds qui pointez vers les nœuds non modifiés de l’ancien arbre. Dans l'AVL d'origine algorithme, les nœuds internes peuvent également contenir des paires clé-valeur. L'AVL+ (notez le plus) modifie l'algorithme AVL pour conserver tout valeurs sur les nœuds feuilles, tout en utilisant uniquement des nœuds de branche pour stocker les clés. Cela simplifie l'algorithme tout en gardant la trace merkle hash court. L’arbre AVL+ est analogue aux essais de Patricia de Ethereum. Il y a compromis. Les clés n'ont pas besoin d'être hashed avant d'être insérées dans Arbres IAVL+, ce qui permet une itération ordonnée plus rapide dans la clé espace qui peut bénéficier à certaines applications. La logique est plus simple à implémenter, ne nécessitant que deux types de nœuds : les nœuds internes et nœuds feuilles. La preuve de Merkle est en moyenne plus courte, étant une                 *                 / \               /     \             /         \           /             \          *               *         / \             / \        /   \           /   \       /     \         /     \      *       *       *       h6     / \     / \     / \    h0  h1  h2  h3  h4  h5    Un SimpleTree avec 7 éléments

arbre binaire équilibré. D'autre part, la racine Merkle d'un L’arborescence IAVL+ dépend de l’ordre des mises à jour. Nous prendrons en charge des Merkle tree supplémentaires efficaces, tels que Patricia Trie de Ethereum lorsque la variante binaire devient disponible. Dans l'implémentation canonique, les transactions sont diffusées vers le Application hub Cosmos via l'interface ABCI. Le Cosmos Hub acceptera un certain nombre de transactions principales types, notamment  SendTx ,  BondTx ,  UnbondTx ,  ReportHackTx ,  SlashTx ,  BurnAtomTx ,  ProposalCreateTx et  ProposalVoteTx , qui sont assez explicites et seront documentés dans un révision future de cet article. Nous documentons ici les deux principaux types de transactions pour IBC :  IBCBlockCommitTx  et  IBCPacketTx . Une transaction  IBCBlockCommitTx est composée de : ChainID (string) : ID du blockchain BlockHash ([]byte) : le bloc-hash octets, la racine Merkle qui comprend l'application-hash BlockPartsHeader (PartSetHeader) : l'en-tête de l'ensemble partiel de bloc octets, uniquement nécessaires pour vérifier les signatures de vote BlockHeight (int) : la hauteur du commit BlockRound (int) : Le tour du commit Commit ([]Vote) : le >⅔ Tendermint Precommit vote qui comprendre un bloc de validation ValidatorsHash ([]byte) : une racine Merkle-tree hash du nouveau validator ensemble

ValidatorsHashProof (SimpleProof) : Un SimpleTree Merkleproof pour prouver le ValidatorsHash par rapport au BlockHash AppHash ([]byte) : une racine IAVLTree Merkle-tree hash du état de l'application AppHashProof (SimpleProof) : un SimpleTree Merkle-proof pour prouver l'AppHash contre le BlockHash Un  IBCPacket est composé de : En-tête (IBCPacketHeader) : l'en-tête du paquet Payload ([]byte) : octets de la charge utile du paquet. Facultatif PayloadHash ([]byte) : le hash pour les octets du paquet. Facultatif L'un des éléments suivants : Payload ou PayloadHash doit être présent. Le hash d'un  IBCPacket est une simple racine Merkle des deux éléments,  Header  et Charge utile . Un IBCPacket sans la charge utile complète est appelé un paquet abrégé. Un  IBCPacketHeader est composé de : SrcChainID (string) : ID source blockchain DstChainID (string) : ID de destination blockchain Number (int) : un numéro unique pour tous les paquets Statut (énumération) : peut être AckPending , AckSent , AckReceived , NoAck ou Timeout Type (chaîne) : les types dépendent de l'application. Cosmos réserve le type de paquet "coin" MaxHeight (int) : si le statut n'est pas NoAckWanted ou AckReceived à cette hauteur, le statut devient Timeout . Facultatif Une transaction  IBCPacketTx est composée de :FromChainID (string) : ID du blockchain qui est fournir ce paquet ; pas nécessairement la source FromBlockHeight (int) : hauteur blockchain à laquelle le Le paquet suivant est inclus (Merkle-isé) dans le bloc-hash de la chaîne d'approvisionnement Paquet (IBCPacket) : Un paquet de données, dont le statut peut être un de AckPending , AckSent , AckReceived , NoAck ou Timeout PacketProof (IAVLProof) : un IAVLTree Merkle-proof pour prouver le hash du paquet par rapport à l'AppHash de la chaîne source à hauteur donnée La séquence d'envoi d'un paquet de « Zone1 » à « Zone2 » via le « Hub » est illustré dans la {Figure X}. Tout d'abord, un IBCPacketTx  prouve à "Hub" que le paquet est inclus dans l'état de l'application de "Zone1". Ensuite, un autre  IBCPacketTx  prouve à « Zone2 » que le Le paquet est inclus dans l’état de l’application de « Hub ». Pendant ce temps procédure, les rendements  IBCPacket  sont identiques : le  SrcChainID  est toujours "Zone1" et  DstChainID est toujours "Zone2". Le PacketProof doit avoir le chemin d'accès correct à l'épreuve de Merkle, comme suit : Lorsque « Zone1 » souhaite envoyer un paquet à « Zone2 » via « Hub », les données  IBCPacket  sont identiques, que le paquet soit merkleisé sur la « Zone1 », le « Hub » ou la « Zone2 ». Le seul rendement mutable est  Statut pour le suivi de la livraison. Nous remercions nos amis et nos pairs pour leur aide dans la conceptualisation, examiner et fournir un soutien à notre travail avec Tendermint et Cosmos. IBC///

Zaki Manian de SkuChain a fourni beaucoup d'aide pour le formatage et libellé, en particulier dans la section ABCI Jehan Tremback d'Althea et Dustin Byington pour leur aide itérations initiales Andrew Miller de Honey Badger pour ses commentaires sur le consensus Greg Slepak pour ses commentaires sur le consensus et la formulation Merci également à Bill Gleim et Seunghwan Han pour divers cotisations. Votre nom et votre organisation ici pour votre contribution 1 Bitcoin : https://bitcoin.org/bitcoin.pdf 2 ZéroCash : http://zerocash-project.org/paper 3 Ethereum : https://github.com/ethereum/wiki/wiki/WhitePaper 4 LeDAO : https://download.slock.it/public/DAO/WhitePaper.pdf 5 Témoin séparé : https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG : https://arxiv.org/pdf/1510.02037v2.pdf 7 Réseau Lightning : https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8Menthe tendre : https://github.com/tendermint/tendermint/wiki 9 Impossibilité FLP : https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf dixSlasheur : https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT : http://pmg.csail.mit.edu/papers/osdi99.pdf 12 BitShares : https://bitshares.org/technology/delegatedproof-of-stake-consensus/

13 Stellar : https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 Grand livre intermédiaire : https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 chaînes latérales : https://blockstream.com/sidechains.pdf 16Casper : https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI : https://github.com/tendermint/abci 18 Ethereum Partage : https://github.com/ethereum/EIPs/issues/53 19 LibSwift : http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalysisOfLibswift.pdf 20 DLS : http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 Sécurité des clients légers : https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 Papier Mauve : http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html

³ è