أخبارالمطورينإدخالالمشروع Blockchain شرح الأحداث والمؤتمرات الصحافةالنشرات الإخبارية

اشترك في نشرتنا الإخبارية.

عنوان بريد الكتروني

نحن نحترم خصوصيتك

الرئيسيةالمدونةأدخل مؤسسة Blockchain

توافق القياس للمؤسسات: شرح خوارزمية IBFT

كيف يعمل تسامح اسطنبول البيزنطي مع الخطأ (IBFT) على تحسين النهاية وزيادة الإنتاجية في شبكات Ethereum الخاصة. بواسطة ConsenSys 22 يونيو 2018 نُشر في 22 يونيو 2018

تعد خوارزميات الإجماع واحدة من الابتكارات الأساسية في blockchain ، ومع ذلك فهي أيضًا واحدة من أكثر الخوارزميات إرباكًا. أنشأ ساتوشي ناكاموتو نسخة من إثبات العمل (PoW) الذي تم تنفيذه كوسيلة لتأمين والتحقق من معاملات البيتكوين في نفس الوقت. لقد بنى مجتمع blockchain على تلك الرؤية الأساسية لإنشاء حساء أبجدي لـ Proof of Stake (PoS) ، و Proof of Authority (PoA) ، و PBFT (يتحمل الخطأ البيزنطي العملي) ، والعديد من الآخرين الذين تم تصميمهم جميعًا لبناء توافق في الآراء. النظام ، مما يخلق المصدر الوحيد للحقيقة الذي يجعل blockchain قيمة للغاية.

IBFT (Istanbul Byzantine Fault Tolerant) هي آلية إجماع وهي بديل لإثبات العمل في شبكة Ethereum. مثل الخوارزميات الأخرى ، يضمن IBFT طلبًا واحدًا متفقًا عليه للمعاملات في blockchain ، ويوفر مزايا إضافية للمؤسسات ، بما في ذلك إنهاء التسوية. كان IBFT تم تنفيذه لأول مرة في Geth بواسطة Amis Technologies, وبعد فترة وجيزة تم تنفيذه في النصاب.

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

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

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

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

IBFT هو أحد النكهات العديدة لبرنامج PoA ويوفر الفوائد التالية:

كتلة نهائية فورية. هناك كتلة واحدة فقط مقترحة بارتفاع سلسلة معين. وبالتالي ، فإن السلسلة المفردة تزيل التفرع ، وكتل العم ، وخطر “التراجع” عن المعاملة مرة واحدة في السلسلة في وقت لاحق.
تقليل الوقت بين الكتل. يتم تقليل الجهد اللازم لإنشاء الكتل والتحقق من صحتها بشكل كبير (لا سيما فيما يتعلق بـ PoW) ، مما يؤدي إلى زيادة إنتاجية السلسلة بشكل كبير.
سلامة البيانات العالية والتسامح مع الخطأ. يستخدم IBFT مجموعة من المدققين لضمان سلامة كل كتلة مقترحة. يُطلب من الغالبية العظمى (حوالي 66٪) من هؤلاء المدققين التوقيع على الكتلة قبل إدخالها في السلسلة ، مما يجعل تزوير الكتل صعبًا للغاية. تدور “قيادة” المجموعة أيضًا بمرور الوقت – مما يضمن أن العقدة المعيبة لا يمكن أن تمارس تأثيرًا طويل المدى على السلسلة.
مرنة من الناحية التشغيلية. يمكن تعديل مجموعة المدققين في الوقت المناسب ، مما يضمن احتواء المجموعة على عقد موثوقة بالكامل فقط.

قدمنا هنا لمحة عامة عن IBFT ، في الغالب من الناحية غير الفنية. بالنسبة لبعض المقترحات الأصلية لـ IBFT ، يمكنك مراجعة EIPs على GitHub:

وثائق IBFT: https://github.com/ethereum/EIPs/issues/650
الكود المستخدم في النصاب: https://github.com/jpmorganchase/quorum

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

ملاحظة: يمكن أيضًا العثور على رمز IBFT في طلب سحب go-ethereum # 16385.

عملية

تتألف آلية إجماع IBFT من المكونات التالية:

أ PBFT نموذج إجماع جماعي مستوحى.
عملية يمكن بواسطتها إضافة / إزالة الأعضاء من مجموعة التحقق.

يتطلب IBFT إعادة صياغة رأس الكتلة (بمهارة) لدعم جميع جوانب القدرة.

نموذج إجماع المجموعة

ملخص

يستخدم IBFT مجموعة من عقد التحقق (Validators) التي تعمل على شبكة Ethereum لتحديد ما إذا كانت الكتلة المقترحة مناسبة للإضافة إلى السلسلة.

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

