خوارزمية إجماع بروتوكول ريبل

Abstract

على الرغم من وجود عدة خوارزميات إجماع لمسألة الجنرالات البيزنطيين (Byzantine Generals Problem)، وتحديداً فيما يتعلق بأنظمة الدفع الموزعة، فإن العديد منها يعاني من زمن استجابة مرتفع ناتج عن متطلب تواصل جميع العقد داخل الشبكة بشكل متزامن. في هذا العمل، نقدم خوارزمية إجماع جديدة تتجاوز هذا المتطلب من خلال استخدام شبكات فرعية موثوقة جماعياً ضمن الشبكة الأكبر. نوضح أن "الثقة" المطلوبة لمنع هجمات Sybil ليست في الواقع عالمية، بل محلية لكل عقدة في الشبكة.

يتم تطبيق خوارزمية إجماع بروتوكول Ripple (RPCA) كل بضع ثوانٍ بواسطة جميع العقد، من أجل الحفاظ على صحة الشبكة واتفاقها. بمجرد الوصول إلى الإجماع، يُعتبر السجل الحالي "مغلقاً" ويصبح آخر سجل مغلق. هذه الخوارزمية فريدة من نوعها حيث تحقق الإجماع بزمن استجابة منخفض مع الحفاظ على ضمانات قوية ضد الإخفاقات البيزنطية، مما يجعلها مناسبة لأنظمة التسوية المالية في الوقت الفعلي.

Introduction

يجب أن ينفذ نظام الدفع الموزع خوارزمية إجماع لمعالجة المدفوعات بشكل صحيح وفي الوقت المناسب حتى في وجود جهات فاعلة معيبة أو خبيثة. يحقق Bitcoin الإجماع باستخدام إثبات العمل (proof-of-work)، الذي يتطلب من جميع العقد إنفاق موارد حسابية لحل الألغاز التشفيرية. في حين أن هذا النهج يوفر ضمانات أمنية قوية، إلا أنه يعاني من عيوب كبيرة تشمل استهلاك الطاقة العالي، وانخفاض إنتاجية المعاملات، وأوقات تأكيد طويلة يمكن أن تمتد إلى ساعة أو أكثر للمعاملات عالية القيمة.

توفر خوارزمية إجماع بروتوكول Ripple نهجاً جديداً للإجماع الموزع لا يتطلب إثبات العمل. بدلاً من ذلك، تتفق العقد في الشبكة بشكل جماعي على مجموعات المعاملات من خلال عملية تصويت تحقق الإجماع في غضون ثوانٍ. تم تصميم آلية الإجماع هذه خصيصاً لمتطلبات شبكة مدفوعات عالمية، حيث يكون زمن الاستجابة المنخفض والإنتاجية العالية ضروريين للنشر العملي.

الابتكار الرئيسي في RPCA هو أنه لا يتطلب موافقة جميع العقد في الشبكة مع بعضها البعض. بدلاً من ذلك، تحتفظ كل عقدة بقائمة عقد فريدة (Unique Node List أو UNL) من العقد الأخرى التي تثق بها في عدم التواطؤ. طالما أن قوائم UNL المختارة من قبل العقد لديها تداخل كافٍ، وأن أقل من نسبة حد معينة من العقد معيبة، فإن الشبكة ستصل إلى الإجماع. يوفر هذا النهج ضمانات الأمان اللازمة لنظام الدفع مع تحقيق زمن إجماع يُقاس بالثواني بدلاً من الدقائق أو الساعات.

Definition of Consensus

في الأنظمة الموزعة، يشير الإجماع إلى العملية التي تتوصل من خلالها شبكة من العقد إلى اتفاق حول حالة مشتركة، على الرغم من وجود مشاركين معيبين أو خبيثين. يجب أن تستوفي خوارزمية الإجماع ثلاث خصائص أساسية: الصحة (لا تتخذ عقدتان صحيحتان قرارات مختلفة)، والاتفاق (تصل جميع العقد الصحيحة إلى نفس القرار)، والإنهاء (تتخذ جميع العقد الصحيحة قراراً في نهاية المطاف). تضمن هذه الخصائص أن النظام الموزع يتصرف كما لو كان عقدة واحدة موثوقة.

