L'algorithme de consensus du protocole Ripple
Abstract
Mặc dù đã có nhiều thuật toán đồng thuận cho Bài toán các tướng Byzantine, đặc biệt trong bối cảnh hệ thống thanh toán phân tán, nhiều thuật toán vẫn gặp độ trễ cao do yêu cầu tất cả các nút trong mạng phải giao tiếp đồng bộ. Trong công trình này, chúng tôi trình bày một thuật toán đồng thuận mới vượt qua yêu cầu đó bằng cách tận dụng các mạng con được tin cậy tập thể bên trong mạng lớn hơn. Chúng tôi chỉ ra rằng "niềm tin" cần thiết để ngăn chặn tấn công Sybil thực chất không phải là toàn cục, mà là cục bộ theo từng nút trong mạng.
Thuật toán đồng thuận giao thức Ripple (RPCA) được áp dụng vài giây một lần bởi tất cả các nút để duy trì tính đúng đắn và sự nhất quán của mạng. Khi đạt đồng thuận, sổ cái hiện tại được coi là "đã đóng" và trở thành sổ cái đóng gần nhất. Thuật toán này khác biệt ở chỗ đạt đồng thuận với độ trễ thấp trong khi vẫn duy trì các bảo đảm mạnh trước lỗi Byzantine, phù hợp cho các hệ thống thanh toán tài chính thời gian thực.
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
Một hệ thống thanh toán phân tán phải triển khai thuật toán đồng thuận để xử lý thanh toán chính xác và kịp thời ngay cả khi có tác nhân lỗi hoặc độc hại. Bitcoin đạt đồng thuận bằng proof-of-work, yêu cầu tất cả các nút tiêu tốn tài nguyên tính toán để giải các bài toán mật mã. Dù cách tiếp cận này cung cấp bảo đảm bảo mật mạnh, nó có các hạn chế đáng kể như tiêu thụ năng lượng cao, thông lượng giao dịch thấp và độ trễ xác nhận dài, có thể kéo dài đến một giờ hoặc hơn với giao dịch giá trị cao.
Thuật toán đồng thuận giao thức Ripple đưa ra một cách tiếp cận mới cho đồng thuận phân tán mà không cần proof-of-work. Thay vào đó, các nút trong mạng cùng thống nhất trên các tập giao dịch thông qua cơ chế bỏ phiếu đạt đồng thuận chỉ trong vài giây. Cơ chế này được thiết kế riêng cho yêu cầu của một mạng thanh toán toàn cầu, nơi độ trễ thấp và thông lượng cao là điều kiện bắt buộc để triển khai thực tế.
Đổi mới cốt lõi của RPCA là không yêu cầu mọi nút trong mạng phải đồng ý trực tiếp với nhau. Thay vào đó, mỗi nút duy trì một Unique Node List (UNL) gồm các nút khác mà nó tin rằng sẽ không thông đồng. Miễn là các UNL do các nút chọn có độ chồng lấn đủ lớn và số nút lỗi thấp hơn một ngưỡng nhất định, mạng sẽ đạt đồng thuận. Cách làm này giữ được các bảo đảm bảo mật cần thiết cho hệ thống thanh toán đồng thời rút ngắn độ trễ đồng thuận xuống mức giây thay vì phút hoặc giờ.
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
Trong hệ thống phân tán, đồng thuận là quá trình một mạng các nút đi đến thống nhất về một trạng thái chung, bất chấp sự hiện diện của các thành phần lỗi hoặc độc hại. Một thuật toán đồng thuận phải thỏa mãn ba thuộc tính nền tảng: tính đúng đắn (không có hai nút đúng đưa ra quyết định khác nhau), sự nhất trí (mọi nút đúng đều đi đến cùng một quyết định), và tính kết thúc (mọi nút đúng cuối cùng đều đưa ra quyết định). Các thuộc tính này bảo đảm hệ thống phân tán hành xử như thể nó là một nút duy nhất và đáng tin cậy.
Khó khăn của đồng thuận đến từ tính không đáng tin cậy vốn có của hệ thống phân tán. Nút có thể gặp sự cố, thông điệp có thể bị trễ hoặc thất lạc, và nút Byzantine có thể hành xử tùy ý hoặc độc hại. Bài toán các tướng Byzantine, được Lamport, Shostak và Pease hình thức hóa, mô tả đúng thách thức này: làm thế nào một nhóm tiến trình đạt được thống nhất khi một phần có thể bị lỗi và truyền thông không đáng tin cậy?
Các kết quả cổ điển trong tính toán phân tán đặt ra giới hạn nền tảng cho những gì thuật toán đồng thuận có thể đạt được. Kết quả bất khả thi FLP cho thấy không thuật toán tất định nào có thể bảo đảm đồng thuận trong hệ bất đồng bộ nếu chỉ một nút cũng có thể lỗi. Vì vậy, các thuật toán đồng thuận thực tế phải đánh đổi giữa an toàn (không bao giờ đạt đồng thuận sai) và tính sống (luôn tiếp tục tiến triển). Proof-of-work của Bitcoin ưu tiên an toàn hơn tính sống, trong khi RPCA đạt cân bằng phù hợp hơn cho hệ thống thanh toán bằng cách hoàn tất các vòng đồng thuận trong thời gian hữu hạn mà vẫn duy trì bảo đảm an toàn mạnh dưới các giả định lỗi thực tế.
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
Nhiều thuật toán đồng thuận đã được đề xuất để giải Bài toán các tướng Byzantine trong hệ thống phân tán. Thuật toán Practical Byzantine Fault Tolerance (PBFT), do Castro và Liskov giới thiệu, có thể chịu tối đa f lỗi Byzantine trong hệ gồm 3f+1 nút. PBFT đạt đồng thuận qua nhiều vòng trao đổi thông điệp giữa tất cả các nút, với độ phức tạp truyền thông O(n^2), trong đó n là số nút. Dù PBFT có bảo đảm an toàn mạnh và độ trễ tương đối thấp với mạng nhỏ, nó không mở rộng tốt lên mạng lớn do chi phí truyền thông bậc hai.
Paxos và các biến thể của nó, do Lamport phát triển, đạt đồng thuận trong hệ bất đồng bộ nhưng giả định lỗi sập (crash) thay vì lỗi Byzantine. Paxos vận hành qua các vòng mà bên đề xuất đưa ra giá trị và bên chấp nhận bỏ phiếu. Dù có thể chịu trễ thông điệp tùy ý và lỗi sập tiến trình, Paxos cần thiết kế cẩn thận để xử lý lỗi Byzantine và có thể gặp livelock trong một số tình huống.
Thuật toán đồng thuận proof-of-work của Bitcoin theo một hướng tiếp cận khác về bản chất: làm cho tấn công Byzantine trở nên không khả thi về kinh tế. Các nút cạnh tranh giải bài toán mật mã, nút thắng sẽ đề xuất khối giao dịch tiếp theo. Cách làm này mở rộng được đến quy mô mạng tùy ý và xử lý được lỗi Byzantine, nhưng có nhược điểm nghiêm trọng: tiêu thụ năng lượng rất lớn (ước tính hơn 150 triệu USD mỗi năm cho mạng Bitcoin), độ trễ xác nhận dài (thường 40-60 phút cho giao dịch giá trị cao), và thông lượng hạn chế (khoảng 7 giao dịch mỗi giây). Các hạn chế này khiến proof-of-work không phù hợp với nhiều ứng dụng thanh toán cần quyết toán nhanh và khối lượng giao dịch cao.
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
Thuật toán Đồng thuận Giao thức Ripple (RPCA) bắt đầu khi mỗi máy chủ lấy tất cả các giao dịch hợp lệ mà nó đã thấy nhưng chưa được áp dụng làm giao dịch ứng viên. Các máy chủ sau đó tuân theo một giao thức nhiều vòng, lặp dần để đạt đồng thuận về tập giao dịch sẽ áp dụng cho sổ cái hiện tại. Trong mỗi vòng, máy chủ đưa ra đề xuất gồm các giao dịch mà nó cho rằng nên được đưa vào sổ cái tiếp theo.
Trong mỗi vòng đồng thuận, máy chủ truyền đề xuất của mình đến các máy chủ khác trong Unique Node List (UNL) của nó. Sau đó, máy chủ tính giao dịch nào xuất hiện trong một tỷ lệ ngưỡng của các đề xuất. Ban đầu ngưỡng này là 50%, nghĩa là giao dịch phải xuất hiện trong đề xuất từ ít nhất một nửa UNL của máy chủ thì mới được xét ở vòng sau. Khi đồng thuận tiến qua các vòng liên tiếp, ngưỡng này tăng dần (thường lên 60%, 70% và cuối cùng 80%).
Khi một giao dịch đạt ngưỡng siêu đa số 80% ủng hộ trong UNL của máy chủ, giao dịch đó sẽ được đưa vào đề xuất của máy chủ cho vòng đồng thuận cuối. Tất cả các giao dịch đạt ngưỡng này trên toàn mạng được áp dụng vào sổ cái, sau đó sổ cái được băm và ký bằng mật mã. Sổ cái mới được xác thực này trở thành sổ cái đóng gần nhất, và quy trình bắt đầu lại với tập giao dịch ứng viên tiếp theo.
Quy trình đồng thuận thường hoàn tất trong 5 giây hoặc ít hơn, với phần lớn giao dịch chỉ cần một vòng đồng thuận để đạt ngưỡng siêu đa số. Giao dịch chưa đạt đồng thuận trong một vòng sẽ tiếp tục là ứng viên cho các vòng sau. Thiết kế này bảo đảm mạng liên tục tiến triển trong khi vẫn giữ an toàn mạnh, vì không giao dịch nào có thể được áp dụng vào sổ cái nếu không có sự ủng hộ siêu đa số từ các validator đáng tin cậy.
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
Tính đúng đắn của RPCA phụ thuộc quyết định vào độ chồng lấn giữa các UNL do các nút khác nhau chọn trong mạng. Gọi UNL_i là unique node list của nút i, và UNL_i ∩ UNL_j là tập các nút xuất hiện trong cả UNL_i và UNL_j. Để mạng duy trì đồng thuận, với mọi cặp nút i và j, giao của hai UNL phải đủ lớn so với kích thước lớn hơn giữa hai UNL đó.
Cụ thể, giao thức bảo đảm an toàn khi |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 cho mọi cặp i, j. Điều kiện này bảo đảm rằng ngay cả khi các nút Byzantine cố làm các phần khác nhau của mạng đạt các quyết định đồng thuận khác nhau, phần chồng lấn các nút đáng tin vẫn ngăn được phân nhánh. Nếu điều kiện này đúng và số nút Byzantine trong bất kỳ UNL nào nhỏ hơn 1/5, thì mọi nút đúng sẽ đi đến cùng một quyết định đồng thuận.
Chứng minh hình thức cho thấy rằng nếu hai nút có thể đi đến hai quyết định đồng thuận khác nhau, phải tồn tại một giao dịch T xuất hiện trong sổ cái cuối của một nút nhưng không có trong nút kia. Để điều này xảy ra, T phải đạt 80% ủng hộ trong UNL của nút thứ nhất nhưng dưới 80% trong UNL của nút thứ hai. Tuy nhiên, với yêu cầu chồng lấn và ràng buộc tỷ lệ Byzantine, kịch bản này là bất khả: nếu T đạt 80% trong UNL_i, nó phải đạt ít nhất 60% trong bất kỳ UNL_j nào thỏa điều kiện chồng lấn; và với đủ số vòng đồng thuận, mức này sẽ hội tụ về 80% hoặc bị cả hai nút loại bỏ.
Thuộc tính tính sống, tức đồng thuận cuối cùng sẽ đạt được, đến từ việc ngưỡng đưa vào tăng một cách tất định qua các vòng đồng thuận. Ngay cả khi có nút Byzantine và độ trễ mạng, giao thức vẫn bảo đảm các giao dịch được siêu đa số nút trung thực ủng hộ cuối cùng sẽ được đưa vào, còn các giao dịch không có mức ủng hộ đó sẽ bị loại. Thời gian đồng thuận hữu hạn (thường khoảng 5 giây) mang lại bảo đảm tính sống thực tế phù hợp với các ứng dụng thanh toán.
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
Unique Node List (UNL) là thành phần cốt lõi của RPCA, tạo nên điểm khác biệt với các thuật toán đồng thuận khác. Mỗi nút trong mạng Ripple duy trì một UNL gồm các nút khác mà nó tin rằng sẽ không thông đồng để gian lận mạng. Điểm then chốt là niềm tin này mang tính cục bộ, không phải toàn cục: các nút khác nhau có thể có UNL khác nhau, và không có yêu cầu phải tồn tại một tập validator thống nhất toàn mạng. Thiết kế này cho phép mạng mở rộng tự nhiên trong khi vẫn giữ tính phi tập trung.
UNL đóng vai trò cơ chế chống tấn công Sybil mà không cần proof-of-work. Trong hệ bỏ phiếu ngây thơ, kẻ tấn công có thể tạo nhiều danh tính giả để giành ảnh hưởng không cân xứng. Bằng cách buộc mỗi nút phải chỉ rõ nó tin nút nào, RPCA bảo đảm việc tạo thêm danh tính không mang lại lợi thế trừ khi các danh tính đó thuyết phục được các nút hiện có thêm chúng vào UNL. Nhờ đó, bài toán kháng Sybil được chuyển từ chi phí tính toán sang quan hệ uy tín và tin cậy.
Để mạng hoạt động đúng, UNL phải được chọn sao cho có độ chồng lấn đủ lớn như đã nêu trong phân tích hình thức. Trong thực tế, điều này có nghĩa là dù mỗi nhà vận hành nút có quyền tự chủ khi chọn UNL, họ vẫn cần bảo đảm danh sách của mình bao gồm các validator cũng được các phần khác của mạng tin cậy. Ripple cung cấp một UNL mặc định gồm các validator do nhiều thực thể vận hành, nhưng nhà vận hành có thể điều chỉnh danh sách này theo đánh giá tin cậy riêng.
Cơ chế UNL cũng tạo ra con đường tự nhiên hướng đến phi tập trung dần theo thời gian. Ở giai đoạn đầu của mạng, tập validator tập trung hơn có thể phù hợp để bảo đảm ổn định và độ tin cậy. Khi mạng trưởng thành và nhiều nhà vận hành đa dạng chứng minh được uy tín, UNL có thể tiến hóa để bao gồm tập validator rộng hơn, tăng khả năng chống chịu và mức độ phi tập trung mà không làm suy giảm các thuộc tính bảo mật.
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
Để kiểm chứng phân tích lý thuyết của RPCA và đánh giá hiệu năng dưới nhiều điều kiện, các mô phỏng quy mô lớn đã được thực hiện bằng phần mềm mô phỏng tùy biến. Khung mô phỏng mô hình hóa một mạng các nút, mỗi nút duy trì UNL riêng và tham gia giao thức đồng thuận. Mã nguồn triển khai đầy đủ thuật toán RPCA, bao gồm đề xuất giao dịch, các vòng bỏ phiếu với ngưỡng tăng dần và xác thực sổ cái.
Các tham số chính được thay đổi trong mô phỏng gồm kích thước mạng (từ 10 đến 1.000 nút), tỷ lệ nút Byzantine (từ 0% đến 20%), kích thước UNL (thường từ 5 đến 50 nút), và cấu hình topology mạng. Với mỗi cấu hình tham số, nhiều lần chạy mô phỏng được thực hiện với các random seed khác nhau để bảo đảm độ tin cậy thống kê của kết quả. Các mô phỏng theo dõi các chỉ số như độ trễ đồng thuận, xác suất phân nhánh, và thông lượng giao dịch.
Kết quả mô phỏng xác nhận các dự đoán lý thuyết về hội tụ và an toàn. Trong mọi cấu hình mà điều kiện chồng lấn UNL được thỏa và tỷ lệ Byzantine trong mỗi UNL dưới 20%, mạng đạt đồng thuận thành công mà không xảy ra phân nhánh. Độ trễ đồng thuận luôn thấp (thường hoàn tất trong 3-5 giây mô phỏng) bất kể kích thước mạng, cho thấy tính mở rộng của thuật toán. Ngay cả khi 15% nút Byzantine chủ động phá hoại đồng thuận, mạng vẫn giữ được tính đúng đắn miễn là điều kiện chồng lấn UNL được đáp ứng.
Các mô phỏng bổ sung cũng khảo sát các trường hợp biên và kịch bản lỗi, gồm phân vùng mạng, thay đổi đột ngột thành phần UNL, và tấn công phối hợp của các nút Byzantine. Các mô phỏng này cung cấp thêm hiểu biết về độ vững chắc của giao thức và định hình các thực hành tốt nhất được khuyến nghị cho lựa chọn UNL và vận hành mạng. Toàn bộ mã mô phỏng đã được công bố để cho phép kiểm chứng độc lập và nghiên cứu tiếp theo.
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
So với đồng thuận proof-of-work của Bitcoin, RPCA mang lại nhiều lợi thế đáng kể cho các ứng dụng hệ thống thanh toán. Nổi bật nhất là độ trễ đồng thuận giảm từ 40-60 phút (thời gian thường được khuyến nghị cho giao dịch Bitcoin giá trị cao) xuống khoảng 5 giây. Cải thiện này khiến RPCA phù hợp cho điểm bán hàng và các ứng dụng đòi hỏi quyết toán gần như tức thời. Ngoài ra, RPCA yêu cầu tài nguyên tính toán tối thiểu so với proof-of-work, loại bỏ mức tiêu thụ năng lượng khổng lồ gắn với hoạt động đào Bitcoin.
Tuy nhiên, các lợi thế này đi kèm giả định tin cậy khác. Trong khi bảo mật của Bitcoin chỉ dựa trên giả định không có kẻ tấn công nào kiểm soát quá 50% năng lực tính toán toàn mạng, RPCA yêu cầu các nút chọn UNL có độ chồng lấn đủ lớn và số nút Byzantine không vượt ngưỡng trong các UNL đó. Điều này chuyển một phần trách nhiệm sang nhà vận hành nút trong việc đưa ra quyết định tin cậy thận trọng. Trong thực tế, đánh đổi này chấp nhận được trong nhiều bối cảnh thanh toán nơi các tổ chức tham gia vốn đã có quan hệ tin cậy.
Topology mạng và chiến lược chọn UNL ảnh hưởng mạnh đến đặc tính của hệ đồng thuận. Topology tập trung cao, nơi mọi nút cùng dùng chung validator trong UNL, tối đa hóa an toàn nhưng có thể làm giảm tính sống nếu các validator đó không khả dụng. Ngược lại, topology phi tập trung cao với độ chồng lấn UNL thấp có thể cải thiện tính sống nhưng làm tăng rủi ro thất bại đồng thuận nếu chồng lấn trở nên quá thưa. Việc tìm điểm cân bằng tối ưu đòi hỏi cân nhắc kỹ kịch bản triển khai cụ thể và mức chấp nhận rủi ro.
Các hướng nghiên cứu tương lai có thể gồm thuật toán chọn UNL thích nghi tự động duy trì điều kiện chồng lấn trong khi tối đa hóa phi tập trung, cơ chế để nút điều chỉnh UNL động theo hành vi validator quan sát được, và mở rộng thuật toán đồng thuận để chịu được tỷ lệ nút Byzantine cao hơn nữa. Những cải tiến này có thể tiếp tục nâng cao độ vững chắc và phạm vi ứng dụng của RPCA cho các hệ thống thanh toán phân tán quy mô lớn.
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
Thuật toán Đồng thuận Giao thức Ripple là một bước tiến quan trọng của đồng thuận phân tán cho hệ thống thanh toán. Bằng cách sử dụng các mạng con được tin cậy tập thể thay vì yêu cầu đồng thuận toàn cục giữa mọi nút, RPCA đạt đồng thuận trong vài giây mà vẫn giữ bảo đảm mạnh trước lỗi Byzantine. Phân tích hình thức cho thấy rằng khi UNL được chọn với độ chồng lấn đủ lớn và tỷ lệ nút Byzantine nằm dưới ngưỡng, mạng sẽ đạt đồng thuận đúng mà không phân nhánh.
Ý nghĩa thực tiễn của công trình này vượt ra ngoài mạng thanh toán Ripple. RPCA cho thấy đánh đổi truyền thống giữa độ trễ đồng thuận và bảo đảm bảo mật có thể được vượt qua bằng thiết kế giao thức cẩn thận và việc khai thác quan hệ tin cậy cục bộ. Cách tiếp cận này có thể áp dụng cho các hệ phân tán khác nơi độ trễ thấp là yếu tố then chốt và các bên tham gia có quan hệ tin cậy sẵn có, như thanh toán liên ngân hàng, theo dõi chuỗi cung ứng, và các hạ tầng tài chính khác.
Việc triển khai RPCA trong môi trường sản xuất đã xác nhận đặc tính hiệu năng và độ vững chắc của thuật toán. Mạng Ripple xử lý hàng nghìn giao dịch mỗi giây với độ trễ đồng thuận ổn định 3-5 giây, chứng minh rằng các thuộc tính lý thuyết có thể chuyển hóa hiệu quả thành vận hành thực tế. Khi mạng tiếp tục phát triển và bổ sung thêm validator từ các nhà vận hành đa dạng, nó trở thành ví dụ thực tiễn về cách một hệ đồng thuận phi tập trung có thể duy trì đồng thời bảo mật và hiệu năng ở quy mô lớn.
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., và Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. Công trình nền tảng này đã hình thức hóa bài toán đạt đồng thuận trong hệ phân tán có thành phần lỗi và đặt nền móng lý thuyết cho các hệ chịu lỗi Byzantine.
Castro, M., và Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). Công trình này giới thiệu PBFT, cho thấy chịu lỗi Byzantine có thể đạt được với hiệu năng thực tiễn, dù độ phức tạp truyền thông O(n^2) giới hạn khả năng mở rộng.
Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." Whitepaper này giới thiệu đồng thuận proof-of-work như lời giải cho bài toán chi tiêu kép trong tiền tệ số, cho phép đồng thuận phi tập trung không cần bên tin cậy nhưng đánh đổi bằng độ trễ cao và tiêu thụ năng lượng lớn.
Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. Bài báo này trình bày thuật toán Paxos, đạt đồng thuận trong hệ bất đồng bộ dưới lỗi sập và có ảnh hưởng lớn đến thiết kế các giao thức đồng thuận về sau.
Fischer, M. J., Lynch, N. A., và Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. Kết quả bất khả thi FLP thiết lập giới hạn cơ bản về những gì thuật toán đồng thuận có thể đạt trong hệ bất đồng bộ, qua đó định hình không gian thiết kế cho các giao thức đồng thuận thực tế.
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.
