TRONのリソース委任の仕組みを徹底解説

委任を理解するために知っておくべきリソースモデル

TRONはイーサリアムのようなガス代の仕組みを採用していません。代わりに、すべてのアカウントにはEnergyとbandwidthという2種類のリソースプールが存在します。Energyはスマートコントラクトの実行時に消費され、bandwidthはコントラクトの有無にかかわらずすべてのトランザクションで消費されます。どちらかのリソースが不足すると、ネットワークはアカウントの残高からTRXを焼却（バーン）して不足分を補います。このバーンこそが、手数料を高くする要因です。

リソースを獲得する方法は2つあります。1つ目はTRXをステーキングすること。TRXをロックすると、ネットワークはグローバルなEnergyまたはbandwidthプールに対する比例した配分をアカウントに付与し、これは24時間ごとに更新されます。2つ目は委任を受け取ること。別のアカウントがTRXをステーキングし、その結果得られたリソースをあなたのアドレスに割り当てます。委任されたリソースは、自分でステーキングした場合とまったく同じように使用できます。仮想マシン（VM）の観点からは、両者に区別はありません。

これがすべての基盤となる考え方です。委任とは、支払いチャネルでも何かのラッパーでもなく、オンチェーンのリソース権限をあるアカウントから別のアカウントへ直接割り当てる仕組みです。

Stake 2.0で委任の何が変わったのか

旧来のステーキングモデル（Stake 1.0）では、ステーキング時にEnergyかbandwidthのどちらを生成するかを選択する必要があり、3日間のロック期間後に全額を一括でアンフリーズすることしかできませんでした。委任機能は存在していましたが、柔軟性に欠けていました。TRXをステークすると1種類のリソースが生成され、そのリソースを任意で別のアドレスに向けることができるという仕組みでした。

2023年半ばにメインネットで有効化されたStake 2.0では、この仕組みが大きく刷新されました。委任に関連する主な変更点は以下の通りです。

• リソースの分割委任：1つのステーキングポジションから生成されたリソースを、複数のアドレスに同時に分割して委任できるようになりました。TRXを送るのではなく、リソースの出力先を振り分けるイメージです。
• 部分的なアンステーキング：ステーキングポジション全体に影響を与えることなく、一部の金額だけアンステーキングできるようになりました。これにより、リソース提供者は既存の委任を中断せずに流動性を管理できます。
• 14日間のアンステーキング遅延：unstakeを呼び出すと、TRXは引き出し待ちのキューに入ります。withdrawExpireUnfreezeを呼び出して実際に受け取れるまで、約14日間ロックされます。この期間中、該当するTRXに依存していた委任はすぐに解除されます。14日後ではなく、アンステーキングを開始した時点で委任が終了する点に注意が必要です。
• リソースタイプの切り替えロックの廃止：Stake 1.0では、Energyからbandwidthへの切り替えには完全なアンステーキングと再ステーキングが必要でした。Stake 2.0では、アンステーキングなしで同じステーキングポジションのリソース出力を別のリソースタイプに再委任できます。ただし、依然として別途オンチェーントランザクションが必要です。

委任されたEnergyを受け取る側にとっての実際的な影響として、委任者がアンステーキングを開始すると、その日の途中でリソース残高がゼロになる可能性があります。受け取る側に猶予期間はありません。

委任トランザクションのオンチェーン上の仕組み

委任者がdelegateResourceを呼び出すと、トランザクションには3つの情報が記録されます。委任者のアドレス、受取人のアドレス、そして委任されるEnergyまたはbandwidthの量です。その後、ネットワークは受取人のアカウント状態に表示されるリソース上限を更新します。

内部的には、TRONノードは委任されたリソースと自己保有のリソースを別々に追跡しています。HTTP APIのwallet/getaccountでアカウントを照会すると、delegated_frozenV2_balance_for_energyやacquired_delegated_frozenV2_balance_for_energyといったフィールドを確認できます。前者は自分が送り出した量、後者は自分が受け取った量です。どちらもTRXを移動させるものではなく、実際のTRXは委任者のステーキング残高に留まり続けます。

トランザクション中のリソース消費の流れは次の通りです。VMは実行中のアカウントで利用可能なEnergy（自己ステーキング分と受け取った委任分の合計）を確認します。十分であれば、そのプールから順番に差し引かれます。受け取った委任分が先に消費され、次に自己ステーキング分が消費されます。プールが枯渇すると、現在のネットワークレートでアカウントの残高からTRXがバーンされます。このレートは固定ではなく、ネットワーク全体のEnergyの総量とオンチェーンパラメータで設定されたバーン価格に基づいて動的に計算されます。

使用後のEnergyの回復の仕組み

Energyは使い切りのクレジットではありません。使用したEnergyは24時間かけて直線的に回復します。たとえば、アカウントの最大Energy上限が100,000で、コントラクト実行で65,000を使用した場合、24時間後には満タンの状態に戻ります。12時間後の時点では、およそ32,500が利用可能になっています。