ينشأ التحدي في تحقيق الإجماع من عدم الموثوقية المتأصلة في الأنظمة الموزعة. قد تتعطل العقد، وقد تتأخر الرسائل أو تُفقد، وقد تتصرف العقد البيزنطية بشكل تعسفي أو خبيث. مسألة الجنرالات البيزنطيين (Byzantine Generals Problem)، التي صاغها Lamport وShostak وPease، تلتقط هذا التحدي: كيف يمكن لمجموعة من العمليات التوصل إلى اتفاق عندما قد يكون بعضها معيباً وعندما يكون الاتصال غير موثوق؟

تحدد النتائج الكلاسيكية في الحوسبة الموزعة حدوداً أساسية لما يمكن أن تحققه خوارزميات الإجماع. تُظهر نتيجة استحالة FLP أنه لا يمكن لأي خوارزمية حتمية ضمان الإجماع في نظام غير متزامن إذا كان حتى عقدة واحدة يمكن أن تفشل. لذلك يجب على خوارزميات الإجماع العملية إجراء مقايضات بين السلامة (عدم الوصول أبداً إلى إجماع خاطئ) والحيوية (تحقيق التقدم دائماً). يعطي إثبات العمل في Bitcoin الأولوية للسلامة على الحيوية، بينما يحقق RPCA توازناً أكثر ملاءمة لأنظمة الدفع من خلال إكمال جولات الإجماع في وقت محدد مع الحفاظ على ضمانات سلامة قوية في ظل افتراضات أعطال واقعية.

Existing Consensus Algorithms

تم اقتراح عدة خوارزميات إجماع لحل مسألة الجنرالات البيزنطيين في الأنظمة الموزعة. يمكن لخوارزمية Practical Byzantine Fault Tolerance (PBFT)، التي قدمها Castro وLiskov، تحمل ما يصل إلى f عطل بيزنطي في نظام مكون من 3f+1 عقدة. يحقق PBFT الإجماع من خلال جولات متعددة من تبادل الرسائل بين جميع العقد، بتعقيد اتصال قدره O(n^2)، حيث n هو عدد العقد. في حين يوفر PBFT ضمانات سلامة قوية وزمن استجابة منخفض نسبياً للشبكات الصغيرة، إلا أنه لا يتوسع بشكل جيد للشبكات الكبيرة بسبب عبء الاتصال التربيعي.

يوفر Paxos ومتغيراته، التي طورها Lamport، إجماعاً في الأنظمة غير المتزامنة ولكنه يفترض أعطال التعطل بدلاً من الأعطال البيزنطية. يحقق Paxos الإجماع من خلال سلسلة من الجولات يقترح فيها المقترحون قيماً ويصوت عليها القابلون. في حين يمكن لـ Paxos تحمل تأخيرات الرسائل التعسفية وتعطل العمليات، فإنه يتطلب هندسة دقيقة للتعامل مع الأعطال البيزنطية ويمكن أن يعاني من القفل الحي (livelock) في سيناريوهات معينة.

تتخذ خوارزمية إجماع proof-of-work في Bitcoin نهجاً مختلفاً جذرياً من خلال جعل الهجمات البيزنطية غير مجدية اقتصادياً. تتنافس العقد لحل الألغاز التشفيرية، حيث يقترح الفائز الكتلة التالية من المعاملات. في حين أن هذا النهج يتوسع إلى أحجام شبكات تعسفية ويتعامل مع الأعطال البيزنطية، فإن له عيوباً خطيرة: استهلاك هائل للطاقة (يُقدر بأكثر من 150 مليون دولار سنوياً لشبكة Bitcoin)، وأوقات تأكيد طويلة (غالباً 40-60 دقيقة للمعاملات عالية القيمة)، وإنتاجية محدودة (حوالي 7 معاملات في الثانية). تجعل هذه القيود proof-of-work غير مناسب للعديد من تطبيقات أنظمة الدفع التي تتطلب تسوية سريعة وأحجام معاملات عالية.

Ripple Protocol Consensus Algorithm

تبدأ خوارزمية إجماع بروتوكول Ripple (RPCA) بأخذ كل خادم لجميع المعاملات الصالحة التي رآها والتي لم يتم تطبيقها بعد كمعاملات مرشحة. ثم تتبع الخوادم بروتوكولاً متعدد الجولات حيث تعمل بشكل تكراري نحو الاتفاق على مجموعة من المعاملات لتطبيقها على السجل الحالي. في كل جولة، تقدم الخوادم مقترحات تتكون من المعاملات التي تعتقد أنها يجب أن تُدرج في السجل التالي.

