RLCS#14: Consensus Algorithms


Consensus Algorithms أو خوازميات الاتفاق.


الاتفاق (Consensus) يعني اتخاذ قرار بشكل جماعي بحيث يكون القرار في مصلحة المجموعة. تُستخدم خوارزميات الاتفاق في الأنظمة الموزعة (Distributed Systems).


في هذه المقالة نتطرق لها في أنظمة الـ Blockchain التي هي أحد أشكال الأنظمة الموزعة.

في البلوك تشين تعني الـ Consensus أن جميع الـ nodes في الشبكة تتفق على حالة محددة للبلوك تشين؛ بمعنى عندما يتفق الأغلبية على حالة (نسخة) محددة من البلوك تشين عندها نكون توصلنا إلى الاتفاق (Consensus).


الهدف من الـ Consensus هو استبعاد أو تقليل أثر الـ malicious nodes بحيث أن رأي الأغلبية (والذين هم في الغالب يكونون honest nodes) هو الذي يأخذ بعين الاعتبار.


يمكّن الـ Consensus نظام البلوك تشين من وظيفتين أساسية:

  • يسمح بتحديث البلوك تشين مع ضمان أن كل بلوك فيها صحيح.

  • يلغي الحاجة إلى المركزية (Centralization)، بحيث أن القرار في يد المجموعة كاملة ولا ينفرد به node سواءً كان فرد أو مؤسسة.


هناك العديد من الخوارزميات المستخدمة لتطبيق استراتيجيات الـ Consensus؛ يعرض هذا المقال الخمسة الأكثر شهرة واستخدامًا في البلوك تشين، وهي كالتالي:




Proof of Work (PoW)

PoW هو حل probabilistic لمشكلة Byzantine Generals، ويعمل في البلوك تشين بالخطوات التالية:

  • عدد من الـ transactions الجديدة يتم إذاعتها (broadcast) لكل الـ nodes في الشبكة.

  • كل node يحفظ هذه الـ transactions في بلوك.

  • كل node يعمل على إيجاد PoW والذي يكون لغز رياضي لهذا البلوك. حل اللغز يعرف بالـ Mining، ويسمى الـ node الذي يحاول إيجاد الحل بالـ miner.

  • عندما يجد أحد الـ nodes الحل، يقوم بإذاعة البلوك لكل الـ nodes الأخرى، و أول من يجد الحل يتم مكافئته.

  • تقبل بقية الـ nodes البلوك وتضيفه إلى السلسلة (Chain) بعد التحقق من صحة الحل والتأكد من أنه ليس موجود بالفعل في السلسلة أي ليس مكرر.

  • تنتقل جميع الـ nodes لمحاولة حل لغز البلوك التالي، وهذه هي إشارة التوصل للاتفاق.


يعتبر PoW من أنجح خوارزميات الاتفاق، وهذا يعود إلى خاصية asymmetry التي يتميز بها بحيث أن اللغز الرياضي يتصف بالتالي:

  • من الصعب على الكمبيوتر إيجاد حل له (مثال: ا - س + س^٢ = ٣).

  • من السهل التحقق من الحل (مثال: إذا عرفت قيمة س في المثال السابق من السهل التحقق من صحة الحل بالتعويض المباشر). * الحل س = ٢ عشان تركز في الباقي لول.*

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

في المقابل ممكن أن نرى استهلاك الطاقة الضخم حسنة كذلك، بحيث أنها تجعل القيام بهجوم (attack) على الشبكة مكلف جدًا.


الـ Bitcoin هي أشهر تطبيقات تقنية البلوك تشين، وهي منصة لتبادل عملة البيتكوين الرقمية، وتستخدم استراتيجية PoW كما شرحها ناكامتو في ورقته.

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

تتضمن المدخلات للـ hash function في البيتكوين قيمة الـ hash للبلوك السابق و رقم عشوائي يعرف بالـ nonce (مفهوم معروف في عالم التشفير وهو اختصار number used only once). يقوم الـ miner بتخمين العديد من الأرقام في خانة الـ nonce حتى يصل إلى قيمة الـ hash المطلوبة، وهذه العملية تتطلب عدد كبير من المحاولات وكلما كان الـ target صغير كان الحصول على الرقم أصعب.




Proof of Stake (PoS)

PoS يحاول حل مشكلة استهلاك الطاقة الموجودة في PoW ويستبدلها بالـ Stake. الـ Stake يعني مبلغ محدد من المال (في صورة عملة رقمية) يقوم صاحبها بحجزها لمدة محددة من الوقت، وفي المقابل يحصل الشخص صاحب المبلغ الأكبر على فرصة إنشاء البلوك التالي وربح الرسوم المصاحبة له.


في هذه الاستراتيجية يوجد هناك مشكلة واضحة ومن المتوقع أنك استنتجها، وهي المركزية، بحيث أن الأشخاص أصحاب الثروة العالية هم من سيفوز بفرصة إنشاء البلوك وربح الرسوم في كل مرة؛ لذلك تم ابتكار طريقتين أخرى من قِبل منصات بلوك تشين مختلفة لاختيار الشخص الذي يحصل على فرصة إنشاء البلوك، وهي كالتالي:

  • اختيار عشوائي.

  • مدة احتجاز المبلغ؛ مستخدمًا هذه المعادلة [المبلغ * عدد الأيام].


