change transaction value fields from u128 to a wrapper-type of U256

[roberto-bayardo]

Chains like OP stack can use the entire range of "value" (256 bits) in a transaction, so we are changing the type to a 256-bit capable representation. The field is still treated as u128 within to/from_compact for backwards DB compatibility with Ethereum & other chains where 128 bits is sufficient. A "value-256" feature is introduced that enables 256-bit DB encoding for value.

[codecov]

Codecov Report

Merging #4439 (ac462ff) into main (6f4febc) will increase coverage by 0.03%.
Report is 1 commits behind head on main.
The diff coverage is 77.65%.

Files	Coverage Δ
bin/reth/src/main.rs	14.28% <ø> (ø)
crates/consensus/common/src/validation.rs	71.73% <100.00%> (ø)
crates/interfaces/src/test_utils/generators.rs	98.23% <100.00%> (ø)
crates/primitives/src/transaction/legacy.rs	100.00% <100.00%> (ø)
crates/storage/codecs/derive/src/compact/mod.rs	94.84% <100.00%> (+0.02%)	⬆️
crates/primitives/src/transaction/eip1559.rs	83.94% <50.00%> (ø)
crates/primitives/src/transaction/eip2930.rs	92.59% <66.66%> (ø)
crates/primitives/src/transaction/eip4844.rs	38.73% <0.00%> (ø)
crates/primitives/src/transaction/tx_value.rs	98.24% <98.24%> (ø)
crates/rpc/rpc-types-compat/src/transaction/mod.rs	0.00% <0.00%> (ø)
... and 6 more

... and 11 files with indirect coverage changes

Flag	Coverage Δ
integration-tests	15.56% <27.65%> (+0.01%)	⬆️
unit-tests	62.60% <77.65%> (+0.04%)	⬆️

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

Components	Coverage Δ
reth binary	32.63% <ø> (ø)
blockchain tree	80.44% <ø> (ø)
pipeline	88.45% <ø> (ø)
storage (db)	73.32% <100.00%> (+<0.01%)	⬆️
trie	94.52% <ø> (+0.03%)	⬆️
txpool	49.62% <12.50%> (+0.44%)	⬆️
networking	76.08% <ø> (-0.04%)	⬇️
rpc	57.72% <0.00%> (-0.01%)	⬇️
consensus	61.06% <100.00%> (ø)
revm	28.54% <25.00%> (ø)
payload builder	8.16% <ø> (ø)
primitives	85.31% <91.89%> (+0.04%)	⬆️

[rkrasiuk]

@mattsse ptal

[roberto-bayardo]

this is just a draft, no need to review just yet. we need to figure out how to best implement the to/from_compact methods to preserve the current ethereum DB format.

[mattsse]

I understand why we need this and this fix makes sense to me.

One problem is, that we're running CI with --all-features, which should be fine for testing but I think we should take extra precautions so that it does not slip into the reth binary.

maybe with a mutually exclusive feature (ethereum) or another compile check in the reth binary

[mattsse]

@roberto-bayardo we just merge the big alloy transition, hence the conflicts.

feature-wise this PR lgtm and I'm supportive, I will make some feature changes so we guarantee that the reth binary never ships with this.

we can phase this out once we're breaking the database format.

And I'm actually not sure if this would even effect existing dbs on ethereum since we're always <u128, wdyt @joshieDo ?

[roberto-bayardo]

I have resolved the conflicts.

[mattsse]

lgtm.

I've added some macros that act as compile check to ensure the feature is enabled/disabled.

This is only needed for existing databases and can all be phased out when we decide to break the format