TRC-20送金手数料を分解：エネルギー、bandwidth、そして実際に課金されるもの
2つのリソース、1つのトランザクション
TRON上のすべてのTRC-20送金は、bandwidthとエネルギーという2つの異なるリソースを消費します。これらは別々に請求され、別々のプールから引き出され、補充メカニクスも完全に異なります。ほとんどの開発者はどちらか一方を理解していますが、両者の相互作用こそがコストを管理可能に保つか、急騰させるかの分かれ目です。
bandwidthは、トランザクションをネットワークにブロードキャストする際の生バイトコストをカバーします。エネルギーは、スマートコントラクトロジックを実行するVM実行コストをカバーします。シンプルなTRX送金はbandwidthだけが必要です。トークンコントラクトのtransfer(address,uint256)関数をトリガーするTRC-20送金は両方が必要です。
bandwidth：シンプルな半分
すべてのTRONアカウントは、ベースラインの割り当てを通じて1日600の無料bandwidthを取得します。標準的なTRC-20送金トランザクションは通常約345バイトで、これは約345 bandwidth単位にマッピングされます（ネットワークは署名やメモフィールドを含むトランザクションデータのバイトごとに1 bandwidthを課金します）。
アカウントに十分な無料の1日bandwidthまたはbandwidthのためにステーキングされたTRXがある場合、トランザクションはこの面でコストがかかりません。bandwidthプールが空の場合、ネットワークは1 bandwidth単位あたり0.001 TRXのレート（1バイトあたり1000 SUN）で直接TRXをバーンします。345単位のトランザクションでは、ステーキング不要で送信アドレスから0.345 TRXがバーンされます。
無料の1日600単位は00:00 UTCにリセットされます。低ボリュームの送金を行っている場合、bandwidthコストにほとんど当たることはありません。高ボリュームの送信者は通常、ステーキング利回りがバーンレートよりもTRXあたり多くのトランザクションをカバーするため、バーンではなくbandwidthのためにTRXをステーキングします。
エネルギー：実際のコストが存在する場所
USDT TRC-20送金は約65,000 energyを消費します。その数値はTRON仮想マシン内のEVM互換バイトコード実行から来ています。コントラクトの残高マッピングへのストレージ読み書き、Transferログのイベント発行、内部の安全チェックです。正確な数値は、ストレージスロットが初めて書き込まれる（コールド）か更新される（ウォーム）かによってわずかに変動する可能性がありますが、2つのアクティブなアドレス間の典型的なUSDT送金では65,000が標準的な数値です。現在のUSDT残高がゼロの受信者への送金は、新しいストレージスロットが割り当てられるため約2倍の約130,000 energyになります。
エネルギーには2つのソースがあります。自分のステーキング済みTRX、またはサードパーティからレンタル（委任）されたエネルギーです。TRXをステーキングするとネットワーク全体のエネルギープールに対する比例的な持分が得られ、プールは24時間で線形的に100%まで再生されます。ステーキング済みTRXあたりの正確なエネルギー比率は、ネットワーク全体のステーキング額に依存し、時間とともに変動します。自分のステークだけから65,000 energyを回復するにはかなりの量のTRXをロックする必要があります。これがエネルギーレンタルが存在する理由です。
エネルギーが尽きたときに起きること
トランザクションが65,000 energyを必要とし、アカウントに十分な利用可能エネルギーがない場合、ネットワークは静かに部分実行を処理することはありません。代わりに、トランザクションのfee_limitを確認し、その限度までアカウントからTRXをバーンしてエネルギー不足をカバーし、その後トランザクション全体を実行します。不足分がfee_limitを超える場合、状態変更がコミットされる前にトランザクションは失敗します。
これは避けたいシナリオです。ステーキング済みエネルギーとバーンされたTRXの両方を支払うか、さらに悪いことにfee_limitが低すぎてトランザクション自体が失敗することになります。戦略を確定する前に、65,000 energyをカバーするための現在のTRXコストを価格ページで確認できます。
Stake 2.0が委任の仕組みを変えた
Stake 2.0（2023年4月にメインネットで有効化）以前は、ステーキングと委任が絡み合っていました。リソース所有者はfreezeBalanceを呼び出し、受信者アドレスを直接指定し、フリーズはその受信者に紐付けられ、リソースマーケットに必要な柔軟性はモデルに含まれていませんでした。
Stake 2.0はfreezeBalanceV2を導入し、ステーキング操作を委任操作から分離しました。これでTRXを個人のエネルギーまたはbandwidthプールにステーキングし、そのリソースをdelegateResource経由で別途委任します。これは次のことを意味します：
- 委任はデフォルトで取り消し可能で、アンステークなしに再割り当てできます。オプションの
lockフラグがあります。trueに設定すると、ネットワークの最小ロック期間（現在3d）の間少なくとも委任が保持されます。そのフラグなしでは、いつでも委任を引き戻せます。 - 14日間のアンフリーズ待機期間は、引き出し時の基となるTRXステークに適用され、委任自体には適用されません。
- エネルギーレンタルプラットフォームは、単一のステーキング済みポジションから多くの受信者アドレスにわたって委任をサイクルできます。
オンチェーンで、tronenergyrent.comのようなレンタルプラットフォームがアドレスにエネルギーを委任すると、委任額はアカウント状態に反映され、wallet/getaccount経由でacquired_delegated_frozenV2_balance_for_energyとして確認できます。対応する使用可能エネルギーはアカウントのエネルギー限度に対して表示され、こちら側で何の操作もなくすぐに使用可能です。
レンタルコスト対バーンコスト
レンタルは期間階層ごとに価格設定されます。1h、1d、3d、30dです。1h階層は絶対TRXで最安、30d階層は最も高価で、1dと3dはその中間です。価格設定は、プラットフォームの基となるTRXステークがアドレスにどれだけ長くロックされるかを反映しています。期間が長い = 資本がより多く拘束される = TRXがより多く請求されます。階層ごとの現在のTRX数値については、価格を参照してください。
バーンと比較すると、レンタルは事前計画する送信者に対してほぼ常に勝ります。ネットワークの動的レートで65,000 energy全部をバーンするのはシンプルですが、その時点での現在のバーンコストにさらされます。これはネットワーク全体のエネルギー需要が変化すると急激に動く可能性があります。レンタルは注文時に固定のTRXコストを提供します。
実行時のリソース優先順序
トランザクションが実行されるとき、VMは特定の順序でエネルギーを消費します：
- 他のアカウントからアドレスに委任されたリソースに裏付けられたエネルギー
- 自分のステーキング済みTRXからのエネルギー
- 残りの不足分をカバーするためにアカウントからバーンされるTRX（
fee_limitで上限あり）
この順序はレンタル戦略にとって重要です。委任されたエネルギーは自分のステークの前に消費されます。そのため、自分のステーキング済みエネルギーとレンタルされたエネルギーの両方を持っている場合、レンタル分が先に消費されます。レンタル期間が期限切れになり委任が回収されると、アカウントは自分のステーキング残高、それが不十分であればTRXバーンにフォールバックします。
bandwidthも同じ優先順位に従います。1日の無料割り当てが最初、次にステーキング済みbandwidth、その後TRXバーンです。クロスリソース代替はありません。余ったエネルギーをbandwidth不足のカバーに使用することはできません。
オンチェーンでアカウントのリソース状態を読む
TRON APIエンドポイントwallet/getaccountresourceは、知っておくべきフィールドを含むJSONオブジェクトを返します：
EnergyLimit：自分のステークから現在アカウントで利用可能な総エネルギーEnergyUsed：現在の24時間ウィンドウで消費されたエネルギーTotalEnergyLimit：ネットワーク全体の総エネルギー（ステークとエネルギーの比率を計算するのに役立つ）TotalEnergyWeight：エネルギーのためのネットワーク全体の総ステーク重みfreeNetLimit：1日の無料bandwidth割り当て（通常600）NetLimit：自分のステーキング済みTRXからのbandwidthNetUsed：今日消費されたbandwidthTotalNetLimit、TotalNetWeight：bandwidthのネットワーク全体の合計
他者によってアドレスに委任されたエネルギー量を確認するには、wallet/getaccountをクエリし、acquired_delegated_frozenV2_balance_for_energyフィールドを読んでください。ロック期限を含む委任者ごとの詳細については、wallet/getdelegatedresourcev2を使用してください。
TRC-20送金をプログラムで送るシステムを構築している場合、ブロードキャスト前にこれらのエンドポイントをポーリングすることで、予期しないTRXバーンを引き起こす前に低エネルギー状態を検出できます。APIドキュメントは、自動化されたワークフローにリソースチェックとエネルギー注文を統合する方法をカバーしています。
トークンコントラクトのエネルギー消費が異なる理由
USDTの65,000 energyという数値はTR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6tのTetherコントラクトに特有です。他のTRC-20コントラクトは異なります。追加のロジック（送金時手数料メカニクス、ルーター用のアローワンスチェック、複数のトピックのイベント発行）を持つトークンコントラクトは、呼び出しあたりより多くのエネルギーを消費します。最小限のERC-20スタイルのコントラクトは30,000未満になる可能性があります。
コントラクトの実際のエネルギーコストを知る唯一の信頼できる方法は、トランザクションをシミュレートするか、ブロックエクスプローラーでその特定のコントラクトの過去の実行記録を確認することです。すべてのTRC-20トークンに対してUSDTの数値を一律に適用しないでください。
