L'algorithme de consensus du protocole Ripple
Abstract
Obwohl mehrere Konsensalgorithmen fur das Problem der Byzantinischen Generale existieren, insbesondere in Bezug auf verteilte Zahlungssysteme, leiden viele unter hoher Latenz, die durch die Anforderung verursacht wird, dass alle Knoten im Netzwerk synchron kommunizieren mussen. In dieser Arbeit prasentieren wir einen neuartigen Konsensalgorithmus, der diese Anforderung umgeht, indem er kollektiv vertrauenswurdige Subnetzwerke innerhalb des grosseren Netzwerks nutzt. Wir zeigen, dass das "Vertrauen", das zur Verhinderung von Sybil-Angriffen erforderlich ist, tatsachlich nicht global ist, sondern lokal fur jeden Knoten im Netzwerk.
Der Konsensalgorithmus des Ripple-Protokolls (RPCA) wird alle paar Sekunden von allen Knoten angewendet, um die Korrektheit und Ubereinstimmung des Netzwerks aufrechtzuerhalten. Sobald ein Konsens erreicht ist, gilt das aktuelle Ledger als "geschlossen" und wird zum letzten geschlossenen Ledger. Dieser Algorithmus ist einzigartig, da er Konsens mit niedriger Latenz erreicht und gleichzeitig starke Garantien gegen byzantinische Ausfalle bietet, was ihn fur Echtzeit-Finanzabrechnungssysteme geeignet macht.
Abstract
Bien que plusieurs algorithmes de consensus existent pour le Probleme des Generaux Byzantins, en particulier en ce qui concerne les systemes de paiement distribues, beaucoup souffrent d'une latence elevee induite par l'exigence que tous les noeuds du reseau communiquent de maniere synchrone. Dans ce travail, nous presentons un nouvel algorithme de consensus qui contourne cette exigence en utilisant des sous-reseaux collectivement fiables au sein du reseau plus large. Nous montrons que la "confiance" requise pour prevenir les attaques Sybil n'est en fait pas globale, mais plutot locale a chaque noeud du reseau.
L'algorithme de consensus du protocole Ripple (RPCA) est applique toutes les quelques secondes par tous les noeuds, afin de maintenir la correction et l'accord du reseau. Une fois le consensus atteint, le ledger actuel est considere comme "ferme" et devient le dernier ledger ferme. Cet algorithme est unique en ce qu'il atteint le consensus avec une faible latence tout en maintenant de fortes garanties contre les defaillances byzantines, ce qui le rend adapte aux systemes de reglement financier en temps reel.
Introduction
Ein verteiltes Zahlungssystem muss einen Konsensalgorithmus implementieren, um Zahlungen korrekt und zeitnah zu verarbeiten, selbst bei Vorhandensein fehlerhafter oder boswilliger Akteure. Bitcoin erreicht Konsens durch Proof-of-Work, bei dem alle Knoten Rechenressourcen aufwenden mussen, um kryptografische Ratsel zu losen. Obwohl dieser Ansatz starke Sicherheitsgarantien bietet, leidet er unter erheblichen Nachteilen, darunter hoher Energieverbrauch, geringer Transaktionsdurchsatz und lange Bestatigungs-Latenzen, die bei hochwertigen Transaktionen eine Stunde oder mehr betragen konnen.
Der Konsensalgorithmus des Ripple-Protokolls bietet einen neuen Ansatz fur verteilten Konsens, der kein Proof-of-Work erfordert. Stattdessen einigen sich die Knoten im Netzwerk durch einen Abstimmungsprozess kollektiv auf Transaktionssatze, der Konsens innerhalb von Sekunden erreicht. Dieser Konsensmechanismus ist speziell fur die Anforderungen eines globalen Zahlungsnetzwerks konzipiert, bei dem niedrige Latenz und hoher Durchsatz fur den praktischen Einsatz unerlasslich sind.
Die wichtigste Innovation des RPCA besteht darin, dass nicht alle Knoten im Netzwerk miteinander ubereinstimmen mussen. Stattdessen pflegt jeder Knoten eine Unique Node List (UNL) anderer Knoten, denen er vertraut, nicht zu kolludieren. Solange die von den Knoten gewahlten UNLs ausreichende Uberlappung aufweisen und weniger als ein Schwellenwertprozentsatz der Knoten fehlerhaft ist, wird das Netzwerk Konsens erreichen. Dieser Ansatz bietet die fur ein Zahlungssystem erforderlichen Sicherheitsgarantien bei einer Konsenslatenz, die in Sekunden statt in Minuten oder Stunden gemessen wird.
Introduction
Un systeme de paiement distribue doit implementer un algorithme de consensus pour traiter correctement les paiements en temps opportun, meme en presence d'acteurs defaillants ou malveillants. Bitcoin atteint le consensus en utilisant la preuve de travail (proof-of-work), qui exige que tous les noeuds depensent des ressources de calcul pour resoudre des puzzles cryptographiques. Bien que cette approche fournisse de solides garanties de securite, elle souffre d'inconvenients importants, notamment une consommation energetique elevee, un faible debit de transactions et de longues latences de confirmation pouvant s'etendre a une heure ou plus pour les transactions de grande valeur.
L'algorithme de consensus du protocole Ripple propose une nouvelle approche du consensus distribue qui ne necessite pas de preuve de travail. Au lieu de cela, les noeuds du reseau s'accordent collectivement sur des ensembles de transactions par un processus de vote qui atteint le consensus en quelques secondes. Ce mecanisme de consensus est specifiquement concu pour les exigences d'un reseau de paiement mondial, ou une faible latence et un debit eleve sont essentiels pour un deploiement pratique.
L'innovation cle du RPCA est qu'il ne necessite pas que tous les noeuds du reseau s'accordent entre eux. Au lieu de cela, chaque noeud maintient une Liste de Noeuds Uniques (Unique Node List, UNL) d'autres noeuds en lesquels il a confiance pour ne pas s'entendre. Tant que les UNL choisies par les noeuds ont un chevauchement suffisant et que moins d'un pourcentage seuil de noeuds sont defaillants, le reseau atteindra le consensus. Cette approche fournit les garanties de securite necessaires a un systeme de paiement tout en atteignant une latence de consensus mesuree en secondes plutot qu'en minutes ou en heures.
Definition of Consensus
In verteilten Systemen bezieht sich Konsens auf den Prozess, durch den ein Netzwerk von Knoten trotz fehlerhafter oder boswilliger Teilnehmer eine Einigung uber einen gemeinsamen Zustand erzielt. Ein Konsensalgorithmus muss drei grundlegende Eigenschaften erfullen: Korrektheit (keine zwei korrekten Knoten entscheiden unterschiedlich), Ubereinstimmung (alle korrekten Knoten treffen die gleiche Entscheidung) und Terminierung (alle korrekten Knoten entscheiden sich schliesslich). Diese Eigenschaften stellen sicher, dass sich das verteilte System verhalt, als ware es ein einzelner, zuverlassiger Knoten.
Die Herausforderung bei der Erreichung von Konsens ergibt sich aus der inharenten Unzuverlassigkeit verteilter Systeme. Knoten konnen absturzen, Nachrichten konnen verzogert werden oder verloren gehen, und byzantinische Knoten konnen sich beliebig oder boswillig verhalten. Das Problem der Byzantinischen Generale, formalisiert von Lamport, Shostak und Pease, erfasst diese Herausforderung: Wie kann eine Gruppe von Prozessen eine Einigung erzielen, wenn ein Teil fehlerhaft sein kann und die Kommunikation unzuverlassig ist?
Klassische Ergebnisse der verteilten Informatik legen fundamentale Grenzen fest, was Konsensalgorithmen erreichen konnen. Das FLP-Unmoglichkeitsergebnis zeigt, dass kein deterministischer Algorithmus Konsens in einem asynchronen System garantieren kann, wenn auch nur ein einziger Knoten ausfallen kann. Praktische Konsensalgorithmen mussen daher Kompromisse zwischen Sicherheit (niemals einen falschen Konsens erreichen) und Lebendigkeit (immer Fortschritte machen) eingehen. Bitcoins Proof-of-Work priorisiert Sicherheit uber Lebendigkeit, wahrend RPCA ein fur Zahlungssysteme besser geeignetes Gleichgewicht erreicht, indem es Konsensrunden in begrenzter Zeit abschliesst und gleichzeitig starke Sicherheitsgarantien unter realistischen Fehlerannahmen aufrechterhalt.
Definition of Consensus
Dans les systemes distribues, le consensus designe le processus par lequel un reseau de noeuds parvient a un accord sur un etat partage, malgre la presence de participants defaillants ou malveillants. Un algorithme de consensus doit satisfaire trois proprietes fondamentales : la correction (deux noeuds corrects ne prennent pas de decisions differentes), l'accord (tous les noeuds corrects parviennent a la meme decision) et la terminaison (tous les noeuds corrects finissent par prendre une decision). Ces proprietes garantissent que le systeme distribue se comporte comme s'il s'agissait d'un noeud unique et fiable.
Le defi pour atteindre le consensus provient de la non-fiabilite inherente des systemes distribues. Les noeuds peuvent tomber en panne, les messages peuvent etre retardes ou perdus, et les noeuds byzantins peuvent se comporter de maniere arbitraire ou malveillante. Le Probleme des Generaux Byzantins, formalise par Lamport, Shostak et Pease, capture ce defi : comment un groupe de processus peut-il parvenir a un accord lorsqu'une fraction d'entre eux peut etre defaillante et que la communication n'est pas fiable ?
Les resultats classiques en informatique distribuee etablissent des limites fondamentales sur ce que les algorithmes de consensus peuvent realiser. Le resultat d'impossibilite FLP montre qu'aucun algorithme deterministe ne peut garantir le consensus dans un systeme asynchrone si meme un seul noeud peut echouer. Les algorithmes de consensus pratiques doivent donc faire des compromis entre la surete (ne jamais atteindre un consensus incorrect) et la vivacite (toujours progresser). La preuve de travail de Bitcoin privilegie la surete par rapport a la vivacite, tandis que le RPCA atteint un equilibre plus adapte aux systemes de paiement en completant les tours de consensus en temps borne tout en maintenant de fortes garanties de surete sous des hypotheses de pannes realistes.
Existing Consensus Algorithms
Mehrere Konsensalgorithmen wurden vorgeschlagen, um das Problem der Byzantinischen Generale in verteilten Systemen zu losen. Der Practical Byzantine Fault Tolerance (PBFT) Algorithmus, eingefuhrt von Castro und Liskov, kann bis zu f byzantinische Fehler in einem System von 3f+1 Knoten tolerieren. PBFT erreicht Konsens durch mehrere Runden des Nachrichtenaustauschs zwischen allen Knoten mit einer Kommunikationskomplexitat von O(n^2), wobei n die Anzahl der Knoten ist. Wahrend PBFT starke Sicherheitsgarantien und relativ niedrige Latenz fur kleine Netzwerke bietet, skaliert er aufgrund des quadratischen Kommunikationsaufwands nicht gut fur grosse Netzwerke.
Paxos und seine Varianten, entwickelt von Lamport, ermoglichen Konsens in asynchronen Systemen, setzen jedoch Absturzfehler statt byzantinischer Fehler voraus. Paxos erreicht Konsens durch eine Reihe von Runden, in denen Vorschlagende Werte vorschlagen und Akzeptoren daruber abstimmen. Wahrend Paxos beliebige Nachrichtenverzogerungen und Prozessabsturze tolerieren kann, erfordert es sorgfaltige Entwicklung fur den Umgang mit byzantinischen Fehlern und kann in bestimmten Szenarien unter Livelock leiden.
Bitcoins Proof-of-Work-Konsensalgorithmus verfolgt einen grundlegend anderen Ansatz, indem er byzantinische Angriffe wirtschaftlich undurchfuhrbar macht. Knoten konkurrieren darum, kryptografische Ratsel zu losen, wobei der Gewinner den nachsten Transaktionsblock vorschlagt. Wahrend dieser Ansatz auf beliebige Netzwerkgrossen skaliert und byzantinische Fehler behandelt, hat er schwerwiegende Nachteile: massiver Energieverbrauch (geschatzt auf uber 150 Millionen Dollar pro Jahr fur das Bitcoin-Netzwerk), lange Bestatigungs-Latenzen (oft 40-60 Minuten fur hochwertige Transaktionen) und begrenzter Durchsatz (ungefahr 7 Transaktionen pro Sekunde). Diese Einschrankungen machen Proof-of-Work fur viele Zahlungssystemanwendungen ungeeignet, die eine schnelle Abwicklung und hohe Transaktionsvolumen erfordern.
Existing Consensus Algorithms
Plusieurs algorithmes de consensus ont ete proposes pour resoudre le Probleme des Generaux Byzantins dans les systemes distribues. L'algorithme Practical Byzantine Fault Tolerance (PBFT), introduit par Castro et Liskov, peut tolerer jusqu'a f fautes byzantines dans un systeme de 3f+1 noeuds. PBFT atteint le consensus par plusieurs tours d'echange de messages entre tous les noeuds, avec une complexite de communication de O(n^2), ou n est le nombre de noeuds. Bien que PBFT fournisse de solides garanties de surete et une latence relativement faible pour les petits reseaux, il ne s'adapte pas bien aux grands reseaux en raison de la surcharge de communication quadratique.
Paxos et ses variantes, developpes par Lamport, fournissent un consensus dans les systemes asynchrones mais supposent des defaillances par arret plutot que des fautes byzantines. Paxos atteint le consensus par une serie de tours au cours desquels les proposants suggerent des valeurs et les accepteurs votent. Bien que Paxos puisse tolerer des retards de messages arbitraires et des arrets de processus, il necessite une ingenierie soigneuse pour gerer les defaillances byzantines et peut souffrir de livelock dans certains scenarios.
L'algorithme de consensus proof-of-work de Bitcoin adopte une approche fondamentalement differente en rendant les attaques byzantines economiquement irrealisables. Les noeuds rivalisent pour resoudre des puzzles cryptographiques, le gagnant proposant le prochain bloc de transactions. Bien que cette approche s'adapte a des reseaux de taille arbitraire et gere les fautes byzantines, elle presente de serieux inconvenients : une consommation d'energie massive (estimee a plus de 150 millions de dollars par an pour le reseau Bitcoin), de longues latences de confirmation (souvent 40-60 minutes pour les transactions de grande valeur) et un debit limite (environ 7 transactions par seconde). Ces limitations rendent le proof-of-work inadapte a de nombreuses applications de systemes de paiement necessitant un reglement rapide et des volumes de transactions eleves.
Ripple Protocol Consensus Algorithm
Der Konsensalgorithmus des Ripple-Protokolls (RPCA) beginnt damit, dass jeder Server alle gultigen Transaktionen, die er gesehen hat und die noch nicht angewendet wurden, als Kandidatentransaktionen nimmt. Die Server folgen dann einem Mehrrundenprotokoll, in dem sie iterativ auf eine Einigung uber einen Satz von Transaktionen hinarbeiten, die auf das aktuelle Ledger angewendet werden sollen. In jeder Runde machen die Server Vorschlage, die aus den Transaktionen bestehen, von denen sie glauben, dass sie in das nachste Ledger aufgenommen werden sollten.
Wahrend jeder Konsensrunde kommunizieren die Server ihre Vorschlage an andere Server in ihrer Unique Node List (UNL). Die Server berechnen dann, welche Transaktionen in einem Schwellenwertprozentsatz der Vorschlage erscheinen. Anfanglich wird dieser Schwellenwert auf 50 % gesetzt, was bedeutet, dass eine Transaktion in Vorschlagen von mindestens der Halfte der UNL eines Servers erscheinen muss, um fur die nachste Runde berucksichtigt zu werden. Wahrend der Konsens durch aufeinanderfolgende Runden fortschreitet, erhoht sich dieser Schwellenwert schrittweise (typischerweise auf 60 %, 70 % und schliesslich 80 %).
Wenn eine Transaktion den Supermajority-Schwellenwert von 80 % Unterstutzung in der UNL eines Servers erreicht, wird sie in den Vorschlag dieses Servers fur die finale Konsensrunde aufgenommen. Alle Transaktionen, die diesen Schwellenwert im gesamten Netzwerk erreichen, werden auf das Ledger angewendet, das dann kryptografisch gehasht und signiert wird. Dieses neu validierte Ledger wird zum letzten geschlossenen Ledger, und der Prozess beginnt mit dem nachsten Satz von Kandidatentransaktionen von vorne.
Der Konsensprozess wird typischerweise in 5 Sekunden oder weniger abgeschlossen, wobei die meisten Transaktionen nur eine einzige Konsensrunde benotigen, um den Supermajority-Schwellenwert zu erreichen. Transaktionen, die in einer Runde keinen Konsens erreichen, bleiben Kandidaten fur nachfolgende Runden. Dieses Design stellt sicher, dass das Netzwerk kontinuierlich Fortschritte macht und gleichzeitig starke Sicherheitsgarantien aufrechterhalt, da keine Transaktion auf das Ledger angewendet werden kann, ohne die Unterstutzung einer Supermajority vertrauenswurdiger Validatoren.
Ripple Protocol Consensus Algorithm
L'algorithme de consensus du protocole Ripple (RPCA) commence par chaque serveur prenant toutes les transactions valides qu'il a vues et qui n'ont pas encore ete appliquees comme transactions candidates. Les serveurs suivent ensuite un protocole multi-tours ou ils travaillent iterativement vers un accord sur un ensemble de transactions a appliquer au ledger actuel. A chaque tour, les serveurs font des propositions consistant en les transactions qu'ils estiment devoir etre incluses dans le prochain ledger.
Pendant chaque tour de consensus, les serveurs communiquent leurs propositions aux autres serveurs de leur Unique Node List (UNL). Les serveurs calculent ensuite quelles transactions apparaissent dans un pourcentage seuil des propositions. Initialement, ce seuil est fixe a 50 %, ce qui signifie qu'une transaction doit apparaitre dans les propositions d'au moins la moitie de l'UNL d'un serveur pour etre consideree pour le tour suivant. Au fur et a mesure que le consensus progresse a travers les tours successifs, ce seuil augmente progressivement (typiquement a 60 %, 70 %, et finalement 80 %).
Lorsqu'une transaction atteint le seuil de supermajority de 80 % de soutien dans l'UNL d'un serveur, elle est incluse dans la proposition de ce serveur pour le tour de consensus final. Toutes les transactions qui atteignent ce seuil a travers le reseau sont appliquees au ledger, qui est ensuite hache cryptographiquement et signe. Ce ledger nouvellement valide devient le dernier ledger ferme, et le processus recommence avec le prochain ensemble de transactions candidates.
Le processus de consensus se termine generalement en 5 secondes ou moins, la plupart des transactions ne necessitant qu'un seul tour de consensus pour atteindre le seuil de supermajority. Les transactions qui n'atteignent pas le consensus en un tour restent candidates pour les tours suivants. Cette conception garantit que le reseau progresse continuellement tout en maintenant de fortes garanties de surete, car aucune transaction ne peut etre appliquee au ledger sans le soutien d'une supermajority de validateurs de confiance.
Formal Analysis of Convergence
Die Korrektheit von RPCA hangt entscheidend von der Uberlappung zwischen den UNLs ab, die von verschiedenen Knoten im Netzwerk gewahlt werden. Sei UNL_i die Unique Node List des Knotens i, und sei UNL_i ∩ UNL_j die Menge der Knoten, die sowohl in UNL_i als auch in UNL_j erscheinen. Damit das Netzwerk den Konsens aufrechterhalt, fordern wir, dass fur zwei beliebige Knoten i und j die Schnittmenge ihrer UNLs im Verhaltnis zur maximalen Grosse einer der beiden UNLs ausreichend gross sein muss.
Genauer gesagt garantiert das Protokoll Sicherheit, wenn |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 fur alle Knotenpaare i und j gilt. Diese Bedingung stellt sicher, dass selbst wenn byzantinische Knoten versuchen, verschiedene Teile des Netzwerks zu unterschiedlichen Konsensentscheidungen zu bringen, die Uberlappung vertrauenswurdiger Knoten einen Fork verhindert. Wenn diese Bedingung erfullt ist und weniger als 1/5 der Knoten in jeder UNL byzantinisch sind, werden alle korrekten Knoten zur gleichen Konsensentscheidung gelangen.
Der formale Beweis erfolgt durch den Nachweis, dass wenn zwei Knoten zu unterschiedlichen Konsensentscheidungen gelangen konnten, eine Transaktion T existieren musste, die im endgultigen Ledger eines Knotens erscheint, aber nicht im anderen. Damit dies eintritt, musste T 80 % Unterstutzung in der UNL des ersten Knotens, aber weniger als 80 % Unterstutzung in der UNL des zweiten Knotens erreicht haben. Angesichts der Uberlappungsanforderung und der Beschrankung byzantinischer Knoten kann jedoch gezeigt werden, dass dieses Szenario unmoglich ist: Wenn T 80 % Unterstutzung in UNL_i erreicht, muss sie mindestens 60 % Unterstutzung in jeder UNL_j erreichen, die die Uberlappungsbedingung erfullt, und mit ausreichend Konsensrunden wird dies zu 80 % konvergieren oder von beiden Knoten abgelehnt werden.
Die Lebendigkeitseigenschaft -- dass Konsens schliesslich erreicht wird -- folgt aus der Beobachtung, dass der Schwellenwert fur die Aufnahme durch die Konsensrunden deterministisch ansteigt. Selbst bei Vorhandensein byzantinischer Knoten und Netzwerkverzogerungen stellt das Protokoll sicher, dass Transaktionen, die von einer Supermajority ehrlicher Knoten unterstutzt werden, schliesslich aufgenommen werden, wahrend Transaktionen ohne solche Unterstutzung ausgeschlossen werden. Die begrenzte Zeit fur den Konsens (typischerweise 5 Sekunden) bietet praktische Lebendigkeitsgarantien, die fur Zahlungssystemanwendungen geeignet sind.
Formal Analysis of Convergence
La correction du RPCA depend de maniere critique du chevauchement entre les UNL choisies par les differents noeuds du reseau. Soit UNL_i la liste de noeuds uniques du noeud i, et soit UNL_i ∩ UNL_j l'ensemble des noeuds qui apparaissent a la fois dans UNL_i et UNL_j. Pour que le reseau maintienne le consensus, nous exigeons que pour deux noeuds quelconques i et j, l'intersection de leurs UNL soit suffisamment grande par rapport a la taille maximale de l'une ou l'autre UNL.
Specifiquement, le protocole garantit la surete lorsque |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 pour toutes les paires de noeuds i et j. Cette condition garantit que meme si des noeuds byzantins tentent de faire en sorte que differentes parties du reseau atteignent des decisions de consensus differentes, le chevauchement des noeuds de confiance empeche une bifurcation (fork). Si cette condition est remplie et que moins de 1/5 des noeuds dans une UNL sont byzantins, alors tous les noeuds corrects atteindront la meme decision de consensus.
La preuve formelle procede en montrant que si deux noeuds pouvaient atteindre des decisions de consensus differentes, il devrait exister une transaction T qui apparait dans le ledger final d'un noeud mais pas dans celui de l'autre. Pour que cela se produise, T devrait avoir obtenu 80 % de soutien dans l'UNL du premier noeud mais moins de 80 % de soutien dans l'UNL du second noeud. Cependant, etant donne l'exigence de chevauchement et la contrainte sur les noeuds byzantins, on peut montrer que ce scenario est impossible : si T atteint 80 % de soutien dans UNL_i, elle doit atteindre au moins 60 % de soutien dans toute UNL_j qui satisfait la condition de chevauchement, et avec suffisamment de tours de consensus, cela convergera vers 80 % ou sera rejete par les deux noeuds.
La propriete de vivacite -- que le consensus sera finalement atteint -- decoule de l'observation que le seuil d'inclusion augmente de maniere deterministe a travers les tours de consensus. Meme en presence de noeuds byzantins et de retards reseau, le protocole garantit que les transactions soutenues par une supermajority de noeuds honnetes seront finalement incluses, tandis que les transactions manquant d'un tel soutien seront exclues. Le temps borne pour le consensus (typiquement 5 secondes) fournit des garanties pratiques de vivacite adaptees aux applications de systemes de paiement.
Unique Node Lists
Die Unique Node List (UNL) ist eine grundlegende Komponente von RPCA, die es von anderen Konsensalgorithmen unterscheidet. Jeder Knoten im Ripple-Netzwerk pflegt eine UNL, die aus anderen Knoten besteht, denen er vertraut, das Netzwerk nicht durch Absprachen zu betrugen. Entscheidend ist, dass dieses Vertrauen lokal und nicht global ist: Verschiedene Knoten konnen unterschiedliche UNLs haben, und es gibt keine Anforderung fur eine global vereinbarte Menge von Validatoren. Dieses Design ermoglicht es dem Netzwerk, organisch zu wachsen und gleichzeitig die Dezentralisierung aufrechtzuerhalten.
Die UNL dient als Sybil-Angriffs-Praventionsmechanismus ohne Proof-of-Work. In einem naiven Abstimmungssystem konnte ein Angreifer viele pseudonyme Knoten erstellen, um unverhaltnismassigen Einfluss zu erlangen. Indem jeder Knoten explizit wahlen muss, welchen anderen Knoten er vertraut, stellt RPCA sicher, dass die Erstellung zusatzlicher Identitaten keinen Vorteil bietet, es sei denn, diese Identitaten konnen bestehende Knoten davon uberzeugen, sie zu ihren UNLs hinzuzufugen. Dies verlagert das Problem der Sybil-Resistenz von der Rechenausgabe auf Reputation und Vertrauensbeziehungen.
Damit das Netzwerk korrekt funktioniert, mussen UNLs so gewahlt werden, dass sie ausreichende Uberlappung aufweisen, wie in der formalen Analyse beschrieben. In der Praxis bedeutet dies, dass jeder Knotenbetreiber zwar Autonomie bei der Auswahl seiner UNL hat, aber sicherstellen muss, dass seine Liste Validatoren enthalt, die auch von anderen Teilen des Netzwerks vertraut werden. Ripple stellt eine Standard-UNL bereit, die aus Validatoren besteht, die von verschiedenen Einrichtungen betrieben werden, aber Knotenbetreiber konnen diese Liste nach ihrer eigenen Vertrauensbewertung anpassen.
Der UNL-Mechanismus bietet auch einen naturlichen Weg zur progressiven Dezentralisierung. In den fruhen Phasen des Netzwerks kann eine zentralisiertere Menge von Validatoren angemessen sein, um Stabilitat und Zuverlassigkeit zu gewahrleisten. Wenn das Netzwerk reift und vielfaltiger Betreiber ihre Vertrauenswurdigkeit unter Beweis stellen, konnen die UNLs weiterentwickelt werden, um eine breitere Menge von Validatoren einzuschliessen, was die Widerstandsfahigkeit und Dezentralisierung des Netzwerks erhoht, ohne seine Sicherheitseigenschaften zu gefahrden.
Unique Node Lists
La Liste de Noeuds Uniques (Unique Node List, UNL) est un composant fondamental du RPCA qui le distingue des autres algorithmes de consensus. Chaque noeud du reseau Ripple maintient une UNL composee d'autres noeuds en lesquels il a confiance pour ne pas s'entendre afin de frauder le reseau. De maniere critique, cette confiance est locale plutot que globale : differents noeuds peuvent avoir differentes UNL, et il n'y a aucune exigence d'un ensemble de validateurs convenu globalement. Cette conception permet au reseau de se developper organiquement tout en maintenant la decentralisation.
L'UNL sert de mecanisme de prevention des attaques Sybil sans necessiter de preuve de travail. Dans un systeme de vote naif, un attaquant pourrait creer de nombreux noeuds pseudonymes pour obtenir une influence disproportionnee. En exigeant que chaque noeud choisisse explicitement les autres noeuds en lesquels il a confiance, le RPCA garantit que la creation d'identites supplementaires ne procure aucun avantage a moins que ces identites ne puissent convaincre les noeuds existants de les ajouter a leurs UNL. Cela deplace le probleme de la resistance Sybil de la depense de calcul vers les relations de reputation et de confiance.
Pour que le reseau fonctionne correctement, les UNL doivent etre choisies de maniere a avoir un chevauchement suffisant, comme decrit dans l'analyse formelle. En pratique, cela signifie que bien que chaque operateur de noeud ait une autonomie dans la selection de son UNL, il doit s'assurer que sa liste inclut des validateurs qui sont egalement approuves par d'autres parties du reseau. Ripple fournit une UNL par defaut composee de validateurs operes par des entites diverses, mais les operateurs de noeuds sont libres de modifier cette liste en fonction de leur propre evaluation de confiance.
Le mecanisme UNL fournit egalement une voie naturelle vers une decentralisation progressive. Dans les premieres etapes du reseau, un ensemble plus centralise de validateurs peut etre approprie pour assurer la stabilite et la fiabilite. A mesure que le reseau murit et que des operateurs plus divers demontrent leur fiabilite, les UNL peuvent evoluer pour inclure un ensemble plus large de validateurs, augmentant la resilience et la decentralisation du reseau sans compromettre ses proprietes de securite.
Simulation Code
Um die theoretische Analyse von RPCA zu validieren und seine Leistung unter verschiedenen Bedingungen zu bewerten, wurden umfangreiche Simulationen mit eigens entwickelter Simulationssoftware durchgefuhrt. Das Simulationsframework modelliert ein Netzwerk von Knoten, von denen jeder seine eigene UNL pflegt und am Konsensprotokoll teilnimmt. Der Code implementiert den vollstandigen RPCA-Algorithmus, einschliesslich Transaktionsvorschlagen, Abstimmungsrunden mit steigenden Schwellenwerten und Ledger-Validierung.
Wesentliche in den Simulationen variierte Parameter umfassen die Netzwerkgrosse (von 10 bis 1.000 Knoten), den Prozentsatz byzantinischer Knoten (von 0 % bis 20 %), die UNL-Grosse (typischerweise zwischen 5 und 50 Knoten) und Netzwerktopologie-Konfigurationen. Fur jede Parameterkonfiguration wurden mehrere Simulationslaufe mit verschiedenen Zufallsstartwerten durchgefuhrt, um die statistische Validitat der Ergebnisse sicherzustellen. Die Simulationen verfolgten Metriken wie Konsenslatenz, Fork-Wahrscheinlichkeit und Transaktionsdurchsatz.
Die Simulationsergebnisse bestatigen die theoretischen Vorhersagen bezuglich Konvergenz und Sicherheit. In allen Konfigurationen, in denen die UNL-Uberlappungsbedingung erfullt war und byzantinische Knoten weniger als 20 % jeder UNL ausmachten, erreichte das Netzwerk erfolgreich Konsens ohne Forks. Die Konsenslatenz blieb durchgehend niedrig (typischerweise in 3-5 simulierten Sekunden abgeschlossen), unabhangig von der Netzwerkgrosse, was die Skalierbarkeit des Algorithmus demonstriert. Selbst bei 15 % byzantinischer Knoten, die aktiv versuchten, den Konsens zu storen, behielt das Netzwerk die Korrektheit bei, solange die UNL-Uberlappungsanforderung erfullt war.
Zusatzliche Simulationen untersuchten Grenzfalle und Ausfallszenarien, einschliesslich Netzwerkpartitionen, plotzlicher Anderungen der UNL-Zusammensetzung und koordinierter Angriffe durch byzantinische Knoten. Diese Simulationen lieferten Erkenntnisse uber die Robustheit des Protokolls und informierten empfohlene Best Practices fur die UNL-Auswahl und den Netzwerkbetrieb. Der vollstandige Simulationscode wurde verfugbar gemacht, um unabhangige Uberprufung und weitere Forschung zu ermoglichen.
Simulation Code
Pour valider l'analyse theorique du RPCA et evaluer ses performances dans diverses conditions, des simulations approfondies ont ete menees a l'aide d'un logiciel de simulation sur mesure. Le cadre de simulation modelise un reseau de noeuds, chacun maintenant sa propre UNL et participant au protocole de consensus. Le code implemente l'algorithme RPCA complet, incluant la proposition de transactions, les tours de vote avec des seuils croissants et la validation du ledger.
Les parametres cles varies dans les simulations comprennent la taille du reseau (allant de 10 a 1 000 noeuds), le pourcentage de noeuds byzantins (de 0 % a 20 %), la taille de l'UNL (typiquement entre 5 et 50 noeuds) et les configurations de topologie reseau. Pour chaque configuration de parametres, plusieurs executions de simulation ont ete menees avec differentes graines aleatoires afin d'assurer la validite statistique des resultats. Les simulations ont suivi des metriques incluant la latence du consensus, la probabilite de bifurcation (fork) et le debit de transactions.
Les resultats de simulation confirment les predictions theoriques concernant la convergence et la surete. Dans toutes les configurations ou la condition de chevauchement de l'UNL etait satisfaite et ou les noeuds byzantins representaient moins de 20 % de chaque UNL, le reseau a atteint le consensus avec succes sans bifurcation. La latence du consensus est restee constamment faible (se terminant typiquement en 3-5 secondes simulees) independamment de la taille du reseau, demontrant la scalabilite de l'algorithme. Meme avec 15 % de noeuds byzantins tentant activement de perturber le consensus, le reseau a maintenu la correction tant que l'exigence de chevauchement de l'UNL etait respectee.
Des simulations supplementaires ont explore des cas limites et des scenarios de defaillance, incluant des partitions reseau, des changements soudains dans la composition de l'UNL et des attaques coordonnees par des noeuds byzantins. Ces simulations ont fourni des informations sur la robustesse du protocole et ont eclaire les meilleures pratiques recommandees pour la selection de l'UNL et l'exploitation du reseau. Le code de simulation complet a ete mis a disposition pour permettre la verification independante et la recherche approfondie.
Discussion
Im Vergleich zu Bitcoins Proof-of-Work-Konsens bietet RPCA mehrere bedeutende Vorteile fur Zahlungssystemanwendungen. Am bemerkenswertesten ist, dass die Konsenslatenz von 40-60 Minuten (der typischerweise fur hochwertige Bitcoin-Transaktionen empfohlene Zeitraum) auf etwa 5 Sekunden reduziert wird. Diese Verbesserung macht RPCA geeignet fur Point-of-Sale und andere Anwendungen, bei denen eine nahezu sofortige Abwicklung erforderlich ist. Daruber hinaus benotigt RPCA im Vergleich zu Proof-of-Work minimale Rechenressourcen, wodurch der massive Energieverbrauch des Bitcoin-Minings entfallt.
Diese Vorteile gehen jedoch mit anderen Vertrauensannahmen einher. Wahrend Bitcoins Sicherheit nur auf der Annahme beruht, dass kein Angreifer mehr als 50 % der Rechenleistung des Netzwerks kontrolliert, erfordert RPCA, dass Knoten UNLs mit ausreichender Uberlappung wahlen und dass byzantinische Knoten den Schwellenwert innerhalb dieser UNLs nicht uberschreiten. Dies ubertragt einen Teil der Verantwortung auf die Knotenbetreiber, umsichtige Vertrauensentscheidungen zu treffen. In der Praxis ist dieser Kompromiss fur viele Zahlungssystem-Anwendungsfalle akzeptabel, in denen die teilnehmenden Institutionen bestehende Vertrauensbeziehungen haben.
Die Netzwerktopologie und die UNL-Auswahlstrategie wirken sich erheblich auf die Eigenschaften des Konsenssystems aus. Eine stark zentralisierte Topologie, bei der alle Knoten dieselben Validatoren in ihre UNLs aufnehmen, maximiert die Sicherheit, kann aber die Lebendigkeit verringern, wenn diese Validatoren nicht verfugbar werden. Umgekehrt kann eine stark dezentralisierte Topologie mit minimaler UNL-Uberlappung die Lebendigkeit verbessern, birgt aber das Risiko von Konsensfehlern, wenn die Uberlappung zu gering wird. Das Finden des optimalen Gleichgewichts erfordert eine sorgfaltige Berucksichtigung des spezifischen Einsatzszenarios und der Risikotoleranz.
Zukunftige Arbeiten konnten adaptive UNL-Auswahlalgorithmen untersuchen, die die Uberlappungsanforderungen automatisch aufrechterhalten und gleichzeitig die Dezentralisierung maximieren, Mechanismen fur Knoten, um ihre UNLs dynamisch basierend auf dem beobachteten Validatorverhalten anzupassen, und Erweiterungen des Konsensalgorithmus, die noch hohere Prozentsatze byzantinischer Knoten tolerieren konnten. Diese Verbesserungen konnten die Robustheit und Anwendbarkeit von RPCA fur grosse verteilte Zahlungssysteme weiter verbessern.
Discussion
Compare au consensus proof-of-work de Bitcoin, le RPCA offre plusieurs avantages significatifs pour les applications de systemes de paiement. Plus remarquablement, la latence du consensus est reduite de 40-60 minutes (le temps typiquement recommande pour les transactions Bitcoin de grande valeur) a environ 5 secondes. Cette amelioration rend le RPCA adapte aux points de vente et autres applications ou un reglement quasi instantane est requis. De plus, le RPCA necessite des ressources de calcul minimales par rapport au proof-of-work, eliminant la consommation massive d'energie associee au minage de Bitcoin.
Cependant, ces avantages s'accompagnent d'hypotheses de confiance differentes. Alors que la securite de Bitcoin repose uniquement sur l'hypothese qu'aucun attaquant ne controle plus de 50 % de la puissance de calcul du reseau, le RPCA exige que les noeuds choisissent des UNL avec un chevauchement suffisant et que les noeuds byzantins ne depassent pas le seuil au sein de ces UNL. Cela transfere une certaine responsabilite aux operateurs de noeuds pour prendre des decisions de confiance prudentes. En pratique, ce compromis est acceptable pour de nombreux cas d'utilisation de systemes de paiement ou les institutions participantes ont des relations de confiance existantes.
La topologie du reseau et la strategie de selection de l'UNL ont un impact significatif sur les proprietes du systeme de consensus. Une topologie hautement centralisee ou tous les noeuds incluent les memes validateurs dans leurs UNL maximise la surete mais peut reduire la vivacite si ces validateurs deviennent indisponibles. Inversement, une topologie hautement decentralisee avec un chevauchement minimal de l'UNL peut ameliorer la vivacite mais risque des echecs de consensus si le chevauchement devient trop faible. Trouver l'equilibre optimal necessite une consideration attentive du scenario de deploiement specifique et de la tolerance au risque.
Les travaux futurs pourraient explorer des algorithmes de selection UNL adaptatifs qui maintiennent automatiquement les exigences de chevauchement tout en maximisant la decentralisation, des mecanismes permettant aux noeuds d'ajuster dynamiquement leurs UNL en fonction du comportement observe des validateurs, et des extensions de l'algorithme de consensus qui pourraient tolerer des pourcentages encore plus eleves de noeuds byzantins. Ces ameliorations pourraient renforcer davantage la robustesse et l'applicabilite du RPCA pour les systemes de paiement distribues a grande echelle.
Conclusion
Der Konsensalgorithmus des Ripple-Protokolls stellt einen bedeutenden Fortschritt im verteilten Konsens fur Zahlungssysteme dar. Durch die Nutzung kollektiv vertrauenswurdiger Subnetzwerke anstelle der Anforderung einer globalen Ubereinstimmung aller Knoten erreicht RPCA Konsens in Sekundenschnelle bei gleichzeitiger Aufrechterhaltung starker Garantien gegen byzantinische Ausfalle. Die formale Analyse zeigt, dass das Netzwerk korrekten Konsens ohne Forks erreicht, solange UNLs mit ausreichender Uberlappung gewahlt werden und byzantinische Knoten unter dem Schwellenwert bleiben.
Die praktischen Implikationen dieser Arbeit gehen uber das Ripple-Zahlungsnetzwerk hinaus. RPCA demonstriert, dass der traditionelle Kompromiss zwischen Konsenslatenz und Sicherheitsgarantien durch sorgfaltiges Protokolldesign und die Nutzung lokaler Vertrauensbeziehungen uberwunden werden kann. Dieser Ansatz kann sich als anwendbar auf andere verteilte Systeme erweisen, in denen niedrige Latenz entscheidend ist und Teilnehmer bestehende Vertrauensbeziehungen haben, wie beispielsweise Interbanken-Abrechnungssysteme, Lieferkettenverfolgung und andere Anwendungen der Finanzinfrastruktur.
Der Einsatz von RPCA in Produktionssystemen hat die Leistungsmerkmale und die Robustheit des Algorithmus validiert. Das Ripple-Netzwerk verarbeitet Tausende von Transaktionen pro Sekunde mit einer konstanten Konsenslatenz von 3-5 Sekunden und demonstriert damit, dass sich die theoretischen Eigenschaften effektiv in den realen Betrieb ubertragen. Wahrend das Netzwerk sich weiterentwickelt und zusatzliche Validatoren von verschiedenen Betreibern einbezieht, liefert es ein praktisches Beispiel dafur, wie ein dezentralisiertes Konsenssystem sowohl Sicherheit als auch Leistung im grossen Massstab aufrechterhalten kann.
Conclusion
L'algorithme de consensus du protocole Ripple represente une avancee significative dans le consensus distribue pour les systemes de paiement. En utilisant des sous-reseaux collectivement fiables plutot que d'exiger un accord global entre tous les noeuds, le RPCA atteint le consensus en quelques secondes tout en maintenant de fortes garanties contre les defaillances byzantines. L'analyse formelle demontre que tant que les UNL sont choisies avec un chevauchement suffisant et que les noeuds byzantins restent en dessous du seuil, le reseau atteindra un consensus correct sans bifurcation.
Les implications pratiques de ce travail s'etendent au-dela du reseau de paiement Ripple. Le RPCA demontre que le compromis traditionnel entre latence du consensus et garanties de securite peut etre surmonte par une conception de protocole soignee et l'utilisation de relations de confiance locales. Cette approche peut s'averer applicable a d'autres systemes distribues ou une faible latence est critique et ou les participants ont des relations de confiance existantes, tels que les systemes de reglement interbancaires, le suivi de la chaine d'approvisionnement et d'autres applications d'infrastructure financiere.
Le deploiement du RPCA dans les systemes de production a valide les caracteristiques de performance et la robustesse de l'algorithme. Le reseau Ripple traite des milliers de transactions par seconde avec une latence de consensus constante de 3-5 secondes, demontrant que les proprietes theoriques se traduisent efficacement en fonctionnement reel. A mesure que le reseau continue d'evoluer et d'incorporer des validateurs supplementaires d'operateurs divers, il fournit un exemple pratique de la facon dont un systeme de consensus decentralise peut maintenir a la fois la securite et la performance a grande echelle.
References
Lamport, L., Shostak, R., und Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. Diese bahnbrechende Arbeit formalisierte das Problem der Konsensfindung in verteilten Systemen mit fehlerhaften Komponenten und legte die theoretische Grundlage fur byzantinisch fehlertolerante Systeme.
Castro, M., und Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). Diese Arbeit fuhrte PBFT ein und zeigte, dass byzantinische Fehlertoleranz mit praktischer Leistung erreicht werden kann, allerdings mit einer Kommunikationskomplexitat von O(n^2), die die Skalierbarkeit einschrankt.
Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Dieses Whitepaper fuhrte den Proof-of-Work-Konsens als Losung fur das Double-Spending-Problem bei digitaler Wahrung ein und ermoglichte dezentralen Konsens ohne vertrauenswurdige Parteien auf Kosten hoher Latenz und Energieverbrauchs.
Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. Diese Arbeit prasentierte den Paxos-Algorithmus, der Konsens in asynchronen Systemen unter Absturzfehlern erreicht und nachfolgende Konsensprotokollentwurfe beeinflusste.
Fischer, M. J., Lynch, N. A., und Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. Das FLP-Unmoglichkeitsergebnis etablierte fundamentale Grenzen dessen, was Konsensalgorithmen in asynchronen Systemen erreichen konnen, und pragte den Designraum fur praktische Konsensprotokolle.
References
Lamport, L., Shostak, R., et Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. Cet article fondateur a formalise le probleme d'atteindre le consensus dans les systemes distribues avec des composants defaillants et a etabli les fondements theoriques des systemes tolerants aux fautes byzantines.
Castro, M., et Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). Ce travail a introduit PBFT, demontrant que la tolerance aux fautes byzantines pouvait etre atteinte avec des performances pratiques, bien qu'avec une complexite de communication O(n^2) limitant la scalabilite.
Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Ce livre blanc a introduit le consensus par preuve de travail comme solution au probleme de la double depense dans la monnaie numerique, permettant un consensus decentralise sans parties de confiance au prix d'une latence elevee et d'une consommation energetique importante.
Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. Cet article a presente l'algorithme Paxos, qui atteint le consensus dans les systemes asynchrones sous des defaillances par arret, influencant les conceptions de protocoles de consensus ulterieures.
Fischer, M. J., Lynch, N. A., et Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. Le resultat d'impossibilite FLP a etabli des limites fondamentales sur ce que les algorithmes de consensus peuvent realiser dans les systemes asynchrones, faconnant l'espace de conception des protocoles de consensus pratiques.
