Protokol Konsensus Stellar

Zusammenfassung

Internationale Zahlungen sind langsam und teuer, was teilweise auf die Multi-Hop-Zahlungsweiterleitung über heterogene Systeme zurückzuführen ist Bankensysteme. Stellar ist ein neues globales Zahlungsnetzwerk das digitales Geld direkt überall in der Welt überweisen kann Welt in Sekunden. Die entscheidende Neuerung ist eine sichere Transaktion Mechanismus über nicht vertrauenswürdige Vermittler unter Verwendung eines neuen Byzantinisches Vereinbarungsprotokoll namens SCP. Mit SCP, jeweils Die Institution gibt andere Institutionen an, bei denen sie bleiben soll im Einvernehmen; durch die globale Vernetzung der Finanzsystem, das gesamte Netzwerk einigt sich dann auf Atomarität Transaktionen zwischen beliebigen Institutionen, ohne Solvenz- oder Wechselkursrisiko durch zwischengeschaltete Emittenten von Vermögenswerten oder Market Maker. Wir präsentieren SCPs Modell, Protokoll und formelle Überprüfung; Beschreiben Sie das Zahlungsnetzwerk Stellar; und schließlich Stellar empirisch durch Benchmarks bewerten und unsere Erfahrung aus mehrjährigem Produktionseinsatz. CCS-Konzepte • Sicherheit und Datenschutz → Verteilt Systemsicherheit; • Organisation von Computersystemen → Peer-to-Peer-Architekturen; • Informationssysteme → Elektronischer Geldtransfer. Schlüsselwörter blockchain, BFT, Quoren, Zahlungen ACM-Referenzformat: Marta Lokhava, Giuliano Losa, David Mazières, Graydon Hoare, Nicolas Barry, Eli Gafni, Jonathan Jove, Rafał Malinowsky, Jed McCaleb. 2019. Schnelle und sichere globale Zahlungen mit Stellar. Im SOSP ’19: Symposium zu Betriebssystemprinzipien, 27.–30. Oktober, 2019, Huntsville, ON, Kanada. ACM, New York, NY, USA, 17 Seiten. https://doi.org/10.1145/3341301.3359636

Einführung

Internationale Zahlungen sind bekanntermaßen langsam und kostspielig [32]. Bedenken Sie, dass es unpraktisch ist, 0,50 US-Dollar aus den USA nach zu senden *Galois, Inc. †UCLA Erlaubnis, digitale oder gedruckte Kopien des gesamten oder eines Teils dieser Arbeit anzufertigen Die persönliche oder unterrichtsbezogene Nutzung ist unentgeltlich gestattet, sofern dies bei Kopien nicht der Fall ist zu Gewinnzwecken oder kommerziellen Vorteilen hergestellt oder verbreitet werden und dass Kopien berechtigt sind Diese Mitteilung und das vollständige Zitat auf der ersten Seite. Urheberrechte für Komponenten Werke, die anderen als ACM gehören, müssen gewürdigt werden. Abstrahieren mit Kredit ist zulässig. Zum anderweitigen Kopieren oder erneuten Veröffentlichen, zum Posten auf Servern oder auf Für die Weiterverbreitung in Listen ist eine vorherige ausdrückliche Genehmigung und/oder eine Gebühr erforderlich. Anfrage Berechtigungen von [email protected]. SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada © 2019 Association for Computing Machinery. ACM ISBN 978-1-4503-6873-5/19/10...15,00 $ https://doi.org/10.1145/3341301.3359636 Mexiko, zwei Nachbarländer. Endverbraucher zahlen fast 9 US-Dollar für den Durchschnitt einer solchen Übertragung [32] und eine bilaterale Vereinbarung Die von den Zentralbanken der Länder vermittelten Gelder konnten nur reduziert werden Die zugrunde liegenden Bankkosten belaufen sich auf 0,67 USD pro Artikel [2]. Zusätzlich zu den Gebühren Bei internationalen Zahlungen wird grundsätzlich die Latenz berücksichtigt innerhalb weniger Tage, was es unmöglich macht, schnell Geld ins Ausland zu bekommen Notfälle. In Ländern, in denen das Bankensystem dies nicht tut funktioniert oder nicht allen Bürgern dient, oder wenn die Gebühren untragbar sind, greifen die Menschen auf die Überweisung von Zahlungen per Bus [38], by zurück Boot [19] und gelegentlich jetzt auch mit Bitcoin [55], allesamt Risiken, Verzögerungen oder Unannehmlichkeiten mit sich bringen. Obwohl es immer Compliance-Kosten geben wird, deuten die Beweise darauf hin, dass ein erheblicher Betrag durch mangelnden Wettbewerb verloren geht [21], was durch ineffiziente Technologie noch verschärft wird. Wo Menschen kann innovativ sein, Preise und Latenzen sinken. Beispielsweise kosteten Überweisungen von Bankkonten im zweiten Quartal 2019 durchschnittlich 6,99 %, während der Wert für mobiles Geld nur 4,88 % betrug [13]. Ein offenes, globales Zahlungsnetzwerk, das Innovationen anzieht und die Konkurrenz durch Nichtbanken könnte nachlassen Kosten und Latenzen auf allen Ebenen, einschließlich Compliance [83]. In diesem Dokument wird Stellar vorgestellt, eine blockchain-basierte Zahlung Netzwerk, das speziell darauf ausgelegt ist, Innovationen zu erleichtern und Wettbewerb im internationalen Zahlungsverkehr. Stellar ist der erste System, um alle drei der folgenden Ziele zu erreichen (unter a neuartige, aber empirisch gültige „Internet-Hypothese“): 1. Offene Mitgliedschaft – Jeder kann währungsgestützte Ausgaben tätigen digitale tokens, die zwischen Benutzern ausgetauscht werden können. 2. Vom Emittenten erzwungene Endgültigkeit – Der Emittent eines token kann dies verhindern Transaktionen im token können nicht storniert oder rückgängig gemacht werden. 3. Emittentenübergreifende Atomizität – Benutzer können atomar austauschen und handeln Sie tokens von mehreren Emittenten. Die ersten beiden zu erreichen ist einfach. Jedes Unternehmen kann einseitig ein Produkt wie Paypal, Venmo, WeChat anbieten Bezahlen Sie oder Alipay und stellen Sie die Endgültigkeit der Zahlungen sicher virtuelle Währungen, die sie geschaffen haben. Leider ist eine atomare Transaktion über diese Währungen hinweg nicht möglich. Tatsächlich, obwohl Paypal die Muttergesellschaft von Venmo übernommen hat Im Jahr 2013 ist es für Endbenutzer immer noch unmöglich, Venmo zu versenden Dollar an Paypal-Benutzer [78]. Erst seit kurzem können Händler Akzeptieren Sie sogar beides mit einer einzigen Integration. Die Ziele 2 und 3 können in einem geschlossenen System erreicht werden. Insbesondere verfügen einige Länder über einen effizienten Inlandszahlungsverkehr Netzwerke, die in der Regel von einer allgemein vertrauenswürdigen Regulierungsbehörde überwacht werden. Die Mitgliedschaft ist jedoch auf eine geschlossene Mitgliedschaft beschränkt Die Anzahl der zugelassenen Banken und die Netzwerke sind auf die beschränkt Reichweite der Regulierungsbehörde eines Landes.SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Lokhava et al. Die Ziele 1 und 3 wurden in abgebauten blockchains erreicht, vor allem in Form von ERC20 tokens auf Ethereum [3]. Die Kernidee dieser blockchains besteht darin, eine neue Kryptowährung zu schaffen, mit der Menschen für ihre Abwicklung belohnt werden können Transaktionen sind schwer rückgängig zu machen. Leider bedeutet dies, dass die Emittenten von token die Endgültigkeit der Transaktion nicht kontrollieren. Wenn Software Fehler führen dazu, dass der Transaktionsverlauf neu organisiert wird [26, 73], oder wenn die Beute betrügerischer Menschen die Kosten übersteigt Durch die Neuordnung der Historie [74, 97] können Emittenten für tokens haftbar gemacht werden Sie wurden bereits gegen echtes Geld eingelöst. Der Stellar blockchain hat zwei charakteristische Eigenschaften. Erstens unterstützt es nativ effiziente Märkte zwischen tokens von verschiedenen Emittenten. Konkret kann jeder ein token ausstellen, Der blockchain bietet ein integriertes Orderbuch für den Handel zwischen einem beliebigen Paar von tokens, und Benutzer können Pfadzahlungen ausstellen die gleichzeitig atomar über mehrere Währungspaare hinweg handeln Gewährleistung eines End-to-End-Grenzpreises. Zweitens führt Stellar ein neues byzantinisches Abkommen ein Protokoll, SCP (Stellar Consensus Protocol), über das token-Aussteller benennen bestimmte validator-Server zur Durchsetzung Endgültigkeit der Transaktion. Solange niemand die validators eines Ausstellers (und die zugrunde liegenden digitalen Signaturen und kryptografische hashes bleiben sicher), der Emittent weiß genau, welche Transaktionen stattgefunden haben und vermeidet das Risiko der Verluste aus der Umstrukturierung der blockchain-Historie. Die Kernidee von SCP besteht darin, dass die meisten Emittenten von Vermögenswerten davon profitieren liquide Märkte und wollen atomare Transaktionen ermöglichen mit anderen Vermögenswerten. Daher konfigurieren validator Administratoren ihre Server, um sich mit anderen validators auf das Genaue zu einigen Historie aller Transaktionen mit allen Vermögenswerten. Ein validator v1 kann sein entweder so konfiguriert werden, dass sie v2 zustimmt, oder v2 kann so konfiguriert werden, dass sie zustimmt mit v1, oder beide können so konfiguriert werden, dass sie miteinander übereinstimmen; In allen Fällen wird sich keiner von beiden auf eine Transaktionshistorie festlegen, bis Es weiß, dass der andere sich nicht auf eine andere Geschichte festlegen kann. Wenn aufgrund der Transitivität v1 nicht mit v2 und v2 mit v3 nicht einverstanden sein kann (oder umgekehrt), kann v1 nicht mit v2 übereinstimmen v3, ob v3 Vermögenswerte darstellt oder nicht, hat v1 überhaupt gehört von. Unter der Annahme, dass diese Vereinbarungsbeziehungen Transitiv das gesamte Netzwerk verbinden, garantiert SCP globales Abkommen, was es zu einem globalen byzantinischen Abkommen macht Protokoll mit offener Mitgliedschaft. Wir nennen diese neue Verbundenheitsannahme die Internet-Hypothese und stellen fest, dass dies der Fall ist gilt sowohl für „das Internet“ (was jeder versteht). bedeuten das größte transitiv verbundene IP-Netzwerk) und alte internationale Zahlungen (die Hop-by-Hop sind). nicht-atomar, sondern nutzen eine transitiv verbundene, globale Netzwerk von Finanzinstituten). Stellar ist seit September 2015 im Produktionseinsatz. Um die Länge von blockchain überschaubar zu halten, läuft das System SCP in 5-Sekunden-Intervallen – für blockchain-Verhältnisse schnell, aber weitaus langsamer als typische Anwendungen byzantinischer Vereinbarungen. Obwohl der Hauptzweck Zahlungen waren, gilt dies auch für Stellar hat sich als attraktiv für nicht durch Geld fungible tokens erwiesen, die davon profitieren aus unmittelbaren Sekundärmärkten (siehe Abschnitt 7.1). Im nächsten Abschnitt werden verwandte Arbeiten besprochen. Abschnitt 3 präsentiert SCP. Abschnitt 4 beschreibt unsere formelle Überprüfung von SCP. Abschnitt 5 beschreibt die Zahlungsebene von Stellar. Abschnitt 6 betrifft einige unserer Einsatzerfahrungen und gewonnenen Erkenntnisse. Abschnitt 7 bewertet das System. Abschnitt 8 schließt ab.

Verwandte Arbeiten

