إثيريوم العميل الخفيف Helios: تحقيق الوصول إلى البلوكتشين دون ثقة
في 8 نوفمبر، تم إطلاق عميل خفيف جديد لإثيريوم يسمى Helios. تم تطوير هذا العميل باستخدام لغة Rust، ويهدف إلى تقديم وصول إثيريوم بالكامل دون الحاجة إلى الثقة.
أحد الأغراض الرئيسية لاستخدام البلوكتشين هو تحقيق عدم الحاجة إلى الثقة. من خلال البلوكتشين، يمكننا السيطرة بشكل مستقل على ثروتنا وبياناتنا. في معظم الحالات، فإن البلوكتشين مثل إثيريوم قد وفى بهذا الوعد: أصولنا تعود حقًا لنا.
ومع ذلك، من أجل السعي نحو الراحة، قمنا أيضاً بإجراء بعض التنازلات. واحدة من هذه هي استخدام RPC( المركزي لاستدعاء ) الخادم عن بُعد. عادةً ما يصل المستخدمون إلى إثيريوم من خلال مزودين مركزيين. تعمل هذه الشركات على تشغيل عقد عالية الأداء على خوادم سحابية، مما يساعد الجميع في الحصول بسهولة على بيانات السلسلة. عندما يستعلم المحفظة عن رصيد الرموز أو يتحقق من حالة المعاملات، يتم استخدام هؤلاء المزودين المركزيين تقريباً دائماً.
المشكلة الحالية في النظام هي أن المستخدمين يحتاجون إلى الثقة في هؤلاء المزودين، ولا يمكنهم التحقق مما إذا كانت نتائج الاستعلام صحيحة.
هيليوس هو عميل خفيف مبني على لغة راست لإثيريوم، قادر على تقديم وصول موثوق به تمامًا إلى إثيريوم. يستخدم بروتوكول العميل الخفيف الذي تم تحقيقه بعد انتقال إثيريوم إلى PoS، لتحويل البيانات من مزودي RPC مركزيين غير موثوقين إلى RPC محلي يمكن التحقق منه بشكل آمن. بالجمع بين RPC المركزي، لا يحتاج هيليوس إلى تشغيل عقدة كاملة للتحقق من صحة البيانات.
يمكن لهذا العميل إكمال المزامنة في حوالي ثانيتين، دون الحاجة إلى التخزين، يمكن للمستخدم الوصول بأمان إلى البيانات على السلسلة من أي جهاز ( بما في ذلك الهاتف المحمول وإضافات المتصفح ). ولكن ما هي المخاطر المحتملة التي تعتمد على البنية التحتية المركزية؟ سنقوم بعد ذلك بتحليل هذه المخاطر، وتقديم تصميم Helios، وتوفير بعض الأفكار للمساعدة في تحسين مكتبة الشيفرة.
المخاطر المحتملة للبنية التحتية المركزية
توجد طريقة هجوم نظرية كامنة في "الغابة المظلمة" لإثيريوم. إنها ليست في البحث عن أهداف في تجمعات ذاكرة المعاملات، ولكنها تقوم من خلال تقليد البنية التحتية المركزية التي نعتمد عليها لوضع الفخاخ. المستخدمون، حتى وإن لم يرتكبوا خطأ، قد يقعوا في الفخ: هم فقط يتداولون في DEX كما هو معتاد، ويحددون انزلاقًا معقولًا... لكنهم قد يتعرضون لهجوم ساندويتش جديد، وهو فخ مُعد بعناية عند مزود RPC.
عند معالجة المعاملات في البورصات اللامركزية، يحتاج المستخدمون إلى تقديم عدة معلمات للعقد الذكي: الرموز التي يرغبون في تبادلها، ومبلغ التبادل، والأهم من ذلك، الحد الأدنى من عدد الرموز الذي يكون المستخدم مستعدًا لقبوله. تشير المعلمة الأخيرة إلى "الحد الأدنى الناتج" الذي يجب أن يتم الوصول إليه في التبادل، وإلا ستُلغى المعاملة. يُعرف هذا عادةً باسم "انزلاق السعر"، حيث يحدد فعليًا أقصى فرق سعر يمكن أن يحدث من إرسال المعاملة إلى تسجيلها على البلوكتشين. إذا تم تعيين انزلاق السعر بشكل منخفض جدًا، قد يحصل المستخدم على عدد قليل من الرموز، وقد يتعرض أيضًا لهجوم السندويتش.
طالما أن إعدادات الحد الأدنى من معلمات الإنتاج ضمن نطاق معقول، فلن تتعرض لهجمات السندوتش. ولكن ماذا لو لم يقدم مزود RPC الاقتباسات الدقيقة لعقد DEX الذكي؟ قد يؤدي ذلك إلى تضليل المستخدمين لتوقيع صفقات تبادل بمعلمات إنتاج دنيا منخفضة. والأسوأ من ذلك، قد يقوم المستخدمون أيضًا بإرسال المعاملات مباشرة إلى مزود RPC خبيث. يمكن لمزود الخدمة عدم بث المعاملات إلى تجمع الذاكرة العامة، ولكن بدلاً من ذلك يحتفظ بها سراً ويرسل حزمة المعاملات المهاجمة مباشرة إلى جهات محددة لتحقيق الربح.
السبب الجذري وراء هذا الهجوم هو الثقة بالآخرين للحصول على حالة البلوكتشين. لحل هذه المشكلة، يقوم المستخدمون ذوو الخبرة عادة بتشغيل عقدة إثيريوم الخاصة بهم، ولكن هذا يتطلب الكثير من الوقت والموارد، حيث تحتاج على الأقل إلى جهاز متصل بالإنترنت باستمرار، ومساحة تخزين تصل إلى مئات الجيجابايت، وحوالي يوم واحد للمزامنة من الصفر. على الرغم من أن العتبة لتشغيل العقد قد انخفضت الآن، إلا أنها لا تزال صعبة بالنسبة لمعظم المستخدمين، خاصةً أولئك الذين يستخدمون الأجهزة المحمولة.
من المهم ملاحظة أن هجمات مزودي RPC المركزيين على الرغم من أنها ممكنة تمامًا، إلا أنها عادة ما تكون مجرد هجمات تصيد بسيطة، ولم تحدث الهجمات من النوع الذي وصفناه. على الرغم من أن السجل السابق لمزودي الخدمة الرئيسيين موثوق به، إلا أنه من الحكمة إجراء المزيد من البحث قبل استخدام مزودي RPC غير المألوفين.
هيليوس: تحقيق الوصول إلى إثيريوم بدون ثقة
إثيريوم أطلقت بروتوكول العميل الخفيف، مما يفتح إمكانيات جديدة للتفاعل السريع مع البلوكتشين والتحقق من نقاط نهاية RPC بمتطلبات أجهزة أقل. بعد شهر من The Merge، تم إطلاق عدة عملاء خفيفين مستقلين، حيث اعتمدوا طرقًا مختلفة، ولكن الهدف واحد: تحقيق وصول فعال بدون ثقة دون الحاجة إلى تشغيل العقد الكاملة.
هيليوس هو عميل خفيف لإيثريوم، يمكنه إكمال المزامنة في حوالي ثانيتين، دون الحاجة إلى التخزين، ويقدم وصولاً إلى إيثريوم دون الحاجة إلى الثقة. مثل جميع عملاء إيثريوم، يحتوي هيليوس على طبقة تنفيذ وطبقة توافق. لكن على عكس معظم العملاء، يقوم هيليوس بدمج الطبقتين بشكل وثيق، مما يسمح للمستخدمين بتثبيت وتشغيل برنامج واحد فقط.
تعمل هيليوس على النحو التالي: تستخدم طبقة الإجماع تجزئة كتلة سلسلة الإشارات المعروفة، وتربطها بـ RPC غير موثوق، لمزامنة الكتل الحالية بطريقة يمكن التحقق منها. تقوم طبقة التنفيذ بدمج هذه الكتل المعروفة من سلسلة الإشارات مع RPC طبقة التنفيذ غير الموثوق بها، للتحقق من معلومات مختلفة عن حالة السلسلة، مثل أرصدة الحسابات، وتخزين العقود، وإيصالات المعاملات، ونتائج استدعاءات العقود الذكية. تعمل هذه المكونات معًا لتوفير RPC لا يتطلب الثقة بالكامل للمستخدمين، وبدون الحاجة لتشغيل عقدة كاملة.
طبقة الإجماع
يتبع العميل الخفيف في طبقة الإجماع مواصفات العميل الخفيف لسلسلة الإشارات، ويستخدم لجنة المزامنة لسلسلة الإشارات. لجنة المزامنة هي مجموعة فرعية تتكون من 512 مُصدِّق تم اختيارهم عشوائيًا، وتستمر فترة خدمتهم حوالي 27 ساعة.
بعد دخول المدققين إلى لجنة التزامن، سيقومون بتوقيع جميع رؤوس الكتل الخاصة بسلسلة الإشارات التي يرونها. إذا وقع أكثر من ثلثي أعضاء اللجنة على رأس كتلة، فمن المحتمل جدًا أن تكون تلك الكتلة ضمن سلسلة الإشارات المعتمدة. إذا كانت هليوس على دراية بتكوين لجنة التزامن الحالية، فيمكنها تتبع رأس السلسلة بشكل موثوق من خلال استعلام توقيعات لجنة التزامن الأخيرة.
بفضل تجميع توقيعات BLS، يمكن التحقق من رأس الكتلة الجديدة من خلال استعلام واحد فقط. طالما أن التوقيع صالح وأن أكثر من 2/3 من أعضاء اللجنة قد أتموا التوقيع، يمكن ضمان أن الكتلة قد تم تضمينها في السلسلة. بالطبع، يمكن أن يوفر تتبع نهائية الكتلة ضمانات أقوى.
تحتاج هذه الإستراتيجية أيضًا إلى حل مشكلة كيفية العثور على لجنة التزامن الحالية. أولاً، يجب الحصول على جذر ثقة يُعرف باسم نقطة التحقق الضعيفة. إنها تمثل تجزئة كتلة قديمة يمكن ضمان تضمينها في السلسلة في وقت ما في الماضي. فيما يتعلق بمدة وجود نقطة التحقق، تُظهر التحليلات النظرية أن أسوأ الحالات تبلغ حوالي أسبوعين، بينما قد تصل التقديرات الفعلية إلى عدة أشهر.
إذا كانت النقطة المرجعية قديمة جدًا، فمن الناحية النظرية، هناك هجوم يمكن أن يغري العقدة لمتابعة سلسلة خاطئة. في هذه الحالة، فإن الحصول على نقطة مرجعية ذات موضوعية ضعيفة يتجاوز نطاق قدرة البروتوكول. الحل من Helios هو تقديم نقطة مرجعية مبدئية، يتم ترميزها بشكل صارم في مستودع الكود ( من السهل تغطيته )، حيث ستحتفظ محليًا بأحدث تجزئة كتلة نهائية، لاستخدامها كنقطة مرجعية أثناء مزامنة العقد.
من خلال عمليات التجزئة، يمكن أن تنتج كتلة سلسلة الإشارات بسهولة تجزئة فريدة لكتلة الإشارة. وبالتالي، يمكن استعلام الكتلة الكاملة للإشارة بسهولة، ثم إثبات صحة محتوى الكتلة من خلال مقارنة التجزئات. تستفيد Helios من هذه الخاصية للحصول على والتحقق من النقاط الحرجة في كتلة نقاط الضعف الذاتية، بما في ذلك اللجنة الحالية للتزامن واللجنة التالية للتزامن. والأهم من ذلك، يمكن للعميل الخفيف الاستفادة من هذه الآلية لمراجعة تاريخ البلوكتشين بسرعة.
بعد الحصول على نقاط تفتيش ذات موضوعية ضعيفة، يمكننا الحصول على والتحقق من المجلس التزامني الحالي والمقبل. إذا كانت رأس السلسلة الحالية ونقطة التفتيش ضمن نفس دورة المجلس التزامني، يمكننا استخدام رأس المجلس التزامني الموقع للتحقق من الكتلة الجديدة على الفور. إذا كانت نقطة التفتيش تأتي بعد عدة مجالس تزامنية، يمكننا:
استخدم لجنة التزام التالية بعد نقطة التفتيش للحصول على والتحقق من الكتلة التي ستولد لجنة التزام في المستقبل.
استخدم هذه الكتلة الجديدة للحصول على لجنة المزامنة التالية.
إذا كانت نقطة التفتيش لا تزال في الخلف، ارجع إلى الخطوة 1.
من خلال العملية المذكورة أعلاه، يمكننا مراجعة تاريخ البلوكتشين بسرعة بوحدات زمنية تبلغ 27 ساعة، بدءًا من أي تجزئة كتلة من الماضي حتى المزامنة مع التجزئة الحالية للكتلة.
طبقة التنفيذ
الهدف من العميل الخفيف في طبقة التنفيذ هو استخدام رأس كتلة الإشارة الذي تم التحقق منه من خلال طبقة الإجماع مع RPC الخاص بطبقة التنفيذ غير الموثوق به، لتوفير بيانات طبقة التنفيذ الموثوقة. يمكن بعد ذلك الوصول إلى هذه البيانات عبر خادم RPC مستضاف محليًا بواسطة Helios.
فيما يلي مثال بسيط على كيفية الحصول على رصيد الحساب، أولاً نقدم بإيجاز كيفية تخزين إثيريوم للحالة. يحتوي كل حساب على عدة حقول، مثل تجزئة كود العقد، ورقم عشوائي، وتجزئة التخزين، والرصيد. يتم تخزين هذه الحسابات في شجرة ميركل-باتريشيا كبيرة معدلة، تُعرف بشجرة الحالة. طالما نعرف جذر شجرة الحالة، يمكننا التحقق من دليل ميركل، لإثبات ما إذا كان هناك أي حساب في الشجرة. لا يمكن تزوير هذا الدليل.
يستمد Helios جذر الحالة الذي تم التحقق منه من طبقة الإجماع. من خلال تطبيق هذا الجذر وطلب إثبات Merkle عبر RPC لطبقة التنفيذ غير الموثوق بها، يمكن لـ Helios التحقق محليًا من جميع البيانات المخزنة في إثيريوم.
نستخدم تقنيات مختلفة للتحقق من البيانات المتنوعة المستخدمة في طبقة التنفيذ، مما يتيح لنا التحقق من جميع البيانات القادمة من RPC غير الموثوق به. يمكن أن ترفض RPC غير الموثوق تقديم الوصول إلى البيانات، ولكن لا يمكنها تقديم نتائج خاطئة.
آفاق تطبيق هيليوس
من الشائع أن يكون من الصعب تحقيق توازن بين سهولة الاستخدام واللامركزية. من خلال Helios الخفيف الوزن، يمكن للمستخدمين الوصول إلى بيانات السلسلة الآمنة من أي جهاز ( بما في ذلك الهواتف المحمولة وإضافات المتصفح ). سيمكن ذلك المزيد من الناس من الوصول إلى بيانات إثيريوم بدون حاجة للثقة، بغض النظر عن الأجهزة المستخدمة. يمكن للمستخدمين استخدام Helios كمزود RPC في المحفظة للوصول إلى مجموعة متنوعة من DApp بدون حاجة للثقة، وكل ذلك دون أي تغييرات أخرى.
بالإضافة إلى ذلك، فإن دعم Rust لـ WebAssembly يمكّن مطوري التطبيقات من دمج Helios بسهولة في تطبيقات Javascript ( مثل المحافظ وDApp ). ستعزز هذه التكاملات من أمان إثيريوم، وتقلل من اعتمادنا على البنية التحتية المركزية.
يمكن للمجتمع المساهمة في Helios بطرق متعددة، بالإضافة إلى تحسين مكتبة الشيفرات، يمكن أيضًا بناء برامج تتكامل مع Helios للاستفادة من مزاياه. فيما يلي بعض الاتجاهات المحتملة للتطوير:
يدعم الحصول على بيانات العميل الخفيف مباشرة من شبكة P2P، بدلاً من الاعتماد على RPC
تنفيذ طرق RPC المفقودة
تطوير إصدار Helios يمكن تجميعه إلى WebAssembly
دمج Helios مباشرة في برنامج المحفظة
بناء لوحة معلومات الشبكة لمشاهدة رصيد التوكن، ودمج Helios في المواقع التي تستخدم WebAssembly للحصول على البيانات
نشر واجهة برمجة التطبيقات لمحرك, ربط طبقة إجماع هليوس إلى عقدة كاملة من الطبقة التنفيذية الحالية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
عميل خفيف هيليوس: تحقيق الوصول إلى بيانات إثيريوم داخل السلسلة بدون ثقة كاملة
إثيريوم العميل الخفيف Helios: تحقيق الوصول إلى البلوكتشين دون ثقة
في 8 نوفمبر، تم إطلاق عميل خفيف جديد لإثيريوم يسمى Helios. تم تطوير هذا العميل باستخدام لغة Rust، ويهدف إلى تقديم وصول إثيريوم بالكامل دون الحاجة إلى الثقة.
أحد الأغراض الرئيسية لاستخدام البلوكتشين هو تحقيق عدم الحاجة إلى الثقة. من خلال البلوكتشين، يمكننا السيطرة بشكل مستقل على ثروتنا وبياناتنا. في معظم الحالات، فإن البلوكتشين مثل إثيريوم قد وفى بهذا الوعد: أصولنا تعود حقًا لنا.
ومع ذلك، من أجل السعي نحو الراحة، قمنا أيضاً بإجراء بعض التنازلات. واحدة من هذه هي استخدام RPC( المركزي لاستدعاء ) الخادم عن بُعد. عادةً ما يصل المستخدمون إلى إثيريوم من خلال مزودين مركزيين. تعمل هذه الشركات على تشغيل عقد عالية الأداء على خوادم سحابية، مما يساعد الجميع في الحصول بسهولة على بيانات السلسلة. عندما يستعلم المحفظة عن رصيد الرموز أو يتحقق من حالة المعاملات، يتم استخدام هؤلاء المزودين المركزيين تقريباً دائماً.
المشكلة الحالية في النظام هي أن المستخدمين يحتاجون إلى الثقة في هؤلاء المزودين، ولا يمكنهم التحقق مما إذا كانت نتائج الاستعلام صحيحة.
هيليوس هو عميل خفيف مبني على لغة راست لإثيريوم، قادر على تقديم وصول موثوق به تمامًا إلى إثيريوم. يستخدم بروتوكول العميل الخفيف الذي تم تحقيقه بعد انتقال إثيريوم إلى PoS، لتحويل البيانات من مزودي RPC مركزيين غير موثوقين إلى RPC محلي يمكن التحقق منه بشكل آمن. بالجمع بين RPC المركزي، لا يحتاج هيليوس إلى تشغيل عقدة كاملة للتحقق من صحة البيانات.
يمكن لهذا العميل إكمال المزامنة في حوالي ثانيتين، دون الحاجة إلى التخزين، يمكن للمستخدم الوصول بأمان إلى البيانات على السلسلة من أي جهاز ( بما في ذلك الهاتف المحمول وإضافات المتصفح ). ولكن ما هي المخاطر المحتملة التي تعتمد على البنية التحتية المركزية؟ سنقوم بعد ذلك بتحليل هذه المخاطر، وتقديم تصميم Helios، وتوفير بعض الأفكار للمساعدة في تحسين مكتبة الشيفرة.
المخاطر المحتملة للبنية التحتية المركزية
توجد طريقة هجوم نظرية كامنة في "الغابة المظلمة" لإثيريوم. إنها ليست في البحث عن أهداف في تجمعات ذاكرة المعاملات، ولكنها تقوم من خلال تقليد البنية التحتية المركزية التي نعتمد عليها لوضع الفخاخ. المستخدمون، حتى وإن لم يرتكبوا خطأ، قد يقعوا في الفخ: هم فقط يتداولون في DEX كما هو معتاد، ويحددون انزلاقًا معقولًا... لكنهم قد يتعرضون لهجوم ساندويتش جديد، وهو فخ مُعد بعناية عند مزود RPC.
عند معالجة المعاملات في البورصات اللامركزية، يحتاج المستخدمون إلى تقديم عدة معلمات للعقد الذكي: الرموز التي يرغبون في تبادلها، ومبلغ التبادل، والأهم من ذلك، الحد الأدنى من عدد الرموز الذي يكون المستخدم مستعدًا لقبوله. تشير المعلمة الأخيرة إلى "الحد الأدنى الناتج" الذي يجب أن يتم الوصول إليه في التبادل، وإلا ستُلغى المعاملة. يُعرف هذا عادةً باسم "انزلاق السعر"، حيث يحدد فعليًا أقصى فرق سعر يمكن أن يحدث من إرسال المعاملة إلى تسجيلها على البلوكتشين. إذا تم تعيين انزلاق السعر بشكل منخفض جدًا، قد يحصل المستخدم على عدد قليل من الرموز، وقد يتعرض أيضًا لهجوم السندويتش.
طالما أن إعدادات الحد الأدنى من معلمات الإنتاج ضمن نطاق معقول، فلن تتعرض لهجمات السندوتش. ولكن ماذا لو لم يقدم مزود RPC الاقتباسات الدقيقة لعقد DEX الذكي؟ قد يؤدي ذلك إلى تضليل المستخدمين لتوقيع صفقات تبادل بمعلمات إنتاج دنيا منخفضة. والأسوأ من ذلك، قد يقوم المستخدمون أيضًا بإرسال المعاملات مباشرة إلى مزود RPC خبيث. يمكن لمزود الخدمة عدم بث المعاملات إلى تجمع الذاكرة العامة، ولكن بدلاً من ذلك يحتفظ بها سراً ويرسل حزمة المعاملات المهاجمة مباشرة إلى جهات محددة لتحقيق الربح.
السبب الجذري وراء هذا الهجوم هو الثقة بالآخرين للحصول على حالة البلوكتشين. لحل هذه المشكلة، يقوم المستخدمون ذوو الخبرة عادة بتشغيل عقدة إثيريوم الخاصة بهم، ولكن هذا يتطلب الكثير من الوقت والموارد، حيث تحتاج على الأقل إلى جهاز متصل بالإنترنت باستمرار، ومساحة تخزين تصل إلى مئات الجيجابايت، وحوالي يوم واحد للمزامنة من الصفر. على الرغم من أن العتبة لتشغيل العقد قد انخفضت الآن، إلا أنها لا تزال صعبة بالنسبة لمعظم المستخدمين، خاصةً أولئك الذين يستخدمون الأجهزة المحمولة.
من المهم ملاحظة أن هجمات مزودي RPC المركزيين على الرغم من أنها ممكنة تمامًا، إلا أنها عادة ما تكون مجرد هجمات تصيد بسيطة، ولم تحدث الهجمات من النوع الذي وصفناه. على الرغم من أن السجل السابق لمزودي الخدمة الرئيسيين موثوق به، إلا أنه من الحكمة إجراء المزيد من البحث قبل استخدام مزودي RPC غير المألوفين.
هيليوس: تحقيق الوصول إلى إثيريوم بدون ثقة
إثيريوم أطلقت بروتوكول العميل الخفيف، مما يفتح إمكانيات جديدة للتفاعل السريع مع البلوكتشين والتحقق من نقاط نهاية RPC بمتطلبات أجهزة أقل. بعد شهر من The Merge، تم إطلاق عدة عملاء خفيفين مستقلين، حيث اعتمدوا طرقًا مختلفة، ولكن الهدف واحد: تحقيق وصول فعال بدون ثقة دون الحاجة إلى تشغيل العقد الكاملة.
هيليوس هو عميل خفيف لإيثريوم، يمكنه إكمال المزامنة في حوالي ثانيتين، دون الحاجة إلى التخزين، ويقدم وصولاً إلى إيثريوم دون الحاجة إلى الثقة. مثل جميع عملاء إيثريوم، يحتوي هيليوس على طبقة تنفيذ وطبقة توافق. لكن على عكس معظم العملاء، يقوم هيليوس بدمج الطبقتين بشكل وثيق، مما يسمح للمستخدمين بتثبيت وتشغيل برنامج واحد فقط.
تعمل هيليوس على النحو التالي: تستخدم طبقة الإجماع تجزئة كتلة سلسلة الإشارات المعروفة، وتربطها بـ RPC غير موثوق، لمزامنة الكتل الحالية بطريقة يمكن التحقق منها. تقوم طبقة التنفيذ بدمج هذه الكتل المعروفة من سلسلة الإشارات مع RPC طبقة التنفيذ غير الموثوق بها، للتحقق من معلومات مختلفة عن حالة السلسلة، مثل أرصدة الحسابات، وتخزين العقود، وإيصالات المعاملات، ونتائج استدعاءات العقود الذكية. تعمل هذه المكونات معًا لتوفير RPC لا يتطلب الثقة بالكامل للمستخدمين، وبدون الحاجة لتشغيل عقدة كاملة.
طبقة الإجماع
يتبع العميل الخفيف في طبقة الإجماع مواصفات العميل الخفيف لسلسلة الإشارات، ويستخدم لجنة المزامنة لسلسلة الإشارات. لجنة المزامنة هي مجموعة فرعية تتكون من 512 مُصدِّق تم اختيارهم عشوائيًا، وتستمر فترة خدمتهم حوالي 27 ساعة.
بعد دخول المدققين إلى لجنة التزامن، سيقومون بتوقيع جميع رؤوس الكتل الخاصة بسلسلة الإشارات التي يرونها. إذا وقع أكثر من ثلثي أعضاء اللجنة على رأس كتلة، فمن المحتمل جدًا أن تكون تلك الكتلة ضمن سلسلة الإشارات المعتمدة. إذا كانت هليوس على دراية بتكوين لجنة التزامن الحالية، فيمكنها تتبع رأس السلسلة بشكل موثوق من خلال استعلام توقيعات لجنة التزامن الأخيرة.
بفضل تجميع توقيعات BLS، يمكن التحقق من رأس الكتلة الجديدة من خلال استعلام واحد فقط. طالما أن التوقيع صالح وأن أكثر من 2/3 من أعضاء اللجنة قد أتموا التوقيع، يمكن ضمان أن الكتلة قد تم تضمينها في السلسلة. بالطبع، يمكن أن يوفر تتبع نهائية الكتلة ضمانات أقوى.
تحتاج هذه الإستراتيجية أيضًا إلى حل مشكلة كيفية العثور على لجنة التزامن الحالية. أولاً، يجب الحصول على جذر ثقة يُعرف باسم نقطة التحقق الضعيفة. إنها تمثل تجزئة كتلة قديمة يمكن ضمان تضمينها في السلسلة في وقت ما في الماضي. فيما يتعلق بمدة وجود نقطة التحقق، تُظهر التحليلات النظرية أن أسوأ الحالات تبلغ حوالي أسبوعين، بينما قد تصل التقديرات الفعلية إلى عدة أشهر.
إذا كانت النقطة المرجعية قديمة جدًا، فمن الناحية النظرية، هناك هجوم يمكن أن يغري العقدة لمتابعة سلسلة خاطئة. في هذه الحالة، فإن الحصول على نقطة مرجعية ذات موضوعية ضعيفة يتجاوز نطاق قدرة البروتوكول. الحل من Helios هو تقديم نقطة مرجعية مبدئية، يتم ترميزها بشكل صارم في مستودع الكود ( من السهل تغطيته )، حيث ستحتفظ محليًا بأحدث تجزئة كتلة نهائية، لاستخدامها كنقطة مرجعية أثناء مزامنة العقد.
من خلال عمليات التجزئة، يمكن أن تنتج كتلة سلسلة الإشارات بسهولة تجزئة فريدة لكتلة الإشارة. وبالتالي، يمكن استعلام الكتلة الكاملة للإشارة بسهولة، ثم إثبات صحة محتوى الكتلة من خلال مقارنة التجزئات. تستفيد Helios من هذه الخاصية للحصول على والتحقق من النقاط الحرجة في كتلة نقاط الضعف الذاتية، بما في ذلك اللجنة الحالية للتزامن واللجنة التالية للتزامن. والأهم من ذلك، يمكن للعميل الخفيف الاستفادة من هذه الآلية لمراجعة تاريخ البلوكتشين بسرعة.
بعد الحصول على نقاط تفتيش ذات موضوعية ضعيفة، يمكننا الحصول على والتحقق من المجلس التزامني الحالي والمقبل. إذا كانت رأس السلسلة الحالية ونقطة التفتيش ضمن نفس دورة المجلس التزامني، يمكننا استخدام رأس المجلس التزامني الموقع للتحقق من الكتلة الجديدة على الفور. إذا كانت نقطة التفتيش تأتي بعد عدة مجالس تزامنية، يمكننا:
استخدم لجنة التزام التالية بعد نقطة التفتيش للحصول على والتحقق من الكتلة التي ستولد لجنة التزام في المستقبل.
استخدم هذه الكتلة الجديدة للحصول على لجنة المزامنة التالية.
إذا كانت نقطة التفتيش لا تزال في الخلف، ارجع إلى الخطوة 1.
من خلال العملية المذكورة أعلاه، يمكننا مراجعة تاريخ البلوكتشين بسرعة بوحدات زمنية تبلغ 27 ساعة، بدءًا من أي تجزئة كتلة من الماضي حتى المزامنة مع التجزئة الحالية للكتلة.
طبقة التنفيذ
الهدف من العميل الخفيف في طبقة التنفيذ هو استخدام رأس كتلة الإشارة الذي تم التحقق منه من خلال طبقة الإجماع مع RPC الخاص بطبقة التنفيذ غير الموثوق به، لتوفير بيانات طبقة التنفيذ الموثوقة. يمكن بعد ذلك الوصول إلى هذه البيانات عبر خادم RPC مستضاف محليًا بواسطة Helios.
فيما يلي مثال بسيط على كيفية الحصول على رصيد الحساب، أولاً نقدم بإيجاز كيفية تخزين إثيريوم للحالة. يحتوي كل حساب على عدة حقول، مثل تجزئة كود العقد، ورقم عشوائي، وتجزئة التخزين، والرصيد. يتم تخزين هذه الحسابات في شجرة ميركل-باتريشيا كبيرة معدلة، تُعرف بشجرة الحالة. طالما نعرف جذر شجرة الحالة، يمكننا التحقق من دليل ميركل، لإثبات ما إذا كان هناك أي حساب في الشجرة. لا يمكن تزوير هذا الدليل.
يستمد Helios جذر الحالة الذي تم التحقق منه من طبقة الإجماع. من خلال تطبيق هذا الجذر وطلب إثبات Merkle عبر RPC لطبقة التنفيذ غير الموثوق بها، يمكن لـ Helios التحقق محليًا من جميع البيانات المخزنة في إثيريوم.
نستخدم تقنيات مختلفة للتحقق من البيانات المتنوعة المستخدمة في طبقة التنفيذ، مما يتيح لنا التحقق من جميع البيانات القادمة من RPC غير الموثوق به. يمكن أن ترفض RPC غير الموثوق تقديم الوصول إلى البيانات، ولكن لا يمكنها تقديم نتائج خاطئة.
آفاق تطبيق هيليوس
من الشائع أن يكون من الصعب تحقيق توازن بين سهولة الاستخدام واللامركزية. من خلال Helios الخفيف الوزن، يمكن للمستخدمين الوصول إلى بيانات السلسلة الآمنة من أي جهاز ( بما في ذلك الهواتف المحمولة وإضافات المتصفح ). سيمكن ذلك المزيد من الناس من الوصول إلى بيانات إثيريوم بدون حاجة للثقة، بغض النظر عن الأجهزة المستخدمة. يمكن للمستخدمين استخدام Helios كمزود RPC في المحفظة للوصول إلى مجموعة متنوعة من DApp بدون حاجة للثقة، وكل ذلك دون أي تغييرات أخرى.
بالإضافة إلى ذلك، فإن دعم Rust لـ WebAssembly يمكّن مطوري التطبيقات من دمج Helios بسهولة في تطبيقات Javascript ( مثل المحافظ وDApp ). ستعزز هذه التكاملات من أمان إثيريوم، وتقلل من اعتمادنا على البنية التحتية المركزية.
يمكن للمجتمع المساهمة في Helios بطرق متعددة، بالإضافة إلى تحسين مكتبة الشيفرات، يمكن أيضًا بناء برامج تتكامل مع Helios للاستفادة من مزاياه. فيما يلي بعض الاتجاهات المحتملة للتطوير: