feat: add fundamental types

[mattsse]

adds a new crate that provides types used by reth,revm,ethers

having this separately makes it easier to unify types.

roadmap

• add crate
• make revm-primitives depend on this crate (for H256 type)
• likely move additional revm-primitives to this crate (Account, Log)

cc @prestwich

[codecov-commenter]

Codecov Report

Merging #1717 (5930ec5) into main (1846f2d) will increase coverage by 0.89%.
The diff coverage is 30.99%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##             main    #1717      +/-   ##
==========================================
+ Coverage   71.87%   72.77%   +0.89%     
==========================================
  Files         388      390       +2     
  Lines       46468    46710     +242     
==========================================
+ Hits        33401    33994     +593     
+ Misses      13067    12716     -351     

Flag	Coverage Δ
integration-tests	20.31% <0.00%> (+2.17%)	⬆️
unit-tests	67.56% <30.99%> (-0.25%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
crates/fundamental-types/src/bits.rs	30.70% <30.70%> (ø)
crates/fundamental-types/src/lib.rs	100.00% <100.00%> (ø)

... and 44 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[rakita]

This would make dependency hell if revm depends on reth that depends on revm.
reth-primitives are made for this reason to have just a subset of the exportable types from revm, you can reexport them here if needed.
Or we can move H types to ruint

[mattsse]

yeh, didn't think about that when discussing this with @prestwich

main motivation for this is to provide a solid foundation for all types for revm,reth,ethers(migration away from primitive-types)

Initially, I thought we need this for all the traits/codecs etc. but turns out we already have control over the rlp trait and can just solve this with features.

So, I perhaps the better solution is to make revm-primitives the base crate for everything type related?
however, there some types that revm only like Database and env.
The purpose of this fundamental type crate would to provide just the shared types.

Or we can move H types to ruint

I think ruint has its own B256 type?
don't know what the difference is

[rakita]

Asked remco: recmo/uint#228

[prestwich]

This would make dependency hell if revm depends on reth that depends on revm.

I think this gets resolved if we publish the types crate (which should be well-ossified) and stop depending on git versions for this crate. If revm and reth both depend on a published version of this types crate there should be no dep hell

[gakonst]

Let's avoid spending time on this as it's debt

[prestwich]

Let's avoid spending time on this as it's debt

Some solution is a blocker for ethers, I think

[gakonst]

Yeh just referring to Reth team needs to focus on the missing feats right now, I think realistically once we're "live" we'll want to do a zoomed out pass from our side, but would like to protect our time in the next few coming weeks. Closing and will reopen then

[prestwich]

If the reth team doesn't have time to maintain core types relied on by ethers, revm, foundry, and others, maybe those types should be maintained by another org?

[gakonst]

What I mean is that we do want to maintain these types and gather everyone around them, but right now dont want to do this refactor because we're changing things across 5+ repos (incl. all the cryptography etc. version bumps). Just asking for some patience hehe

[prestwich]

making changes across 5+ repos without a commitment to fundamental shared types is how we got into this mess in the first place