الهجوم المحتمل على النظام الذي يستخدم استراتيجية PoS هو ( nothing at-stake)، ويعني أن المستخدم لن يخسر شيء في بناء بلوك على كل فرع من فروع البلوك تشين، وهذا يعني تواجد عدد من البلوك الصحيحة في فروع مختلفة في نفس اللحظة مما يربك النظام في اختيار أي فرع. هذا السلوك هو نتيجة أن بناء البلوك غير مكلف كما في PoW بالإضافة إلى أنه من مصلحة المستخدم المالية نظريًا التصرف بهذه الطريقة لجعل فرصته في بناء البلوك أعلى.




Delegated Proof of Stake (DPoS)

DPoS تم ابتكاره من قِِبل مؤسس BitShares، وهو ملائم للأنظمة التي تتسم بالتوسع والنمو السريع ( High Scalability)، وذلك نتيجة أنه يحصر عدد الـ Validators في النظام وهم الأعضاء الذين يملكون صلاحية بناء البلوك والتحكم في الشبكة، في المقابل يحصلون على مقابل مالي عند القيام بأي من هذا، وبهذه الطريقة تتم المعاملات وبناء البلوك بسرعة عالية. يعرف الـ Validators أيضًا بالـ witnesses.


يعمل DPoS بأن يقوم مستخدمين النظام بالتصويت (Vote) للأشخاص الذين يستحقون أن يصبحوا Validators، وتنتج قائمة بالأعضاء الأكثر حصولاً على الأصوات وهم من ستمنح لهم صلاحية بناء البلوك. قيمة الصوت تعتمد على الثروة، ويمكنك كعضو منح قوة التصويت التي تملكها لشخص آخر ليصوت بدلًا عنك.


مع آلية العمل هذه لايتطلب أن تكون لديك ثروة عالية حتى يتم التصويت لك، في المقابل عند اتساع النظام وزيادة عدد مستخدميه تصبح المنافسة أعلى وفرصة بقاءك في قائمة الـ Validators أقل. يمكن للأعضاء كذلك التصويت لحذف شخص من القائمة عند فقدان ثقتهم فيه، بالإضافة إلى أن أي تصرف مخادع من الـ Validator يزيحه من القائمة ويضعه في القائمة السوداء.




Practical Byzantine Fault Tolerance (pBFT)

pBFT يُستخدم في بناء byzantine fault tolerant system، وهي أنظمة موزعة لها القدرة على تخطي الخطأ الذي ينتج من وجود faulty nodes إلى مدى معين، فإذا كان f هو عدد faulty nodes يستلزم وجود 2f+1 عدد من الـ non-faulty nodes حتى يعمل النظام بشكل صحيح.


تُستخدم طريقة State machine replication في pBFT، والتي تعني وجود عدد من النُسخ المكررة (replicas) لحالة النظام تقوم بمعالجة نفس الطلبات القادمة للنظام والتي يجب أن تتوفر لها ثلاثة خصائص:

  • جميع النسخ (replicas) تبدأ من نفس الحالة (same inital state).

  • عند نفس المُدخل (input) ونفس الحالة (state)، جميع النسخ (replicas) تعطي نفس النتيجة (output).

  • تقوم النسخ (replicas) بمعالجة الطلبات بنفس الخطوات.


في البلوك تشين يستخدم pBFT في منصة hyperledger fabric للتأكد من ترتيب الـ transactions، بحيث أن يحتوي النظام على node يكون هو القائد وبقية الـ nodes تعرف بالـ backup nodes، وخطوات معالجة الطلب في pBFT بشكل عام تتم كالتالي:

  • يُرسل المُستخدم الطلب للقائد.

  • يقوم القائد بإرسال الطلب لكل الـ backup nodes.

  • يقوم كل واحد من الـ backup nodes بمعالجة الطلب وإرسال النتيجة للمستخدم.

  • ينتظر المستخدم عدد f+1 من الردود المتشابهة، وتعتبر هذه هي النتيجة المطلوبة.




Proof of Elapsed Time (PoET)

PoET يعمل وفقًا للاستراتيجية التالية:

  • كل node في الشبكة ينتظر لمدة عشوائية من الوقت.

  • أول من ينتهي وقت انتظاره يحصل على فرصة بناء البلوك التالي.


لتنفيذ هذه الاستراتيجية يجب أن نضمن نقطتين:

  • أن يتم تحديد الوقت بشكل عشوائي لكل node.

  • أن نتأكد أن الـ node فعلًا انتظر لكامل الوقت.


لتحقيق النقطتين السابقة يتطلب استخدام hardware خاص.

الـ (Intel Software Guard Extensions (SGX يحقق المطلوب بحيث أنه hardware يوفر وبحماية عالية بيئة آمنة لتنفيذ الأوامر (trusted code)، بحيث يكون تنفيذ الأوامر بمعزل تام عن بقية التطبيقات الأخرى التي تعمل على الجهاز، ولايمكن التدخل أو التعديل عليه.


في البلوك تشين يقوم الـ node بتحميل الـ trusted code، ثم يتابع عملية التسجيل في الشكبة والتي تضمن إنشاء keypair وإعلام جميع الـ nodes في الشبكة، وبعدها يحصل الـ node على signed timer object ثم يتبعه الانتظار لوقت محدد.



انتهت المقالة، وبقي أن أذكر أن كل منصة بلوك تشين لها طريقة تنفيذ (implementation) خاصة للخوارزميات المذكورة، وقد تستخدم المنصة الواحدة عدد من الخوارزميات بحيث أن كل خوارزمية تخدم غرض محدد.


أتمنى أن المقالة منحتك نظرة عامة وبداية جيدة للانطلاقة للفهم بشكل عميق.

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

Join