المؤلف: Shew, Xianyang GodRealmX
يعد السائل الفائق أحد أكثر السوائل تأثيرًا. لقد تجاوزت عمليات تبادل كتب الطلبات عبر السلسلة 2 مليار دولار أمريكي، بينما تم تقييمها على أنها "Binance على السلسلة" من قبل Messari، فقد تضمنت الطبقة الثالثة وسلاسل التطبيقات التي تلاشت بعيدًا عن أعين الجمهور العودة إلى دائرة الضوء. مع الإنجاز الرائع المتمثل في رفع قيمة FDV إلى 30 مليار دولار أمريكي في غضون شهر واحد من إطلاق Token، اكتسب Hyperliquid اهتمامًا واسع النطاق من المستخدمين العاديين إلى الممارسين. وفي الوقت نفسه، ظهر عدد كبير من التقارير البحثية حول Hyperliquid في السوق، ولكن هذه التقارير لا تزال قيد الاستخدام تركز المقالات بشكل أساسي على ميزاته من أجل حجز وظائف المنتج وآليات التداول، ولم تتعمق في البنية الفنية والمخاطر الأمنية الكامنة وراءه.
يهدف مؤلف هذا المقال إلى سد هذه الفجوة وفحص Hyperliquid بشكل بحت من منظور البنية التقنية والسلامة، لمساعدة المزيد من الأشخاص على فهم هذا النجم هيكل المشروع ومبادئه. سنتناول بالتفصيل الهيكل والمخاطر الخفية لعقد الجسر عبر السلسلة Hyperliquid وهيكل السلسلة المزدوجة HyperEVM وHyperL1 لمساعدة الجميع على فهم البنية التقنية والتنفيذ الكامن وراءها.
(يمثل Hyperliquid حاليًا 67% من إجمالي عرض USDC على Arbitrum)
تحليل الجسر عبر سلسلة HyperLiquid
نظرًا لأن HyperLiquid لا يحتوي على مكونات أساسية مفتوحة المصدر، ولكنه مفتوح المصدر مصادر عقود الجسور ذات الصلة،لذلك لدينا فهم أفضل للمخاطر فيما يتعلق بعقود الجسور. قامت Hyperliquid بنشر عقد جسر على Arbitrum لتخزين أصول USDC المودعة من قبل المستخدمين. يمكننا رؤية جزء من سلوك عقدة Hyperliquid في مكون Bridge.
مجموعة أدوات التحقق
من منظور تقسيم هوية العقدة يبدو أن Hyperliquid لديه 4 مجموعات من أدوات التحقق من الصحة، وهي hotValidatorSet
، وcoldValidatorSet
، وfinalizers
وlockers
، المتوافقة مع وظائف مختلفة. من بينها، يتم استخدام hotValidatorSet للرد على السلوكيات عالية التردد مثل عمليات سحب المستخدم. تُستخدم المحافظ الساخنة بشكل عام للرد على طلبات السحب الخاصة بمستخدمي Hyperliquid في أي وقت.
وcoldValidatorSet
يُستخدم بشكل أساسي لتعديل تكوين النظام، مثل إعادة كتابة hotValidatorSet
أو تنتظر lockers
قائمة مجموعات أدوات التحقق من الصحة، أو تتعامل مع حالة القفل لعقد الجسر، ويحق لـ coldValidatorSet
إبطال طلبات سحب معينة بشكل مباشر.
و lockers
عبارة عن مجموعة من المحققين ذوي أذونات خاصة، تشبه "اللجنة الأمنية" التي تستخدمها Layer2، والتي سيتم استخدامها في بعض حالات الطوارئ، في حالة حدوث مشكلة، يتم استخدام التصويت لتحديد ما إذا كان سيتم تعليق تشغيل الجسر عبر السلسلة. حاليًاالسائل الزائدخزاناتالجسر
> تحتوي المجموعة على5 عناوين، ولا يلزم سوى صوتين للخزانةلتعليقإتمام العقدالعملية.
أما بالنسبة إلى finalizers
، فهي في الواقع مجموعة من أدوات التحقق الخاصة، تُستخدم بشكل أساسي لتأكيد تغييرات الحالة للجسور عبر السلسلة. من منظور العقد، التأكيدات الرئيسية هي المستخدم الودائع والسحوبات. يستخدم جسر Hyperliquid عبر السلسلة"إرسال التأكيد"آلية > ،على سبيل المثال، المستخدمالذي يبدأالسحب لنيتمتنفيذه على الفور ,< /strong>عليك الانتظار لفترة من الوقت (هذه الفترة تسمى فترة النزاع). بعد الانتظار حتى انتهاء فترة النزاع، يقوم الأعضاء ضمن المتأهلين
بتنفيذ معاملة السحبوسحب الأموال< /strong>< strong>يمكنتنفيذه بشكل طبيعي.
بمجرد وجود مشكلة في الجسر عبر السلسلة، على سبيل المثال، يعلن بيان سحب معين أن الأصول المراد سحبها أكبر من رصيد الأصول الفعلي مملوكة للمستخدم، يمكن لعقد Hyperliquid خلال فترة النزاع استخدام lockers
للتصويت لتعليق تشغيل عقد الجسر عبر السلسلة، أو استخدام coldValidatorSet
لإبطال مباشرة طلب سحب إشكالي.
يحتوي Hyperliquid حاليًا على 4 عقد تحقق فقط، لذا فإن hotValidatorSet
وcoldValidatorSet
يتوافقان فقط مع 4 سلاسل عنوان. أثناء التهيئة، يقوم Hyperliquid تلقائيًا بتسجيل العناوين في hotValidatorSet
كأعضاء في lockers
وfinalizers
، بينما coldValidatorSet
هو Hyperliquid رسميًا يتحكم فيه بنفسه ويستخدم المحافظ الباردة لتخزين المفاتيح.
الإيداع
يعتمد عقد جسر Hyperliquid على EIP- 2612 يتم استخدام طريقة التصريح لمعالجة عملية إيداع المستخدم، ولا يسمح عقد الجسر إلا للمستخدمين بإيداع USDC كأصل. بالمقارنة مع وضع الموافقة والنقل التقليدي، يعد التصريح أبسط وأسهل لدعم العمليات المجمعة.
يستخدم عقد الجسر الخاص بـ Hyperliquid وظيفة batchedDepositWithPermit
لمعالجة الودائع المتعددة بشكل مجمع، إجراء الإيداع هنا بسيط نسبيًا ولا يوجد أمان للصندوق بالنسبة للمخاطر، فإن عملية المعالجة بسيطة للغاية، فقط باستخدام طريقة التصريح لتحسين تجربة المستخدم.
السحب
بالمقارنة مع الإيداع، يعد السحب عملية خطيرة للغاية، وبالتالي فإن منطق السحب سيكون أعلى من منطق السحب. الإيداع الأمر أكثر تعقيدًا. عندما يبدأ المستخدم طلب سحب، ستستدعي عقدة Hyperliquid وظيفة batchedRequestWithdrawals
الخاصة بعقد الجسر. في هذه المرحلةسوف يكون عقد الجسريتطلب كل عملية سحبطلبيجب نجتمع معًاح otValidatorSet
's2/3وزن التوقيع،لاحظ أن العديد من المستندات تصفه هنا على أنه "Set 2 / 3 توقيع"، ولكن في الواقع يتحقق عقد الجسر من "وزن التوقيع 2/3". حاليًا، يحتوي HyperLiquid على 4 عقد بنفس الوزن، لذا فإن التحقق من وزن التوقيع والتحقق من عدد التوقيعات متماثلان مؤقتًا، ولكن في المستقبل، قد يقدم HyperLiquid عقدًا ذات أوزان عالية.
عند بدء طلب السحب، لن يقوم الجسر عبر السلسلة بنقل العقد الخاضع للرقابة تم نقل USDC، ولكن هناك " فترة النزاع " ، على غرار إثبات الاحتيال " فترة التحدي" في الاتفاقية. فترة النزاع الحالية لعقد جسر Hyperliquid هي 200 ثانية. وقد تحدث حالتان خلال فترة النزاع:
1.lockers
يعتقد. توجد حاليًا مشكلات خطيرة في طلب السحب، ويمكنك التصويت مباشرةً لتعليق/تجميد العقد؛
2 هناك مشاكل في بعض سلوكيات الانسحاب في هذا الوقت، يمكن للأعضاء الاتصال تعمل وظيفة invalidateWithdrawals
على إبطال عملية السحب.
إذا لم تنشأ أية مشكلات أثناء فترة النزاع،بعدانتهاء فترة النزاع،النهائيات
الأعضاء في يمكنهم الاتصال بـ < في عقد الجسر كود>دفعاتFinalizeWithdrawalsالوظيفةلوضعوضع اللمسات الأخيرةالنهائيمن >الحالة، سيتم نقل USDC إلى عنوان محفظة المستخدم في Arbitrum فقط بعد تشغيل هذه الوظيفة.
لذلك من منظور نموذج الأمان، إذا كان هناكمهاجم ضاريريد استخدام عملية السحب الخاصة بـ Hyperliquid للقيام بذلك الحيل ، فقط تحتاج إلى اختراق ثلاثة خطوط دفاع:
1. إتقان 2/3 من أوزان التوقيع في hotValidatorSet
. بمعنى آخر، تحتاج إلى الحصول على عدد معين من المفاتيح الخاصة أو التواطؤ؛ حاليًا يحتوي HyperLiquid على 4 أدوات تحقق فقط، وهي إمكانية التحكم فيها أو التلاعب بها من قبل المهاجمين ليست منخفضة؛
2. خلال فترة النزاع، يجب على المهاجم تجنب اكتشاف معاملاته الضارة مرة واحدة تم اكتشافه، فمن المحتمل جدًا أن يتسبب lockers
في قفل العقد. وسوف نناقش هذا الجزء على وجه التحديد أدناه.
3. احصل على المفتاح الخاص لعضو واحد على الأقل من أعضاء finalizers
حتى يمكن تأكيد سلوك السحب الخاص بك أخيرًا. حاليًا، أعضاء finalizers
هم في الأساس نفس أعضاء hotValidatorSet
، لذا طالما أن المهاجم يستوفي الشرط 1 أعلاه، فسيتم استيفاء الشرط 3 تلقائيًا.
عقد قفل الجسر
لقد ذكرنا تم ذلك عدة مرات قبل أن يقوم Now Hyperliquid بإعداد وظيفة لتأمين عقود الجسر عبر السلسلة. على وجه التحديد، يتطلب تأمين الجسر عبر السلسلةالخزائن
من الأعضاء الاتصال بعقد الجسر عبر السلسلة strong>وظيفةvoteEmergencyLock
تجريالتصويت< /strong>< strong>، يعمل حاليًا باعتباره الثاني الخزائن
اتصلبالوظيفةالمقدمة > قوي>بعد التصويت، سيتم إغلاق عقد الجسر عبر السلسلةوتعليقه >.
ولكن تجدر الإشارة إلى أن الجسر عبر السلسلة الخاص بـ HyperLiquid يوفر أيضًا وظيفة unvoteEmergencyLock
، مما يسمح بخزائن
code>عضو يسحب صوته. بمجرد قفل عقد الجسر عبر السلسلة بنجاح، لا يمكن فتحه إلا من خلال وظيفة تسمى emergencyUnlock
، والتي تتطلب جمع أكثر من ثلثي أوزان توقيع coldValidatorSet
. أعضاء.
emergencyUnlock
ستعمل أيضًا على إدخال hotValidatorSet
وcoldValidatorSet الجديدتين أثناء فتح
A مجموعة عناوين المدقق وسيتم تحديثها على الفور.
تحديث مجموعة التحقق
مقارنة بمحاولة اختراق خطوط الدفاع الحالية في عملية الانسحاب، هناك طريقة هجوم أفضل هو الاستخدام المباشر تعمل وظيفة updateValidatorSet
على تحديث مجموعات أدوات التحقق من hotValidatorSet
وcoldValidatorSet
. يتطلب هذا من المتصل تقديم توقيعات جميع أعضاء hotValidatorSet
، وتشتمل العملية على فترة نزاع مدتها 200 ثانية.
عندما تنتهي فترة النزاع، يحتاج عضو finalizers
إلى استدعاء وظيفة finalizeValidatorSetUpdate
لإكمال المرحلة النهائية تحديث الحالة.
لقد قدمنا حتى الآن معظم تفاصيل جسر Hyperliquid عبر السلسلة. لا تقدم هذه المقالة منطق التحديث الخاص بـ lockers
وfinalizers
. تتطلب تحديثات كليهما توقيع hotValidatorSet
، وتتطلب إزالة عضو معين coldValidatorSet
.
باختصار، يحتوي عقد الجسر الخاص بـ Hyperliquid على المخاطر التالية:
1. بعد سيطرة المتسللين على coldValidatorSet
، يمكنهم تجاهل أي عائق وسرقة أصول المستخدم. نظرًا لأن coldValidatorSet
لديه إذن التشغيل لوظيفة emergencyUnlock
، فيمكنه إبطال إجراء القفل الخاص بـ lockers
في عقد الجسر وتحديثه قائمة العقدة في الوقت الحقيقي. في الوقت الحالي، لا يوجد سوى 4 عقد تحقق في Hyperliquid، واحتمال سرقة المفتاح الخاص ليس منخفضًا؛
2. يرفض .finalizers
إنهاء معاملة السحب الخاصة بالمستخدم ويطلق هجومًا رقابيًا؛ وفي هذه الحالة، لن يتم سرقة أصول المستخدم، ولكن قد لا يتمكن المستخدم من سحب الأموال من عقد الجسر؛
3.lockers الجسر عبر السلسلة بشكل ضار. في هذا الوقت، لا يمكن تنفيذ جميع معاملات السحب ويمكنها فقط الانتظار حتى يتم إلغاء قفل coldValidatorSet
؛< /p>
HyperEVM وبنية التفاعل ثنائية السلسلة
من أجل جعل معاملات دفتر الطلبات قابلة للبرمجة، مثل تقديم المعاملات الخاصة والسيناريوهات الأخرى التي تتطلب تنفيذ العقود الذكية، أطلقت Hyperliquid برنامجًا يسمى HyperEVM< قوي>خطة. يتمتع بميزتين خاصتين مقارنةً بـ EVM التقليدي: أولاً، يمكن لـ HyperEVM قراءة حالة دفتر طلبات HyperLiquid، وثانيًا، يمكن للعقد الذكي في HyperEVM أن يتفاعل مع نظام دفتر طلبات Hyperliquid، مما يوسع سيناريوهات تطبيق Hyperliquid بشكل كبير.
لإعطاء مثال بسيط، إذا كان المستخدم يحتاج إلى ضمان خصوصية عملية الطلب المعلق، فيمكن تنفيذ طبقة من الخصوصية على HyperEVM من خلال عقد ذكي على غرار Tornado Cash، قم بتشغيل إجراء الطلب المعلق في نظام دفتر الطلبات الخاص بـ HyperLiquid من خلال واجهة محددة.
قبل تقديم HyperEVM، نحتاج إلى تقديم البنية الخاصة التي أعدتها Hyperliquid لـ HyperEVM. نظرًا لأن Hyperliquid يحتوي على نظام دفتر طلبات مخصص عالي الأداء، فإن سرعة معالجة المعاملات في بيئة EVM تكون أبطأ بكثير. من أجل تجنب تباطؤ نظام دفتر الطلبات، يستخدم Hyperliquid "حل السلسلة المزدوجة"، والذي يتيح بشكل أساسي< /strong> Hyperliquidيقوم جهاز العقدة بتشغيل سلسلتين من الكتل على مستوى البرنامج في نفس الوقت. تقوم كل عقدة بتخزين بيانات السلسلتين محليًا وتعالج المعاملات الخاصة بالسلسلتين سلاسل على حدة.
قامت Hyperliquid بإعداد سلسلة خصيصًا لنظام دفتر الطلبات المخصص الخاص بها، كما أضافت أيضًا سلسلة متوافقة مع EVM (HyperEVM). تنتشر بيانات هاتين السلسلتين بين مجموعات العقد من خلال نفس بروتوكول الإجماع وتوجد كحالة موحدة، ولكنها تعمل بشكل منفصل في بيئات تنفيذ مختلفة. نطلق على سجل الطلباتالخاصسلسلة Hyperliquid L1 (L1) ،هذه السلسلة مسموحة لـHyperEVM السلسلة هي HyperEVM(EVM). هذه السلسلة غير مسموح بها ويمكن لأي شخص نشر العقود التي يمكنها الوصول إلى المعلومات داخل L1 من خلال التعليمات البرمجية المترجمة مسبقًا.
تجدر الإشارة إلى أن سرعة إنشاء الكتلة لـ Hyperliquid L1 أكبر من سرعة سلسلة HyperEVM، ولكن سيتم تنفيذ هذه الكتل بالترتيب. يمكن للعقود الموجودة في سلسلة EVM قراءة البيانات الموجودة في كتل L1 السابقة وكتابة البيانات إلى كتل L1 المستقبلية. كما هو موضح أدناه:
من أجل تحقيق التفاعل بين HyperL1 وHyperEVM، يستخدم Hyperliquid وسيلتين تقنيتين: الترجمة المسبقة والأحداث.
الترجمات المسبقة
إن ما يسمىالترجمات المسبقة، بصراحة، هو نقل بعض العمليات التي يصعب تنفيذها والتي تتسم بدرجة عالية من التعقيد في العقود الذكية مباشرةً إلى الطبقة الأساسية،لإزالة المشكلات التي ليست صديقة لـ Solidity ويتم نقل عملية الحساب الأكثر إزعاجًا خارج العقد الذكي التقليدي. يمكن تنفيذ هذا النوع من التعليمات البرمجية المترجمة مسبقًا بلغات C وC++ ولغات أخرى أقرب إلى الجهاز الأساسي من Solidity.
تسمح الطريقة المجمعة مسبقًا لـ EVM بدعم وظائف أكثر تقدمًا وتعقيدًا لتسهيل دعم احتياجات مطوري العقود الذكية. من حيث الشكل، يعد التجميع المسبق في الأساس مجموعة من العقود الذكية الخاصة، ويمكن للعقود الذكية الأخرى استدعاء هذه العقود الخاصة مباشرة، وتمرير المعلمات والحصول على نتائج التنفيذ المترجمة مسبقًا. حاليًا، يتم تنفيذ تعليمات ecRecover
في EVM الأصلي من خلال التجميع المسبق. يمكنك التحقق مما إذا كان توقيع secp256k1
صحيحًا داخل EVM، والتعليمة موجودة في secp256k1
. كود>0x01 داخل العنوان.
يعد استخدام الترجمة المسبقة لإضافة بعض الوظائف الخاصة ممارسة سائدة حاليًا، على سبيل المثال، أضافت Base كود P256
المترجم مسبقًا لتسهيل المستخدمين. عملية مصادقة هوية WebAuth.
(هذه الصورة مأخوذة من موقعالرموز المجمعة)
تماشيًا مع هذا الحل السائد الحالي، أضافت HyperEVM أيضًا سلسلة منالأكواد المترجمة مسبقًالتنفيذ دعم EVM لدفاتر طلبات Hyperliquid< قوية>قراءة حالة النظام. عنوان كود Hyperliquid المعروف حاليًا هو 0x0000000000000000000000000000800
. يمكن لهذا العنوان المترجم مسبقًا قراءة موضع العقد الدائم للمستخدم في أحدث كتلة L1.
الأحداث
لقد ذكرنا أعلاه أن HyperEVM يمكنه كتابة البيانات إلى كتلة HyperL1، ويعتمد سلوك الكتابة على الأحداث. الأحداث هي مفهوم أصلي في EVM، والذي يسمح للعقود الذكية بإرسال معلومات السجل إلى الخارج (مثل تطبيقات الواجهة الأمامية أو المستمعين) أثناء التنفيذ، حتى يتمكن العالم الخارجي من مراقبة حالة تشغيل العقود الذكية.
على سبيل المثال، عندما يستخدم المستخدم وظيفة نقل الرمز المميز لعقد ERC-20، فإن العقد سيطرح حدث نقل
بحيث يمكنك الحصول على حالة نقل الرمز المميز من تطبيقات الواجهة الأمامية مثل مستكشفات المجموعات. سيتم تضمين معلومات الأحداث هذه في الكتلة، وهناك عدد كبير من الحلول الناضجة لمراقبة سجلات الأحداث واسترجاعها.
يوجد الآنالعديدوسيناريوهات متعددةذات صلةالجميع سوفاستخدام الأحداثللتمرير معلمات عبر السلسلة،على سبيل المثال، يتم نشر Arbitrum على شبكة Ethereum الرئيسية ضمن عقد الجسر، يمكن للمستخدمين الاتصال بالوظائف ذات الصلة لرمي الأحداث لبدء المعاملات على Arbitrum.
تشير المعلومات المعروفة إلى أن عقد HyperLiquid ستستمع
0x333333333333333333333333333
& nbsp; ( عنوان الحدث ) نية المستخدم هي معرفة نية المستخدم وفقًا للمعلومات الواردة في الأحداث، وستكون النية مقصودة. قم بالترجمة إلى إجراءات المعاملات، والكتابة في كتل Hyperliquid L1 المستقبلية.
على سبيل المثال، سيوفر عنوان الحدث أعلاه وظيفة عندما يستدعي المستخدم هذه الوظيفة، فسيقوم عنوان الحدث بطرح كائن يسمى IocOrder
الكود> الحدث. عند إنشاء كتلة Hyper L1، ستقوم عقدة HyperLiquid أولاً بالاستعلام عن الأحداث التي تم طرحها بواسطة عنوان الحدث الأخير في HyperEVM. عند استرداد حدث
IocOrder
جديد، سيتم تحويله إلى حدث في Hyper L1. عملية الطلب المعلقة.
HyperBFT
على مستوى بروتوكول الإجماع، يستخدم Hyperliquid بروتوكولًا يسمى HyperBFT وهو مشتق من HotStuff. يعد HutStuff-2 حاليًا أحد أحدث بروتوكولات الإجماع بأقل قدر من التعقيد.
وفقًا للبيانات، استخدم HyperLiquid في البداية خوارزمية إجماع Tendermint، وهي خوارزمية الإجماع الافتراضية المستخدمة في نظام Cosmos، ومع ذلك، فإن هذه الخوارزمية أقل كفاءة يلزم تبادل الرسائل من الكل إلى الكل في المرحلة. يجب على كل عقدة إرسال رسائل إلى جميع العقد الأخرى. تعقيد الاتصال هو O(n²)، حيث n هي العقدة . كمية.
باستخدام Tendermint، يمكن لـ Hyperliquid معالجة ما يصل إلى 20000 طلب في الثانية. من أجل تحقيق سرعة التبادلات المركزية، قام فريق HyperLiquid بتطوير خوارزمية HyperBFT استنادًا إلى HotStuff وتنفيذها في Rust، والتي يمكنها نظريًا التعامل مع ما يصل إلى 2 مليون طلب في الثانية.
يوضح الشكل التالي طريقة تسليم الرسائل لإجماع HyperBFT في موقف غير متوازي، ويمكن ملاحظة أن جميع الرسائل يتم تلخيصها وبثها بشكل موحد بواسطة القائد ، مما يلغي الحاجة إلى أنه يلغي خطوات تبادل الرسائل بين العقد، مما يقلل بشكل كبير من التعقيد.
بكل بساطة، HyperBFT هو بروتوكول إجماعي ينتج فيه القائد الحالي كتلة، وتشارك جميع العقد في التصويت ويتم إرسال نتائج التصويت بشكل موحد إلى القائد، ثم يتم تدوير القائد التالي. في الواقع، التفاصيل المحددة المتعلقة بـ Hotstuff وTendermint أكثر تعقيدًا بكثير. هذه المقالة محدودة بالطول والتركيز ولن تخوض في التفاصيل هنا.
نقاط يجب ملاحظتها للمطورين
ما سبق ذكره تعتبر آلية قراءة البيانات المبنية على Precompiles مثالية نسبيًا. لا يحتاج مطورو Solidity إلى كتابة التعليمات البرمجية المقابلة عند قراءة حالة Hyper L1، لكنهم بحاجة إلى الانتباه إلى مشكلة msg.sender
. كما هو الحال مع معظم طبقات إيثريوم الثانية، يسمح HyperLiquid أيضًا للمستخدمين بالتفاعل بشكل مباشر مع عقد النظام في Hyper L1 وتشغيل إجراءات المعاملة بشكل غير مباشر على سلسلة HyperEVM في هذا الوقت، إذا كان العقد الذكي يقرأ msg.sender في المعاملة < /code>، ستجد أن msg.sender
يتوافق مع عنوان عقد نظام HyperL1، وليس عنوان المستخدم الذي بدأ المعاملة في البداية على HyperL1.
أما بالنسبة للتفاعل بين EVMوL1، فيحتاج المطورون إلى الانتباه إلى سلسلة من القضايا. المشكلة الأولى هي عدم تفاعل التفاعل إذا قام المستخدم بشكل غير مباشر بتقديم طلب في L1 من خلال عنوان الحدث المذكور أعلاه على HyperEVM، ولكن لا يوجد طلب في L1. بدون أصول كافية، ستفشل المعاملة بالتأكيد، ولكن لن تكون هناك مطالبة بإرجاع خطأ عندما يستدعي المستخدم وظيفة عنوان الحدث. قد تؤدي المشكلات المتعلقة بعدم ذرية التفاعلات إلى تعرض أصول المستخدمللاختراق. بالنسبة للمطورين في هذا الوقت، يتعين عليهم التعامل يدويًا مع فشل الطلبات المعلقة من جانب العقد الذكي لـ EVM. علاوة على ذلك، يجب أن يكون للعقد الذكي في آلة القيمة الإلكترونية وظيفة استرداد الأموال النهائية لمنع سحب أصول المستخدم مطلقًا في L1.
ثانيًا، يجب أن يكون عنوان العقد المطابق لـ EVM موجودًا في حساب L1الخريطة،< /strong>بعد أن ينشر المستخدم العقد الذكي في EVM، يحتاج إلى نقل كمية صغيرة من USDC إلى العنوان المعين في L1، مما يجبر L1 على إنشاء حساب لعنوان العقد. قد يكون هذا الجزء من العملية مرتبطًا بالإجماع الأساسي لشركة HyperLiquid، وهو أمر مطلوب بوضوح في وثائق Hyperliquid.
أخيرًا، يحتاج المطورون إلى الانتباه إلى بعض المواقف الخاصة، وخاصة رصيد الرموز المميزة. يحتوي Hyper L1 على عنوان خاص لنقل الأصول، ولكن عندما يرسل المستخدمون الأصول إلى هذا العنوان الخاص، سيتم نقل الأصول من L1 إلى سلسلة HyperEVM. نظرًا لأن عقدة HyperLiquid تنفذ فعليًا سلسلة EVM وسلسلة L1 في نفس الوقت، فقد لا ينتج HyperEVM كتلة لفترة طويلة بعد نقل المستخدم للأصول، وفي هذا الوقت لا يمكن للمستخدم قراءة رصيده على EVM سلسلة.
بكل بساطة، أصول المستخدم في هذا الوقت عالقة في الجسر عبر السلسلة ولا يمكن الاستعلام عنها في سلسلة L1 أو EVM يجب على المطورين الذين قاموا ببناء البروتوكول التعامل مع المواقف الخاصة المذكورة أعلاه لتجنب الذعر بين المستخدمين.
باختصار، يشبه HyperEVMاستنادًا إلىالسائل الزائد بالنسبة للطبقة الثانية من L1يعتمد HyperEVM علىالكود المترجم مسبقًالقراءة حالة L1، ويعتمد أيضًا على الأحداثتفاعل مع Hyper L1إنشاء تفاعلاتs. يحتوي L1 أيضًا على بعض عقود النظام لمساعدة المستخدمينفي تشغيلالمعاملاتفيHyperEVM، أو نعم تنفيذ الأصول عبر السلسلة. ولكن على عكس بنية Layer1-Layer2 العامة، يوفر Hyperliquid إمكانية تشغيل تفاعلي أعلى لـ HyperEVM.
المواد المرجعية
-
السائل المفرط: كتاب الترتيب المفرط L1
السائل المفرط-dex/contracts< /p>
الدليل غير النهائي للترجمات المسبقة للسوائل المفرطة.
ما الفرق بين PBFT وTendermint وHotStuff و و HotStuff-2؟