تجميعات اللجنة مع المدققين الموزعين

اقتراح لإضافة نقطتي نهاية جديدتين إلى منارة API التي من شأنها أن تسمح لعملاء مدقق DVT بدعم تجميعات اللجان.

بهيشيك كومار

8 ديسمبر 2022 •5 دقائق للقراءة

المبادئ الأساسية لتجميعات اللجان

اليوم ، نريد التحدث عن واجبات التجميع في إثبات الحصة في Ethereum وكيف يمكن للأدوات الوسيطة الموزعة لأداة التحقق مثل Charon أن تدعمها.

بروتوكول Ethereum له نوعان من اللجان: لجان منارة ولجان التزامن . اللجان هي مجموعات فرعية من مجموعة كاملة من المدققين النشطين التي يتم استخدامها لتوزيع عبء العمل الإجمالي.

تدير لجان المنارة الشهادات لبروتوكول الإجماع بينما تسمح لجان المزامنة للعملاء الخفيفين بتحديد رئيس سلسلة المنارات بسرعة وبدون ثقة.

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

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

واجبات التجميع هذه أكثر تعقيدًا من المهام القياسية. أولاً ، يجب على كل مدقق في اللجنة إنشاء دليل على الاختيار ، وهو توقيع BLS. يتم تمرير إثبات التحديد إلى دالة IsAggregator التي تحدد ما إذا كان المدقق عبارة عن مجمّع لتلك الفتحة أم لا. إذا كان المدقق عبارة عن مجمّع ، فإنه يُعلم عميله المُوافق عليه بالاشتراك في الشبكة الفرعية للجنة المرتبطة ، والتي تستمع لتجميع الرسائل. بعد مرور بعض الوقت ، سيتم بعد ذلك جلب مجموعة من الرسائل المجمعة ودمجها مع إثبات التحديد في رسالة تسمى التجميع والدليل(A & P). ثم يوقع المدقق على A&P ويرسله إلى سلسلة المنارة. من المهم ملاحظة أن التجميع والدليل الموقعين هو توقيع متداخل يحتوي على إثبات التحديد بداخله.

المشكلة الحالية في إجراء تجميعات اللجان باستخدام المدققين الموزعين

بالنسبة إلى بنية البرامج الوسيطة DVT مثل تلك الخاصة بـ Obol ، فإن كل عميل مدقق (VC) في المجموعة لديه حق الوصول إلى مشاركة المفتاح الخاص فقط ، وليس المفتاح الخاص الكامل. في سياق DVT ، يُطلق على التوقيع الذي يتم إنشاؤه بواسطة مشاركة مفتاح خاص توقيعًا جزئيًا . تجمع DVT بين النصاب القانوني لهذه التواقيع الجزئية باستخدام تجميع عتبة BLS في التوقيع النهائي الذي يتم إرساله إلى سلسلة المنارة ، والتي تسمى التوقيع المجمع.

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

لذلك يحتاج رأس المال الجريء (VC) إلى الوصول بطريقة ما إلى دليل اختيار مجمع كامل لأداء واجبات التجميع الخاصة به.

الحل المقترح

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

• POST / eth / v1 / Validator / beacon_committee_selections
• POST / eth / v1 / Validator / sync_committee_selections

يجب على VCs التي تدعم البرامج الوسيطة DVT استدعاء نقاط النهاية هذه عند بداية الفتحة لجلب دليل اختيار مجمع لاستخدامه في واجبات مجمع اللجان (كل من لجنة المنارة ولجنة المزامنة).

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

يحتاج جانب العميل لنقاط النهاية هذه فقط إلى أن يتم تنفيذه بواسطة عملاء المدققين الذين يهدفون إلى دعم البرامج الوسيطة DVT. يجب تمكينه من خلال علامة ميزة الاشتراك مثل: `--distributed-validator`.

تدفق المدقق

دعونا نرى كيف يعمل هذا لتدفق تجميع الشهادات .

