Bump reth-db from v1.0.6 to v1.1.0

[dependabot]

Bumps reth-db from v1.0.6 to v1.1.0.

Release notes

Sourced from reth-db's releases.

Reth v1.1.0

Summary

Reth Engine 2.0

This release enables the new performant engine architecture for ethereum chains by default. This was previously opt-in, as the --engine.experimental flag.

[!IMPORTANT]
Nodes which do not want to use the new engine MUST now add --engine.legacy to their cli flags to preserve the old engine behavior.

Using --engine.legacy is recommended for stakers / payload builders, as the previous architecture has been tested in production for a longer period of time. Validators that update to 1.1.0 without changing any command line flags will not be using the previous architecture, hence the recommendation to add the --engine.legacy flag.

The new engine is not enabled for op-reth by default, and must still be enabled using the --engine.experimental flag. We encourage op-reth users to use this flag.

[!IMPORTANT]
Applications which access the database externally, and require the database to be at the head of the chain, should use --engine.legacy

Engine 2.0 overview

The previous engine architecture required that the node database be always at the head of the chain. This requirement made it simple to reason about the database, but required that the node's engine_forkchoiceUpdated API synchronously commit to the database, which caused high latency for the API. Removing this requirement required a rewrite of the node's consensus handling logic.

This new engine architecture yields great performance improvement when syncing near the tip of the chain. Here is the engine_forkchoiceUpdated latency with the old engine:

And here is the engine_forkchoiceUpdated latency with the new engine:

ExEx breaking changes and improvements

The ExExNotifications::recv and ExExNotifications::poll_recv are now removed.

ExExNotifications::with_head is introduced - this method allows exex notifications to work properly with the new engine, and requires users to specify a head block. This head block determines where the exex notifications will start from.

Engine 2.0 improvements

There have been some performance improvements and bug fixes for the new engine architecture since 1.0.8:

• fix: acquire permit first (#11537)
• fix: in-memory trie updates pruning (#11580)

op-reth related enhancements and fixes

We have fixed some issues for op-reth instances running with --engine.experimental:

• feat: store safe block num as well (#11648)
• fix: persist finalized block (#11623)
• fix: always handle payload building for opstack (#11629)

There are also various fixes not related to the new engine architecture:

• fix: set system tx correctly (#11601)
• fix(op-reth): add jemalloc feature to optimism-cli for version (#11543)

Observability improvements

New metrics have been added, and the dashboard has been improved:

... (truncated)

Changelog

Sourced from reth-db's changelog.

Releases

Release cadence

reth does not currently have a regular release cadence while it is still experimental software.

For maintainers

This section outlines how to cut a new release.

It is assumed that the commit that is being considered for release has been marked as stable, i.e. that there is an expectation of no major bugs.

Release PR

• Create a new branch (e.g. release/vx.y.z) and open a pull request for it
• Ensure all tests and lints pass for the chosen commit
• Version bump
  • Update the version in all Cargo.toml's
• Commit the changes
  • The message format should be release: vx.y.z, substituting x.y.z for the semver.
• The PR should be reviewed to see if anything was missed
• Once reviewed, merge the PR

Releasing

• Tag the new commit on main with vx.y.z (git tag vx.y.z SHA)
• Push the tag (git push origin vx.y.z)[^1]
• Update Homebrew Tap
• Run the release commit on testing infrastructure for 1-3 days to check for inconsistencies and bugs
  • This testing infrastructure is going to sync and keep up with a live testnet, and includes monitoring of bandwidth, CPU, disk space etc.

Note

The v prefix for the tag is important! If it is missing, the release workflow will not run.

When the tag is pushed, the artifacts are built automatically and a draft release is added to the repository. This draft release includes a template that must be filled out, including:

• A summary of the release (highlights etc.)
• The update priority (see below)
• An auto-generated changelog

The release artifacts are automatically added to the draft release. Once ready, simply publish the release.

Release summaries

The release summary should include general notes on what the release contains that is important to operators. These changes can be found using the https://github.com/paradigmxyz/reth/labels/M-changelog label.

[^1]: It is possible to use git push --tags, but this is discouraged since it can be very difficult to get rid of bad tags.

Commits

• 1ba631b feat: store safe block num as well (#11648)
• 250785f chore: preempt single block downloading (#11647)
• fca1cd8 fix: don't unwrap missing requests (#11646)
• 1d2c6d5 chore(rpc): don't recover sender if we have it (#11645)
• d027b7b feat(bin): make experimental engine default (#11612)
• 58bac0e chore: release 1.1.0 (#11640)
• 456d507 feat(ci): move book clippy and tests to matrix (#11618)
• 90cb362 feat(exex): commit only notifications with unfinalized blocks to WAL (#11638)
• 8a11830 feat(ci): add Kurtosis workflow (#11615)
• 01f382b docs: clarify op-mainnet --debug.tip (#11634)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #22.