عند الانتهاء من جولة الإجماع ، يجوز للمدققين اختيار مقدم عرض جديد يكون مسؤولاً عن توفير الكتلة المرشحة في فترة الكتلة التالية.

آلية الإجماع هي آلة حالة متزامنة مسؤولة عن ضمان قيام جميع المدققين بإلحاق نفس الكتلة بالسلسلة على نفس الارتفاع.

إذا فشل إدراج كتلة ، يتم تغيير مقدم العرض ، وتبدأ العملية من جديد.

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

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

ملاحظة: هنا F تشير إلى عدد العقد المعيبة التي يتحملها النظام.

آلة الدولة

آلة الدولة IBFT

تنص على

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

الانتقالات

أانتظار الاقتراح → الإعداد. عند استلام كتلة جديدة (تحضير رسالة) من مقدم الاقتراح (أي أن الكتلة صالحة في محتواها ، كما هو الحال بالنسبة لنقطة إدخال السلسلة المقترحة).
في انتظار الاقتراح ← جولة التغيير. لم يكن الاقتراح المستلم كتلة صالحة وفقًا لمجموعة معينة من القواعد (على سبيل المثال مقدم غير صالح ، أو ترقيم دائري غير صحيح).
التحضير → جاهز. عند استلام إخطارات 2F + 1 (تحضير الرسالة) من أقران المدققين الذين يشيرون إلى أن الكتلة المقترحة مناسبة للإدراج.
جاهز → في انتظار الاقتراح. عند استلام إشعارات 2F + 1 (رسالة الالتزام) من أقران المدققين الذين يشيرون إلى استعدادهم لإلحاق الكتلة بالسلسلة. عند الانتقال ، يتم تنفيذ عملية إلحاق الكتلة بالسلسلة (نجاح).
جاهز → جولة التغيير. حسب جاهز->في انتظار الاقتراح ، ومع ذلك ، فشل إدراج الكتلة.
جولة التغيير → انتظار الاقتراح. يتفق المدققون 2F + 1 على رقم الجولة التالية الذي سيتم استخدامه.

ملاحظة: تؤدي جميع عمليات الانتقال إلى “RoundChange” إلى قيام المدقق بإرسال رسالة “RoundChange” إلى نظرائه في المدقق.

قفل الكتلة

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

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

عضوية مجموعة التحقق من الصحة

قد يتغير أعضاء مجموعة التحقق بمرور الوقت من خلال آلية التصويت. يمكن إضافة الأعضاء أو إزالتهم من خلال التصويت بالأغلبية (الطابق (N / 2) + 1) ؛ يتم التقاط كل صوت في رأس الكتلة.

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

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

بمجرد أن تصل العقدة إلى أصوات الأغلبية ، فإنها تنضم على الفور / تغادر مجموعة المدققين.

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

تحدد الأصوات تغيير الحالة (أي يتم التصويت على المرشحين ، ويتم التصويت على المدققين) ، وعدم التصويت لعقدة معينة يعني أن المدقق لا يرغب في أن تغير العقدة الحالة (لا يلزم التصويت الصريح للحفاظ على الوضع الراهن).

كتلة رأس Refactor

لدعم IBFT في Ethereum ، يجب إجراء عدد من التغييرات على رؤوس الكتلة. تشمل هذه التغييرات:

المستفيد: يحدد العقدة التي يتم التصويت عليها.
nonce: يحدد “اتجاه” التصويت – AUTH أو DROP.
mixHash: رقم سحري تم إصلاحه ، وتحديد هذه الكتلة على أنها تم التحقق من صحة IBFT.
ommersHash: يجب أن يكون تجزئة مجموعة فارغة ، حيث لا توجد كتل ommer عند العمل تحت IBFT.
الطابع الزمني: يجب أن يكون على الأقل الطابع الزمني للكتلة الرئيسية + فاصل الكتلة.
الصعوبة: يجب ملؤها بـ 0x0000000000000001.
extraData: يحتوي على بيانات محددة لـ IBFT بما في ذلك قائمة عناوين المدقق ، ProposerSeal (يحدد مقدم العرض) ، CommittingSeals (قائمة المدققين الذين أبلغوا عن “الالتزام” في هذه الكتلة).

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

استنتاج

في الختام ، IBFT هو حل بيزنطي متسامح مع الأخطاء يوفر إنهاء فوري للمعاملات مما يقلل من البنية التحتية المطلوبة التي تتطلبها PoW.

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

تعطي العمليات التي تم استكشافها في هذه المقالة الثقة في أن الشبكة التي تستخدم IBFT ستكون متسامحة مع العقد البيزنطية ويمكن استردادها في حالة رؤية هذه العقد تمارس السيطرة على الشبكة.

اشترك في النشرة الإخبارية لدينا للحصول على أحدث أخبار Ethereum وحلول المؤسسات وموارد المطورين والمزيد.يرشد