نگاهی عمیق به مکانیزم تفویض منابع در TRON: از درون شبکه چه خبر است؟

مدل منابع در TRON؛ پیش از هر چیز باید این را بدانید

TRON برخلاف اتریوم، مفهومی به نام کارمزد گاز ندارد. در عوض، هر حساب دو مخزن منابع جداگانه دارد: Energy و bandwidth. Energy در اجرای قراردادهای هوشمند مصرف می‌شود و bandwidth در هر تراکنش، چه با قرارداد سروکار داشته باشد چه نداشته باشد. اگر موجودی هر یک از این دو منبع تمام شود، شبکه مستقیماً از موجودی TRX حساب شما کسر می‌کند تا کمبود را جبران کند. همین سوختن TRX است که هزینه‌ها را بالا می‌برد.

منابع از دو طریق به دست می‌آیند: اول، از طریق استیک کردن TRX؛ با قفل کردن TRX، شبکه سهمی متناسب از مخزن جهانی Energy یا bandwidth را به حساب شما اعتبار می‌دهد و این سهم هر ۲۴ ساعت یک‌بار بازیابی می‌شود. دوم، از طریق دریافت تفویض؛ یعنی حساب دیگری TRX استیک می‌کند و منابع حاصل از آن را به آدرس شما اختصاص می‌دهد. حساب شما از این منابع تفویض‌شده دقیقاً مثل منابع خودش استفاده می‌کند. از دید ماشین مجازی، هیچ تفاوتی وجود ندارد.

این همان پایه‌ای است که همه چیز روی آن بنا شده است. تفویض نه یک کانال پرداخت است و نه یک لایه واسط. بلکه یک انتساب مستقیم از حقوق منابع روی زنجیره، از یک حساب به حساب دیگر است.

Stake 2.0 چه چیزی را در تفویض تغییر داد؟

در مدل استیک اولیه (Stake 1.0) باید در لحظه استیک مشخص می‌کردید که TRX شما Energy تولید کند یا bandwidth، و برای آزادسازی هم مجبور بودید کل مبلغ را یک‌جا پس از ۳ روز قفل آزاد کنید. تفویض وجود داشت اما بسیار محدود بود؛ TRX استیک می‌کردید، یک نوع منبع تولید می‌شد و در نهایت می‌توانستید آن منبع را به آدرس دیگری اختصاص دهید.

Stake 2.0 که در اواسط سال ۲۰۲۳ روی شبکه اصلی فعال شد، این ساختار را به‌طور قابل توجهی بازآرایی کرد. مهم‌ترین تغییرات مربوط به تفویض عبارتند از:

• تقسیم منابع به‌صورت نسبی: یک موقعیت استیک‌شده می‌تواند منابع تولیدشده‌اش را به‌طور همزمان بین چند آدرس مختلف تقسیم و تفویض کند. شما TRX را جایی ارسال نمی‌کنید، بلکه فقط مسیر خروجی منابع را تعیین می‌کنید.
• آزادسازی تدریجی: می‌توانید بخشی از موجودی استیک‌شده را بدون دست زدن به بقیه آزاد کنید. این قابلیت به ارائه‌دهندگان منابع امکان می‌دهد نقدینگی خود را مدیریت کنند بدون اینکه تفویض‌های فعال مختل شوند.
• تاخیر ۱۴ روزه در آزادسازی: پس از فراخوانی unstake، TRX وارد صف برداشت می‌شود و حدود ۱۴ روز قفل می‌ماند تا بتوانید با withdrawExpireUnfreeze آن را پس بگیرید. اما نکته مهم اینجاست: در طول این مدت، هر تفویضی که به آن TRX متکی بود، فوری لغو می‌شود، نه بعد از ۱۴ روز. تفویض همزمان با شروع فرآیند آزادسازی پایان می‌یابد، نه وقتی TRX به دست شما می‌رسد.
• حذف قفل تغییر نوع منبع: در نسخه ۱.0، برای تغییر از Energy به bandwidth باید کل چرخه آزادسازی و استیک مجدد را طی می‌کردید. در نسخه ۲.0، می‌توانید خروجی منبع همان موقعیت استیک‌شده را بدون آزادسازی به نوع دیگری هدایت کنید، هرچند این کار همچنان به یک تراکنش جداگانه روی زنجیره نیاز دارد.

نتیجه عملی برای کسی که Energy تفویض‌شده دریافت می‌کند این است: اگر تفویض‌دهنده فرآیند آزادسازی را آغاز کند، موجودی منابع شما ممکن است در اواسط روز به صفر برسد. هیچ مهلت یا دوره تنفسی برای طرف دریافت‌کننده وجود ندارد.

مکانیزم درونی یک تراکنش تفویض روی زنجیره

