# Constructing `BeaconState` from SSZ

## Progress

1. **[Feature]** Worked mainly on [consenzero](https://github.com/unnawut/consenzero), or more specifically tried to fetch the beacon head slot number (done), then fetch the beacon state at that particular slot number (in progress). See [my draft PR](https://github.com/unnawut/consenzero/pull/1) for the work in progress.
2. **[Chore]** Internal organization - Spent some time on external coordinations and coming up with rationales for:
1.1) Why Ethereum needs another consensus client
1.2) Why Ream client development should start now

## Details

- I've been trying to generate mock BeaconState from scratch, in hope that I can use it to prepare the data for experimentation with zk state transitioning. It's been straight hard labor since the BeaconState [contains over 20+ attributes](https://ethereum.github.io/consensus-specs/specs/deneb/beacon-chain/#beaconstate), each with its own complex types that need to be prepared.
- After a hint from [Jun Song](https://hackmd.io/@6kR9CHxoQ1ujPzY6ZI6kEQ) that the consensus-spec-tests contain [SSZ-serialized data for testing purposes](https://github.com/ethereum/consensus-spec-tests/tree/master/tests/mainnet/deneb/ssz_static), I gave up generating the state from scratch and tried to construct the state from pre-existing SSZs instead.
- Kolby has [this code in ream repo](https://github.com/ReamLabs/ream/blob/master/testing/ef-tests/src/macros.rs) that's a pretty neat example of how to deserialize the SSZ for usage in Rust
- However, instead of fetching from the `consensus-spec-tests` data, I tried to fetch fresh SSZ'ed state straight from the Beacon API because:
- The test data contains only 5 cases but the end goal for [consenzero](https://github.com/unnawut/consenzero) is to be able to continuously snarkify the CL's state transition. So having a live and continuously updated source of data would be ideal.
- Fetching fresh SSZ data is quite trivial. The Beacon API contains a [debug endpoint that allows you to fetch a full beacon state](https://ethereum.github.io/beacon-APIs/#/Debug/getStateV2), it's also conveniently able to output SSZ format when provided `Accept: application/octet-stream` into the request header.
- I didn't get very far today after fetching the SSZ. I spent some time debugging only to realize that I was using incompatible BeaconState schema with the SSZ data. Really noob mistake.
- I was fetching BeaconState SSZ from https://beacon.mekong.ethpandaops.io/ which is based on Electra specs, but [ream's BeaconState schema](https://github.com/ReamLabs/ream/tree/master/crates/common/consensus/src/deneb) is based on Debeb
- Big thanks to https://simpleserialize.com, I was only able to confirm my mistake by deserializing the SSZ on their web UI and found out that there were extra attributes in the BeaconState SSZ that were introduced in Electra.
- Now having switched to a Deneb API, I'm still unable to deserialize the BeaconState:

    Err(
        InvalidByteLength {
            len: 204919,
            expected: 262320,
        },
    )

## Next

- Continue to try fetch/debug the BeaconState SSZ from a Deneb instance of the Beacon API
- Try construct the BeaconState from a local SSZ file instead
- Perform a tiny subset of the state transition within risczero zkVM