Stellar 共识协议

Résumé

Les paiements internationaux sont lents et coûteux, en partie à cause du routage des paiements à plusieurs niveaux via des réseaux hétérogènes. systèmes bancaires. Stellar est un nouveau réseau de paiement mondial qui peut transférer directement de l'argent numérique n'importe où dans le monde en quelques secondes. L'innovation clé est une transaction sécurisée mécanisme entre intermédiaires non fiables, en utilisant un nouveau Protocole d'accord byzantin appelé SCP. Avec SCP, chacun l'établissement précise les autres établissements avec lesquels rester en accord; grâce à l’interconnectivité mondiale des système financier, l’ensemble du réseau s’accorde alors sur le nucléaire transactions impliquant des institutions arbitraires, sans risque de solvabilité ou de change de la part des émetteurs d’actifs intermédiaires ou des teneurs de marché. Nous présentons le modèle, le protocole et vérification formelle; décrire le réseau de paiement Stellar ; et enfin évaluer Stellar empiriquement à travers des benchmarks et notre expérience avec plusieurs années d'utilisation en production. Concepts du CSC • Sécurité et confidentialité →Distribué sécurité des systèmes ; • Organisation des systèmes informatiques → Architectures peer-to-peer ; • Systèmes d'information → Transfert électronique de fonds. Mots-clés blockchain, BFT, quorums, paiements Format de référence ACM : Marta Lokhava, Giuliano Losa, David Mazières, Graydon Hoare, Nicolas Barry, Eli Gafni, Jonathan Jove, Rafał Malinowsky, Jed McCaleb. 2019. Paiements mondiaux rapides et sécurisés avec Stellar. Dans SOSP '19 : Symposium sur les principes des systèmes d'exploitation, du 27 au 30 octobre 2019, Huntsville, Ontario, Canada. ACM, New York, NY, États-Unis, 17 pages. https://doi.org/10.1145/3341301.3359636

Introduction

Les paiements internationaux sont notoirement lents et coûteux [32]. Considérez l’impossibilité d’envoyer 0,50 $ des États-Unis vers *Galois, Inc. †UCLA Autorisation de faire des copies numériques ou papier de tout ou partie de ce travail pour l'utilisation personnelle ou en classe est autorisée sans frais à condition que les copies ne soient pas réalisés ou distribués dans un but lucratif ou pour un avantage commercial et que les copies portent cet avis et la citation complète sur la première page. Droits d'auteur pour les composants de ce travail appartenant à d’autres qu’ACM doit être honoré. Abstraction avec le crédit est autorisé. Pour copier autrement, ou republier, pour publier sur des serveurs ou pour la redistribution à des listes nécessite une autorisation spécifique préalable et/ou des frais. Demande autorisations de [email protected]. SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada © 2019 Association pour les machines informatiques. ACM ISBN 978-1-4503-6873-5/19/10...15,00 $ https://doi.org/10.1145/3341301.3359636 Le Mexique, deux pays voisins. Les utilisateurs finaux paient près de 9 $ pour la moyenne de ce transfert [32], et un accord bilatéral négociés par les banques centrales des pays ne pouvaient que réduire le coût bancaire sous-jacent à 0,67 $ par article [2]. En plus des frais, la latence des paiements internationaux est généralement comptée en quelques jours, ce qui rend impossible l'obtention rapide d'argent à l'étranger en urgences. Dans les pays où le système bancaire ne fonctionne pas fonctionne ou ne sert pas tous les citoyens, ou lorsque les frais sont intolérables, les gens ont recours à l'envoi de paiements par bus [38], par bateau [19], et occasionnellement maintenant par Bitcoin [55], le tout encourir des risques, des latences ou des désagréments. Même s'il y aura toujours des coûts de mise en conformité, les éléments de preuve suggèrent qu'un montant important est perdu en raison du manque de concurrence [21], ce qui est exacerbé par une technologie inefficace. Où les gens peut innover, les prix et les latences diminuent. Par exemple, les envois de fonds depuis des comptes bancaires au deuxième trimestre 2019 coûtaient en moyenne 6,99%, alors que le chiffre pour l'argent mobile n'était que de 4,88% [13]. Un réseau de paiement ouvert et mondial qui attire l’innovation et la concurrence des entités non bancaires pourrait faire baisser coûts et latences à tous les niveaux, y compris la conformité [83]. Ce document présente Stellar, un paiement basé sur blockchain réseau spécialement conçu pour faciliter l’innovation et concurrence dans les paiements internationaux. Stellar est le premier système pour atteindre les trois objectifs suivants (dans le cadre d’un « hypothèse Internet nouvelle mais empiriquement valable » : 1. Adhésion ouverte – N’importe qui peut émettre des titres adossés à des devises token numériques pouvant être échangés entre utilisateurs. 2. Finalité imposée par l'émetteur – L'émetteur d'un token peut empêcher les transactions dans le token ne soient pas annulées ou annulées. 3. Atomicité entre émetteurs – Les utilisateurs peuvent échanger atomiquement et négociez des token de plusieurs émetteurs. Atteindre les deux premiers est facile. Toute entreprise peut proposer unilatéralement un produit tel que Paypal, Venmo, WeChat Pay, ou Alipay et assurez la finalité des paiements dans les délais monnaies virtuelles qu'ils ont créées. Malheureusement, les transactions atomiques entre ces devises sont impossibles. En fait, bien que Paypal ait acquis la société mère de Venmo en 2013, il est toujours impossible pour les utilisateurs finaux d'envoyer du Venmo dollars aux utilisateurs Paypal [78]. Ce n'est que récemment que les commerçants peuvent acceptez même les deux avec une seule intégration. Les objectifs 2 et 3 peuvent être atteints dans un système fermé. En particulier, un certain nombre de pays disposent de systèmes de paiement nationaux efficaces. réseaux, généralement supervisés par une autorité de régulation universellement fiable. Toutefois, l'adhésion est limitée à un groupe fermé ensemble de banques à charte et les réseaux se limitent au portée de l’autorité de régulation d’un pays.SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Lokhava et coll. Les objectifs 1 et 3 ont été atteints dans les blockchain extraits, notamment sous la forme d'ERC20 token sur Ethereum [3]. L'idée clé de ces blockchain est de créer une nouvelle crypto-monnaie avec laquelle récompenser les personnes qui s'installent. transactions difficiles à annuler. Malheureusement, cela signifie que les émetteurs token ne contrôlent pas le caractère définitif des transactions. Si le logiciel les erreurs provoquent une réorganisation de l'historique des transactions [26, 73], ou lorsque le butin des fraudeurs dépasse le coût de en réorganisant l'historique [74, 97], les émetteurs peuvent être responsables de tokens ils ont déjà échangé contre de l'argent réel. Le Stellar blockchain possède deux propriétés distinctives. Premièrement, il prend en charge nativement les marchés efficaces entre tokens provenant de différents émetteurs. Plus précisément, n'importe qui peut émettre un token, le blockchain fournit un carnet d'ordres intégré pour les échanges entre n'importe quelle paire de token, et les utilisateurs peuvent émettre des paiements de chemin qui négocient atomiquement sur plusieurs paires de devises tout en garantissant un prix limite de bout en bout. Deuxièmement, Stellar introduit un nouvel accord byzantin protocole, SCP (Stellar Consensus Protocol), à travers lequel Les émetteurs token désignent des serveurs validator spécifiques à appliquer finalité de la transaction. Tant que personne ne compromet les validator d’un émetteur (et les signatures numériques et les hashes cryptographiques restent sécurisés), l'émetteur sait exactement quelles transactions ont eu lieu et évite le risque des pertes résultant de la réorganisation de l'historique blockchain. L’idée clé de SCP est que la plupart des émetteurs d’actifs bénéficient des marchés liquides et veulent faciliter les transactions atomiques avec d'autres actifs. Par conséquent, les administrateurs validator configurent leurs serveurs pour se mettre d'accord avec d'autres validator sur les détails exacts historique de toutes les transactions sur tous les actifs. Un validator v1 peut être configuré pour être d'accord avec la v2, ou la v2 peut être configurée pour être d'accord avec la version v1, ou les deux peuvent être configurés pour s'accorder ; dans tous les cas, ni l'un ni l'autre ne s'engagera sur un historique des transactions jusqu'à ce que il sait que l’autre ne peut pas s’engager dans une histoire différente. Par transitivité, si v1 ne peut pas être en désaccord avec v2 et v2 ne peut pas être en désaccord avec v3 (ou vice versa), v1 ne peut pas être en désaccord avec v3, que v3 représente ou non des actifs dont v1 a même entendu parler de. Sous l’hypothèse que ces relations d’accord connecter transitivement l'ensemble du réseau, garantit SCP accord mondial, ce qui en fait un accord byzantin mondial protocole avec adhésion ouverte. Nous appelons cette nouvelle hypothèse de connectivité l’hypothèse d’Internet et notons qu’elle détient à la fois « Internet » (que tout le monde comprend comme signifie le plus grand réseau IP connecté de manière transitive) et les anciens paiements internationaux (qui sont effectués étape par étape non atomique, mais exploite un système global et connecté de manière transitive. réseau d’institutions financières). Stellar est utilisé en production depuis septembre 2015. Pour que la longueur blockchain reste gérable, le système exécute SCP à intervalles de 5 secondes – rapide selon les normes blockchain, mais beaucoup plus lente que les applications typiques de l’accord byzantin. Bien que l'utilisation principale ait été les paiements, Stellar a également s'est avéré attrayant pour les token non monétaires fongibles qui bénéficient provenant des marchés secondaires immédiats (voir la section 7.1). La section suivante traite des travaux connexes. La section 3 présente SCP. La section 4 décrit notre vérification formelle de SCP. La section 5 décrit la couche de paiement de Stellar. La section 6 concerne une partie de notre expérience de déploiement et des leçons apprises. La section 7 évalue le système. La section 8 conclut.

Travaux connexes

