فهم الإجماع الموزع

المقال الأصلي 

https://www.preethikasireddy.com/post/lets-take-a-crack-at-understanding-distributed-consensus

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

    أجبرت بلوكتشين المهندسين والعلماء على إعادة النظر والتشكيك في النماذج الراسخة في الحوسبة الموزعة.

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

الأنظمة الموزعة ليست جديدة بأي حال من الأحوال. أمضى العلماء والمهندسون عقودًا في البحث في هذا الموضوع. ولكن ما علاقة blockchain بهم؟ حسنًا ، لم تكن جميع المساهمات التي قدمتها blockchain ممكنة إذا لم تكن الأنظمة الموزعة موجودة أولاً.

في الأساس ، تعد blockchain نوعًا جديدًا من الأنظمة الموزعة. لقد بدأ مع ظهور Bitcoin ومنذ ذلك الحين كان له تأثير دائم في مجال الحوسبة الموزعة. لذا ، إذا كنت تريد حقًا معرفة كيفية عمل blockchain ، فإن الفهم الجيد لمبادئ الأنظمة الموزعة أمر ضروري.

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

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

بعد قراءة هذا المقال ، ستخرج بفهم أقوى لما يلي:

• ما هو النظام الموزع ،
• خصائص النظام الموزع ،
• ماذا يعني أن يكون لديك إجماع في نظام موزع ،
• فهم خوارزميات الإجماع التأسيسي (مثل DLS و PBFT) ، و
• لماذا إجماع ناكاموتو صفقة كبيرة.

ما هو النظام الموزع؟

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

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

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

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

في حالة وجود طائرة ، تعمل هذه الوحدات المنفصلة معًا لتوصلك من النقطة أ إلى النقطة ب:

مصدر

في هذا المقال، سنركز على الأنظمة الموزعة التي تكون فيها العمليات عبارة عن أجهزة كمبيوتر منفصلة مكانيًا.

ملاحظة: يمكنني استخدام المصطلحات “عقدة” أو “نظير” أو “كمبيوتر” أو “مكون” بالتبادل مع “عملية”. كلهم يعنون نفس الشيء لأغراض هذا المقال. وبالمثل ، يمكنني استخدام مصطلح “شبكة” بالتبادل مع “النظام”.

خصائص النظام الموزع

كل نظام موزع له مجموعة محددة من الخصائص. وتشمل هذه:

أ) التزامن

تعمل العمليات في النظام بشكل متزامن ، مما يعني حدوث أحداث متعددة في وقت واحد. بمعنى آخر ، ينفذ كل كمبيوتر في الشبكة الأحداث بشكل مستقل في نفس الوقت مثل أجهزة الكمبيوتر الأخرى في الشبكة.

هذا يتطلب التنسيق.

لامبورت ، إل (1978). الوقت والساعات وترتيب الأحداث في نظام موزع

ب) عدم وجود ساعة عالمية

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

في مقالة بعنوان “الوقت والساعات وترتيب الأحداث في نظام موزع” ، توضح ليزلي لامبورت كيف يمكننا استنتاج ما إذا كان حدث ما يحدث قبل آخر من خلال تذكر العوامل التالية:

1. يتم إرسال الرسائل قبل استلامها.
2. كل كمبيوتر له سلسلة من الأحداث.

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

ومع ذلك ، إذا أسسنا الترتيب بالكامل على الأحداث التي يسمعها كل كمبيوتر فردي ، فيمكننا أن نواجه مواقف يختلف فيها هذا الترتيب عما يدركه مستخدم خارجي عن النظام. وهكذا ، تُظهر الورقة أن الخوارزمية لا يزال بإمكانها السماح بالسلوك الشاذ.

أخيرًا ، يناقش لامبورت كيف يمكن منع مثل هذه الحالات الشاذة باستخدام ساعات فعلية متزامنة بشكل صحيح.

لكن انتظر – هناك تحذير كبير: تنسيق الساعات المستقلة يعد مشكلة معقدة للغاية في علوم الكمبيوتر. حتى إذا قمت في البداية بتعيين مجموعة من الساعات بدقة ، ستبدأ الساعات في الاختلاف بعد فترة زمنية معينة. ويرجع ذلك إلى “انجراف الساعة” ، وهي ظاهرة تقوم فيها الساعات بحساب الوقت بمعدلات مختلفة قليلاً.

