Laisky's Notes

最近都在学习 TON 开发，积累了一些经验。TON 有很多独特的设计和开发范式，值得先记个小笔记，主要以 Ethereum/EVM 作对比。这是基于我目前的理解，不一定正确，有兴趣欢迎讨论。 1. 所有的调用都是消息，所有的消息都是异步的。也就是说，你没法同步取得跨合约调用的结果。 2. 每次调用的费用是非确定性的，而且因为整个调用是异步的，没法预知调用的总费用。所以只能先给一个相对较高的手续费，然后等合约执行完后退还余款。TON 的费用的精确控制非常困难，我花了很多时间在这上面，这个以后可以单独讲一…

终于学会相对精确的控制 TON 的 value flow 了，先记个小笔记防止忘了。这也只是我目前的理解，不一定正确，欢迎讨论或指正。

有三个主要费用 network、computing、action。network 包含消息发送的费用，一般由 sender 付，钱包里一般消息的 value 和 network fee 是分别支付的，而合约中默认是从消息的 value 中支付的。computing 是执行合约的费用，action 是合约发送 external message 的费用，主要就是 emit。（此外还有 storage fee 先不管了）

ctx.value 代表的是 inflow msg 携带的 value，sender 已经付过了 network fee，还没支付 computing 和 action。合约执行后会扣除 computing，执行完成后如果有需要发送的 outflow 消息，那么再扣除 action fee。

可以把 ctx.value 理解为税前收入，而且你无法知道会收多少税（computing & action fees）。

补充：FunC 里是可以精确计算 fwd_fee 的，但是感觉 tact 不太行，可参考：
* https://docs.ton.org/develop/smart-contracts/fee-calculation
* https://github.com/ton-blockchain/stablecoin-contract/blob/main/contracts/gas.fc
* https://tonviewer.com/config#24

myBalance() - ctx.value 代表合约执行前的余额。可以用 nativeReserve(myBalance() - ctx.value, ReserveExact); 来保护合约余额不被用户消息所消耗。

但是你在合约代码中极难通过控制 ctx.value 来计算你能操作的 inflow 余额，因为 computing 和 action 的开销是很难计算的。比如如果你想要把剩余的 inflow value 全部转走，可行的办法是用 nativeReserve 锁定不想转走的余额，然后再用 SendRemainingBalance mode 发送一条 value 为 0 的消息。

SendRemainingBalance 会转走未被 nativeReserve 锁定的全部金额，按照上文描述，也就是所有剩余的 ctx.value。注意 send 的 value 并不会支付 action fee，而仅会包含 network fee。也就是说，当你在代码中 send 一个消息，这个消息的 network fee 会从 send 的 value 中扣除，但是 action fee 会从合约余额中扣除。这其中有一个坑，emit 的费用是在 action 阶段计算的，如果你的代码中使用了 emit，那么就需要记住在 action 阶段合约余额会被扣钱，你最好在 nativeReserve 的锁定中包含 emit 的费用。
经过多次测试，nativeReserve 锁定余额后，仅有 storage_fee 是从 balance 扣除的，其他都是从 send 的 value 里扣除的。

但是 emit 具体花多少钱？我还不知道怎么算，目前是估计一个经验值，测试网是 0.007，你可以多锁定 0.01 给 emit。 #blockchain

Ps. 我真是行业冥灯，搞啥啥死

prev: https://t.me/laiskynotes/318
next: https://t.me/laiskynotes/324

docs.ton.org

Fees calculation | The Open Network

Introducation