Das in diesem Artikel beschriebene System ist insgesamt unser drittes Versuchen Sie, ein dezentrales Zahlungsnetzwerk zu realisieren. Die Der erste Versuch eines der Autoren führte zum Ripple blockchain. Obwohl Ripple noch existiert, glauben wir, dass es die Vision eines wirklich offenen Zahlungsnetzwerks nicht verwirklichen kann sowohl aus Governance- als auch aus technischen Gründen. Die Governance-Gründe ergeben sich aus Spannungen zwischen Aktionärsinteressen und Netzwerkbenutzer, gehen jedoch über den Rahmen dieses Dokuments hinaus. Die Das technische Problem besteht darin, dass das byzantinische Vereinbarungsprotokoll [89] von Ripple eine nahezu geschlossene Mitgliedschaft [33] erfordert funktional ähnlich dem konventionellen byzantinischen Abkommen. Der zweite Versuch, eine kurzlebige Abzweigung des Ripple-Codes Die Basis namens Stellard ging im Juli 2014 in Betrieb. Das hatten wir geplant Entwickeln Sie SCP und fügen Sie es in Stellard ein, wenn es bereit ist, aber stattdessen beschlossen, ein neues System rund um SCP aufzubauen, wird Sternkern genannt und in diesem Artikel beschrieben. Sternenkern wurde zusammen mit einer Beschreibung und einem Beweis von SCP [68] veröffentlicht im April 2015 und ging fünf Monate später in den Produktionseinsatz. Ein Internetentwurf [20] beschrieb später SCP für Implementierer. Motivation und Struktur von SCP ähneln dem asymmetrischen Vertrauen in der Mehrparteienberechnung [40], obwohl dieses Modell erfordert, dass Knoten eine globale Sicht auf die Struktur des Gegners haben. SCP genießt die Einführung eines Konzepts von Quorum-Slices Auffindbarkeit und dynamische Mitgliedschaft, die für die Bereitstellung von Stellar wichtig sind. Persönliches byzantinisches Kollegium Systeme [47] und asymmetrisches verteiltes Vertrauen [29] verallgemeinern die Quoren von SCP und vereinfachen den Vergleich mit herkömmlichen Systeme. In einem eingeschränkteren Rahmen haben Gotsman et al. [49] auch Studieren Sie eine Verallgemeinerung der Kollegien von Stellar. Mehrere andere blockchains haben SCP übernommen, darunter MobileCoin [7] und NCNT. Ripple hat kürzlich auch ein byzantinisches Abkommensprotokoll mit offener Mitgliedschaft vorgeschlagen namens Cobalt [66]. Die Sicherheit von SCP ist optimal, daher ist SCP sicher jedes Ausfallszenario, in dem Kobalt vorhanden ist, während das Gegenteil der Fall ist unklar. Cobalt behauptet jedoch, sein Sicherheitszustand sei leichter zu verstehen und daher weniger anfällig für Fehlkonfigurationen. Es wird interessant sein zu bewerten, ob Cobalt eingesetzt wird. 2.1 Systeme ohne offene Mitgliedschaft Wie viele Konsensprotokolle basiert SCP auf Abstimmungen [50, 94] in einem Quorumsystem. Frühere Arbeiten zu Quorumsystemen [52, 67, 72], manchmal auch „Survivor Sets“ genannt [57], untersuchen Quorumsysteme, die statisch sind, d. h. durchgehend festgelegt sind Systemausführung und einheitlich, d. h. wo alle Knoten das haben Ich habe die gleiche Vorstellung davon, was ein Quorum ist. Die Einstellung von SCP ist unterschiedlich dass verschiedene Knoten unterschiedliche und sich entwickelnde Quoren akzeptieren.Schnelle und sichere globale Zahlungen mit Stellar SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Der heterogene schnelle Konsens [91] ermöglicht eine nuanciertere Gestaltung Vorstellungen von Vertrauen, die durch Etiketten in einem Gitter ausgedrückt werden sollen und nutzt dies, um die Kommunikation zu optimieren, geht aber davon aus geschlossene Mitgliedschaft. Weitere Bemühungen zur Anpassung byzantinischer Vertragsprotokolle zu Blockchain-ähnlichen Einstellungen, einschließlich HoneyBadger [70], SBFT [53] und HotStuff [99] haben sich auf Skalierbarkeit konzentriert für viele Teilnehmer und Leistung über Weitverkehrsnetze unter Beibehaltung des traditionellen geschlossenen Mitgliedschaftsmodells. Blockchains, die auf geschlossene Mitgliedschaften abzielen, haben eine Hebelwirkung erzielt solche Protokolle, darunter zuletzt Libra [11]. 2.2 Systeme ohne vom Emittenten erzwungene Endgültigkeit Bitcoin [71] war der erste fungible digitale Vermögenswert ohne vertrauenswürdige Autorität zur Nachverfolgung von Salden. Es wurde gleichzeitig gelöst zwei Probleme: Wie verteilt man einen neuen Vermögenswert so, dass die Leute glauben? Es hat einen Wert und wie kann man diesen für irreversible Transaktionen bereitstellen? Verhindern Sie Double-Spend-Angriffe. Bitcoin erstellt Assets durch proof-of-work [43], den der Autor mit Goldminenarbeitern vergleicht, die Ressourcen investieren, um das Goldangebot zu erhöhen. Die Die nachgewiesene Arbeit hängt von der Transaktionshistorie ab, die vereitelt Double-Spend-Angriffe, da das Zurücksetzen von Transaktionen einen Arbeitsaufwand erfordert, der mit dem Erstellen des ursprünglichen Verlaufs vergleichbar ist. Angriffe auf proof-of-work blockchains werden möglich sobald ein Angreifer 1/3 der Mining-Power kontrolliert [46, 48]. Proof-of-Work ist besonders riskant für neue oder kleinere blockchains [15, 23]; Es ist bekannt, dass etablierte Bergleute den Bergbau umleiten Macht an kleinere Ketten aus Profitgründen [10, 54, 74, 97, 98] oder einfach nur Probleme verursachen [25, 37] (sog. „Goldfinger-Angriffe“ [60]). Manchmal haben Miner wohlwollend solche „51 %-Angriffe“ durchgeführt, um die unerwünschten Auswirkungen von Bugs [95] einzudämmen. Neu blockchains können einen gewissen Schutz vor 51 %-Angriffen erhalten Nutzung etablierterer blockchains mit fusioniertem Mining [6] oder Proof of Burn [79]. Zum jetzigen Zeitpunkt werden die Kosten eines 51-Prozent-Angriffs auf 823.000 US-Dollar geschätzt. Stunde am Bitcoin, \(93,000/hour on Ethereum, and under \)20.000/ Stunde für alle anderen verfolgten blockchains [12]. Letztendlich sind es diese Die Kosten hängen vom Wert der Kryptowährung ab, die den Mining-Anreiz darstellt, und sind unabhängig vom ausgegebenen Wert Vermögenswerte. Im Gegensatz dazu unterliegen die Kosten für die Kompromittierung von Stellar validators in gewissem Maße der Kontrolle ihrer Administratoren; SCP ist für hochsichere Implementierungen geeignet, z Verwendung von Hardware-Sicherheitsmodulen, um einen validator zu verhindern widersprüchliche Botschaften unterzeichnen. Als zusätzlichen Vorteil: Für Stellar fallen keine Mining-Kosten an, die durch eine Transaktion amortisiert werden könnten Gebühren oder Seigniorage. Der enorme Energieverbrauch von Bitcoin [76] hat motiviert energieeffizientere Varianten des Arbeitsnachweises wie z Platznachweis [16, 17, 44, 87], Speichernachweis [18, 56, 86, 90], und Nachweis der verstrichenen Zeit [4]. Der Arbeitsnachweis kann aufgrund von Transaktionsblöcken langsam sein Die Bestätigung dauert Minuten und es sind mehrere Blöcke erforderlich stärkere Sicherheit. Die Arbeit, einen Block abzubauen, kann jedoch sein amortisiert über eine Reihe von Transaktionen beliebiger Größe, die nur durch politische Probleme und Kompatibilität eingeschränkt sind. BitcoinNG [45] verwendet einen Arbeitsnachweis, um einen Leiter zu wählen, der koordiniert eine größere Anzahl von Transaktionen. Thunderella [84] kann Proof-of-Work als Fallback-„langsamen Pfad“ verwenden und optimistisch bestätigen Transaktionen viel schneller mit einem asynchronen Konsens Protokoll, wenn ein Beschleunigerknoten und drei Viertel eines gewählten Ausschusses ehrlich sind. Obwohl SCP schneller als proof-of-work ist, es erfordert mehr Nachrichten als Thunderellas schneller Weg, aber könnte möglicherweise ein nützlicher langsamer Thunderella-Pfad sein. Eine Alternative zum Arbeitsnachweis ist der Einsatznachweis [59], bei denen Bergleute entweder direkt oder indirekt durch den Besitz von Vermögenswerten Einfluss erlangen. In einigen Fällen nimmt der Einfluss mit der Zeit zu, in der Vermögenswerte gehalten werden. Einige Schemata Fördern Sie die Ehrlichkeit, indem Sie die Anteile der Bergleute beschlagnahmen, wenn dies der Fall ist sich schlecht benehmen [27, 28, 41]. Delegiert proof-of-stake [9, 61] hat Knoten stimmen über ihren Anteil ab, um Vertreter für ein konventionelles byzantinisches Vertragsprotokoll wie PBFT [31] zu wählen. Algorand [51] verwendet überprüfbare Zufallsfunktionen, um repräsentative Knoten pseudozufällig und mit proportionaler Wahrscheinlichkeit auszuwählen zu Kryptowährungsbeständen. Schneewittchen [39] formalisiert das Sicherheitseigenschaften, die für den Nachweis des Einsatzes erforderlich sind und „schläfrige“ Knoten aufnehmen, die weitergehen undoffline. Obwohl die meisten proof-of-stake-Programme nicht mit aufwändigen Berechnungen brutal erzwungen werden können, sind die Kosten für den Erwerb der Anteile hoch oder Bestechung von Bergleuten hängt immer noch vom Wert der zugrunde liegenden Kryptowährung ab und liegt außerhalb der Kontrolle des Emittenten von Vermögenswerten. Auch ohne böswillige Miner können Fehler auftreten blockchain Reorganisation [26, 73]. Daher ist, anders als bei SCP, Emittenten haben keine Möglichkeit, die Endgültigkeit von blockchain vorher sicherzustellen Einlösen von tokens in der Kette gegen eine echte Überweisung oder Bargeldabhebung.

Stellar Konsensprotokoll

