EPF5 Dev Updates - Week 2

## EPF5 Dev Updates - Week 2 [◀️ *previous update*](https://hackmd.io/@hangleang/epf5-week1) ### Goals For This Week - [x] PeerDAS: related-PRs on [consensus-spec](https://github.com/ethereum/pm/issues/1059) and [open questions](https://github.com/ethereum/consensus-specs/issues/3652). I also found a [tool](https://github.com/jimmygchen/peerdas-custody) by Jimmy, to play in the next week. - [x] SSZ: would need to check out [Simple Serialize (SSZ)](https://epf.wiki/#/wiki/CL/SSZ), as it is a way to serialize and deserialize data on consensus layer, and potentially replacing [RLP](https://epf.wiki/#/wiki/EL/RLP) on execution layer for a more robust operations on data structure. also will follow on the last ACD call [PR updates](https://github.com/ethereum/pm/issues/1069#issuecomment-2162556692) - [x] Find out which area to work on, and get connected with the core devs/contributors in the area. ### Dive A Little More Deep (Reading) - I started by reading SSZ [serialization](https://epf.wiki/#/wiki/CL/SSZ) and [merkleization](https://epf.wiki/#/wiki/CL/merkleization) from protocol wiki. Basically, **serialization** is a process to transform arbitrary types into a standardised form of data, which can be reconstruct back into original form later. On the other hand, **merkleization** is a process to transform the serialized data into a Merkle Tree, which provide efficient way to verify/validate proofs, especially client with low-resources environment (*light-client*). - Additionally, speed read on [SSZ and Merkleization specs](https://ethereum.github.io/consensus-specs/ssz/simple-serialize/) on `consensus-specs` for more details explanation - Go through some PR mentioned in the last CL call related to SSZ update. The implementations can be found in [stabilitynow.box](https://stabilitynow.box/) - [EIP-7495](https://eips.ethereum.org/EIPS/eip-7495): this proposal will include two SSZ types of `StableContainer[N]` and `Profile[B]` into consensus specs. The [PR](https://github.com/ethereum/consensus-specs/pull/3789) to include `EIP-7495` is being reviewing for inclusion. **StableContainer** will enable backward & forward-compatible serialization and stable merkleization for new changes in the future, potentially will be used in transactions and reciepts. **Profile[B]** is a type of subset of fields from a base type `StableContainer[B]` denoted as `B` - [EIP-7688](https://eips.ethereum.org/EIPS/eip-7688): this proposal will transform consensus data structures to `StableContainer[N]` and `Profile[B]`. I did inspect the required dependencies of the proposal, all is being included in [EIP-7600: Pectra Hardfork](https://eips.ethereum.org/EIPS/eip-7600), which is feasible for this proposal to also being included. Existing `hash_tree_root` and merkle proof verifiers need to be updated to support new Merkle tree structure, those functions will be broken once **reaching a new power of two (2<sup>n</sup>) in the number of fields** even though this EIP isn't introduced, forward compatibility will be quaranteed for future update once this EIP is implemented. - Then, spend much of time look into [EIP-7594: PeerDAS specs](https://github.com/ethereum/consensus-specs/tree/dev/specs/_features/eip7594) back and forth to understand the current scope of the PeerDAS implementation. - Before check out the specs, I have to understand how [Proto-danksharding](https://epf.wiki/#/wiki/research/scaling/core-changes/eip-4844) works in general, since the proposal is build on top on [EIP-4844](https://epf.wiki/#/wiki/research/scaling/core-changes/eip-4844), especially the **KZG commitment** cryptographic proofs, proving a piece of data exists in the set without revealing the entire dataset. **Blob sidecar** is the actual blobs data which propagated via p2p network, only the blob commitments is stored in the `BeaconBlock` for validation. - Review some open questions that're being discussed in [this discussion thread](https://github.com/ethereum/consensus-specs/issues/3652), seem like the configuration parameters (`CUSTODY_REQUIREMENT`, `TARGET_NUMBER_OF_PEERS`) in the specs still need to be finalized since there are some push-back from the contributors, and a [PR](https://github.com/ethereum/consensus-specs/pull/3779) to change the parameters and introduce fork-choice regarding the robustness and security of the network against some attack scenario. - Play with a tool ([webpage](https://jimmygchen.github.io/peerdas-custody/)) developed by Jimmy from Lighthouse, he is also one of the fellowship alumni. this tool shows how `get_custody_columns(node_id, subnet_count) -> list[column_index]` function in the specs works in practice when changing the `node_id` arg, I found some from [nodes crawler](https://www.ethernets.io/nodes/). Thanks to Mario ### Practices - Following on [SSZ Resources](https://epf.wiki/#/wiki/CL/merkleization?id=resources), I tried running [consensus specs](https://eth2book.info/capella/appendices/running/) from eth2book with a simple test case to calculate size of various container types based on the specs - Try follow instructions on [documentation](https://ethereum.github.io/consensus-specs/docs/new-feature/) on how to add new feature proposal in `consenses-specs` with `StableContainer` spec *(just for fun 😊)* - Check out [PeerDAS implementation](https://github.com/grandinetech/grandine/tree/das) in Rust by Grandine, built from source, and start the client with the branch - I thought the implementation branch is not up to date with the [alpha-3 specs](https://github.com/ethereum/consensus-specs/releases/tag/v1.5.0-alpha.3), and also there are a few [proposed projects](https://github.com/eth-protocol-fellows/cohort-five/blob/main/projects/project-ideas.md#grandine) from Grandine related to PeerDAS improvement, so I reached out to Mario if I can help on some parts of it. - Made a [PR](https://github.com/grandinetech/grandine/pull/29) to update container SSZ types to compatible with [v1.5.0-alpha3](https://github.com/ethereum/consensus-specs/releases/tag/v1.5.0-alpha.3) specs ### Plan For Next Week - Once got reference from Mario, and got connected with Grandine maintainer, I will get myself familiar with the repo *(e.g. project structure, process flow, etc)* - Seek support from mentors, and start working on project proposal - Continue working on making branch `electra` of Grandine compatible with `v1.5.0-alpha3` specs ### Conclusion As planned, I did a lot of reading, checked out some EIPs on SSZ regarding `StableContainer`, somehow a bit confused with `PeerDAS` *(EIP-7495 ~ EIP-7594)*, then review `Proto-Danksharding` to get the sense before checking the `PeerDAS` specs, and implementation on `Grandine` client, got connected with their maintainer, and made a PR to update based on `v1.5.0-alpha3` specs. --- [▶️ *next update*](https://hackmd.io/@hangleang/epf5-week3)