چگونه USDT TRC-20 را با حداقل کارمزد ارسال کنیم: یک بررسی فنی
چرا انتقالهای USDT TRC-20 اصلاً هزینه دارند
TRON کارمزد ثابتی برای تراکنش به شکلی که اتریوم دریافت میکند نمیگیرد. به جای آن، از دو منبع جداگانه استفاده میکند: انرژی و bandwidth. هر عملیات روی شبکه یکی یا هر دوی اینها را مصرف میکند. اگر حساب شما به اندازه کافی از هر کدام داشته باشد، انتقال عملاً رایگان است. اگر نداشته باشد، TRX سوزانده میشود تا کمبود را جبران کند.
برای یک انتقال استاندارد USDT TRC-20، شبکه تقریباً به 65,000 انرژی و 345 bandwidth نیاز دارد. هزینه انرژی از اجرای تابع transfer(address,uint256) داخل قرارداد هوشمند TRC-20 میآید. هزینه bandwidth بایتهای خام تراکنش سریالشده را پوشش میدهد. این دو منبع به طور مستقل مصرف میشوند، بنابراین کمبود یکی روی دیگری تأثیری ندارد.
نگهداشتن bandwidth نسبتاً آسان است. استیک کردن مقدار کمی TRX برای پوشش 345 بایت روی بیشتر کیف پولهای فعال bandwidth کافی تولید میکند. انرژی بخش گران است، زیرا اجرای قرارداد هوشمند آن را سریع مصرف میکند و یک انتقال واحد مقدار زیادی از آن را میبلعد.
در سطح ماشین مجازی هنگام یک انتقال TRC-20 چه اتفاقی میافتد
وقتی transfer(address _to, uint256 _value) را روی قرارداد USDT (TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t) فراخوانی میکنید، ماشین مجازی TRON راهاندازی میشود، بایتکد قرارداد را بارگذاری میکند و منطق سازگار با ERC-20 را اجرا میکند: دو اسلات ذخیرهسازی (موجودی فرستنده و گیرنده) را میخواند، محاسبات را انجام میدهد، دو مقدار بهروزرسانیشده را پس مینویسد و یک رویداد Transfer منتشر میکند. هر یک از این خواندنها و نوشتنهای ذخیرهسازی انرژی هزینه دارد و انتشار رویداد کمی بیشتر اضافه میکند. مجموع برای یک انتقال استاندارد به آدرسی که از قبل USDT دارد، به طور پیوسته حدود 65,000 انرژی میرسد.
اگر آدرس گیرنده هرگز USDT دریافت نکرده باشد، یا موجودی USDT آن در حال حاضر صفر باشد، عملیات نوشتن باید به جای بهروزرسانی یک اسلات موجود، یک اسلات ذخیرهسازی جدید در قرارداد ایجاد کند. این تغییر ساده هزینه انرژی را تقریباً دو برابر میکند: یک انتقال به گیرنده با موجودی صفر حدود 130,000 انرژی مصرف میکند، نه 65,000. هزینه کاملاً به وضعیت USDT گیرنده بستگی دارد. اینکه کیف پول فرستنده چند بار تراکنش انجام میدهد روی شارژ انرژی تأثیری ندارد.
مصرف bandwidth سادهتر است: TRON طول بایت تراکنش امضاشده را اندازهگیری میکند و آن را از سهمیه bandwidth شما کسر میکند. اگر حساب شما کمتر از 345 bandwidth در دسترس داشته باشد، شبکه به عنوان جایگزین TRX را با نرخ تقریباً 1000 SUN (0.001 TRX) به ازای هر بایت میسوزاند.
سه راه برای پوشش هزینه انرژی
سه گزینه واقعی دارید. هر کدام بسته به فراوانی ارسال شما اقتصاد متفاوتی دارند.
۱. سوزاندن TRX در محل
اگر کیف پول شما هیچ منبع استیکشدهای ندارد، شبکه به طور خودکار TRX را برای پوشش هم انرژی و هم bandwidth میسوزاند. نرخ سوزاندن انرژی بر اساس تقاضای شبکه نوسان دارد. برای یافتن هزینه فعلی به TRX برای دقیقاً 65,000 انرژی، به جای تکیه بر عددی ثابت در اینجا به صفحه قیمتگذاری مراجعه کنید، زیرا عامل پویای انرژی این رقم را به طور منظم تنظیم میکند.
سوزاندن برای انتقالهای گاهبهگاه به خوبی کار میکند. مشکل این است که هر انتقال واحد TRX واقعی هزینه دارد و هیچ مزیت انباشتی وجود ندارد. هر بار قیمت کامل را میپردازید.
۲. استیک کردن TRX برای تولید انرژی
تحت Stake 2.0 (که از آوریل ۲۰۲۳ روی شبکه اصلی فعال است)، استیک کردن از طریق freezeBalanceV2(uint256 frozenBalance, uint256 resourceType) با resourceType = 1 برای انرژی انجام میشود. مبلغ استیکشده به شما سهمی متناسب از کل مخزن انرژی شبکه میدهد. مخزن به طور خطی ظرف 24 ساعت به طور کامل بازیابی میشود (به طور خطی تا 100% در 24h پس از مصرف کامل) و بازده انرژی به ازای هر TRX با تغییر کل استیک شبکه تغییر میکند.
مشکل مقیاس است. مقدار TRX که برای تولید قابل اعتماد 65,000 انرژی در روز (کافی برای یک انتقال USDT) باید استیک کنید قابل توجه است، زیرا برای سهمی از کل محدودیت انرژی شبکه رقابت میکنید. برای کیف پولهایی که بیش از چند انتقال در روز ارسال میکنند، سرمایه قفلشده در استیکینگ در مقایسه با اجاره از نظر اقتصادی منطقی نیست، به خصوص با توجه به دوره انتظار آنفریز 14 روزه تحت Stake 2.0.
Stake 2.0 همچنین قابلیت تفویض منابع استیکشده به آدرس دیگری از طریق delegateResource را معرفی کرد، که سازوکاری است که سرویسهای اجاره انرژی روی آن ساخته میشوند.
۳. اجاره انرژی
اجاره انرژی یعنی شخص ثالثی انرژی را برای مدت ثابت به آدرس شما تفویض میکند. شما یک کارمزد TRX کوچک میپردازید، انرژی در حساب شما ظاهر میشود، انتقال را اجرا میکنید و تفویض منقضی میشود. هیچ TRX برای اجرای واقعی قرارداد سوزانده نمیشود.
قیمت اجاره به ازای هر سطح زمانی است: 1h، 1d، 3d، 30d. مدتهای کوتاهتر از نظر TRX مطلق کمتر هزینه دارند زیرا استیک TRX زیربنایی پلتفرم مدت کمتری قفل میشود. مدتهای طولانیتر بیشتر هزینه دارند زیرا قفل سرمایه طولانیتر است. برای اعداد زنده TRX به ازای هر سطح و هر مقدار انرژی، به قیمتگذاری مراجعه کنید.
سطح 1h برای یک انتقال واحد که میخواهید فوراً اجرا کنید منطقی است. سطحهای طولانیتر برای مواردی وجود دارند که میخواهید قیمتگذاری ثابت در طول یک بازه گسترده داشته باشید یا میخواهید از سفارشدهی مجدد هر بار که ارسال میکنید جلوگیری کنید.
تفویض واقعاً چگونه در حساب شما قرار میگیرد
وقتی یک سرویس اجاره انرژی را به شما تفویض میکند، میتوانید آن را روی شبکه تأیید کنید. wallet/getaccount را برای آدرس خود پرسوجو کنید و به acquired_delegated_frozenV2_balance_for_energy نگاه کنید که کل استیک TRX تفویضشده به حساب شما برای انرژی است. همچنین میتوانید از wallet/getdelegatedresourcev2 برای دیدن جزئیات هر تفویضکننده، شامل هر گونه انقضای قفل، استفاده کنید.
انرژی تفویضشده بلافاصله قابل استفاده است. نیاز نیست کار خاصی انجام دهید: دفعه بعدی که یک فراخوانی قرارداد هوشمند را راهاندازی میکنید، TVM از موجودی انرژی در دسترس شما برداشت میکند، که اکنون شامل مبلغ تفویضشده میشود.
یک نکته را به وضوح درک کنید: وقتی N انرژی را برای یک بازه ثابت اجاره میکنید، پلتفرم یک مخزن از استیک TRX زیربنایی را به آدرس شما تفویض میکند که در زمان تفویض به N انرژی تبدیل میشود. آن انرژی یک بار در طول بازه مصرف میشود. برای گیرنده در میانه اجاره دوباره پر نمیشود. سطح زمانی که انتخاب میکنید فقط کنترل میکند که استیک TRX پلتفرم چه مدت به آدرس شما قفل میماند، نه اینکه چند دسته انرژی جداگانه دریافت میکنید. بنابراین کوتاهترین مدتی که مصرف شما را به راحتی در بر میگیرد را انتخاب کنید و انرژی کافی را از قبل اجاره کنید تا آنچه را که قصد ارسالش را دارید پوشش دهد.
بهینهسازی برای الگوهای ارسال مختلف
اگر USDT را به طور پراکنده ارسال میکنید (چند بار در ماه)، اجاره 1h به صورت درخواستی تقریباً همیشه بهترین حرکت است. فقط زمانی پرداخت میکنید که ارسال میکنید و TRX خود را در استیک یا پرداخت برای ظرفیت بیکار قفل نمیکنید.
اگر یک خط لوله برداشت صرافی، یک پردازشگر پرداخت یا هر برنامهای را اجرا میکنید که دهها انتقال در روز انجام میدهد، ظرفیت را از قبل برنامهریزی کنید. بودجه انرژی خود را برای بازهای که میخواهید پوشش دهید تخمین بزنید (انتقال در هر بازه × 65,000، به علاوه ذخیره برای هر گیرنده با موجودی صفر به ازای 130,000 هر کدام) و یک سفارش اجاره واحد به اندازه آن بودجه ثبت کنید. در آن حجم، همچنین به داشبورد و API نگاه کنید تا سفارشها را خودکار کنید و موجودی باقیمانده خود را به صورت برنامهنویسی نظارت کنید.
یک نکته که به راحتی نادیده گرفته میشود: همیشه bandwidth کافی نگه دارید. استیک کردن حتی مقدار کمی TRX برای bandwidth تضمین میکند که هزینه 345 بایت هر انتقال همیشه بدون سوزاندن TRX اضافی پوشش داده میشود. ترکیب این با انرژی اجارهشده به این معنی است که هزینه مؤثر شما به ازای هر انتقال فقط کارمزد اجاره است، نه چیز اضافی.
مسیر واقعاً ارزان
برای یک انتقال گاهبهگاه واحد، 65,000 انرژی را برای 1h اجاره کنید و مطمئن شوید که حساب شما bandwidth استیکشده دارد. سطح 1h ارزانترین مسیر به TRX است و معمولاً از هزینه پویای سوزاندن TRX برای همان انتقال ارزانتر است. برای عدد فعلی به قیمتگذاری مراجعه کنید.
برای فرستندگان مکرر، اجاره را متناسب با حجم واقعی انتقال خود در بازهای که میخواهید پوشش دهید تنظیم کنید، کوتاهترین مدتی که آن بازه را در بر میگیرد را انتخاب کنید و bandwidth را استیکشده نگه دارید تا هرگز کارمزد جایگزین به ازای هر بایت سوزاندن را نپردازید.
این مدل به برنامهریزی پاداش میدهد. فراوانی ارسال خود را بدانید، مدت زمان اجاره را که با آن مطابقت دارد انتخاب کنید و بودجه انرژی را به اندازه بار کاری واقعی خود تنظیم کنید نه اینکه به طور انعکاسی طولانیترین سطح را بخرید.