变更记录
- 03-03-2022：初始草案
状态
已接受背景
费用模块为所有被托管以激励数据包中继的费用维护了一个托管账户。 它还会将每笔被托管的数据包费用与该托管账户分开追踪。这是因为托管账户只维护总余额，无法标识哪些代币属于哪一笔数据包费用。 在出现严重缺陷时，托管余额可能会与被标记为已托管的数据包费用不同步。 ICS29 模块应当能够优雅地处理这种情况。决策
如果确定托管余额与被标记为已托管的数据包费用不同步，我们将允许 ICS29 模块进入“锁定”状态。 处于“锁定”状态的费用模块将不允许进行数据包托管，也不会分发费用。所有 IBC 回调都会跳过费用相关逻辑，类似于费用已禁用的通道。 解锁费用模块将需要人工干预。发送侧
需要在OnAcknowledgementPacket 中处理特殊行为。由于对手方仍会继续为已启用费用的通道发送激励确认，因此在调用底层应用的 OnAcknowledgePacket 回调之前，仍然需要先将确认反序列化为激励确认。
在分发费用时，应使用缓存上下文。如果托管账户余额将变为负数，则应丢弃当前状态变更，并使用未缓存上下文将费用模块锁定。这样可以防止某个 packetID 的费用只被部分分发。
接收侧
OnRecvPacket 不应受到费用模块进入锁定状态的影响，因为托管账户只影响发送侧。
后果
正面
费用模块可以在出现严重缺陷时被优雅地禁用。负面
需要增加额外逻辑来处理仅在存在缺陷时才可能出现的边界情况。中性
参考
问题： PR：Changelog
- 03-03-2022: initial draft
Status
AcceptedContext
The fee module maintains an escrow account for all fees escrowed to incentivize packet relays. It also tracks each packet fee escrowed separately from the escrow account. This is because the escrow account only maintains a total balance. It has no reference for which coins belonged to which packet fee. In the presence of a severe bug, it is possible the escrow balance will become out of sync with the packet fees marked as escrowed. The ICS29 module should be capable of elegantly handling such a scenario.Decision
We will allow for the ICS29 module to become “locked” if the escrow balance is determined to be out of sync with the packet fees marked as escrowed. A “locked” fee module will not allow for packet escrows to occur nor will it distribute fees. All IBC callbacks will skip performing fee logic, similar to fee disabled channels. Manual intervention will be needed to unlock the fee module.Sending side
Special behaviour will have to be accounted for inOnAcknowledgementPacket. Since the counterparty will continue to send incentivized acknowledgements for fee enabled channels, the acknowledgement will still need to be unmarshalled into an incentivized acknowledgement before calling the underlying application OnAcknowledgePacket callback.
When distributing fees, a cached context should be used. If the escrow account balance would become negative, the current state changes should be discarded and the fee module should be locked using the uncached context. This prevents fees from being partially distributed for a given packetID.
Receiving side
OnRecvPacket should remain unaffected by the fee module becoming locked since escrow accounts only affect the sending side.