Sudo actions have some interesting side effects to the rest of the block, and as such should be posted at the bottom of the block with no non sudo actions occuring after them. We may even want a hierarchical order in which groupings can occur, and rules about coupling:
I propose the following transaction groupings, all actions in the same groupings have a property of if they can be bundled. If they can, they can only be bundled with same grouping txs. They are in order of how they should appear in a block.
- General
- These are general purpose txs which have no odd implications on later txs
- Bundlable? ✅
- Can charge fees
- Actions
TransferActionSequenceActionBridgeLockActionBridgeUnlockActionIbcRelayIcs20WithdrawalValidatorUpdate
- Bridge Control
- Bundlable? ❌
- These actions change fundamentals on the signing account. They can't be bundled cleanly because same signer can't do another action after it. Additionally, can have implications on txs in general validity based on ordering. Putting after makes clean break.
- Charge fees
- Actions
InitBridgeAccountActionBridgeSudoChangeAction
- Sudo Actions
- Bundlable? ✅
- Most of these have implications on fees charged and valid, affect all txs which have fees and must be after any tx which can charge fees. IbcRelayer affects the validity of
IbcRelay actions as such should be towards end of block.
- No fees, submittable only by sudo actor
- Actions
FeeAssetChangeActionFeeChangeActionIbcRelayerChangeAction
- Sudo Control
- Bundlable? ❌
- This updates the sudo account, impossible to have more than one in a valid bundle. The sudo account is also the payee of fees, so it needs to be after all fee paying items, it would affect the validity of any sudo actions. I think it's best to include after any such actions occur.
SudoAddressChangeAction
I think these might be best viewed as a sort of "action category" where a transaction can only have actions that are all the same category, and categories have two properties (priority, and if it can be bundled). Thus the category of the first action would the that for the whole transaction, and stateless checks can easily be added over this.
┆Issue Number: ENG-750
Sudo actions have some interesting side effects to the rest of the block, and as such should be posted at the bottom of the block with no non sudo actions occuring after them. We may even want a hierarchical order in which groupings can occur, and rules about coupling:
I propose the following transaction groupings, all actions in the same groupings have a property of if they can be bundled. If they can, they can only be bundled with same grouping txs. They are in order of how they should appear in a block.
TransferActionSequenceActionBridgeLockActionBridgeUnlockActionIbcRelayIcs20WithdrawalValidatorUpdateInitBridgeAccountActionBridgeSudoChangeActionIbcRelayactions as such should be towards end of block.FeeAssetChangeActionFeeChangeActionIbcRelayerChangeActionSudoAddressChangeActionI think these might be best viewed as a sort of "action category" where a transaction can only have actions that are all the same category, and categories have two properties (priority, and if it can be bundled). Thus the category of the first action would the that for the whole transaction, and stateless checks can easily be added over this.
┆Issue Number: ENG-750