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

refactor(sequencer): remove global state #1317

Merged
merged 6 commits into from
Aug 1, 2024
Merged

refactor(sequencer): remove global state #1317

merged 6 commits into from
Aug 1, 2024

Conversation

SuperFluffy
Copy link
Member

@SuperFluffy SuperFluffy commented Jul 31, 2024

Summary

Removed all global from sequencer.

Background

Upon init, sequencer stored its native asset and address base prefix at a fixed global memory locations. This did not yet lead to issues during runtime (because we don't mutate global after startup), it made testing unnecessarily difficult: sequencer relies heavily on unit tests, yet the tests were impure because they relied on the same global state.

The changes to the mempool module shows another issue: while the mempool could be wholly agnostic to the specific global state, heavy use of the global base prefix meant was less decoupled than it could be.

Because sequencer explicitly passes around state (in the form of state deltas, the data inside which are made accessible via various StateReadExt and StateWriteExt traits), we can read the configured base prefix and native assets from there.

The downside is that this patch introduces more database reads. However, given the amounts of data sequencer is dealing with this might not matter and can be alleviated by using a rocksdb Cache (or other mechanism) instead of relying on globals.

Changes

  • Remove global setters and writers in crate::address and crate::assets
  • Update all code to read the base address prefix and native asset through crate::address::StateReadExt and crate::address::assets::StateReadExt instead.
  • Update the mempool to be agnostic of address prefixes and use address bytes insteda: this change is in line with sequencer design considerations in that the address prefix only matters at the boundary while state reads are done via the address bytes underlying the bech32m addresses.
  • Require that the sequencer genesis contains a TracePrefixed asset.

Testing

Updated all tests to either use hard coded prefixes, native assets (if not performing reads or writes on state deltas), or write a base prefix and native asset to state before performing tests (if accessing state).

Breaking Changelist

While the change to astria-core is technically breaking (because a field that was of type asset::Denom is now asset::TracePrefixed), in practice this change is not breaking because Sequencer required native assets to be non-ibc prefixed.

Related Issues

Closes #1208

@github-actions github-actions bot added the sequencer pertaining to the astria-sequencer crate label Jul 31, 2024
@SuperFluffy SuperFluffy marked this pull request as ready for review July 31, 2024 15:23
@SuperFluffy SuperFluffy requested a review from a team as a code owner July 31, 2024 15:23
@SuperFluffy SuperFluffy requested a review from Fraser999 July 31, 2024 15:23
Comment on lines +92 to +99
let _ = snapshot
.get_native_asset()
.await
.context("failed to get native asset from storage")?;
crate::assets::initialize_native_asset(&native_asset.to_string());
let base_prefix = snapshot
.context("failed to query state for native asset")?;
let _ = snapshot
.get_base_prefix()
.await
.context("failed to get address base prefix from storage")?;
crate::address::initialize_base_prefix(&base_prefix)
.context("failed to initialize global address base prefix")?;
.context("failed to query state for base prefix")?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any point to still doing these calls?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are right. I am going to remove these as part of addressing #1318

Base automatically changed from ENG-659 to main August 1, 2024 16:41
@SuperFluffy SuperFluffy enabled auto-merge August 1, 2024 16:46
@SuperFluffy SuperFluffy added this pull request to the merge queue Aug 1, 2024
Merged via the queue into main with commit c765408 Aug 1, 2024
42 checks passed
@SuperFluffy SuperFluffy deleted the ENG-46 branch August 1, 2024 16:58
steezeburger added a commit that referenced this pull request Aug 2, 2024
* main:
  chore(core): Implement Protobuf trait for tx actions (#1320)
  refactor(sequencer): remove global state (#1317)
  refactor(sequencer): move asset state methods to asset module (#1313)
  feat(sequencer, core): Add fee reporting (#1305)
  chore(bridge-withdrawer): cleanup nonce handling (#1292)
  fix(charts, bridge): fix ci test (#1310)
github-merge-queue bot pushed a commit that referenced this pull request Aug 21, 2024
## Summary
Addition of a new benchmark target to assess the performance of the
prepare_proposal method in sequencer's `App`.

## Background
Previous perf work has indicated this is a bottleneck. However, making
that determination was done via spamoor which is slightly convoluted to
run. Before working to improve the performance, we want to have a faster
feedback loop on the effects of updates, hence the need for a benchmark
which is easy to run and which isolates the slow function.

## Changes
- Added benchmark to `app` module. Currently this has only one case: a
mempool filled with transactions containing exclusively transfers. This
matches the shape of the data being sent when using spamoor.
- Added `benchmark` feature to enable sharing some of the existing test
utils.

## Testing
This is a new test.

Example of running `cargo bench --features=benchmark -qp
astria-sequencer app` on my Ryzen 7900X:
```
Timer precision: 10 ns
astria_sequencer                                fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ app                                                        │               │               │               │         │
   ╰─ benchmarks                                              │               │               │               │         │
      ╰─ execute_transactions_prepare_proposal  11.63 s       │ 14.68 s       │ 12.74 s       │ 12.88 s       │ 10      │ 10
```

Since rebasing after #1317 has merged, the same run shows (as expected)
a slowdown:
```
astria_sequencer                                fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ app                                                        │               │               │               │         │
   ╰─ benchmarks                                              │               │               │               │         │
      ╰─ execute_transactions_prepare_proposal  14.49 s       │ 17 s          │ 16.52 s       │ 15.98 s       │ 8       │ 8
```

## Related Issues
Closes #1314.
Fraser999 added a commit to Fraser999/astria that referenced this pull request Aug 23, 2024
…org#1337)

## Summary
Addition of a new benchmark target to assess the performance of the
prepare_proposal method in sequencer's `App`.

## Background
Previous perf work has indicated this is a bottleneck. However, making
that determination was done via spamoor which is slightly convoluted to
run. Before working to improve the performance, we want to have a faster
feedback loop on the effects of updates, hence the need for a benchmark
which is easy to run and which isolates the slow function.

## Changes
- Added benchmark to `app` module. Currently this has only one case: a
mempool filled with transactions containing exclusively transfers. This
matches the shape of the data being sent when using spamoor.
- Added `benchmark` feature to enable sharing some of the existing test
utils.

## Testing
This is a new test.

Example of running `cargo bench --features=benchmark -qp
astria-sequencer app` on my Ryzen 7900X:
```
Timer precision: 10 ns
astria_sequencer                                fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ app                                                        │               │               │               │         │
   ╰─ benchmarks                                              │               │               │               │         │
      ╰─ execute_transactions_prepare_proposal  11.63 s       │ 14.68 s       │ 12.74 s       │ 12.88 s       │ 10      │ 10
```

Since rebasing after astriaorg#1317 has merged, the same run shows (as expected)
a slowdown:
```
astria_sequencer                                fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ app                                                        │               │               │               │         │
   ╰─ benchmarks                                              │               │               │               │         │
      ╰─ execute_transactions_prepare_proposal  14.49 s       │ 17 s          │ 16.52 s       │ 15.98 s       │ 8       │ 8
```

## Related Issues
Closes astriaorg#1314.
Fraser999 added a commit to Fraser999/astria that referenced this pull request Aug 25, 2024
…org#1337)

## Summary
Addition of a new benchmark target to assess the performance of the
prepare_proposal method in sequencer's `App`.

## Background
Previous perf work has indicated this is a bottleneck. However, making
that determination was done via spamoor which is slightly convoluted to
run. Before working to improve the performance, we want to have a faster
feedback loop on the effects of updates, hence the need for a benchmark
which is easy to run and which isolates the slow function.

## Changes
- Added benchmark to `app` module. Currently this has only one case: a
mempool filled with transactions containing exclusively transfers. This
matches the shape of the data being sent when using spamoor.
- Added `benchmark` feature to enable sharing some of the existing test
utils.

## Testing
This is a new test.

Example of running `cargo bench --features=benchmark -qp
astria-sequencer app` on my Ryzen 7900X:
```
Timer precision: 10 ns
astria_sequencer                                fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ app                                                        │               │               │               │         │
   ╰─ benchmarks                                              │               │               │               │         │
      ╰─ execute_transactions_prepare_proposal  11.63 s       │ 14.68 s       │ 12.74 s       │ 12.88 s       │ 10      │ 10
```

Since rebasing after astriaorg#1317 has merged, the same run shows (as expected)
a slowdown:
```
astria_sequencer                                fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ app                                                        │               │               │               │         │
   ╰─ benchmarks                                              │               │               │               │         │
      ╰─ execute_transactions_prepare_proposal  14.49 s       │ 17 s          │ 16.52 s       │ 15.98 s       │ 8       │ 8
```

## Related Issues
Closes astriaorg#1314.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sequencer pertaining to the astria-sequencer crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants