Algoritma Konsensus Protokol 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
Meskipun sudah ada beberapa algoritma konsensus untuk Masalah Jenderal Bizantium, khususnya pada sistem pembayaran terdistribusi, banyak di antaranya mengalami latensi tinggi akibat persyaratan bahwa semua node dalam jaringan harus berkomunikasi secara sinkron. Dalam karya ini, kami memperkenalkan algoritma konsensus baru yang mengatasi persyaratan tersebut dengan memanfaatkan subjaringan yang dipercaya secara kolektif di dalam jaringan yang lebih besar. Kami menunjukkan bahwa "kepercayaan" yang diperlukan untuk mencegah serangan Sybil pada kenyataannya bukan bersifat global, melainkan lokal pada setiap node dalam jaringan.
Algoritma konsensus protokol Ripple (RPCA) diterapkan setiap beberapa detik oleh semua node untuk menjaga ketepatan dan keselarasan jaringan. Setelah konsensus tercapai, ledger saat ini dianggap "tertutup" dan menjadi ledger tertutup terakhir. Algoritma ini unik karena mampu mencapai konsensus dengan latensi rendah sambil mempertahankan jaminan kuat terhadap kegagalan Byzantine, sehingga cocok untuk sistem penyelesaian keuangan waktu nyata.
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
Sistem pembayaran terdistribusi harus menerapkan algoritma konsensus agar pembayaran dapat diproses secara benar dan tepat waktu bahkan ketika ada pelaku yang rusak atau berniat jahat. Bitcoin mencapai konsensus menggunakan proof-of-work, yang mengharuskan semua node mengeluarkan sumber daya komputasi untuk memecahkan teka-teki kriptografis. Walaupun pendekatan ini memberikan jaminan keamanan yang kuat, pendekatan ini memiliki kelemahan signifikan, termasuk konsumsi energi tinggi, throughput transaksi rendah, serta latensi konfirmasi panjang yang dapat mencapai satu jam atau lebih untuk transaksi bernilai tinggi.
Algoritma konsensus protokol Ripple menawarkan pendekatan baru terhadap konsensus terdistribusi tanpa memerlukan proof-of-work. Sebagai gantinya, node dalam jaringan secara kolektif menyepakati himpunan transaksi melalui proses pemungutan suara yang mencapai konsensus dalam hitungan detik. Mekanisme ini dirancang khusus untuk kebutuhan jaringan pembayaran global, di mana latensi rendah dan throughput tinggi sangat penting untuk implementasi praktis.
Inovasi utama RPCA adalah tidak mengharuskan semua node dalam jaringan saling menyetujui secara langsung. Sebaliknya, setiap node memelihara Unique Node List (UNL) berisi node lain yang dipercaya tidak akan berkolusi. Selama UNL yang dipilih antar-node memiliki tumpang tindih yang memadai, dan persentase node yang rusak berada di bawah ambang tertentu, jaringan akan mencapai konsensus. Pendekatan ini menyediakan jaminan keamanan yang dibutuhkan sistem pembayaran sekaligus mencapai latensi konsensus dalam hitungan detik, bukan menit atau jam.
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
Dalam sistem terdistribusi, konsensus merujuk pada proses ketika jaringan node mencapai kesepakatan atas satu keadaan bersama, meskipun ada peserta yang rusak atau berniat jahat. Algoritma konsensus harus memenuhi tiga sifat fundamental: correctness (dua node benar tidak boleh memutuskan hal yang berbeda), agreement (semua node benar mencapai keputusan yang sama), dan termination (semua node benar pada akhirnya mengambil keputusan). Sifat-sifat ini memastikan sistem terdistribusi berperilaku seolah-olah merupakan satu node tunggal yang andal.
Tantangan utama dalam mencapai konsensus berasal dari sifat tidak andal bawaan pada sistem terdistribusi. Node dapat crash, pesan dapat tertunda atau hilang, dan node Byzantine dapat bertindak sewenang-wenang atau jahat. Masalah Jenderal Bizantium, yang diformalkan oleh Lamport, Shostak, dan Pease, menangkap tantangan ini: bagaimana sekelompok proses mencapai kesepakatan ketika sebagian dapat rusak dan komunikasi tidak andal?
Hasil-hasil klasik dalam komputasi terdistribusi menetapkan batas dasar atas apa yang dapat dicapai oleh algoritma konsensus. Hasil ketidakmungkinan FLP menunjukkan bahwa tidak ada algoritma deterministik yang dapat menjamin konsensus dalam sistem asinkron jika bahkan satu node saja dapat gagal. Karena itu, algoritma konsensus praktis harus membuat trade-off antara safety (tidak pernah mencapai konsensus yang salah) dan liveness (selalu terus maju). Proof-of-work Bitcoin memprioritaskan safety dibanding liveness, sementara RPCA mencapai keseimbangan yang lebih sesuai untuk sistem pembayaran dengan menyelesaikan ronde konsensus dalam waktu terbatas sambil mempertahankan jaminan safety yang kuat di bawah asumsi kegagalan yang realistis.
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
Sejumlah algoritma konsensus telah diusulkan untuk menyelesaikan Masalah Jenderal Bizantium dalam sistem terdistribusi. Algoritma Practical Byzantine Fault Tolerance (PBFT), yang diperkenalkan oleh Castro dan Liskov, mampu menoleransi hingga f kesalahan Byzantine dalam sistem berisi 3f+1 node. PBFT mencapai konsensus melalui beberapa ronde pertukaran pesan antar semua node, dengan kompleksitas komunikasi O(n^2), di mana n adalah jumlah node. Meskipun PBFT memberikan jaminan safety yang kuat dan latensi relatif rendah untuk jaringan kecil, PBFT tidak berskala baik pada jaringan besar karena overhead komunikasi kuadratik.
Paxos dan variannya, yang dikembangkan oleh Lamport, menyediakan konsensus dalam sistem asinkron tetapi mengasumsikan kegagalan crash, bukan kegagalan Byzantine. Paxos mencapai konsensus melalui serangkaian ronde ketika proposer mengusulkan nilai dan acceptor memberikan suara. Walaupun Paxos dapat mentoleransi penundaan pesan arbitrer dan crash proses, Paxos memerlukan rekayasa yang cermat untuk menangani kegagalan Byzantine dan dapat mengalami livelock pada skenario tertentu.
Algoritma konsensus proof-of-work Bitcoin mengambil pendekatan yang secara fundamental berbeda, yakni membuat serangan Byzantine tidak layak secara ekonomi. Node bersaing memecahkan teka-teki kriptografis, dan pemenang mengusulkan blok transaksi berikutnya. Walaupun pendekatan ini dapat diskalakan ke ukuran jaringan arbitrer dan menangani kegagalan Byzantine, pendekatan ini memiliki kekurangan serius: konsumsi energi masif (diperkirakan lebih dari 150 juta dolar AS per tahun untuk jaringan Bitcoin), latensi konfirmasi panjang (sering 40-60 menit untuk transaksi bernilai tinggi), dan throughput terbatas (sekitar 7 transaksi per detik). Keterbatasan ini membuat proof-of-work kurang cocok bagi banyak aplikasi sistem pembayaran yang memerlukan penyelesaian cepat dan volume transaksi tinggi.
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
Ripple Protocol Consensus Algorithm (RPCA) dimulai dengan setiap server mengambil semua transaksi valid yang telah dilihat tetapi belum diterapkan sebagai transaksi kandidat. Server kemudian mengikuti protokol multi-ronde, bekerja secara iteratif menuju kesepakatan atas himpunan transaksi yang akan diterapkan ke ledger saat ini. Pada setiap ronde, server membuat proposal yang terdiri dari transaksi yang menurut mereka perlu dimasukkan ke ledger berikutnya.
Selama setiap ronde konsensus, server mengomunikasikan proposalnya ke server lain dalam Unique Node List (UNL) mereka. Server lalu menghitung transaksi mana yang muncul dalam persentase ambang proposal. Pada awalnya, ambang ini ditetapkan di 50%, artinya transaksi harus muncul dalam proposal dari setidaknya setengah UNL server agar dipertimbangkan pada ronde berikutnya. Seiring konsensus berkembang melalui ronde berturut-turut, ambang ini meningkat secara bertahap (umumnya menjadi 60%, 70%, dan akhirnya 80%).
Ketika transaksi mencapai ambang supermajority 80% dukungan dalam UNL server, transaksi tersebut dimasukkan ke proposal server untuk ronde konsensus akhir. Semua transaksi yang mencapai ambang ini di seluruh jaringan diterapkan ke ledger, lalu ledger di-hash dan ditandatangani secara kriptografis. Ledger yang baru divalidasi ini menjadi ledger tertutup terakhir, dan proses dimulai kembali dengan himpunan transaksi kandidat berikutnya.
Proses konsensus biasanya selesai dalam 5 detik atau kurang, dengan sebagian besar transaksi hanya membutuhkan satu ronde konsensus untuk mencapai ambang supermajority. Transaksi yang belum mencapai konsensus dalam satu ronde tetap menjadi kandidat untuk ronde berikutnya. Desain ini memastikan jaringan terus membuat kemajuan sambil mempertahankan jaminan safety yang kuat, karena tidak ada transaksi yang dapat diterapkan ke ledger tanpa dukungan supermajority dari validator tepercaya.
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
Kebenaran RPCA sangat bergantung pada tingkat tumpang tindih antara UNL yang dipilih oleh node-node berbeda dalam jaringan. Misalkan UNL_i menyatakan unique node list milik node i, dan UNL_i ∩ UNL_j menyatakan himpunan node yang muncul pada UNL_i dan UNL_j sekaligus. Agar jaringan mempertahankan konsensus, untuk setiap pasangan node i dan j, irisan UNL keduanya harus cukup besar relatif terhadap ukuran UNL yang lebih besar.
Secara spesifik, protokol menjamin safety ketika |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 untuk semua pasangan node i dan j. Kondisi ini memastikan bahwa sekalipun node Byzantine berusaha membuat bagian-bagian jaringan mencapai keputusan konsensus yang berbeda, tumpang tindih node tepercaya mencegah terjadinya fork. Jika kondisi ini terpenuhi dan kurang dari 1/5 node dalam setiap UNL bersifat Byzantine, maka semua node benar akan mencapai keputusan konsensus yang sama.
Pembuktian formal menunjukkan bahwa jika dua node dapat mencapai keputusan konsensus berbeda, harus ada transaksi T yang muncul di ledger final satu node tetapi tidak pada node lainnya. Agar hal ini terjadi, T harus mencapai dukungan 80% di UNL node pertama namun kurang dari 80% di UNL node kedua. Namun, dengan syarat tumpang tindih dan batas node Byzantine, skenario ini terbukti mustahil: jika T mencapai 80% dukungan di UNL_i, T harus mencapai setidaknya 60% dukungan di UNL_j mana pun yang memenuhi kondisi tumpang tindih, dan dengan ronde konsensus yang cukup, dukungan ini akan konvergen ke 80% atau ditolak oleh kedua node.
Properti liveness, yaitu konsensus pada akhirnya tercapai, berasal dari pengamatan bahwa ambang inklusi meningkat secara deterministik sepanjang ronde konsensus. Bahkan dengan keberadaan node Byzantine dan keterlambatan jaringan, protokol memastikan transaksi yang didukung supermajority node jujur pada akhirnya akan dimasukkan, sementara transaksi yang tidak memiliki dukungan tersebut akan dikeluarkan. Waktu konsensus yang terbatas (umumnya sekitar 5 detik) memberikan jaminan liveness praktis yang sesuai untuk aplikasi sistem pembayaran.
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
Unique Node List (UNL) adalah komponen fundamental RPCA yang membedakannya dari algoritma konsensus lain. Setiap node dalam jaringan Ripple memelihara UNL yang berisi node lain yang dipercaya tidak akan berkolusi untuk menipu jaringan. Hal kritisnya adalah kepercayaan ini bersifat lokal, bukan global: node yang berbeda dapat memiliki UNL yang berbeda, dan tidak ada keharusan atas satu set validator yang disepakati secara global. Desain ini memungkinkan jaringan bertumbuh secara organik sambil tetap mempertahankan desentralisasi.
UNL berfungsi sebagai mekanisme pencegahan serangan Sybil tanpa membutuhkan proof-of-work. Dalam sistem voting naif, penyerang bisa membuat banyak identitas pseudonim untuk memperoleh pengaruh berlebihan. Dengan mengharuskan setiap node secara eksplisit memilih node mana yang dipercaya, RPCA memastikan pembuatan identitas tambahan tidak memberi keuntungan kecuali identitas tersebut dapat meyakinkan node yang ada untuk memasukkannya ke UNL mereka. Dengan demikian, masalah ketahanan Sybil bergeser dari pengeluaran komputasi ke reputasi dan relasi kepercayaan.
Agar jaringan berfungsi dengan benar, UNL harus dipilih sehingga memiliki tumpang tindih yang memadai, sebagaimana dijelaskan dalam analisis formal. Dalam praktiknya, ini berarti meskipun setiap operator node memiliki otonomi untuk memilih UNL sendiri, mereka harus memastikan daftar tersebut mencakup validator yang juga dipercaya oleh bagian lain jaringan. Ripple menyediakan UNL default yang terdiri dari validator yang dioperasikan oleh entitas beragam, tetapi operator node bebas menyesuaikan daftar ini berdasarkan penilaian kepercayaan mereka sendiri.
Mekanisme UNL juga menyediakan jalur alami menuju desentralisasi progresif. Pada tahap awal jaringan, kumpulan validator yang lebih terpusat mungkin tepat untuk memastikan stabilitas dan keandalan. Saat jaringan matang dan operator yang lebih beragam membuktikan kredibilitasnya, UNL dapat berevolusi untuk mencakup kumpulan validator yang lebih luas, meningkatkan ketahanan dan desentralisasi jaringan tanpa mengorbankan properti keamanannya.
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
Untuk memvalidasi analisis teoritis RPCA dan mengevaluasi kinerjanya di berbagai kondisi, simulasi ekstensif dilakukan menggunakan perangkat lunak simulasi khusus. Kerangka simulasi memodelkan jaringan node, masing-masing memelihara UNL sendiri dan berpartisipasi dalam protokol konsensus. Kode tersebut mengimplementasikan algoritma RPCA secara lengkap, termasuk proposal transaksi, ronde voting dengan ambang yang meningkat, dan validasi ledger.
Parameter kunci yang divariasikan dalam simulasi meliputi ukuran jaringan (dari 10 hingga 1.000 node), persentase node Byzantine (dari 0% hingga 20%), ukuran UNL (umumnya antara 5 dan 50 node), serta konfigurasi topologi jaringan. Untuk setiap konfigurasi parameter, beberapa kali simulasi dijalankan dengan random seed berbeda untuk memastikan validitas statistik hasil. Simulasi melacak metrik seperti latensi konsensus, probabilitas fork, dan throughput transaksi.
Hasil simulasi mengonfirmasi prediksi teoritis mengenai konvergensi dan safety. Pada semua konfigurasi ketika kondisi tumpang tindih UNL terpenuhi dan node Byzantine kurang dari 20% dari setiap UNL, jaringan berhasil mencapai konsensus tanpa fork. Latensi konsensus tetap rendah secara konsisten (umumnya selesai dalam 3-5 detik simulasi) terlepas dari ukuran jaringan, menunjukkan skalabilitas algoritma. Bahkan dengan 15% node Byzantine yang aktif mencoba mengganggu konsensus, jaringan tetap mempertahankan correctness selama syarat tumpang tindih UNL terpenuhi.
Simulasi tambahan mengeksplorasi kasus tepi dan skenario kegagalan, termasuk partisi jaringan, perubahan mendadak komposisi UNL, serta serangan terkoordinasi oleh node Byzantine. Simulasi ini memberikan wawasan tentang ketangguhan protokol dan menjadi dasar rekomendasi praktik terbaik untuk pemilihan UNL serta operasi jaringan. Kode simulasi lengkap telah dipublikasikan untuk memungkinkan verifikasi independen dan riset lanjutan.
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
Dibandingkan konsensus proof-of-work pada Bitcoin, RPCA menawarkan sejumlah keunggulan penting untuk aplikasi sistem pembayaran. Yang paling menonjol, latensi konsensus turun dari 40-60 menit (waktu yang umumnya direkomendasikan untuk transaksi Bitcoin bernilai tinggi) menjadi sekitar 5 detik. Peningkatan ini membuat RPCA cocok untuk point-of-sale dan aplikasi lain yang membutuhkan penyelesaian hampir seketika. Selain itu, RPCA memerlukan sumber daya komputasi minimal dibanding proof-of-work, sehingga menghilangkan konsumsi energi masif yang terkait dengan penambangan Bitcoin.
Namun, keunggulan ini datang dengan asumsi kepercayaan yang berbeda. Keamanan Bitcoin bergantung pada asumsi bahwa tidak ada penyerang yang mengendalikan lebih dari 50% daya komputasi jaringan, sedangkan RPCA mensyaratkan node memilih UNL dengan tumpang tindih memadai dan node Byzantine tidak melampaui ambang di dalam UNL tersebut. Hal ini memindahkan sebagian tanggung jawab kepada operator node untuk membuat keputusan kepercayaan yang bijak. Dalam praktik, trade-off ini dapat diterima untuk banyak kasus penggunaan pembayaran ketika institusi yang berpartisipasi sudah memiliki hubungan kepercayaan.
Topologi jaringan dan strategi pemilihan UNL sangat memengaruhi sifat sistem konsensus. Topologi sangat terpusat, ketika semua node memasukkan validator yang sama dalam UNL mereka, memaksimalkan safety tetapi dapat mengurangi liveness jika validator tersebut tidak tersedia. Sebaliknya, topologi sangat terdesentralisasi dengan tumpang tindih UNL minimal dapat meningkatkan liveness namun berisiko menyebabkan kegagalan konsensus jika tumpang tindih menjadi terlalu jarang. Menemukan keseimbangan optimal membutuhkan pertimbangan cermat terhadap skenario deployment spesifik dan toleransi risiko.
Pekerjaan mendatang dapat mengeksplorasi algoritma pemilihan UNL adaptif yang otomatis mempertahankan persyaratan tumpang tindih sambil memaksimalkan desentralisasi, mekanisme agar node menyesuaikan UNL secara dinamis berdasarkan perilaku validator yang diamati, dan ekstensi algoritma konsensus yang dapat mentoleransi persentase node Byzantine lebih tinggi. Peningkatan ini dapat semakin memperkuat ketangguhan dan penerapan RPCA untuk sistem pembayaran terdistribusi berskala besar.
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
Ripple Protocol Consensus Algorithm merupakan kemajuan penting dalam konsensus terdistribusi untuk sistem pembayaran. Dengan memanfaatkan subjaringan yang dipercaya secara kolektif alih-alih menuntut kesepakatan global dari semua node, RPCA mencapai konsensus dalam hitungan detik sambil mempertahankan jaminan kuat terhadap kegagalan Byzantine. Analisis formal menunjukkan bahwa selama UNL dipilih dengan tumpang tindih yang cukup dan node Byzantine tetap di bawah ambang, jaringan akan mencapai konsensus yang benar tanpa fork.
Implikasi praktis karya ini melampaui jaringan pembayaran Ripple. RPCA menunjukkan bahwa trade-off tradisional antara latensi konsensus dan jaminan keamanan dapat diatasi melalui desain protokol yang cermat serta penggunaan relasi kepercayaan lokal. Pendekatan ini berpotensi diterapkan pada sistem terdistribusi lain yang membutuhkan latensi rendah dan memiliki peserta dengan relasi kepercayaan yang sudah ada, seperti penyelesaian antarbank, pelacakan rantai pasok, dan aplikasi infrastruktur keuangan lainnya.
Penerapan RPCA di sistem produksi telah memvalidasi karakteristik kinerja dan ketangguhan algoritma ini. Jaringan Ripple memproses ribuan transaksi per detik dengan latensi konsensus konsisten 3-5 detik, menunjukkan bahwa properti teoritisnya efektif diterjemahkan ke operasi dunia nyata. Seiring jaringan terus berkembang dan menambah validator dari operator yang beragam, RPCA menjadi contoh praktis bagaimana sistem konsensus terdesentralisasi dapat mempertahankan keamanan dan performa pada skala besar.
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., dan Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. Makalah seminal ini memformalisasi masalah pencapaian konsensus dalam sistem terdistribusi dengan komponen yang rusak, serta meletakkan fondasi teoretis bagi sistem yang toleran terhadap kesalahan Byzantine.
Castro, M., dan Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). Karya ini memperkenalkan PBFT dan menunjukkan bahwa toleransi kesalahan Byzantine dapat dicapai dengan performa praktis, walaupun kompleksitas komunikasi O(n^2) membatasi skalabilitas.
Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Whitepaper ini memperkenalkan konsensus proof-of-work sebagai solusi untuk masalah double-spending pada mata uang digital, memungkinkan konsensus terdesentralisasi tanpa pihak tepercaya dengan biaya latensi tinggi dan konsumsi energi besar.
Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. Makalah ini memperkenalkan algoritma Paxos, yang mencapai konsensus dalam sistem asinkron di bawah kegagalan crash, dan memengaruhi desain protokol konsensus setelahnya.
Fischer, M. J., Lynch, N. A., dan Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. Hasil ketidakmungkinan FLP menetapkan batas fundamental mengenai apa yang dapat dicapai algoritma konsensus dalam sistem asinkron, sehingga membentuk ruang desain protokol konsensus praktis.