Das Stellar-Konsensprotokoll (SCP) basiert auf einem Quorum Byzantinisches Vertragsprotokoll mit offener Mitgliedschaft. Quoren entstehen aus den kombinierten lokalen Konfigurationsentscheidungen einzelner Knoten. Knoten erkennen jedoch nur Kollegien, denen sie selbst angehören, und erst danach Lernen der lokalen Konfigurationen aller anderen Kollegiumsmitglieder. Ein Vorteil dieses Ansatzes besteht darin, dass SCP von Natur aus vorhanden ist toleriert heterogene Ansichten darüber, welche Knoten vorhanden sind. Daher, Knoten können einseitig beitreten und verlassen, ohne dass ein Knoten erforderlich ist „View Change“-Protokoll zur Koordinierung der Mitgliedschaft. 3.1 Föderiertes byzantinisches Abkommen Das traditionelle Problem der byzantinischen Vereinbarung besteht aus a geschlossenes System von N Knoten, von denen einige fehlerhaft sind und möglicherweise sich willkürlich verhalten. Knoten empfangen Eingabewerte und tauschen sie aus Nachrichten, um über einen Ausgabewert unter den Eingaben zu entscheiden. Ein byzantinisches Vereinbarungsprotokoll ist sicher, wenn keine zwei gut funktionierenden Knoten unterschiedliche Entscheidungen und die Einzigartigkeit ausgeben Entscheidung war eine gültige Eingabe (für eine Definition von gültig vereinbart).SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Lokhava et al. (siehe vorher). Ein Protokoll ist dann live, wenn es dies garantiert Jeder ehrliche Knoten gibt schließlich eine Entscheidung aus. Normalerweise gehen Protokolle davon aus, dass N = 3f + 1 für eine ganze Zahl ist f > 0, dann garantieren Sicherheit und eine gewisse Lebendigkeit solange höchstens f Knoten fehlerhaft sind. Irgendwann in diesen Protokolle, Knoten stimmen über vorgeschlagene Werte und einen Vorschlag ab Der Erhalt von 2f + 1 Stimmen, ein sogenanntes Stimmenquorum, wird die Entscheidung. Mit N = 3f + 1 Knoten, zwei beliebige Quoren von Größe 2f + 1 Überlappung in mindestens f + 1 Knoten; auch wenn f davon Überlappende Knoten sind fehlerhaft, die beiden Quoren teilen sich zumindest ein fehlerfreier Knoten, wodurch widersprüchliche Entscheidungen verhindert werden. Allerdings funktioniert dieser Ansatz nur, wenn sich alle Knoten darauf einigen Was stellt ein Quorum dar, was in SCP wo unmöglich ist Zwei Knoten wissen möglicherweise nicht einmal von der Existenz des anderen. Mit SCP deklariert jeder Knoten v einseitig Knotenmengen, nennt seine Quorum-Slices, so dass (a) v das glaubt, wenn alle Die Mitglieder eines Slice sind sich also über den Zustand des Systems einig Sie haben Recht, und (b) v glaubt, dass mindestens eine seiner Scheiben wird zur Verfügung stehen, um rechtzeitig Informationen darüber bereitzustellen Zustand des Systems. Wir nennen das resultierende System bestehend von Knoten und ihren Slices, ein Föderiertes Byzantinisches Abkommen (FBA)-System. Wie wir als nächstes sehen werden, entsteht ein Quorumsystem aus Knotenscheiben. Informell geben die Slices eines FBA-Knotens an, mit wem der Knoten erfordert Zustimmung. Beispielsweise kann ein Knoten eine Vereinbarung mit vier spezifischen Organisationen erfordern, die jeweils drei Knoten betreiben. zu Um Ausfallzeiten zu berücksichtigen, kann es seine Slices so einstellen, dass sie alle Sätze sind bestehend aus 2 Knoten jeder Organisation. Wenn dies „erfordert „Übereinstimmung mit“-Beziehung verbindet transitiv zwei beliebige Knoten, Wir bekommen eine globale Einigung. Andernfalls kann es zu Divergenz kommen, aber nur zwischen Organisationen, die beides nicht erfordert Vereinbarung mit dem anderen. Angesichts der Topologie der heutigen Wir gehen davon aus, dass die umfassende Konvergenz im Finanzsystem weiterhin zu einer Singe-Ledger-Geschichte führen wird, die die Leute nennen „das Stellar-Netzwerk“, so wie wir auch vom Internet sprechen. Quoren entstehen wie folgt aus Slices. Jeder Knoten spezifiziert Sein Quorum schneidet jede Nachricht ab, die es sendet. Sei S das Gruppe von Knoten, von denen eine Gruppe von Nachrichten stammt. A Der Knoten geht davon aus, dass der Nachrichtensatz das Quorum erreicht hat Schwellenwert, wenn für jedes Mitglied von S ein Slice in S enthalten ist. Aufgrund der Konstruktion erfüllt eine solche Menge S, wenn sie einstimmig ist, die Zustimmungsanforderungen jedes seiner Mitglieder. Ein fehlerhafter Peer kann Slices anbieten, die so gestaltet sind, dass sie etwas ändern Gut erzogene Knoten berücksichtigen Quoren. Aus Gründen der Protokollanalyse definieren wir ein Quorum in FBA als nicht leer Menge S von Knoten, die mindestens ein Quorum-Slice umfassen jedes nicht fehlerhafte Mitglied. Diese Abstraktion ist wie jede Menge solide von Nachrichten, die angeblich ein einstimmiges Quorum darstellen tatsächlich (auch wenn es Nachrichten von fehlerhaften Knoten enthält), und es ist präzise, wenn S nur gut erzogene Knoten enthält. In In diesem Abschnitt gehen wir auch davon aus, dass sich die Slices der Knoten nicht ändern. Dennoch lassen sich unsere Ergebnisse auf den Fall der sich verändernden Schicht übertragen denn ein System, in dem sich Slices ändern, ist nicht weniger sicher als ein System mit festen Scheiben, bei dem die Scheiben eines Knotens aus allen bestehen Slices, die es jemals im Fall der sich verändernden Slices verwendet (siehe Theorem 13 in [68]). Wie in Abschnitt 4 erläutert, hängt die Lebendigkeit davon ab Gut erzogene Knoten entfernen schließlich unzuverlässige Knoten aus ihren Scheiben. Da verschiedene Knoten unterschiedliche Vereinbarungsanforderungen haben, schließt FBA eine globale Definition von Sicherheit aus. Wir sagen Die nicht fehlerhaften Knoten v1 und v2 sind jeweils miteinander verflochten Quorum von v1 schneidet jedes Quorum von v2 in mindestens einem nicht fehlerhafter Knoten. Ein FBA-Protokoll kann eine Einigung gewährleisten nur zwischen ineinander verschlungenen Knoten; Da SCP dies tut, ist es seine Schuld Die Sicherheitstoleranz ist optimal. Die Internet-Hypothese, Das zugrunde liegende Design von Stellar besagt, dass sich die Knoten um die Menschen kümmern ungefähr wird miteinander verflochten sein. Wir sagen, dass eine Menge von Knoten I intakt ist, wenn I ein einheitlich fehlerfreies Quorum ist, sodass alle zwei Mitglieder von I miteinander verflochten sind, selbst wenn jeder Knoten außerhalb von I fehlerhaft ist. Intuitiv, dann sollte ich für die Handlungen von Nichtintakten unempfindlich bleiben Knoten. SCP garantiert sowohl nicht blockierende Lebendigkeit [93] als auch Sicherheit für intakte Mengen, obwohl die Knoten selbst dies nicht benötigen zu wissen (und möglicherweise nicht wissen zu können), welche Sätze intakt sind. Darüber hinaus ist die Vereinigung zweier intakter Mengen, die sich schneiden ein intaktes Set. Daher definieren intakte Mengen eine Partition der gut erzogene Knoten, bei denen jede Partition sicher und aktiv ist (unter bestimmten Bedingungen), aber möglicherweise werden unterschiedliche Partitionen ausgegeben abweichende Entscheidungen. 3.1.1 Überlegungen zur Sicherheit vs. Lebendigkeit beim Versand durch Amazon Mit wenigen Ausnahmen [64] sind die meisten geschlossenen byzantinischen Vereinbarungsprotokolle auf den Gleichgewichtspunkt abgestimmt, an dem Sicherheit und Lebendigkeit haben die gleiche Fehlertoleranz. Bei Versand durch Amazon Das bedeutet Konfigurationen, bei denen unabhängig von Ausfällen alle Ineinander verschlungene Mengen sind ebenfalls intakt. Vorausgesetzt, FBA bestimmt Da die Quoren dezentral verteilt werden, ist es unwahrscheinlich, dass einzelne Wahlmöglichkeiten zu diesem Gleichgewicht führen. Darüber hinaus bei Zumindest in Stellar ist das Gleichgewicht nicht wünschenswert: die Konsequenzen eines Sicherheitsversagens (nämlich doppelt ausgegebenes digitales Geld) vorliegen weitaus schlimmer als die eines Liveness-Ausfalls (nämlich Verzögerungen). bei Zahlungen, die ohnehin Tage gedauert haben, bevor Stellar). Menschen Daher sollten und werden große Quorum-Slices ausgewählt, so dass Ihre Knoten bleiben eher miteinander verflochten als intakt. Je weiter die Waage kippt, desto einfacher ist es, sich davon zu erholen typischere Liveness-Fehler in einem FBA-System als in einem herkömmlichen geschlossenen System. In geschlossenen Systemen müssen alle Nachrichten vorhanden sein im Hinblick auf die gleiche Gruppe von Kollegien interpretiert werden. Daher, Das Hinzufügen und Entfernen von Knoten zur Wiederherstellung nach einem Ausfall ist erforderlich Einen Konsens über ein Neukonfigurationsereignis zu erzielen, was schwierig ist, wenn der Konsens nicht mehr besteht. Im Gegensatz dazu gilt bei FBA Jeder Knoten kann seine Quorum-Slices jederzeit einseitig anpassen Zeit. Als Reaktion auf einen Ausfall an einer systemrelevanten Stelle Organisation können Knotenadministratoren ihre Slices anpassen Umgehen des Problems, ähnlich wie beim Koordinieren von Antworten zu BGP-Katastrophen [63] (allerdings ohne die Einschränkungen von Routing über physische Netzwerkverbindungen).

Schnelle und sichere globale Zahlungen mit Stellar SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada 3.1.2 Der Kaskadensatz SCP folgt der Vorlage des Grundrundenmodells [42]; Die Knoten durchlaufen jeweils eine Reihe nummerierter Stimmzettel Versuchen Sie drei Aufgaben: (1) Identifizieren Sie einen „sicheren“ Wert, der nicht durch eine Entscheidung in einem früheren Wahlgang im Widerspruch steht (oft als „sicherer“ Wert bezeichnet). Vorbereitung des Stimmzettels), (2) Einigung über den sicheren Wert und (3) Feststellung, dass die Einigung erfolgreich war. Versand durch Amazon ist jedoch geöffnet Die Mitgliedschaft behindert mehrere gängige Techniken und macht es möglich Es ist unmöglich, herkömmliche geschlossene Protokolle auf die FBA zu „portieren“. Modell durch einfaches Ändern der Definition des Quorums. Eine von vielen Protokollen verwendete Technik ist die Rotation nach Zeitüberschreitungen im Round-Robin-Verfahren durch die Leader-Knoten. In einem geschlossenen System wird die Leader-Auswahl im Round-Robin-Verfahren sichergestellt dass am Ende ein einzigartiger, ehrlicher Anführer eine Einigung über einen einzigen Wert erzielt. Leider Round-Robin kann nicht in einem FBA-System mit unbekannter Mitgliedschaft arbeiten. Eine weitere häufige Technik, die bei FBA fehlschlägt, besteht darin, anzunehmen, dass ein bestimmtes Quorum alle Knoten überzeugen kann. Zum Beispiel, Wenn jeder beliebige 2f + 1-Knoten als Quorum anerkennt, dann 2f + 1 Signaturen reichen aus, um allen Knoten den Protokollstatus nachzuweisen. Ähnlich verhält es sich, wenn ein Knoten ein Quorum identischer Nachrichten empfängt Durch die zuverlässige Übertragung [24] kann der Knoten davon ausgehen, dass alle nicht fehlerhaften Knoten ebenfalls ein Quorum sehen. Im Gegensatz dazu a Für Knoten außerhalb des Quorums bedeutet das Quorum nichts. Schließlich verwenden nicht-föderierte Systeme häufig „Rückwärts“-Methoden. Argumentation zur Sicherheit: Wenn f + 1 Knoten fehlerhaft sind, gilt für alle Sicherheit Garantien gehen verloren. Wenn also Knoten v alle f + 1 Knoten hört Geben Sie eine Tatsache an. F, v kann davon ausgehen, dass mindestens einer davon erzählt Wahrheit (und daher, dass F wahr ist) ohne Verlust der Sicherheit. So Die Argumentation schlägt bei FBA fehl, da Sicherheit eine Eigenschaft von Paaren ist von Knoten, so dass ein Knoten, der die Sicherheit einiger Peers verloren hat, dies kann Verlieren Sie immer die Sicherheit an mehr Knoten, indem Sie schlechte Fakten annehmen. FBA kann jedoch in Bezug auf die Lebendigkeit rückwärts denken. Definieren Sie einen V-Blocking-Satz als einen Satz von Knoten, die sich alle schneiden Scheibe von v. Wenn ein v-blockierender Satz B einstimmig fehlerhaft ist, B kann Node V ein Quorum verweigern und ihm die Lebendigkeit kosten. Daher, wenn B gibt einstimmig die Tatsache F an, dann weiß v, dass entweder F ist wahr oder v ist nicht intakt. Allerdings muss v noch vollständig angezeigt werden Quorum, um zu wissen, dass ineinander verschlungene Knoten F nicht widersprechen, was zu einer letzten Kommunikationsrunde in SCP führt und andere FBA-Protokolle [47], die analog nicht erforderlich sind geschlossene Mitgliedschaftsprotokolle. Das Ergebnis ist, dass wir es haben drei mögliche Ebenen des Vertrauens in potenzielle Fakten: unbestimmt, sicher unter intakten Knoten anzunehmen (was wir tun werden). Begriff akzeptierte Fakten) und sicher untereinander anzunehmen Knoten (die wir als bestätigte Fakten bezeichnen werden). Knoten v kann effizient bestimmen, ob eine Menge B blockiert, indem er prüft, ob B alle seine Slices schneidet. Interessanterweise kündigen Knoten immer ihre Anweisungen an Akzeptieren und ein vollständiges Quorum eine Aussage akzeptiert, löst dies einen Kaskadenprozess aus, durch den sich die Aussagen überall verbreiten intakte Sätze. Wir nennen die Schlüsseltatsache, die dieser Ausbreitung zugrunde liegt der Kaskadensatz, der Folgendes besagt: Wenn ich ein bin Intakte Menge, Q ist ein Quorum eines beliebigen Mitglieds von I und S ist ein beliebiges Obermenge von Q, dann ist entweder S ⊇I oder es gibt ein Mitglied v ∈I so dass v < S und I ∩S v-blockierend ist. Intuitiv war das so Ist dies nicht der Fall, würde das Komplement von S ein Quorum enthalten das schneidet I, aber nicht Q, und verstößt gegen die Quorum-Schnittmenge. Beachten Sie, dass wir mit S = Q beginnen und S wiederholt zu erweitern Wenn wir alle Knoten einbeziehen, die es blockiert, erhalten wir einen Kaskadeneffekt, bis schließlich umfasst S alles von I. 3.2 Protokollbeschreibung SCP ist ein teilweise synchrones Konsensprotokoll [42], das aus einer Reihe von Versuchen besteht, einen Konsens zu erreichen Stimmzettel. Bei Abstimmungen kommt es zu immer längeren Auszeiten. A Das Abstimmungssynchronisierungsprotokoll stellt sicher, dass die Knoten eingeschaltet bleiben den gleichen Stimmzettel für immer längere Zeiträume bis zu den Stimmzetteln sind effektiv synchron. Eine Kündigung ist nicht garantiert bis die Stimmzettel synchron sind, aber zwei synchrone Stimmzettel Dies ist bei fehlerhaften Mitgliedern von Slices gut erzogener Knoten der Fall Nichteingreifen reicht aus, damit SCP beendet wird. In einem Abstimmungsprotokoll werden die jeweils getroffenen Maßnahmen festgelegt Stimmzettel. Ein Stimmzettel beginnt mit einer Vorbereitungsphase, in der Knoten Versuchen Sie, einen Wert zu ermitteln, der nicht im Widerspruch steht eine frühere Entscheidung. Dann versuchen es die Knoten in einer Commit-Phase eine Entscheidung über den vorbereiteten Wert zu treffen. Bei der Stimmabgabe wird ein Vereinbarungs-Unterprotokoll namens „Federated Voting“ eingesetzt, dn welche Knoten über abstrakte Aussagen abstimmen das könnte sich irgendwann bestätigen oder stecken bleiben. Einige Aussagen könnten als widersprüchlich bezeichnet werden, und die Sicherheit Die Garantie der föderierten Abstimmung besteht darin, dass keine zwei Mitglieder einer Ineinander verschlungene Mengen bestätigen widersprüchliche Aussagen. Die Bestätigung einer Aussage kann nicht garantiert werden, es sei denn, sie ist intakt Gruppe, deren Mitglieder alle gleich abstimmen. Wenn jedoch a Mitglied einer intakten Menge bestätigt eine Aussage, föderiert Die Abstimmung garantiert, dass alle Mitglieder der intakten Menge diese Aussage letztendlich bestätigen. Daher werden irreversible Schritte unternommen als Antwort auf bestätigende Aussagen bewahrt die Lebendigkeit für intakte Knoten. Knoten schlagen zunächst Werte vor, die aus einer Nominierung stammen Protokoll, das die Chancen aller Mitglieder eines intakten Systems erhöht Satz, der denselben Wert vorschlägt, und der schließlich konvergiert (obwohl es keine Möglichkeit gibt, die Konvergenz als vollständig zu bestimmen). Die Nominierung kombiniert eine gemeinsame Abstimmung mit der Auswahl des Anführers. Da Round-Robin bei Versand durch Amazon nicht möglich ist, wird die Nominierung verwendet ein probabilistisches Führungsauswahlschema. Das Kaskadentheorem spielt bei der Stimmabgabe eine entscheidende Rolle Synchronisierung und bei der Vermeidung blockierter Zustände Eine Kündigung ist nicht mehr möglich. 3.2.1 Abstimmung SCP-Knoten führen eine Reihe nummerierter Abstimmungen durch und nutzen eine gemeinsame Abstimmung, um sich auf Aussagen darüber zu einigen Welche Werte in welchen Abstimmungen entschieden werden oder nicht. Wenn Asynchronität oder fehlerhaftes Verhalten eine Entscheidung in Abstimmung n verhindert, Zeitüberschreitung der Knoten und erneuter Versuch in Stimmzettel n + 1.

SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Lokhava et al. Die Rückruf-Verbundabstimmung wird möglicherweise nicht beendet. Daher einige Aussagen zu Stimmzetteln können dauerhaft stecken bleiben unbestimmter Zustand, in dem Knoten niemals feststellen können, ob sie sind noch in Bearbeitung oder stecken fest. Weil Knoten nicht ausschließen können die Möglichkeit, dass sich unbestimmte Aussagen später als wahr erweisen, Sie dürfen niemals versuchen, gemeinsam über neue Stellungnahmen abzustimmen widersprüchliche unbestimmte. In jedem Wahlgang n nutzen die Knoten die föderierte Abstimmung für zwei Arten der Aussage: • Prepare ⟨n,x⟩– gibt an, dass es keinen anderen Wert als x gibt wurde oder wird jemals in einem Wahlgang ≤n entschieden. • commit ⟨n,x⟩– besagt, dass über x in Abstimmung n entschieden wird. Beachten Sie unbedingt, dass „prepare ⟨n,x⟩dem Commit widerspricht“. ⟨n′,x ′⟩wenn n ≥n′ und x , x ′. Ein Knoten beginnt mit Abstimmung n, indem er versucht, eine gemeinsame Abstimmung über a durchzuführen Anweisung vorbereiten ⟨n,x⟩. Falls vorhanden, vorbereiten Sie eine Anweisung wurde durch föderale Abstimmung erfolgreich bestätigt Der Knoten wählt x aus der bestätigten Liste des höchsten Stimmzettels. Andernfalls setzt der Knoten x auf die Ausgabe des Nominierungsprotokoll, das im nächsten Unterabschnitt beschrieben wird. Genau dann, wenn ein Knoten die Vorbereitung ⟨n,x⟩ erfolgreich bestätigt In Stimmzettel n versucht es eine föderierte Abstimmung über Commit ⟨n,x⟩. Wenn Wenn dies gelingt, bedeutet dies, dass der SCP eine Entscheidung getroffen hat und der Knoten etwas ausgibt der Wert aus der bestätigten Commit-Anweisung. Betrachten Sie eine ineinander verschlungene Menge S. Da höchstens ein Wert Kann von Mitgliedern von S in einem bestimmten Wahlgang bestätigt werden, es dürfen keine zwei unterschiedlichen Werte bestätigt werden Mitglieder von S in einem bestimmten Wahlgang. Darüber hinaus, wenn commit ⟨n,x⟩ bestätigt ist, dann Prepare ⟨n,x⟩wurde ebenfalls bestätigt; seitdem Prepare ⟨n,x⟩ widerspricht jedem früheren Commit für einen anderen Wert, da die Vereinbarung eine föderierte Abstimmung garantiert Wir erhalten, dass früher kein anderer Wert festgelegt werden darf Stimmzettel durch Mitglieder von S. Durch Einleitung der Stimmzettelnummern, wir Stellen Sie daher sicher, dass SCP sicher ist. Betrachten Sie für die Lebendigkeit einen intakten Satz I und einen ausreichend langen Satz synchroner Stimmzettel n. Wenn fehlerhafte Knoten in den Slices auftreten von gut erzogenen Knoten stören sich nicht an n, dann per Stimmzettel n + 1 alle Mitglieder von I haben die gleiche Menge P von Prepare-Anweisungen bestätigt. Wenn P = ∅und Stimmzettel n lang genug war, ist der Das Nominierungsprotokoll wird sich auf einen Wert x konvergiert haben. Andernfalls sei x der Wert aus dem Plan mit der höchsten Abstimmung in P. In jedem Fall werde ich es einheitlich mit dem Verbund versuchen Abstimmung über die Vorbereitung von ⟨n + 1,x⟩ im nächsten Wahlgang. Deshalb, wenn n + 1 ebenfalls synchron ist, folgt zwangsläufig eine Entscheidung für x. 3.2.2 Nominierung Die Nominierung erfordert eine gemeinsame Abstimmung über Stellungnahmen: • x nominieren – gibt an, dass x ein gültiger Entscheidungskandidat ist. Knoten können dafür stimmen, mehrere Werte zu nominieren – unterschiedliche Nominate-Aussagen sind nicht widersprüchlich. Allerdings einmal Bestätigt ein Knoten eine Nominierungsaussage, stimmt er nicht mehr dafür ab neue Werte benennen. Die föderierte Abstimmung ermöglicht es einem Knoten weiterhin Bestätigen Sie die Aussagen der neuen Nominierten, für die sie nicht gestimmt hat abstimmen oder annehmen a vom Kollegium akzeptiere a vom Kollegium a ist gültig akzeptiere ein von Sperrsatz unverbindlich stimmte a akzeptiert a bestätigt a stimmte mit ¬a Abbildung 1. Phasen der föderierten Abstimmung ermöglicht es Mitgliedern eines intakten Sets, sich gegenseitig zu bestätigen nominierten Werte, während gleichzeitig neue Stimmen zurückgehalten werden. Das (sich entwickelnde) Ergebnis der Nominierung ist eine deterministische Kombination aller Werte in bestätigten Nominierungsaussagen. Wenn x stellt eine Reihe von Transaktionen dar, Knoten können die Vereinigung annehmen von Mengen, die größte Menge oder die mit dem höchsten hash, also solange alle Knoten dasselbe tun. Weil Knoten Neues zurückhalten Stimmen nach Bestätigung einer Nominierungserklärung, der Satz von bestätigte Aussagen können nur endlich viele Werte enthalten. Die Tatsache, dass sich bestätigte Aussagen zuverlässig verbreiten Intakte Mengen bedeuten, dass intakte Knoten schließlich auf dem zusammenlaufen der gleiche Satz nominierter Werte und damit das gleiche Nominierungsergebnis, allerdings an einem unbekannten Punkt, willkürlich spät im Protokoll. Knoten verwenden eine föderierte Leiterauswahl, um die zu reduzieren Anzahl unterschiedlicher Werte in Nominate-Anweisungen. Nur Ein Anführer, der noch nicht für eine Nominierungserklärung gestimmt hat, kann ein neues x einführen. Andere Knoten warten darauf, von ihnen zu hören Führer und kopieren Sie einfach die (gültigen) Nominierungsstimmen ihrer Führer. Um Misserfolgen entgegenzuwirken, wächst die Gruppe der Führungskräfte immer weiter Es kommt zu Zeitüberschreitungen, obwohl in der Praxis nur wenige Knoten neue Werte von x einführen. 3.2.3 Föderierte Abstimmung Bei der föderierten Abstimmung wird ein dreiphasiges Protokoll verwendet, das in gezeigt wird Abbildung 1. Knoten versuchen zunächst, sich auf abstrakte Aussagen zu einigen Abstimmung, dann Annahme und schließlich Bestätigung von Aussagen. Ein Knoten v kann für jede gültige Anweisung a stimmen, die dies nicht tut dem anderen widersprechenausstehende Stimmen und angenommene Stellungnahmen. Dies geschieht durch die Ausstrahlung einer unterzeichneten Abstimmungsnachricht. v akzeptiert dann a, wenn a mit anderen akzeptierten Aussagen übereinstimmt und entweder (Fall 1)v Mitglied eines Quorums ist, in dem jeder Knoten stimmt entweder für a oder akzeptiert a, oder (Fall 2) auch wenn v habe nicht für a gestimmt, ein V-Blocking-Set akzeptiert a. Im Fall 2 kann v haben zuvor Stimmen abgegeben, die einem widersprechen, was jetzt der Fall ist überstimmt worden. v darf überstimmte Stimmen vergessen und tun Sie so, als hätte es sie nie gewirkt, weil ifv intakt ist, es weiß es Überstimmte Stimmen können kein Quorum durch Fall 1 vervollständigen. v sendet, dass es a akzeptiert, und bestätigt dann a, wenn es drin ist ein Quorum, das einstimmig annimmt. Abbildung 2 zeigt die Wirkung von V-Blocking-Sets und des Kaskadensatzes während föderierte Abstimmung. Zwei miteinander verflochtene Knoten können widersprüchliche Aussagen nicht bestätigen, da sich die beiden erforderlichen Quoren einen teilen müsstenSchnelle und sichere globale Zahlungen mit Stellar SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada 3 4 2 1 5 7

Abstimmung X

Stimme Y (a) 3 4 2 1 5 7 6 Abstimmung X Abstimmung X Abstimmung X Abstimmung Y Abstimmung X Abstimmung Y Abstimmung Y (b) 3 4 2 1 5 7 6 Akzeptiere X Abstimmung X Akzeptiere X Abstimmung Y Akzeptiere X Abstimmung Y Abstimmung Y (c) 3 4 2 1 5 7 6 Akzeptiere X Akzeptiere X Akzeptiere X Abstimmung Y Akzeptiere X Akzeptiere X Abstimmung Y (d) 3 4 2 1 5 7 6 Akzeptiere X Abstimmung X Akzeptiere X Akzeptiere X Akzeptiere X Akzeptiere X Akzeptiere X (e) Abbildung 2. Kaskadeneffekt bei der föderierten Abstimmung. Jeder Knoten verfügt über einen Quorum-Slice, der den Mitgliedern des Slice durch Pfeile angezeigt wird. (a) Widersprüchliche Aussagen X und Y werden eingeführt. (b) Knoten stimmen für gültige Aussagen. (c) Knoten 1 akzeptiert X nach Erreichen seines Quorums {1, 2, 3, 4} stimmt einstimmig für X. (d) Knoten 1, 2, 3 und 4 akzeptieren alle X; Satz {1} ist 5-blockierend, also akzeptiert Knoten 5 X und überstimmt seine vorherige Stimme für Y. (e) Satz {5} ist 6- und 7-blockierend, also akzeptieren 6 und 7 beide X. nicht fehlerhafter Knoten, der widersprüchliche Aussagen nicht akzeptieren konnte. Eine Bestätigung einer Aussage ist nicht gewährleistet: in Im Falle einer getrennten Abstimmung können beide Aussagen dauerhaft sein Ich muss in der Abstimmungsphase auf ein Quorum warten. Wenn jedoch ein Knoten in einer intakten Menge I bestätigt eine Aussage, die Kaskade Satz und akzeptiere Fall 2 stellen sicher, dass ich irgendwann alles tun werde bestätige diese Aussage. 3.2.4 Abstimmungssynchronisierung Wenn Knoten nicht in der Lage sind, eine Commit-Anweisung für zu bestätigen Aktueller Wahlgang, sie geben nach einer Auszeit auf. Die Zeitüberschreitung wird angezeigt mit jedem Wahlgang länger, um sich an willkürliche Grenzen anzupassen auf Netzwerkverzögerung. Timeouts allein reichen jedoch nicht aus, um Stimmzettel von Knoten zu synchronisieren, die nicht gleichzeitig gestartet sind oder wurde aus anderen Gründen desynchronisiert. Um eine Synchronisierung zu erreichen, starten Knoten den Timer erst, wenn sie Teil eines Knotens sind Quorum, das bei der aktuellen (oder einer späteren) Abstimmung gilt. Dies verlangsamt Knoten, die früh gestartet sind, und stellt sicher, dass keine Mitglied einer intakten Gruppe bleibt zu weit vor der Gruppe. Darüber hinaus, wenn ein Knoten v zu einem späteren Zeitpunkt jemals einen v-blockierenden Satz bemerkt Stimmzettel, es springt sofort zum niedrigsten Stimmzettel, so dass dieser Dies ist unabhängig von etwaigen Timern nicht mehr der Fall. Die Kaskade Der Satz stellt dann sicher, dass alle Nachzügler aufholen. Das Ergebnis ist, dass die Stimmzettel während eines ganzen Zeitraums ungefähr synchronisiert sind gesetzt, sobald das System synchron wird. 3.2.5 Auswahl des föderierten Anführers Durch die Auswahl von Anführern kann jeder Knoten Anführer in einem solchen Netzwerk auswählen So wählen Knoten im Allgemeinen nur eine oder eine kleine Anzahl aus von Führungskräften. Um dem Versagen des Leiters Rechnung zu tragen, erfolgt die Auswahl des Leiters geht durch Runden. Wenn Anführer der aktuellen Runde scheinen ihrer Verantwortung nicht nachzukommen, dann nach a Bestimmte Timeout-Knoten gehen in die nächste Runde über Erweitern Sie die Gruppe der Führungskräfte, denen sie folgen. Jede Runde verwendet zwei einzigartige kryptografische hash-Funktionen, H0 und H1, die Ganzzahlen im Bereich [0,hmax) ausgeben. Zum Beispiel verwendet Stellar Hi(m) = SHA256(i∥b∥r ∥m), wobei b ist die gesamte SCP-Instanz (Block- oder Ledger-Nummer), r ist die Anzahl der Leader-Auswahlrunden und hmax = 2256. Innerhalb In einer Runde definieren wir die Priorität von Knoten v als: Priorität(v) = H1(v) Jeder Knoten würde einen Strohmann als Anführer wählen der Knoten mit der höchsten Priorität (v). Dieser Ansatz funktioniert gut mit nahezu identischen Quorum-Slices, funktioniert aber nicht richtig Erfassen Sie die Bedeutung von Knoten in unausgeglichenen Konfigurationen. Wenn beispielsweise Europa und China jeweils 3 beitragen Knoten zu jedem Quorum, aber China betreibt 1.000 Knoten und Europa 4, dann wird China den Knoten mit der höchsten Priorität haben 99,6 % der Zeit. Wir führen daher einen Begriff des Scheibengewichts ein, wo Weight(u,v) ∈[0, 1] ist der Bruchteil der Quorum-Slices des Knotens u enthält den Knoten v. Wenn der Knoten u einen neuen Anführer auswählt, wird er berücksichtigt nur Nachbarn, die wie folgt definiert sind: Nachbarn(u) = { v | H0(v) < hmax · Gewicht(u,v) } Ein Knoten beginnt dann mit einem leeren Satz von Anführern und zwar bei jedem Runde fügt den Knoten v in Nachbarn (u) mit dem höchsten hinzu Priorität(v). Wenn die Menge der Nachbarn in einer Runde leer ist, fügt u stattdessen den Knoten v mit dem niedrigsten Wert von H0(v)/Gewicht(u,v) hinzu.

