إثيريوم العميل الخفيف Helios:实现无需信任的 البلوكتشين الوصول
في 8 نوفمبر، تم إطلاق عميل خفيف جديد لإيثريوم يسمى Helios. يهدف هذا العميل الذي تم تطويره بلغة Rust إلى توفير وصول لإيثريوم بدون حاجة للثقة.
lواحدة من الأسباب الرئيسية لاستخدامنا للبلوكتشين هو عدم الحاجة للثقة. من خلال البلوكتشين، يمكننا التحكم بشكل مستقل في ثروتنا وبياناتنا. في معظم الحالات، فإن البلوكتشين مثل إثيريوم حقاً تحقق هذا الوعد: أصولنا تعود لنا حقاً.
ومع ذلك، من أجل السعي لتحقيق便利، قدمنا بعض التنازلات. واحدة من هذه هي استخدام RPC( المركزي لاستدعاء) الخادم عن بُعد. عادةً ما يصل المستخدمون إلى إثيريوم عبر مزودين مركزيين. تعمل هذه الشركات على تشغيل عقد عالية الأداء على خوادم سحابية، مما يساعد المستخدمين على الوصول بسهولة إلى بيانات السلسلة. عندما يتحقق المحفظة من رصيد الرموز أو يتحقق من ما إذا كانت المعاملات المعلقة قد تم تضمينها في كتلة، فإنها غالبًا ما تستخدم هؤلاء المزودين المركزيين.
المشكلة الحالية في النظام هي أن المستخدمين يحتاجون إلى الثقة بهذه المزودين، ولا يمكنهم التحقق من صحة نتائج الاستعلام.
Helios هو عميل خفيف لإثيريوم مبني على Rust، قادر على تقديم وصول موثوق تمامًا إلى إثيريوم. يستفيد من بروتوكول العميل الخفيف الذي تم تحقيقه بعد تحول إثيريوم إلى PoS، حيث يمكنه تحويل البيانات من مزودي RPC المركزيين غير الموثوقين إلى RPC محلي قابل للتحقق بشكل آمن. من خلال دمج RPC المركزي، يمكن لـ Helios التحقق من صحة البيانات دون الحاجة إلى تشغيل عقدة كاملة.
من الصعب التوفيق بين الراحة واللامركزية، وهذه مشكلة شائعة. يمكن لهذا العميل الجديد إكمال المزامنة في حوالي ثانيتين، ولا يحتاج إلى تخزين، حيث يمكن للمستخدمين من خلال أي جهاز ( بما في ذلك الهواتف المحمولة وملحقات المتصفح ) الوصول إلى بيانات السلسلة الآمنة. لكن ما هي المخاطر المحتملة المرتبطة بالاعتماد على البنية التحتية المركزية؟ ستستعرض هذه المقالة هذه المخاطر، وتقدم تصميم هليوس، وتوفر بعض الأفكار لمساعدة المطورين على المساهمة في مكتبة الشفرات.
مخاطر البنية التحتية المركزية: المنتجات النظرية في "الغابة المظلمة" لإثيريوم
منتج نظري يكمن في الغابة المظلمة. إنه لا يبحث عن فرائسه في حوض ذاكرة معاملات إثيريوم، بل ينصب الفخاخ من خلال محاكاة البنية التحتية المركزية التي نعتمد عليها. المستخدمون الذين يقعون في هذا الفخ لم يرتكبوا أي خطأ: لقد قاموا فقط بزيارة البورصات اللامركزية التي يذهبون إليها عادة، وضبطوا انزلاقاً معقولاً، وتداولوا الرموز كما هو معتاد... لم يفعلوا شيئاً خاطئاً، لكنهم لا يزالون يتعرضون لهجوم سموذي جديد، وهو فخ مُعد بعناية عند مدخل الغابة المظلمة لإثيريوم - مزود خدمة RPC.
قبل أن نشرح بالتفصيل، دعنا نلقي نظرة على كيفية معالجة البورصات اللامركزية للمعاملات. عندما يقوم المستخدم بتنفيذ صفقة تبادل، فإنه يقدم عدة معلمات للعقد الذكي: الرموز التي يرغب في تبادلها، ومبلغ التبادل، والأهم من ذلك، الحد الأدنى لعدد الرموز التي يجب على المستخدم تلقيها لإتمام الصفقة. تشير المعلمة الأخيرة إلى "الحد الأدنى للإنتاج" الذي يجب أن تحققه الصفقة، وإلا سيتم إلغاء المعاملة. يُعرف هذا عادةً باسم "الانزلاق"، لأنه يحدد بشكل فعال الحد الأقصى للاختلاف في الأسعار الذي قد يحدث من إرسال المعاملة إلى تجمع الذاكرة حتى يتم تضمين المعاملة في الكتلة. إذا تم تعيين الانزلاق منخفضًا جدًا، قد يتمكن المستخدم من تلقي عدد أقل من الرموز. قد تؤدي هذه الحالة أيضًا إلى هجوم السندويتش، حيث يمكن للمهاجم أن يحشر عرض المستخدم بين معاملتين خبيثتين. ستعمل هذه المعاملات على رفع سعر السوق، مما يجبر المستخدم على إجراء الصفقة بسعر سيء. ثم يقوم المهاجم ببيع الرموز على الفور لتحقيق ربح صغير.
طالما أن هذا المعامل الحد الأدنى للإنتاج مضبوط بالقرب من القيمة العادلة، فلن تكون عرضة لهجمات السندويش. لكن ماذا لو لم يقدم مزود RPC الخاص بك أسعار دقيقة لعقود الذكاء الخاصة بالبورصات اللامركزية؟ في هذه الحالة، قد يتم خداع المستخدمين ويوقعون على صفقات تبادل بمعامل حد أدنى منخفض، والأسوأ من ذلك، قد يقوم المستخدمون بإرسال المعاملات مباشرة إلى مزود RPC خبيث. يمكن للمزود عدم بث هذه المعاملة إلى تجمع الذاكرة العامة ( حيث تتنافس عشرات الروبوتات في تنفيذ هجمات السندويش )، بل يمكنه احتجاز حزمة المعاملة المستهدفة في الخفاء وإرسالها مباشرة إلى منصة MEV معينة لتحقيق الربح.
السبب الجذري وراء هذا الهجوم هو الثقة بالآخرين لمساعدتك في الحصول على حالة البلوكتشين. لمعالجة هذه المشكلة، يقوم المستخدمون ذوو الخبرة عادةً بتشغيل عقدة إثيريوم الخاصة بهم، وهي مهمة تتطلب وقتًا وموارد كبيرة، حيث تحتاج على الأقل إلى جهاز متصل بالإنترنت باستمرار، ومساحة تخزين تصل إلى مئات جيجابايت، وحوالي يوم من الوقت لمزامنة البيانات من البداية. من الواضح أن هذه العملية أصبحت أكثر تبسيطًا مقارنة بالماضي. وقد كانت هناك مجموعات تعمل بلا كلل لمساعدة الجميع في تشغيل العقد باستخدام أجهزة منخفضة التكلفة، مثل الكمبيوتر الصغير Raspberry Pi مع محرك الأقراص الخارجي (. لكن حتى مع هذه المتطلبات المنخفضة، لا يزال تشغيل العقدة صعبًا بالنسبة لمعظم المستخدمين، وخاصة مستخدمي الأجهزة المحمولة.
من المهم ملاحظة أن هجمات مزودي RPC المركزيين، رغم أنها ممكنة تمامًا، غالبًا ما تكون مجرد هجمات تصيد بسيطة، والهجمات التي نتحدث عنها لم تحدث بعد. على الرغم من أن السجلات السابقة لمزودي الخدمات الكبيرة لا تعطي سببًا للشك فيهم، إلا أنه من المجدي القيام ببعض الأبحاث قبل إضافة مزود RPC غير مألوف إلى المحفظة.
مقدمة هليوس: الوصول إلى إثيريوم بدون ثقة كاملة
أطلقت إثيريوم بروتوكول العميل الخفيف، مما يفتح إمكانيات مثيرة للتفاعل السريع مع البلوكتشين والتحقق من نقاط نهاية RPC بأقل متطلبات للأجهزة. في الشهر الذي تلا The Merge، ظهرت مجموعة من العملاء الخفيفين المستقلين عن بعضهم البعض، كل منهم يسلك طريقا مختلفا، ولكن لهدف واحد: الوصول الفعال بدون حاجة للثقة، دون الحاجة لاستخدام العقد الكاملة.
Helios هو عميل خفيف ل ايثر ، يمكنه إكمال المزامنة في حوالي ثانيتين ، دون الحاجة إلى التخزين ، ويقدم وصولاً إلى ايثر بالكامل بدون ثقة. مثل جميع عملاء ايثر ، يتكون Helios من طبقة التنفيذ وطبقة الإجماع. لكن على عكس معظم العملاء الآخرين ، فإن Helios يقترن بين هاتين الطبقتين بشكل وثيق ، حيث يحتاج المستخدم فقط إلى تثبيت وتشغيل برنامج واحد.
كيف يعمل ذلك؟ تستخدم طبقة إجماع Helios تجزئة كتلة سلسلة الإشارة المعروفة، وتتصل بـ RPC غير موثوق به، لمزامنة الكتل الحالية بطريقة قابلة للتحقق. تقوم طبقة التنفيذ في Helios بدمج هذه الكتل الموثوقة من سلسلة الإشارة مع RPC غير موثوق به لطبقة التنفيذ، للتحقق من معلومات مختلفة حول حالة السلسلة، مثل أرصدة الحسابات، وتخزين العقود، وإيصالات المعاملات، ونتائج استدعاءات العقود الذكية. تعمل هذه المكونات معًا لتوفير RPC غير موثوق به تمامًا للمستخدمين، دون الحاجة إلى تشغيل عقدة كاملة.
) طبقة الإجماع
يتوافق العميل الخفيف في طبقة الإجماع مع معيار العميل الخفيف لسلسلة الإشارات، ويستخدم لجنة التزامن لسلسلة الإشارات ### التي تم إطلاقها قبل دمج Altair Hard Fork (. تتكون لجنة التزامن من مجموعة فرعية عشوائية من 512 من المدققين، بمدة خدمة تبلغ حوالي 27 ساعة.
بعد دخول المدققين إلى لجنة التزامن، سيوقعون على جميع رؤوس كتل سلسلة الإشارات التي يرونها ) block header (. إذا وقع أكثر من ثلثي أعضاء اللجنة على رأس كتلة واحدة، فمن المحتمل جدًا أن تكون تلك الكتلة موجودة في سلسلة الإشارات القياسية. إذا كانت Helios تعرف تكوين لجنة التزامن الحالية، فيمكنها تتبع رأس السلسلة بثقة من خلال استعلام RPC غير موثوق للحصول على توقيعات لجنة التزامن الأخيرة.
بفضل تجميع توقيعات BLS، يكفي استعلام واحد لإكمال التحقق من رأس الكتلة الجديد. طالما أن التوقيع صالح وأن أكثر من ثلثي أعضاء اللجنة قد أكملوا التوقيع، يمكن ضمان أن الكتلة قد تم تضمينها في البلوكتشين ) بالطبع، قد يتم إعادة هيكلتها أيضًا خارج السلسلة، ويمكن أن يوفر تتبع نهائية الكتلة ضمانًا أقوى (.
لكن هذه الاستراتيجية تفتقر بوضوح إلى عنصر: كيفية العثور على لجنة التزامن الحالية. أولاً، يجب الحصول على جذر الثقة المعروف باسم نقطة الفحص الضعيفة )weak subjectivity checkpoint(. لا تدع الاسم يخيفك، فهو مجرد إشارة إلى تجزئة كتلة قديمة يمكن ضمان إدخالها في السلسلة في لحظة معينة في الماضي. بخصوص الوقت الدقيق لوجود نقطة الفحص، هناك بعض الحسابات الرياضية المثيرة للاهتمام: يُظهر تحليل أسوأ الحالات حوالي أسبوعين، بينما تشير التقديرات الأكثر واقعية إلى عدة أشهر.
إذا كانت نقاط التفتيش قديمة جدًا، فمن الناحية النظرية، هناك هجوم يمكن أن يخدع العقد لتتبع سلسلة خاطئة. في هذه الحالة، فإن الحصول على نقطة تفتيش ذات موضوعية ضعيفة يتجاوز قدرة البروتوكول. الحل الذي تقدمه Helios هو توفير نقطة تفتيش أولية، يتم ترميزها بشكل ثابت في الكود ) ويمكن بسهولة تجاوزها (، حيث سيتم حفظ أحدث تجزئة الكتلة النهائية محليًا لاستخدامها كنقطة تفتيش عند مزامنة العقد.
من خلال عمليات التجزئة، يمكن أن تنتج كتلة سلسلة الإشارات هاش فريد لكتلة الإشارات بسهولة. وبالتالي، يمكن الاستعلام بسهولة عن كتلة الإشارات الكاملة من العقد، ثم من خلال إجراء عمليات التجزئة عليها ومقارنتها مع هاش الكتلة المعروف، لإثبات صحة محتوى الكتلة. تستخدم Helios هذه الخاصية للحصول على والتحقق من بعض الحقول داخل كتلة نقاط التفتيش ذات الموضوع الضعيف، بما في ذلك حقلين حيويين: اللجنة الحالية للتزامن واللجنة التالية للتزامن. والأهم من ذلك، يمكن للعميل الخفيف الاستفادة من هذه الآلية لمراجعة تاريخ البلوكتشين بسرعة.
الآن بعد أن أصبح لدينا نقاط تفتيش ذات موضوعية ضعيفة، يمكننا الحصول على والتحقق من اللجنة المتزامنة الحالية واللاحقة. إذا كانت رأس السلسلة الحالية ونقطة التفتيش في نفس دورة اللجنة المتزامنة، فيمكننا البدء على الفور باستخدام رأس اللجنة المتزامنة الموقعة للتحقق من الكتلة الجديدة. إذا كانت نقطة التفتيش الخاصة بنا تتأخر بعد عدة لجان متزامنة، فيمكننا:
استخدم لجنة التزام التالية بعد نقطة التفتيش للحصول على والتحقق من كتلة ستولد لجنة التزام في المستقبل.
2.استخدام هذه الكتلة الجديدة للحصول على اللجنة المتزامنة التالية.
3.إذا كانت النقطة المرجعية لا تزال في الخلف، عد إلى الخطوة 1.
من خلال العملية الموضحة أعلاه، يمكننا مراجعة تاريخ البلوكتشين بسرعة بوحدات زمنية مدتها 27 ساعة، بدءًا من أي تجزئة كتلة في الماضي وحتى التزامن مع تجزئة الكتلة الحالية.
) طبقة التنفيذ
الهدف من العميل الخفيف في طبقة التنفيذ هو استخدام رأس كتلة الإشارة الذي تم التحقق منه من خلال طبقة الإجماع مع RPC في طبقة التنفيذ غير الموثوق بها، لتوفير بيانات موثوقة في طبقة التنفيذ. بعد ذلك يمكن الوصول إلى هذه البيانات من خلال خادم RPC المستضاف محليًا باستخدام Helios.
فيما يلي مثال بسيط للحصول على رصيد الحساب، دعونا نقدم مقدمة بسيطة حول كيفية تخزين إثيريوم للحالة. يحتوي كل حساب على عدة حقول، مثل تجزئة رمز العقد، ورقم عشوائي، وتجميع تجزئة، ورصيد. يتم تخزين هذه الحسابات في شجرة ميركل-باتريشيا الكبيرة المعدلة، المسماة شجرة الحالة. طالما تم معرفة جذر شجرة الحالة، يمكن التحقق من إثبات ميركل، لإثبات ما إذا كان هناك أي حساب في الشجرة. لا يمكن تزوير هذا الإثبات.
تتمتع Helios بجذر حالة تم التحقق منه من طبقة الإجماع ###state root(. من خلال تطبيق هذا الجذر والحصول على إثبات Merkle من طبقة التنفيذ غير الموثوق بها، يمكن لـ Helios التحقق محليًا من جميع البيانات المخزنة على إثيريوم.
نستخدم تقنيات مختلفة للتحقق من البيانات المتنوعة المستخدمة في طبقة التنفيذ، ومن خلال ذلك، يمكننا التحقق من جميع البيانات القادمة من RPC غير الموثوق. يمكن أن ترفض RPC غير الموثوق توفير الوصول إلى البيانات، لكنها لم تعد قادرة على تقديم نتائج خاطئة.
استخدام Helios في العالم الحقيقي
من الصعب تحقيق التوازن بين سهولة الاستخدام واللامركزية، وهذه نقطة ألم شائعة. من خلال Helios الخفيف الوزن، يمكن للمستخدمين الوصول إلى بيانات سلسلة الكتل الآمنة من أي جهاز ) بما في ذلك الهواتف الذكية وإضافات المتصفح (. سيمكن هذا المزيد من الأشخاص من الوصول إلى بيانات إيثرم بدون ثقة، بغض النظر عن الأجهزة المستخدمة. يمكن للمستخدمين استخدام Helios كمزود RPC لهم في محفظة معينة للوصول بدون ثقة إلى مجموعة متنوعة من DApp، وكل ذلك دون الحاجة إلى أي تغييرات أخرى.
بالإضافة إلى ذلك، فإن دعم Rust لـ WebAssembly يمكّن مطوري التطبيقات من دمج Helios بسهولة في تطبيقات Javascript ) مثل المحافظ وDApp (. ستعزز هذه التكاملات من أمان إثيريوم، وتقلل من احتياجنا إلى الثقة في البنية التحتية المركزية.
هناك العديد من الطرق للمساهمة في Helios، بالإضافة إلى إضافة لبنات إلى مستودع الشفرة، يمكنك أيضًا بناء برامج تتكامل مع Helios للاستفادة من مزاياه. فيما يلي بعض الأفكار المثيرة:
يدعم الحصول على بيانات العميل الخفيف مباشرة من شبكة P2P بدلاً من RPC
نشر بعض طرق RPC المفقودة
بناء نسخة Helios القابلة للتجميع إلى WebAssembly
دمج Helios مباشرة في برنامج المحفظة
بناء لوحة معلومات الشبكة لعرض رصيد الرموز، دمج Helios في المواقع التي تستخدم WebAssembly للحصول على البيانات
نشر واجهة برمجة التطبيقات الخاصة بمحرك، ربط طبقة توافق هيليوس مع العقدة الكاملة في طبقة التنفيذ الحالية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
عميل خفيف هليوس: تحقيق الوصول إلى إثيريوم بدون ثقة
إثيريوم العميل الخفيف Helios:实现无需信任的 البلوكتشين الوصول
في 8 نوفمبر، تم إطلاق عميل خفيف جديد لإيثريوم يسمى Helios. يهدف هذا العميل الذي تم تطويره بلغة Rust إلى توفير وصول لإيثريوم بدون حاجة للثقة.
lواحدة من الأسباب الرئيسية لاستخدامنا للبلوكتشين هو عدم الحاجة للثقة. من خلال البلوكتشين، يمكننا التحكم بشكل مستقل في ثروتنا وبياناتنا. في معظم الحالات، فإن البلوكتشين مثل إثيريوم حقاً تحقق هذا الوعد: أصولنا تعود لنا حقاً.
ومع ذلك، من أجل السعي لتحقيق便利، قدمنا بعض التنازلات. واحدة من هذه هي استخدام RPC( المركزي لاستدعاء) الخادم عن بُعد. عادةً ما يصل المستخدمون إلى إثيريوم عبر مزودين مركزيين. تعمل هذه الشركات على تشغيل عقد عالية الأداء على خوادم سحابية، مما يساعد المستخدمين على الوصول بسهولة إلى بيانات السلسلة. عندما يتحقق المحفظة من رصيد الرموز أو يتحقق من ما إذا كانت المعاملات المعلقة قد تم تضمينها في كتلة، فإنها غالبًا ما تستخدم هؤلاء المزودين المركزيين.
المشكلة الحالية في النظام هي أن المستخدمين يحتاجون إلى الثقة بهذه المزودين، ولا يمكنهم التحقق من صحة نتائج الاستعلام.
Helios هو عميل خفيف لإثيريوم مبني على Rust، قادر على تقديم وصول موثوق تمامًا إلى إثيريوم. يستفيد من بروتوكول العميل الخفيف الذي تم تحقيقه بعد تحول إثيريوم إلى PoS، حيث يمكنه تحويل البيانات من مزودي RPC المركزيين غير الموثوقين إلى RPC محلي قابل للتحقق بشكل آمن. من خلال دمج RPC المركزي، يمكن لـ Helios التحقق من صحة البيانات دون الحاجة إلى تشغيل عقدة كاملة.
من الصعب التوفيق بين الراحة واللامركزية، وهذه مشكلة شائعة. يمكن لهذا العميل الجديد إكمال المزامنة في حوالي ثانيتين، ولا يحتاج إلى تخزين، حيث يمكن للمستخدمين من خلال أي جهاز ( بما في ذلك الهواتف المحمولة وملحقات المتصفح ) الوصول إلى بيانات السلسلة الآمنة. لكن ما هي المخاطر المحتملة المرتبطة بالاعتماد على البنية التحتية المركزية؟ ستستعرض هذه المقالة هذه المخاطر، وتقدم تصميم هليوس، وتوفر بعض الأفكار لمساعدة المطورين على المساهمة في مكتبة الشفرات.
مخاطر البنية التحتية المركزية: المنتجات النظرية في "الغابة المظلمة" لإثيريوم
منتج نظري يكمن في الغابة المظلمة. إنه لا يبحث عن فرائسه في حوض ذاكرة معاملات إثيريوم، بل ينصب الفخاخ من خلال محاكاة البنية التحتية المركزية التي نعتمد عليها. المستخدمون الذين يقعون في هذا الفخ لم يرتكبوا أي خطأ: لقد قاموا فقط بزيارة البورصات اللامركزية التي يذهبون إليها عادة، وضبطوا انزلاقاً معقولاً، وتداولوا الرموز كما هو معتاد... لم يفعلوا شيئاً خاطئاً، لكنهم لا يزالون يتعرضون لهجوم سموذي جديد، وهو فخ مُعد بعناية عند مدخل الغابة المظلمة لإثيريوم - مزود خدمة RPC.
قبل أن نشرح بالتفصيل، دعنا نلقي نظرة على كيفية معالجة البورصات اللامركزية للمعاملات. عندما يقوم المستخدم بتنفيذ صفقة تبادل، فإنه يقدم عدة معلمات للعقد الذكي: الرموز التي يرغب في تبادلها، ومبلغ التبادل، والأهم من ذلك، الحد الأدنى لعدد الرموز التي يجب على المستخدم تلقيها لإتمام الصفقة. تشير المعلمة الأخيرة إلى "الحد الأدنى للإنتاج" الذي يجب أن تحققه الصفقة، وإلا سيتم إلغاء المعاملة. يُعرف هذا عادةً باسم "الانزلاق"، لأنه يحدد بشكل فعال الحد الأقصى للاختلاف في الأسعار الذي قد يحدث من إرسال المعاملة إلى تجمع الذاكرة حتى يتم تضمين المعاملة في الكتلة. إذا تم تعيين الانزلاق منخفضًا جدًا، قد يتمكن المستخدم من تلقي عدد أقل من الرموز. قد تؤدي هذه الحالة أيضًا إلى هجوم السندويتش، حيث يمكن للمهاجم أن يحشر عرض المستخدم بين معاملتين خبيثتين. ستعمل هذه المعاملات على رفع سعر السوق، مما يجبر المستخدم على إجراء الصفقة بسعر سيء. ثم يقوم المهاجم ببيع الرموز على الفور لتحقيق ربح صغير.
طالما أن هذا المعامل الحد الأدنى للإنتاج مضبوط بالقرب من القيمة العادلة، فلن تكون عرضة لهجمات السندويش. لكن ماذا لو لم يقدم مزود RPC الخاص بك أسعار دقيقة لعقود الذكاء الخاصة بالبورصات اللامركزية؟ في هذه الحالة، قد يتم خداع المستخدمين ويوقعون على صفقات تبادل بمعامل حد أدنى منخفض، والأسوأ من ذلك، قد يقوم المستخدمون بإرسال المعاملات مباشرة إلى مزود RPC خبيث. يمكن للمزود عدم بث هذه المعاملة إلى تجمع الذاكرة العامة ( حيث تتنافس عشرات الروبوتات في تنفيذ هجمات السندويش )، بل يمكنه احتجاز حزمة المعاملة المستهدفة في الخفاء وإرسالها مباشرة إلى منصة MEV معينة لتحقيق الربح.
السبب الجذري وراء هذا الهجوم هو الثقة بالآخرين لمساعدتك في الحصول على حالة البلوكتشين. لمعالجة هذه المشكلة، يقوم المستخدمون ذوو الخبرة عادةً بتشغيل عقدة إثيريوم الخاصة بهم، وهي مهمة تتطلب وقتًا وموارد كبيرة، حيث تحتاج على الأقل إلى جهاز متصل بالإنترنت باستمرار، ومساحة تخزين تصل إلى مئات جيجابايت، وحوالي يوم من الوقت لمزامنة البيانات من البداية. من الواضح أن هذه العملية أصبحت أكثر تبسيطًا مقارنة بالماضي. وقد كانت هناك مجموعات تعمل بلا كلل لمساعدة الجميع في تشغيل العقد باستخدام أجهزة منخفضة التكلفة، مثل الكمبيوتر الصغير Raspberry Pi مع محرك الأقراص الخارجي (. لكن حتى مع هذه المتطلبات المنخفضة، لا يزال تشغيل العقدة صعبًا بالنسبة لمعظم المستخدمين، وخاصة مستخدمي الأجهزة المحمولة.
من المهم ملاحظة أن هجمات مزودي RPC المركزيين، رغم أنها ممكنة تمامًا، غالبًا ما تكون مجرد هجمات تصيد بسيطة، والهجمات التي نتحدث عنها لم تحدث بعد. على الرغم من أن السجلات السابقة لمزودي الخدمات الكبيرة لا تعطي سببًا للشك فيهم، إلا أنه من المجدي القيام ببعض الأبحاث قبل إضافة مزود RPC غير مألوف إلى المحفظة.
مقدمة هليوس: الوصول إلى إثيريوم بدون ثقة كاملة
أطلقت إثيريوم بروتوكول العميل الخفيف، مما يفتح إمكانيات مثيرة للتفاعل السريع مع البلوكتشين والتحقق من نقاط نهاية RPC بأقل متطلبات للأجهزة. في الشهر الذي تلا The Merge، ظهرت مجموعة من العملاء الخفيفين المستقلين عن بعضهم البعض، كل منهم يسلك طريقا مختلفا، ولكن لهدف واحد: الوصول الفعال بدون حاجة للثقة، دون الحاجة لاستخدام العقد الكاملة.
Helios هو عميل خفيف ل ايثر ، يمكنه إكمال المزامنة في حوالي ثانيتين ، دون الحاجة إلى التخزين ، ويقدم وصولاً إلى ايثر بالكامل بدون ثقة. مثل جميع عملاء ايثر ، يتكون Helios من طبقة التنفيذ وطبقة الإجماع. لكن على عكس معظم العملاء الآخرين ، فإن Helios يقترن بين هاتين الطبقتين بشكل وثيق ، حيث يحتاج المستخدم فقط إلى تثبيت وتشغيل برنامج واحد.
كيف يعمل ذلك؟ تستخدم طبقة إجماع Helios تجزئة كتلة سلسلة الإشارة المعروفة، وتتصل بـ RPC غير موثوق به، لمزامنة الكتل الحالية بطريقة قابلة للتحقق. تقوم طبقة التنفيذ في Helios بدمج هذه الكتل الموثوقة من سلسلة الإشارة مع RPC غير موثوق به لطبقة التنفيذ، للتحقق من معلومات مختلفة حول حالة السلسلة، مثل أرصدة الحسابات، وتخزين العقود، وإيصالات المعاملات، ونتائج استدعاءات العقود الذكية. تعمل هذه المكونات معًا لتوفير RPC غير موثوق به تمامًا للمستخدمين، دون الحاجة إلى تشغيل عقدة كاملة.
) طبقة الإجماع
يتوافق العميل الخفيف في طبقة الإجماع مع معيار العميل الخفيف لسلسلة الإشارات، ويستخدم لجنة التزامن لسلسلة الإشارات ### التي تم إطلاقها قبل دمج Altair Hard Fork (. تتكون لجنة التزامن من مجموعة فرعية عشوائية من 512 من المدققين، بمدة خدمة تبلغ حوالي 27 ساعة.
بعد دخول المدققين إلى لجنة التزامن، سيوقعون على جميع رؤوس كتل سلسلة الإشارات التي يرونها ) block header (. إذا وقع أكثر من ثلثي أعضاء اللجنة على رأس كتلة واحدة، فمن المحتمل جدًا أن تكون تلك الكتلة موجودة في سلسلة الإشارات القياسية. إذا كانت Helios تعرف تكوين لجنة التزامن الحالية، فيمكنها تتبع رأس السلسلة بثقة من خلال استعلام RPC غير موثوق للحصول على توقيعات لجنة التزامن الأخيرة.
بفضل تجميع توقيعات BLS، يكفي استعلام واحد لإكمال التحقق من رأس الكتلة الجديد. طالما أن التوقيع صالح وأن أكثر من ثلثي أعضاء اللجنة قد أكملوا التوقيع، يمكن ضمان أن الكتلة قد تم تضمينها في البلوكتشين ) بالطبع، قد يتم إعادة هيكلتها أيضًا خارج السلسلة، ويمكن أن يوفر تتبع نهائية الكتلة ضمانًا أقوى (.
لكن هذه الاستراتيجية تفتقر بوضوح إلى عنصر: كيفية العثور على لجنة التزامن الحالية. أولاً، يجب الحصول على جذر الثقة المعروف باسم نقطة الفحص الضعيفة )weak subjectivity checkpoint(. لا تدع الاسم يخيفك، فهو مجرد إشارة إلى تجزئة كتلة قديمة يمكن ضمان إدخالها في السلسلة في لحظة معينة في الماضي. بخصوص الوقت الدقيق لوجود نقطة الفحص، هناك بعض الحسابات الرياضية المثيرة للاهتمام: يُظهر تحليل أسوأ الحالات حوالي أسبوعين، بينما تشير التقديرات الأكثر واقعية إلى عدة أشهر.
إذا كانت نقاط التفتيش قديمة جدًا، فمن الناحية النظرية، هناك هجوم يمكن أن يخدع العقد لتتبع سلسلة خاطئة. في هذه الحالة، فإن الحصول على نقطة تفتيش ذات موضوعية ضعيفة يتجاوز قدرة البروتوكول. الحل الذي تقدمه Helios هو توفير نقطة تفتيش أولية، يتم ترميزها بشكل ثابت في الكود ) ويمكن بسهولة تجاوزها (، حيث سيتم حفظ أحدث تجزئة الكتلة النهائية محليًا لاستخدامها كنقطة تفتيش عند مزامنة العقد.
من خلال عمليات التجزئة، يمكن أن تنتج كتلة سلسلة الإشارات هاش فريد لكتلة الإشارات بسهولة. وبالتالي، يمكن الاستعلام بسهولة عن كتلة الإشارات الكاملة من العقد، ثم من خلال إجراء عمليات التجزئة عليها ومقارنتها مع هاش الكتلة المعروف، لإثبات صحة محتوى الكتلة. تستخدم Helios هذه الخاصية للحصول على والتحقق من بعض الحقول داخل كتلة نقاط التفتيش ذات الموضوع الضعيف، بما في ذلك حقلين حيويين: اللجنة الحالية للتزامن واللجنة التالية للتزامن. والأهم من ذلك، يمكن للعميل الخفيف الاستفادة من هذه الآلية لمراجعة تاريخ البلوكتشين بسرعة.
الآن بعد أن أصبح لدينا نقاط تفتيش ذات موضوعية ضعيفة، يمكننا الحصول على والتحقق من اللجنة المتزامنة الحالية واللاحقة. إذا كانت رأس السلسلة الحالية ونقطة التفتيش في نفس دورة اللجنة المتزامنة، فيمكننا البدء على الفور باستخدام رأس اللجنة المتزامنة الموقعة للتحقق من الكتلة الجديدة. إذا كانت نقطة التفتيش الخاصة بنا تتأخر بعد عدة لجان متزامنة، فيمكننا:
2.استخدام هذه الكتلة الجديدة للحصول على اللجنة المتزامنة التالية.
3.إذا كانت النقطة المرجعية لا تزال في الخلف، عد إلى الخطوة 1.
من خلال العملية الموضحة أعلاه، يمكننا مراجعة تاريخ البلوكتشين بسرعة بوحدات زمنية مدتها 27 ساعة، بدءًا من أي تجزئة كتلة في الماضي وحتى التزامن مع تجزئة الكتلة الحالية.
) طبقة التنفيذ
الهدف من العميل الخفيف في طبقة التنفيذ هو استخدام رأس كتلة الإشارة الذي تم التحقق منه من خلال طبقة الإجماع مع RPC في طبقة التنفيذ غير الموثوق بها، لتوفير بيانات موثوقة في طبقة التنفيذ. بعد ذلك يمكن الوصول إلى هذه البيانات من خلال خادم RPC المستضاف محليًا باستخدام Helios.
فيما يلي مثال بسيط للحصول على رصيد الحساب، دعونا نقدم مقدمة بسيطة حول كيفية تخزين إثيريوم للحالة. يحتوي كل حساب على عدة حقول، مثل تجزئة رمز العقد، ورقم عشوائي، وتجميع تجزئة، ورصيد. يتم تخزين هذه الحسابات في شجرة ميركل-باتريشيا الكبيرة المعدلة، المسماة شجرة الحالة. طالما تم معرفة جذر شجرة الحالة، يمكن التحقق من إثبات ميركل، لإثبات ما إذا كان هناك أي حساب في الشجرة. لا يمكن تزوير هذا الإثبات.
تتمتع Helios بجذر حالة تم التحقق منه من طبقة الإجماع ###state root(. من خلال تطبيق هذا الجذر والحصول على إثبات Merkle من طبقة التنفيذ غير الموثوق بها، يمكن لـ Helios التحقق محليًا من جميع البيانات المخزنة على إثيريوم.
نستخدم تقنيات مختلفة للتحقق من البيانات المتنوعة المستخدمة في طبقة التنفيذ، ومن خلال ذلك، يمكننا التحقق من جميع البيانات القادمة من RPC غير الموثوق. يمكن أن ترفض RPC غير الموثوق توفير الوصول إلى البيانات، لكنها لم تعد قادرة على تقديم نتائج خاطئة.
استخدام Helios في العالم الحقيقي
من الصعب تحقيق التوازن بين سهولة الاستخدام واللامركزية، وهذه نقطة ألم شائعة. من خلال Helios الخفيف الوزن، يمكن للمستخدمين الوصول إلى بيانات سلسلة الكتل الآمنة من أي جهاز ) بما في ذلك الهواتف الذكية وإضافات المتصفح (. سيمكن هذا المزيد من الأشخاص من الوصول إلى بيانات إيثرم بدون ثقة، بغض النظر عن الأجهزة المستخدمة. يمكن للمستخدمين استخدام Helios كمزود RPC لهم في محفظة معينة للوصول بدون ثقة إلى مجموعة متنوعة من DApp، وكل ذلك دون الحاجة إلى أي تغييرات أخرى.
بالإضافة إلى ذلك، فإن دعم Rust لـ WebAssembly يمكّن مطوري التطبيقات من دمج Helios بسهولة في تطبيقات Javascript ) مثل المحافظ وDApp (. ستعزز هذه التكاملات من أمان إثيريوم، وتقلل من احتياجنا إلى الثقة في البنية التحتية المركزية.
هناك العديد من الطرق للمساهمة في Helios، بالإضافة إلى إضافة لبنات إلى مستودع الشفرة، يمكنك أيضًا بناء برامج تتكامل مع Helios للاستفادة من مزاياه. فيما يلي بعض الأفكار المثيرة: