Sha*_*izi 2 blockchain substrate
在 Substrate 区块链开发框架中，FRAME Balances 托盘引用了 4 种不同的余额：
这些不同类型的 balances 之间有什么区别，它们什么时候在 Substrate 中使用，我应该如何在我自己的运行时模块中使用它们？
Balances 模块是一个全面的链上货币，可以灵活地提供许多不同的功能。
在余额模块的存储中，只有两个余额是直接存储的：
这两个余额的总和用于计算帐户的总余额。
额外的逻辑层置于自由平衡之上，以创建抽象，例如：
因此，让我们来看看由 Balances 模块管理的不同类型的余额。
从参考文档的术语部分：
自由余额：余额中未预留的部分。自由余额是对大多数操作而言唯一重要的余额。当此余额低于存留存款时，该帐户的大部分功能将被删除。当它和保留余额都被删除时，则称该帐户已死。
每当启动、 或时transfer，都会使用帐户的可用余额。在这些操作可以成功完成之前，用 some 调用并检查提款是否不干扰某些归属余额或锁定余额withdrawreserveensure_can_withdrawWithdrawReason。
这不会阻止其他操作，例如 slash发生，它不关心任何对自由平衡的抽象。
账户的归属余额是对其自由余额的抽象。更具体地说，具有归属余额的账户不能从低于该金额的自由余额中支出。归属余额不在乎WithdrawReason。
amount_spendable = free_balance - vesting_balance
因此，即使在查询可用余额时，账户看起来似乎有大量流动资金可供使用，但账户归属余额可以防止这些资金被提取。
归属平衡只能在衬底链的起源被设置，并以每块起始于一些线性速率减小starting_block为一个length块，在该点归属余额为零。在自由余额因削减而减少的情况下，归属余额可以大于自由余额。在这些情况下amount_spendable饱和为零。
帐户的锁定余额是对其自由余额的另一种抽象。在这种情况下，它是由于某种原因被锁定不能提取的一定数量。
不同的退出原因是：
So if an account has a lock for 100 units with WithdrawReasons::Transfer, it cannot make a transfer which brings its free balance lower than 100 units. However, this account will be able to perform another operation like reserve taking its free balance below 100 units. A lock can have multiple reasons associated with it, in which case, those funds can only be spent for the other reasons.
Multiple different locks can be placed on an account, but these locks overlay one another rather than stack. This means that if an account has 3 locks for 100 units, the account can spend it's funds for any reason down to 100 units, at which point the locks will start to come into play.
Locked balance also overlays with vesting balance as these two are checked independently, but both checks must pass for ensure_can_withdraw to be successful.
From the terminology section:
Reserved Balance: Reserved balance still belongs to the account holder, but is suspended. Reserved balance can still be slashed, but only after all the free balance has been slashed. If the reserved balance falls below the existential deposit then it and any related functionality will be deleted. When both it and the free balance are deleted, then the account is said to be dead.
Relatively speaking, reserved balance is more simple than free balance because there are no abstractions over it. Funds which are reserved from a user are not meant to be directly touched by any other logic outside of the balances module. Instead, funds should first be unreserved and then modified in the free_balance.
Reserved balance and locked balance appear similar but are fundamentally different. Locked balance has an identity in terms of a lock identifier, what reasons funds are locked for, and how long they are locked for. A reserved balance has none of these traits, and are untouchable without explicit action from the runtime to unreserve those funds.
Furthermore, there could be implications about having a free balance to versus not having one. For example, if you set a lock on the full free balance of an account, it will still have a free balance, and OnFreeBalanceZero will not be called. However, if you reserve all the funds, the free balance will drop below the existential deposit and OnFreeBalanceZero will be triggered for modules who have implemented this feature.