Le système décrit dans cet article est collectivement notre troisième tenter de réaliser un réseau de paiement décentralisé. Le la première tentative, par l'un des auteurs, a abouti au Ripple blockchain. Bien qu'il existe encore, nous pensons que Ripple ne peut pas réaliser la vision d'un réseau de paiement véritablement ouvert pour à la fois pour des raisons de gouvernance et techniques. Les raisons de gouvernance découlent des tensions entre les intérêts des actionnaires et utilisateurs du réseau, mais dépassent le cadre de cet article. Le Le problème technique est que le protocole d'accord byzantin de Ripple [89] nécessite une adhésion presque fermée [33], ce qui en fait fonctionnellement similaire à l’accord byzantin conventionnel. La deuxième tentative, un fork éphémère du code Ripple base appelée Stellard, a été mise en service en juillet 2014. Nous avions prévu de développer SCP et l'insérer dans Stellard lorsqu'il est prêt, mais à la place a décidé de construire un nouveau système à partir de zéro autour de SCP, appelé noyau stellaire et décrit dans cet article. noyau stellaire a été libéré avec une description et une preuve de SCP [68] en avril 2015 et est entré en production 5 mois plus tard. Un brouillon Internet [20] a décrit plus tard SCP pour les implémenteurs. La motivation et la structure de SCP sont similaires à la confiance asymétrique dans le calcul multipartite [40], bien que ce modèle nécessite que les nœuds aient une vue globale de la structure de l’adversaire. En introduisant une notion de tranches de quorum, SCP bénéficie la découvrabilité et l’adhésion dynamique qui sont importantes pour le déploiement de Stellar. Quorum byzantin personnel Les systèmes [47] et la confiance distribuée asymétrique [29] généralisent les quorums de SCP et simplifient la comparaison avec les systèmes traditionnels. systèmes. Dans un cadre plus restreint, Gotsman et al. [49] également étudier une généralisation des quorums de Stellar. Plusieurs autres blockchain ont adopté SCP, notamment MobileCoin [7] et NCNT. Ripple a également proposé plus récemment un protocole d'accord byzantin à adhésion ouverte. appelé Cobalt [66]. La sécurité de SCP est optimale, donc SCP est en sécurité dans tout scénario d'échec où se trouve le cobalt, alors que l'inverse est peu clair. Cependant, Cobalt affirme que sa condition de sécurité est plus facile à comprendre et donc moins sujette à une mauvaise configuration, ce qui sera intéressant d’évaluer si Cobalt sera déployé. 2.1 Systèmes sans adhésion ouverte Comme de nombreux protocoles de consensus, SCP est basé sur le vote [50, 94] dans un système de quorum. Des travaux antérieurs sur les systèmes de quorum [52, 67, 72], parfois appelés « ensembles de survivants » [57], étudient les systèmes de quorum qui sont statiques, c'est-à-dire fixes tout au long de l'année. exécution du système et uniforme, c'est-à-dire où tous les nœuds ont le même notion de ce qu'est un quorum. Le paramètre de SCP est différent dans que différents nœuds acceptent des quorums différents et évolutifs.Paiements mondiaux rapides et sécurisés avec Stellar SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Un consensus rapide et hétérogène [91] permet des analyses plus nuancées notions de confiance à exprimer via des étiquettes dans un treillis et exploite cela pour optimiser la communication, mais cela suppose adhésion fermée. Autres efforts pour adapter les protocoles d'accord byzantins aux paramètres de type Blockchain, y compris HoneyBadger [70], SBFT [53] et HotStuff [99] se sont concentrés sur l'évolutivité à de nombreux participants et des performances sur des réseaux étendus, en conservant le modèle traditionnel à adhésion fermée. Les blockchains ciblant les membres fermés ont tiré parti de tels protocoles, y compris plus récemment Libra [11]. 2.2 Systèmes sans caractère définitif imposé par l'émetteur Bitcoin [71] a été le premier actif numérique fongible sans autorité de confiance pour suivre les soldes. Il a simultanément résolu deux problèmes : comment distribuer un nouvel actif pour que les gens croient il a de la valeur, et comment fournir des transactions irréversibles qui empêcher les attaques à double dépense. Bitcoin crée des actifs grâce à proof-of-work [43], que son auteur compare aux mineurs d'or qui investissent des ressources pour augmenter l'offre d'or. Le le travail prouvé dépend de l’historique des transactions, ce qui contrecarre attaques à double dépense, car l'annulation des transactions nécessite un travail comparable à la création de l'historique d'origine. Les attaques contre les proof-of-work blockchain deviennent possibles une fois qu'un attaquant contrôle 1/3 de la puissance minière [46, 48]. La preuve de travail est particulièrement risquée pour les blockchain nouveaux ou plus petits [15, 23]; on sait que les mineurs établis détournent l'exploitation minière pouvoir aux petites chaînes pour le profit [10, 54, 74, 97, 98] ou simplement pour créer des problèmes [25, 37] (appelés « attaques Goldfinger » [60]). Parfois, les mineurs ont monté avec bienveillance de telles « attaques à 51 % » pour annuler les effets indésirables des bugs [95]. Nouveau Les blockchain peuvent obtenir une certaine protection contre 51 % des attaques en tirer parti de blockchain plus établis avec une exploitation minière fusionnée [6] ou une preuve de brûlage [79]. Au moment d'écrire ces lignes, une attaque à 51 % est estimée à 823 000 $/ heure sur Bitcoin, \(93,000/hour on Ethereum, and under \)20 000/ heure pour tous les autres blockchain suivis [12]. En fin de compte, ces les coûts dépendent de la valeur de la cryptomonnaie incitant au minage, qui est indépendante de la valeur de l'émission. actifs. En revanche, le coût de la compromission des Stellar validator est dans une certaine mesure sous le contrôle de leurs administrateurs ; SCP se prête à des implémentations à haute assurance, telles que en utilisant des modules de sécurité matériels pour empêcher un validator de signer des messages contradictoires. Comme avantage supplémentaire, Stellar n'a aucun coût minier à récupérer via la transaction droits ou seigneuriage. La consommation énergétique massive de Bitcoin [76] a motivé des variantes de preuve de travail plus économes en énergie telles que preuve d'espace [16, 17, 44, 87], preuve de stockage [18, 56, 86, 90], et une preuve du temps écoulé [4]. La preuve de travail peut être lente, avec des blocs de transactions prendre quelques minutes pour confirmer et plusieurs blocs requis pour une sécurité renforcée. Cependant, le travail pour extraire un bloc peut être amorti sur un lot de transactions de taille arbitraire, limité uniquement par des questions politiques et de compatibilité. BitcoinNG [45] utilise une preuve de travail pour élire un leader qui coordonne un plus grand lot de transactions. Thunderella [84] peut utiliser la preuve de travail comme « chemin lent » de secours et confirmer avec optimisme transactions beaucoup plus rapides grâce à un consensus asynchrone protocole quand un nœud accélérateur et les 3/4 d'un comité élu sont honnêtes. Bien que SCP soit plus rapide que proof-of-work, cela nécessite plus de messages que le chemin rapide de Thunderella, mais pourrait potentiellement être un chemin lent utile pour Thunderella. Une alternative à la preuve de travail est la preuve d'enjeu [59], dans lequel les mineurs obtiennent une influence directe ou indirecte de la propriété des actifs. Dans certains cas, l’influence augmente avec la durée de détention des actifs. Certains schémas encourager l’honnêteté en confisquant les parts des mineurs s’ils se comporter mal [27, 28, 41]. Le délégué proof-of-stake [9, 61] a les nœuds votent selon leur participation pour élire des représentants pour un protocole d'accord byzantin conventionnel tel que PBFT [31]. Algorand [51] utilise des fonctions aléatoires vérifiables pour élire des nœuds représentatifs de manière pseudo-aléatoire, avec une probabilité proportionnelle aux avoirs en crypto-monnaie. Blanche-Neige [39] officialise le propriétés de sécurité requises dans la preuve d'enjeu, accueillant des nœuds « endormis » qui continuent ethors ligne. Bien que la plupart des schémas proof-of-stake ne puissent pas être forcés par des calculs coûteux, le coût d'acquisition de la participation ou la corruption des mineurs est toujours liée à la valeur de la cryptomonnaie sous-jacente et échappe au contrôle de l’émetteur d’actifs. Même en l'absence de mineurs malveillants, les bugs peuvent également provoquer blockchain réorganisation [26, 73]. Ainsi, contrairement à SCP, les émetteurs n'ont aucun moyen de garantir le caractère définitif de blockchain avant échanger des token en chaîne contre un virement bancaire réel ou retrait d'espèces.

Protocole de consensus Stellar