خلال كل جولة إجماع، تنقل الخوادم مقترحاتها إلى الخوادم الأخرى في قائمة العقد الفريدة (Unique Node List أو UNL) الخاصة بها. ثم تحسب الخوادم المعاملات التي تظهر في نسبة حد معينة من المقترحات. في البداية، يتم تعيين هذا الحد عند 50%، مما يعني أن المعاملة يجب أن تظهر في مقترحات نصف UNL الخادم على الأقل لتُعتبر للجولة التالية. مع تقدم الإجماع عبر الجولات المتتالية، يزداد هذا الحد تدريجياً (عادةً إلى 60%، 70%، وأخيراً 80%).

عندما تحقق معاملة حد الأغلبية العظمى البالغ 80% من الدعم في UNL الخادم، يتم تضمينها في مقترح ذلك الخادم لجولة الإجماع النهائية. يتم تطبيق جميع المعاملات التي تصل إلى هذا الحد عبر الشبكة على السجل، الذي يتم بعد ذلك تجزئته تشفيرياً وتوقيعه. يصبح هذا السجل المصادق عليه حديثاً آخر سجل مغلق، وتبدأ العملية مرة أخرى مع المجموعة التالية من المعاملات المرشحة.

تكتمل عملية الإجماع عادةً في 5 ثوانٍ أو أقل، حيث تتطلب معظم المعاملات جولة إجماع واحدة فقط لتحقيق حد الأغلبية العظمى. تبقى المعاملات التي لا تحقق الإجماع في جولة واحدة مرشحة للجولات اللاحقة. يضمن هذا التصميم أن الشبكة تحقق تقدماً مستمراً مع الحفاظ على ضمانات سلامة قوية، حيث لا يمكن تطبيق أي معاملة على السجل دون دعم الأغلبية العظمى من المصادقين الموثوقين.

Formal Analysis of Convergence

تعتمد صحة RPCA بشكل حاسم على التداخل بين قوائم UNL المختارة من قبل العقد المختلفة في الشبكة. ليكن UNL_i قائمة العقد الفريدة للعقدة i، وليكن UNL_i ∩ UNL_j مجموعة العقد التي تظهر في كل من UNL_i وUNL_j. للحفاظ على إجماع الشبكة، نشترط أنه لأي عقدتين i وj، يجب أن يكون تقاطع قوائم UNL الخاصة بهما كبيراً بما فيه الكفاية مقارنة بالحجم الأقصى لأي من القائمتين.

على وجه التحديد، يضمن البروتوكول السلامة عندما |UNL_i ∩ UNL_j| / max(|UNL_i|, |UNL_j|) 1/5 لجميع أزواج العقد i وj. يضمن هذا الشرط أنه حتى لو حاولت العقد البيزنطية التسبب في وصول أجزاء مختلفة من الشبكة إلى قرارات إجماع مختلفة، فإن التداخل في العقد الموثوقة يمنع الانقسام (fork). إذا تحقق هذا الشرط وكانت أقل من 1/5 من العقد في أي UNL بيزنطية، فإن جميع العقد الصحيحة ستصل إلى نفس قرار الإجماع.

يتقدم البرهان الرسمي بإظهار أنه إذا تمكنت عقدتان من الوصول إلى قرارات إجماع مختلفة، فيجب أن توجد معاملة T تظهر في السجل النهائي لعقدة واحدة ولكن ليس في الأخرى. لحدوث ذلك، يجب أن تكون T قد حققت 80% من الدعم في UNL العقدة الأولى ولكن أقل من 80% من الدعم في UNL العقدة الثانية. ومع ذلك، بالنظر إلى متطلب التداخل والقيد على العقد البيزنطية، يمكن إثبات أن هذا السيناريو مستحيل: إذا حققت T دعم 80% في UNL_i، فيجب أن تحقق دعم 60% على الأقل في أي UNL_j تستوفي شرط التداخل، ومع جولات كافية من الإجماع، سيتقارب هذا إلى 80% أو سيتم رفضه من قبل كلتا العقدتين.