بشكل أساسي ، توضح ورقة لامبورت أن الوقت وترتيب الأحداث يمثلان عقبات أساسية في نظام من أجهزة الكمبيوتر الموزعة والمنفصلة مكانيًا.

ج) الفشل المستقل للمكونات

يتمثل أحد الجوانب الحاسمة لفهم الأنظمة الموزعة في الاعتراف بأن المكونات في النظام الموزع معيبة. وهذا هو سبب تسميته “الحوسبة الموزعة المتسامحة مع الأخطاء”.

من المستحيل أن يكون لديك نظام خالٍ من الأخطاء. تخضع الأنظمة الحقيقية لعدد من العيوب أو العيوب المحتملة ، سواء كانت عملية تعطل ؛ فقدان الرسائل أو تشويهها أو تكرارها ؛ قسم الشبكة يؤخر أو يسقط الرسائل ؛ أو حتى عملية تسير بشكل كامل وترسل رسائل وفقًا لبعض الخطط الحاقدة.

    من المستحيل أن يكون لديك نظام خالٍ من الأخطاء.

يمكن تصنيف هذه الإخفاقات على نطاق واسع إلى ثلاث فئات:

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

مع أخذ ذلك في الاعتبار ، فإن الهدف هو تصميم بروتوكولات تسمح لنظام به مكونات خاطئة بمواصلة تحقيق الهدف المشترك وتقديم خدمة مفيدة.

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

بشكل عام ، هناك نوعان من النماذج التي يجب مراعاتها عند إنشاء نظام موزع:

1) التسامح البسيط مع الخطأ

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

2 أ) التسامح البيزنطي مع الخطأ

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

2ب) بار للتسامح مع الخطأ

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

بشكل أكثر رسمية ، يتم تعريف هذا على أنه نموذج BAR – النموذج الذي يحدد لكل من الفشل البيزنطي والعقلاني. يفترض نموذج BAR ثلاثة أنواع من الممثلين:

• البيزنطية (Byzantine): العقد البيزنطية خبيثة وتحاول إفسادك.
• الإيثار (Altruistic): تتبع العقد الصادقة دائمًا البروتوكول.
• عقلاني (Rational): لا تتبع العقد العقلانية البروتوكول إلا إذا كان يناسبها.

د) مرور الرسالة

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

1) متزامن

في النظام المتزامن ، من المفترض أن يتم تسليم الرسائل خلال فترة زمنية محددة ومعروفة.

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

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

2) غير متزامن

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

ماذا يعني الحصول على إجماع في نظام موزع

لقد تعلمنا حتى الآن عن الخصائص التالية للنظام الموزع:

• تزامن العمليات
• عدم وجود ساعة عالمية
• عمليات معيبة
• تمرير الرسالة

بعد ذلك ، سنركز على فهم ما يعنيه تحقيق “الإجماع” في نظام موزع. لكن أولاً ، من المهم إعادة التأكيد على ما أشرنا إليه سابقًا: هناك المئات من هياكل الأجهزة والبرامج المستخدمة في الحوسبة الموزعة.

يُطلق على الشكل الأكثر شيوعًا اسم حالة الألة المنسوخة .

حالة الألة المنسوخة (Replicated State Machine)

حالة الألة المنسوخة هي حالة آلة حتمية يتم نسخها عبر العديد من أجهزة الكمبيوتر ولكنها تعمل كحالة واحدة. قد يكون أي من أجهزة الكمبيوتر هذه معيبًا ، لكن حالة الأله ستستمر في العمل.

في حالة الألة المنسوخة، إذا كانت المعاملة صالحة ، فستؤدي مجموعة من المدخلات إلى انتقال حالة النظام إلى الحالة التالية. العملية (transaction ) هي عملية ذرية في قاعدة بيانات. هذا يعني أن العمليات إما اكتملت بالكامل أو لم تكتمل على الإطلاق. تُعرف مجموعة المعاملات المحفوظة في حالة الألة المنسوخة باسم “سجل المعاملات”.

يُطلق على منطق الانتقال من حالة صالحة إلى حالة أخرى اسم “منطق انتقال الحالة”.

بمعنى آخر ، حالة الألة المنسوخة عبارة عن مجموعة من أجهزة الكمبيوتر الموزعة التي تبدأ جميعها بنفس القيمة الأولية. لكل حالة انتقال ، تقرر كل عملية القيمة التالية. يعني الوصول إلى “الإجماع” أن جميع أجهزة الكمبيوتر يجب أن تتفق بشكل جماعي على ناتج هذه القيمة.

في المقابل ، يحتفظ هذا بسجل معاملات متسق عبر كل جهاز كمبيوتر في النظام (أي أنهم “يحققون هدفًا مشتركًا”). يجب أن تقبل حالة الألة المنسوخة باستمرار المعاملات الجديدة في هذا السجل (أي “تقديم خدمة مفيدة”). يجب أن تفعل ذلك على الرغم من حقيقة أن:

1. بعض أجهزة الكمبيوتر معيبة.
2. الشبكة غير موثوقة وقد تفشل الرسائل في التسليم أو تتأخر أو تكون معطلة.
3. لا توجد ساعة عالمية للمساعدة في تحديد ترتيب الأحداث.

وهذا ، يا أصدقائي ، هو الهدف الأساسي لأي خوارزمية إجماع.

مشكلة الإجماع ، التعريف

تحقق الخوارزمية الإجماع إذا استوفت الشروط التالية:

1. الاتفاقية: تقرر جميع العقد غير المعيبة نفس قيمة الإخراج.
2. الإنهاء: تقرر جميع العقد غير المعيبة في النهاية بعض قيمة الإخراج.

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

بشكل عام ، تفترض خوارزميات الإجماع عادةً ثلاثة أنواع من الفاعلين في النظام:

1. المُقدمون (Proposers)، ويطلق عليهم غالبًا القادة أو المنسقون.
2. المُتقبلون (Acceptors) ، العمليات التي تستمع إلى الطلبات من المقترحين وتستجيب بالقيم.
3. المُتعلمين (Learners) ، عمليات أخرى في النظام تتعلم القيم النهائية التي يتم تحديدها.

بشكل عام ، يمكننا تحديد خوارزمية الإجماع من خلال ثلاث خطوات:

الخطوة 1: انتخاب

• تنتخب العمليات عملية واحدة (أي قائد) لاتخاذ القرارات.

    يقترح القائد قيمة الإخراج الصالحة التالية.

الخطوة الثانية: التصويت

• تستمع العمليات غير المعيبة إلى القيمة التي يقترحها القائد ، وتتحقق من صحتها ، وتقترحها باعتبارها القيمة الصالحة التالية.

الخطوة 3: القرار

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

من المهم ملاحظة أن كل خوارزمية إجماع مختلفة:

• المصطلحات (على سبيل المثال ، الجولات والمراحل) ،
• إجراءات كيفية التعامل مع الأصوات ، و
• معايير كيفية تحديد القيمة النهائية (على سبيل المثال ، شروط الصلاحية).

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

بسيط بما فيه الكفاية ، أليس كذلك؟

استحالة FLP

… ليس صحيحا. لكن ربما رأيت ذلك قادمًا!

تذكر كيف وصفنا الفرق بين نظام متزامن ونظام غير متزامن:

• في البيئات المتزامنة ، يتم تسليم الرسائل في إطار زمني ثابت
• في البيئات غير المتزامنة ، لا يوجد ضمان لتسليم الرسالة.

هذا التمييز مهم.

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

ولكن ، كما أشرنا سابقًا ، فإن افتراض أننا نعمل في بيئات متزامنة ليس عمليًا خارج البيئات الخاضعة للرقابة حيث يمكن توقع زمن انتقال الرسالة ، مثل مراكز البيانات التي تحتوي على ساعات ذرية متزامنة.

في الواقع ، لا تسمح لنا معظم البيئات بعمل افتراض متزامن. لذلك يجب علينا التصميم لبيئات غير متزامنة.

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

يُعرف هذا رسميًا باسم “نتيجة استحالة FLP”. كيف حصلت على هذا الاسم؟ حسنًا ، أنا سعيد لأنك سألت!

    كل عملية خاطئة واحدة تجعل من المستحيل التوصل إلى إجماع بين العمليات غير المتزامنة القطعية.

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