Formale Überprüfung des SCP

Um Konstruktionsfehler auszuschließen, haben wir die Sicherheit von SCP offiziell überprüft und Lebendigkeitseigenschaften (siehe [65]). Konkret haben wir es überprüft dass ineinander verschlungene Knoten niemals anderer Meinung sind und dass unter den unten diskutierten Bedingungen jedes Mitglied einer intakten Menge letztendlich entscheidet. Interessanterweise ergab die Überprüfung, dass die Bedingungen, unter denen SCP Lebendigkeit garantiert, sind subtil, und stärker als zunächst angenommen [68]: wie unten besprochen, bösartige Knoten, die das Timing unbefugt manipulieren Abweichungen vom Protokoll müssen möglicherweise manuell entfernt werden aus Quorum-Slices.

SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Lokhava et al. Um sicherzustellen, dass die bewährten Eigenschaften möglichst erhalten bleiben FBA-Konfigurationen und -Ausführungen betrachten wir als beliebig Anzahl der Knoten mit beliebigen lokalen Konfigurationen. Dies umfasst Szenarien mit disjunkten intakten Mengen sowie potenziell unendlich langen Ausführungen. Der Nachteil ist, dass wir stehen vor dem herausfordernden Problem der Verifizierung einer parametrisierten System mit unendlichen Zuständen. Um die Überprüfung nachvollziehbar zu halten, haben wir SCP in First-Order-Logik (FOL) unter Verwendung von Ivy [69] und der Methodik von [82] modelliert. Der Verifizierungsprozess besteht aus der manuellen Bereitstellung induktiver Vermutungen, die dann automatisch überprüft werden Efeu. Das FOL-Modell von SCP abstrahiert einige Aspekte von FBA-Systeme, die in FOL schwer zu handhaben sind (z. B. das Der Kaskadensatz wird als Axiom genommen), also überprüfen wir das Solidität der Abstraktion unter Verwendung von Isabelle/HOL [75]. Nachdem wir das Verifizierungsproblem in FOL ausgedrückt haben, verifizieren wir die Sicherheit, indem wir eine induktive Invariante bereitstellen. Das Induktive Invariante besteht aus einem Dutzend einzeiliger Vermutungen für etwa 150 Zeilen Protokollspezifikation. Anschließend spezifizieren wir die Lebendigkeitseigenschaften von SCP in Ivys linearer zeitlicher Logik und verwenden die Reduzierung der Lebendigkeit auf Sicherheit von [80, 81] zur Reduzierung der Lebendigkeit Verifikationsproblem zum Problem, eine Induktion zu finden invariant. Während die Sicherheit von SCP relativ einfach ist beweisen, dass das Lebendigkeitsargument von SCP viel komplizierter ist und besteht aus etwa 150 einzeiligen Invarianten. Der Nachweis der Lebendigkeit erforderte eine genaue Formalisierung des Annahmen, unter denen SCP die Beendigung sicherstellt. Wir dachten zunächst, dass ich einen intakten Satz immer beenden würde, wenn alle vorhanden wären Mitglieder haben fehlerhafte Knoten aus ihren Slices [68] entfernt. Dies erwies sich jedoch als unzureichend: ein braves (aber nicht intakt) Knoten in einem Quorum eines Mitglieds von I can, unter dem Einfluss fehlerhafter Knoten, Beendigung durch Abschluss verhindern ein Quorum kurz vor dem Ende eines Wahlgangs, wodurch verursacht wird Mitglieder von I sollen im nächsten Wahlgang andere Werte für x wählen. Wir müssen daher zusätzlich davon ausgehen, dass informell Jeder Knoten in einem Quorum eines Mitglieds von I. schließlich auch kommt pünktlich oder sendet über einen ausreichenden Zeitraum überhaupt keine Nachrichten. In der Praxis bedeutet dies, dass Mitglieder von I may müssen ihre Slices anpassen, bis die Bedingung erfüllt ist. Dies Das Problem ist bei FBA-Systemen nicht inhärent: Losa et al. [47] vorhanden ein Protokoll, dessen Lebendigkeit von den strikt Schwächeren abhängt Annahmen lediglich einer eventuellen Synchronität und einer eventuellen Leaderelection, ohne dass fehlerhafte Knoten aus den Slices entfernt werden müssen.

Zahlungsnetzwerk

In diesem Abschnitt wird das Zahlungsnetzwerk von Stellar beschrieben, das als replizierte Zustandsmaschine [88] auf SCP implementiert ist. 5.1 Ledger-Modell Das Hauptbuch von Stellar basiert auf einer Kontoabstraktion (in Im Gegensatz zur eher münzenzentrierten nicht ausgegebenen Transaktionsausgabe oder UTXO Modell von Bitcoin). Der Hauptbuchinhalt besteht aus a Satz von Hauptbucheinträgen aus vier verschiedenen Typen: Konten, Treuhandlinien, Angebote und Kontodaten. Konten sind die Auftraggeber, die Vermögenswerte besitzen und ausgeben. Jeder Das Konto wird durch einen öffentlichen Schlüssel benannt. Standardmäßig kann der entsprechende private Schlüssel Transaktionen für das Konto signieren. Konten können jedoch neu konfiguriert werden, um andere Unterzeichner hinzuzufügen und den Schlüssel, der das Konto benennt, mit einem zu deaktivieren „Multisig“-Option, um mehrere Unterzeichner zu erfordern. Jedes Konto enthält außerdem: eine Sequenznummer (in Transaktionen enthalten). um eine Wiederholung zu verhindern), einige Flags und ein Gleichgewicht in einer „nativen“ Vorab erstellte Kryptowährung namens XLM, die Abhilfe schaffen soll einige Denial-of-Service-Angriffe und erleichtern das Market-Making als neutrale Währung. Trustlines verfolgen das Eigentum an ausgegebenen Vermögenswerten benannt durch ein Paar bestehend aus dem ausstellenden Konto und einem Short Anlagecode (z. B. „USD“ oder „EUR“). Jede Vertrauenslinie gibt an ein Konto, ein Vermögenswert, der Kontostand in diesem Vermögenswert, a Grenze, über die der Saldo nicht steigen kann, und einige Flaggen. Ein Konto muss dem Halten eines Vermögenswerts ausdrücklich zustimmen Erstellen einer Vertrauenslinie, um Spammer daran zu hindern, sich anzumelden Konten mit unerwünschten Vermögenswerten. Die KYC-Vorschriften (Know Your Customer) verlangen von vielen Finanzinstituten, dass sie wissen, wessen Einlagen sie halten. zum Beispiel durch die Überprüfung des Lichtbildausweises. Zur Einhaltung können Emittenten festlegen ein optionales auth_reqired-Flag auf ihren Konten, das den Besitz der von ihnen ausgegebenen Vermögenswerte auf autorisierte Konten beschränkt. Um eine solche Autorisierung zu erteilen, legt der Emittent eine Autorisierung fest Markieren Sie die Vertrauenslinien der Kunden. Angebote entsprechen der Bereitschaft eines Kontos, nach oben zu handeln einen bestimmten Betrag eines bestimmten Vermögenswerts für einen anderen zu einem bestimmten Zeitpunkt zu übertragen Preis im Auftragsbuch; Sie werden automatisch abgeglichen und gefüllt, wenn sich Kauf-/Verkaufspreise kreuzen. Schließlich bestehen Kontodaten aus Konto-, Schlüssel- und Werttripeln, die den Kontoinhabern ermöglichen um kleine Metadatenwerte zu veröffentlichen. Um Ledger-Spam zu verhindern, gibt es ein XLM-Mindestguthaben. als Reserve bezeichnet. Die Reserve eines Kontos erhöht sich mit jedem zugeordneten Hauptbucheintrag und verringert sich, wenn der Hauptbucheintrag erfolgt verschwindet (z. B. wenn eine Bestellung ausgeführt oder storniert wird oder wenn a Trustline wird gelöscht). Derzeit wächst die Reserve um 0,5 XLM (∼0,03 $) pro Hauptbucheintrag. Unabhängig von der Reserve ist es so Es ist möglich, durch Löschung den gesamten Wert eines Kontos zurückzufordern es mit einer AccountMerge-Operation. Ein Hauptbuchkopf, wie in Abbildung 3 dargestellt, speichert globale Attribute: eine Hauptbuchnummer, Parameter wie der Reservesaldo pro Hauptbucheintrag, ein hash des vorherigen Hauptbuchkopfes (eigentlich mehrere hashes, die eine Skiplist bilden), einschließlich der SCP-Ausgabe a hash neuer Transaktionen, die in diesem Hauptbuch angewendet wurden, a hash von die Ergebnisse dieser Transaktionen (z. B. Erfolg oder Misserfolg für jeweils) und eine Momentaufnahme hash aller Hauptbucheinträge. Da der Snapshot hash alle Hauptbuchinhalte enthält, validators müssen den Verlauf nicht aufbewahren, um Transaktionen zu validieren. Allerdings ist mit einer Skalierung auf Hunderte Millionen zu rechnen Konten können wir nicht alle Hauptbucheintragstabellen für alle neu erstellen Hauptbuch schließen. Darüber hinaus ist es nicht praktikabel, ein Hauptbuch zu übertragenSchnelle und sichere globale Zahlungen mit Stellar SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Hauptbuch # = 4 H(vorheriges HDR) SCP-Ausgabe H∗(Ergebnisse) H∗(Schnappschuss) ... Kopfzeile Hauptbuch # = 5 H(vorheriges HDR) SCP-Ausgabe H∗(Ergebnisse) H∗(Schnappschuss) ... Kopfzeile . . . Abbildung 3. Hauptbuchinhalte. H ist SHA-256, während H ∗ eine hierarchische oder rekursive Anwendung von H darstellt. SCP-Ausgabe Hängt auch vom vorherigen Header hash ab. Konto erstellen Erstellen und finanzieren Sie einen neuen Kontoeintrag Kontozusammenführung Kontobucheintrag löschen SetOptions Kontokennzeichnungen und Unterzeichner ändern Zahlung Zahlen Sie eine bestimmte Menge an Vermögenswerten an das Ziel. Konto. PathPayment Wie „Zahlung“, aber zahlen Sie in einem anderen Guthaben ein (aufwärts). begrenzen); Geben Sie bis zu 5 zwischengeschaltete Vermögenswerte an Angebot verwalten Angebotsbucheintrag erstellen/löschen/ändern, -Passives Angebot mit passiver Variante, um eine Nullausbreitung zu ermöglichen Daten verwalten Konto erstellen/löschen/ändern Datenbucheintrag ChangeTrust Trustline erstellen/löschen/ändern AllowTrust Setzen oder löschen Sie das Autorisierungskennzeichen auf der Trustline BumpSequence Erhöhen Sie die Folge. Nummer auf dem Konto Abbildung 4. Hauptbuchoperationen dieser Größe jedes Mal, wenn die Verbindung zu einem Knoten getrennt wurde zu lange im Netzwerk. Der Snapshot hash ist daher Entwickelt, um sowohl den hashing als auch den Zustandsabgleich zu optimieren. Konkret werden in der Momentaufnahme die Hauptbucheinträge nach Zeit geschichtet der letzten Änderung in einer Reihe exponentiell großer Container sogenannte Eimer. Die Ansammlung von Eimern wird Eimer genannt Liste und weist eine gewisse Ähnlichkeit mit logarithmisch strukturierten Zusammenführungsbäumen auf (LSM-Bäume) [77]. Die Bucket-Liste wird während der Transaktionsverarbeitung nicht gelesen (siehe Abschnitt 5.4). Daher bestimmtes Design Aspekte von LSM-Bäumen können gelockert werden. Insbesondere zufällig Ein Zugriff per Schlüssel ist nicht erforderlich und Buckets werden immer nur gelesen nacheinander im Rahmen der Zusammenführung von Ebenen. Den Eimer hashen Die Liste wird erstellt, indem jeder Bucket beim Zusammenführen hash wird und ein neuer kumulativer hash der Bucket-hashes berechnet wird (ein kleiner, fester Referenzindex hashes) bei jedem Ledgerabschluss. Der Abgleich der Bucket-Liste nach der Trennung erfordert einen Download nur Eimer, die sich unterscheiden. 5.2 Transaktionsmodell Eine Transaktion besteht aus einem Quellkonto, Gültigkeitskriterien, a Memo und eine Liste von einem oder mehreren Vorgängen. Abbildung 4 listet die verfügbaren Operationen auf. Jeder Vorgang verfügt über ein Quellkonto, das Der Standardwert ist der der gesamten Transaktion. Eine Transaktion muss mit Schlüsseln signiert sein, die jedem Quellkonto in entsprechen eine Operation. Multisig-Konten können eine höhere Signierung erfordern Gewicht für einige Operationen (z. B. SetOptions) und niedriger für andere (z. B. AllowTrust). Transaktionen sind atomar – wenn eine Operation fehlschlägt, keine davon sie ausführen. Dies vereinfacht Mehrweggeschäfte. Angenommen, ein Der Emittent erstellt einen Vermögenswert, um Landurkunden darzustellen, und Benutzer A möchte ein kleines Grundstück plus 10.000 US-Dollar gegen ein tauschen größeres Grundstück im Besitz von B. Die beiden Nutzer können beide unterzeichnen eine einzelne Transaktion mit drei Vorgängen: zwei Grundstücke Zahlungen und Ein-Dollar-Zahlung. Das wichtigste Gültigkeitskriterium einer Transaktion ist ihre Sequenznummer, die um eins größer sein muss als die der Transaktion Hauptbucheintrag des Quellkontos. Eine gültige Transaktion ausführen (erfolgreich oder nicht) erhöht die Sequenznummer und verhindert so die Wiedergabe. Die anfänglichen Sequenznummern enthalten das Hauptbuch Nummer in den hohen Bits, um eine erneute Wiedergabe auch nach dem Löschen zu verhindern und ein Konto neu erstellen. Das andere Gültigkeitskriterium ist eine optionale Begrenzung des Zeitpunkts Eine Transaktion kann ausgeführt werden. Zurück zum Land und zum Dollar Swap oben: Wenn A die Transaktion vor B unterzeichnet, kann A dies möglicherweise nicht tun Ich möchte, dass B die Transaktion ein Jahr lang abwartet, bevor sie sie einreicht Dies könnte dazu führen, dass eine Frist gesetzt wird, die die Transaktion ungültig macht nach ein paar Tagen. Es können auch Multisig-Konten konfiguriert werden um der Enthüllung eines hash Vorbildes signierendes Gewicht zu verleihen, Dies ermöglicht in Kombination mit Zeitgrenzen den atomaren Cross-Chain-Handel [1]. Das Quellkonto einer Transaktion zahlt eine geringe Gebühr in XLM. 10−5 XLM, es sei denn, es liegt eine Überlastung vor. Unter Stau ist die Die Betriebskosten werden durch eine niederländische Auktion festgelegt. Validatoren sind nicht durch Gebühren kompensiert, da validators analog sind zu Bitcoin vollständigen Knoten, nicht zu Minern. Anstatt XLM zu zerstören, Die Gebühren werden recycelt und anteilig durch Abstimmung verteilt bestehende XLM-Inhaber, die im Nachhinein möglicherweise oder könnten war die Komplexität nicht wert. 5.3 Konsenswerte Für jedes Hauptbuch verwendet Stellar SCP, um eine Datenstruktur zu vereinbaren mit drei Feldern: einem Transaktionssatz hash (einschließlich eines hash des vorherigen Ledger-Kopfes), ein Abschlusszeitpunkt, eind Upgrades. Wenn mehrere Werte als bestätigt bestätigt werden, wird Stellar übernommen der Transaktionssatz mit den meisten Operationen (Unterbrechung von Bindungen). nach Gesamtgebühren, dann Transaktionssatz hash), die Vereinigung aller Upgrades und die höchste Schließzeit. Eine enge Zeit ist nur gültig, wenn es zwischen dem Abschlusszeitpunkt des letzten Hauptbuchs und dem liegt vorhanden, sodass Knoten keine ungültigen Zeiten nominieren. Durch Upgrades werden globale Parameter wie der Reservesaldo, die Mindestbetriebsgebühr und die Protokollversion angepasst. Wann Während der Nominierung werden höhere Gebühren und Protokollversionsnummern kombiniert und ersetzen niedrigere. Upgrades wirken sich auf die Governance durch einen Streitraum mit gemeinsamer Abstimmung aus [34], aber auch nicht weder egalitär noch zentralisiert. Jeder validator ist konfiguriert als entweder regierend oder nicht regierend (Standardeinstellung). davon, ob sein Betreiber sich an der Governance beteiligen möchte. Die validators berücksichtigen drei Arten von Upgrades: erwünscht, gültig und ungültig (alles, was validator nicht tut).

SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Lokhava et al. validator Kern Horizont FS DB DB einreichen Kunde Kunde andere validators Abbildung 5. Stellar validator Architektur wissen, wie man es umsetzt). Gewünschte Upgrades werden konfiguriert Auslöser zu einem bestimmten Zeitpunkt, der koordiniert werden soll Betreiber. Regierende Knoten stimmen immer für die Nominierung der gewünschten Personen Upgrades akzeptieren, aber nicht stimmen, um gültige Upgrades zu nominieren (d. h. einem Sperrquorum zustimmen) und niemals dafür stimmen oder ungültige Upgrades akzeptieren. Nicht regierendes validators-Echo Jede Stimme, die sie für ein gültiges Upgrade sehen, delegiert im Wesentlichen Die Entscheidung darüber, welche Upgrades gewünscht werden, liegt bei denjenigen, die sich dafür entscheiden für eine Führungsrolle. 5.4 Umsetzung Abbildung 5 zeigt die validator-Architektur von Stellar. Ein Dämon namens stellar-core (ca. 92.000 Zeilen C++, ohne Bibliotheken von Drittanbietern) implementiert das SCP-Protokoll und die replizierte Zustandsmaschine. Um Werte für SCP zu erzeugen, muss eine große Anzahl von Hauptbucheinträgen auf kleine kryptografische Werte reduziert werden hashes. Im Gegensatz dazu Transaktionsvalidierung und -ausführung erfordert die Suche nach Kontostatus und Auftragsabgleich unter der beste Preis. Um beide Funktionen effizient zu erfüllen, stellar-core Behält zwei Darstellungen des Ledgers: eine externe Darstellung, die die Bucket-Liste enthält und als Binärdateien gespeichert wird kann effizient aktualisiert und inkrementell rehashed werden, und eine interne Darstellung in einer SQL-Datenbank (PostgreSQL für Produktionsknoten). Stellar-core erstellt ein schreibgeschütztes Verlaufsarchiv mit Jeder Transaktionssatz, der bestätigt wurde, und Snapshots davon Eimer. Das Archiv ermöglicht es neuen Knoten, sich selbst zu booten beim Beitritt zum Netzwerk. Es bietet auch eine Aufzeichnung des Hauptbuchs Geschichte – es muss einen Ort geben, an dem man nachschlagen kann Transaktion von vor zwei Jahren. Da der Verlauf nur angehängt werden kann Da es selten genutzt wird und selten darauf zugegriffen wird, kann es an günstigen Orten aufbewahrt werden wie Amazon Glacier oder jeder andere Dienst, der das Speichern ermöglicht und Flatfiles abrufen. Validator-Hosts hosten normalerweise nicht ihre eigenen Archive, um jegliche Auswirkungen auf die Validierung zu vermeiden Leistung aus dem Dienst der Geschichte. Um den Sternkern einfach zu halten, ist er nicht für die Verwendung vorgesehen direkt durch Anwendungen und stellt nur eine sehr schmale Schnittstelle für die Übermittlung neuer Transaktionen bereit. Zur Unterstützung Clients führen die meisten validators einen Daemon namens Horizon aus (∼18k Zeilen von Go), die eine HTTP-Schnittstelle zum Senden bereitstellt und Lernen von Transaktionen. Horizon hat nur Lesezugriff auf Die SQL-Datenbank von stellar-core minimiert das Risiko von Horizon Destabilisierender Sternenkern. Funktionen wie die Zahlungspfadfindung sind vollständig in Horizon implementiert und können erweitert werden einseitig ohne Abstimmung mit anderen validators. Mehrere optionale Daemons höherer Ebenen sind Clients für Horizon und runden das Ökosystem ab. Ein Bridge-Server erleichtert dies Integration von Stellar in bestehende Systeme, z. B. Verbuchung von Benachrichtigungen über alle auf einem bestimmten Konto eingegangenen Zahlungen. A Der Compliance-Server bietet Hooks für Finanzinstitute Austausch und Genehmigung von Absender- und Empfängerinformationen zu Zahlungen, zur Einhaltung von Sanktionslisten. Schließlich, Ein Verbundserver implementiert eine für Menschen lesbare Benennung System für Konten. 6 Bereitstellungserfahrung Stellar entwickelte sich über mehrere Jahre zu einem Staat mit gemäßigtem Anzahl einigermaßen zuverlässiger Full-Node-Betreiber. Allerdings Die Konfigurationen der Knoten waren so, dass Lebendigkeit (obwohl nicht Sicherheit) hing von uns ab, der Stellar Development Foundation (SDF); SDF war plötzlich verschwunden, andere Knotenbetreiber hätte eingreifen und uns manuell entfernen müssen von Quorum-Slices, damit das Netzwerk fortfahren kann. Während wir und viele andere die systemische Bedeutung von SDF reduzieren wollen, hat dieses Ziel seitdem immer mehr Priorität erhalten Forscher [58] quantifizierten und veröffentlichten die Zentralisierung des Netzwerks, ohne die Risiken für Sicherheit und Sicherheit zu differenzieren Lebendigkeit. Eine Reihe von Betreibern reagierte mit aktiven Konfigurationsanpassungen, vor allem mit der Vergrößerung ihrer Anlagen Quorum-Scheiben, um die Bedeutung der SDF abzuschwächen; Ironischerweise erhöhte dies nur das Risiko für die Lebendigkeit. Zwei Probleme verschärften die Situation. Erstens ein beliebter Das Überwachungstool [5] eines Drittanbieters Stellar wurde systematisch durchgeführt Überschätzung der Betriebszeit von validator durch nicht tatsächliche Überprüfung dieser Sternenkern lief; Dies führte dazu, dass Menschen einbezogen wurden unzuverlässige Knoten in ihren Quorum-Slices. Zweitens ein Fehler Stellar-Core bedeutete, dass einmal ein validator in das nächste Hauptbuch verschoben wurde, Es hat den verbleibenden Knoten nicht ausreichend dabei geholfen, die Previ abzuschließenNotieren Sie sich Ihr Konto für den Fall, dass Nachrichten verloren gehen. Infolgedessen ist die Das Netzwerk hatte eine Ausfallzeit von 67 Minuten und war erforderlich manuelle Koordination durch validator-Administratoren zum Neustart. Schlimmer noch: Beim Versuch, das Netzwerk neu zu starten, kam es gleichzeitig zu überstürzten Neukonfigurationen auf mehreren Knoten in einer kollektiven Fehlkonfiguration, die es einigen Knoten ermöglichte divergieren, was ein manuelles Herunterfahren dieser Knoten erfordert und Wiedervorlage der während der Divergenz akzeptierten Transaktionen. Glücklicherweise wurde diese Abweichung erkannt und korrigiert schnell und enthielt keine widersprüchlichen Transaktionen, aber die Risiko, dass das Netzwerk die Quorum-Überschneidung nicht erreicht – Spaltung unter gleichzeitiger Akzeptanz potenzieller Konflikte Transaktionen, einfach aufgrund einer Fehlkonfiguration, wurden durchgeführt sehr konkret durch diesen Vorfall. Die Überprüfung dieser Erfahrungen führte zu zwei wichtigen Schlussfolgerungen und entsprechende Korrekturmaßnahmen.Schnelle und sichere globale Zahlungen mit Stellar SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Kritisch, 100 % 51 % 51 % Hoch, 67 % 51 % Mittel, 67 % 51 % Niedrig, 67 % 51 % 51 % ... ... ... 51 % ... 51 % Abbildung 6. Qualitätshierarchie des Validators. Knoten höchster Qualität erfordern den höchsten Schwellenwert von 100 %, während niedrigere Qualitäten auf einen Schwellenwert von 67 % konfiguriert sind. Knoten innerhalb eines einzigen Für die Organisation ist eine einfache Mehrheit von 51 % erforderlich. 6.1 Komplexität und Fragilität der Konfiguration Stellar drückt Quorum-Slices als verschachtelte Quorum-Sets aus, die aus n Einträgen und einem Schwellenwert k bestehen, wobei jeder Satz von k Einträgen besteht stellt einen Quorum-Slice dar. Jeder der n Einträge ist dann entweder ein öffentlicher Schlüssel validator oder, rekursiv, ein anderer Quorumsatz. Obwohl es flexibel und kompakt ist, haben wir ein verschachteltes Quorum realisiert Sets boten den Knotenbetreibern gleichzeitig zu viel Flexibilität und zu wenig Anleitung: Es war leicht, unsichere (bzw auch unsinnige) Konfigurationen. Die Kriterien für die Gruppierung Knoten in Mengen, zum Organisieren von Teilmengen in einer Hierarchie und zur Auswahl der Schwellenwerte waren alle nicht ausreichend klar und trugen zu Betriebsausfällen bei. Es war nicht klar, ob Behandeln Sie eine „Ebene“ in der Hierarchie der verschachtelten Mengen als eine Vertrauensebene. oder eine Organisation oder beides; viele Konfigurationen im Feld vermischte diese Konzepte zusätzlich zur Angabe gefährlicher oder bedeutungslose Schwellenwerte. Wir haben daher einen einfacheren Konfigurationsmechanismus hinzugefügt das zwei Aspekte verschachtelter Quorum-Sets trennt: Gruppierung Knoten nach Organisation zusammenfassen und jede Organisation mit einer einfachen Vertrauensklassifizierung (niedrig, mittel, hoch usw.) kennzeichnen kritisch). Organisationen auf und über hoher Ebene sind dazu verpflichtet Geschichtsarchive veröffentlichen. Das neue System synthetisiert verschachtelte Quorum-Sets, in denen jede Organisation als eine dargestellt wird Es wurde ein Schwellenwert von 51 % festgelegt und Organisationen werden in Gruppen eingeteilt mit 67 %- oder 100 %-Schwellenwerten (abhängig von der Gruppenqualität). Jede Gruppe ist ein einzelner Eintrag in der nächsten (höherwertigen) Gruppe. wie in Abbildung 6 dargestellt. Dieses vereinfachte Modell reduziert die Wahrscheinlichkeit einer Fehlkonfiguration, sowohl hinsichtlich der Struktur der synthetisierten verschachtelten Mengen und der dafür gewählten Schwellenwerte Jeder Satz. 6.2 Proaktive Erkennung von Fehlkonfigurationen Zweitens haben wir erkannt, dass es zu spät ist, kollektive Fehlkonfigurationen zu erkennen, indem man auf die Beobachtung ihrer negativen Auswirkungen wartet. Insbesondere im Hinblick auf Fehlkonfigurationen, die abweichen können – a schwerwiegenderer Fehlermodus als Anhalten – das Netzwerk benötigt um in der Lage zu sein, Fehlkonfigurationen sofort zu erkennen, so dass Bediener sie rückgängig machen können, bevor es tatsächlich zu Abweichungen kommt. Um diesem Bedarf gerecht zu werden, haben wir einen Mechanismus in die Software validator eingebaut, der kontinuierlich den kollektiven Konfigurationsstatus aller Peers im transitiven Abschluss des Knotens erfasst und das Potenzial für Divergenz – d. h. Disjunktheit – erkennt Kollegien – innerhalb dieser kollektiven Konfiguration. 6.2.1 Überprüfung der Quorum-Schnittmenge Während das Sammeln von Quorum-Slices einfach ist, ist es schwierig, disjunkte Quoren unter ihnen zu finden.[62]. Wir haben es jedoch angenommen eine Reihe algorithmischer Heuristiken und Falleliminierungsregeln vorgeschlagen von Lachowski [62], die typische Instanzen überprüfen des Problems mehrere Größenordnungen schneller als die Kosten im schlimmsten Fall. Praktisch gesehen das aktuelle Netzwerk Die transitiven Quorum-Slice-Abschlüsse liegen in der Größenordnung von 20–30 Knoten und, mit Lachowskis Optimierungen, typischerweise überprüfen in Sekundenschnelle auf einer einzigen CPU. Sollte sich der Bedarf ergeben Um die Leistung zu verbessern, können wir die Suche parallelisieren. 6.2.2 Überprüfung riskanter Konfigurationen Zu erkennen, dass das Netzwerk disjunkte Quoren zulässt, ist ein Schritt in die richtige Richtung, macht aber unangenehm spät auf die Gefahr aufmerksam für solch ein kritisches Thema. Im Idealfall möchten wir, dass Knotenbetreiber Warnungen erhalten, wenn die kollektive Konfiguration des Netzwerks erfolgt nähert sich lediglich einem riskanten Zustand. Daher haben wir den Quorum-Intersection-Checker erweitert Um einen Zustand zu erkennen, nennen wir ihn Kritikalität: wenn der Strom Die kollektive Konfiguration ist nur eine Fehlkonfiguration entfernt ein Staat, der disjunkte Quoren zulässt. Um Kritikalität zu erkennen, Der Prüfer ersetzt dann wiederholt die Konfiguration jeder Organisation durch eine simulierte Worst-Case-Fehlkonfiguration führt die innere Quorum-Schnittpunktprüfung für das Ergebnis erneut aus. Wenn eine solche kritische Fehlkonfiguration vorliegt, ist nur ein Schritt entfernt Ab dem aktuellen Stand gibt die Software eine Warnung aus und meldet, dass die Organisation ein Fehlkonfigurationsrisiko darstellt. Durch diese Änderungen erhält die Betreibergemeinschaft zwei Ebenen von Hinweisen und Anleitungen, um sich vor den schlimmsten Formen zu schützen kollektiver Fehlkonfiguration.

