بناء هيليوس: وصول غير موثوق به تمامًا إلى Ethereum

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

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

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

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

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

مطبات البنية التحتية المركزية: المخلوقات النظرية في "الغابة المظلمة" في Ethereum

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

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

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

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

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

تقديم Helios: وصول غير موثوق به تمامًا إلى Ethereum

من خلال تقديم بروتوكول العميل الخفيف (الذي أصبح ممكنًا من خلال التبديل الأخير إلى Proof of Stake) ، فتحت Ethereum إمكانيات جديدة ومثيرة للتفاعل بسرعة مع blockchain والتحقق من نقاط نهاية RPC مع الحد الأدنى من متطلبات الأجهزة. في الشهر منذ ذلك الحين الدمج، لقد رأينا مجموعة جديدة من العملاء الخفيفين تظهر بشكل مستقل عن بعضها البعض (الهادي, هالة نورانية، والمستندة إلى JavaScript كيفلر) التي اتخذت مناهج مختلفة في خدمة نفس الهدف: الوصول الفعال وغير الموثوق به ، دون استخدام عقدة كاملة.

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

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

... عند مستوى الإجماع

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

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

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

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

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

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

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

1. استخدم لجنة المزامنة التالية بعد نقطة التفتيش الخاصة بنا لجلب والتحقق من كتلة تنشئ لجنة مزامنة واحدة في المستقبل.
2. استخدم هذه الكتلة الجديدة لجلب لجنة المزامنة التالية الجديدة.
3. إذا كنت لا تزال في الخلف ، فارجع إلى الخطوة 1.

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

... في طبقة التنفيذ

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

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

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

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

استخدام هيليوس في البرية

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

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

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

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

تحقق من مصدر البرنامج للبدء - نرحب بتقارير الأخطاء وطلبات الميزات والرمز. وإذا كنت تبني شيئًا أكثر ، فشاركه معنا تويتر, تیلیجرامأو Farcaster @ a16zcrypto.

***
الآراء المعبر عنها هنا هي آراء أفراد AH Capital Management، LLC ("a16z") المقتبس منهم وليست آراء a16z أو الشركات التابعة لها. تم الحصول على بعض المعلومات الواردة هنا من مصادر خارجية ، بما في ذلك من شركات محافظ الصناديق التي تديرها a16z. على الرغم من أنه مأخوذ من مصادر يُعتقد أنها موثوقة ، لم تتحقق a16z بشكل مستقل من هذه المعلومات ولا تقدم أي تعهدات حول الدقة الحالية أو الدائمة للمعلومات أو ملاءمتها لموقف معين. بالإضافة إلى ذلك ، قد يتضمن هذا المحتوى إعلانات جهات خارجية ؛ لم تقم a16z بمراجعة مثل هذه الإعلانات ولا تصادق على أي محتوى إعلاني وارد فيها.

يتم توفير هذا المحتوى لأغراض إعلامية فقط ، ولا ينبغي الاعتماد عليه كمشورة قانونية أو تجارية أو استثمارية أو ضريبية. يجب عليك استشارة مستشاريك بخصوص هذه الأمور. الإشارات إلى أي أوراق مالية أو أصول رقمية هي لأغراض توضيحية فقط ، ولا تشكل توصية استثمارية أو عرضًا لتقديم خدمات استشارية استثمارية. علاوة على ذلك ، هذا المحتوى غير موجه أو مخصص للاستخدام من قبل أي مستثمرين أو مستثمرين محتملين ، ولا يجوز الاعتماد عليه تحت أي ظرف من الظروف عند اتخاذ قرار بالاستثمار في أي صندوق تديره a16z. (سيتم تقديم عرض للاستثمار في صندوق a16z فقط من خلال مذكرة الاكتتاب الخاص واتفاقية الاشتراك والوثائق الأخرى ذات الصلة لأي صندوق من هذا القبيل ويجب قراءتها بالكامل.) أي استثمارات أو شركات محفظة مذكورة ، يشار إليها ، أو الموصوفة لا تمثل جميع الاستثمارات في السيارات التي تديرها a16z ، ولا يمكن أن يكون هناك ضمان بأن الاستثمارات ستكون مربحة أو أن الاستثمارات الأخرى التي تتم في المستقبل سيكون لها خصائص أو نتائج مماثلة. قائمة الاستثمارات التي أجرتها الصناديق التي يديرها Andreessen Horowitz (باستثناء الاستثمارات التي لم يمنحها المُصدر إذنًا لـ a16z للإفصاح علنًا عن الاستثمارات غير المعلنة في الأصول الرقمية المتداولة علنًا) على https://a16z.com/investments /.

الرسوم البيانية والرسوم البيانية المقدمة في الداخل هي لأغراض إعلامية فقط ولا ينبغي الاعتماد عليها عند اتخاذ أي قرار استثماري. الأداء السابق ليس مؤشرا على النتائج المستقبلية. المحتوى يتحدث فقط اعتبارًا من التاريخ المشار إليه. أي توقعات وتقديرات وتنبؤات وأهداف وآفاق و / أو آراء معبر عنها في هذه المواد عرضة للتغيير دون إشعار وقد تختلف أو تتعارض مع الآراء التي يعبر عنها الآخرون. يرجى الاطلاع على https://a16z.com/disclosures للحصول على معلومات إضافية مهمة