كانت هذه النتيجة مشكلة كبيرة بالنسبة في الحوسبة الموزعة. ومع ذلك ، استمر العلماء في المضي قدمًا لإيجاد طرق للتحايل على استحالة FLP.

على مستوى عالٍ ، هناك طريقتان للتحايل على استحالة FLP:

• استخدم افتراضات التزامن.
• استخدم اللا حتمية.

دعونا نلقي نظرة عميقة على كل واحد الآن.

النهج 1: استخدام افتراضات التزامن

أعرف ما الذي تفكر فيه: ماذا يعني هذا بحق؟

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

ولكن كيف يمكننا أن نضمن أن كل عملية غير خاطئة ستقرر قيمة ما إذا كنا لا نعرف متى سيتم تسليم الرسالة بسبب الشبكات غير المتزامنة؟

لكي نكون واضحين ، لا تشير النتائج إلى أن الإجماع لا يمكن الوصول إليه. بدلا من ذلك ، بسبب عدم التزامن ، لا يمكن التوصل إلى توافق في وقت محدد. القول بأن الإجماع “مستحيل” يعني ببساطة أن الإجماع “ليس ممكنًا دائمًا”. إنها تفاصيل دقيقة ولكنها مهمة.

طريقة واحدة للتحايل على هذا هو استخدام المُهله (timeouts) . إذا لم يتم إحراز أي تقدم في تحديد القيمة التالية ، فإننا ننتظر حتى انتهاء المهلة ، ثم نبدأ الخطوات من جديد. كما نحن على وشك أن نرى ، هذا ما فعلته خوارزميات الإجماع مثل Paxos و Raft بشكل أساسي.

باكسوس

تم تقديم Paxos في التسعينيات ، وكان أول خوارزمية إجماع واقعية وعملية ومتسامحة مع الأخطاء. إنها واحدة من أول خوارزميات الإجماع المعتمدة على نطاق واسع والتي أثبتت صحتها بواسطة Leslie Lamport واستخدمتها شركات الإنترنت العالمية مثل Google و Amazon لبناء الخدمات الموزعة.

يعمل Paxos مثل هذا:

المرحلة الأولى: تجهيز الطلب

