-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sequencer: add notion of transaction categories #1414
Comments
This was referenced Aug 28, 2024
This was referenced Sep 11, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 30, 2024
## Note for Reviewers Most of the logic changes are in the files `crates/astria-core/src/protocol/transaction/v1alpha1/action_group.rs` and `crates/astria-core/src/protocol/transaction/v1alpha1/mod.rs`. The rest of the changes are updating the construction of `UnsignedTransactions` and/or changing the access to the inner fields. ## Summary Adds restrictions on what type of `Actions` can be included in the same `UnsignedTransaction`. Implements the categories as described in #1412 but with slightly different names: - General: - TransferAction - SequenceAction - BridgeLockAction - BridgeUnlockAction - IbcRelay - Ics20Withdrawal - ValidatorUpdate - UnbundeableGeneral (Instead of Bridge Control): - InitBridgeAccountAction - BridgeSudoChangeAction - Sudo: - FeeAssetChangeAction - FeeChangeAction - IbcRelayerChangeAction - UnbundleableSudo (Instead of Sudo Control): - SudoAddressChangeAction - IbcSudoChangeAction The check is applied at the time of constructing the `UnsignedTransaction`. The `UnsignedTransaction` additionally had its struct fields changed to private and now uses a new constructor to prevent the contained actions from being modified. ## Background We want transactions that can affect the validity of other transactions to be ordered last in blocks to reduce the amount of failed transactions we process. These logic changes are the first code changes being made to realize this goal. ## Changes - Introduced the `Actions` struct to hold valid groupings of `Actions`. - Introduced `ActionGroup` enum to represent which `Actions` can be included together in a transaction and if more than one action can be included in a transaction. - Changed the `UnsignedTransaction` struct to have private fields and to use a new constructor. - Changed the `UnsignedTransaction`'s `action` to be a `Actions` type instead of just a vector of `Actions`. ## Testing Unit testing and ran locally. ## Breaking Changelist Transactions that contain invalid `ActionGroup` combos (due to mixed groups or multiple actions in non-bundleable group types) are now 'invalid' transactions. I had to update one of the snapshot tests due to having to unbundle some of the transactions, creating a new state. ## Related Issues Initial steps for #1412 closes #1414, #1416
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For #1412's implementation, adding the notion of transaction categories based on contained
Actions
is a possible first step. The different categories/enums would then be used to construct rules about whichActions
are allowed to be bundled together and eventually be used to enforce block-level order rules needed by the mempool for #1152.Different categories/enums (from #1412):
┆Issue Number: ENG-751
The text was updated successfully, but these errors were encountered: