Bounced CCM fees are not escrowed

[ishantiw]

Description

Bounced messages, i.e., CCMs that are returned to the sending chain when an error occurs during their processing, incur an extra fee on the sending chain. If, for example, the target chain does not support a given module, the CCU relayer receives no fee but the fee of the bounced CCM is reduced by minFee to penalize the chain who sent the "bad" CCM (the relayer of the newly bounced CCM can only get part of the fee that had originated from the original sending chain). The goal is for the originating chain to be able to recover most of the fee (since no real processing occurred), but still be penalized for the "bad" CCM.
A problem exists when subtracting minFee because the receiving chain does not burn it nor does it update the other sidechain's escrow balance. This means that the sidechain can recover the full fee amount, circumventing the penalisation for the "bad" CCM (we should note that the regular fee for each byte of the CCM is still paid by the relayer when submitting the CCU update transaction).
This is present in the apply method when a module is not supported or when a command in a module is not supported, and in the forward method when the mainchain does not have a channel to the receiving chain or when this channel is only in the registered state. Transactions that fail on the execute method are not affected because, in that case, the fee has already been paid to the relayer.

• Update bounce method #8732
• Update apply method to improve handling of ccm fee #8733
• Update forward method to handle ccm fee properly #8735
• Update beforeCrossChainMessageForwarding in token module to handle fee properly #8737
• CCM fees are under-specified and the implementation is not defensive #8602 (Should be done after Update beforeCrossChainMessageForwarding in token module to handle fee properly #8737)
• Update Message Recovery command execute to handle failed ccm fee handling #8738

Which version(s) does this affect? (Environment, OS, etc...)

v6.0.0-beta.2