وقتی تفویض‌دهنده تابع delegateResource را فراخوانی می‌کند، تراکنش سه چیز را ثبت می‌کند: آدرس تفویض‌دهنده، آدرس دریافت‌کننده و مقدار Energy یا bandwidth که تفویض می‌شود. سپس شبکه محدودیت‌های منابع نمایش‌داده‌شده در وضعیت حساب دریافت‌کننده را به‌روز می‌کند.

در سطح داخلی، گره‌های TRON منابع تفویض‌شده را جدا از منابع خودِ حساب پیگیری می‌کنند. اگر یک حساب را از طریق wallet/getaccount در HTTP API جستجو کنید، فیلدهایی مثل delegated_frozenV2_balance_for_energy و acquired_delegated_frozenV2_balance_for_energy خواهید دید. اولی نشان‌دهنده منابعی است که شما به دیگران تفویض کرده‌اید و دومی منابعی است که از دیگران دریافت کرده‌اید. در هر دو حالت، هیچ TRX جابه‌جا نمی‌شود. TRX واقعی در موجودی استیک‌شده تفویض‌دهنده باقی می‌ماند.

مصرف منابع در حین اجرای یک تراکنش به این شکل است: ماشین مجازی ابتدا Energy موجود حساب اجراکننده را بررسی می‌کند که شامل منابع خودِ حساب و منابع دریافت‌شده از طریق تفویض است. اگر کافی باشد، به این ترتیب کسر می‌شود: اول منابع تفویض‌شده دریافتی مصرف می‌شوند، بعد منابع استیک‌شده خودِ حساب. اگر مخزن تمام شود، TRX از موجودی آزاد حساب با نرخ جاری شبکه سوزانده می‌شود. این نرخ ثابت نیست؛ به‌صورت پویا بر اساس کل Energy شبکه و قیمت سوختن تعیین‌شده توسط پارامترهای زنجیره محاسبه می‌شود.

Energy بعد از مصرف چطور بازیابی می‌شود؟

Energy یک اعتبار یک‌بار مصرف نیست. Energy مصرف‌شده طی یک پنجره ۲۴ ساعته به‌صورت خطی بازیابی می‌شود. مثلاً اگر سقف Energy حساب شما ۱۰۰٫۰۰۰ باشد و ۶۵٫۰۰۰ از آن را در اجرای یک قرارداد مصرف کنید، پس از ۲۴ ساعت به سطح کامل برمی‌گردید. در نقطه میانی یعنی ۱۲ ساعت بعد، حدود ۳۲٫۵۰۰ Energy در دسترس خواهید داشت.

این بازیابی هم برای Energy خودِ حساب و هم برای Energy تفویض‌شده اعمال می‌شود. نرخ بازیابی به سقف حساب بستگی دارد، نه به یک ساعت جهانی ثابت. بنابراین دو حساب با سقف‌های متفاوت، سرعت بازیابی مطلق متفاوتی دارند، حتی اگر هر دو در ۲۴ ساعت به طور کامل پر شوند.

برای عملیات‌های پرتکرار، همین چرخه ۲۴ ساعته است که تعیین‌کننده اصلی است. یک تفویض که برای یک تراکنش در روز کافی است، ده تراکنش در روز را پوشش نمی‌دهد، حتی اگر روی کاغذ کل Energy کافی به نظر برسد. باید ریتم بازیابی را در نظر بگیرید، نه فقط ظرفیت کل را.

لغو و واگذاری مجدد تفویض‌ها

تفویض دائمی نیست. تفویض‌دهنده می‌تواند در هر زمانی با فراخوانی unDelegateResource منابع را پس بگیرد. تأثیر آن فوری است: Energy موجود دریافت‌کننده در بلاک بعدی به میزان مقدار لغوشده کاهش می‌یابد. هیچ دوره انتظاری برای طرف دریافت‌کننده وجود ندارد و هیچ مکانیزم جبرانی در سطح پروتکل پیش‌بینی نشده است.

برای واگذاری مجدد یک تفویض یعنی انتقال همان خروجی منبع به دریافت‌کننده دیگری، دو تراکنش جداگانه لازم است: اول لغو تفویض از دریافت‌کننده فعلی، سپس تفویض به دریافت‌کننده جدید. این دو عملیات روی زنجیره جداگانه هستند و خودشان bandwidth مصرف می‌کنند. در Stake 2.0 می‌توانید این کارها را کارآمدتر از قبل انجام دهید، اما از نظر یک تراکنش واحد، همچنان اتمیک نیستند.