1. يختار مقدم الاقتراح رقم إصدار الاقتراح الجديد (n) ويرسل “طلب التحضير” للمُتقبلون .
2. إذا تلقى المُتقبلون طلبًا للتحضير ((“prepare,” n) مع n أكبر من طلب أي طلب تم الرد عليه بالفعل ، يرسل المتقبلون (“ack,” n, n’, v’) أو (“ack,” n, ^ , ^).
3. يستجيب المُتقبلون بوعد بعدم قبول أي إقنراحات أخرى مرقمة أقل من n.
4. يقترح المُتقبلون القيمة (v) لأكبر عدد من المقترحات التي قبلوها ، إن وجدت. وإلا فإنهم يجيبون بـ ^.

المرحلة الثانية: قبول الطلب

1. إذا تلقى مقدم الطلب ردودًا من غالبية المُتقبلين ، فيمكنه إصدار طلب قبول(“accept,” n, v) برقم n وقيمة v.
2. n هو الرقم الذي ظهر في طلب التحضير.
3. v هي قيمة الاقتراح الأعلى رقمًا بين الردود.
4. إذا تلقى المُتقبل طلب قبول (“accept,” n, v) ، فإنه يقبل الاقتراح ما لم يكن قد استجاب بالفعل لطلب التحضير برقم أكبر من n.

المرحلة 3: مرحلة التعلم

1. عندما يقبل المتقبل عرضًا ، فإنه يرد على جميع المتعلمين (“accept,” n, v).
2. يتلقى المتعلمون (“accept,” n, v) من غالبية المُتقبلين ، قرر v ، وأرسل (“decide,” v)  إلى جميع المتعلمين الآخرين.
3. يتلقى المتعلمون(“decide,” v)  وv المقرره.

مصدر

واو ! تلخبط؟ أعلم أن هذه الكثير من المعلومات التي يجب استيعابها.

ولكن انتظر هناك المزيد!

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

لن أخوض في التفاصيل ، ولكن عملية العودة إلى العمليات العادية في مثل هذه الحالات كانت معقدة للغاية حيث كان من المتوقع أن تتدخل العمليات وتدفع عملية الحل إلى الأمام.

السبب الرئيسي في صعوبة فهم Paxos هو أن العديد من تفاصيل التنفيذ الخاصة به تُترك مفتوحة لتفسير القارئ: كيف نعرف عندما يفشل مقدم العرض؟ هل نستخدم الساعات المتزامنة لتعيين فترة مهلة لتقرير متى يفشل مقدم العرض ونحتاج إلى الانتقال إلى المرتبة التالية؟ 🤷‍

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

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

الآن ، ربما تتساءل من أين يأتي افتراض التزامن.

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

رافت

في عام 2013 ، نشر Ongaro و Ousterhout خوارزمية إجماع جديدة لآلة حالة مكررة تسمى Raft ، حيث كان الهدف الأساسي هو القابلية للفهم (على عكس Paxos).

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

لكن انتظر … وماذا عن البيئات “البيزنطية”؟

في حين أن خوارزميات الإجماع التقليدية (مثل Paxos و Raft) قادرة على الازدهار في البيئات غير المتزامنة باستخدام مستوى معين من افتراضات التزامن (أي المهلات) ، فهي ليست بيزنطية متسامحة مع الأخطاء. إنهم يتحملون الأخطاء فقط.

من السهل التعامل مع أخطاء الأعطال لأنه يمكننا نمذجة العملية على أنها إما عاملة أو معطلة – 0 أو 1. لا يمكن للعمليات أن تتصرف بشكل ضار وتكذب. لذلك ، في نظام متسامح مع الأعطال ، يمكن بناء نظام موزع حيث تكفي الأغلبية البسيطة للتوصل إلى توافق في الآراء.

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

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

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

“مشكلة الجنرال البيزنطي”

تُعرف محاولة بناء نظام كمبيوتر موثوق به يمكنه التعامل مع العمليات التي توفر معلومات متضاربة رسميًا باسم “المشكلة العامة البيزنطية”. يجب أن يكون البروتوكول البيزنطي المتسامح مع الأخطاء قادرًا على تحقيق هدفه المشترك حتى ضد السلوك الضار من العقد.

قدمت الورقة “المشكلة العامة البيزنطية” بقلم ليزلي لامبورت ، وروبرت شوستاك ، ومارشال بيز الدليل الأول لحل مشكلة الجنرال البيزنطي: فقد أظهرت أن النظام الذي يحتوي على عقد بيزنطية x يجب أن يحتوي على الأقل على 3x + 1 من العقد الإجمالية من أجل الوصول إجماع.

إليكم السبب:

إذا كانت العقد x معيبة ، فيجب أن يعمل النظام بشكل صحيح بعد التنسيق مع n ناقص x nodes (نظرًا لأن العقد x قد تكون معيبة / بيزنطية ولا تستجيب). ومع ذلك ، يجب أن نستعد لاحتمال أن x الذي لا يستجيب قد لا يكون معيبًا ؛ يمكن أن يكون x هو الذي يستجيب. إذا أردنا أن يفوق عدد العقد غير المعيبة عدد العقد المعيبة ، فإننا نحتاج على الأقل n minus x minus x > x . ومن ثم ، فإن n > 3x + 1  هو الأمثل.

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

لماذا ا؟

باختصار ، بناء خوارزمية إجماع يمكنها الصمود في وجه كل من بيئة غير متزامنة وبيئة بيزنطية … حسنًا ، سيكون ذلك نوعًا ما مثل صنع معجزة.

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

لذا اربطوا أحزمة الأمان …

نحن ذاهبون في رحلة ميدانية …

إلى أرض …

أوراق أكاديمية نظرية!

حسنًا ، حسنًا – أنا آسف لبناء ذلك. لكن يجب أن تكون متحمسًا! تذكر هذا الشيء برمته “صنع معجزة” الذي ناقشناه في وقت سابق؟ سنلقي نظرة على خوارزميتين (DLS و PBFT) التي قربتنا أكثر من أي وقت مضى لكسر الحاجز البيزنطي + غير المتزامن.

خوارزمية DLS

قدمت الورقة “الإجماع في وجود التزامن الجزئي” من قبل Dwork و Lynch و Stockmeyer (ومن هنا جاءت تسميتها خوارزمية DLS) تقدمًا كبيرًا في الإجماع البيزنطي المتسامح مع الأخطاء: فقد حددت نماذج لكيفية تحقيق الإجماع في “” نظام متزامن جزئيا. “

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

أوضحت الورقة نسختين من افتراض التزامن الجزئي:

• افترض وجود حدود ثابتة للمدة التي يستغرقها تسليم الرسائل. لكنهم غير معروفين بداهة. الهدف هو الوصول إلى إجماع بغض النظر عن الحدود الفعلية.
• افترض أن الحدود العليا لتسليم الرسائل معروفة ، ولكن لا يمكن ضمان تعليقها إلا بدءًا من وقت غير معروف (يُطلق عليه أيضًا “وقت التقييس العالمي (Global Standardization Time)”  أو GST). الهدف هو تصميم نظام يمكنه الوصول إلى إجماع بغض النظر عن وقت حدوث هذا الوقت.

إليك كيفية عمل خوارزمية DLS:

سلسلة من الجولات مقسمة إلى مراحل “المحاولة (trying)” و “تحرير القفل(lock-release)”.

1. كل جولة لها مقترح وتبدأ بكل عملية من العمليات التي توصل القيمة التي يعتقدون أنها صحيحة.
2. “يقترح” مقدم الطلب قيمة إذا كانت عمليات N – x على الأقل قد أبلغت تلك القيمة.
3. عندما تتلقى العملية القيمة المقترحة من مقدم الاقتراح ، يجب عليها قفل القيمة ثم بث تلك المعلومات.
4. إذا تلقى مقدم الطلب رسائل من عمليات x + 1 التي قاموا بتأمينها على بعض القيمة ، فإنه يلتزم بذلك كقيمة نهائية.

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

أمان (Safety)

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

الحياه(Liveness)

هذا مصطلح آخر لخاصية “الإنهاء” التي ناقشناها سابقًا ، حيث تقرر كل عقدة غير معيبة في النهاية بعض قيمة الإخراج. في إعداد blockchain ، تعني “الحياة” أن blockchain يستمر في النمو عن طريق إضافة كتل جديدة صالحة. تعد الحياة أمرًا مهمًا لأنها الطريقة الوحيدة التي يمكن أن تستمر بها الشبكة في أن تكون مفيدة – وإلا فإنها ستتوقف.

كما نعلم من استحالة FLP ، لا يمكن تحقيق الإجماع في نظام غير متزامن تمامًا. جادلت ورقة DLS بأن وضع افتراض التزامن الجزئي لتحقيق شرط الحياة يكفي للتغلب على استحالة FLP.

وهكذا أثبتت الورقة أن الخوارزميات لا تحتاج إلى استخدام أي افتراض تزامن لتحقيق حالة السلامة.

بسيط جدًا ، أليس كذلك؟ لا تقلق إذا لم يكن كذلك. دعونا نحفر أعمق قليلا.

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

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

    دائمًا ما يتعلق تصميم نظام موزع بالمقايضات.

سيكون هذا أكثر خطورة بكثير من الخيار السابق. ليس هناك فائدة من الحصول على خدمة مفيدة (أي ، الحياة) إذا كانت الخدمة فاسدة (أي لا يوجد أمان). في الأساس ، وجود نوعين مختلفين من blockchain أسوأ من توقف blockchain بأكمله.

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

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

خوارزمية PBFT

أُطلق على خوارزمية بيزنطية أخرى تتسامح مع الأخطاء ، نُشرت عام 1999 من قبل ميغيل كاسترو وباربرا ليسكوف ، “التحمل البيزنطي العملي للخطأ (Practical Byzantine Fault-Tolerance” )أ” أو (PBFT). تم اعتباره خوارزمية أكثر “عملية” للأنظمة التي تظهر السلوك البيزنطي.

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

وكما أوضحنا ، يمكن أن يكون ذلك خطيرًا للغاية في بيئة غير متزامنة.

باختصار ، أظهرت خوارزمية PBFT أنها يمكن أن توفر السلامة والحيوية على افتراض (n-1)/3 عُقد خاطئة. كما ناقشنا سابقًا ، هذا هو الحد الأدنى لعدد العقد التي نحتاجها لتحمل العيوب البيزنطية. لذلك ، كانت مرونة الخوارزمية هي الأمثل.

وفرت الخوارزمية الأمان بغض النظر عن عدد العقد المعيبة. بمعنى آخر ، لم يفترض التزامن من أجل الأمان. ومع ذلك ، اعتمدت الخوارزمية على التزامن من أجل الحياة. على الأكثر ، يمكن أن تكون العقد (n-1) / 3 معيبة ولا يزداد تأخير الرسالة أكثر من حد زمني معين. ومن ثم ، فقد تحايلت PBFT على استحالة FLP باستخدام افتراض التزامن لضمان الحياة.

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

1. حدثت معاملة جديدة على العميل وتم بثها إلى العقدة الأساسيه.
2.  تفوم العقدة الأساسية ببث متعدد لجميع العقد الاحتياطية.
3. نفذت العقد الاحتياطية المعاملة وأرسلت الرد إلى العميل.
4. أراد العميل ردود x + 1 من العقد الاحتياطية بنفس النتيجة. كانت هذه هي النتيجة النهائية ، وحدث انتقال الحاله.

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

ملاحظة: شرح خوارزمية PBFT بالكامل هو منشور مدونة بمفرده! سنحفظ ذلك ليوم آخر ؛).

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

