fusaka light client: implement Ssz and Log EIPs to enable merkle proof generation and validation

[g11tech]

WIP

ref: - https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6493.md

How to :

git clone the repo and checkout/pull the eip-6493 branch

in repo root run: npm i this will build all packages:

test ssz spec for the ssz wrappers

1. cd packages/util
2. (build the package if changed something from last build); npm run build
3. run test spec: npx vitest run test/ssz.spec.ts

Fusaka light client

• The endgame: https://fusaka-light.box
• kurtosis params to run locally: https://fusaka-light.box/network_params_fusaka-light.yaml

Work

doesn't include 7702 support, EL p2p still stays RLP which also implies that 6493 ssz txs out of scope. so for beacon payload, it shifts to the ssz stablecontainer format for txs, as well as the roots shift to ssz HTR

• [x] txs merkelization https://eips.ethereum.org/EIPS/eip-6404 and stablecontainer format for engine api
• [x] withdrawals root merkelization
• [x] blockheader/hash merkelization
• [x] receipts root merkelization https://eips.ethereum.org/EIPS/eip-6466, https://fusaka-light.box/el_receipt.html
• [x] logs bloom refactoring: https://notes.ethereum.org/@vbuterin/parallel_post_state_roots
  • state saved in a dummy system contract ivcPredeployAddress: '0x' + '6493'.repeat(10) (till actual contract is developed/ deployed)
  • also the ivcPredeployAddress is saved with nonce 1 for the first time to prevent eip 158 cleanup as a hack till actual contract is deployed
• [x] modified IVC log accum for best proofing capabilities and its placement for tx parallelization
• [ ] eth transfer logs: https://eips.ethereum.org/EIPS/eip-7708

Note

1. please note that a dummy hardfork eip6493 has been added for ease of development testing and devnet creation (on top of prague) so that will be cleaned up later when the work will become mergable
2. some parts of the code will be cleaned up/optimized later

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 33.73984% with 163 lines in your changes missing coverage. Please review.

Project coverage is 37.67%. Comparing base (4470cc3) to head (8821e70). Report is 105 commits behind head on master.

Additional details and impacted files

Flag	Coverage Δ
block	?
blockchain	83.49% <ø> (?)
client	?
common	89.90% <100.00%> (?)
devp2p	0.00% <ø> (?)
evm	65.18% <100.00%> (?)
genesis	0.00% <ø> (?)
mpt	51.69% <ø> (?)
statemanager	67.41% <ø> (?)
tx	?
vm	55.18% <30.63%> (?)
wallet	0.00% <ø> (ø)

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

[paulmillr]

FYI micro-eth-signer (https://github.com/paulmillr/micro-eth-signer) ssz implementation was like 8 times smaller the last time i've checked.

It's tree-shakeable, so you won't need to use the entire package.

[holgerd77]

🤔

Atm this work here is conceptual only (so: not to be merged soon), but might be worth a try.

[wemeetagain]

@paulmillr nice library, if you implement https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7495.md there, then it can be used

[etan-status]

@paulmillr thanks, have added it to https://stabilitynow.box

[paulmillr]

@wemeetagain @etan-status SSZ stable containers have been implemented in eth-signer v0.12.

[etan-status]

@wemeetagain @etan-status SSZ stable containers have been implemented in eth-signer v0.12.

Cool, have added the checkmark on https://stabilitynow.box – Thanks!!

[paulmillr]

@etan-status doesn't seem like the site got updated? Also url to micro-eth-signer is wrong, instead of github it's some random website

[etan-status]

Yeah, I noticed that weird link as well and informed @philknows - something weird with that notion instance going on (the link is correct in the editor but points to this weird caching server that has wrong http headers once rendered)

[philknows]

Yeah, I noticed that weird link as well and informed @philknows - something weird with that notion instance going on (the link is correct in the editor but points to this weird caching server that has wrong http headers once rendered)

This has been fixed now @paulmillr , thanks for bringing it to our attention!

[paulmillr]

@g11tech to clarify, micro-eth-signer, which you're already using in monorepo, supports stable container ssz out-of-box, today. I will make some benchmarks, but even the code size is 5x+ smaller.

[g11tech]

@g11tech to clarify, micro-eth-signer, which you're already using in monorepo, supports stable container ssz out-of-box, today. I will make some benchmarks, but even the code size is 5x+ smaller.

hey @paulmillr ! awesome! although will look into the replacement a bit down the line :)

[paulmillr]

SSZ benchmarks have been added to eth-signer. chainsafe/ssz is faster, however, it is not correct, and fails consensus-spec-tests. E.g. https://github.com/ChainSafe/ssz/issues/406

[g11tech]

SSZ benchmarks have been added to eth-signer. chainsafe/ssz is faster, however, it is not correct, and fails consensus-spec-tests. E.g. ChainSafe/ssz#406

yes this is correct, for 64 bit uint, this type is supposed to be used: UintBn64 (so we choose accordingly)

[paulmillr]

1. https://github.com/ethereum/consensus-spec-tests don't pass
2. See this https://github.com/paulmillr/micro-eth-signer/blob/be73fe4e4e512d26204b18c2f86d98bc90d09075/benchmark/ssz.js#L24-L32

[paulmillr]

Update: chainsafe maintainer mentioned consensus-spec-tests are not supposed to pass with the implementation:

https://github.com/ChainSafe/ssz/issues/406#issuecomment-2397702528

Yes, this UintNum64 type will not pass all consensus spec tests for the uint64 type

[g11tech]

superseded by https://github.com/ethereumjs/ethereumjs-monorepo/pull/3756 because of branch rename to more appropriate one