Progressive data structures and tests EIP-7916, EIP-8016 - #8505
Progressive data structures and tests EIP-7916, EIP-8016#8505michaelsproul wants to merge 14 commits into
Conversation
michaelsproul
added
spec_change
|
I've made a bunch of progress on this, but it requires local checkouts of
Progressive bitlist tests are currently not passing, need to dig into why. The derive macro for progressive containers with 1 field works though 😅 |
| #[derive(Debug, Clone, PartialEq, Decode, Encode, TreeHash, Deserialize)] | ||
| #[tree_hash( | ||
| struct_behaviour = "progressive_container", | ||
| active_fields(0, 0, 0, 0, 1) | ||
| )] | ||
| #[context_deserialize(ForkName)] | ||
| struct ProgressiveSingleListContainerTestStruct { | ||
| C: ProgressiveBitList, | ||
| } |
There was a problem hiding this comment.
Looking for feedback on the UX of this.
I quite like this UX for progressive containers because it closely follows the spec. We can just copy the active_fields vec straight into the struct attributes.
michaelsproul
changed the title
|
Hi @michaelsproul (cc @macladson) !! I've been mapping SSZ progressive-type support across the Rust ecosystem for downstream EL adoption. Reading the four PRs together, the visible blockers seem to be:
If priorities pulled you elsewhere and you'd welcome help, I'd be glad to take on the rebase + spec-sync across the four PRs and close out those blockers. I'd do the work as draft PRs from a fork so you keep ownership of the design , happy to squash credit back to you and Mac on merge. Won't touch anything until you say go. Two questions before I'd start:
Happy to move this to Discord if easier. |
|
Hi @Zyra-V21 we've got it covered |
|
Closing in favour of: |
## Relevant Links - https://eips.ethereum.org/EIPS/eip-7688 - ethereum/consensus-specs#4630 ## Proposed Changes Adds the necessary types and components to support EIP-7688, along with the cargo patches to pull in the `progressive` versions of the crates in our SSZ stack. ## Testing ```yaml participants_matrix: el: - el_type: nethermind el_image: ethpandaops/nethermind:master cl: - cl_type: nimbus cl_image: ethpandaops/nimbus-eth2:glamsterdam-devnet-7-minimal - cl_type: lodestar cl_image: ethpandaops/lodestar:glamsterdam-devnet-7 - cl_type: lighthouse cl_image: ethpandaops/lighthouse:glamsterdam-devnet-7 - cl_type: teku cl_image: ethpandaops/teku:glamsterdam-devnet-7 ethereum_genesis_generator_params: image: "ethpandaops/ethereum-genesis-generator:glamsterdam-devnet-7" dora_params: image: ethpandaops/dora:glamsterdam-devnet-7 global_log_level: debug network_params: preset: minimal gloas_fork_epoch: 1 additional_services: - dora ``` ## Additional Info Based on the original work by @michaelsproul in #8505 Co-authored-by: Michael Sproul <michael@sigmaprime.io>
3 participants
Proposed Changes
Run the EF tests for new types from EIP-7916 and EIP-8016:
ProgressiveListProgressiveBitListThe SSZ generic tests are passing if you run them without compiling the rest of Lighthouse:
Everything else is probably broken.
Additional Info
Depends on:
ProgressiveList(EIP-7916) milhouse#82Known Issues
BitList<Progressive>::with_capacityhas created some type inference ambiguities causingstate_processingnot to compile. We should probably rename this method inethereum_ssz.unstablesince the types refactor nor the gloas-containers merge.