تفويض موارد TRON من الداخل: كيف يعمل فعلياً

نموذج الموارد: نقطة البداية لفهم التفويض

لا تعتمد شبكة TRON على رسوم الغاز بالمفهوم المعروف في إيثيريوم. بدلاً من ذلك، يمتلك كل حساب مجموعتين من الموارد: Energy وbandwidth. تُستهلك Energy عند تنفيذ العقود الذكية، بينما تُستهلك bandwidth مع كل معاملة سواء تضمّنت عقداً أم لا. حين ينفد أيٌّ من هذين المصدرين، تقوم الشبكة بحرق TRX من رصيد الحساب لتغطية النقص، وهذا الحرق هو ما يُكلّف المستخدمين أموالهم.

تتولّد الموارد بطريقتين: الأولى عبر تجميد TRX، إذ يحصل الحساب عند قفل عملاته على حصة من مجموع Energy أو bandwidth العالمي تتجدد كل 24 ساعة. والثانية عبر استقبال تفويض من حساب آخر يُجمّد TRX ويُحوّل الموارد الناتجة إلى عنوانك. يستخدم حسابك الموارد المفوّضة تماماً كما لو كنت قد جمّدت بنفسك، ولا فرق من منظور الآلة الافتراضية بين الحالتين.

هذا هو الأساس الذي يقوم عليه كل شيء. فالتفويض ليس قناة دفع ولا طبقة وسيطة، بل هو نقل مباشر لحقوق الموارد على السلسلة من حساب إلى آخر.

ما الذي غيّره Stake 2.0 في آلية التفويض

كان النموذج الأصلي للتجميد (Stake 1.0) يُلزمك باختيار نوع المورد وقت التجميد، هل ستُنتج Energy أم bandwidth، ولم يكن بإمكانك إلغاء التجميد جزئياً بل كنت مضطراً لإلغاء المبلغ كاملاً بعد فترة قفل مدتها 3 أيام. وكان التفويض موجوداً لكنه كان مُقيّداً، إذ تُجمّد TRX فينتج مورد واحد ثم تُوجّه ذلك المورد اختيارياً إلى عنوان آخر.

جاء Stake 2.0 الذي أُطلق على الشبكة الرئيسية في منتصف عام 2023 ليُعيد هيكلة هذا النظام بشكل جوهري. أبرز التغييرات المتعلقة بالتفويض:

• تقسيم الموارد بشكل تناسبي: بات بإمكانك تقسيم الموارد الناتجة عن مركز تجميد واحد وتفويضها لعدة عناوين في آنٍ واحد. أنت لا تُرسل TRX إلى أحد، بل تُوزّع مخرجات الموارد فحسب.
• إلغاء التجميد على دفعات: أصبح بإمكانك إلغاء تجميد جزء من مبلغك دون المساس بالبقية، مما يمنح مزوّدي الموارد مرونة في إدارة سيولتهم دون تعطيل التفويضات النشطة.
• فترة انتظار 14 يوماً لاسترداد التجميد: بعد استدعاء أمر unstake، تدخل عملاتك في طابور انتظار لمدة 14 يوماً تقريباً قبل أن تتمكن من استدعاء withdrawExpireUnfreeze لاستردادها. والأهم من ذلك أن أي تفويض مرتبط بتلك العملات يُلغى فوراً عند بدء إلغاء التجميد، لا بعد انتهاء فترة الـ14 يوماً.
• إلغاء قيد تبديل نوع المورد: كان في النسخة الأولى تبديل المورد من Energy إلى bandwidth يستلزم إلغاء التجميد وإعادته من جديد. أما الآن فيمكنك إعادة تفويض مخرجات الموارد من نفس المركز إلى نوع مورد مختلف دون إلغاء التجميد، وإن كان ذلك لا يزال يستلزم معاملة منفصلة على السلسلة.

المعنى العملي لمن يستقبل Energy مفوّضة: رصيدك من الموارد قد ينهار فجأة في منتصف اليوم إذا بدأ المفوِّض في إلغاء تجميده، ولا توجد فترة سماح لمستقبل التفويض.