この回復は自己ステーキング分にも委任されたEnergyにも同様に適用されます。回復速度はアカウントの最大上限に連動しており、グローバルな固定タイマーとは無関係です。そのため、Energy上限が異なる2つのアカウントでは、どちらも24時間で完全回復するとはいえ、絶対的な回復速度は異なります。

高頻度の処理を行う場合、この24時間サイクルが実質的な制約となります。1日1回の送金に合わせたサイズの委任では、たとえ総Energy量が十分に見えても、1日10回の送金には対応できません。総容量だけでなく、回復のペースも考慮する必要があります。

委任の取り消しと再割り当て

委任は永続的なものではありません。委任者はいつでもunDelegateResourceを呼び出してリソースを引き戻すことができます。その効果は即時で、次のブロックから受取人の利用可能なEnergyが取り消し分だけ減少します。受取人側にクールダウンはなく、プロトコルレベルでの補償の仕組みもありません。

委任の再割り当て、つまり同じリソース出力を別の受取人に向けるには、2つのトランザクションが必要です。現在の受取人からの取り消し、そして新しい受取人への委任です。これらは別々のオンチェーン操作であり、それぞれbandwidthを消費します。Stake 2.0ではこれらをより効率的に処理できるようになりましたが、単一トランザクションとしてアトミックに実行することはできません。

知っておくべきエッジケースが1つあります。委任者のステーキングTRXが200,000のEnergyを生成し、そのうち150,000をアドレスAに委任している場合、残りの50,000をアドレスBに委任してもAへの委任には影響しません。制約は、委任したEnergyの合計が生成されたEnergyの合計を超えてはならないという点です。過剰な委任を試みた場合、トランザクションレベルで失敗します。

Energy貸し出しへの影響

tronenergyrent.comのようなEnergyの貸し出しサービスは、この委任モデルの上で完全に成り立っています。Energyを借りると、提供者はTRXをステーキングしてEnergyを生成し、あなたのアドレスを対象にdelegateResourceを呼び出します。あなたのアカウントからは、上述したようにacquired_delegated_frozenV2_balance_for_energyを受け取った形になります。あなたはTRXを保有するのではなく、一時的なリソース割り当てを受け取るわけです。

貸し出し期間は、提供者がその委任をアクティブな状態に保つ期間に対応します。現在の価格では、1日間の貸し出しは65,000 Energyあたり8.19 TRXです（TRC-20 USDTの標準的な送金1回分として、約65,000 Energyと約345 bandwidthを賄える量）。30日間の貸し出しでは、同じEnergyブロックに対して175.50 TRXとなります。ご自身の送金量に応じた正確なコストは計算ツールで確認できます。

短期間の貸し出しが1日あたりのコストで割高になる理由は純粋に仕組みによるものです。提供者はアンステーキングキューの管理と頻繁なサイクルに伴う再委任のオーバーヘッドを負担しなければならないためです。14日間の引き出し遅延により、貸し出し期間がどれほど短くても資金は拘束されてしまいます。

bandwidthの委任も同じモデルで動く

上述したことはすべてbandwidthにも同様に当てはまりますが、デフォルトの挙動に1点違いがあります。すべてのアカウントは、ステーキングの有無にかかわらず、ネットワークから1日あたり600の無料bandwidthを受け取ります。この無料枠は基本的なTRXの送金には対応できますが、高頻度のTRC-20送金のbandwidth部分には対応できません。ステーキングまたは委任されたbandwidthを受け取ることで、この600というベースラインを超えた上限が得られます。

あるアカウントにbandwidthを委任すると、そのアカウントがすでに持っている無料枠に加えて容量が追加されます。消費の順番は、無料bandwidthが最初、次に委任されたbandwidth、そして自己ステーキング分のbandwidth、最後にTRXバーンとなります。特定のアカウントでいつバーンが発生するかを正確に計算したい場合、この消費順序は重要なポイントになります。

APIから委任の状態を読み取る

ツールの構築や委任の監視を行う場合、関連するAPI呼び出しは以下の通りです。

• wallet/getaccount：委任済みおよび受取済みのリソースフィールドを含む、アカウントの完全な状態を返します
• wallet/getdelegatedresourcev2：2つのアドレス間の特定の委任レコードを返します。正確なEnergyの量と、ロックが設定されている場合はロックの期限も含まれます
• wallet/getcanwithdrawunfreezeamount：委任者がキューに入っているアンステーキングのうち、すでに引き出し可能な金額を確認できます

getdelegatedresourcev2エンドポイントは、委任に依存するトランザクションを実行する前に、委任がアクティブで適切なサイズであることを確認するのに特に役立ちます。昨日設定したからといって委任が有効であると思い込まないようにしましょう。オンチェーンの状態を常に確認してから利用するようにしてください。