Le protocole de consensus (SCP) Stellar est un protocole basé sur le quorum. Protocole d'accord byzantin avec adhésion ouverte. Les quorums émergent des décisions combinées de configuration locale des nœuds individuels. Cependant, les nœuds ne reconnaissent que collèges auxquels ils appartiennent eux-mêmes, et seulement après apprendre les configurations locales de tous les autres membres du collège. L'un des avantages de cette approche est que SCP est intrinsèquement tolère des vues hétérogènes sur les nœuds existants. Hence, les nœuds peuvent rejoindre et quitter unilatéralement sans avoir besoin d'un protocole « visualiser le changement » pour coordonner l'adhésion. 3.1 Accord byzantin fédéré Le problème traditionnel de l’accord byzantin consiste en un système fermé de N nœuds, dont certains sont défaillants et peuvent behave arbitrarily. Les nœuds reçoivent des valeurs d'entrée et échangent messages pour décider d’une valeur de sortie parmi les entrées. Un protocole d'accord byzantin est sûr lorsqu'il n'y a pas deux nœuds bien élevés qui produisent des décisions différentes et l'unique la décision était une contribution valable (pour une définition d’un accord valideSOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Lokhava et coll. au préalable). Un protocole est opérationnel lorsqu'il garantit que chaque nœud honnête finit par produire une décision. Généralement, les protocoles supposent N = 3f + 1 pour un nombre entier f > 0, alors garantir la sécurité et une certaine forme de vivacité donc tant qu'au plus les nœuds f sont défectueux. À un moment donné de ces protocoles, les nœuds votent sur les valeurs proposées et une proposition recevoir 2f + 1 voix, appelé quorum de voix, devient la décision. Avec N = 3f + 1 nœuds, deux quorums quelconques de la taille 2f + 1 se chevauche dans au moins f + 1 nœuds ; même si f d'entre eux les nœuds qui se chevauchent sont défectueux, les deux quorums partagent au moins un nœud non défectueux, évitant ainsi les décisions contradictoires. Cependant, cette approche ne fonctionne que si tous les nœuds sont d'accord sur ce qui constitue un quorum, ce qui est impossible dans SCP où deux nœuds peuvent même ne pas connaître l’existence de l’autre. Avec SCP, chaque nœud v déclare unilatéralement des ensembles de nœuds, appelé ses tranches de quorum, telles que (a) v croit que si tous les membres d'une tranche sont d'accord sur l'état du système, alors ils ont raison, et (b) v croit qu'au moins une de ses tranches sera disponible pour fournir des informations en temps opportun sur état du système. Nous appelons le système résultant, constitué de nœuds et de leurs tranches, un accord byzantin fédéré (FBA). Comme nous le verrons ensuite, un système de quorum émerge à partir des tranches des nœuds. De manière informelle, les tranches d'un nœud FBA expriment avec qui le le nœud nécessite un accord. Par exemple, un nœud peut nécessiter un accord avec 4 organisations spécifiques, chacune exécutant 3 nœuds ; à s'adapter aux temps d'arrêt, il peut définir ses tranches pour qu'elles soient toutes définies composé de 2 nœuds de chaque organisation. Si cela « nécessite La relation « accord avec » relie transitivement deux nœuds quelconques, nous obtenons un accord mondial. Sinon, nous pouvons obtenir une divergence, mais seulement entre organisations, ce qui ne nécessite aucune accord avec l'autre. Compte tenu de la topologie actuelle système financier, nous émettons l’hypothèse qu’une convergence généralisée continuera à produire un registre unique que les gens appellent «le réseau Stellar», tout comme nous parlons d'Internet. Les quorums proviennent des tranches comme suit. Chaque nœud spécifie son quorum tranche dans chaque message qu'il envoie. Soit S le ensemble de nœuds à partir duquel un ensemble de messages provient. Un le nœud considère que l'ensemble des messages a atteint le quorum seuil lorsque chaque membre de S a une tranche incluse dans S. Par construction, un tel ensemble S, s’il est unanime, satisfait au exigences contractuelles de chacun de ses membres. Un homologue défectueux peut annoncer des tranches conçues pour changer ce qui les nœuds bien élevés considèrent les quorums. Par souci d'analyse protocolaire, nous définissons un quorum dans FBA comme étant un quorum non vide. ensemble S de nœuds englobant au moins une tranche de quorum de chaque membre non fautif. Cette abstraction est saine, comme tout ensemble de messages prétendant représenter un quorum unanime le fait réellement (même s'il contient des messages provenant de nœuds défectueux), et c'est précis lorsque S ne contient que des nœuds bien élevés. Dans dans cette section, nous supposons également que les tranches des nœuds ne changent pas. Néanmoins, nos résultats sont transférables au cas du changement de tranche car un système dans lequel les tranches changent n'est pas moins sûr qu'un un système à tranches fixes dans lequel les tranches d’un nœud sont constituées de tous les tranches qu'il utilise dans le cas des tranches changeantes (voir le théorème 13 dans [68]). Comme expliqué dans la section 4, la vivacité dépend de les nœuds bien élevés suppriment finalement les nœuds peu fiables de leurs tranches. Étant donné que les différents nœuds ont des exigences d'accord différentes, FBA exclut une définition globale de la sécurité. Nous disons les nœuds non défectueux v1 et v2 sont entrelacés à chaque fois le quorum de v1 croise chaque quorum de v2 dans au moins un nœud non défectueux. Un protocole FBA peut garantir un accord uniquement entre les nœuds entrelacés ; puisque SCP le fait, c'est de la faute la tolérance en matière de sécurité est optimale. L'hypothèse d'Internet, qui sous-tend la conception de Stellar, indique que les nœuds dont les gens se soucient à propos sera entrelacé. Nous disons qu'un ensemble de nœuds I est intact si I est un quorum uniformément non défectueux tel que tous les deux membres de I sont entrelacés même si chaque nœud en dehors de I est défectueux. Intuitivement, alors, je devrais rester imperméable aux actions des personnes non intactes nœuds. SCP garantit à la fois la vivacité non bloquante [93] et sécurité aux ensembles intacts, bien que les nœuds eux-mêmes n'aient pas besoin pour savoir (et peut-être ne pas pouvoir savoir) quels ensembles sont intacts. De plus, l’union de deux ensembles intacts qui se croisent est un ensemble intact. Par conséquent, les ensembles intacts définissent une partition du des nœuds bien élevés, où chaque partition est sûre et active (sous certaines conditions), mais différentes partitions peuvent afficher des décisions divergentes. 3.1.1 Considérations relatives à la sécurité et à la vivacité dans FBA À quelques exceptions près [64], la plupart des protocoles d'accords byzantins fermés sont adaptés au point d'équilibre auquel la sécurité et la vivacité ont la même tolérance aux pannes. Dans Expédié par Amazon, cela signifie des configurations dans lesquelles, quelles que soient les pannes, tous les ensembles entrelacés sont également intacts. Étant donné que Expédié par Amazon détermine quorums de manière décentralisée, il est peu probable que les choix individuels des tranches conduisent à cet équilibre. De plus, à au moins en Stellar, l'équilibre n'est pas souhaitable : les conséquences d'une défaillance de sécurité (à savoir de l'argent numérique dépensé en double) sont bien pires que ceux d'un échec de vivacité (à savoir des retards en paiements qui ont de toute façon pris des jours avant le Stellar). Les gens par conséquent, nous devrions sélectionner et sélectionnons de grandes tranches de quorum telles que leurs nœuds sont plus susceptibles de rester entrelacés qu’intacts. En faisant encore pencher la balance, il est plus facile de se remettre de échecs de vivacité typiques dans un système FBA que dans un système fermé traditionnel. Dans les systèmes fermés, tous les messages doivent être interprété par rapport au même ensemble de quorums. Par conséquent, l'ajout et la suppression de nœuds pour récupérer après une panne nécessitent parvenir à un consensus sur un événement de reconfiguration, ce qui est difficile une fois que le consensus n’est plus d’actualité. En revanche, avec FBA, n'importe quel nœud peut ajuster unilatéralement ses tranches de quorum à tout moment. le temps. En réponse à une panne dans un site d'importance systémique organisation, les administrateurs de nœuds peuvent ajuster leurs tranches en fonction contourner le problème, un peu comme coordonner les réponses aux catastrophes BGP [63] (mais sans les contraintes de routage sur des liens réseau physiques).

Paiements internationaux rapides et sécurisés avec Stellar SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada 3.1.2 Le théorème des cascades SCP suit le modèle du modèle rond de base [42] ; les nœuds progressent à travers une série de bulletins de vote numérotés, chacun tenter trois tâches : (1) identifier une valeur « sûre » qui n'est contredite par aucune décision lors d'un scrutin précédent (souvent appelée préparer le scrutin), (2) s'entendre sur la valeur sûre et (3) détecter que l'accord a été conclu. Cependant, FBA est ouvert l'adhésion bloque plusieurs techniques courantes, ce qui rend impossible de « porter » les protocoles fermés traditionnels vers le FBA modèle en changeant simplement la définition du quorum. Une technique utilisée par de nombreux protocoles est la rotation via les nœuds leaders de manière circulaire après les délais d'attente. Dans un système fermé, la sélection des leaders à tour de rôle garantit qu'au final, un leader honnête et unique finit par coordonner un accord sur une valeur unique. Malheureusement, le tournoi à la ronde ne peut pas fonctionner dans un système FBA avec une adhésion inconnue. Une autre technique courante qui échoue avec FBA consiste à supposer qu'un quorum particulier peut convaincre tous les nœuds. Par exemple, si tout le monde reconnaît des nœuds 2f + 1 comme quorum, alors Les signatures 2f + 1 suffisent pour prouver l'état du protocole à tous les nœuds. De même, si un nœud reçoit un quorum de messages identiques grâce à une diffusion fiable [24], le nœud peut supposer que tous les nœuds non défectueux verront également un quorum. Dans FBA, en revanche, un le quorum ne signifie rien pour les nœuds en dehors du quorum. Enfin, les systèmes non fédérés emploient souvent des raisonnement sur la sécurité : si les nœuds f + 1 sont défectueux, toute la sécurité les garanties sont perdues. Par conséquent, si le nœud v entend tous les nœuds f + 1 énoncer un fait F, v peut supposer qu'au moins l'un d'eux dit au vérité (et donc que F est vrai) sans perte de sécurité. Tel le raisonnement échoue dans FBA car la sécurité est une propriété des paires de nœuds, donc un nœud qui a perdu sa sécurité au profit de certains pairs peut perdez toujours la sécurité sur plus de nœuds en supposant de mauvais faits. Expédié par Amazon peut cependant raisonner à rebours sur la vivacité. Définir un ensemble de blocage en V comme un ensemble de nœuds qui se croisent tous les tranche de v. Si un ensemble de blocage en v B est unanimement défectueux, B peut refuser au nœud v un quorum et lui coûter de la vivacité. Par conséquent, si B énonce à l’unanimité le fait F, alors v sait que soit F est vrai ou v n’est pas intact. Cependant, v a encore besoin de voir un aperçu complet quorum pour savoir que les nœuds entrelacés ne contrediront pas F, ce qui mène à un dernier cycle de communication dans SCP et d'autres protocoles FBA [47] qui ne sont pas requis dans des protocoles d’adhésion fermée. Le résultat est que nous avons trois niveaux de confiance possibles dans des faits potentiels : indéterminé, sûr à supposer parmi les nœuds intacts (que nous allons terme faits acceptés), et on peut le supposer en toute sécurité parmi les nœuds (que nous appellerons faits confirmés). Le nœud v peut déterminer efficacement si un ensemble B est vbloquant en vérifiant si B coupe toutes ses tranches. Il est intéressant de noter que si les nœuds annoncent toujours les déclarations qu'ils accepter et qu'un quorum complet accepte une déclaration, cela déclenche un processus en cascade par lequel les déclarations se propagent partout ensembles intacts. Nous appelons le fait clé qui sous-tend cette propagation le théorème de la cascade, qui énonce ce qui suit : Si I est un ensemble intact, Q est un quorum de n'importe quel membre de I, et S est n'importe quel surensemble de Q, alors soit S ⊇I soit il y a un membre v ∈I tel que v < S et I ∩S est v-bloquant. Intuitivement, était-ce ce n'est pas le cas, le complément de S contiendrait un quorum qui coupe I mais pas Q, violant l'intersection du quorum. Notez que si nous commençons par S = Q et développons S à plusieurs reprises pour inclure tous les nœuds qu'il bloque, on obtient un effet en cascade jusqu'à ce que, finalement, S englobe tout I. 3.2 Description du protocole SCP est un protocole de consensus partiellement synchrone [42] composé d'une série de tentatives pour parvenir à un consensus appelées bulletins de vote. Les bulletins de vote utilisent des délais d'attente de durée croissante. Un le protocole de synchronisation des bulletins de vote garantit que les nœuds restent activés le même scrutin pour des périodes croissantes jusqu'aux scrutins sont effectivement synchrones. La résiliation n'est pas garantie jusqu'à ce que les scrutins soient synchrones, mais deux scrutins synchrones dans lequel font les membres défectueux des tranches de nœuds bien élevés ne pas interférer sont suffisants pour que SCP se termine. Un protocole de vote précise les actions menées lors de chaque bulletin de vote. Un scrutin commence par une phase de préparation, au cours de laquelle les nœuds essayer de déterminer une valeur à proposer qui ne contredit pas toute décision antérieure. Ensuite, dans une phase de validation, les nœuds essaient pour prendre une décision sur la valeur préparée. Le scrutin utilise un sous-protocole d'accord appelé vote fédéré, jen quels nœuds votent sur des déclarations abstraites cela pourrait éventuellement être confirmé ou rester bloqué. Certaines déclarations peuvent être qualifiées de contradictoires et la sécurité La garantie du vote fédéré est qu'il n'y a pas deux membres d'un un ensemble entrelacé confirme des déclarations contradictoires. La confirmation d'une déclaration n'est pas garantie sauf pour une déclaration intacte ensemble dont les membres votent tous de la même manière. Cependant, si un un membre d'un ensemble intact confirme une déclaration, fédérée le vote garantit que tous les membres de l’ensemble intact finissent par confirmer cette déclaration. Par conséquent, prendre des mesures irréversibles en réponse aux déclarations confirmatives préserve la vivacité pour nœuds intacts. Les nœuds proposent initialement des valeurs obtenues à partir d'une nomination protocole qui augmente les chances de tous les membres d’un groupe intact ensemble proposant la même valeur, et qui finit par converger (bien qu'il n'y ait aucun moyen de déterminer que la convergence est complète). La nomination combine le vote fédéré et la sélection des dirigeants. Parce que le round-robin est impossible dans FBA, la nomination utilise un système probabiliste de sélection des dirigeants. Le théorème de la cascade joue un rôle crucial à la fois dans le scrutin synchronisation et en évitant les états bloqués à partir desquels la résiliation n’est plus possible. 3.2.1 Vote Les nœuds SCP procèdent à une série de scrutins numérotés, en utilisant le vote fédéré pour se mettre d'accord sur des déclarations sur lesquelles les valeurs sont ou ne sont pas décidées dans quels scrutins. Si asynchronie ou un comportement fautif empêche de parvenir à une décision au scrutin n, les nœuds expirent et réessayez au scrutin n + 1.

SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Lokhava et coll. Le vote fédéré de rappel pourrait ne pas prendre fin. Ainsi, certains les déclarations sur les bulletins de vote peuvent rester bloquées de façon permanente état indéterminé où les nœuds ne peuvent jamais déterminer s'ils sont toujours en cours ou bloqués. Parce que les nœuds ne peuvent pas exclure la possibilité que des déclarations indéterminées s'avèrent plus tard vraies, ils ne doivent jamais tenter de voter de manière fédérée sur de nouvelles déclarations contredisant les indéterminés. A chaque scrutin n, les nœuds utilisent le vote fédéré sur deux types de déclaration: • préparer ⟨n,x⟩– indique qu'aucune valeur autre que x a été ou sera un jour décidé lors d’un scrutin ≤n. • commit ⟨n,x⟩– indique que x est décidé lors du scrutin n. Surtout, notez que préparer ⟨n,x⟩contradit le commit ⟨n′,x ′⟩quand n ≥n′ et x , x ′. Un nœud démarre le scrutin n en tentant un vote fédéré sur un instruction préparer ⟨n,x⟩. Si une instruction de préparation précédente a été confirmé avec succès par un vote fédéré, le Le nœud choisit x dans le plan confirmé du scrutin le plus élevé. Sinon, le nœud définit x sur la sortie du protocole de nomination décrit dans la sous-section suivante. Si et seulement si un nœud confirme avec succès, préparez ⟨n,x⟩ lors du scrutin n, il tente un vote fédéré sur le commit ⟨n,x⟩. Si qui réussit, cela signifie que SCP a décidé, donc le nœud sort la valeur de l'instruction de validation confirmée. Considérons un ensemble entrelacé S. Puisqu'au plus une valeur peuvent être confirmées préparées par les membres de S lors d'un scrutin donné, deux valeurs différentes ne peuvent pas être confirmées par membres de S lors d’un scrutin donné. De plus, si commit ⟨n,x⟩ est confirmé, alors préparer ⟨n,x⟩a également été confirmé ; depuis préparer ⟨n,x⟩contredit tout engagement antérieur pour une valeur différente, par l'accord garantissant le vote fédéré nous obtenons qu'aucune valeur différente ne peut être décidée dans un précédent scrutin par les membres de S. Par induction sur les numéros de scrutin, on assurez-vous donc que SCP est en sécurité. Pour la vivacité, considérons un ensemble I intact et suffisamment long vote synchrone n. Si des nœuds défaillants apparaissent dans les tranches des nœuds bien élevés n'interfèrent pas dans n, alors par scrutin n + 1 tous les membres de I ont confirmé le même ensemble P d'instructions de préparation. Si P = ∅ et que le scrutin n était suffisamment long, le le protocole de nomination aura convergé vers une certaine valeur x. Sinon, soit x la valeur du plan avec le vote le plus élevé dans P. Quoi qu'il en soit, je tenterai uniformément de fédérer voter sur la préparation ⟨n + 1,x⟩au prochain scrutin. Par conséquent, si n + 1 est également synchrone, une décision pour x s'ensuit inévitablement. 3.2.2 Nomination La nomination implique un vote fédéré sur les déclarations : • Nommer x – déclare que x est un candidat à la décision valide. Les nœuds peuvent voter pour désigner plusieurs valeurs, différentes les déclarations de nomination ne sont pas contradictoires. Cependant, une fois un nœud confirme toute déclaration nominative, il arrête de voter pour nommer de nouvelles valeurs. Le vote fédéré permet toujours à un nœud de confirmer les nouvelles déclarations nominatives pour lesquelles il n'a pas voté, ce qui voter ou accepter un du quorum accepter un du quorum a est valide accepter un de ensemble de blocage non engagé a voté un accepté un a confirmé un a voté ¬a Figure 1. Étapes du vote fédéré permet aux membres d’un ensemble intact de se confirmer mutuellement valeurs proposées tout en retenant de nouveaux votes. Le résultat (évolutif) de la nomination est une combinaison déterministe de toutes les valeurs contenues dans les déclarations de nomination confirmées. Si x représente un ensemble de transactions, les nœuds peuvent prendre l'union d'ensembles, l'ensemble le plus grand ou celui avec le hash le plus élevé, donc tant que tous les nœuds font de même. Parce que les nœuds retiennent les nouvelles votes après avoir confirmé une déclaration de nomination, l'ensemble des les déclarations confirmées ne peuvent contenir qu’un nombre fini de valeurs. Le fait que des déclarations confirmées se soient répandues de manière fiable les ensembles intacts signifient que les nœuds intacts finissent par converger vers le même ensemble de valeurs nominées et donc résultat de la nomination, mais à un moment inconnu, arbitrairement tard dans le protocole. Les nœuds utilisent la sélection de leaders fédérés pour réduire le nombre de valeurs différentes dans les instructions nominatives. Seulement un leader qui n'a pas encore voté pour une déclaration de nomination peut introduire un nouveau x. D'autres nœuds attendent des nouvelles dirigeants et copiez simplement les votes de nomination (valides) de leurs dirigeants. Pour faire face à l'échec, l'ensemble des dirigeants ne cesse de croître à mesure que des délais d'attente se produisent, bien qu'en pratique, seuls quelques nœuds introduisent de nouvelles valeurs de x. 3.2.3 Vote fédéré Le vote fédéré utilise un protocole en trois phases illustré dans Figure 1. Les nœuds tentent de se mettre d'accord sur des déclarations abstraites en premier voter, puis accepter et enfin confirmer les déclarations. Un nœud v peut voter pour toute déclaration valide a qui ne correspond pas à contredire son autrevotes en suspens et déclarations acceptées. Pour ce faire, il diffuse un message de vote signé. v accepte alors a si a est cohérent avec d'autres déclarations acceptées et soit (cas 1) v est membre d'un quorum dans lequel chaque nœud vote pour a ou accepte a, ou (cas 2) même si v n'a pas voté pour un, un ensemble de blocage en V accepte un. Dans le cas 2, v peut ont déjà voté contre a, qui ont maintenant été rejetée. v est autorisé à oublier les votes annulés et faire comme s'il ne les avait jamais lancés car si V est intact, il le sait les votes annulés ne peuvent pas atteindre le quorum dans le cas 1. v diffuse qu'il accepte a, puis confirme a lorsqu'il est en un quorum qui accepte à l'unanimité a. La figure 2 montre le effet des ensembles v-bloquants et du théorème de la cascade pendant vote fédéré. Deux nœuds entrelacés ne peuvent pas confirmer des déclarations contradictoires, car les deux quorums requis devraient partager unPaiements internationaux rapides et sécurisés avec Stellar SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada 3 4 2 1 5 7

Votez X

Votez Y (une) 3 4 2 1 5 7 6 Voter X Voter X Voter X Voter Oui Voter X Voter Oui Voter Oui (b) 3 4 2 1 5 7 6 Accepter X Voter X Accepter X Voter Oui Accepter X Voter Oui Voter Oui (c) 3 4 2 1 5 7 6 Accepter X Accepter X Accepter X Voter Oui Accepter X Accepter X Voter Oui (d) 3 4 2 1 5 7 6 Accepter X Voter X Accepter X Accepter X Accepter X Accepter X Accepter X (e) Figure 2. Effet cascade dans le vote fédéré. Chaque nœud possède une tranche de quorum indiquée par des flèches vers les membres de la tranche. (a) Des déclarations contradictoires X et Y sont introduites. (b) Les nœuds votent pour des déclarations valides. (c) Le nœud 1 accepte X après son quorum {1, 2, 3, 4} vote à l'unanimité pour X. (d) Les nœuds 1, 2, 3 et 4 acceptent tous X ; l'ensemble {1} est 5-bloquant, donc le nœud 5 accepte X, annulant son vote précédent pour Y. (e) L'ensemble {5} est bloquant 6 et 7, donc 6 et 7 acceptent tous deux X. nœud non défectueux qui ne pouvait pas accepter de déclarations contradictoires. La confirmation d'une déclaration n'est pas garantie : en En cas de vote partagé, les deux déclarations peuvent être définitivement coincé dans l'attente du quorum lors de la phase de vote. Cependant, si un nœud dans un ensemble intact I confirme une affirmation, la cascade théorème et accepter le cas 2 garantir que tout je finirai par confirmer cette affirmation. 3.2.4 Synchronisation des bulletins de vote Si les nœuds ne sont pas en mesure de confirmer une instruction de validation pour le scrutin en cours, ils abandonnent après un temps mort. Le délai d'attente devient plus longtemps à chaque scrutin afin de s'ajuster à des limites arbitraires sur le retard du réseau. Cependant, les délais d'attente ne suffisent pas à eux seuls à synchroniser les scrutins des nœuds qui n'ont pas démarré en même temps ou qui n'ont pas démarré en même temps. a été désynchronisé pour d'autres raisons. Pour réaliser la synchronisation, les nœuds démarrent le temporisateur uniquement lorsqu'ils font partie d'un quorum atteint lors du scrutin en cours (ou ultérieur) n. Ceci ralentit les nœuds qui ont démarré tôt et garantit qu'aucun un membre d'un ensemble intact reste trop en avance sur le groupe. De plus, si un nœud v remarque un v-blocage défini ultérieurement scrutin, il passe immédiatement au scrutin le plus bas de telle sorte que celui-ci ce n'est plus le cas, quelles que soient les minuteries. La cascade Le théorème garantit alors que tous les retardataires rattrapent leur retard. Le résultat est que les bulletins de vote sont à peu près synchronisés dans un pays intact défini une fois que le système devient synchrone. 3.2.5 Sélection des leaders fédérés La sélection des leaders permet à chaque nœud de choisir des leaders de manière façon dont les nœuds n'en choisissent généralement qu'un ou un petit nombre de dirigeants. Pour s'adapter à l'échec du leader, sélection du leader se déroule par tours. Si les leaders du tour en cours semblent ne pas s'acquitter de leurs responsabilités, puis après un certains nœuds de délai d'attente passent au tour suivant pour élargir l'ensemble des dirigeants qu'ils suivent. Chaque tour utilise deux fonctions cryptographiques uniques hash, H0 et H1, qui génèrent des entiers dans la plage [0,hmax). Par exemple, Stellar utilise Hi(m) = SHA256(i∥b∥r ∥m), où b est l'instance SCP globale (numéro de bloc ou de grand livre), r est le numéro du tour de sélection du leader, et hmax = 2256. Dans un tour, nous définissons la priorité du nœud v comme : priorité(v) = H1(v) Un homme de paille serait choisi pour chaque nœud comme leader le nœudv avec la priorité la plus élevée (v). Cette approche fonctionne bien avec des tranches de quorum presque identiques, mais pas correctement capturer l’importance des nœuds dans les configurations déséquilibrées. Par exemple, si l’Europe et la Chine contribuent chacune à hauteur de 3 nœuds à chaque quorum, mais la Chine gère 1 000 nœuds et l'Europe 4, alors la Chine aura le nœud le plus prioritaire 99,6 % de l'époque. Nous introduisons donc une notion de poids de tranche, où poids(u,v) ∈[0, 1] est la fraction des tranches de quorum du nœud u contenant le nœud v. Lorsque le nœud u sélectionne un nouveau leader, il ne considère que les voisins, définis comme suit : voisins (u) = { v | H0(v) < hmax · poids(u,v) } Un nodeu commence alors avec un ensemble vide de leaders, et à chaque round lui ajoute le nœud v des voisins(u) de plus haut priorité(v). Si l'ensemble des voisins est vide à n'importe quel tour, u ajoute à la place le nœudv avec la valeur la plus basse de H0(v)/weight(u,v).

Vérification formelle du SCP

Pour éliminer les erreurs de conception, nous avons formellement vérifié la sécurité de SCP et propriétés de vivacité (voir [65]). Plus précisément, nous avons vérifié que les nœuds entrelacés ne sont jamais en désaccord et que, dans les conditions discutées ci-dessous, chaque membre d'un ensemble intact finit par décider. Il est intéressant de noter que la vérification a révélé que les conditions dans lesquelles SCP garantit la vivacité sont subtiles, et plus fort qu'on ne le pensait initialement [68] : comme indiqué ci-dessous, nœuds malveillants qui manipulent le timing sans autrement tout écart par rapport au protocole devra peut-être être expulsé manuellement from quorum slices.

SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Lokhava et al. Pour garantir que les propriétés se sont avérées valables dans toutes les conditions possibles Configurations et exécutions FBA, nous considérons un arbitraire nombre de nœuds avec des configurations locales arbitraires. Ceci inclut des scénarios avec des ensembles intacts disjoints, ainsi que des exécutions potentiellement infinies. L'inconvénient est que nous faire face au problème difficile de la vérification d'un paramètre système à états infinis. Pour que la vérification reste réalisable, nous avons modélisé SCP en logique du premier ordre (FOL) en utilisant Ivy [69] et la méthodologie de [82]. Le processus de vérification consiste à fournir manuellement des conjectures inductives qui sont ensuite automatiquement vérifiées par Ivy. Le modèle FOL de SCP résume certains aspects de Les systèmes Expédié par Amazon difficiles à gérer en FOL (par exemple, le le théorème de cascade est pris comme un axiome), nous vérifions donc le solidité de l'abstraction à l'aide d'Isabelle/HOL [75]. Après avoir exprimé le problème de vérification en FOL, nous vérifions la sécurité en fournissant un invariant inductif. L'inductif invariant se compose d'une douzaine de conjectures sur une seule ligne pour environ 150 lignes de spécification de protocole. Nous spécifions ensuite les propriétés de vivacité de SCP dans la logique temporelle linéaire d'Ivy et utilisons la vivacité à une réduction de sécurité de [80, 81] pour réduire la vivacité problème de vérification au problème de trouver un inductif invariant. Bien que la sécurité de SCP soit relativement simple à prouver, l’argument de la vivacité de SCP est beaucoup plus complexe et se compose d’environ 150 invariants sur une seule ligne. Prouver la vivacité nécessitait une formalisation précise du hypothèses selon lesquelles SCP assure la résiliation. Nous pensions initialement qu'un ensemble intact serait toujours terminé si tous les membres ont supprimé les nœuds défectueux de leurs tranches [68]. Mais cela s'est avéré insuffisant : une personne bien élevée (mais pas intact) nœud dans un quorum d’un membre du Je peux, sous le influence de nœuds défectueux, empêcher la résiliation en complétant un quorum juste avant la fin d'un scrutin, provoquant ainsi les membres de I choisiront différentes valeurs de x lors du prochain scrutin. Nous devons donc en outre supposer que, de manière informelle, chaque nœud d'un quorum d'un membre de I éventuellement soit devient opportun ou n’envoie pas de messages du tout pendant une période suffisante. En pratique, cela signifie que les membres de I may doivent ajuster leurs tranches jusqu'à ce que la condition soit respectée. Ceci le problème n’est pas inhérent aux systèmes Expédié par Amazon : Losa et al. [47] présent un protocole dont la vivacité dépend du strictement plus faible hypothèses d'une éventuelle synchronisation et d'une éventuelle élection du leader, sans qu'il soit nécessaire de supprimer les nœuds défectueux des tranches.

Réseau de paiement

Cette section décrit le réseau de paiement de Stellar, implémenté en tant que machine à états répliquée [88] au-dessus de SCP. 5.1 Modèle de grand livre Le grand livre de Stellar est conçu autour d'une abstraction de compte (en contrairement à la sortie de transaction non dépensée plus centrée sur les pièces ou modèle UTXO de Bitcoin). Le contenu du grand livre se compose d'un ensemble d'écritures comptables de quatre types distincts : comptes, lignes de confiance, offres et données de compte. Les comptes sont les principaux qui possèdent et émettent des actifs. Chacun le compte est nommé par une clé publique. Par défaut, la clé privée correspondante peut signer les transactions pour le compte. Cependant, les comptes peuvent être reconfigurés pour ajouter d'autres signataires et annuler l'autorisation de la clé qui nomme le compte, avec un Option « multisig » pour exiger plusieurs signataires. Chaque compte contient également : un numéro de séquence (inclus dans les transactions pour éviter les rediffusions), quelques flags, et un solde en mode « natif » crypto-monnaie pré-exploitée appelée XLM, destinée à atténuer certaines attaques par déni de service et faciliter la tenue de marché comme monnaie neutre. Les lignes de confiance suivent la propriété des actifs émis, qui sont nommé par une paire composée du compte émetteur et d'un short code d'actif (par exemple, « USD » ou « EUR »). Chaque ligne de confiance précise un compte, un actif, le solde du compte dans cet actif, un limite au-dessus de laquelle le solde ne peut pas monter, et quelques drapeaux. Un compte doit consentir explicitement à la détention d'un actif par créer une ligne de confiance, empêchant les spammeurs de s'en prendre à vous comptes avec des actifs indésirables. Les réglementations de connaissance du client (KYC) exigent que de nombreuses institutions financières sachent quels dépôts elles détiennent, par exemple en vérifiant une pièce d'identité avec photo. Pour se conformer, les émetteurs peuvent définir un indicateur auth_reqired facultatif sur leurs comptes, limitant la propriété des actifs qu'ils émettent aux comptes autorisés. Pour accorder une telle autorisation, l'émetteur fixe un signaler sur les lignes de confiance des clients. Les offres correspondent à la volonté d’un compte d’échanger à un certain montant d'un actif particulier pour un autre à un moment donné prix sur le carnet de commandes ; ils sont automatiquement mis en correspondance et rempli lorsque les prix d’achat/vente se croisent. Enfin, les données du compte sont constituées de triplets de compte, de clé et de valeur, permettant aux titulaires de compte pour publier de petites valeurs de métadonnées. Pour éviter le spam du grand livre, il existe un solde XLM minimum, appelé la réserve. La réserve d’un compte augmente à chaque fois écriture comptable associée et diminue lorsque l'écriture comptable disparaît (par exemple, lorsqu'une commande est exécutée ou annulée, ou lorsqu'un la ligne de confiance est supprimée). Actuellement, la réserve augmente de 0,5 XLM (∼0,03 $) par écriture au grand livre. Quelle que soit la réserve, c'est possible de récupérer la totalité de la valeur d'un compte en supprimant avec une opération AccountMerge. Un en-tête de grand livre, illustré à la figure 3, stocke les attributs globaux : un numéro de grand livre, des paramètres tels que le solde de réserve par écriture comptable, un hash de l'en-tête comptable précédent (en fait plusieurs hashes formant une liste de saut), la sortie SCP comprenant un hash de nouvelles transactions appliquées à ce grand livre, un hash de les résultats de ces transactions (par exemple, le succès ou l'échec de chacun) et un instantané hash de toutes les écritures du grand livre. Étant donné que l'instantané hash inclut tout le contenu du grand livre, Les validator n'ont pas besoin de conserver l'historique pour valider les transactions. Cependant, pour atteindre les centaines de millions de comptes, nous ne pouvons pas rehash toutes les tables d'écriture du grand livre sur chaque clôture du grand livre. De plus, il n'est pas pratique de transférer un grand livrePaiements internationaux rapides et sécurisés avec Stellar SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada numéro de grand livre = 4 H (HDR précédent) Sortie SCP H∗(résultats) H∗(instantané) ... en-tête numéro de grand livre = 5 H (HDR précédent) Sortie SCP H∗(résultats) H∗(instantané) ... en-tête . . . Figure 3. Contenu du grand livre. H est SHA-256, tandis que H ∗ représente une application hiérarchique ou récursive de H. Sortie SCP dépend aussi de l'en-tête précédent hash. Créer un compte Créer et financer une nouvelle écriture de compte Fusion de comptes Supprimer l'écriture comptable du compte Définir les options Modifier les indicateurs de compte et les signataires Paiement Payez une quantité spécifique d'actif à destination. compte. CheminPaiement Comme le paiement, mais payez avec un actif différent (jusqu'à limiter); spécifier jusqu'à 5 actifs intermédiaires Gérer l'offre Créer/supprimer/modifier une entrée au grand livre d'offre, -Offre Passive avec variante passive pour permettre un spread nul Gérer les données Créer/supprimer/modifier un compte. saisie de données au grand livre ChangerConfiance Créer/supprimer/modifier une ligne de confiance Autoriser la confiance Définir ou effacer l'indicateur autorisé sur la ligne de confiance Séquence de bosses Augmenter séq. numéro de compte Figure 4. Principales opérations du grand livre de cette taille chaque fois qu'un nœud a été déconnecté de le réseau depuis trop longtemps. L'instantané hash est donc conçu pour optimiser à la fois le hashing et la réconciliation de l’État. Plus précisément, l'instantané stratifie les écritures du grand livre par heure de la dernière modification dans un ensemble de conteneurs de taille exponentielle appelés seaux. La collection de buckets est appelée le bucket liste, et présente une certaine similitude avec les arbres de fusion structurés en journaux (Arbres LSM) [77]. La bucket list n'est pas lue pendant le traitement de la transaction (voir Section 5.4). Par conséquent, certaines conceptions certains aspects des arbres LSM peuvent être assouplis. En particulier, aléatoire l'accès par clé n'est pas requis et les compartiments ne sont que lus séquentiellement dans le cadre de la fusion des niveaux. Hacher le seau La liste est effectuée en hashing chaque compartiment au fur et à mesure de sa fusion et en calculant un nouveau hash cumulatif du bucket hashes (un petit, indice fixe de référence hashes) à chaque clôture du grand livre. La réconciliation de la bucket list après la déconnexion nécessite un téléchargement seulement des seaux qui diffèrent. 5.2 Modèle de transaction Une transaction se compose d'un compte source, de critères de validité, d'un mémo et une liste d’une ou plusieurs opérations. La figure 4 répertorie les opérations disponibles. Chaque opération possède un compte source, qui par défaut, celui de la transaction globale. Une transaction doit être signé par des clés correspondant à chaque compte source dans une opération. Les comptes Multisig peuvent nécessiter une signature plus élevée poids pour certaines opérations (telles que SetOptions) et inférieur pour d'autres (comme AllowTrust). Les transactions sont atomiques : si une opération échoue, aucune des opérations les exécuter. Cela simplifie les transactions multidirectionnelles. Supposons qu'un l'émetteur crée un actif pour représenter les titres de propriété et l'utilisateur A veut échanger une petite parcelle de terrain plus 10 000 $ contre un parcelle de terrain plus grande appartenant à B. Les deux utilisateurs peuvent tous deux signer une seule transaction contenant trois opérations : deux terrains paiements et paiement d’un dollar. Le principal critère de validité d’une transaction est son numéro d’ordre, qui doit être supérieur de un à celui du numéro de séquence de la transaction. écriture comptable du compte source. Exécuter une transaction valide (avec succès ou non) incrémente le numéro de séquence, empêchant la relecture. Les numéros de séquence initiaux contiennent le grand livre numéro dans les bits hauts pour empêcher la relecture même après la suppression et recréer un compte. L'autre critère de validité est une limite facultative quant au moment où une transaction peut s’exécuter. Retour à la terre et au dollar swap ci-dessus, si A signe la transaction avant B, A ne peut pas veut que B reste assis sur la transaction pendant un an avant de la soumettre cela, et pourrait ainsi imposer un délai invalidant la transaction après quelques jours. Les comptes Multisig peuvent également être configurés donner un poids de signature à la révélation d'une pré-image hash, ce qui, combiné à des limites de temps, permet le trading atomique crosschain [1]. Le compte source d'une transaction paie des frais insignifiants en XLM, 10−5 XLM sauf en cas de congestion. En période de congestion, le le coût des opérations est fixé par les enchères néerlandaises. Les validateurs sont non compensé par des frais car les validator sont analogues aux nœuds complets Bitcoin, pas aux mineurs. Plutôt que de détruire XLM, les frais sont recyclés et répartis proportionnellement par vote du les détenteurs XLM existants, qui, rétrospectivement, pourraient ou pourraient cela ne valait pas la complexité. 5.3 Valeurs consensuelles Pour chaque grand livre, Stellar utilise SCP pour convenir d'une structure de données avec trois champs : un ensemble de transactions hash (incluant un hash de l'en-tête du référentiel précédent), une heure de clôture, uned mises à niveau. Lorsque plusieurs valeurs sont confirmées, Stellar prend l'ensemble de transactions avec le plus d'opérations (rupture des liens par frais totaux, puis ensemble de transactions hash), l'union de tous mises à niveau et temps de fermeture le plus élevé. Une heure de fermeture est seulement valable s'il est compris entre l'heure de clôture du dernier référentiel et le présents, afin que les nœuds ne nomment pas d'heures invalides. Les mises à niveau ajustent les paramètres globaux tels que le solde de réserve, les frais de fonctionnement minimum et la version du protocole. Quand combinés lors de la nomination, les frais plus élevés et les numéros de version du protocole remplacent les plus bas. Les mises à niveau affectent la gouvernance à travers un espace de lutte avec vote fédéré [34], ni l'un ni l'autre égalitaire ni centralisé. Chaque validator est configuré comme soit gouvernant, soit non gouvernant (par défaut), selon à savoir si son opérateur souhaite participer à la gouvernance. Les validator gouvernants envisagent trois types de mise à niveau : souhaité, valide et invalide (tout ce que le validator ne fait pas

SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Lokhava et coll. validator noyau horizon FS Base de données Base de données soumettre client client autres validator Figure 5. Architecture Stellar validator savoir mettre en œuvre). Les mises à niveau souhaitées sont configurées pour déclenchement à un moment précis, destiné à être coordonné entre opérateurs. Les nœuds dirigeants votent toujours pour nommer les candidats souhaités. mises à niveau, acceptez mais ne votez pas pour proposer des mises à niveau valides (c'est-à-dire, acceptez un quorum bloquant) et ne votez jamais pour ou acceptez les mises à niveau non valides. Écho de validators non gouvernementaux tout vote qu'ils voient pour une mise à niveau valide, déléguant essentiellement la décision sur les mises à niveau souhaitées pour ceux qui optent pour un rôle de gouvernance. 5.4 Mise en œuvre La figure 5 montre l'architecture validator de Stellar. Un démon appelé stellar-core (∼92 000 lignes de C++, sans compter les bibliothèques tierces) implémente le protocole SCP et la machine à états répliquée. La production de valeurs pour SCP nécessite de réduire un grand nombre d'écritures comptables à de petites écritures cryptographiques. hashes. En revanche, la validation et l'exécution des transactions nécessite de rechercher l'état du compte et la correspondance des commandes sur le meilleur prix. Pour remplir efficacement ces deux fonctions, Stellar-Core conserve deux représentations du grand livre : une représentation externe contenant la bucket list, stockée sous forme de fichiers binaires qui peut être mis à jour efficacement et réhashed progressivement, et une représentation interne dans une base de données SQL (PostgreSQL pour les nœuds de production). Stellar-core crée une archive d'historique en écriture seule contenant chaque ensemble de transactions confirmé et des instantanés de seaux. L'archive permet aux nouveaux nœuds de s'amorcer eux-mêmes en rejoignant le réseau. Il fournit également un enregistrement du grand livre histoire - il doit y avoir un endroit où l'on peut rechercher une transaction d’il y a deux ans. Puisque l'historique est uniquement ajouté et rarement consulté, il peut être conservé dans des endroits bon marché comme Amazon Glacier ou tout service permettant de stocker et récupérer des fichiers plats. Les hôtes du validateur n'hébergent généralement pas leurs propres archives afin d'éviter tout impact sur la validation performance de l’histoire de service. Pour garder le noyau stellaire simple, il n'est pas destiné à être utilisé directement par les applications et n'expose qu'une interface très étroite pour la soumission de nouvelles transactions. Pour soutenir clients, la plupart des validator exécutent un démon appelé horizon (∼18k lignes de Go) qui fournit une interface HTTP pour la soumission et l'apprentissage des transactions. horizon a un accès en lecture seule à base de données SQL de Stellar-Core, minimisant le risque d'horizon noyau stellaire déstabilisant. Des fonctionnalités telles que la recherche du chemin de paiement sont entièrement mises en œuvre à Horizon et peuvent être mises à niveau unilatéralement sans coordination avec les autres validator. Plusieurs démons facultatifs de couche supérieure sont des clients à horizon, complétant l’écosystème. Un serveur pont facilite intégration de Stellar avec les systèmes existants, par exemple, publication de notifications de tous les paiements reçus par un compte spécifique. Un le serveur de conformité fournit des points d'ancrage aux institutions financières pour échanger et approuver les informations sur l’expéditeur et le bénéficiaire sur les paiements, pour le respect des listes de sanctions. Enfin, un serveur de fédération implémente une dénomination lisible par l'homme système de comptabilité. 6 Expérience de déploiement Stellar s'est développé pendant plusieurs années pour devenir un État à nombre d’opérateurs de nœuds complets raisonnablement fiables. Cependant, les configurations des nœuds étaient telles que la vivacité (mais pas sécurité) dépendait de nous, la Stellar Fondation de Développement (SDF); Si SDF avait soudainement disparu, d'autres opérateurs de nœuds il aurait fallu intervenir et nous supprimer manuellement à partir des tranches de quorum pour que le réseau puisse continuer. Alors que nous et beaucoup d’autres souhaitons réduire l’importance systémique du SDF, cet objectif a reçu une priorité croissante après Les chercheurs [58] ont quantifié et rendu public la centralisation du réseau sans différencier les risques pour la sécurité et la sécurité. vivacité. Un certain nombre d'opérateurs ont réagi en ajustant activement la configuration, principalement en augmentant la taille de leur des tranches de quorum dans le but de diluer l’importance du SDF ; ironiquement, cela n'a fait qu'augmenter le risque pour la vitalité. Deux problèmes ont aggravé la situation. Tout d'abord, un populaire L'outil de surveillance tiers Stellar [5] a été systématiquement surestimer la disponibilité de validator en ne vérifiant pas réellement ce noyau stellaire fonctionnait ; cela amène les gens à inclure nœuds peu fiables dans leurs tranches de quorum. Deuxièmement, un bug dans stellar-core signifiait qu'une fois qu'un validator était passé au registre suivant, cela n'a pas suffisamment aidé les nœuds restants à terminer la précédenteun grand livre en cas de perte de messages. En conséquence, le Le réseau a connu 67 minutes d'indisponibilité et a nécessité coordination manuelle par les administrateurs validator pour redémarrer. Pire encore, lors de la tentative de redémarrage du réseau, des reconfigurations précipitées simultanées sur plusieurs nœuds ont entraîné des reconfigurations précipitées simultanées sur plusieurs nœuds. dans une mauvaise configuration collective qui a permis à certains nœuds de diverger, nécessitant un arrêt manuel de ces nœuds et resoumission des transactions acceptées lors de la divergence. Heureusement, cette divergence a été détectée et corrigée rapidement et ne contenait aucune transaction conflictuelle, mais le risque que le réseau ne parvienne pas à bénéficier de l'intersection du quorum : se diviser tout en continuant à accepter des situations potentiellement conflictuelles transactions, simplement en raison d'une mauvaise configuration, a été effectuée très concret par cet incident. L’examen de ces expériences a conduit à deux conclusions majeures et les actions correctives correspondantes.Paiements mondiaux rapides et sécurisés avec Stellar SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Critique, 100% 51% 51% Élevé, 67 % 51% Moyen, 67 % 51% Faible, 67 % 51% 51% ... ... ... 51% ... 51% Figure 6. Hiérarchie de qualité du validateur. Nœuds de la plus haute qualité nécessitent le seuil le plus élevé de 100 %, tandis que les qualités inférieures sont configurées au seuil de 67 %. Nœuds au sein d'un même l’organisation requiert une majorité simple de 51 %. 6.1 Complexité et fragilité de la configuration Stellar exprime les tranches de quorum sous forme d'ensembles de quorum imbriqués composés de n entrées et d'un seuil k où tout ensemble de k entrées constitue une tranche de quorum. Chacune des n entrées est alors soit une clé publique validator ou, récursivement, un autre ensemble de quorum. Bien que flexibles et compacts, nous avons réalisé un quorum imbriqué ensembles offraient simultanément aux opérateurs de nœuds trop de flexibilité et trop peu de conseils : il était facile d'écrire de manière non sécurisée (ou voire absurdes). Les critères de regroupement nœuds en ensembles, pour organiser les sous-ensembles dans une hiérarchie, et les choix des seuils n’étaient pas tous suffisamment clairs et ont contribué à des échecs opérationnels. Il n'était pas clair s'il fallait traiter un « niveau » dans la hiérarchie imbriquée comme un niveau de confiance, ou une organisation, ou les deux ; de nombreuses configurations sur le terrain mélangé ces concepts, en plus de préciser les dangers ou des seuils dénués de sens. Nous avons donc ajouté un mécanisme de configuration plus simple qui sépare deux aspects des ensembles de quorum imbriqués : le regroupement nœuds regroupés par organisation et étiquetant chaque organisation avec une classification de confiance simple (faible, moyenne, élevée ou critique). Les organisations de niveau élevé et supérieur sont tenues de publier des archives historiques. Le nouveau système synthétise des ensembles de quorum imbriqués dans lesquels chaque organisation est représentée comme un Un seuil de 51 % est défini et les organisations sont regroupées en ensembles avec des seuils de 67% ou 100% (selon la qualité du groupe). Chaque groupe est une entrée unique dans le groupe suivant (de qualité supérieure), comme illustré à la figure 6. Ce modèle simplifié réduit le probabilité de mauvaise configuration, tant en termes de structure des ensembles imbriqués synthétisés et des seuils choisis pour chaque ensemble. 6.2 Détection proactive des erreurs de configuration Deuxièmement, nous avons réalisé qu’il était trop tard pour détecter une mauvaise configuration collective en attendant d’observer ses effets négatifs. Surtout en ce qui concerne les erreurs de configuration qui peuvent diverger - un mode de défaillance plus grave que l'arrêt : le réseau a besoin être capable de détecter immédiatement une mauvaise configuration afin que les opérateurs puissent y remédier avant qu'une divergence ne se produise réellement. Pour répondre à ce besoin, nous avons intégré un mécanisme dans le logiciel validator qui rassemble en permanence l'état de configuration collective de tous les pairs dans la fermeture transitive du nœud et détecte le potentiel de divergence, c'est-à-dire disjoint. quorums – au sein de cette configuration collective. 6.2.1 Vérification de l'intersection du quorum Bien que rassembler des tranches de quorum soit facile, trouver des quorums disjoints parmi elles est co-NP-difficile [62]. Cependant, nous avons adopté un ensemble d'heuristiques algorithmiques et de règles d'élimination de cas proposé par Lachowski [62] qui vérifie les instances typiques du problème plusieurs ordres de grandeur plus rapidement que le coût dans le pire des cas. En pratique, le réseau actuel les fermetures transitives des tranches de quorum sont de l’ordre de 20 à 30 nœuds et, avec les optimisations de Lachowski, vérifient généralement en quelques secondes sur un seul processeur. Si le besoin s'en fait sentir pour améliorer les performances, nous pouvons paralléliser la recherche. 6.2.2 Vérification des configurations à risque Détecter que le réseau admet des quorums disjoints est une étape dans la bonne direction, mais signale le danger trop tard pour une question aussi cruciale. Idéalement, nous souhaitons que les opérateurs de nœuds reçoivent des avertissements lorsque la configuration collective du réseau s’approche simplement d’un état à risque. Nous avons donc étendu le vérificateur d'intersection de quorum pour détecter une condition que nous appelons criticité : lorsque le courant la configuration collective est à une mauvaise configuration de un État qui admet des quorums disjoints. Pour détecter la criticité, le vérificateur remplace à plusieurs reprises la configuration de chaque organisation par une mauvaise configuration simulée dans le pire des cas, puis réexécute le vérificateur d’intersection de quorum interne sur le résultat. Si une telle mauvaise configuration critique existe à une étape à partir de l'état actuel, le logiciel émet un avertissement et signale que l'organisation présente un risque de mauvaise configuration. Ces changements donnent à la communauté des opérateurs deux niveaux de préavis et de conseils pour se prémunir contre les pires formes de mauvaise configuration collective.

Évaluation

Comprendre l’adéquation de Stellar en tant que paiement global et réseau commercial, nous avons évalué l'état du réseau public et mené des expériences contrôlées sur un laboratoire expérimental privé réseau. Nous nous sommes concentrés sur les questions suivantes : • À quoi ressemble la topologie du réseau de production ? Combien de messages sont diffusés en moyenne, et comment SCP subit-il les délais d'attente ? • Les latences de consensus et de mise à jour du grand livre restent-elles indépendantes du nombre de comptes ?SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Lokhava et coll. • Comment les latences sont-elles affectées par l'augmentation (a) des transactions par seconde (et, par conséquent, des transactions par seconde) ? grand livre), et (b) le nombre de nœuds validator ? • Quel est le coût de fonctionnement d'un nœud en termes de CPU, mémoire et bande passante réseau ? Les réseaux de paiement ont des taux de transaction faibles par rapport à d’autres types de systèmes distribués. Les principaux blockchain, Bitcoin et Ethereum, confirment jusqu'à 15 transactions/seconde, inférieur à Stellar. De plus, ces systèmes prennent quelques minutes pour une heure pour confirmer une transaction en toute sécurité, car la preuve de travail nécessite d'attendre plusieurs blocs pour être extraits. Le Le réseau SWIFT non blockchain n'a enregistré en moyenne que 420 transactions par seconde lors de sa journée de pointe [14]. Nous avons donc choisi pour comparer nos mesures par rapport à l'objectif de 5 secondes intervalle du grand livre, un objectif plus agressif. Nos résultats montrent que les latences sont confortablement inférieures à cette limite, même avec plusieurs optimisations non implémentées sont toujours en cours. 7.1 Ancres Les actifs les plus négociés en volume incluent la devise (par exemple, 3 USD ancres, 2 CNY), une ancre Bitcoin, un titre adossé à l'immobilier token [92] et une devise intégrée à l'application [8]. Différentes ancres ont des politiques différentes. Par exemple, une ancre en USD, Stronghold, définit auth_reqired et nécessite un processus de connaissance du client (KYC) pour chaque compte qui détient son actifs. Un autre, AnchorUSD, permet à tout le monde de recevoir et d'échanger leur USD (ce qui permet littéralement d'envoyer 0,50 $ au Mexique en 5 secondes avec des frais de 0,000001 $). Cependant, AnchorUSD nécessite un KYC et des frais pour acheter ou échanger leurs USD avec des virements électroniques classiques. Aux Philippines, où les réglementations bancaires sont plus laxistes pour les paiements entrants, coins.ph prend en charge l'encaissement de PHP sur n'importe quel guichet automatique [36]. En plus des token de sécurité susmentionnés et de la devise de l'application, il existe une gamme de token non monétaires allant de obligations commerciales [22] et crédits carbone [85, 96] à plus des actifs ésotériques tels qu'un token collaboratif incitatif reprise de possession de voiture [35]. 7.2 Réseau public Au moment d'écrire ces lignes, il existe 126 nœuds complets actifs, dont 66 participer au consensus en signant les messages de vote. Figure 7 (généré par [5]) visualise le réseau, avec une ligne entre deux nœuds si l’un apparaît dans les tranches de quorum de l’autre et un ligne bleue plus foncée pour montrer la dépendance bidirectionnelle. Au Le centre est un groupe de 17 « validators » de facto gérés par SDF, SatoshiPay, LOBSTR, COINQVEST et Keybase. Il y a quatre mois, avant les événements de la Section 6, il y avait il y avait 15 nœuds d'importance systémique : 3 provenant apparemment organisations de premier niveau et plusieurs singletons aléatoires. Le le graphique semblait également beaucoup moins régulier. Par conséquent, le nouveau mécanisme de configuration et/ou de meilleures décisions des opérateurs semblent contribuer à une topologie de réseau plus saine. Sans d'excellentes ressources financières (et un actionnaire correspondant Figure 7. Carte des tranches de quorum obligations), il aurait été difficile de recruter 5 tier one organisations dès le départ. Cela suggère un quorum les tranches jouent un rôle utile dans l'amorçage du réseau : n'importe qui peut rejoindre avec l'objectif de devenir un acteur important car il n’y a pas de gardiens à l’accord par paires. Il y a actuellement plus de 3,3 millions de comptes dans le grand livre. Fini sur une période récente de 24 heures, Stellar a réalisé en moyenne 4,5 transactions et 15,7 opérations par seconde. En examinant les registres récents, la plupart les transactions semblent avoir une seule opération, alors que toutes les quelques grands livres, nous voyons des transactions contenant de nombreuses opérations qui semblent provenir des teneurs de marché gérant les offres. Le les délais moyens pour parvenir à un consensus et mettre à jour le grand livre étaient 1061 ms et 46 ms, respectivement. Les 99e percentiles étaient 2252 ms et 142 ms (le premier reflétant un délai d'attente d'une seconde dans la sélection des chefs de file des nominations). Notez que les performances de SCP sont principalement indépendant des transactions par seconde, puisque SCP s'entend sur un hash de transactions arbitrairement nombreuses. Les goulots d'étranglement sont plus susceptibles de provenir de la propagation des candidats transactions lors de la nomination, de l’exécution et de la validation transactions et fusion de compartiments. Nous n'avons pas encore eu besoin pour paralléliser le traitement des transactions de Stellar-Core sur plusieurs cœurs de processeur ou lecteurs de disque. Nous avons également évalué le nombre de messages SCP diffusés sur le réseau de production. Dans le cas normal avec un seul leader élu pour désigner une valeur, nous nous attendons à sept logiques messages à diffuser : deux messages pour voter et accepter un nomidéclaration nate, deux messages pour accepter et confirmer une instruction de préparation, deux messages pour accepter et confirmer une instruction de validation et enfin un message d'externalisation (envoyé après avoir validé un nouveau registre sur le disque pour aider les retardataires rattraper). L'implémentation combine confirmer le commit et externaliser les messages comme une optimisation, car c'est il est sûr d’externaliser une valeur après son engagement. Nous analysons ensuite les métriques recueillies sur une production Stellar validator. Fini en 68 heures, 1,3 messages/seconde ont été émis, en moyenne 6 à 7 messages par registre. Nous notons que le total

Paiements internationaux rapides et sécurisés avec Stellar SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Centile Nombre de délais d'attente Nomination Vote 75% 0 0 99% 1 0 Max. 4 1 Figure 8. Délais d'attente par grand livre sur 68 heures le nombre de messages diffusés par validators est plus grand, car dans En plus des messages de vote fédérés, les nœuds diffusent également toutes les transactions dont ils ont connaissance. La figure 8 montre les délais d'attente rencontrés par une production validator sur une période de 68 heures. Les délais de nomination sont une mesure de l’(in)efficacité de la fonction d’élection des dirigeants, alors que les délais d’attente des votes dépendent fortement du réseau et les retards potentiels des messages. Les délais d'attente sont cohérents avec le nombre de messages émis : six messages dans le dans le meilleur des cas, et au moins sept messages si un tour de nomination supplémentaire est nécessaire. 7.3 Expériences contrôlées Nous avons mené des expériences contrôlées dans des conteneurs emballés sur Instances Amazon EC2 c5d.9xlarge avec 72 Gio de RAM, 900 Go de SSD NVMe et 36 vCPU. Chaque instance était dans la même région EC2 et avait une bande passante fixe de 10 Gbit/s. Nous avons utilisé SQLite comme magasin. (Stellar prend également en charge PostgreSQL, mais cela comporte des tâches asynchrones qui injectent du bruit dans les mesures.) Stellar fournit une requête d'exécution intégrée, generateload, qui permet de générer une charge synthétique sur une cible spécifique transaction/second taux. Bien que Stellar prenne en charge divers fonctionnalités de trading, telles que le carnet d'ordres et le parcours multi-actifs paiements, nous nous sommes concentrés sur les paiements simples. La confirmation des transactions comprend plusieurs étapes, nous enregistré les mesures pour chacun des éléments suivants : • Nomination : délai entre la nomination et la première préparation. • Vote : temps écoulé entre la première préparation et la confirmation d'un scrutin engagé • Mise à jour du grand livre : il est temps d'appliquer la valeur consensuelle • Nombre de transactions : transactions confirmées par grand livre Chacune de nos expériences a été définie par trois paramètres : le nombre d'écritures de compte dans le grand livre, le montant de charge (sous forme de paiements XLM) soumise par seconde, et le nombre de validator. Nous avons configuré chaque validator connaître tous les autres validator (le pire des cas pour SCP), avec des tranches de quorum fixées à une majorité simple de nœuds (afin de maximiser le nombre de quorums différents). Référence Notre expérience de base mesurait Stellar avec 100 000 comptes, quatre validator et la génération de charge taux de 100 transactions/seconde. Nous avons observé 507 transactions par grand livre en moyenne, avec un écart type de 49. (9,7%). Notez qu'aucune transaction n'a été abandonnée ; le léger 105 106 107 0 500 1 000 1 500 2 000 Comptes Latence [ms] Mise à jour du grand livre Vote Nomination Figure 9. Latence à mesure que le nombre de comptes augmente la variance est due aux limitations de planification du générateur de charge. Nous avons observé que le nombre de transactions par grand livre était cohérent avec notre taux de génération de charge, compte tenu du grand livre fermeture toutes les 5 secondes. Nomination, vote et grand livre la mise à jour a montré des latences moyennes de 82,53 ms, 95,96 ms et 174,08 ms, respectivement. Nous avons observé que la latence de nomination Le 99e centile est constamment inférieur à 61 ms, avec des des pics d'environ 1 seconde, correspondant à la première étape dans la fonction de timeout de sélection du leader. Compte tenu des performances de base, nous avons examiné les effets de faire varier chacun des paramètres de configuration du test. Comptes Les données de la figure 9 suggèrent que Stellar évolue ainsi que le nombre de comptes augmente. Génération de test les comptes sont devenus un processus long, à mesure que la création du compartiment et la fusion nous a empêché de simplement remplir la base de données avec des comptes directement via SQL. C'est pourquoi nous avons mené notre expériences pour un maximum de 50 000 000 de comptes. Alors qu'il y a impact minimal sur les latences de consensus et de mise à jour du grand livre, nous constatons que l'augmentation des comptes crée une surcharge de fusionner des buckets, qui deviennent plus grands. Taux de transactions Le taux de transaction a un impact sur le montant de multidiffusion du trafic entre validators, le nombre de transactions incluses dans chaque grand livre et la taille du niveau supérieur seaux. Comprendre les effets de l’augmentation des transactions charge, nous avons mené une expérience avec 100 000 comptes et 4 validator. La figure 10 montre une croissance lente de la latence du consensus, tandis que la majorité du temps était consacrée à la mise à jour du grand livre. Il n’est pas surprenant qu’à mesure que la taille de l’ensemble des transactions augmente, prend plus de temps pour le valider dans la base de données. Nous notons également que la latence de mise à jour du grand livre dépend fortement de la mise en œuvre, et est affecté par le choix de la base de données. Nœuds de validation Pour voir comment augmenter le nombre de validator tieronea un impact sur les performances, nous avons mené des expériences avec 100 000 comptes, 100 transactions/seconde et un nombre variable de validator de 4 à 43. Tous les validator sont apparus dans toutes les tranches de quorum de validator ; des tranches de quorum plus petites ont un moindre impact sur les performances.SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada Lokhava et coll. 100 150 200 250 300 350 0 500 1 000 1 500 2 000 Charger [transactions/seconde] Latence [ms] Mise à jour du grand livre Vote Nomination Figure 10. Latence à mesure que la charge de transaction augmente 10 20 30 40 0 500 1 000 1 500 2 000 Validateurs Latence [ms] Mise à jour du grand livre Vote Nomination Figure 11. Latence à mesure que le nombre de nœuds augmente Modification du nombre de nœuds de validation sur le réseau impacte le nombre de messages SCP échangés ainsi que le nombre de valeurs potentielles lors de la nomination. Figure 11 montre que le temps de nomination augmente à un rythme relativement faible. Même si les données suggèrent que le scrutin constitue le goulot d'étranglement, nous Je pense que de nombreux problèmes de mise à l'échelle peuvent être résolus en améliorant Réseau superposé de Stellar pour optimiser le trafic réseau. Comme attendu, la latence de mise à jour du grand livre est restée indépendante de le nombre de nœuds. Taux de clôture Enfin, nous voulions mesurer les performances de bout en bout de Stellar en mesurant la fréquence à laquelle les grands livres sont confirmés et si Stellar atteint son objectif de 5 secondes sans abandonnant toute transaction. Nous avons observé une clôture moyenne du grand livre des temps de 5,03 s, 5,10 s et 5,15 s à mesure que nous augmentions le compte entrées, taux de transaction et nombre de nœuds, respectivement. Les résultats suggèrent que Stellar peut clôturer systématiquement les grands livres sous forte charge. 7.4 Exécution d'un validator L'une des caractéristiques importantes de Stellar est le faible coût de exécuter un validator, car les ancres devraient exécuter (ou contracter avec) validators pour faire respecter le caractère définitif. SDF exécute 3 validator de production, tous sur des instances AWS c5.large, qui ont deux cœurs, 4 Go de RAM et processeur Intel(R) Xeon(R) Platinum 8124M @ Processeurs 3,00 GHz. Inspecter l'utilisation des ressources sur un de ces machines, nous avons observé le processus Stellar utilisant environ 7% du CPU et 300 Mo de mémoire. En termes de trafic réseau, avec 28 connexions aux pairs et une taille de quorum sur 34, les débits entrants et sortants étaient de 2,78 Mbit/s et 2,56 Mbit/s, respectivement. Matériel requis pour exécuter un tel le processus est peu coûteux. Dans notre cas, le coût est de 0,054$/heure soit environ 40$/mois. 7.5 Travaux futurs Ces expériences suggèrent que Stellar peut facilement faire évoluer 1 à 2 commandes d’ampleur au-delà de l’utilisation actuelle du réseau. Parce que le les exigences de performance ont été si modestes jusqu'à présent, Stellar laisse place à de nombreuses optimisations simples en utilisant techniques bien connues. Par exemple, les transactions et SCP les messages sont diffusés par validators à l'aide d'une inondation naïve protocole, mais devrait idéalement utiliser un protocole plus efficace et plus structuré. Multidiffusion peer-to-peer [30]. De plus, lourd en base de données Le temps de mise à jour du grand livre peut être amélioré grâce à des techniques standard de traitement par lots et de prélecture.

Conclusion

Les paiements internationaux sont chers et prennent des jours. Fonds la garde passe par plusieurs institutions financières, notamment des banques correspondantes et des services de transfert d'argent. Parce que chaque saut doit être pleinement fiable, il est difficile pour les nouveaux entrants pour gagner des parts de marché et être compétitifs. Stellar affiche comment envoyer de l'argent partout dans le monde à moindre coût en quelques secondes. Le L'innovation clé est un nouveau protocole d'accord byzantin à adhésion ouverte, SCP, qui exploite la structure peer-to-peer du réseau financier pour parvenir à un consensus mondial dans le cadre nouvelle hypothèse sur Internet. SCP permet à Stellar de s'engager atomiquement transactions irréversibles entre participants arbitraires qui ne se connaissent pas et ne se font pas confiance. Cela garantit à son tour l’accès des nouveaux entrants aux mêmes marchés que ceux établis. joueurs, permet d'obtenir en toute sécurité le meilleur échange disponible taux même de la part de teneurs de marché peu fiables, et de façon spectaculaire réduit la latence de paiement. Remerciements Stellar ne serait pas là où il est aujourd'hui sans le début le leadership de Joyce Kim ou les formidables contributions de Scott Fleckenstein et Bartek Nowotarski dans la construction et maintenir Horizon, le SDK Stellar et d'autres éléments clés de l’écosystème Stellar. Nous remercions également Kolten Bergeron, Henry Corrigan-Gibbs, Candace Kelly, Kapil K. Jain, Boris Reznikov, Jeremy Rubin, Christian Rudder, Eric Saunders, Torsten Stüber, Tomer Weller, les évaluateurs anonymes et notre berger Justine Sherry pour ses commentaires utiles sur versions antérieures. Avis de non-responsabilité La contribution du professeur Mazières à cette publication était à titre de consultant rémunéré et ne faisait pas partie de son mandat. Devoirs ou responsabilités de l'Université de Stanford.

Paiements mondiaux rapides et sécurisés avec Stellar SOSP '19, du 27 au 30 octobre 2019, Huntsville, ON, Canada