آلية معاملة التفويض على السلسلة

حين يستدعي المفوِّض أمر delegateResource، تُسجّل المعاملة ثلاثة عناصر: عنوان المفوِّض، وعنوان المستقبِل، وكمية Energy (أو bandwidth) المُفوَّضة. تقوم الشبكة بعدها بتعديل حدود الموارد الظاهرة في حالة حساب المستقبِل.

تتتبّع عُقد TRON داخلياً الموارد المفوّضة بشكل منفصل عن الموارد المملوكة ذاتياً. إن استعلمت عن حساب عبر wallet/getaccount في الـAPI، ستجد حقولاً مثل delegated_frozenV2_balance_for_energy وacquired_delegated_frozenV2_balance_for_energy. الأول يمثّل ما أرسلته للخارج، والثاني ما استقبلته. لا يتحرك TRX في كلتا الحالتين، إذ يظل في رصيد التجميد الخاص بالمفوِّض.

أما آلية استهلاك الموارد خلال المعاملة فتعمل هكذا: تتحقق الآلة الافتراضية من Energy المتاحة في الحساب المنفِّذ (المُجمَّدة ذاتياً والمستقبَلة عبر التفويض) فإن كانت كافية، خصمت من المجموع بترتيب معيّن: تُستهلك التفويضات المستقبَلة أولاً ثم المُجمَّدة ذاتياً. وإن نفدت البنية بالكامل، حُرق TRX من الرصيد الحر للحساب وفق السعر الشبكي الحالي، وهو سعر متغيّر يُحسب ديناميكياً بناءً على إجمالي Energy الشبكة وسعر الحرق المُحدَّد بمعاملات السلسلة.

كيف تتعافى Energy بعد الاستهلاك

Energy ليست رصيداً يُستخدم مرة واحدة. بل تتعافى بشكل خطّي تدريجي على مدار 24 ساعة. فإن كان الحد الأقصى لحسابك 100,000 واستهلكت 65,000 في تنفيذ عقد، عادت إلى الحد الأقصى بعد 24 ساعة. وعند منتصف الطريق أي بعد 12 ساعة، يكون لديك نحو 32,500 متاحة.

ينطبق هذا التعافي على كل من Energy المُجمَّدة ذاتياً والمفوَّضة. معدل التعافي مرتبط بالحد الأقصى للحساب لا بساعة عالمية ثابتة. ولذلك يتعافى حسابان بحدود مختلفة بمعدلات مطلقة مختلفة، وإن كان كلاهما يعود لطاقته الكاملة خلال 24 ساعة.

بالنسبة للعمليات كثيفة التكرار، تُشكّل دورة الـ24 ساعة هذه القيد الأساسي. تفويض مُصمَّم لمعاملة واحدة يومياً لن يستوعب عشر معاملات في اليوم، حتى لو بدا المجموع كافياً على الورق. عليك مراعاة إيقاع التعافي لا مجرد الطاقة الإجمالية.

إلغاء التفويض وإعادة توجيهه

التفويض ليس دائماً. يستطيع المفوِّض استدعاء unDelegateResource في أي وقت لاسترداد الموارد، والأثر فوري: تنخفض Energy المتاحة لدى المستقبِل بمقدار الكمية المسترَدة في الكتلة التالية مباشرة، دون أي فترة انتظار للمستقبِل ودون أي آلية تعويض على مستوى البروتوكول.

أما إعادة توجيه التفويض لمستقبِل آخر، فتستلزم معاملتين منفصلتين: إلغاء التفويض من المستقبِل الحالي ثم التفويض للمستقبِل الجديد. وكلتا العمليتين تستهلكان bandwidth بذاتهما. يتيح Stake 2.0 تجميع هذه العمليات بكفاءة أعلى من ذي قبل، لكنها لا تزال ليست ذرّية من منظور معاملة واحدة.