من المهم أن نشكر PBFT على مساهماتها. لقد تضمنت أفكارًا ثورية مهمة ستتعلم منها بروتوكولات الإجماع الأحدث (خاصة في عالم ما بعد blockchain) وتستخدمها.

على سبيل المثال ، Tendermint عبارة عن خوارزمية إجماع جديدة تتأثر بشدة بـ PBFT. في مرحلة “التحقق” ، تستخدم Tendermint خطوتين للتصويت (مثل PBFT) لتحديد القيمة النهائية. يتمثل الاختلاف الرئيسي مع خوارزمية Tendermint في أنها مصممة لتكون أكثر عملية.

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

النهج 2: عدم الحتمية

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

يدخل: إجماع ناكاموتو

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

    الإجماع التقليدي لا يرقى إلى مستوى جيد.

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

إن تألق إجماع ناكاموتو هو بجعل الاحتمالية المذكورة أعلاه. بدلاً من  أن كل عقدة توافق على قيمة ما ، تعمل f (x) بحيث تتفق جميع العقد على احتمالية أن تكون القيمة صحيحة.

انتظر ، ماذا يعني ذلك؟

متسامح مع الخطأ البيزنطي

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

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

مكافآت الكتلة

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

مقاومة سيبيل

إثبات العمل المطلوب لحل هذا اللغز يجعل البروتوكول مقاومًا بطبيعته لـ Sybil. لا حاجة إلى PKI أو أي مخططات مصادقة خيالية أخرى.

