रिपल प्रोटोकॉल सर्वसम्मति एल्गोरिथ्म
Abstract
แม้ว่าจะมีอัลกอริทึมฉันทามติหลายแบบสำหรับปัญหานายพลไบแซนไทน์ โดยเฉพาะในบริบทของระบบการชำระเงินแบบกระจาย แต่หลายแนวทางยังมีความหน่วงสูงจากข้อกำหนดที่ว่าโหนดทั้งหมดในเครือข่ายต้องสื่อสารกันแบบซิงโครนัส งานนี้นำเสนออัลกอริทึมฉันทามติแบบใหม่ที่หลีกเลี่ยงข้อกำหนดดังกล่าว โดยอาศัยเครือข่ายย่อยที่ได้รับความไว้วางใจร่วมกันภายในเครือข่ายขนาดใหญ่กว่า เราแสดงให้เห็นว่า "ความไว้วางใจ" ที่จำเป็นต่อการป้องกันการโจมตี Sybil ไม่ได้เป็นแบบทั่วโลก แต่เป็นแบบเฉพาะที่ในระดับแต่ละโหนด
Ripple Protocol Consensus Algorithm (RPCA) ถูกนำมาใช้ทุก ๆ ไม่กี่วินาทีโดยทุกโหนด เพื่อรักษาความถูกต้องและความสอดคล้องของเครือข่าย เมื่อได้ฉันทามติแล้ว ledger ปัจจุบันจะถือว่า "ปิด" และกลายเป็น last-closed ledger อัลกอริทึมนี้โดดเด่นตรงที่ให้ฉันทามติได้ด้วยความหน่วงต่ำ ขณะยังคงการรับประกันที่แข็งแรงต่อความล้มเหลวแบบ Byzantine จึงเหมาะกับระบบชำระบัญชีทางการเงินแบบเรียลไทม์
Abstract
हालांकि Byzantine Generals Problem के लिए कई सहमति एल्गोरिदम मौजूद हैं, विशेष रूप से वितरित भुगतान प्रणालियों के संबंध में, उनमें से कई नेटवर्क के सभी नोड्स को समकालिक रूप से संवाद करने की आवश्यकता के कारण उच्च विलंबता से ग्रस्त हैं। इस कार्य में, हम एक नवीन सहमति एल्गोरिदम प्रस्तुत करते हैं जो बड़े नेटवर्क के भीतर सामूहिक रूप से विश्वसनीय उप-नेटवर्क का उपयोग करके इस आवश्यकता को दरकिनार करता है। हम दिखाते हैं कि Sybil हमलों को रोकने के लिए आवश्यक "विश्वास" वास्तव में वैश्विक नहीं है, बल्कि नेटवर्क में प्रत्येक नोड के लिए स्थानीय है।
Ripple प्रोटोकॉल सहमति एल्गोरिदम (RPCA) नेटवर्क की शुद्धता और सहमति बनाए रखने के लिए सभी नोड्स द्वारा हर कुछ सेकंड में लागू किया जाता है। एक बार सहमति प्राप्त हो जाने पर, वर्तमान लेजर को "बंद" माना जाता है और यह अंतिम-बंद लेजर बन जाता है। यह एल्गोरिदम अद्वितीय है क्योंकि यह Byzantine विफलताओं के खिलाफ मजबूत गारंटी बनाए रखते हुए कम विलंबता के साथ सहमति प्राप्त करता है, जो इसे वास्तविक समय वित्तीय निपटान प्रणालियों के लिए उपयुक्त बनाता है।
Introduction
ระบบการชำระเงินแบบกระจายจำเป็นต้องมีอัลกอริทึมฉันทามติเพื่อประมวลผลการชำระเงินให้ถูกต้องและทันเวลา แม้ในสภาพที่มีผู้มีส่วนร่วมที่ผิดพลาดหรือประสงค์ร้าย Bitcoin บรรลุฉันทามติด้วย proof-of-work ซึ่งกำหนดให้ทุกโหนดใช้ทรัพยากรคอมพิวเตอร์ในการแก้ปริศนาการเข้ารหัส แม้วิธีนี้จะให้การรับประกันความปลอดภัยที่แข็งแรง แต่ก็มีข้อเสียสำคัญ ได้แก่ การใช้พลังงานสูง ปริมาณธุรกรรมต่อเวลาต่ำ และความหน่วงในการยืนยันที่ยาวนาน ซึ่งอาจนานถึงหนึ่งชั่วโมงหรือมากกว่านั้นสำหรับธุรกรรมมูลค่าสูง
Ripple Protocol Consensus Algorithm เสนอแนวทางใหม่ของฉันทามติแบบกระจายที่ไม่ต้องอาศัย proof-of-work แทนที่จะทำเช่นนั้น โหนดในเครือข่ายจะร่วมกันตกลงบนชุดธุรกรรมผ่านกระบวนการโหวตที่ได้ฉันทามติภายในไม่กี่วินาที กลไกนี้ออกแบบมาโดยเฉพาะสำหรับข้อกำหนดของเครือข่ายการชำระเงินระดับโลก ซึ่งความหน่วงต่ำและปริมาณงานสูงเป็นเงื่อนไขสำคัญต่อการใช้งานจริง
นวัตกรรมหลักของ RPCA คือไม่ต้องให้ทุกโหนดในเครือข่ายเห็นพ้องกันทั้งหมด แต่ให้แต่ละโหนดเก็บ Unique Node List (UNL) ของโหนดอื่นที่ตนเชื่อว่าจะไม่สมรู้ร่วมคิด ตราบใดที่ UNL ของโหนดต่าง ๆ มีการทับซ้อนเพียงพอ และจำนวนโหนดที่ผิดพลาดต่ำกว่าเกณฑ์ที่กำหนด เครือข่ายจะบรรลุฉันทามติได้ แนวทางนี้ให้การรับประกันความปลอดภัยที่ระบบการชำระเงินต้องการ พร้อมกับความหน่วงฉันทามติระดับวินาทีแทนนาทีหรือชั่วโมง
Introduction
एक वितरित भुगतान प्रणाली को दोषपूर्ण या दुर्भावनापूर्ण अभिकर्ताओं की उपस्थिति में भी भुगतानों को सही और समय पर संसाधित करने के लिए एक सहमति एल्गोरिदम लागू करना होगा। Bitcoin प्रूफ-ऑफ-वर्क (proof-of-work) का उपयोग करके सहमति प्राप्त करता है, जिसमें सभी नोड्स को क्रिप्टोग्राफिक पहेलियों को हल करने के लिए कम्प्यूटेशनल संसाधन खर्च करने की आवश्यकता होती है। हालांकि यह दृष्टिकोण मजबूत सुरक्षा गारंटी प्रदान करता है, इसमें महत्वपूर्ण कमियां हैं जिनमें उच्च ऊर्जा खपत, कम लेनदेन थ्रूपुट और लंबी पुष्टि विलंबता शामिल है जो उच्च-मूल्य लेनदेन के लिए एक घंटे या उससे अधिक तक बढ़ सकती है।
Ripple प्रोटोकॉल सहमति एल्गोरिदम वितरित सहमति के लिए एक नया दृष्टिकोण प्रदान करता है जिसमें प्रूफ-ऑफ-वर्क की आवश्यकता नहीं होती। इसके बजाय, नेटवर्क में नोड्स एक मतदान प्रक्रिया के माध्यम से लेनदेन सेट पर सामूहिक रूप से सहमत होते हैं जो सेकंडों में सहमति प्राप्त करती है। यह सहमति तंत्र विशेष रूप से एक वैश्विक भुगतान नेटवर्क की आवश्यकताओं के लिए डिज़ाइन किया गया है, जहां व्यावहारिक तैनाती के लिए कम विलंबता और उच्च थ्रूपुट आवश्यक हैं।
RPCA में प्रमुख नवाचार यह है कि इसमें नेटवर्क के सभी नोड्स को एक-दूसरे से सहमत होने की आवश्यकता नहीं होती। इसके बजाय, प्रत्येक नोड अन्य नोड्स की एक Unique Node List (UNL) बनाए रखता है जिन पर वह मिलीभगत न करने का भरोसा करता है। जब तक नोड्स द्वारा चुनी गई UNL में पर्याप्त ओवरलैप होता है, और नोड्स का एक सीमा प्रतिशत से कम दोषपूर्ण होता है, तब तक नेटवर्क सहमति प्राप्त करेगा। यह दृष्टिकोण भुगतान प्रणाली के लिए आवश्यक सुरक्षा गारंटी प्रदान करता है जबकि सहमति विलंबता को मिनटों या घंटों के बजाय सेकंडों में मापा जाता है।
Definition of Consensus
ในระบบแบบกระจาย ฉันทามติคือกระบวนการที่เครือข่ายของโหนดตกลงร่วมกันบนสถานะเดียวกัน แม้จะมีผู้เข้าร่วมที่ผิดพลาดหรือประสงค์ร้าย อัลกอริทึมฉันทามติต้องมีคุณสมบัติพื้นฐานสามประการ ได้แก่ correctness (โหนดที่ถูกต้องสองโหนดต้องไม่ตัดสินใจต่างกัน), agreement (โหนดที่ถูกต้องทั้งหมดต้องตัดสินใจเหมือนกัน), และ termination (โหนดที่ถูกต้องทั้งหมดต้องตัดสินใจได้ในที่สุด) คุณสมบัติเหล่านี้ทำให้ระบบกระจายทำงานเสมือนเป็นโหนดเดียวที่เชื่อถือได้
ความท้าทายของการบรรลุฉันทามติมาจากความไม่น่าเชื่อถือโดยธรรมชาติของระบบกระจาย โหนดอาจล่ม ข้อความอาจล่าช้าหรือสูญหาย และโหนด Byzantine อาจมีพฤติกรรมตามอำเภอใจหรือเป็นอันตราย ปัญหานายพลไบแซนไทน์ที่ Lamport, Shostak และ Pease นิยามไว้อย่างเป็นทางการ สะท้อนความท้าทายนี้โดยตรง: กลุ่มโปรเซสจะตกลงร่วมกันได้อย่างไรเมื่อบางส่วนอาจผิดพลาดและการสื่อสารไม่น่าเชื่อถือ
ผลลัพธ์คลาสสิกในงานคำนวณแบบกระจายชี้ให้เห็นขอบเขตพื้นฐานของสิ่งที่อัลกอริทึมฉันทามติทำได้ ผลลัพธ์ความเป็นไปไม่ได้ของ FLP แสดงว่าไม่มีอัลกอริทึมเชิงกำหนดใดรับประกันฉันทามติได้ในระบบอะซิงโครนัส หากแม้แต่โหนดเดียวมีโอกาสล้มเหลว ดังนั้นอัลกอริทึมฉันทามติภาคปฏิบัติจึงต้องแลกเปลี่ยนระหว่าง safety (ไม่บรรลุฉันทามติที่ผิด) และ liveness (ระบบยังคงเดินหน้าได้เสมอ) proof-of-work ของ Bitcoin ให้ความสำคัญกับ safety มากกว่า liveness ขณะที่ RPCA สร้างสมดุลที่เหมาะกับระบบชำระเงินมากกว่า โดยปิดรอบฉันทามติได้ภายในเวลาจำกัดและยังคงการรับประกัน safety ที่แข็งแรงภายใต้สมมติฐานความผิดพลาดที่สมจริง
Definition of Consensus
वितरित प्रणालियों में, सहमति उस प्रक्रिया को संदर्भित करती है जिसके द्वारा नोड्स का एक नेटवर्क दोषपूर्ण या दुर्भावनापूर्ण प्रतिभागियों की उपस्थिति के बावजूद एक साझा स्थिति पर सहमति पर पहुंचता है। एक सहमति एल्गोरिदम को तीन मूलभूत गुणों को संतुष्ट करना चाहिए: शुद्धता (कोई भी दो सही नोड अलग-अलग निर्णय नहीं लेते), सहमति (सभी सही नोड एक ही निर्णय पर पहुंचते हैं), और समाप्ति (सभी सही नोड अंततः निर्णय लेते हैं)। ये गुण सुनिश्चित करते हैं कि वितरित प्रणाली ऐसे व्यवहार करती है जैसे कि वह एक एकल, विश्वसनीय नोड हो।
सहमति प्राप्त करने की चुनौती वितरित प्रणालियों की अंतर्निहित अविश्वसनीयता से उत्पन्न होती है। नोड्स क्रैश हो सकते हैं, संदेश विलंबित या खो सकते हैं, और Byzantine नोड्स मनमाने ढंग से या दुर्भावनापूर्ण तरीके से व्यवहार कर सकते हैं। Byzantine Generals Problem, जिसे Lamport, Shostak और Pease ने औपचारिक रूप दिया, इस चुनौती को पकड़ती है: प्रक्रियाओं का एक समूह कैसे सहमति पर पहुंच सकता है जब कुछ अंश दोषपूर्ण हो सकता है और जब संचार अविश्वसनीय हो?
वितरित कंप्यूटिंग में शास्त्रीय परिणाम इस बात की मूलभूत सीमाएं स्थापित करते हैं कि सहमति एल्गोरिदम क्या हासिल कर सकते हैं। FLP असंभवता परिणाम दिखाता है कि कोई भी नियतात्मक एल्गोरिदम एक असमकालिक प्रणाली में सहमति की गारंटी नहीं दे सकता यदि एक भी नोड विफल हो सकता है। इसलिए व्यावहारिक सहमति एल्गोरिदम को सुरक्षा (कभी भी गलत सहमति नहीं पहुंचना) और जीवंतता (हमेशा प्रगति करना) के बीच समझौता करना होगा। Bitcoin का proof-of-work जीवंतता पर सुरक्षा को प्राथमिकता देता है, जबकि RPCA यथार्थवादी दोष धारणाओं के तहत मजबूत सुरक्षा गारंटी बनाए रखते हुए सीमित समय में सहमति दौर पूरा करके भुगतान प्रणालियों के लिए अधिक उपयुक्त संतुलन प्राप्त करता है।
Existing Consensus Algorithms
มีการเสนออัลกอริทึมฉันทามติหลายแบบเพื่อแก้ปัญหานายพลไบแซนไทน์ในระบบแบบกระจาย อัลกอริทึม Practical Byzantine Fault Tolerance (PBFT) ที่ Castro และ Liskov นำเสนอ สามารถทนต่อความผิดพลาดแบบ Byzantine ได้สูงสุด f ตัว ในระบบที่มี 3f+1 โหนด PBFT บรรลุฉันทามติผ่านหลายรอบของการแลกเปลี่ยนข้อความระหว่างทุกโหนด โดยมีความซับซ้อนด้านการสื่อสาร O(n^2) เมื่อ n คือจำนวนโหนด แม้ PBFT จะให้ safety ที่แข็งแรงและความหน่วงค่อนข้างต่ำในเครือข่ายขนาดเล็ก แต่ไม่ขยายตัวได้ดีในเครือข่ายขนาดใหญ่เนื่องจากภาระการสื่อสารแบบกำลังสอง
Paxos และอนุพันธ์ซึ่งพัฒนาโดย Lamport ให้ฉันทามติในระบบอะซิงโครนัส แต่ตั้งสมมติฐานความผิดพลาดแบบ crash แทน Byzantine Paxos ทำงานผ่านชุดรอบที่ proposer เสนอค่าและ acceptor โหวต แม้ Paxos จะทนต่อความล่าช้าของข้อความแบบไม่จำกัดและการล่มของโปรเซสได้ แต่การรับมือความผิดพลาดแบบ Byzantine ต้องใช้การออกแบบวิศวกรรมอย่างระมัดระวัง และในบางสถานการณ์อาจเกิด livelock
ฉันทามติแบบ proof-of-work ของ Bitcoin ใช้แนวทางที่ต่างออกไปโดยสิ้นเชิง คือทำให้การโจมตี Byzantine ไม่คุ้มค่าทางเศรษฐศาสตร์ โหนดแข่งขันกันแก้ปริศนาการเข้ารหัส โดยผู้ชนะจะเสนอ block ธุรกรรมถัดไป แม้แนวทางนี้จะสเกลได้กับขนาดเครือข่ายตามต้องการและรองรับความผิดพลาดแบบ Byzantine แต่มีข้อเสียรุนแรง ได้แก่ การใช้พลังงานมหาศาล (มีการประเมินว่าเกิน 150 ล้านดอลลาร์ต่อปีสำหรับเครือข่าย Bitcoin), ความหน่วงในการยืนยันยาวนาน (มัก 40-60 นาทีสำหรับธุรกรรมมูลค่าสูง), และ throughput ที่จำกัด (ประมาณ 7 ธุรกรรมต่อวินาที) ข้อจำกัดเหล่านี้ทำให้ proof-of-work ไม่เหมาะกับหลายกรณีใช้งานระบบชำระเงินที่ต้องการการชำระบัญชีรวดเร็วและปริมาณธุรกรรมสูง
Existing Consensus Algorithms
वितरित प्रणालियों में Byzantine Generals Problem को हल करने के लिए कई सहमति एल्गोरिदम प्रस्तावित किए गए हैं। Practical Byzantine Fault Tolerance (PBFT) एल्गोरिदम, जिसे Castro और Liskov ने पेश किया, 3f+1 नोड्स की प्रणाली में f Byzantine दोषों तक सहन कर सकता है। PBFT सभी नोड्स के बीच संदेश विनिमय के कई दौरों के माध्यम से सहमति प्राप्त करता है, जिसमें O(n^2) की संचार जटिलता होती है, जहां n नोड्स की संख्या है। हालांकि PBFT छोटे नेटवर्क के लिए मजबूत सुरक्षा गारंटी और अपेक्षाकृत कम विलंबता प्रदान करता है, द्विघात संचार ओवरहेड के कारण यह बड़े नेटवर्क के लिए अच्छी तरह से स्केल नहीं करता।
Paxos और इसके संस्करण, Lamport द्वारा विकसित, असमकालिक प्रणालियों में सहमति प्रदान करते हैं लेकिन Byzantine दोषों के बजाय क्रैश विफलताओं को मानते हैं। Paxos दौरों की एक श्रृंखला के माध्यम से सहमति प्राप्त करता है जिसमें प्रस्तावक मूल्य सुझाते हैं और स्वीकर्ता उन पर मतदान करते हैं। हालांकि Paxos मनमानी संदेश विलंबता और प्रक्रिया क्रैश को सहन कर सकता है, इसमें Byzantine विफलताओं को संभालने के लिए सावधानीपूर्वक इंजीनियरिंग की आवश्यकता होती है और कुछ परिदृश्यों में livelock से ग्रस्त हो सकता है।
Bitcoin का proof-of-work सहमति एल्गोरिदम Byzantine हमलों को आर्थिक रूप से अव्यवहार्य बनाकर एक मौलिक रूप से भिन्न दृष्टिकोण अपनाता है। नोड्स क्रिप्टोग्राफिक पहेलियों को हल करने के लिए प्रतिस्पर्धा करते हैं, विजेता लेनदेन का अगला ब्लॉक प्रस्तावित करता है। हालांकि यह दृष्टिकोण मनमाने नेटवर्क आकार तक स्केल करता है और Byzantine दोषों को संभालता है, इसमें गंभीर कमियां हैं: भारी ऊर्जा खपत (Bitcoin नेटवर्क के लिए प्रति वर्ष 150 मिलियन डॉलर से अधिक अनुमानित), लंबी पुष्टि विलंबता (उच्च-मूल्य लेनदेन के लिए अक्सर 40-60 मिनट), और सीमित थ्रूपुट (लगभग 7 लेनदेन प्रति सेकंड)। ये सीमाएं proof-of-work को कई भुगतान प्रणाली अनुप्रयोगों के लिए अनुपयुक्त बनाती हैं जिनमें तेजी से निपटान और उच्च लेनदेन मात्रा की आवश्यकता होती है।
Ripple Protocol Consensus Algorithm
Ripple Protocol Consensus Algorithm (RPCA) เริ่มต้นจากการที่เซิร์ฟเวอร์แต่ละตัวรวบรวมธุรกรรมที่ถูกต้องทั้งหมดที่ตนพบและยังไม่ถูกนำไปใช้ ให้เป็นธุรกรรมผู้สมัคร จากนั้นเซิร์ฟเวอร์จะทำตามโปรโตคอลหลายรอบ โดยทำงานแบบวนซ้ำเพื่อให้ได้ข้อตกลงร่วมกันบนชุดธุรกรรมที่จะนำไปใช้กับ ledger ปัจจุบัน ในแต่ละรอบ เซิร์ฟเวอร์จะยื่นข้อเสนอที่ประกอบด้วยธุรกรรมที่ตนเชื่อว่าควรถูกบรรจุใน ledger ถัดไป
ระหว่างแต่ละรอบของฉันทามติ เซิร์ฟเวอร์จะสื่อสารข้อเสนอของตนไปยังเซิร์ฟเวอร์อื่นใน Unique Node List (UNL) ของตน แล้วจึงคำนวณว่าธุรกรรมใดปรากฏในสัดส่วนถึงเกณฑ์ของข้อเสนอ ตอนเริ่มต้นเกณฑ์นี้ตั้งไว้ที่ 50% หมายความว่าธุรกรรมต้องปรากฏในข้อเสนอจากอย่างน้อยครึ่งหนึ่งของ UNL ของเซิร์ฟเวอร์ จึงจะถูกพิจารณาในรอบถัดไป เมื่อฉันทามติดำเนินผ่านหลายรอบ เกณฑ์นี้จะเพิ่มขึ้นทีละขั้น (โดยทั่วไปเป็น 60%, 70% และสุดท้าย 80%)
เมื่อธุรกรรมใดถึงเกณฑ์ supermajority ที่ 80% ของการสนับสนุนภายใน UNL ของเซิร์ฟเวอร์ ธุรกรรมนั้นจะถูกใส่ไว้ในข้อเสนอสำหรับรอบฉันทามติสุดท้ายของเซิร์ฟเวอร์ ธุรกรรมทั้งหมดที่ถึงเกณฑ์นี้ทั่วทั้งเครือข่ายจะถูกนำไปใช้กับ ledger จากนั้น ledger จะถูก hash และลงลายมือชื่อเชิงคริปโตกราฟี ledger ที่ผ่านการตรวจสอบใหม่นี้จะกลายเป็น last-closed ledger และกระบวนการจะเริ่มใหม่กับชุดธุรกรรมผู้สมัครถัดไป
กระบวนการฉันทามติโดยทั่วไปเสร็จสิ้นใน 5 วินาทีหรือน้อยกว่า โดยธุรกรรมส่วนใหญ่ต้องใช้เพียงหนึ่งรอบเพื่อถึงเกณฑ์ supermajority ธุรกรรมที่ยังไม่ถึงฉันทามติในรอบหนึ่งจะคงสถานะผู้สมัครสำหรับรอบถัดไป การออกแบบนี้ทำให้เครือข่ายเดินหน้าต่อเนื่องพร้อมรักษา safety ที่แข็งแรง เนื่องจากไม่มีธุรกรรมใดถูกนำเข้า ledger ได้หากไม่มีการสนับสนุนระดับ supermajority จาก validator ที่เชื่อถือได้
Ripple Protocol Consensus Algorithm
Ripple प्रोटोकॉल सहमति एल्गोरिदम (RPCA) प्रत्येक सर्वर द्वारा उन सभी वैध लेनदेन को लेकर शुरू होता है जो उसने देखे हैं और जो अभी तक कैंडिडेट लेनदेन के रूप में लागू नहीं किए गए हैं। सर्वर फिर एक बहु-दौर प्रोटोकॉल का पालन करते हैं जहां वे वर्तमान लेजर पर लागू किए जाने वाले लेनदेन के एक सेट पर सहमति की ओर पुनरावृत्त रूप से काम करते हैं। प्रत्येक दौर में, सर्वर उन लेनदेन से युक्त प्रस्ताव बनाते हैं जिन्हें वे अगले लेजर में शामिल किया जाना चाहिए।
प्रत्येक सहमति दौर के दौरान, सर्वर अपने Unique Node List (UNL) में अन्य सर्वरों को अपने प्रस्ताव संप्रेषित करते हैं। सर्वर तब गणना करते हैं कि कौन से लेनदेन प्रस्तावों के एक सीमा प्रतिशत में दिखाई देते हैं। शुरू में, यह सीमा 50% पर निर्धारित होती है, जिसका अर्थ है कि एक लेनदेन को अगले दौर के लिए विचार किए जाने हेतु सर्वर की UNL के कम से कम आधे प्रस्तावों में दिखाई देना चाहिए। जैसे-जैसे सहमति क्रमिक दौरों के माध्यम से आगे बढ़ती है, यह सीमा क्रमिक रूप से बढ़ती है (आमतौर पर 60%, 70%, और अंत में 80%)।
जब कोई लेनदेन सर्वर की UNL में 80% समर्थन की सुपरमेजॉरिटी सीमा प्राप्त करता है, तो इसे अंतिम सहमति दौर के लिए उस सर्वर के प्रस्ताव में शामिल किया जाता है। नेटवर्क भर में इस सीमा तक पहुंचने वाले सभी लेनदेन लेजर पर लागू किए जाते हैं, जिसे फिर क्रिप्टोग्राफिक रूप से हैश और हस्ताक्षरित किया जाता है। यह नव सत्यापित लेजर अंतिम-बंद लेजर बन जाता है, और प्रक्रिया कैंडिडेट लेनदेन के अगले सेट के साथ फिर से शुरू होती है।
सहमति प्रक्रिया आमतौर पर 5 सेकंड या उससे कम में पूरी होती है, अधिकांश लेनदेन को सुपरमेजॉरिटी सीमा प्राप्त करने के लिए केवल एक सहमति दौर की आवश्यकता होती है। एक दौर में सहमति प्राप्त नहीं करने वाले लेनदेन बाद के दौरों के लिए कैंडिडेट बने रहते हैं। यह डिज़ाइन सुनिश्चित करता है कि नेटवर्क मजबूत सुरक्षा गारंटी बनाए रखते हुए निरंतर प्रगति करता है, क्योंकि कोई भी लेनदेन विश्वसनीय वैलिडेटरों के सुपरमेजॉरिटी समर्थन के बिना लेजर पर लागू नहीं किया जा सकता।
Formal Analysis of Convergence
ความถูกต้องของ RPCA ขึ้นอยู่กับระดับการทับซ้อนของ UNL ที่โหนดต่าง ๆ ในเครือข่ายเลือกอย่างมีนัยสำคัญ กำหนดให้ UNL_i คือ unique node list ของโหนด i และ UNL_i ∩ UNL_j คือเซตของโหนดที่อยู่ทั้งใน UNL_i และ UNL_j เพื่อให้เครือข่ายคงฉันทามติได้ ต้องมีเงื่อนไขว่าคู่โหนดใด ๆ i และ j มีขนาดจุดตัดของ UNL มากพอเมื่อเทียบกับขนาดที่ใหญ่ที่สุดของ UNL ทั้งสอง
โดยเฉพาะ โปรโตคอลรับประกัน safety เมื่อ |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 สำหรับทุกคู่โหนด i และ j เงื่อนไขนี้ทำให้แม้โหนด Byzantine พยายามผลักดันให้ส่วนต่าง ๆ ของเครือข่ายตัดสินใจไม่ตรงกัน การทับซ้อนของโหนดที่เชื่อถือได้ก็ยังป้องกันการแตก fork ได้ หากเงื่อนไขนี้เป็นจริงและสัดส่วนโหนด Byzantine ใน UNL ใด ๆ ต่ำกว่า 1/5 โหนดที่ถูกต้องทั้งหมดจะลงเอยด้วยการตัดสินใจฉันทามติแบบเดียวกัน
หลักฐานเชิงรูปแบบดำเนินโดยแสดงว่า หากสองโหนดสามารถไปถึงการตัดสินใจฉันทามติที่ต่างกันได้ จะต้องมีธุรกรรม T ที่อยู่ใน ledger สุดท้ายของโหนดหนึ่งแต่ไม่อยู่ในอีกโหนดหนึ่ง การเกิดเหตุเช่นนี้ต้องการให้ T ได้รับการสนับสนุน 80% ใน UNL ของโหนดแรก แต่ต่ำกว่า 80% ใน UNL ของโหนดที่สอง อย่างไรก็ตาม ภายใต้ข้อกำหนดการทับซ้อนและข้อจำกัดจำนวนโหนด Byzantine สถานการณ์นี้พิสูจน์ได้ว่าเป็นไปไม่ได้: หาก T ได้ 80% ใน UNL_i ก็ต้องได้อย่างน้อย 60% ใน UNL_j ที่เข้าเงื่อนไขการทับซ้อน และเมื่อมีรอบฉันทามติเพียงพอ ค่าดังกล่าวจะลู่เข้าไปที่ 80% หรือถูกปฏิเสธโดยทั้งสองโหนด
คุณสมบัติ liveness ซึ่งหมายถึงการได้ฉันทามติในที่สุด มาจากข้อเท็จจริงว่าเกณฑ์การรวมธุรกรรมเพิ่มขึ้นแบบเชิงกำหนดผ่านแต่ละรอบฉันทามติ แม้จะมีโหนด Byzantine และความหน่วงเครือข่าย โปรโตคอลยังคงรับประกันว่าธุรกรรมที่ได้รับการสนับสนุนระดับ supermajority จากโหนดสุจริตจะถูกบรรจุในที่สุด ส่วนธุรกรรมที่ขาดการสนับสนุนดังกล่าวจะถูกตัดออก เวลาฉันทามติที่มีขอบเขต (โดยทั่วไปประมาณ 5 วินาที) จึงให้การรับประกัน liveness เชิงปฏิบัติที่เหมาะกับงานระบบชำระเงิน
Formal Analysis of Convergence
RPCA की शुद्धता नेटवर्क में विभिन्न नोड्स द्वारा चुनी गई UNL के बीच ओवरलैप पर गंभीर रूप से निर्भर करती है। UNL_i को नोड i की unique node list और UNL_i ∩ UNL_j को UNL_i और UNL_j दोनों में दिखाई देने वाले नोड्स के सेट के रूप में मानें। नेटवर्क को सहमति बनाए रखने के लिए, हम आवश्यक करते हैं कि किन्हीं भी दो नोड्स i और j के लिए, उनके UNL का प्रतिच्छेदन किसी भी UNL के अधिकतम आकार के सापेक्ष पर्याप्त रूप से बड़ा होना चाहिए।
विशेष रूप से, प्रोटोकॉल सुरक्षा की गारंटी देता है जब |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 सभी नोड जोड़ियों i और j के लिए। यह शर्त सुनिश्चित करती है कि भले ही Byzantine नोड्स नेटवर्क के विभिन्न भागों को अलग-अलग सहमति निर्णय लेने का कारण बनाने का प्रयास करें, विश्वसनीय नोड्स का ओवरलैप फोर्क को रोकता है। यदि यह शर्त पूरी होती है और किसी भी UNL में 1/5 से कम नोड्स Byzantine हैं, तो सभी सही नोड्स एक ही सहमति निर्णय पर पहुंचेंगे।
औपचारिक प्रमाण यह दिखाकर आगे बढ़ता है कि यदि दो नोड्स अलग-अलग सहमति निर्णय ले सकते, तो कोई लेनदेन T अवश्य होना चाहिए जो एक नोड के अंतिम लेजर में दिखाई देता है लेकिन दूसरे में नहीं। इसके लिए, T को पहले नोड की UNL में 80% समर्थन प्राप्त होना चाहिए लेकिन दूसरे नोड की UNL में 80% से कम समर्थन। हालांकि, ओवरलैप आवश्यकता और Byzantine नोड्स पर बाधा को देखते हुए, यह दिखाया जा सकता है कि यह परिदृश्य असंभव है: यदि T UNL_i में 80% समर्थन प्राप्त करता है, तो इसे ओवरलैप शर्त को संतुष्ट करने वाली किसी भी UNL_j में कम से कम 60% समर्थन प्राप्त करना चाहिए, और सहमति के पर्याप्त दौरों के साथ, यह 80% में अभिसरित होगा या दोनों नोड्स द्वारा अस्वीकार किया जाएगा।
जीवंतता गुण -- कि सहमति अंततः प्राप्त होगी -- इस अवलोकन से अनुसरण करता है कि शामिल करने की सीमा सहमति दौरों के माध्यम से नियतात्मक रूप से बढ़ती है। Byzantine नोड्स और नेटवर्क विलंब की उपस्थिति में भी, प्रोटोकॉल सुनिश्चित करता है कि ईमानदार नोड्स के सुपरमेजॉरिटी द्वारा समर्थित लेनदेन अंततः शामिल किए जाएंगे, जबकि ऐसे समर्थन की कमी वाले लेनदेन बाहर रखे जाएंगे। सहमति के लिए सीमित समय (आमतौर पर 5 सेकंड) भुगतान प्रणाली अनुप्रयोगों के लिए उपयुक्त व्यावहारिक जीवंतता गारंटी प्रदान करता है।
Unique Node Lists
Unique Node List (UNL) เป็นองค์ประกอบหลักของ RPCA ที่ทำให้แตกต่างจากอัลกอริทึมฉันทามติอื่น ๆ แต่ละโหนดในเครือข่าย Ripple จะดูแล UNL ของตนเอง ซึ่งประกอบด้วยโหนดอื่นที่ตนเชื่อว่าจะไม่สมรู้ร่วมคิดเพื่อฉ้อโกงเครือข่าย ประเด็นสำคัญคือความไว้วางใจนี้เป็นแบบเฉพาะที่ ไม่ใช่แบบทั่วโลก: โหนดต่างกันสามารถมี UNL ต่างกันได้ และไม่จำเป็นต้องมีชุด validator เดียวที่ทุกฝ่ายตกลงร่วมกันทั้งเครือข่าย การออกแบบนี้ช่วยให้เครือข่ายขยายตัวอย่างเป็นธรรมชาติพร้อมรักษาความเป็นกระจายอำนาจ
UNL ทำหน้าที่เป็นกลไกป้องกันการโจมตี Sybil โดยไม่ต้องพึ่ง proof-of-work ในระบบโหวตแบบง่าย ผู้โจมตีสามารถสร้างตัวตนปลอมจำนวนมากเพื่อเพิ่มอิทธิพลอย่างไม่สมส่วน แต่เมื่อ RPCA บังคับให้แต่ละโหนดต้องเลือกอย่างชัดเจนว่าจะเชื่อโหนดใด การสร้างตัวตนเพิ่มจึงไม่ให้ประโยชน์ เว้นแต่ตัวตนเหล่านั้นจะโน้มน้าวโหนดที่มีอยู่ให้เพิ่มเข้ามาใน UNL ได้ ปัญหาการต้านทาน Sybil จึงย้ายจากการใช้ทรัพยากรคำนวณไปสู่เรื่องชื่อเสียงและความสัมพันธ์เชิงความไว้วางใจ
เพื่อให้เครือข่ายทำงานได้อย่างถูกต้อง UNL ต้องถูกเลือกให้มีการทับซ้อนเพียงพอตามที่ระบุไว้ใน formal analysis ในทางปฏิบัติ แม้ผู้ดำเนินการโหนดแต่ละรายจะมีอิสระในการเลือก UNL ของตนเอง แต่ต้องทำให้แน่ใจว่ารายชื่อดังกล่าวรวม validator ที่ส่วนอื่นของเครือข่ายไว้วางใจด้วย Ripple มี UNL เริ่มต้นที่ประกอบด้วย validator จากหลายองค์กรที่หลากหลาย แต่ผู้ดำเนินการโหนดสามารถปรับเปลี่ยนรายชื่อตามการประเมินความไว้วางใจของตนเองได้
กลไก UNL ยังเปิดเส้นทางตามธรรมชาติสู่การกระจายอำนาจแบบค่อยเป็นค่อยไป ในช่วงแรกของเครือข่าย การมีชุด validator ที่รวมศูนย์กว่าอาจเหมาะสมต่อความเสถียรและความน่าเชื่อถือ เมื่อเครือข่ายเติบโตและผู้ดำเนินการที่หลากหลายพิสูจน์ความน่าเชื่อถือได้มากขึ้น UNL ก็สามารถพัฒนาให้รวม validator ที่กว้างขึ้น เพิ่มทั้งความยืดหยุ่นและความเป็นกระจายอำนาจ โดยไม่ลดทอนคุณสมบัติความปลอดภัย
Unique Node Lists
Unique Node List (UNL) RPCA का एक मूलभूत घटक है जो इसे अन्य सहमति एल्गोरिदम से अलग करता है। Ripple नेटवर्क में प्रत्येक नोड एक UNL बनाए रखता है जिसमें अन्य नोड्स शामिल होते हैं जिन पर वह नेटवर्क को धोखा देने के लिए मिलीभगत न करने का भरोसा करता है। महत्वपूर्ण रूप से, यह विश्वास वैश्विक के बजाय स्थानीय है: विभिन्न नोड्स की अलग-अलग UNL हो सकती हैं, और वैलिडेटरों के विश्व स्तर पर सहमत सेट की कोई आवश्यकता नहीं है। यह डिज़ाइन नेटवर्क को विकेंद्रीकरण बनाए रखते हुए स्वाभाविक रूप से बढ़ने की अनुमति देता है।
UNL प्रूफ-ऑफ-वर्क की आवश्यकता के बिना Sybil हमला रोकथाम तंत्र के रूप में कार्य करता है। एक भोले मतदान प्रणाली में, एक हमलावर असमानुपातिक प्रभाव प्राप्त करने के लिए कई छद्मनामी नोड्स बना सकता है। प्रत्येक नोड से स्पष्ट रूप से यह चुनने की आवश्यकता करके कि वह किन अन्य नोड्स पर भरोसा करता है, RPCA सुनिश्चित करता है कि अतिरिक्त पहचान बनाने से कोई लाभ नहीं होता जब तक कि वे पहचान मौजूदा नोड्स को अपनी UNL में जोड़ने के लिए मना नहीं सकतीं। यह Sybil प्रतिरोध की समस्या को कम्प्यूटेशनल व्यय से प्रतिष्ठा और विश्वास संबंधों में स्थानांतरित करता है।
नेटवर्क को सही ढंग से कार्य करने के लिए, UNL को इस प्रकार चुना जाना चाहिए कि उनमें पर्याप्त ओवरलैप हो, जैसा कि औपचारिक विश्लेषण में वर्णित है। व्यवहार में, इसका अर्थ है कि जहां प्रत्येक नोड ऑपरेटर को अपनी UNL चुनने में स्वायत्तता है, उन्हें यह सुनिश्चित करना होगा कि उनकी सूची में ऐसे वैलिडेटर शामिल हैं जिन पर नेटवर्क के अन्य भागों द्वारा भी भरोसा किया जाता है। Ripple विविध संस्थाओं द्वारा संचालित वैलिडेटरों से युक्त एक डिफ़ॉल्ट UNL प्रदान करता है, लेकिन नोड ऑपरेटर अपने स्वयं के विश्वास मूल्यांकन के आधार पर इस सूची को संशोधित करने के लिए स्वतंत्र हैं।
UNL तंत्र प्रगतिशील विकेंद्रीकरण की ओर एक स्वाभाविक मार्ग भी प्रदान करता है। नेटवर्क के प्रारंभिक चरणों में, स्थिरता और विश्वसनीयता सुनिश्चित करने के लिए वैलिडेटरों का एक अधिक केंद्रीकृत सेट उपयुक्त हो सकता है। जैसे-जैसे नेटवर्क परिपक्व होता है और अधिक विविध ऑपरेटर अपनी विश्वसनीयता प्रदर्शित करते हैं, UNL वैलिडेटरों के एक व्यापक सेट को शामिल करने के लिए विकसित हो सकते हैं, जिससे इसकी सुरक्षा गुणों से समझौता किए बिना नेटवर्क की लचीलापन और विकेंद्रीकरण बढ़ता है।
Simulation Code
เพื่อยืนยันการวิเคราะห์เชิงทฤษฎีของ RPCA และประเมินประสิทธิภาพภายใต้เงื่อนไขที่หลากหลาย ได้มีการจำลองอย่างครอบคลุมด้วยซอฟต์แวร์จำลองที่พัฒนาขึ้นเฉพาะทาง กรอบการจำลองจำลองเครือข่ายของโหนดซึ่งแต่ละโหนดดูแล UNL ของตนเองและเข้าร่วมในโปรโตคอลฉันทามติ โค้ดครอบคลุมการทำงาน RPCA แบบครบถ้วน ทั้งการเสนอธุรกรรม รอบโหวตที่เพิ่มเกณฑ์ตามลำดับ และการตรวจสอบ ledger
พารามิเตอร์สำคัญที่ถูกปรับในการจำลอง ได้แก่ ขนาดเครือข่าย (ตั้งแต่ 10 ถึง 1,000 โหนด), สัดส่วนโหนด Byzantine (0% ถึง 20%), ขนาด UNL (โดยทั่วไป 5 ถึง 50 โหนด), และการกำหนด topology ของเครือข่าย สำหรับแต่ละชุดพารามิเตอร์ มีการรันจำลองหลายครั้งด้วย random seed ที่ต่างกันเพื่อรับรองความน่าเชื่อถือเชิงสถิติของผลลัพธ์ การจำลองติดตามตัวชี้วัดสำคัญ เช่น ความหน่วงฉันทามติ ความน่าจะเป็นของการเกิด fork และ throughput ของธุรกรรม
ผลการจำลองยืนยันการคาดการณ์ทางทฤษฎีเกี่ยวกับการลู่เข้าและ safety ในทุกการกำหนดค่าที่เงื่อนไขการทับซ้อนของ UNL เป็นจริง และสัดส่วนโหนด Byzantine ต่ำกว่า 20% ของแต่ละ UNL เครือข่ายสามารถบรรลุฉันทามติได้โดยไม่เกิด fork ความหน่วงฉันทามติคงอยู่ในระดับต่ำอย่างสม่ำเสมอ (โดยทั่วไปเสร็จในเวลา 3-5 วินาทีจำลอง) ไม่ขึ้นกับขนาดเครือข่าย ซึ่งแสดงถึงความสามารถในการขยายตัวของอัลกอริทึม แม้มีโหนด Byzantine 15% พยายามรบกวนฉันทามติอย่างจริงจัง เครือข่ายก็ยังคง correctness ได้ ตราบใดที่เงื่อนไขการทับซ้อนของ UNL ยังถูกต้อง
การจำลองเพิ่มเติมยังครอบคลุมกรณีขอบและสถานการณ์ล้มเหลว เช่น การแบ่งพาร์ทิชันของเครือข่าย การเปลี่ยนองค์ประกอบ UNL อย่างฉับพลัน และการโจมตีแบบประสานงานโดยโหนด Byzantine ผลลัพธ์เหล่านี้ให้ข้อมูลเชิงลึกเกี่ยวกับความทนทานของโปรโตคอล และช่วยกำหนดแนวปฏิบัติที่แนะนำสำหรับการเลือก UNL และการปฏิบัติการเครือข่าย โค้ดจำลองทั้งหมดถูกเผยแพร่เพื่อรองรับการตรวจสอบอิสระและการวิจัยต่อยอด
Simulation Code
RPCA के सैद्धांतिक विश्लेषण को मान्य करने और विभिन्न स्थितियों में इसके प्रदर्शन का मूल्यांकन करने के लिए, कस्टम-निर्मित सिमुलेशन सॉफ्टवेयर का उपयोग करके व्यापक सिमुलेशन आयोजित किए गए। सिमुलेशन फ्रेमवर्क नोड्स के एक नेटवर्क का मॉडल बनाता है, जिनमें से प्रत्येक अपना स्वयं का UNL बनाए रखता है और सहमति प्रोटोकॉल में भाग लेता है। कोड पूर्ण RPCA एल्गोरिदम को लागू करता है, जिसमें लेनदेन प्रस्ताव, बढ़ते सीमा मानों के साथ मतदान दौर और लेजर सत्यापन शामिल हैं।
सिमुलेशन में विविध किए गए प्रमुख पैरामीटरों में नेटवर्क आकार (10 से 1,000 नोड्स तक), Byzantine नोड्स का प्रतिशत (0% से 20% तक), UNL आकार (आमतौर पर 5 से 50 नोड्स के बीच) और नेटवर्क टोपोलॉजी कॉन्फ़िगरेशन शामिल हैं। प्रत्येक पैरामीटर कॉन्फ़िगरेशन के लिए, परिणामों की सांख्यिकीय वैधता सुनिश्चित करने के लिए विभिन्न यादृच्छिक बीजों के साथ कई सिमुलेशन रन आयोजित किए गए। सिमुलेशन ने सहमति विलंबता, फोर्क संभावना और लेनदेन थ्रूपुट सहित मेट्रिक्स को ट्रैक किया।
सिमुलेशन परिणाम अभिसरण और सुरक्षा के संबंध में सैद्धांतिक भविष्यवाणियों की पुष्टि करते हैं। सभी कॉन्फ़िगरेशन जहां UNL ओवरलैप शर्त संतुष्ट थी और Byzantine नोड्स प्रत्येक UNL के 20% से कम थे, नेटवर्क ने बिना फोर्क के सफलतापूर्वक सहमति प्राप्त की। सहमति विलंबता नेटवर्क आकार की परवाह किए बिना लगातार कम रही (आमतौर पर 3-5 सिमुलेटेड सेकंड में पूरी), जो एल्गोरिदम की स्केलेबिलिटी प्रदर्शित करती है। 15% Byzantine नोड्स सक्रिय रूप से सहमति को बाधित करने का प्रयास करने पर भी, जब तक UNL ओवरलैप आवश्यकता पूरी होती रही, नेटवर्क ने शुद्धता बनाए रखी।
अतिरिक्त सिमुलेशन ने एज केस और विफलता परिदृश्यों का पता लगाया, जिनमें नेटवर्क विभाजन, UNL संरचना में अचानक परिवर्तन और Byzantine नोड्स द्वारा समन्वित हमले शामिल हैं। इन सिमुलेशन ने प्रोटोकॉल की मजबूती के बारे में अंतर्दृष्टि प्रदान की और UNL चयन और नेटवर्क संचालन के लिए अनुशंसित सर्वोत्तम प्रथाओं की जानकारी दी। स्वतंत्र सत्यापन और आगे के अनुसंधान की अनुमति देने के लिए पूर्ण सिमुलेशन कोड उपलब्ध कराया गया है।
Discussion
เมื่อเทียบกับฉันทามติแบบ proof-of-work ของ Bitcoin แล้ว RPCA มีข้อได้เปรียบสำคัญหลายประการสำหรับงานระบบการชำระเงิน จุดเด่นที่สุดคือความหน่วงฉันทามติลดลงจาก 40-60 นาที (เวลาที่มักแนะนำสำหรับธุรกรรม Bitcoin มูลค่าสูง) เหลือประมาณ 5 วินาที การปรับปรุงนี้ทำให้ RPCA เหมาะกับงาน point-of-sale และกรณีใช้งานอื่นที่ต้องการการชำระบัญชีเกือบทันที นอกจากนี้ RPCA ใช้ทรัพยากรคำนวณต่ำมากเมื่อเทียบกับ proof-of-work จึงลดปัญหาการใช้พลังงานมหาศาลที่สัมพันธ์กับการขุด Bitcoin
อย่างไรก็ตาม ข้อได้เปรียบดังกล่าวมาพร้อมสมมติฐานความไว้วางใจที่ต่างออกไป ความปลอดภัยของ Bitcoin อาศัยเพียงสมมติฐานว่าไม่มีผู้โจมตีรายใดควบคุมกำลังคำนวณเกิน 50% ของเครือข่าย ขณะที่ RPCA ต้องการให้โหนดเลือก UNL ที่มีการทับซ้อนเพียงพอ และจำนวนโหนด Byzantine ไม่เกินเกณฑ์ภายใน UNL เหล่านั้น สิ่งนี้ย้ายความรับผิดชอบบางส่วนไปยังผู้ดำเนินการโหนดให้ตัดสินใจด้านความไว้วางใจอย่างรอบคอบ ในทางปฏิบัติ trade-off นี้ยอมรับได้สำหรับหลายกรณีใช้งานด้านการชำระเงินที่องค์กรผู้เข้าร่วมมีความสัมพันธ์ความไว้วางใจกันอยู่แล้ว
topology ของเครือข่ายและกลยุทธ์การเลือก UNL ส่งผลอย่างมีนัยสำคัญต่อคุณสมบัติของระบบฉันทามติ topology ที่รวมศูนย์สูง ซึ่งทุกโหนดใช้ validator ชุดเดียวกันใน UNL จะเพิ่ม safety ได้สูงสุด แต่สามารถลด liveness ได้หาก validator ชุดนั้นไม่พร้อมใช้งาน ในทางกลับกัน topology ที่กระจายอำนาจสูงและมีการทับซ้อน UNL ต่ำ อาจช่วย liveness แต่เสี่ยงต่อความล้มเหลวของฉันทามติหากการทับซ้อนเบาบางเกินไป การหาจุดสมดุลที่เหมาะสมจึงต้องพิจารณาร่วมกันทั้งบริบทการใช้งานจริงและระดับความเสี่ยงที่ยอมรับได้
งานในอนาคตอาจสำรวจอัลกอริทึมเลือก UNL แบบปรับตัวที่รักษาเงื่อนไขการทับซ้อนโดยอัตโนมัติพร้อมเพิ่มความเป็นกระจายอำนาจให้มากที่สุด กลไกที่ให้โหนดปรับ UNL แบบไดนามิกจากพฤติกรรม validator ที่สังเกตได้ และส่วนขยายของอัลกอริทึมฉันทามติที่ทนต่อสัดส่วนโหนด Byzantine ที่สูงขึ้นได้อีก การพัฒนาเหล่านี้จะช่วยเพิ่มทั้งความแข็งแรงและความสามารถในการประยุกต์ใช้ RPCA ในระบบการชำระเงินแบบกระจายขนาดใหญ่
Discussion
Bitcoin के proof-of-work सहमति की तुलना में, RPCA भुगतान प्रणाली अनुप्रयोगों के लिए कई महत्वपूर्ण फायदे प्रदान करता है। सबसे उल्लेखनीय रूप से, सहमति विलंबता 40-60 मिनट (उच्च-मूल्य Bitcoin लेनदेन के लिए आमतौर पर अनुशंसित समय) से घटाकर लगभग 5 सेकंड कर दी गई है। यह सुधार RPCA को पॉइंट-ऑफ-सेल और अन्य अनुप्रयोगों के लिए उपयुक्त बनाता है जहां लगभग तत्काल निपटान की आवश्यकता होती है। इसके अतिरिक्त, RPCA को proof-of-work की तुलना में न्यूनतम कम्प्यूटेशनल संसाधनों की आवश्यकता होती है, जो Bitcoin माइनिंग से जुड़ी भारी ऊर्जा खपत को समाप्त करता है।
हालांकि, ये फायदे विभिन्न विश्वास धारणाओं के साथ आते हैं। जबकि Bitcoin की सुरक्षा केवल इस धारणा पर निर्भर करती है कि कोई भी हमलावर नेटवर्क की 50% से अधिक कम्प्यूटेशनल शक्ति को नियंत्रित नहीं करता, RPCA के लिए आवश्यक है कि नोड्स पर्याप्त ओवरलैप वाली UNL चुनें और Byzantine नोड्स इन UNL के भीतर सीमा से अधिक न हों। यह कुछ जिम्मेदारी नोड ऑपरेटरों पर स्थानांतरित करता है कि वे विवेकपूर्ण विश्वास निर्णय लें। व्यवहार में, यह समझौता कई भुगतान प्रणाली उपयोग मामलों के लिए स्वीकार्य है जहां भाग लेने वाली संस्थाओं के मौजूदा विश्वास संबंध हैं।
नेटवर्क टोपोलॉजी और UNL चयन रणनीति सहमति प्रणाली के गुणों को महत्वपूर्ण रूप से प्रभावित करती है। एक अत्यधिक केंद्रीकृत टोपोलॉजी जहां सभी नोड्स अपनी UNL में समान वैलिडेटर शामिल करते हैं, सुरक्षा को अधिकतम करती है लेकिन उन वैलिडेटरों के अनुपलब्ध होने पर जीवंतता कम कर सकती है। इसके विपरीत, न्यूनतम UNL ओवरलैप वाली अत्यधिक विकेंद्रीकृत टोपोलॉजी जीवंतता में सुधार कर सकती है लेकिन ओवरलैप बहुत कम होने पर सहमति विफलताओं का जोखिम उठा सकती है। इष्टतम संतुलन खोजने के लिए विशिष्ट तैनाती परिदृश्य और जोखिम सहनशीलता पर सावधानीपूर्वक विचार की आवश्यकता होती है।
भविष्य का कार्य अनुकूली UNL चयन एल्गोरिदम का पता लगा सकता है जो विकेंद्रीकरण को अधिकतम करते हुए स्वचालित रूप से ओवरलैप आवश्यकताओं को बनाए रखते हैं, नोड्स के लिए देखे गए वैलिडेटर व्यवहार के आधार पर अपनी UNL को गतिशील रूप से समायोजित करने के तंत्र, और सहमति एल्गोरिदम के विस्तार जो Byzantine नोड्स के और भी अधिक प्रतिशत को सहन कर सकते हैं। ये सुधार बड़े पैमाने पर वितरित भुगतान प्रणालियों के लिए RPCA की मजबूती और प्रयोज्यता को और बढ़ा सकते हैं।
Conclusion
Ripple Protocol Consensus Algorithm เป็นความก้าวหน้าสำคัญของฉันทามติแบบกระจายสำหรับระบบการชำระเงิน ด้วยการใช้เครือข่ายย่อยที่ได้รับความไว้วางใจร่วมกัน แทนการบังคับให้ทุกโหนดต้องตกลงกันแบบทั่วทั้งเครือข่าย RPCA จึงบรรลุฉันทามติได้ภายในไม่กี่วินาที พร้อมคงการรับประกันที่แข็งแรงต่อความล้มเหลวแบบ Byzantine การวิเคราะห์เชิงรูปแบบยืนยันว่า หาก UNL ถูกเลือกให้มีการทับซ้อนเพียงพอ และจำนวนโหนด Byzantine อยู่ต่ำกว่าเกณฑ์ เครือข่ายจะบรรลุฉันทามติที่ถูกต้องโดยไม่เกิด fork
นัยเชิงปฏิบัติของงานนี้ไม่ได้จำกัดอยู่แค่เครือข่ายการชำระเงินของ Ripple เท่านั้น RPCA แสดงให้เห็นว่าการแลกเปลี่ยนแบบดั้งเดิมระหว่างความหน่วงฉันทามติกับการรับประกันความปลอดภัย สามารถก้าวข้ามได้ด้วยการออกแบบโปรโตคอลอย่างรอบคอบและการใช้ความสัมพันธ์ความไว้วางใจแบบเฉพาะที่ แนวทางนี้มีศักยภาพสำหรับระบบแบบกระจายอื่นที่ต้องการความหน่วงต่ำและมีผู้เข้าร่วมที่มีความไว้วางใจต่อกันอยู่แล้ว เช่น ระบบชำระบัญชีระหว่างธนาคาร การติดตามห่วงโซ่อุปทาน และงานโครงสร้างพื้นฐานทางการเงินอื่น ๆ
การนำ RPCA ไปใช้งานจริงในระบบ production ได้ยืนยันทั้งสมรรถนะและความทนทานของอัลกอริทึม เครือข่าย Ripple ประมวลผลธุรกรรมได้หลายพันรายการต่อวินาที พร้อมความหน่วงฉันทามติที่สม่ำเสมอที่ 3-5 วินาที แสดงให้เห็นว่าคุณสมบัติเชิงทฤษฎีสามารถแปลงเป็นผลลัพธ์จริงได้อย่างมีประสิทธิภาพ เมื่อเครือข่ายพัฒนาอย่างต่อเนื่องและเพิ่ม validator จากผู้ดำเนินการที่หลากหลายมากขึ้น RPCA จึงเป็นตัวอย่างเชิงปฏิบัติของระบบฉันทามติแบบกระจายอำนาจที่รักษาได้ทั้งความปลอดภัยและประสิทธิภาพในระดับสเกลใหญ่
Conclusion
Ripple प्रोटोकॉल सहमति एल्गोरिदम भुगतान प्रणालियों के लिए वितरित सहमति में एक महत्वपूर्ण प्रगति का प्रतिनिधित्व करता है। सभी नोड्स के बीच वैश्विक सहमति की आवश्यकता के बजाय सामूहिक रूप से विश्वसनीय उप-नेटवर्क का उपयोग करके, RPCA Byzantine विफलताओं के खिलाफ मजबूत गारंटी बनाए रखते हुए सेकंडों में सहमति प्राप्त करता है। औपचारिक विश्लेषण प्रदर्शित करता है कि जब तक UNL पर्याप्त ओवरलैप के साथ चुनी जाती हैं और Byzantine नोड्स सीमा से नीचे रहते हैं, नेटवर्क बिना फोर्क के सही सहमति प्राप्त करेगा।
इस कार्य के व्यावहारिक निहितार्थ Ripple भुगतान नेटवर्क से परे फैलते हैं। RPCA प्रदर्शित करता है कि सहमति विलंबता और सुरक्षा गारंटी के बीच पारंपरिक समझौते को सावधानीपूर्वक प्रोटोकॉल डिज़ाइन और स्थानीय विश्वास संबंधों के उपयोग के माध्यम से दूर किया जा सकता है। यह दृष्टिकोण अन्य वितरित प्रणालियों पर लागू हो सकता है जहां कम विलंबता महत्वपूर्ण है और प्रतिभागियों के मौजूदा विश्वास संबंध हैं, जैसे अंतर-बैंक निपटान प्रणालियां, आपूर्ति श्रृंखला ट्रैकिंग और अन्य वित्तीय अवसंरचना अनुप्रयोग।
उत्पादन प्रणालियों में RPCA की तैनाती ने एल्गोरिदम की प्रदर्शन विशेषताओं और मजबूती को मान्य किया है। Ripple नेटवर्क 3-5 सेकंड की लगातार सहमति विलंबता के साथ प्रति सेकंड हजारों लेनदेन संसाधित करता है, जो प्रदर्शित करता है कि सैद्धांतिक गुण वास्तविक-विश्व संचालन में प्रभावी रूप से अनुवादित होते हैं। जैसे-जैसे नेटवर्क विकसित होना और विविध ऑपरेटरों से अतिरिक्त वैलिडेटर शामिल करना जारी रखता है, यह एक व्यावहारिक उदाहरण प्रदान करता है कि कैसे एक विकेंद्रीकृत सहमति प्रणाली बड़े पैमाने पर सुरक्षा और प्रदर्शन दोनों बनाए रख सकती है।
References
Lamport, L., Shostak, R., และ Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. งานคลาสสิกนี้ได้ทำให้ปัญหาการบรรลุฉันทามติในระบบกระจายที่มีองค์ประกอบผิดพลาดเป็นรูปแบบทางการ และวางรากฐานเชิงทฤษฎีให้กับระบบที่ทนต่อความผิดพลาดแบบ Byzantine
Castro, M., และ Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). งานนี้แนะนำ PBFT และแสดงให้เห็นว่าความทนทานต่อ Byzantine fault สามารถทำได้จริงในทางปฏิบัติ แม้จะมีความซับซ้อนด้านการสื่อสาร O(n^2) ที่จำกัดการขยายตัว
Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." เอกสาร whitepaper นี้เสนอฉันทามติแบบ proof-of-work เพื่อแก้ปัญหา double-spending ในสกุลเงินดิจิทัล ทำให้เกิดฉันทามติแบบกระจายศูนย์โดยไม่ต้องพึ่งผู้มีอำนาจที่เชื่อถือได้ แต่แลกมาด้วยความหน่วงสูงและการใช้พลังงานมาก
Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. บทความนี้นำเสนออัลกอริทึม Paxos ซึ่งบรรลุฉันทามติในระบบอะซิงโครนัสภายใต้ความล้มเหลวแบบ crash และมีอิทธิพลต่อการออกแบบโปรโตคอลฉันทามติในเวลาต่อมา
Fischer, M. J., Lynch, N. A., และ Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. ผลลัพธ์ความเป็นไปไม่ได้ของ FLP ได้กำหนดขอบเขตพื้นฐานของสิ่งที่อัลกอริทึมฉันทามติทำได้ในระบบอะซิงโครนัส และกำหนดทิศทางพื้นที่ออกแบบของโปรโตคอลฉันทามติเชิงปฏิบัติ
References
Lamport, L., Shostak, R., and Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. इस मौलिक पत्र ने दोषपूर्ण घटकों वाली वितरित प्रणालियों में सहमति प्राप्त करने की समस्या को औपचारिक रूप दिया और Byzantine दोष-सहिष्णु प्रणालियों के लिए सैद्धांतिक आधार स्थापित किया।
Castro, M., and Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). इस कार्य ने PBFT पेश किया, यह प्रदर्शित करते हुए कि Byzantine दोष सहिष्णुता व्यावहारिक प्रदर्शन के साथ प्राप्त की जा सकती है, हालांकि O(n^2) संचार जटिलता स्केलेबिलिटी को सीमित करती है।
Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." इस श्वेतपत्र ने डिजिटल मुद्रा में दोहरे खर्च की समस्या के समाधान के रूप में proof-of-work सहमति पेश की, जो उच्च विलंबता और ऊर्जा खपत की कीमत पर विश्वसनीय पक्षों के बिना विकेंद्रीकृत सहमति को सक्षम बनाती है।
Lamport, L. (1998). "The Part-Time Parliament." ACM Transactions on Computer Systems, 16(2):133-169. इस पत्र ने Paxos एल्गोरिदम प्रस्तुत किया, जो क्रैश विफलताओं के तहत असमकालिक प्रणालियों में सहमति प्राप्त करता है, जिसने बाद के सहमति प्रोटोकॉल डिज़ाइनों को प्रभावित किया।
Fischer, M. J., Lynch, N. A., and Paterson, M. S. (1985). "Impossibility of Distributed Consensus with One Faulty Process." Journal of the ACM, 32(2):374-382. FLP असंभवता परिणाम ने असमकालिक प्रणालियों में सहमति एल्गोरिदम क्या प्राप्त कर सकते हैं इसकी मूलभूत सीमाएं स्थापित कीं, जिसने व्यावहारिक सहमति प्रोटोकॉल के लिए डिज़ाइन स्थान को आकार दिया।