ثمة حالة حافّة تستحق الذكر: إذا كان TRX المُجمَّد لدى المفوِّض يُنتج 200,000 Energy وقد فوّض 150,000 للعنوان (أ)، يمكنه تفويض الـ50,000 المتبقية للعنوان (ب) دون المساس بتفويض (أ). القيد الوحيد هو ألا يتجاوز مجموع Energy المفوَّضة مجموع Energy المُنتَجة، وأي محاولة تجاوز هذا الحد ستُرفض على مستوى المعاملة.

ما يعنيه ذلك لتأجير الـEnergy

تعمل خدمات تأجير Energy مثل tronenergyrent.com ضمن نموذج التفويض هذا كلياً. حين تستأجر Energy، يُجمّد المزوّد TRX ويُنتج Energy ثم يستدعي delegateResource موجِّهاً إياها لعنوانك. من منظور حسابك، تستقبل acquired_delegated_frozenV2_balance_for_energy كما وصفنا تماماً. أنت لا تملك TRX، بل تملك تخصيصاً مؤقتاً للموارد.

مدة الإيجار تعادل المدة التي يُبقي فيها المزوّد ذلك التفويض نشطاً. إيجار ليوم واحد بالأسعار الحالية يكلّف 8.19 TRX مقابل 65,000 Energy (تكفي لتغطية معاملة تحويل USDT بمعيار TRC-20 التي تتطلب نحو 65,000 Energy وما يقارب 345 bandwidth). أما إيجار 30 يوماً فيبلغ 175.50 TRX لنفس كتلة الـEnergy. يمكنك حساب التكلفة الدقيقة لحجم التحويلات الخاصة بك عبر الآلة الحاسبة.

سبب ارتفاع تكلفة الإيجار قصير المدة بحساب اليوم الواحد ميكانيكي بحت: على المزوّد إدارة طابور الاسترداد وتكاليف إعادة التفويض في الدورات المتكررة. فترة انتظار الـ14 يوماً تعني تجميد رأس المال بصرف النظر عن قِصَر مدة الإيجار.

تفويض الـbandwidth يتبع المنطق ذاته

كل ما سبق ينطبق على bandwidth أيضاً، مع فارق واحد في السلوك الافتراضي. كل حساب يحصل على 600 bandwidth مجاناً يومياً من الشبكة بغض النظر عن التجميد. يكفي هذا المخصص للتحويلات الأساسية لعملة TRX، لكنه لا يغطي نصيب bandwidth في تحويلات TRC-20 عالية التكرار. تجميد العملات أو استقبال bandwidth مفوَّضة يرفع حدك فوق هذا الحد الأساسي البالغ 600.

حين تُفوِّض bandwidth لحساب ما، فأنت تُضيف لطاقته فوق أي مخصص مجاني لديه بالفعل. ترتيب الاستهلاك هو: bandwidth المجانية أولاً، ثم المفوَّضة، ثم المُجمَّدة ذاتياً، ثم حرق TRX. هذا الترتيب مهم إن أردت حساب متى سيبدأ الحرق بدقة لحساب بعينه.

قراءة حالة التفويض من الـAPI

إن كنت تبني أدوات برمجية أو تراقب تفويضاً معيّناً، فاستدعاءات الـAPI ذات الصلة هي:

• wallet/getaccount: تُعيد الحالة الكاملة للحساب بما فيها حقول الموارد المفوَّضة والمستقبَلة
• wallet/getdelegatedresourcev2: تُعيد سجل التفويض المحدد بين عنوانين، متضمنةً كمية Energy الدقيقة وتاريخ انتهاء القفل إن وُجد
• wallet/getcanwithdrawunfreezeamount: تتيح للمفوِّض التحقق من حجم ما بات قابلاً للسحب من طابور إلغاء التجميد

تتميّز نقطة getdelegatedresourcev2 بأهمية خاصة للتحقق من أن التفويض نشط وبالحجم الصحيح قبل تنفيذ معاملات تعتمد عليه. لا تفترض وجود التفويض لمجرد أنه أُعِدَّ بالأمس، بل تحقق دائماً من حالة السلسلة قبل الاعتماد عليه.