说到底,租来的 TRON 能量能撑多久
问租来的 TRON 能量能撑多久,得到的那些答案不可能都是真的:交易一确认它就没了;一小时之后它就回来了;它在钱包上待三天;它一直待到卖方决定收回去为止。每一个都是对另一个问题的正确回答,因为一笔租来的代理上跑着三个互不相干的时钟,而人们心里想的只是其中一个。下面把它们一个一个分开来讲。要是只想要一句短的:只要那笔代理还落在地址上,它就还在——我们的订单是 300 秒,其中除最后三秒外都是用来发出去的;大多数卖方是一小时。但一段租期在背后没有锁定顶着之前只是一个承诺,而真正回答这个问题的那个时钟,是锁定。
三个时钟
第一个是商业上的:卖方卖给您的那段租期,它是价目表上的一个数字,再没有别的。第二个在链上:锁定,协议里唯一能拦住卖方提前把代理收回去的东西。第三个属于资源本身:花掉的能量会在接下来的一天里恢复,不管这个账户是谁的。它们彼此独立——一个卖方可以卖一小时而一点也不锁——而这件事上大多数彼此矛盾的答案,都是有人把三者之一当成了全部三个在讲。
卖方卖出的那段租期
租期是一个产品决定,而各家拉得很开。我们自己的监测在 2026 年 9 月 7 日读到的十七份价目表里,十六份报的是一小时的租期,一份报的是三天。这些租期背后的价格,每一个都盖着它被读到的那一刻,都在行情页上;租期则是它们背后卖方自己的产品说明。我们的是 300 秒,而这是故意做短的:一笔代理创建不要钱,结束也不要钱,所以为了花掉其中五秒钟而买下一小时立在那里的能量,买的是仓储。
这对一个订单意味着的是一个字段。当能量在转出地址上被确认的时候,回答里带着 send_before:交付窗口关闭的那一刻,比租期早三秒。这三秒是算术,不是保护:它们只让窗口比租期先结束,别的什么也不做。租期由网络按承载那笔代理的区块来计时,我们则按看到那笔代理被确认的那一刻来计时,两者之间隔着一次轮询——所以在窗口最后几秒发出去的转账,可能在能量已经回家之后才到链上,并为此烧掉 TRX。要按信号发,别按截止时刻发:要围着来安排的是 send_before,不是租期,也不是墙上的钟(一个钱包怎么靠租来的能量发出去把这条流程的其余部分走了一遍)。
锁定,以及一段租期做不到什么
价目表上的租期是一个承诺;机制是代理上的 lock=true。没有它,卖方随时可以解除代理——这是寻常租赁卖方会留着的一项权利,因为收回来正是他们再卖一次的办法。2026 年 9 月 3 日读到的一家主网卖方池子的那些行,压根没带到期这个键,而第二天,节点被请求时就对着它一笔活着的代理构造出了一笔解除代理——而一笔构造好的解除代理,离到家只差一次广播。
有锁定的地方,它是精确的。这段时长以三秒一个的区块计数,不写的时候默认是 86,400 个——三天——而 2026 年 9 月 3 日在主网上,上限停在 864,000 个区块,也就是三十天。
它可以延长,永远不能缩短,而在它顶着的时候压根没有出路:那天一个主网节点把一个区块的时长和四小时的时长一样地拒绝了——一道新锁定要过的不是旧锁定的长度,而是它还剩下的时间——而且直接拒绝了解除代理,被锁的余额一分不算;2026 年 9 月 4 日在 Nile 测试网上的两次运行,对着我们自己的锁定引出了同样的拒绝,然后在到期时间一过就让解除代理通过了,一次在五分钟,一次在四小时。讲代理本身的那一篇把节点的回答一字不差地记了下来。所以这个问题诚实的问法是:能量在多长时间里不能被从您手上拿走——而那个问题的答案,就是锁定。背后没有锁定的租期,能撑多久,取决于卖方对不去动它还有多大兴趣。
底下那个每日的周期
第三个时钟是协议自己的。一个账户的能量上限是一份配额,不是一份余额:花能量不会从上限里减掉,而是把一个已用计数器往上顶,而那个计数器会在接下来的二十四小时里排回去。“一小时之后它就回来了”就是从这里来的——一个用自己的 TRX 质押的账户,花掉一部分配额之后大致就是这个样子。对一次租赁来说,它只在一个地方起作用,而这个地方跟想当然的正好相反。计数器属于钱包,不属于代理,而且不会因为代理回了家就清零:一个刚刚花掉 65,000 单位的钱包,这一天剩下的时间里都背着它们顶在自己的上限上。五分钟的租期大约是那个恢复日的三百分之一,所以在下一个订单之前,几乎排不掉多少。这就是为什么第二次租赁得把第一次花掉的那些盖过去,而不是再送来同样多的一份——也是为什么我们在收费之前读地址上的可用能量,也就是上限减去已用,而不是上限。在市场的另一头,这个周期就是被卖的东西的大半:一个一天只发几笔转账的钱包上的三天租期,买的与其说是代理,不如说是恢复。
“用掉”不等于“没了”
一笔转账不会消耗那笔代理。能量是对着上限花的;把上限抬上去的那笔代理是两个地址之间的一行,谁花能量都碰不到它。它结束于代理方解除代理的时候,或者在有锁定顶着时,不早于到期时间——所以一个刚刚把整个上限烧穿的钱包,照样拿着那笔代理,而一个一点都没花的钱包,拿着的也不比它多。正因如此,一次租赁的结束对不同的人意味着两件不同的事:能量在它出现在地址上的时候就已经交付了,而它有没有被用掉是另一件事。
有一条路我们没有量过:收方钱包自己的质押动作,会对立在它上面的一笔代理做什么。如果它在租期中间解押或者把资源再代理出去,执行器的代码暗示这里有东西可挖,而我们还没有跑过。
租期结束在一个订单上是什么样
一个走到窗口关闭还没被用掉的条目,以 expired 收场,而那不是一次失败。它不带错误,因为什么都没出错:能量被买下、被代理、在地址上被确认,并且在整个窗口里都待在那里,而您没有发。在 mode A 里照常扣费正是为了这个道理——卖的是交付出去的能量,不是您发出去这个动作——而在 mode C 里,一个钱包在还不知道收款方是谁的时候就被计费,expired 是正常的结局,而不是例外。
mode B 是唯一一种窗口关闭算我们的、不算您的情形。那里,发送本身是服务的一部分:如果到了 send_before 我们还没有把您签好的交易广播出去,这个条目就以 failed 收场,带着 broadcast_window_missed,而整笔预留都会回来。我们也不会迟到了还广播,而这是有意的,不是较真——一笔在代理已经走了之后才转发出去的转账,会烧掉我们受雇去省下的那些 TRX。这些状态各自会对一张发票做什么,在价格页上,而简短的答案在 FAQ 里。
当一个钱包整天都需要能量
这里没有一种形状对一个热钱包来说是好的。一份盖住一整天不可预测发送的长租期,要为闲着的那些小时付钱;一笔转账一份短租期,则意味着一笔转账一个订单。Auto-refill 规则是第三个选择:一个地址,一个每日预算,此后钱包每发一笔转账,后面都跟着一次补回到大约 131,000 能量——计费发生在那些能量在网络上可见的时候,而不是某个东西报告它的时候。一个闲着的钱包什么也不花,因为它什么也不需要——这一天的预算是被预留而不是被扣掉的——而租期也就不再是您要围着来安排的东西了。
怎么自己读出还剩多少租期
这里没有一件事必须靠信任来接,因为它全都在链上。两个地址之间的那笔代理是自成一行的,而回答整篇文章的那个字段是 expire_time_for_energy——那一对地址所在的那一行上,一个以毫秒计的时间戳。这个键不在,意思是没有锁定,而不是一道长度为零的锁定,而这正是大多数零售租赁诚实的读法。
到期时间是拿上一个区块的头盖的,不是拿代理自己那个区块盖的,这就是为什么讲代理本身的那一篇说这个数字要读出来,永远不要算出来。答案的另一半是账户本身:代理到来时升上去的那个能量上限,以及它被收回的那一刻就缺失掉的那些字段——不是归零,是缺失。