Auswertung

Um die Eignung von Stellar als globales Zahlungsmittel zu verstehen und Handelsnetzwerk haben wir den Zustand des öffentlichen Netzwerks bewertet und führte kontrollierte Experimente auf einem privaten Experiment durch Netzwerk. Dabei haben wir uns auf folgende Fragen konzentriert: • Wie sieht die Topologie des Produktionsnetzwerks aus? Wie viele Nachrichten werden durchschnittlich gesendet und Wie kommt es bei SCP zu Zeitüberschreitungen? • Bleiben Konsens- und Ledger-Update-Latenzen unabhängig von der Anzahl der Konten?SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Lokhava et al. • Wie werden Latenzen durch die Erhöhung (a) der Transaktionen pro Sekunde (und folglich der Transaktionen pro Sekunde) beeinflusst? Ledger) und (b) die Anzahl der validator Knoten? • Wie hoch sind die Kosten für den Betrieb eines Knotens in Bezug auf die CPU? Speicher und Netzwerkbandbreite? Zahlungsnetzwerke weisen im Vergleich niedrige Transaktionsraten auf zu anderen Arten von verteilten Systemen. Die führenden blockchains, Bitcoin und Ethereum, bestätigen bis zu 15 Transaktionen/Sekunde, weniger als Stellar. Darüber hinaus dauert die Installation dieser Systeme nur wenige Minuten eine Stunde, um eine Transaktion sicher zu bestätigen, da für den Proof-of-Work darauf gewartet werden muss, dass mehrere Blöcke abgebaut werden. Die Nicht-blockchain Das SWIFT-Netzwerk verzeichnete an seinem Spitzentag [14] durchschnittlich nur 420 Transaktionen pro Sekunde. Deshalb haben wir uns entschieden um unsere Messungen mit dem 5-Sekunden-Ziel zu vergleichen Ledger-Intervall, ein aggressiveres Ziel. Unsere Ergebnisse zeigen dass die Latenzen auch mit deutlich unter dieser Grenze liegen Mehrere nicht implementierte Optimierungen sind noch in der Pipeline. 7.1 Anker Zu den volumenmäßig am häufigsten gehandelten Vermögenswerten gehören Währungen (z. B. 3 USD). Anker, 2 CNY), ein Anker Bitcoin, ein immobilienbesichertes Wertpapier token [92] und eine In-App-Währung [8]. Verschiedene Anker haben unterschiedliche Richtlinien. Zum Beispiel ein USD-Anker, Stronghold legt auth_reqired fest und erfordert einen Know-Your-Customer-Prozess (KYC) für jedes Konto, das seinen Kunden besitzt Vermögenswerte. Ein anderes, AnchorUSD, lässt jeden empfangen und handeln ihren USD (was es buchstäblich möglich macht, 0,50 $ nach Mexiko zu senden). in 5 Sekunden mit einer Gebühr von 0,000001 $). Allerdings AnchorUSD Für den Kauf oder die Einlösung ihrer USD sind KYC und Gebühren erforderlich mit herkömmlichen Überweisungen. Auf den Philippinen, wo Laut Coins.ph sind die Bankvorschriften für eingehende Zahlungen laxer unterstützt die Auszahlung von PHP an jedem Geldautomaten [36]. Zusätzlich zu der oben genannten Sicherheit token und der In-App-Währung gibt es eine Reihe von Nicht-Währungs-tokens von Handelsanleihen [22] und Emissionsgutschriften [85, 96] bis mehr esoterische Vermögenswerte wie eine token, die Anreize für die Zusammenarbeit bietet Autorücknahme [35]. 7.2 Öffentliches Netzwerk Zum jetzigen Zeitpunkt gibt es 126 aktive Vollknoten, davon 66 Nehmen Sie am Konsens teil, indem Sie Abstimmungsbotschaften unterzeichnen. Abbildung 7 (generiert von [5]) visualisiert das Netzwerk mit einer Linie dazwischen zwei Knoten, wenn einer in den Quorum-Slices des anderen erscheint und a Eine dunkelblaue Linie zeigt die bidirektionale Abhängigkeit. Am Center ist ein Cluster von 17 De-facto-„Tier-One-validators“, die von betrieben werden SDF, SatoshiPay, LOBSTR, COINQVEST und Keybase. Vor vier Monaten, vor den Ereignissen von Abschnitt 6, dort Es gab 15 systemisch wichtige Knoten: 3 von scheinbar Tier-1-Organisationen und mehrere zufällige Singletons. Die Die Grafik sah auch viel weniger regelmäßig aus. Daher scheinen der neue Konfigurationsmechanismus und/oder bessere Bedienerentscheidungen zu sein um zu einer gesünderen Netzwerktopologie beizutragen. Ohne große finanzielle Mittel (und entsprechender Anteilseigner). Abbildung 7. Quorum-Slice-Map Verpflichtungen) wäre es schwierig gewesen, fünf Tier-1-Mitarbeiter zu rekrutieren Organisationen jedoch von Anfang an. Dies deutet auf ein Quorum hin Slices spielen beim Netzwerk-Bootstraping eine nützliche Rolle: Das kann jeder Treten Sie mit dem Ziel bei, ein wichtiger Spieler zu werden, denn Es gibt keine Gatekeeper für die paarweise Vereinbarung. Derzeit befinden sich über 3,3 Millionen Konten im Hauptbuch. Vorbei In den letzten 24 Stunden hat Stellar durchschnittlich 4,5 Transaktionen durchgeführt und 15,7 Operationen pro Sekunde. Meistens die Überprüfung aktueller Bücher Transaktionen scheinen einen einzigen Vorgang zu haben, während alle paar In Hauptbüchern sehen wir Transaktionen, die viele Vorgänge enthalten scheinen von Market Makern zu stammen, die Angebote verwalten. Die Die durchschnittlichen Zeiten, um einen Konsens zu erzielen und das Hauptbuch zu aktualisieren, waren 1061 ms bzw. 46 ms. Die 99. Perzentile waren 2252 ms und 142 ms (ersteres entspricht einer Zeitüberschreitung von 1 Sekunde). bei der Auswahl des Nominierungsleiters). Beachten Sie, dass die Leistung von SCP beträgt weitgehend unabhängig von Transaktionen pro Sekunde, da SCP stimmt einem hash beliebig vieler Transaktionen zu. Es ist wahrscheinlicher, dass Engpässe durch die Verbreitung von Kandidaten entstehen Transaktionen während der Nominierung, Ausführung und Validierung Transaktionen und das Zusammenführen von Buckets. Wir haben es noch nicht gebraucht um die Transaktionsverarbeitung von Stellar-Core über mehrere CPU-Kerne oder Festplatten zu parallelisieren. Wir haben auch die Anzahl der gesendeten SCP-Nachrichten ausgewertet im Produktionsnetzwerk. Im Normalfall mit einer Single Führer gewählt, um einen Wert zu nominieren, erwarten wir sieben logische Zu sendende Nachrichten: zwei Nachrichten zum Abstimmen und Annehmen ein Nominate-Anweisung, zwei Nachrichten zum Akzeptieren und Bestätigen eine Vorbereitungserklärung, zwei Nachrichten zum Akzeptieren und Bestätigen eine Commit-Anweisung und schließlich eine Externalize-Nachricht (wird gesendet, nachdem ein neues Hauptbuch auf die Festplatte übertragen wurde, um Nachzüglern zu helfen aufholen). Die Implementierung kombiniert Commit bestätigen und externalisieren Sie Nachrichten als Optimierung, da dies der Fall ist Es ist sicher, einen Wert zu externalisieren, nachdem er festgeschrieben wurde. Anschließend analysieren wir die für eine Produktion erfassten Metriken Stellar validator. Vorbei Im Laufe von 68 Stunden wurden 1,3 Nachrichten/Sekunde ausgesendet, Durchschnittlich 6-7 Nachrichten pro Hauptbuch. Wir stellen fest, dass die Summe