خاصية الحيوية -- أن الإجماع سيتم الوصول إليه في نهاية المطاف -- تنبع من ملاحظة أن حد الإدراج يزداد بشكل حتمي عبر جولات الإجماع. حتى في وجود عقد بيزنطية وتأخيرات في الشبكة، يضمن البروتوكول أن المعاملات المدعومة من الأغلبية العظمى للعقد الصادقة ستُدرج في النهاية، بينما ستُستبعد المعاملات التي تفتقر إلى هذا الدعم. يوفر الوقت المحدد للإجماع (عادةً 5 ثوانٍ) ضمانات حيوية عملية مناسبة لتطبيقات أنظمة الدفع.

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 الكاملة، بما في ذلك اقتراح المعاملات، وجولات التصويت ذات الحدود المتزايدة، والتحقق من صحة السجل.

تشمل المعلمات الرئيسية المتغيرة في المحاكاة حجم الشبكة (من 10 إلى 1,000 عقدة)، ونسبة العقد البيزنطية (من 0% إلى 20%)، وحجم UNL (عادةً بين 5 و50 عقدة)، وتكوينات طوبولوجيا الشبكة. لكل تكوين معلمات، أُجريت عمليات محاكاة متعددة ببذور عشوائية مختلفة لضمان الصلاحية الإحصائية للنتائج. تتبعت المحاكاة مقاييس تشمل زمن استجابة الإجماع، واحتمال الانقسام (fork)، وإنتاجية المعاملات.

تؤكد نتائج المحاكاة التنبؤات النظرية المتعلقة بالتقارب والسلامة. في جميع التكوينات التي استُوفي فيها شرط تداخل UNL وشكلت العقد البيزنطية أقل من 20% من كل UNL، وصلت الشبكة بنجاح إلى الإجماع دون انقسامات. ظل زمن استجابة الإجماع منخفضاً باستمرار (يكتمل عادةً في 3-5 ثوانٍ محاكاة) بغض النظر عن حجم الشبكة، مما يوضح قابلية الخوارزمية للتوسع. حتى مع وجود 15% من العقد البيزنطية تحاول بنشاط تعطيل الإجماع، حافظت الشبكة على الصحة طالما تم استيفاء متطلب تداخل UNL.

استكشفت محاكاة إضافية الحالات الحدية وسيناريوهات الفشل، بما في ذلك تقسيم الشبكة، والتغييرات المفاجئة في تكوين UNL، والهجمات المنسقة من قبل العقد البيزنطية. قدمت هذه المحاكاة رؤى حول متانة البروتوكول وأفادت في تحديد أفضل الممارسات الموصى بها لاختيار UNL وتشغيل الشبكة. تم توفير كود المحاكاة الكامل للسماح بالتحقق المستقل والبحث الإضافي.

Discussion

مقارنةً بإجماع proof-of-work في Bitcoin، يقدم RPCA عدة مزايا مهمة لتطبيقات أنظمة الدفع. والأبرز من ذلك، يتم تقليل زمن الإجماع من 40-60 دقيقة (الوقت الموصى به عادةً لمعاملات Bitcoin عالية القيمة) إلى حوالي 5 ثوانٍ. يجعل هذا التحسين RPCA مناسباً لنقاط البيع والتطبيقات الأخرى التي تتطلب تسوية شبه فورية. بالإضافة إلى ذلك، يتطلب RPCA موارد حسابية ضئيلة مقارنة بـ proof-of-work، مما يلغي الاستهلاك الهائل للطاقة المرتبط بتعدين Bitcoin.

ومع ذلك، تأتي هذه المزايا مع افتراضات ثقة مختلفة. بينما يعتمد أمان Bitcoin فقط على افتراض أن لا مهاجم يتحكم في أكثر من 50% من القوة الحسابية للشبكة، يتطلب RPCA أن تختار العقد قوائم UNL ذات تداخل كافٍ وأن لا تتجاوز العقد البيزنطية الحد الأقصى ضمن هذه القوائم. ينقل هذا بعض المسؤولية إلى مشغلي العقد لاتخاذ قرارات ثقة حكيمة. عملياً، هذه المقايضة مقبولة للعديد من حالات استخدام أنظمة الدفع حيث تكون للمؤسسات المشاركة علاقات ثقة قائمة.

