TRON 能量代理是怎么运作的
TRON 能量代理就是一笔交易和两个账户字段。一个为能量质押过 TRX 的地址调用 delegateResource,在里面点名一个收方,从那个区块起,这个收方就能花它从来没有为之质押过的能量,而质押方仍然拿着它冻结的每一个 TRX。没有什么被转走,收的这一侧没有什么被授权,也没有密钥易手。整个能量租赁市场就站在这套机制上,而下面这些,是从 java-tron 自己的执行器里、从对主网的实时读取里,以及从 2026 年 9 月 3 日和 4 日在 Nile 测试网上的两次交易运行里读出来的。
什么过去了,什么留下
质押着的 TRX 从来不离开持有者的账户:代理只是把它在这个账户内部的两个桶之间挪了个位置,从为能量冻结的余额里出来,进到一个为能量代理出去的桶里。TRON Power——也就是投票权重——是两个桶之和,所以借出去不花质押方一票,也不花一分投票收益。2026 年 9 月 3 日读到的一个主网质押方,把这件事说得比源码还清楚:它正投出 3,080,000 票,而手里没代理出去的还不到这个数的一半,其余都借了出去,而节点给它算的 TRON Power,就是两个桶加起来。
收方拿到的是这桩交易的另一半:能量,别无他物。一笔代理写在收方账户上的那个字段不是 TRON Power 的一项,所以借来的能量不带任何选票——同一次读取里的那个收方压根没有 TRON Power 这个数,我们在 Nile 上的那个也没有。
收方账户上显示什么
两个数字会动。acquired_delegated_frozenV2_balance_for_energy 按代理出去的数量上升,账户的能量上限也跟着上升——升幅是代理出去的 TRX 乘以网络的 TotalEnergyLimit,再除以它的 TotalEnergyWeight,截尾取整。2026 年 9 月 3 日,一个从两个代理方那里持有 31246 TRX 代理的主网收方,显示出的能量上限是 299,638,正是那天傍晚网络所带的那个比值下的这道算术:180,000,000,000 比 18,770,236,993。
买能量的人正是在这里意外:一笔代理是以 TRX 计的,不是以能量计的。分母是全网质押的总权重,它每个区块都在动,而在别处量到的数字并搬不过来——那一周同样一笔质押在 Nile 上值的能量,大约是主网上的 7.7 倍。
锁定,以及那四次拒绝
默认情况下,一笔代理随时可以被收回。代理调用上的 lock=true 是能拦住这件事的东西,而且是唯一的一个。它带一个参数 lock_period,以三秒一个的区块计数——一个读起来像时长、其实是个计数的字段,所以因为想要 300 秒就填 300,买到的是十五分钟,而且悄无声息。留成零或者干脆不写,它的意思就是 86,400 个区块:三天。上限是一个链上参数,2026 年 9 月 3 日在主网上,它停在 864,000 个区块,也就是三十天。
锁定可以延长,永远不能缩短。对同一个收方的第二笔代理,只有在它的时长至少等于还剩下的时间时才会被接受,而且它随后重置的是整个累积余额的到期时间,而不只是新加的那部分——所以给一笔锁定的代理续上一笔,会把它下面的一切重新锁一遍。其余的一切,网络都拒绝。下面这四条是 2026 年 9 月 3 日从一个主网节点上回来的,针对的是一对带着二十四小时活锁定的地址;节点在构造这两种调用中的任何一种时,都会跑一遍执行器自己的校验,所以这四条都是执行器自己的回答,而没有任何东西被签名或者发出去:
- 在活着的那道锁定之上再加一个区块的锁定——
The lock period for ENERGY this time cannot be less than the remaining time[86241000ms] of the last lock period for ENERGY!,它把还剩多少时间点了出来,单位是毫秒; - 在同一道锁定之上加四小时的锁定——一模一样的拒绝。要过的不是比一道新锁定长,而是比剩下的时间长;
- 比上限多出一个区块的锁定——
The lock period of delegate resource cannot be less than 0 and cannot exceed 864000!; - 解除代理本身——
insufficient delegateFrozenBalance(Energy), request=1000000, unlock_balance=0。不是“比您要的少”:锁定还在的时候,被锁的余额算作压根不存在。
一次通过校验的构造不是一个区块,所以同样的事又对着我们自己的一道锁定做了一遍。2026 年 9 月 4 日在 Nile 上的两次运行,先立一道锁定,立刻要求解除代理,等锁定过去再要一次:两次都被拒绝,一字不差地拿到最后那句话,而过了到期时间之后两次都被接受——一次在五分钟,一次在四小时。长的那次还顺带定下了这个单位数的是什么:两笔交易之间,区块头的时钟走过了 4,801 个三秒的时隙,而区块高度只走了 4,785,也就是有十六个时隙没有出块,而那道锁定照样跑满了它的四小时。lock_period 数的是区块时钟的时隙,不是出得出来的区块。
怎么结束一笔,以及怎么看出它结束了
代理方调用 undelegateResource,在没有锁定挡路的时候,一个区块就完事。两次调用都不带带宽以外的费用——两个执行器都把自己定价为零——正因为如此,能量才可能以分钟为单位卖出去。对着一道活着的锁定,既没有取消,也没有哪笔费用能买到一条出路;用 lock=false 再代理一次也不是出路,因为那写的是另外一行,被锁的那一行照样立着。
锁定只在一个地方可见:那一对地址的代理行,那里的 expire_time_for_energy 是一个以毫秒计的时间戳。这个键不在,就是没有锁定——一家寻常租赁卖方的代理就长这样,而 2026 年 9 月 3 日读到的一个主网池子的那些行,压根没带到期这个键。这个数字要读出来,而不是算出来:执行器是拿上一个区块的头给它盖的时间戳,所以从代理自己那个区块算出来会差一个区块,而从交易的时间戳算出来,每次差得都不一样。两次 Nile 运行按第一条规则都和存下来的值对到了毫秒,按另外两条都对不上。
一笔代理结束的时候,收方那两个字段不会归零——它们从回答里消失了,而那条代理行回来是空的。任何在轮询账户的东西都得把缺失当成零来处理,否则它会一直显示几分钟前就已经回到主人手里的能量。
为什么收能量的钱包什么都不用签
这一切都发生在代理方那一侧:收方在交易里被点了名,它的账户上被写了一个字段,而没有什么要接受、批准或者连接的——这也正是为什么一笔代理够不着那个钱包里装着的东西。有两条要求指向另一个方向:这个地址必须已经作为账户存在,而且它不能是合约,合约会被执行器直接拒绝。正是这一点,才让能量可以用 API 租出去(能量是什么,它又从哪里来)。
租赁在它上面搭了什么
一个卖能量的,就是一个有质押、也有代理习惯的账户:它把能量代理给您的转出钱包一段时间,您把这些能量花在一笔 USDT 转账上,它再把代理收回去。租期各家不同;我们的是 300 秒,因为一笔转账只要几秒。一个订单的回答里带着 send_before——交付窗口关闭的那一刻,比这段租期早三秒——而要围着来安排的是这个字段,不是墙上的钟。
在租期跑着的时候,这一切都看得见,而这正是在一条公链上租东西有用的地方:转出钱包上那笔代理交易、它身上升上去的那个能量上限,以及任何一个会读代理状态的区块浏览器上,那两个地址之间的那一行。能量要么在那个地址上,要么不在,而收费收的是前一件事(现在这要花多少)。一个整天都在发的钱包,就是同一套机制加上一张时间表:一条 Auto-refill 规则会在每一笔转账之后把它补回去,而不是要您去下一个订单。
有两件事我们还没有量过,而两件都该摆在明处。一是收方账户自己的质押动作,会对立在它上面的一笔代理做什么:如果一个收方在租期中间解押,或者把资源再代理出去,执行器的代码暗示这里有东西可挖,而我们还没有跑过。另一件是续加:源码和 TIP-542 都说,一笔被接受的第二次代理会把它下面的整个余额重新锁一遍,而我们还没有真的过一笔。