Skip to content
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

Closed
Lilyjjo opened this issue Aug 28, 2024 · 0 comments · Fixed by #1512
Closed

sequencer: add notion of transaction categories #1414

Lilyjjo opened this issue Aug 28, 2024 · 0 comments · Fixed by #1512
Assignees
Labels
mempool sequencer pertaining to the astria-sequencer crate

Comments

@Lilyjjo
Copy link
Contributor

Lilyjjo commented Aug 28, 2024

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 which Actions 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):

  • General (cannot contain Actions listed in the other categories)
  • Sudo Actions
  • Bridge Control
  • Sudo Control

┆Issue Number: ENG-751

@Lilyjjo Lilyjjo added sequencer pertaining to the astria-sequencer crate mempool labels Aug 28, 2024
@Lilyjjo Lilyjjo self-assigned this 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