تؤثر طوبولوجيا الشبكة واستراتيجية اختيار UNL بشكل كبير على خصائص نظام الإجماع. تعمل الطوبولوجيا المركزية للغاية حيث تتضمن جميع العقد نفس المصادقين في قوائم UNL الخاصة بها على تعظيم السلامة ولكنها قد تقلل من الحيوية إذا أصبح هؤلاء المصادقون غير متاحين. على العكس، قد تحسن الطوبولوجيا اللامركزية للغاية ذات التداخل الأدنى في UNL من الحيوية ولكنها قد تخاطر بفشل الإجماع إذا أصبح التداخل ضئيلاً جداً. يتطلب إيجاد التوازن الأمثل دراسة متأنية لسيناريو النشر المحدد وتحمل المخاطر.

يمكن أن تستكشف الأعمال المستقبلية خوارزميات اختيار UNL التكيفية التي تحافظ تلقائياً على متطلبات التداخل مع تعظيم اللامركزية، وآليات للعقد لتعديل قوائم UNL الخاصة بها ديناميكياً بناءً على سلوك المصادقين الملاحظ، وتوسعات لخوارزمية الإجماع يمكنها تحمل نسب أعلى من العقد البيزنطية. يمكن أن تعزز هذه التحسينات متانة وقابلية تطبيق RPCA لأنظمة الدفع الموزعة واسعة النطاق.

Conclusion

تمثل خوارزمية إجماع بروتوكول Ripple تقدماً كبيراً في الإجماع الموزع لأنظمة الدفع. من خلال استخدام شبكات فرعية موثوقة جماعياً بدلاً من طلب اتفاق عالمي بين جميع العقد، يحقق RPCA الإجماع في غضون ثوانٍ مع الحفاظ على ضمانات قوية ضد الإخفاقات البيزنطية. يوضح التحليل الرسمي أنه طالما يتم اختيار قوائم UNL بتداخل كافٍ وتبقى العقد البيزنطية دون الحد الأقصى، فإن الشبكة ستصل إلى إجماع صحيح دون انقسامات.

تمتد الآثار العملية لهذا العمل إلى ما هو أبعد من شبكة مدفوعات Ripple. يوضح RPCA أن المقايضة التقليدية بين زمن الإجماع وضمانات الأمان يمكن التغلب عليها من خلال تصميم بروتوكول دقيق واستخدام علاقات الثقة المحلية. قد يثبت هذا النهج قابليته للتطبيق على أنظمة موزعة أخرى حيث يكون زمن الاستجابة المنخفض حاسماً ولدى المشاركين علاقات ثقة قائمة، مثل أنظمة التسوية بين البنوك، وتتبع سلسلة التوريد، وتطبيقات البنية التحتية المالية الأخرى.

أثبت نشر RPCA في أنظمة الإنتاج خصائص أداء الخوارزمية ومتانتها. تعالج شبكة Ripple آلاف المعاملات في الثانية بزمن إجماع ثابت يتراوح بين 3-5 ثوانٍ، مما يوضح أن الخصائص النظرية تترجم بفعالية إلى التشغيل في العالم الحقيقي. مع استمرار الشبكة في التطور ودمج مصادقين إضافيين من مشغلين متنوعين، فإنها توفر مثالاً عملياً على كيف يمكن لنظام إجماع لامركزي الحفاظ على الأمان والأداء معاً على نطاق واسع.

References

Lamport, L., Shostak, R., and Pease, M. (1982). "The Byzantine Generals Problem." ACM Transactions on Programming Languages and Systems, 4(3):382-401. صاغت هذه الورقة الرائدة مشكلة الوصول إلى الإجماع في الأنظمة الموزعة ذات المكونات المعيبة وأسست الأساس النظري للأنظمة المتسامحة مع الأعطال البيزنطية.

Castro, M., and Liskov, B. (1999). "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI). قدم هذا العمل PBFT، موضحاً أن التسامح مع الأعطال البيزنطية يمكن تحقيقه بأداء عملي، وإن كان بتعقيد اتصال O(n^2) يحد من قابلية التوسع.

Nakamoto, S. (2008). "Bitcoin: A Peer-to-Peer Electronic Cash System." قدمت هذه الورقة البيضاء إجماع إثبات العمل كحل لمشكلة الإنفاق المزدوج في العملة الرقمية، مما أتاح الإجماع اللامركزي بدون أطراف موثوقة على حساب زمن استجابة عالٍ واستهلاك مرتفع للطاقة.

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 حدوداً أساسية لما يمكن أن تحققه خوارزميات الإجماع في الأنظمة غير المتزامنة، مشكّلةً فضاء التصميم لبروتوكولات الإجماع العملية.