یک حالت لبه‌ای که ارزش دانستن دارد: اگر TRX استیک‌شده یک تفویض‌دهنده مثلاً ۲۰۰٫۰۰۰ Energy تولید کند و ۱۵۰٫۰۰۰ آن را به آدرس A تفویض کرده باشد، می‌تواند ۵۰٫۰۰۰ باقیمانده را به آدرس B تفویض کند بدون اینکه تفویض A دست بخورد. محدودیت اینجاست که مجموع Energy تفویض‌شده نمی‌تواند از مجموع Energy تولیدشده بیشتر باشد. هر تلاشی برای تفویض بیش از حد ظرفیت، در سطح تراکنش با خطا مواجه خواهد شد.

این مدل چه معنایی برای اجاره Energy دارد؟

سرویس‌های اجاره Energy مانند tronenergyrent.com کاملاً در چارچوب همین مدل تفویض فعالیت می‌کنند. وقتی Energy اجاره می‌کنید، ارائه‌دهنده TRX استیک می‌کند، Energy تولید می‌کند و سپس delegateResource را به آدرس شما فراخوانی می‌کند. از دید حساب شما، acquired_delegated_frozenV2_balance_for_energy دریافت می‌کنید، دقیقاً همان‌طور که بالاتر توضیح داده شد. شما TRX نگه نمی‌دارید، بلکه یک تخصیص منبع موقت در اختیار دارید.

مدت اجاره به همان مدتی بستگی دارد که ارائه‌دهنده آن تفویض را فعال نگه می‌دارد. اجاره ۱ روزه در قیمت‌های فعلی برای ۶۵٫۰۰۰ Energy معادل ۸.۱۹ TRX هزینه دارد که برای پوشش یک انتقال استاندارد TRC-20 USDT با مصرف حدود ۶۵٫۰۰۰ Energy و ۳۴۵ bandwidth کافی است. اجاره ۳۰ روزه برای همان بلاک Energy به ۱۷۵.۵۰ TRX می‌رسد. می‌توانید هزینه دقیق بر اساس حجم تراکنش‌های خود را با ماشین حساب محاسبه کنید.

دلیل گران‌تر بودن اجاره‌های کوتاه‌مدت به ازای هر روز کاملاً فنی است: ارائه‌دهنده باید صف آزادسازی و هزینه‌های تفویض مجدد را برای چرخه‌های پرتکرار مدیریت کند. تاخیر ۱۴ روزه در برداشت یعنی سرمایه در هر صورت قفل می‌ماند، صرف‌نظر از اینکه مدت اجاره چقدر کوتاه باشد.

تفویض bandwidth هم از همین مدل پیروی می‌کند

همه آنچه گفته شد برای bandwidth هم به همان شکل صدق می‌کند، با یک تفاوت در رفتار پیش‌فرض. هر حساب بدون توجه به استیک، روزانه ۶۰۰ bandwidth رایگان از شبکه دریافت می‌کند. این سهم رایگان انتقال‌های ساده TRX را پوشش می‌دهد، اما برای bandwidth لازم برای انتقال‌های پرتکرار TRC-20 کافی نیست. استیک کردن یا دریافت bandwidth تفویض‌شده، سقف شما را بالاتر از آن ۶۰۰ واحد پایه می‌برد.

وقتی bandwidth را به یک حساب تفویض می‌کنید، به ظرفیت آن حساب علاوه بر هر سهم رایگانی که دارد اضافه می‌شود. ترتیب مصرف به این شکل است: اول bandwidth رایگان، سپس bandwidth تفویض‌شده، بعد bandwidth استیک‌شده خودِ حساب و در نهایت سوختن TRX. این ترتیب اهمیت دارد، به‌خصوص وقتی می‌خواهید دقیقاً حساب کنید چه زمانی سوختن TRX برای یک حساب مشخص شروع می‌شود.

خواندن وضعیت تفویض از طریق API

اگر ابزاری می‌سازید یا می‌خواهید یک تفویض را رصد کنید، فراخوانی‌های API مرتبط عبارتند از:

• wallet/getaccount: وضعیت کامل حساب را برمی‌گرداند، از جمله فیلدهای منابع تفویض‌شده و دریافت‌شده
• wallet/getdelegatedresourcev2: رکورد دقیق تفویض بین دو آدرس مشخص را برمی‌گرداند، از جمله مقدار دقیق Energy و تاریخ انقضای قفل، اگر قفلی تنظیم شده باشد
• wallet/getcanwithdrawunfreezeamount: به تفویض‌دهنده اجازه می‌دهد بررسی کند چه مقدار از آزادسازی‌های صف‌شده‌اش در حال حاضر قابل برداشت است

اندپوینت getdelegatedresourcev2 به‌ویژه برای تأیید فعال بودن تفویض و صحیح بودن مقدار آن، پیش از اجرای تراکنش‌هایی که به آن وابسته‌اند، بسیار مفید است. فرض نکنید چون دیروز تفویض تنظیم شده، حتماً همچنان فعال است. همیشه قبل از تکیه بر آن، وضعیت را روی زنجیره تأیید کنید.