ثرثرة الند للند

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

ليست آمنة “تقنيًا” في البيئات غير المتزامنة

وفقًا لإجماع ناكاموتو ، يكون ضمان الأمان احتماليًا – فنحن نطور أطول سلسلة ، وكل كتلة جديدة تقلل من احتمال محاولة عقدة ضارة بناء سلسلة أخرى صالحة.

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

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

    توافق ناكاموتو لا يضمن من الناحية الفنية السلامة في بيئة غير متزامنة.

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

من المسلم به أن هذا سيتطلب من المهاجم اكتساب الكثير من قوة التجزئة وإنفاق الكثير من المال.

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

ناكاموتو مقابل الإجماع التقليدي

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

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

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

هذا يجعلها قابلة للنشر بسهولة في بيئة العالم الحقيقي. إنه حقًا ابن العم الأكثر “العملي” لـ PBFT.

الخاتمه

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

إجماع ناكاموتو هو حقًا ابتكار سمح لموجة جديدة كاملة من الباحثين والعلماء والمطورين والمهندسين بمواصلة فتح آفاق جديدة في أبحاث بروتوكول الإجماع.

وهناك مجموعة جديدة تمامًا من البروتوكولات التي يتم تطويرها والتي تتجاوز إجماع ناكاموتو.مثل إجماع اللحم ، أي شخص؟ ؛) لكنني سأحتفظ بهذا المنشور التالي – ترقبوا ذلك!