عميل خفيف إثيريوم Helios: وصول البيانات داخل السلسلة بدون حاجة للثقة

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

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

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

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

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

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

المخاطر المحتملة للبنية التحتية المركزية: التهديدات النظرية في نظام إثيريوم البيئي

تختبئ في نظام إثيريوم البيئي تهديد نظري. إنها لا تبحث عن أهداف في ذاكرة المعاملات (Mempool)، بل تنصب الفخاخ من خلال تقليد البنية التحتية المركزية التي نعتمد عليها. المستخدمون الذين يقعوا في هذا الفخ لم يرتكبوا أي خطأ: لقد قاموا فقط بزيارة DEX المألوف كما هو الحال دائمًا، وضبطوا انزلاقًا معقولًا، وقاموا بتداول الرموز...... عملياتهم لم تكن بها أي مشكلة، لكنهم قد يواجهون نوعًا جديدًا من هجوم السندويشات، وهو فخ مُعد بعناية عند مدخل نظام إثيريوم البيئي - مزود RPC.

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

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

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

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

مقدمة Helios: الوصول إلى إثيريوم بدون حاجة للثقة

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

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

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

طبقة الإجماع

يتبع عميل الخفيف في طبقة الإجماع معايير عميل الخفيف لسلسلة الإشارات، ويستفيد من لجنة التزامن لسلسلة الإشارات (التي تم تقديمها في الانقسام الصلب Altair قبل الدمج). تتكون لجنة التزامن من مجموعة فرعية من 512 مدققًا يتم اختيارهم عشوائيًا، وتستمر دورة الخدمة حوالي 27 ساعة.

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

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

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

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

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

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

1. استخدم لجنة التزام التالية بعد نقطة الفحص للحصول على والتحقق من الكتلة التي سيتم إنشاؤها في المستقبل بواسطة لجنة التزام.

2. استخدم هذه الكتلة الجديدة للحصول على لجنة التزامن التالية.

3. إذا كانت نقطة التحقق لا تزال في الخلف، ارجع إلى الخطوة 1.

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

طبقة التنفيذ

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

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

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

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

استخدام هيليوس في بيئات معقدة

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

بالإضافة إلى ذلك، فإن دعم Rust لـ WebAssembly يمكّن مطوري التطبيقات من دمج Helios بسهولة في تطبيقات JavaScript (مثل المحافظ وDApp). ستعزز هذه التكاملات أمان إثيريوم وتقلل من اعتمادنا على البنية التحتية المركزية.

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

• يدعم الحصول على بيانات العميل الخفيف مباشرة من شبكة P2P (بدلاً من RPC)
• تنفيذ بعض طرق RPC غير المدعومة بعد
• تطوير نسخة هليوس التي يمكن تجميعها إلى WebAssembly
• دمج Helios مباشرة في برنامج المحفظة
• بناء لوحة معلومات الشبكة لرؤية رصيد الرموز، دمج Helios في المواقع التي تستخدم WebAssembly للحصول على البيانات
• نشر واجهة برمجة التطبيقات لمحرك ، ربط طبقة الإجماع Helios بالعقد الكامل للطبقة التنفيذية الحالية