• في بداية الفتحة حيث يكون لدى المدقق تصديق ، يقوم VC بإنشاء برهان اختيار جزئي.
• تستدعي على الفور نقطة نهاية POST / eth / v1 / validator / beacon_committee_selections الجديدة بهذا التوقيع ، والتي تُرجع إثبات الاختيار المجمع بمجرد استلام النصاب القانوني للتوقيعات الجزئية ودمجها لإنشاء التجميع الصحيح .
• باستخدام استجابة إثبات التحديد المدمجة ، يحسب VC ما إذا كان مُجمّع تصديق للفتحة باستخدام دالة is_aggregator .
• إذا لم يكن VC مجمعًا ، فإنه يخرج من هذا التدفق. خلاف ذلك؛
• يستدعي VC POST / eth / v1 / validator / beacon_committee_subscriptions مع IsAggregator = القيمة الحقيقية ، وهذا يُعلم عميل المنارة بالبدء في إعداد شهادة مجمعة للتوقيع.
• بعد ثلثي الفتحة ، يستدعي VC GET / eth / v1 / validator / aggregate_attestation . هذا يجلب الشهادة المجمعة من عقدة المنارة.
• يتم الجمع بين الشهادة المجمعة وإثبات الاختيار المجمع في رسالة مجمعة وإثبات.
• أخيرًا ، يوقع VC على الرسالة التجميعية والإثبات ويستدعي POST / eth / v1 / Validator / aggregate_and_proofs . هذا ينشر الشهادة المجمعة الموقعة. 🎉
• لاحظ أن هذا التجميع النهائي الموقع والإثبات هو بحد ذاته تجميع وإثبات جزئي. ولكن نظرًا لاحتوائه على إثبات الاختيار المجمع ، فإن البرمجيات الوسيطة DVT قادرة على تجميع العتبة في تجميع وإثبات مُجمَّع مُوقَّع يتم تقديمه إلى سلسلة المنارة.

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

خاتمة

توضح هذه المقالة كيف يمكننا إضافة إتاحة عالية للمدققين الحاليين على Ethereum مع بعض الامتدادات الثانوية لمواصفات API المتفق عليها وبعض سلوك الاشتراك لعميل المدقق. نعتقد أن جعل DVT ميزة إضافية يمكن لجميع العملاء الاستفادة منها أفضل لللامركزية من جعل عميل مدقق مخصص قادرًا على توقيع رسائل عشوائية ، على غرار الطريقة التي تم بها استبدال mev-geth بـ mev-boost جزئيًا لتقليل قوة مركزية العميل التي فرضها .

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

شكرا للقراءة!

زائدة

هيكل API

نقطة النهاية

POST / eth / v1 / Validator / beacon_committee_selections

وصف

إرجاع براهين اختيار لجنة المنارة المجمعة للعتبة.

طلب

[

{

"validator_index": "1"،

"فتحة 1"،

"Selection_proof": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66519af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b665668d0dff91cc1b66846

}

]

إجابة

{

"بيانات": [

{

"validator_index": "1"،

"فتحة 1"،

"Selection_proof": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66519af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b665668d0dff91cc1b66846

}

]

}

نقطة النهاية

POST / eth / v1 / Validator / sync_committee_selections

وصف

تُرجع البراهين البراهين على اختيار لجنة المزامنة المجمعة.

طلب

[

{

"validator_index": "1"،

"فتحة 1"،

"subcommittee_index": "1"،

"Selection_proof": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66519af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b665668d0dff91cc1b66846

}

]

إجابة

{

"بيانات": [

{

"validator_index": "1"،

"فتحة 1"،

"subcommittee_index": "1"،

"Selection_proof": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66519af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b665668d0dff91cc1b66846

}

]

}

حاويات SSZ

// BeaconCommitteeSelection هي البيانات المطلوبة لاختيار لجنة المنارة.

فئة منارة لجنة الاختيار (حاوية):

ValidatorIndex: ValidatorIndex

الفتحة: الفتحة

إثبات الاختيار: توقيع BLS

// SyncCommitteeSelection هي البيانات المطلوبة لاختيار لجنة المزامنة.

فئة SyncCommitteeSelection (حاوية):

ValidatorIndex: ValidatorIndex

الفتحة: الفتحة

اللجنة الفرعية الفهرس: فهرس اللجنة

إثبات الاختيار: توقيع BLS