عند لحظة ترجمة "Stake Abstraction" إلى "Hyperstaking"، تحوّل الأمر من معلمة بروتوكول إلى صياغة تسويقية للمنتج—لكن عند قلب التوثيق إلى طبقته السفلية، ما يفعله في الحقيقة هو فك اقتران حقوق الإيداع عن مفاتيح EOA الخاصة عبر عقد ذكي: يجب على العقد أن يمر عبر stake_from_contract الخاص بـ Stake Contract، ثم يستدعي بين العقود عبر Transfer Contract. ويظل التفعيل يحتاج إلى 4320 كتلة (حوالي 12 ساعة) نضجًا، والحد الأدنى للعتبة هو نفسه 1000 #dusk .
المشكلة تنبع من العبارة الضمنية في جملة "العقد هو المودِع". في توافق SBA، يتم استخراج Generator/Provisioner بالاعتماد على Proof-of-Blind Bid واختيار Sortition حتمي؛ وتوزن الأوزان بحسب الإيداع النشط. لكن بمجرد أن تُودَع الأوزان داخل عقد تفويض خصوصي، لا يستطيع الطرف الخارجي رؤية سوى إجمالي الـ stake لعقد بعينه؛ لا يرى ما إذا كانت داخله 300 مستثمر فردي أم جهة واحدة قامت بتقسيم 5 “قواقع”. @Dusk يروّج للـ auditable privacy بنفسه، لكن هل يفرض Hyperstaking Pool بالضرورة تكامل view key لأغراض التدقيق؟ الوثائق لا تحدد ذلك بشكل صارم—ومن ثم تتحول "درجة اللامركزية" من افتراض قابل للتحقق إلى مجرد إعلان ثقة.
أما طبقة LSD فهي أكثر تعقيدًا. في طبقة LSD، لا توجد فترة انتظار عند unstake في البروتوكول الأساسي، وفرص المكافآت مُحتملة/احتمالية؛ فالمستخدم يمكنه سحب أموالَه مباشرة واستبدال stDUSK من أجل الاسترجاع في حوضٍ ما سيكون أكثر سلاسة. لكن إذا جمدنا نموذج Lido بالقوة، فإن الطلب لا ينشأ طبيعيًا، بل يورَّد من خلال العقد؛ والنتيجة غالبًا هي تقطيعًا إضافيًا للسيولة—even لو كانت أصلًا غير عميقة—للأصل $DUSK إلى عدة شرائح.
لن أضيف نقاطًا فقط لأن "الدعم الأصلي للـ staking القابل للبرمجة" موجود. في جدار التحمل (أمان الإجماع)، كلما فتحت نافذة جديدة—تفويضات خاصة، وLSD، واستراتيجيات عوائد—يجب أن تطرح الأسئلة: هل يغطي تدقيق العقد استقبال المكافأة (receive_reward) واستقبال الـ unstake (receive_unstake) من خلال ردّ الاستدعاء؟ هل توجد لوحة تحكم third-party لتوزيع أوزان حوض الخصوصية؟ بالنسبة للأحواض من الدفعة الأولى مثل Sozu، كيف يتم التعامل مع جزء الإقفال عند حدوث slashing؟ إذا لم تكن الإجابات واضحة، فإن Hyperstaking ليس ترقية للـ staking، بل استبدال لآلة بسيطة لها حالتان أصلاً، إلى ألف آلة حالة غير مدققة تشترك في مفتاح إجماع واحد غير مُراجع.
المشكلة تنبع من العبارة الضمنية في جملة "العقد هو المودِع". في توافق SBA، يتم استخراج Generator/Provisioner بالاعتماد على Proof-of-Blind Bid واختيار Sortition حتمي؛ وتوزن الأوزان بحسب الإيداع النشط. لكن بمجرد أن تُودَع الأوزان داخل عقد تفويض خصوصي، لا يستطيع الطرف الخارجي رؤية سوى إجمالي الـ stake لعقد بعينه؛ لا يرى ما إذا كانت داخله 300 مستثمر فردي أم جهة واحدة قامت بتقسيم 5 “قواقع”. @Dusk يروّج للـ auditable privacy بنفسه، لكن هل يفرض Hyperstaking Pool بالضرورة تكامل view key لأغراض التدقيق؟ الوثائق لا تحدد ذلك بشكل صارم—ومن ثم تتحول "درجة اللامركزية" من افتراض قابل للتحقق إلى مجرد إعلان ثقة.
أما طبقة LSD فهي أكثر تعقيدًا. في طبقة LSD، لا توجد فترة انتظار عند unstake في البروتوكول الأساسي، وفرص المكافآت مُحتملة/احتمالية؛ فالمستخدم يمكنه سحب أموالَه مباشرة واستبدال stDUSK من أجل الاسترجاع في حوضٍ ما سيكون أكثر سلاسة. لكن إذا جمدنا نموذج Lido بالقوة، فإن الطلب لا ينشأ طبيعيًا، بل يورَّد من خلال العقد؛ والنتيجة غالبًا هي تقطيعًا إضافيًا للسيولة—even لو كانت أصلًا غير عميقة—للأصل $DUSK إلى عدة شرائح.
لن أضيف نقاطًا فقط لأن "الدعم الأصلي للـ staking القابل للبرمجة" موجود. في جدار التحمل (أمان الإجماع)، كلما فتحت نافذة جديدة—تفويضات خاصة، وLSD، واستراتيجيات عوائد—يجب أن تطرح الأسئلة: هل يغطي تدقيق العقد استقبال المكافأة (receive_reward) واستقبال الـ unstake (receive_unstake) من خلال ردّ الاستدعاء؟ هل توجد لوحة تحكم third-party لتوزيع أوزان حوض الخصوصية؟ بالنسبة للأحواض من الدفعة الأولى مثل Sozu، كيف يتم التعامل مع جزء الإقفال عند حدوث slashing؟ إذا لم تكن الإجابات واضحة، فإن Hyperstaking ليس ترقية للـ staking، بل استبدال لآلة بسيطة لها حالتان أصلاً، إلى ألف آلة حالة غير مدققة تشترك في مفتاح إجماع واحد غير مُراجع.