Schnelle und sichere globale Zahlungen mit Stellar SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Perzentil Anzahl der Timeouts Nominierung Abstimmung 75 % 0 0 99 % 1 0 Max 4 1 Abbildung 8. Timeouts pro Ledger über 68 Stunden Die Anzahl der von validators gesendeten Nachrichten ist größer, seit in Zusätzlich zu den föderierten Abstimmungsnachrichten senden die Knoten auch Nachrichten alle Transaktionen, von denen sie erfahren. Abbildung 8 zeigt die Zeitüberschreitungen bei einer Produktion validator über einen Zeitraum von 68 Stunden. Nominierungs-Timeouts sind ein Maß für die (Un-)Wirksamkeit der Funktion zur Wahl des Vorsitzenden, während Abstimmungszeitüberschreitungen stark vom Netzwerk abhängen und mögliche Nachrichtenverzögerungen. Die Timeouts sind konsistent mit der Anzahl der ausgegebenen Nachrichten: sechs Nachrichten im Best-Case-Szenario und mindestens sieben Nachrichten, falls eine weitere Nominierungsrunde erforderlich ist. 7.3 Kontrollierte Experimente Wir führten kontrollierte Experimente in aufgepackten Behältern durch Amazon EC2 c5d.9xlarge-Instances mit 72 GiB RAM, 900 GB NVMe SSD und 36 vCPUs. Jede Instanz war in derselben EC2-Region und hatte eine feste Bandbreite von 10 Gbit/s. Wir haben SQLite als Speicher verwendet. (Stellar unterstützt auch PostgreSQL, aber das hat asynchrone Aufgaben, die Rauschen in die Messungen einbringen.) Stellar bietet eine integrierte Laufzeitabfrage, genericload, Dies ermöglicht die Erzeugung einer synthetischen Last an einem bestimmten Ziel Transaktion/Zweitkurs. Obwohl Stellar verschiedene unterstützt Handelsfunktionen wie Orderbuch und Cross-Asset-Pfad Im Bereich Zahlungen haben wir uns auf einfache Zahlungen konzentriert. Die Bestätigung von Transaktionen besteht aus mehreren Schritten zeichnete die Messungen für jedes der folgenden Elemente auf: • Nominierung: Zeit von der Nominierung bis zur ersten Vorbereitung • Abstimmung: Zeit von der ersten Vorbereitung bis zur Bestätigung a Stimmzettel begangen • Ledger-Aktualisierung: Zeit, den Konsenswert anzuwenden • Transaktionsanzahl: bestätigte Transaktionen pro Hauptbuch Jedes unserer Experimente wurde durch drei Parameter definiert: die Anzahl der Kontoeinträge im Hauptbuch, der Betrag von Last (in Form von XLM-Zahlungen), die pro Sekunde übermittelt wird, und die Anzahl der validators. Wir haben jeden validator konfiguriert über jeden anderen validator Bescheid wissen (ein Worst-Case-Szenario). für SCP), wobei die Quorum-Slices auf eine beliebige einfache Mehrheit eingestellt sind Knoten (um die Anzahl verschiedener Quoren zu maximieren). Grundlinie Unser Basisexperiment hat Stellar mit gemessen 100.000 Konten, vier validators und die Lastgenerierung Rate von 100 Transaktionen/Sekunde. Wir haben durchschnittlich 507 Transaktionen pro Hauptbuch beobachtet, mit einer Standardabweichung von 49 (9,7 %). Beachten Sie, dass keine Transaktionen gelöscht wurden; das Geringste 105 106 107 0 500 1.000 1.500 2.000 Konten Latenz [ms] Aktualisierung des Hauptbuchs Abstimmung Nominierung Abbildung 9. Latenz bei zunehmender Anzahl von Konten Die Abweichung ist auf Planungseinschränkungen des Lastgenerators zurückzuführen. Wir haben beobachtet, dass die Anzahl der Transaktionen pro Ledger entsprach unserer Lastgenerierungsrate, gegeben im Hauptbuch Schließt alle 5 Sekunden. Nominierung, Abstimmung und Protokoll Das Update zeigte mittlere Latenzen von 82,53 ms, 95,96 ms und 174,08 ms. Wir haben diese Nominierungslatenz beobachtet Das 99. Perzentil liegt gelegentlich unter 61 ms Spitzen von etwa 1 Sekunde, entsprechend dem ersten Schritt in der Timeout-Funktion der Leader-Auswahl. Angesichts der Ausgangsleistung haben wir uns die Auswirkungen angesehen Möglichkeit, die einzelnen Parameter des Testaufbaus zu variieren. Konten Die Daten in Abbildung 9 deuten darauf hin, dass Stellar skaliert Außerdem steigt die Anzahl der Konten. Testgenerierung Konten wurden zu einem langwierigen Prozess, da die Bucket-Erstellung und Durch die Zusammenführung konnten wir die Datenbank nicht einfach füllen mit Konten direkt über SQL. Deshalb haben wir unsere durchgeführt Experimente für bis zu 50.000.000 Konten. Während es gibt minimale Auswirkung auf Konsens- und Ledger-Update-Latenzen, Wir stellen fest, dass die Erhöhung der Konten einen Overhead von verursacht Zusammenführen von Eimern, die größer werden. Transaktionsrate Die Transaktionsrate beeinflusst die Menge Traffic-Multicast zwischen validators, die Anzahl der in jedem Ledger enthaltenen Transaktionen und die Größe der obersten Ebene Eimer. Die Auswirkungen zunehmender Transaktionen verstehen Beim Laden haben wir ein Experiment mit 100.000 Konten und 4 validators durchgeführt. Abbildung 10 zeigt das langsame Wachstum der Konsenslatenz. während die meiste Zeit für die Aktualisierung des Hauptbuchs aufgewendet wurde. Es überrascht nicht, dass es mit zunehmender Größe des Transaktionssatzes zunimmt Es dauert länger, es in die Datenbank zu übernehmen. Das nehmen wir auch zur Kenntnis Die Latenz der Ledger-Aktualisierung ist stark von der Implementierung abhängig. und wird durch die Wahl der Datenbank beeinflusst. Validatorknoten Um zu sehen, wie sich die Anzahl der Tierone validators erhöhtAuswirkungen auf die Leistung haben, haben wir Experimente durchgeführt mit 100.000 Konten, 100 Transaktionen/Sekunde und einer variierenden Anzahl von validators von 4 bis 43. Alle validators wurden angezeigt in allen Quorum-Slices von validators; kleinere Quorum-Slices würden es tun einen geringeren Einfluss auf die Leistung haben.SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada Lokhava et al. 100 150 200 250 300 350 0 500 1.000 1.500 2.000 Laden [Transaktionen/Sekunde] Latenz [ms] Aktualisierung des Hauptbuchs Abstimmung Nominierung Abbildung 10. Latenz bei steigender Transaktionslast 10 20 30 40 0 500 1.000 1.500 2.000 Validatoren Latenz [ms] Aktualisierung des Hauptbuchs Abstimmung Nominierung Abbildung 11. Latenz mit zunehmender Knotenanzahl Ändern der Anzahl validierender Knoten im Netzwerk wirkt sich auch auf die Anzahl der ausgetauschten SCP-Nachrichten aus die Anzahl der potenziellen Werte während der Nominierung. Abbildung 11 zeigt, dass die Nominierungszeit relativ langsam zunimmt. Während die Daten darauf hindeuten, dass die Stimmabgabe der Engpass ist, haben wir sind davon überzeugt, dass viele Skalierungsprobleme durch Verbesserungen gelöst werden können Das Overlay-Netzwerk von Stellar zur Optimierung des Netzwerkverkehrs. Als erwartet, blieb die Latenz der Ledger-Aktualisierung unabhängig davon die Anzahl der Knoten. Schlusskurs Schließlich wollten wir die End-to-End-Leistung von Stellar messen, indem wir messen, wie oft Hauptbücher bestätigt werden und ob Stellar sein 5-Sekunden-Ziel ohne Bestätigung erreicht alle Transaktionen fallen lassen. Wir haben einen durchschnittlichen Hauptbuchabschluss beobachtet Zeiten von 5,03 s, 5,10 s und 5,15 s, als wir das Konto erhöhten Einträge, Transaktionsrate bzw. Anzahl der Knoten. Die Ergebnisse legen nahe, dass Stellar Hauptbücher konsistent schließen kann unter hoher Belastung. 7.4 Ausführen eines validator Eines der wichtigen Merkmale von Stellar sind die geringen Kosten Ausführen eines validator, da Anker ausgeführt (oder mit ihnen kontrahiert) werden sollen validators, um die Endgültigkeit zu erzwingen. SDF führt drei Produktions-validators aus, alle auf c5.large AWS-Instanzen, die über zwei Kerne verfügen. 4 GiB RAM und Intel(R) Xeon(R) Platinum 8124M CPU @ 3,00-GHz-Prozessoren. Überprüfen der Ressourcennutzung auf einem Bei diesen Maschinen haben wir den Prozess Stellar beobachtet etwa 7 % der CPU und 300 MiB Speicher. Bezogen auf den Netzwerkverkehr mit 28 Verbindungen zu Peers und einer Quorumgröße Von 34 betrugen die eingehenden und ausgehenden Raten 2,78 Mbit/s und 2,56 Mbit/s. Hardware, die zum Ausführen eines solchen erforderlich ist Der Prozess ist kostengünstig. In unserem Fall betragen die Kosten 0,054 $/Stunde oder etwa 40 $/Monat. 7.5 Zukünftige Arbeit Diese Experimente legen nahe, dass Stellar problemlos 1–2 Ordnungen skalieren kann in einer Größenordnung, die über die heutige Netzwerknutzung hinausgeht. Denn die Die Leistungsanforderungen waren bisher so bescheiden, Stellar lässt Raum für viele einfache Optimierungen bekannte Techniken. Zum Beispiel Transaktionen und SCP Nachrichten werden von validators mithilfe einer naiven Flutung gesendet Protokoll, sollte aber idealerweise effizienter und strukturierter sein Peer-to-Peer-Multicast [30]. Zudem datenbanklastig Die Aktualisierungszeit des Hauptbuchs kann durch Standard-Batching- und Prefetching-Techniken verbessert werden.

Abschluss

Internationale Zahlungen sind teuer und dauern Tage. Fonds Die Verwahrung erfolgt über mehrere Finanzinstitute, darunter Korrespondenzbanken und Geldtransferdienste. Da jeder Hop vollständig vertrauenswürdig sein muss, ist es schwierig, neue Hops zu erstellen Marktteilnehmer, um Marktanteile zu gewinnen und im Wettbewerb zu bestehen. Stellar zeigt So senden Sie Geld in Sekundenschnelle günstig um die Welt. Die Die wichtigste Innovation ist ein neues byzantinisches Vereinbarungsprotokoll mit offener Mitgliedschaft, SCP, das die Peer-to-Peer-Struktur nutzt des Finanznetzwerks, um einen globalen Konsens unter a zu erreichen neuartige Internet-Hypothese. SCP lässt Stellar atomar festschreiben irreversible Transaktionen zwischen beliebigen Teilnehmern, die Sie wissen nichts voneinander und vertrauen einander nicht. Dies wiederum garantiert neuen Marktteilnehmern Zugang zu denselben Märkten wie etablierten Spieler, macht es sicher, den besten verfügbaren Austausch zu erhalten selbst von nicht vertrauenswürdigen Market Makern, und zwar dramatisch reduziert die Zahlungsverzögerung. Danksagungen Stellar wäre ohne die frühen nicht da, wo es heute ist Führung von Joyce Kim oder die enormen Beiträge von Scott Fleckenstein und Bartek Nowotarski im Bauwesen und Aufrechterhaltung des Horizonts, des Stellar SDK und anderer wichtiger Elemente des Ökosystems Stellar. Wir danken auch Kolten Bergeron, Henry Corrigan-Gibbs, Candace Kelly, Kapil K. Jain, Boris Reznikov, Jeremy Rubin, Christian Rudder, Eric Saunders, Torsten Stüber, Tomer Weller, die anonymen Gutachter und unserer Schäferin Justine Sherry für ihre hilfreichen Kommentare zu frühere Entwürfe. Haftungsausschluss Der Beitrag von Professor Mazières zu dieser Veröffentlichung erfolgte als bezahlter Berater und war nicht Teil seiner Aufgaben oder Verantwortlichkeiten der Stanford University.

Schnelle und sichere globale Zahlungen mit Stellar SOSP ’19, 27.–30. Oktober 2019, Huntsville, ON, Kanada