استكشاف البنية التقنية لـ Hyperliquid والمخاطر الأمنية
تعتبر Hyperliquid التي نالت اهتمامًا واسعًا مؤخرًا واحدة من أكثر بورصات الطلبات على السلسلة تأثيرًا، حيث تجاوزت قيمة إجمالي الإغلاق 2 مليار دولار، وتم تقييمها في الصناعة على أنها "نسخة على السلسلة من بورصة مركزية معروفة"، كما أثارت من جديد النقاش حول Layer3 وسلاسل التطبيقات. بفضل الأداء البارز الذي حققته والذي بلغ تقييم المشروع 30 مليار دولار خلال شهر واحد من الإطلاق، حصلت Hyperliquid على اهتمام واسع. حاليًا، هناك العديد من تقارير التحليل حول Hyperliquid في السوق، ولكن معظمها يركز على وظائف المنتج وآلية التداول، ويفتقر إلى تحليل عميق لبنيتها التحتية والتحديات الأمنية المحتملة.
تهدف هذه المقالة إلى سد هذه الفجوة، من خلال تحليل Hyperliquid من منظور تقني وأمني بحت، لمساعدة القراء على فهم البنية الداخلية والمبادئ الخاصة بهذا المشروع البارز بشكل أفضل. سنركز على تحليل تصميم ومخاطر عقد جسر Hyperliquid عبر السلاسل، بالإضافة إلى الهيكل الثنائي لـ HyperEVM وHyperL1، واستكشاف طرق التنفيذ التقنية وراء ذلك.
تحليل جسر Hyperliquid المتقاطع
نظرًا لأن Hyperliquid لم تقم بفتح مصدر مكوناته الأساسية، لكنها فتحت مصدر العقود الجسرية ذات الصلة، فإن لدينا فهمًا أكبر للمخاطر المتعلقة بالعقود الجسرية. قامت Hyperliquid بنشر عقد جسر على شبكة Layer2 معينة، لغرض تخزين أصول USDC التي أودعها المستخدمون، ويمكننا من خلال مكون الجسر مراقبة بعض سلوكيات عقد Hyperliquid.
مجموعة المدققين
من حيث تقسيم هوية العقد، تحتوي Hyperliquid على 4 مجموعات من المدققين، وهي hotValidatorSet و coldValidatorSet بالإضافة إلى finalizers و lockers، حيث تتحمل كل منها مسؤوليات مختلفة. تتولى hotValidatorSet الاستجابة لعمليات المستخدم عالية التردد مثل سحب الأموال وما إلى ذلك، وعادة ما تستخدم المحفظة الساخنة لمعالجة طلبات المستخدمين في الوقت المناسب.
يستخدم coldValidatorSet بشكل أساسي لتعديل تكوين النظام، مثل تحديث قائمة مجموعة المدققين الآخرين، أو معالجة حالة قفل عقد الجسر، وله الحق في إبطال بعض طلبات السحب مباشرة.
الـ lockers هي مجموعة من المدققين ذوي الصلاحيات الخاصة، تشبه "اللجنة الأمنية" الشائعة في Layer2، يمكنها التصويت في حالات الطوارئ لتقرير ما إذا كان ينبغي وقف تشغيل جسر السلسلة المتقاطعة. حالياً، تتكون مجموعة الـ lockers لجسر Hyperliquid من 5 عناوين، ويتطلب الأمر تصويت 2 من الـ lockers لإيقاف عقد الجسر.
النهائيات هي أيضًا مجموعة من المدققين الخاصين، تُستخدم بشكل رئيسي لتأكيد تغييرات الحالة لجسر السلسلة المتقاطعة، مثل عمليات الإيداع والسحب من قبل المستخدمين. يستخدم جسر السلسلة المتقاطعة في Hyperliquid آلية "تقديم-تأكيد"، بعد أن يبدأ المستخدم سحبًا، يجب الانتظار لفترة "نزاع"، وبعد انتهاء الفترة، يقوم النهائيات بتنفيذ صفقة السحب.
إذا واجهت مشكلة، مثل طلب سحب يتجاوز الرصيد الفعلي للمستخدم، يمكن لعقد Hyperliquid أن يصوت على تعليق عقد الجسر من خلال lockers خلال فترة النزاع، أو يمكن لمجموعة المدققين الباردة جعل سحب المشكلة غير صالح مباشرة.
حاليًا، يحتوي Hyperliquid فقط على 4 عقد للمدققين، لذلك يتوافق hotValidatorSet و coldValidatorSet مع 4 عناوين على السلسلة. عند التهيئة، يقوم Hyperliquid تلقائيًا بتسجيل العناوين داخل hotValidatorSet كأعضاء في lockers و finalizers، بينما يتم التحكم في coldValidatorSet من قبل الجهات الرسمية، حيث يتم استخدام محفظة باردة لتخزين المفاتيح.
إيداع
تقوم عقود جسر Hyperliquid بمعالجة ودائع المستخدمين بناءً على طريقة Permit الخاصة بـ EIP-2612، وتدعم فقط أصل USDC واحد. مقارنة بنموذج الموافقة-التحويل التقليدي، فإن Permit أكثر بساطة، مما يسهل العمليات الجماعية.
تستخدم عقود الجسور دالة batchedDepositWithPermit لمعالجة عدة ودائع دفعة واحدة، والعملية بسيطة ولا تحمل مخاطر على أمان الأموال، حيث تعتمد بشكل أساسي على طريقة Permit لتحسين تجربة المستخدم.
سحب
بالمقارنة مع الودائع، فإن السحب يعتبر عملية عالية المخاطر، لذلك فإن المنطق أكثر تعقيدًا. بعد أن يقوم المستخدم بإطلاق طلب السحب، يستدعي عقد الجسر وظيفة batchedRequestWithdrawals من عقد Hyperliquid. في هذه المرحلة، يتطلب أن يحصل كل طلب سحب على 2/3 من وزن توقيع hotValidatorSet، لاحظ أن الأمر يتعلق بـ "وزن توقيع 2/3" وليس "عدد توقيعات 2/3". حاليًا، يوجد في Hyperliquid أربعة عقد ذات أوزان متساوية، لذا فإن التحقق من وزن التوقيع وعدد التوقيعات يتطابق مؤقتًا، ولكن في المستقبل قد يتم إدخال عقد ذات أوزان عالية.
بعد تقديم طلب السحب، لن تقوم جسر السلسلة المتقاطعة بنقل USDC على الفور، بل سيكون هناك "فترة نزاع" مدتها 200 ثانية. خلال هذه الفترة، قد تحدث حالتان:
تعتقد lockers أن هناك مشكلة خطيرة في طلب السحب، ويمكنها التصويت مباشرة على تجميد العقد؛
تعتقد العقدة أن هناك مشاكل في بعض عمليات السحب، يمكن لأعضاء coldValidatorSet استدعاء دالة invalidateWithdrawals لجعل هذه العملية غير صالحة.
إذا لم يكن هناك أي استثناءات خلال فترة النزاع، يمكن لأعضاء finalizers استدعاء دالة batchedFinalizeWithdrawals لتأكيد الحالة النهائية بعد انتهاء الفترة، وفي هذه الحالة فقط سيتم تحويل USDC إلى عنوان محفظة المستخدم في Layer2.
من منظور نموذج الأمان، إذا كان المهاجم الخبيث يريد أن يسيء استخدام عملية سحب Hyperliquid، يجب عليه اختراق ثلاث خطوط دفاعية:
السيطرة على 2/3 من وزن التوقيع لـ hotValidatorSet، مما يعني الحصول على عدد كافٍ من المفاتيح الخاصة أو التآمر. حالياً يوجد 4 مدققين فقط، ومن المحتمل أن تكون احتمالية السيطرة أو التآمر مرتفعة؛
تجنب إجراء معاملات خبيثة خلال فترة النزاع، وإلا قد يؤدي ذلك إلى تفعيل عقود القفل.
احصل على مفتاح خاص لعضو واحد على الأقل من finalizers، وتأكد من السحب. في الوقت الحالي، يتوافق أعضاء finalizers بشكل أساسي مع أعضاء hotValidatorSet، ويمكن أن يلبي استيفاء الشرط 1 الشرط 3.
قفل عقد الجسر
هايبرليكيد وضعت وظيفة قفل عقد الجسر بين السلاسل. على وجه التحديد، يجب على أعضاء القفل استدعاء دالة voteEmergencyLock للتصويت، وفي الوقت الحالي يمكن لقفلين اثنين التصويت لقفل وإيقاف عقد الجسر.
من الجدير بالذكر أن جسر Hyperliquid يوفر أيضًا دالة unvoteEmergencyLock، التي تسمح للمقفلين بسحب تصويتهم. بمجرد قفل عقد الجسر، يمكن إلغاء قفله فقط من خلال دالة emergencyUnlock، ويجب جمع أكثر من 2/3 من وزن التوقيع لأعضاء coldValidatorSet.
تقوم عملية emergencyUnlock بفك القفل في نفس الوقت بتحديث مجموعة عناوين المدققين hotValidatorSet و coldValidatorSet ، وتصبح سارية المفعول على الفور.
تحديث مجموعة المدققين
بالمقارنة مع اختراق عملية سحب الأموال، فإن استخدام دالة updateValidatorSet لتحديث مجموعة المدققين هو وسيلة هجوم أكثر فاعلية. يتطلب ذلك توقيع جميع أعضاء hotValidatorSet، وهناك فترة جدل مدتها 200 ثانية.
بعد انتهاء فترة النزاع، يجب على أعضاء finalizers استدعاء وظيفة finalizeValidatorSetUpdate لإكمال التحديث النهائي.
تلخيص المخاطر الموجودة في عقد جسر Hyperliquid:
بعد أن يتحكم الهاكر في coldValidatorSet، يمكنه تجاهل العقبات وسرقة أصول المستخدمين. لأن coldValidatorSet لديه صلاحيات emergencyUnlock، يمكنه جعل lockers غير فعالة وتحديث قائمة العقد على الفور. حالياً، يوجد فقط 4 عقد مصادقة، ومخاطر سرقة المفتاح الخاص ليست منخفضة.
تقوم finalizers برفض تأكيد معاملات سحب المستخدم، مما يفتح المجال لهجمات المراجعة. في هذه الحالة، تكون أصول المستخدم آمنة ولكن قد لا تتمكن من سحبها؛
قفل lockers بشكل ضار لجسر عبر السلاسل، مما يمنع تنفيذ جميع معاملات السحب، ولا يمكن الانتظار إلا لفك القفل من coldValidatorSet.
HyperEVM والهيكل التفاعلي ثنائي السلسلة
لتنفيذ برمجة تداول دفتر الطلبات، مثل إدخال معاملات الخصوصية وغيرها من السيناريوهات التي تتطلب دعم العقود الذكية، أطلقت Hyperliquid方案 HyperEVM. يتمتع هذا النظام بمزايا رئيسية على EVM التقليدي: القدرة على قراءة حالة دفتر طلبات Hyperliquid، بالإضافة إلى إمكانية تفاعل العقود الذكية الداخلية مع نظام دفتر الطلبات، مما يوسع بشكل كبير من سيناريوهات التطبيق.
على سبيل المثال، إذا كان المستخدم يحتاج إلى ضمان خصوصية الطلبات المعلقة، يمكنه إضافة طبقة خصوصية من خلال عقود مشابهة لـ Tornado Cash على HyperEVM، ثم استخدام واجهة معينة في نظام دفتر الطلبات Hyperliquid لتفعيل الطلبات المعلقة.
هايبرليكويد صممت هيكلًا خاصًا لـ HyperEVM. نظرًا لأن أداء نظام دفتر الطلبات المخصص يتفوق بكثير على بيئة EVM، ولتجنب انخفاض السرعة، اعتمدت هايبرليكويد "حل السلسلتين": حيث يعمل كل عقدة على تشغيل سلسلتين في نفس الوقت، وتخزين بيانات السلسلتين محليًا ومعالجة المعاملات بشكل منفصل.
هايبرليكويد تضع نظام دفتر الطلبات على سلسلة مخصصة ( هايبرL1، نظام ترخيص )، وفي ذات الوقت تضيف سلسلة متوافقة مع EVM ( هايبرEVM، بدون ترخيص ). يتم توزيع بيانات السلسلتين من خلال نفس بروتوكول الإجماع، كحالة موحدة، ولكن تعمل في بيئات مختلفة. سرعة إنتاج الكتل في هايبرL1 أسرع من هايبرEVM، لكن الكتل لا تزال تنفذ بالتسلسل. يمكن للعقود على سلسلة EVM قراءة بيانات الكتل السابقة من L1، وكتابة البيانات إلى كتل L1 المستقبلية.
تتمثل التفاعلات بين HyperL1 و HyperEVM بشكل أساسي من خلال Precompiles و Events.
التهيئات المسبقة
تقوم ( Precompiles) بتنفيذ العمليات المعقدة مباشرة على المستوى الأساسي، باستخدام لغات مثل C/C++ لمعالجة الحسابات غير الودية مع Solidity. تعتبر المسبقات في جوهرها عقود ذكية خاصة، يمكن للعقود الأخرى استدعاؤها والحصول على نتائج التنفيذ. في الوقت الحالي، تم استخدام المسبقات في EVM الأصلي لتنفيذ تعليمة ecRecover (0x01 العنوان ).
أضاف HyperEVM أيضًا رمزًا مُسبق الترجمة لتمكين قراءة حالة نظام دفتر الطلبات Hyperliquid. ومن المعروف أن عنوان الترجمة المسبق هو 0x0000000000000000000000000000000000000800، ويمكنه قراءة مراكز العقود الدائمة للمستخدمين داخل الكتل L1 الأخيرة.
أحداث
تعتمد HyperEVM على Events لتنفيذ كتابة البيانات إلى HyperL1. Events هي مفهوم أصلي في EVM، يسمح للعقود بإرسال معلومات السجل إلى الخارج. على سبيل المثال، يتم إطلاق حدث Transfer عند إجراء تحويل ERC-20، مما يسهل عملية الاستماع. تُستخدم العديد من سيناريوهات النقل عبر السلاسل أيضًا Events لنقل المعلمات.
يستمع عقد HyperLiquid إلى الأحداث التي تم إلقاؤها من عنوان 0x3333333333333333333333333333333333333333، ويستنتج نية المستخدم بناءً على المعلومات ويحولها إلى إجراءات تداول، ويكتبها في كتلة L1 المستقبلية. إذا كان هذا العنوان يوفر دالة، فعند الاستدعاء يتم إلقاء حدث IocOrder، وعند إنشاء كتلة L1، يقوم العقد باكتشاف حدث IocOrder الجديد وتحويله إلى عملية إدخال أمر داخل L1.
هايبر بي إف تي
فيما يتعلق ببروتوكولات التوافق، تعتمد Hyperliquid بروتوكول HyperBFT المستند إلى HotStuff. في البداية، استخدم خوارزمية Tendermint، ولكنها كانت غير فعالة، حيث تتطلب تبادل الرسائل من All-to-All في كل مرحلة، مع تعقيد O(n²).
للوصول إلى سرعة البورصة المركزية، قام الفريق بتطوير HyperBFT وتنفيذه بلغة Rust، ومن الناحية النظرية يمكن معالجة مليوني طلب في الثانية. جميع الرسائل في HyperBFT يتم تلخيصها ونشرها من قبل القائد، مما يلغي الحاجة لتبادل الرسائل بين العقد، ويقلل بشكل كبير من التعقيد.
باختصار، HyperBFT هو بروتوكول توافق حيث يقوم الزعيم الحالي بكتابة الكتل، وتقوم جميع العقد بالتصويت وإرسال النتائج إلى الزعيم، ثم يتم التناوب على الزعيم التالي.
ملاحظات للمطورين
آلية قراءة البيانات المعتمدة على Precompiles متطورة نسبيًا، ولكن يجب الانتباه إلى مشكلة msg.sender. عند تفاعل المستخدم مع عقد نظام L1، يؤدي ذلك بشكل غير مباشر إلى تفعيل صفقة EVM، حيث تكون msg.sender داخل EVM هي عنوان عقد نظام L1 وليس عنوان المستخدم.
توجد مشكلة عدم الذرية في التفاعل بين EVM و L1. على سبيل المثال، إذا قام المستخدم بإدخال طلب على L1 عبر EVM ولكن الأصول غير كافية، تفشل المعاملة ولكن لا توجد رسالة خطأ عند استدعاء الدالة. يجب على المطورين معالجة حالات فشل الطلب على جانب عقد EVM، وتحديد دالة لاسترداد الأموال.
يجب أن يكون عنوان عقد EVM على L1 لديه حساب مخصص. بعد نشر عقد EVM، يجب تحويل كمية صغيرة من USDC إلى عنوان L1 لإنشاء الحساب.
انتبه للحالات الخاصة مثل رصيد الرموز. L1 لديها عناوين خاصة لنقل الأصول عبر السلاسل، ولكن بعد النقل عبر السلاسل قد لا يتم إنشاء الكتل في EVM في الوقت المناسب، مما يجعل المستخدم غير قادر على قراءة الرصيد مؤقتًا. يجب على المطورين معالجة مثل هذه الحالات لتجنب ذعر المستخدمين.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 22
أعجبني
22
6
مشاركة
تعليق
0/400
LazyDevMiner
· 07-12 07:14
هناك الكثير من المخاطر ومع ذلك 20 مليار قفل المركز، حقًا أمر غير منطقي
شاهد النسخة الأصليةرد0
PumpDoctrine
· 07-11 11:56
啥时候能شراء الانخفاض它啊
شاهد النسخة الأصليةرد0
Web3ExplorerLin
· 07-09 10:39
من الناحية الفنية، هناك فرصة أخرى للصعود إلى القمر من المستوى الثالث في الطريق...يؤسفني ذلك
شاهد النسخة الأصليةرد0
RugResistant
· 07-09 10:38
انتظر لتناول البطيخ
شاهد النسخة الأصليةرد0
WalletInspector
· 07-09 10:32
أخبار غير رسمية, إن المال لفتح صندوق الغموض ليس مزاحاً
شاهد النسخة الأصليةرد0
WalletDoomsDay
· 07-09 10:20
هل يمكنك توضيح المخاطر الأمنية؟ التحدث باستمرار عن الارتفاع والانخفاض ليس له فائدة.
تحليل عميق لـ Hyperliquid: مناقشة أمان الجسور عبر السلسلة وهيكل HyperEVM المزدوج
استكشاف البنية التقنية لـ Hyperliquid والمخاطر الأمنية
تعتبر Hyperliquid التي نالت اهتمامًا واسعًا مؤخرًا واحدة من أكثر بورصات الطلبات على السلسلة تأثيرًا، حيث تجاوزت قيمة إجمالي الإغلاق 2 مليار دولار، وتم تقييمها في الصناعة على أنها "نسخة على السلسلة من بورصة مركزية معروفة"، كما أثارت من جديد النقاش حول Layer3 وسلاسل التطبيقات. بفضل الأداء البارز الذي حققته والذي بلغ تقييم المشروع 30 مليار دولار خلال شهر واحد من الإطلاق، حصلت Hyperliquid على اهتمام واسع. حاليًا، هناك العديد من تقارير التحليل حول Hyperliquid في السوق، ولكن معظمها يركز على وظائف المنتج وآلية التداول، ويفتقر إلى تحليل عميق لبنيتها التحتية والتحديات الأمنية المحتملة.
تهدف هذه المقالة إلى سد هذه الفجوة، من خلال تحليل Hyperliquid من منظور تقني وأمني بحت، لمساعدة القراء على فهم البنية الداخلية والمبادئ الخاصة بهذا المشروع البارز بشكل أفضل. سنركز على تحليل تصميم ومخاطر عقد جسر Hyperliquid عبر السلاسل، بالإضافة إلى الهيكل الثنائي لـ HyperEVM وHyperL1، واستكشاف طرق التنفيذ التقنية وراء ذلك.
تحليل جسر Hyperliquid المتقاطع
نظرًا لأن Hyperliquid لم تقم بفتح مصدر مكوناته الأساسية، لكنها فتحت مصدر العقود الجسرية ذات الصلة، فإن لدينا فهمًا أكبر للمخاطر المتعلقة بالعقود الجسرية. قامت Hyperliquid بنشر عقد جسر على شبكة Layer2 معينة، لغرض تخزين أصول USDC التي أودعها المستخدمون، ويمكننا من خلال مكون الجسر مراقبة بعض سلوكيات عقد Hyperliquid.
مجموعة المدققين
من حيث تقسيم هوية العقد، تحتوي Hyperliquid على 4 مجموعات من المدققين، وهي hotValidatorSet و coldValidatorSet بالإضافة إلى finalizers و lockers، حيث تتحمل كل منها مسؤوليات مختلفة. تتولى hotValidatorSet الاستجابة لعمليات المستخدم عالية التردد مثل سحب الأموال وما إلى ذلك، وعادة ما تستخدم المحفظة الساخنة لمعالجة طلبات المستخدمين في الوقت المناسب.
يستخدم coldValidatorSet بشكل أساسي لتعديل تكوين النظام، مثل تحديث قائمة مجموعة المدققين الآخرين، أو معالجة حالة قفل عقد الجسر، وله الحق في إبطال بعض طلبات السحب مباشرة.
الـ lockers هي مجموعة من المدققين ذوي الصلاحيات الخاصة، تشبه "اللجنة الأمنية" الشائعة في Layer2، يمكنها التصويت في حالات الطوارئ لتقرير ما إذا كان ينبغي وقف تشغيل جسر السلسلة المتقاطعة. حالياً، تتكون مجموعة الـ lockers لجسر Hyperliquid من 5 عناوين، ويتطلب الأمر تصويت 2 من الـ lockers لإيقاف عقد الجسر.
النهائيات هي أيضًا مجموعة من المدققين الخاصين، تُستخدم بشكل رئيسي لتأكيد تغييرات الحالة لجسر السلسلة المتقاطعة، مثل عمليات الإيداع والسحب من قبل المستخدمين. يستخدم جسر السلسلة المتقاطعة في Hyperliquid آلية "تقديم-تأكيد"، بعد أن يبدأ المستخدم سحبًا، يجب الانتظار لفترة "نزاع"، وبعد انتهاء الفترة، يقوم النهائيات بتنفيذ صفقة السحب.
إذا واجهت مشكلة، مثل طلب سحب يتجاوز الرصيد الفعلي للمستخدم، يمكن لعقد Hyperliquid أن يصوت على تعليق عقد الجسر من خلال lockers خلال فترة النزاع، أو يمكن لمجموعة المدققين الباردة جعل سحب المشكلة غير صالح مباشرة.
حاليًا، يحتوي Hyperliquid فقط على 4 عقد للمدققين، لذلك يتوافق hotValidatorSet و coldValidatorSet مع 4 عناوين على السلسلة. عند التهيئة، يقوم Hyperliquid تلقائيًا بتسجيل العناوين داخل hotValidatorSet كأعضاء في lockers و finalizers، بينما يتم التحكم في coldValidatorSet من قبل الجهات الرسمية، حيث يتم استخدام محفظة باردة لتخزين المفاتيح.
إيداع
تقوم عقود جسر Hyperliquid بمعالجة ودائع المستخدمين بناءً على طريقة Permit الخاصة بـ EIP-2612، وتدعم فقط أصل USDC واحد. مقارنة بنموذج الموافقة-التحويل التقليدي، فإن Permit أكثر بساطة، مما يسهل العمليات الجماعية.
تستخدم عقود الجسور دالة batchedDepositWithPermit لمعالجة عدة ودائع دفعة واحدة، والعملية بسيطة ولا تحمل مخاطر على أمان الأموال، حيث تعتمد بشكل أساسي على طريقة Permit لتحسين تجربة المستخدم.
سحب
بالمقارنة مع الودائع، فإن السحب يعتبر عملية عالية المخاطر، لذلك فإن المنطق أكثر تعقيدًا. بعد أن يقوم المستخدم بإطلاق طلب السحب، يستدعي عقد الجسر وظيفة batchedRequestWithdrawals من عقد Hyperliquid. في هذه المرحلة، يتطلب أن يحصل كل طلب سحب على 2/3 من وزن توقيع hotValidatorSet، لاحظ أن الأمر يتعلق بـ "وزن توقيع 2/3" وليس "عدد توقيعات 2/3". حاليًا، يوجد في Hyperliquid أربعة عقد ذات أوزان متساوية، لذا فإن التحقق من وزن التوقيع وعدد التوقيعات يتطابق مؤقتًا، ولكن في المستقبل قد يتم إدخال عقد ذات أوزان عالية.
بعد تقديم طلب السحب، لن تقوم جسر السلسلة المتقاطعة بنقل USDC على الفور، بل سيكون هناك "فترة نزاع" مدتها 200 ثانية. خلال هذه الفترة، قد تحدث حالتان:
تعتقد lockers أن هناك مشكلة خطيرة في طلب السحب، ويمكنها التصويت مباشرة على تجميد العقد؛
تعتقد العقدة أن هناك مشاكل في بعض عمليات السحب، يمكن لأعضاء coldValidatorSet استدعاء دالة invalidateWithdrawals لجعل هذه العملية غير صالحة.
إذا لم يكن هناك أي استثناءات خلال فترة النزاع، يمكن لأعضاء finalizers استدعاء دالة batchedFinalizeWithdrawals لتأكيد الحالة النهائية بعد انتهاء الفترة، وفي هذه الحالة فقط سيتم تحويل USDC إلى عنوان محفظة المستخدم في Layer2.
من منظور نموذج الأمان، إذا كان المهاجم الخبيث يريد أن يسيء استخدام عملية سحب Hyperliquid، يجب عليه اختراق ثلاث خطوط دفاعية:
السيطرة على 2/3 من وزن التوقيع لـ hotValidatorSet، مما يعني الحصول على عدد كافٍ من المفاتيح الخاصة أو التآمر. حالياً يوجد 4 مدققين فقط، ومن المحتمل أن تكون احتمالية السيطرة أو التآمر مرتفعة؛
تجنب إجراء معاملات خبيثة خلال فترة النزاع، وإلا قد يؤدي ذلك إلى تفعيل عقود القفل.
احصل على مفتاح خاص لعضو واحد على الأقل من finalizers، وتأكد من السحب. في الوقت الحالي، يتوافق أعضاء finalizers بشكل أساسي مع أعضاء hotValidatorSet، ويمكن أن يلبي استيفاء الشرط 1 الشرط 3.
قفل عقد الجسر
هايبرليكيد وضعت وظيفة قفل عقد الجسر بين السلاسل. على وجه التحديد، يجب على أعضاء القفل استدعاء دالة voteEmergencyLock للتصويت، وفي الوقت الحالي يمكن لقفلين اثنين التصويت لقفل وإيقاف عقد الجسر.
من الجدير بالذكر أن جسر Hyperliquid يوفر أيضًا دالة unvoteEmergencyLock، التي تسمح للمقفلين بسحب تصويتهم. بمجرد قفل عقد الجسر، يمكن إلغاء قفله فقط من خلال دالة emergencyUnlock، ويجب جمع أكثر من 2/3 من وزن التوقيع لأعضاء coldValidatorSet.
تقوم عملية emergencyUnlock بفك القفل في نفس الوقت بتحديث مجموعة عناوين المدققين hotValidatorSet و coldValidatorSet ، وتصبح سارية المفعول على الفور.
تحديث مجموعة المدققين
بالمقارنة مع اختراق عملية سحب الأموال، فإن استخدام دالة updateValidatorSet لتحديث مجموعة المدققين هو وسيلة هجوم أكثر فاعلية. يتطلب ذلك توقيع جميع أعضاء hotValidatorSet، وهناك فترة جدل مدتها 200 ثانية.
بعد انتهاء فترة النزاع، يجب على أعضاء finalizers استدعاء وظيفة finalizeValidatorSetUpdate لإكمال التحديث النهائي.
تلخيص المخاطر الموجودة في عقد جسر Hyperliquid:
بعد أن يتحكم الهاكر في coldValidatorSet، يمكنه تجاهل العقبات وسرقة أصول المستخدمين. لأن coldValidatorSet لديه صلاحيات emergencyUnlock، يمكنه جعل lockers غير فعالة وتحديث قائمة العقد على الفور. حالياً، يوجد فقط 4 عقد مصادقة، ومخاطر سرقة المفتاح الخاص ليست منخفضة.
تقوم finalizers برفض تأكيد معاملات سحب المستخدم، مما يفتح المجال لهجمات المراجعة. في هذه الحالة، تكون أصول المستخدم آمنة ولكن قد لا تتمكن من سحبها؛
قفل lockers بشكل ضار لجسر عبر السلاسل، مما يمنع تنفيذ جميع معاملات السحب، ولا يمكن الانتظار إلا لفك القفل من coldValidatorSet.
HyperEVM والهيكل التفاعلي ثنائي السلسلة
لتنفيذ برمجة تداول دفتر الطلبات، مثل إدخال معاملات الخصوصية وغيرها من السيناريوهات التي تتطلب دعم العقود الذكية، أطلقت Hyperliquid方案 HyperEVM. يتمتع هذا النظام بمزايا رئيسية على EVM التقليدي: القدرة على قراءة حالة دفتر طلبات Hyperliquid، بالإضافة إلى إمكانية تفاعل العقود الذكية الداخلية مع نظام دفتر الطلبات، مما يوسع بشكل كبير من سيناريوهات التطبيق.
على سبيل المثال، إذا كان المستخدم يحتاج إلى ضمان خصوصية الطلبات المعلقة، يمكنه إضافة طبقة خصوصية من خلال عقود مشابهة لـ Tornado Cash على HyperEVM، ثم استخدام واجهة معينة في نظام دفتر الطلبات Hyperliquid لتفعيل الطلبات المعلقة.
هايبرليكويد صممت هيكلًا خاصًا لـ HyperEVM. نظرًا لأن أداء نظام دفتر الطلبات المخصص يتفوق بكثير على بيئة EVM، ولتجنب انخفاض السرعة، اعتمدت هايبرليكويد "حل السلسلتين": حيث يعمل كل عقدة على تشغيل سلسلتين في نفس الوقت، وتخزين بيانات السلسلتين محليًا ومعالجة المعاملات بشكل منفصل.
هايبرليكويد تضع نظام دفتر الطلبات على سلسلة مخصصة ( هايبرL1، نظام ترخيص )، وفي ذات الوقت تضيف سلسلة متوافقة مع EVM ( هايبرEVM، بدون ترخيص ). يتم توزيع بيانات السلسلتين من خلال نفس بروتوكول الإجماع، كحالة موحدة، ولكن تعمل في بيئات مختلفة. سرعة إنتاج الكتل في هايبرL1 أسرع من هايبرEVM، لكن الكتل لا تزال تنفذ بالتسلسل. يمكن للعقود على سلسلة EVM قراءة بيانات الكتل السابقة من L1، وكتابة البيانات إلى كتل L1 المستقبلية.
تتمثل التفاعلات بين HyperL1 و HyperEVM بشكل أساسي من خلال Precompiles و Events.
التهيئات المسبقة
تقوم ( Precompiles) بتنفيذ العمليات المعقدة مباشرة على المستوى الأساسي، باستخدام لغات مثل C/C++ لمعالجة الحسابات غير الودية مع Solidity. تعتبر المسبقات في جوهرها عقود ذكية خاصة، يمكن للعقود الأخرى استدعاؤها والحصول على نتائج التنفيذ. في الوقت الحالي، تم استخدام المسبقات في EVM الأصلي لتنفيذ تعليمة ecRecover (0x01 العنوان ).
أضاف HyperEVM أيضًا رمزًا مُسبق الترجمة لتمكين قراءة حالة نظام دفتر الطلبات Hyperliquid. ومن المعروف أن عنوان الترجمة المسبق هو 0x0000000000000000000000000000000000000800، ويمكنه قراءة مراكز العقود الدائمة للمستخدمين داخل الكتل L1 الأخيرة.
أحداث
تعتمد HyperEVM على Events لتنفيذ كتابة البيانات إلى HyperL1. Events هي مفهوم أصلي في EVM، يسمح للعقود بإرسال معلومات السجل إلى الخارج. على سبيل المثال، يتم إطلاق حدث Transfer عند إجراء تحويل ERC-20، مما يسهل عملية الاستماع. تُستخدم العديد من سيناريوهات النقل عبر السلاسل أيضًا Events لنقل المعلمات.
يستمع عقد HyperLiquid إلى الأحداث التي تم إلقاؤها من عنوان 0x3333333333333333333333333333333333333333، ويستنتج نية المستخدم بناءً على المعلومات ويحولها إلى إجراءات تداول، ويكتبها في كتلة L1 المستقبلية. إذا كان هذا العنوان يوفر دالة، فعند الاستدعاء يتم إلقاء حدث IocOrder، وعند إنشاء كتلة L1، يقوم العقد باكتشاف حدث IocOrder الجديد وتحويله إلى عملية إدخال أمر داخل L1.
هايبر بي إف تي
فيما يتعلق ببروتوكولات التوافق، تعتمد Hyperliquid بروتوكول HyperBFT المستند إلى HotStuff. في البداية، استخدم خوارزمية Tendermint، ولكنها كانت غير فعالة، حيث تتطلب تبادل الرسائل من All-to-All في كل مرحلة، مع تعقيد O(n²).
للوصول إلى سرعة البورصة المركزية، قام الفريق بتطوير HyperBFT وتنفيذه بلغة Rust، ومن الناحية النظرية يمكن معالجة مليوني طلب في الثانية. جميع الرسائل في HyperBFT يتم تلخيصها ونشرها من قبل القائد، مما يلغي الحاجة لتبادل الرسائل بين العقد، ويقلل بشكل كبير من التعقيد.
باختصار، HyperBFT هو بروتوكول توافق حيث يقوم الزعيم الحالي بكتابة الكتل، وتقوم جميع العقد بالتصويت وإرسال النتائج إلى الزعيم، ثم يتم التناوب على الزعيم التالي.
ملاحظات للمطورين
آلية قراءة البيانات المعتمدة على Precompiles متطورة نسبيًا، ولكن يجب الانتباه إلى مشكلة msg.sender. عند تفاعل المستخدم مع عقد نظام L1، يؤدي ذلك بشكل غير مباشر إلى تفعيل صفقة EVM، حيث تكون msg.sender داخل EVM هي عنوان عقد نظام L1 وليس عنوان المستخدم.
توجد مشكلة عدم الذرية في التفاعل بين EVM و L1. على سبيل المثال، إذا قام المستخدم بإدخال طلب على L1 عبر EVM ولكن الأصول غير كافية، تفشل المعاملة ولكن لا توجد رسالة خطأ عند استدعاء الدالة. يجب على المطورين معالجة حالات فشل الطلب على جانب عقد EVM، وتحديد دالة لاسترداد الأموال.
يجب أن يكون عنوان عقد EVM على L1 لديه حساب مخصص. بعد نشر عقد EVM، يجب تحويل كمية صغيرة من USDC إلى عنوان L1 لإنشاء الحساب.
انتبه للحالات الخاصة مثل رصيد الرموز. L1 لديها عناوين خاصة لنقل الأصول عبر السلاسل، ولكن بعد النقل عبر السلاسل قد لا يتم إنشاء الكتل في EVM في الوقت المناسب، مما يجعل المستخدم غير قادر على قراءة الرصيد مؤقتًا. يجب على المطورين معالجة مثل هذه الحالات لتجنب ذعر المستخدمين.