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

Switch Lighthouse and all deps off ethereum-types #6022

Open
michaelsproul opened this issue Jul 1, 2024 · 0 comments
Open

Switch Lighthouse and all deps off ethereum-types #6022

michaelsproul opened this issue Jul 1, 2024 · 0 comments
Labels
code-quality dependencies Pull requests that update a dependency file

Comments

@michaelsproul
Copy link
Member

Description

Presently Lighthouse is using ethereum-types for many of our core type definitions like Hash256. This is an old Parity crate that is not actively maintained any more, and there is some desire to move Lighthouse to Alloy so that it synergises better with the new Rust Ethereum ecosystem around Reth, forge, etc.

This task would involve:

  1. Updating all our external crates like ethereum_hashing, tree_hash, ethereum_ssz so that they do not depend on ethereum-types.
  2. Updating Lighthouse to depend on the updated versions of the external crates prior to releasing the crates on crates.io. We don't want to commit to merging alloy into our external crates until we're sure it's going to work & not be too much hassle. We should use patch to point at the feature branches for each crate so that the crate overrides apply globally (e.g. so that we are also patching transitive dependencies on ethereum_hashing via ethereum_ssz to use the git dep).
  3. Update API usage within Lighthouse
  4. Merge the changes to the external crates and release new minor versions signalling the breaking change.
  5. Update the Lighthouse PR to use the released versions of the crates, and then merge that to unstable.

Part 1 is already underway thanks to @KolbyML:

I have merged these branches down into an alloy branch on their respective repositories and created new PRs:

Ideas to minimise the size of the diff

  • We should alias B256 to Hash256 to avoid a huge amount of unnecessary rename churn. Even if we want to use the "proper" type name eventually, IMO it is better to separate the semantic change of using alloy, from a bunch of hard-to-review rename churn.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-quality dependencies Pull requests that update a dependency file
Projects
None yet
Development

No branches or pull requests

1 participant