You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Updating all our external crates like ethereum_hashing, tree_hash, ethereum_ssz so that they do not depend on ethereum-types.
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).
Update API usage within Lighthouse
Merge the changes to the external crates and release new minor versions signalling the breaking change.
Update the Lighthouse PR to use the released versions of the crates, and then merge that to unstable.
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.
The text was updated successfully, but these errors were encountered:
Description
Presently Lighthouse is using
ethereum-types
for many of our core type definitions likeHash256
. 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:
ethereum_hashing
,tree_hash
,ethereum_ssz
so that they do not depend onethereum-types
.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 usepatch
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 onethereum_hashing
viaethereum_ssz
to use thegit
dep).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:alloy
tree_hash#16alloy
ethereum_ssz#21alloy
ssz_types#25alloy
ethereum_serde_utils#8Ideas to minimise the size of the diff
B256
toHash256
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.The text was updated successfully, but these errors were encountered: