اقتراح اللجنة 88 هو طلب تصويت لإعداد معايير سلسلة 77 و 78 على شبكة TRON ، والتي تهدف إلى تمكين تحسين استخدام Stake 2.0.
يسمح للمستخدمين بـ unstaking الذي بدأ ولكن لم يكتمل بعد ، ويسمح للمستخدمين بتحديد وقت قفل تفويض المورد حسب الحاجة.
يرجى الرجوع إلى هنا لمناقشة الأصل. الآن أصبح اقتراح اللجنة 88 ساري المفعول بالفعل ، يرجى الرجوع إلى هنا للحصول على تفاصيل التصويت وسيتم شرح المزيد من التفاصيل حول الاقتراح في هذه المقالة.
ما هو الدافع لتحسين استخدام Stake 2.0؟
من ناحية بعد بدء معاملة غير مثبتة في Stake 2.0 يحتاج المستخدمون إلى الانتظار لمدة 14 يوم قبل سحب الأموال المقابلة ولا يمكن unstaking فهو إنه غير مناسب للمستخدمين في حالة رغبتهم في الاسترداد مرة أخرى مما قد يؤثر أيضًا على الأرباح.
لذلك يُقترح السماح للمستخدمين بإلغاء عمليات unstaking التي تم البدء فيها ولكن لم تكتمل بعد وعند إلغاء عمليات unstaking ستتم إعادة تخزين جميع أموال unstaked التي لا تزال في فترة الانتظار ، وسيظل المورد الذي تم الحصول عليه من خلال إعادة re-staking كما كان من قبل.
لا يمكن إلغاء عمليات unstaking التي تجاوزت فترة الانتظار البالغة 14 يومًا ، وسيتم تلقائيًا سحب هذا الجزء من أموال unstaked إلى حساب المالك.
من ناحية أخرى عند بدء معاملة تفويض المورد في Stake 2.0 إذا اختار المستخدم أن يكون القفل صحيحًا ، فلا يمكن إلغاء تفويض الموارد المفوضة في غضون 3 أيام.
ومع ذلك ، فإن وقت القفل القوي البالغ 3 أيام لا يمكن أن يلبي جميع السيناريوهات كما أنه لا يفضي إلى تسهيل أو حماية سوق تأجير الموارد.
لذلك يُقترح السماح للمستخدمين بتحديد وقت قفل تفويض الموارد حسب الحاجة ، والحد الأقصى لوقت القفل هو 30 يومًا حيث سيؤدي جعل وقت الإغلاق وقتًا قابلاً للتخصيص إلى تعزيز المرونة والأمان في معاملات التفويض.
مقدمة من معايير السلسلة المترابطة “correlated chain”
يهدف تحسين استخدام Stake 2.0 إلى توسيع ميزات جديدة لتحسين المرونة في Stake 2.0 ، وتكون معايير الاقتراح كما يلي:
◽️ getAllowCancelAllUnfreezeV2 (№77) = 1
تم تعيين معيار الشبكة №77 على 1 ، وهذا يعني أنه تم تمكين وظيفة السماح بإلغاء عمليات إلغاء التثبيت.
◽️ getMaxDelegateLockPeriod (№78) = 864000
تم تعيين معلمة الشبكة №78 على 864000 ، وهذا يعني أنه تم تمكين وظيفة السماح بتحديد وقت قفل تفويض المورد حيث تشير القيمة إلى الحد الأقصى لقيمة وقت القفل التي يمكن ضبطها ، والوحدة هي فاصل الكتلة (3 ثوانٍ).
لذا فإن تعيين القيمة على 864000 يعني أن الحد الأقصى لوقت القفل هو 30 يوم (864000 * 3/24/60/60).
قرر المجتمع أخيرًا أن يكون getMaxDelegateLockPeriod ليكون 864000 فترة كتلة بعد المناقشة الكاملة ، مما يعني أن الحد الأقصى لوقت القفل هو 30 يوم.
القيمة الافتراضية لـ lock_period الجديد هي 86400 وهي 3 أيام أي عندما يكون القفل صحيحًا إذا لم يتم تحديد lock_period أو تم ضبطه على 0 ، فسيتم تعيين lock_period إلى 86400 افتراضيًا ، مما يضمن التوافق قبل وبعد سريان الاقتراح.
بالإضافة إلى ذلك لا يمكن أن تكون قيمة lock_period أقل من وقت القفل المتبقي لهذا النوع من الموارد الذي تم تفويضه مسبقًا لنفس عنوان المستلم وستحل القيمة محل وقت القفل المتبقي للمفوض السابق.
كيف تتكيف مع الاستخدام الأمثل لـ Stake 2.0؟
بعد تمكين تحسين الاستخدام لـ Stake 2.0 تمت إضافة محفظة API جديدة / إلغاء جميع unfreezev2 ، وإضافة معيار جديد ، lock_period ، إلى واجهة برمجة التطبيقات للمحفظة / المندوبية.
يرجى تقييم والتحقق مما إذا كانت هناك حاجة إلى أعمال التكييف ، لمزيد من المعلومات حول كيفية التكيف مع التحسين يرجى الرجوع إلى هنا.
ملخص
بعد تمكين تحسين الاستخدام ستوفر TRON للمستخدمين المزيد من الخيارات في نموذج stake ، وسيتم تحسين مرونة Stake 2.0 بشكل كبير ، وسيتم تعزيز كفاءة استخدام موارد TRON بشكل أكبر.