a16z Crypto أطلقت Helios العميل الخفيف: تحقيق الوصول إلى إثيريوم بدون ثقة حقيقية
في 8 نوفمبر 2023، أصدرت a16z Crypto العميل الخفيف Helios لإثيريوم، وهي أداة تم تطويرها بلغة Rust تهدف إلى توفير قدرة الوصول إلى شبكة إثيريوم بالكامل دون الحاجة إلى الثقة.
تتمثل إحدى القيم الأساسية لتقنية البلوكشين في تمكين المستخدمين من عدم الاعتماد على الثقة من الأطراف الثالثة، وبالتالي السيطرة الحقيقية على ثرواتهم وبياناتهم. لقد حققت بلوكشينات مثل إثيريوم إلى حد كبير هذا الالتزام، مما يضمن أن أصولنا تعود حقًا لنا.
ومع ذلك ، من أجل الراحة ، يقدم معظم المستخدمين بعض التنازلات عند استخدام blockchain. أحد أكثر التنازلات وضوحا هو الاعتماد على المكالمات المركزية RPC( عن بعد ) الخوادم. عادة ما يصل المستخدمون إلى شبكة Ethereum من خلال بعض مزودي الخدمة المركزيين. تقوم هذه الشركات بتشغيل عقد عالية الأداء على الخوادم السحابية لمساعدة المستخدمين على الوصول بسهولة إلى البيانات على السلسلة. عندما تستفسر المحفظة عن رصيد رمز مميز أو تتحقق من حالة المعاملة ، يتم ذلك دائما تقريبا من خلال هذه الخدمات المركزية.
تكمن المشكلة الرئيسية في النظام الحالي في أن المستخدمين يجب أن يثقوا في هؤلاء المزودين، ولا يمكنهم التحقق من دقة المعلومات التي يحصلون عليها بأنفسهم.
هيليوس: عميل خفيف وقابل للتحقق تمامًا
هيليوس كعميل خفيف مبني على روست لإثيريوم، قادر على توفير وصول سهل إلى البلوكشين دون التضحية بالأمان. يستخدم بروتوكول العميل الخفيف الذي تم تحقيقه بعد تحول إثيريوم إلى PoS، لتحويل البيانات القادمة من موفري RPC مركزيين غير موثوقين إلى RPC محلي آمن وقابل للتحقق. من خلال التعاون مع RPC مركزي، يمكن لهيليوس التحقق من صحة البيانات دون الحاجة إلى تشغيل عقدة كاملة.
يمكن لهذا العميل الخفيف إكمال المزامنة في حوالي ثانيتين، دون الحاجة إلى مساحة تخزين إضافية، ويمكن للمستخدمين الوصول بأمان إلى البيانات على السلسلة من أي جهاز ( بما في ذلك الهواتف المحمولة وإضافات المتصفح ).
المخاطر المحتملة للبنية التحتية المركزية
تتواجد مخاطر نظرية في "الغابة المظلمة" لإثيريوم. هذه المخاطر لا تأتي من هجمات التشغيل الأمامية في تجمع معاملات (Mempool)، بل من خلال محاكاة الفخاخ التي تعتمد على البنية التحتية المركزية التي نعتمد عليها.
قد لا يكون المستخدمون الذين يتعرضون لمثل هذه الهجمات قد ارتكبوا أي خطأ: إنهم فقط يقومون بزيارة DEX المستخدمة بشكل شائع، وضبطوا انزلاقًا معقولًا، وأجروا معاملات رمزية طبيعية. ومع ذلك، قد يواجهون هجوم ساندويتش خاص، والذي يكمن عند مدخل الوصول إلى إثيريوم - مزودي RPC.
عندما ينفذ المستخدم معاملة على DEX ، يتم توفير العديد من المعلمات للعقد الذكي: الرمز المميز المراد تداوله ، وعدد المعاملات ، والحد الأدنى لعدد الرموز المميزة التي يرغب المستخدم في قبولها ( ، أي ) الانزلاق. إذا تم ضبط الانزلاق بشكل صحيح ، فلن يعاني المستخدم نظريا من هجوم شطيرة. ولكن ماذا لو لم يقدم مزود RPC عرض أسعار دقيق لعقد DEX؟ قد يتم تضليل المستخدمين لتوقيع المعاملات بحد أدنى أقل من القبول. ومما زاد الطين بلة ، قد يرسل المستخدمون المعاملات مباشرة إلى مزودي RPC الخبيثين ، الذين يمكنهم الاحتفاظ بهذه المعاملات بشكل خاص وإرسالها مباشرة إلى حظر المنتجين من خلال قنوات محددة لتحقيق الربح.
السبب الجذري لهذا النوع من الهجمات هو أن المستخدمين يحتاجون إلى الاعتماد على طرف ثالث للحصول على حالة البلوكشين. لمعالجة هذه المشكلة، يختار المستخدمون ذوو الخبرة عادةً تشغيل عقدة إثيريوم الخاصة بهم، ولكن هذا يتطلب استثمارًا كبيرًا من الوقت والموارد: يحتاج إلى جهاز متصل بالإنترنت باستمرار، ومساحة تخزين تتجاوز مئات الجيجابايت، وحوالي يوم واحد للتزامن. على الرغم من أن هذه العملية قد تم تبسيطها كثيرًا مقارنة بالماضي، إلا أنها لا تزال صعبة التحقيق بالنسبة لمعظم المستخدمين، خاصة لمستخدمي الأجهزة المحمولة.
وتجدر الإشارة إلى أنه في حين أن هجوم مزود RPC المركزي ممكن من الناحية النظرية ، إلا أنه لم يتم العثور على مزودين كبار ومعروفين لديهم مثل هذا السلوك. ومع ذلك ، من المهم إجراء البحث قبل إضافة مزود RPC غير مألوف إلى محفظتك.
كيفية عمل هيليوس: تحليل عميق
أدى إدخال Ethereum لبروتوكول العميل الخفيف إلى خلق إمكانيات جديدة لتفاعلات blockchain السريعة والتحقق من نقاط نهاية RPC مع الحد الأدنى من متطلبات الأجهزة. في غضون شهر من (The Merge) الاندماج ، ظهر عدد من مشاريع العملاء الخفيفة المنفصلة ، (Lodestar و Nimbus و Kevlar) المستندة إلى JavaScript ، ولكل منها نهج مختلف. لكنهم جميعا يعملون لتحقيق نفس الهدف: توفير وصول فعال وموثوق به دون تشغيل عقدة كاملة.
هيلوس، مثل جميع عملاء إيثريوم، يتكون من طبقة التنفيذ وطبقة التوافق. لكن على عكس معظم العملاء، يدمج هيلوس هاتين الطبقتين بشكل وثيق، حيث يحتاج المستخدم فقط لتثبيت وتشغيل برنامج واحد.
طبقة الإجماع
يتبع العميل الخفيف لطبقة الإجماع في هليوس معايير العميل الخفيف لسلسلة الإشارة، مستفيدًا من لجنة التزامن لسلسلة الإشارة ( التي تم تقديمها في الشوكة الصلبة ألتير. تتكون لجنة التزامن من مجموعة من 512 مدققًا يتم اختيارهم عشوائيًا، وتكون فترة الخدمة حوالي 27 ساعة.
المتحققون في لجنة التزامن سيقومون بالتوقيع على جميع رؤوس كتل سلسلة الإشارة التي يرونها. إذا قام أكثر من ثلثي أعضاء اللجنة بالتوقيع على رأس الكتلة، فإن هذه الكتلة ستكون تقريبًا موجودة في سلسلة الإشارة القياسية. عندما يفهم Helios تركيبة لجنة التزامن الحالية، يمكنه تتبع رأس السلسلة بشكل موثوق من خلال استعلام توقيعات لجنة التزامن الأخيرة.
بفضل تقنية تجميع توقيعات BLS، يكفي استعلام واحد لإكمال التحقق من رأس الكتلة الجديدة. طالما أن التوقيع صالح وأن أكثر من ثلثي أعضاء اللجنة قد وقعوا، يمكن ضمان أن هذه الكتلة قد تم تضمينها في السلسلة.
يحتاج النظام أولاً إلى الحصول على نقطة فحص ضعف الموضوعية )weak subjectivity checkpoint( كمصدر موثوق. هذه نقطة يتم ضمان أنها قد تم تضمينها في سلسلة الكتل في لحظة ما في الماضي. باستخدام هذه النقطة، يمكن لـ Helios الحصول على والتحقق من اللجنة التزامنية الحالية والتالية، مما يسمح بمراجعة تاريخ سلسلة الكتل بسرعة ومزامنة إلى أحدث كتلة.
) طبقة التنفيذ
هدف العميل الخفيف في طبقة التنفيذ هو الجمع بين رأس كتلة الإشارة الذي تم التحقق منه بواسطة طبقة الإجماع وRPC طبقة التنفيذ غير الموثوق به، لتوفير بيانات طبقة التنفيذ التي تم التحقق منها. ثم يتم الوصول إلى هذه البيانات عبر خادم RPC المستضاف محليًا باستخدام Helios.
إثيريوم من خلال شجرة الحالة تخزن معلومات الحساب، بما في ذلك تجزئة كود العقد، الرقم العشوائي، تجزئة التخزين والرصيد. طالما أنه معروف جذر شجرة الحالة، يمكن التحقق من إثبات ميركل، لإثبات ما إذا كانت هناك أي حسابات في الشجرة، هذا الإثبات لا يمكن تزويره.
يستخرج هيليوس جذر الحالة المعتمد من طبقة الإجماع، ويجمعه مع طلب إثبات ميركل لطبقة التنفيذ غير الموثوق بها، لتحقيق التحقق المحلي من جميع البيانات المخزنة على إثيريوم. وبهذه الطريقة، يمكن لـ RPC غير الموثوق به رفض تقديم الوصول إلى البيانات، ولكن لا يمكنه تقديم نتائج خاطئة.
التطبيقات العملية لـ Helios
تصميم هليوس الخفيف الوزن يسمح للمستخدمين بالوصول بأمان إلى البيانات على السلسلة من أي جهاز ### بما في ذلك الهواتف المحمولة وإضافات المتصفح (. يمكن للمستخدمين إعداد هليوس كمزود RPC في ميتاماسك، دون الحاجة إلى أي تغييرات أخرى للوصول إلى مجموعة متنوعة من التطبيقات اللامركزية بطريقة غير موثوقة.
علاوة على ذلك، فإن دعم Rust الجيد لـ WebAssembly يمكّن مطوري التطبيقات من دمج Helios بسهولة في تطبيقات JavaScript ) مثل المحافظ وDApp (. ستعزز هذه التكاملات من أمان إثيريوم، وتقلل من الاعتماد على الثقة في البنية التحتية المركزية.
يمكن للمجتمع المساهمة في Helios بعدة طرق ، بما في ذلك:
يدعم الحصول على بيانات العميل الخفيف مباشرة من شبكة P2P
تنفيذ طرق RPC المفقودة
بناء نسخة هليوس القابلة للتجميع إلى WebAssembly
دمج Helios مباشرة في برنامج المحفظة
بناء لوحة تحكم الشبكة لعرض رصيد الرموز
ربط طبقة الإجماع Helios بالعقدة الكاملة لطبقة التنفيذ الحالية
تم فتح كود هذا المشروع المصدر، ونرحب بالمطورين المهتمين بالمشاركة في المساهمة.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
a16z أطلق العميل الخفيف Helios: حل جديد للوصول إلى إثيريوم بدون ثقة
a16z Crypto أطلقت Helios العميل الخفيف: تحقيق الوصول إلى إثيريوم بدون ثقة حقيقية
في 8 نوفمبر 2023، أصدرت a16z Crypto العميل الخفيف Helios لإثيريوم، وهي أداة تم تطويرها بلغة Rust تهدف إلى توفير قدرة الوصول إلى شبكة إثيريوم بالكامل دون الحاجة إلى الثقة.
تتمثل إحدى القيم الأساسية لتقنية البلوكشين في تمكين المستخدمين من عدم الاعتماد على الثقة من الأطراف الثالثة، وبالتالي السيطرة الحقيقية على ثرواتهم وبياناتهم. لقد حققت بلوكشينات مثل إثيريوم إلى حد كبير هذا الالتزام، مما يضمن أن أصولنا تعود حقًا لنا.
ومع ذلك ، من أجل الراحة ، يقدم معظم المستخدمين بعض التنازلات عند استخدام blockchain. أحد أكثر التنازلات وضوحا هو الاعتماد على المكالمات المركزية RPC( عن بعد ) الخوادم. عادة ما يصل المستخدمون إلى شبكة Ethereum من خلال بعض مزودي الخدمة المركزيين. تقوم هذه الشركات بتشغيل عقد عالية الأداء على الخوادم السحابية لمساعدة المستخدمين على الوصول بسهولة إلى البيانات على السلسلة. عندما تستفسر المحفظة عن رصيد رمز مميز أو تتحقق من حالة المعاملة ، يتم ذلك دائما تقريبا من خلال هذه الخدمات المركزية.
تكمن المشكلة الرئيسية في النظام الحالي في أن المستخدمين يجب أن يثقوا في هؤلاء المزودين، ولا يمكنهم التحقق من دقة المعلومات التي يحصلون عليها بأنفسهم.
هيليوس: عميل خفيف وقابل للتحقق تمامًا
هيليوس كعميل خفيف مبني على روست لإثيريوم، قادر على توفير وصول سهل إلى البلوكشين دون التضحية بالأمان. يستخدم بروتوكول العميل الخفيف الذي تم تحقيقه بعد تحول إثيريوم إلى PoS، لتحويل البيانات القادمة من موفري RPC مركزيين غير موثوقين إلى RPC محلي آمن وقابل للتحقق. من خلال التعاون مع RPC مركزي، يمكن لهيليوس التحقق من صحة البيانات دون الحاجة إلى تشغيل عقدة كاملة.
يمكن لهذا العميل الخفيف إكمال المزامنة في حوالي ثانيتين، دون الحاجة إلى مساحة تخزين إضافية، ويمكن للمستخدمين الوصول بأمان إلى البيانات على السلسلة من أي جهاز ( بما في ذلك الهواتف المحمولة وإضافات المتصفح ).
المخاطر المحتملة للبنية التحتية المركزية
تتواجد مخاطر نظرية في "الغابة المظلمة" لإثيريوم. هذه المخاطر لا تأتي من هجمات التشغيل الأمامية في تجمع معاملات (Mempool)، بل من خلال محاكاة الفخاخ التي تعتمد على البنية التحتية المركزية التي نعتمد عليها.
قد لا يكون المستخدمون الذين يتعرضون لمثل هذه الهجمات قد ارتكبوا أي خطأ: إنهم فقط يقومون بزيارة DEX المستخدمة بشكل شائع، وضبطوا انزلاقًا معقولًا، وأجروا معاملات رمزية طبيعية. ومع ذلك، قد يواجهون هجوم ساندويتش خاص، والذي يكمن عند مدخل الوصول إلى إثيريوم - مزودي RPC.
عندما ينفذ المستخدم معاملة على DEX ، يتم توفير العديد من المعلمات للعقد الذكي: الرمز المميز المراد تداوله ، وعدد المعاملات ، والحد الأدنى لعدد الرموز المميزة التي يرغب المستخدم في قبولها ( ، أي ) الانزلاق. إذا تم ضبط الانزلاق بشكل صحيح ، فلن يعاني المستخدم نظريا من هجوم شطيرة. ولكن ماذا لو لم يقدم مزود RPC عرض أسعار دقيق لعقد DEX؟ قد يتم تضليل المستخدمين لتوقيع المعاملات بحد أدنى أقل من القبول. ومما زاد الطين بلة ، قد يرسل المستخدمون المعاملات مباشرة إلى مزودي RPC الخبيثين ، الذين يمكنهم الاحتفاظ بهذه المعاملات بشكل خاص وإرسالها مباشرة إلى حظر المنتجين من خلال قنوات محددة لتحقيق الربح.
السبب الجذري لهذا النوع من الهجمات هو أن المستخدمين يحتاجون إلى الاعتماد على طرف ثالث للحصول على حالة البلوكشين. لمعالجة هذه المشكلة، يختار المستخدمون ذوو الخبرة عادةً تشغيل عقدة إثيريوم الخاصة بهم، ولكن هذا يتطلب استثمارًا كبيرًا من الوقت والموارد: يحتاج إلى جهاز متصل بالإنترنت باستمرار، ومساحة تخزين تتجاوز مئات الجيجابايت، وحوالي يوم واحد للتزامن. على الرغم من أن هذه العملية قد تم تبسيطها كثيرًا مقارنة بالماضي، إلا أنها لا تزال صعبة التحقيق بالنسبة لمعظم المستخدمين، خاصة لمستخدمي الأجهزة المحمولة.
وتجدر الإشارة إلى أنه في حين أن هجوم مزود RPC المركزي ممكن من الناحية النظرية ، إلا أنه لم يتم العثور على مزودين كبار ومعروفين لديهم مثل هذا السلوك. ومع ذلك ، من المهم إجراء البحث قبل إضافة مزود RPC غير مألوف إلى محفظتك.
كيفية عمل هيليوس: تحليل عميق
أدى إدخال Ethereum لبروتوكول العميل الخفيف إلى خلق إمكانيات جديدة لتفاعلات blockchain السريعة والتحقق من نقاط نهاية RPC مع الحد الأدنى من متطلبات الأجهزة. في غضون شهر من (The Merge) الاندماج ، ظهر عدد من مشاريع العملاء الخفيفة المنفصلة ، (Lodestar و Nimbus و Kevlar) المستندة إلى JavaScript ، ولكل منها نهج مختلف. لكنهم جميعا يعملون لتحقيق نفس الهدف: توفير وصول فعال وموثوق به دون تشغيل عقدة كاملة.
هيلوس، مثل جميع عملاء إيثريوم، يتكون من طبقة التنفيذ وطبقة التوافق. لكن على عكس معظم العملاء، يدمج هيلوس هاتين الطبقتين بشكل وثيق، حيث يحتاج المستخدم فقط لتثبيت وتشغيل برنامج واحد.
طبقة الإجماع
يتبع العميل الخفيف لطبقة الإجماع في هليوس معايير العميل الخفيف لسلسلة الإشارة، مستفيدًا من لجنة التزامن لسلسلة الإشارة ( التي تم تقديمها في الشوكة الصلبة ألتير. تتكون لجنة التزامن من مجموعة من 512 مدققًا يتم اختيارهم عشوائيًا، وتكون فترة الخدمة حوالي 27 ساعة.
المتحققون في لجنة التزامن سيقومون بالتوقيع على جميع رؤوس كتل سلسلة الإشارة التي يرونها. إذا قام أكثر من ثلثي أعضاء اللجنة بالتوقيع على رأس الكتلة، فإن هذه الكتلة ستكون تقريبًا موجودة في سلسلة الإشارة القياسية. عندما يفهم Helios تركيبة لجنة التزامن الحالية، يمكنه تتبع رأس السلسلة بشكل موثوق من خلال استعلام توقيعات لجنة التزامن الأخيرة.
بفضل تقنية تجميع توقيعات BLS، يكفي استعلام واحد لإكمال التحقق من رأس الكتلة الجديدة. طالما أن التوقيع صالح وأن أكثر من ثلثي أعضاء اللجنة قد وقعوا، يمكن ضمان أن هذه الكتلة قد تم تضمينها في السلسلة.
يحتاج النظام أولاً إلى الحصول على نقطة فحص ضعف الموضوعية )weak subjectivity checkpoint( كمصدر موثوق. هذه نقطة يتم ضمان أنها قد تم تضمينها في سلسلة الكتل في لحظة ما في الماضي. باستخدام هذه النقطة، يمكن لـ Helios الحصول على والتحقق من اللجنة التزامنية الحالية والتالية، مما يسمح بمراجعة تاريخ سلسلة الكتل بسرعة ومزامنة إلى أحدث كتلة.
) طبقة التنفيذ
هدف العميل الخفيف في طبقة التنفيذ هو الجمع بين رأس كتلة الإشارة الذي تم التحقق منه بواسطة طبقة الإجماع وRPC طبقة التنفيذ غير الموثوق به، لتوفير بيانات طبقة التنفيذ التي تم التحقق منها. ثم يتم الوصول إلى هذه البيانات عبر خادم RPC المستضاف محليًا باستخدام Helios.
إثيريوم من خلال شجرة الحالة تخزن معلومات الحساب، بما في ذلك تجزئة كود العقد، الرقم العشوائي، تجزئة التخزين والرصيد. طالما أنه معروف جذر شجرة الحالة، يمكن التحقق من إثبات ميركل، لإثبات ما إذا كانت هناك أي حسابات في الشجرة، هذا الإثبات لا يمكن تزويره.
يستخرج هيليوس جذر الحالة المعتمد من طبقة الإجماع، ويجمعه مع طلب إثبات ميركل لطبقة التنفيذ غير الموثوق بها، لتحقيق التحقق المحلي من جميع البيانات المخزنة على إثيريوم. وبهذه الطريقة، يمكن لـ RPC غير الموثوق به رفض تقديم الوصول إلى البيانات، ولكن لا يمكنه تقديم نتائج خاطئة.
التطبيقات العملية لـ Helios
تصميم هليوس الخفيف الوزن يسمح للمستخدمين بالوصول بأمان إلى البيانات على السلسلة من أي جهاز ### بما في ذلك الهواتف المحمولة وإضافات المتصفح (. يمكن للمستخدمين إعداد هليوس كمزود RPC في ميتاماسك، دون الحاجة إلى أي تغييرات أخرى للوصول إلى مجموعة متنوعة من التطبيقات اللامركزية بطريقة غير موثوقة.
علاوة على ذلك، فإن دعم Rust الجيد لـ WebAssembly يمكّن مطوري التطبيقات من دمج Helios بسهولة في تطبيقات JavaScript ) مثل المحافظ وDApp (. ستعزز هذه التكاملات من أمان إثيريوم، وتقلل من الاعتماد على الثقة في البنية التحتية المركزية.
يمكن للمجتمع المساهمة في Helios بعدة طرق ، بما في ذلك:
تم فتح كود هذا المشروع المصدر، ونرحب بالمطورين المهتمين بالمشاركة في المساهمة.