مقدمة العملة

تتضمن خارطة طريق إيثريوم تقنية توسعية تسمى أخذ عينات توافر البيانات (DAS) 6. تقدم DAS متطلبات < a href= " https://notes.ethereum.org/@djrtwo/das-requirements " > الجديدة 4 إلى مجموعة شبكات إيثريوم، مما يستلزم تنفيذ بروتوكولات الشبكات المتخصصة 7. أحد البروتوكولات البارزة < a href= " https://notes.ethereum.org/@dankrad/S-Kademlia-DAS " > يستخدم الاقتراح 4 جدول التجزئة الموزع (DHT) استنادًا إلى Kademlia 2 لتخزين واسترجاع عينات البيانات.

ومع ذلك، فإن DHTs 4 عرضة لهجمات Sybil: يمكن للمهاجم الذي يتحكم في عدد كبير من عقد DHT أن يجعل عينات DAS غير متاحة. ولمواجهة هذا التهديد، يمكن إنشاء طبقة شبكات عالية الثقة، تتكون فقط من مدققي سلسلة أجهزة الإرشاد. مثل هذا الإجراء الأمني يرفع بشكل كبير الحاجز أمام المهاجمين، حيث يجب عليهم الآن شراء ETH الخاص بهم لمهاجمة DHT.

في هذا المنشور، نقدم دليلًا على بروتوكول التحقق، والذي يمكّن المشاركين في DHT من إثبات، دون معرفة، أنهم مدققون من Ethereum.

الدافع: هجوم «إخفاء العينة» على DAS

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

يدور بروتوكول DAS حول أداة إنشاء الكتل لضمان إتاحة بيانات الكتلة حتى يتمكن العملاء من جلبها. تتضمن الأساليب الحالية تقسيم البيانات إلى عينات، ولا يجلب المشاركون في الشبكة سوى العينات التي تتعلق باهتماماتهم.

)

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

لمزيد من المعلومات حول هجمات Sybil هذه، راجع ورقة البحث الأخيرة 2 حول هجمات DHT Eclipse. وعلاوة على ذلك، < a href= " https://notes.ethereum.org/@dankrad/S-كاديمليا-داس #SKademlia -التعديلات " > الدنماركية يصف اقتراح بروتوكول شبكة DAS 8 كيف يعاني بروتوكول S/Kademlia DHT من مثل هذه الهجمات ويظهر الحاجة إلى إثبات بروتوكول التحقق.

إثبات المدقق

يحفز الهجوم أعلاه الحاجة إلى إثبات بروتوكول التحقق: إذا كان بإمكان المدققين فقط الانضمام إلى DHT، فإن المهاجم الذي يريد شن هجوم Sybil يجب أن يشارك أيضًا في كمية كبيرة من ETH.

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

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

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

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

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

إثبات بروتوكول المدقق

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

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

نظرة عامة على البروتوكول

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

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

وفي حين يُظهر كلا النهجين كفاءة مقبولة، إلا أنهما يتميزان بمقايضات متميزة. تعتمد أشجار Merkle على وظائف التجزئة الصديقة لـ Snark مثل Poseidon (والتي يمكن اعتبارها تجريبية). من ناحية أخرى، تعتمد بروتوكولات البحث الفعالة على إعداد موثوق به من powers-of-tau بحجم يساوي حجم مجموعة أدوات التحقق (حاليًا 700 ألف مدقق ولكن في ازدياد).

الآن دعونا نتعمق في البروتوكولات:

النهج #1: أشجار ميركل

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

• إيجابي: لا حاجة لإعداد موثوق
• إيجابي: سهل الفهم
• سلبي: يعتمد على وظائف التجزئة الصديقة لـ Snark مثل Poseidon
• سلبي: إنشاء إثبات أبطأ

فيما يلي وصف لبروتوكول إثبات المصادقة استنادًا إلى أشجار Merkle:

بروتوكول إثبات المصادقة باستخدام أشجار Merkle

)

في نهاية البروتوكول، يمكن لـ Alice استخدام D في DHT لتوقيع الرسائل واستنباط هوية عقدة DHT الفريدة الخاصة بها.

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

النهج #2: عمليات البحث

فيما يلي مساحة المقايضة لاستخدام بروتوكولات البحث 2 مثل Caulk 2:

• إيجابي: إنشاء إثبات فعال للغاية (باستخدام مرحلة المعالجة المسبقة)
• إيجابي: يمكن تكييف البروتوكول لاستخدام وظيفة هاش عادية بدلاً من Poseidon
• سلبي: يتطلب إعدادًا موثوقًا بحجم كبير (يساوي بشكل مثالي حجم المدققين)

فيما يلي وصف لإثبات ملموس لبروتوكول المدقق:

إثبات بروتوكول المدقق باستخدام عمليات البحث

تمامًا كما هو الحال في نهج ميركل، يقوم كل مدقق i بتسجيل قيمة pi جديدة على البلوكشين بحيث:

الكفاءة

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

نقدم أدناه نتائج معيارية لإثبات عضوية شجرة ميركل باستخدام نظام إثبات Halo2 مع IPA كمخطط التزام متعدد الحدود. يعد IPA مخططًا أبطأ من KZG ولكنه لا يتطلب إعدادًا موثوقًا به يزيد من مزايا نهج شجرة ميركل.

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

تم جمع المعايير على كمبيوتر محمول يعمل على Intel i7-8550U (وحدة معالجة مركزية عمرها خمس سنوات).

مناقشة

الهويات الدوارة

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

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

لماذا لا تستخدم المفتاح العام للهوية BLS12-381؟

قد يكون النهج البديل (ربما الأبسط) هو بناء التزام من جميع مفاتيح هوية المدقق BLS12-381 وإثبات العضوية على هذا الالتزام.

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

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

اتجاهات البحث المستقبلية

• هل يمكننا تجنب دوائر SNARK تمامًا وإجراء إثبات العضوية واشتقاق المفاتيح بطريقة جبرية بحتة؟
• ذات صلة: هل يمكننا الحصول على إثبات فعال لبروتوكول العضوية بدون إعداد موثوق ودون الاعتماد على وظائف التجزئة الصديقة لـ Snark؟

شكر وتقدير

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

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [ethresear]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [جورج كادياناكيس، ماري مالر، أندريجا نوفاكوفيتش، سوفانات تشونهابانيا]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية:
   الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.