Week 0 - HackMD

## Intro This is Nando. During the last three years I've mainly been coding in Solidity (DivaStaking and Nektar Network), and have aslo had exposure to Python and Go. For this EPF I have two main personal goals: - To become proficient in Go/Rust - To move from merely using zero-knowledge technologies to laying solid foundations for researching and building them I want to focus on the Consensus Layer or in the boundary between Consensus Layer and Execution Layer, e.g. working on an efficient general purpose CL data prover in Execution Layer. During weeks prior to the start, I've been catching up with the latest trends in Ethereum, state of the art in ZK technologies and reviewing the list of proposed projects. ## Summary ### Consensus Layer - Beam Chain - Resources - https://beamroadmap.org/ - [Devcon - Keynote: Redacted - Justin Drake](https://youtu.be/rGE_RDumZGg?t=7187 ) - [Devconnect - Beacon chain design mistakes](https://www.youtube.com/watch?v=10Ym34y3Eoo) - [You’re Not Bullish Enough! Ethereum Roadmap & Beamchain with Justin Drake](https://www.youtube.com/watch?v=8mJDt8TGebc) - [Deep Dive into Ethereum's Beam Chain: Exclusive Insights with Researcher Justin Drake](https://www.youtube.com/watch?v=88FDeg5JaUk) https://bitvm.org/, https://rollup.wtf/, https://ethproofs.org/ - ⭐️⭐️ https://medium.com/@organmo/future-of-ethereum-1-beam-chain-52492e39af62https://metaschool.so/articles/beam-chain-ethereum-upgrade - https://blockworks.co/news/ethereum-consensus-beam-chain ### Consensus Layer - Road to the Beam Chain Upgrading the Consensus Layer is less intrussive than upgrading the Data Layer (blobs) and Execution Layer (EVM) as the Consensus Layer is the backend that does not interact directly with the Dapps. Breaking changes in Data or/and Execution Layer are limited as they would potentially break the applications. In this regard, there will be a purge in the Consensus Layer: ❌ epochs ✅ only slots ❌ deposit contract ✅ only precompile ❌ sync committees ✅ only SNARK proofs ❌ max balance ✅ only min balance ❌ deposit tree ✅ only EVM root ❌ withdrawal credentials ✅ only EVM address ❌ effective balances ✅ only balances ❌ committee indices ✅ only attestation slots ❌ swap-or-not ✅ only RANDAO Although the Beam Chain got some negative feedback from KOLs as they thought it was a "big refactor" or, not challenging, this seems a needed step to make Ethereum: - credible neutrality, censorship resistance - scalability, scalability, scalability (gas limit, SNARKIFICATION, posseidon...) - maintaining the current decentralization degree - post quantum computing resistance ### Key ideas Justin Drake's talks are great resources, but the following points are mainly based on [this article](https://medium.com/@organmo/future-of-ethereum-1-beam-chain-52492e39af62). #### Shorter Slot Time (4 seconds) [Source](https://medium.com/@organmo/future-of-ethereum-1-beam-chain-52492e39af62) Reduce minimum transaction confirmation time of 12 to 4 seconds. Key benefits: 1. Latency similar to other L1s. 2. Reduction of MEV. Generally, the amount of MEV decreases as block time shortens, making Ethereum users less susceptible to MEV. [# EIP-7782: Reduce Block Latency ](https://eips.ethereum.org/EIPS/eip-7782) "Approximately 98% of blocks are propagated within 4 seconds, while about 2% take longer. Based on this data, a 4-second block time may appear feasible. However, block time accounts for more than just communication — it also includes execution and voting. Considering these factors, only about 2 seconds of a 4-second block time would be available for communication. Under these conditions, achieving a 4-second block time is challenging." #### Faster Finality (Single Slot Finality, 3-slot FFG) [Source](https://medium.com/@organmo/future-of-ethereum-1-beam-chain-52492e39af62) Reduce the epoch size of 32 slots to a single slot (~12 seconds, maybe 4 seconds in the future), at the cost of increasing the resource usage for validator communication, negatively impacting Ethereum’s decentralization. 1. Economic security can be maintained increasing the size of the Max EB, reducing the number of communication. 2. Reducing the number of committees per slot, creating a super committee where the bigger validators are almost always included while rotating the validators with less stake #### Preconfirmation [Source](https://medium.com/@organmo/future-of-ethereum-1-beam-chain-52492e39af62) This feature is thought as an offchain sidecar rather than in-protocol e.g. Commit-Boost. For this reason, it needs community adoption to succeed. The preconfirmation allows block-producing entities to promise users that their transactions are to be included in the coming block. #### Chain Snarkification (Posseidon + zkVM) [Source](https://medium.com/@organmo/future-of-ethereum-1-beam-chain-52492e39af62) Instead of re-executing blocks all the time, the Beam Chain aims to replace this for the "verification" using ZK Tech. The verification process significantly lowers the hardware requirements for validators, enabling anyone to run an Ethereum node from anywhere (even smartwatches). This is where zkSNARKs come into play. The zkSNARKS will also server as the base for an aggregation algorithm for quantum-resistant signatures, improving the efficiency of the consensus layer. --- ### Zero Knowledge For a long time, I've wanted to follow this [Hickup's ZK Journey](https://sunrise-clerk-234.notion.site/Hickup-s-ZK-Journey-affa9ce9cdf44a33b3549c37f908521a) During this time I mainly reviewed the first two articles from the list which provides some examples of core ZK properties: [Zero Knowledge Proofs: An illustrated primer](https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/ ) and [Zero Knowledge Proofs: An illustrated primer, Part 2](https://blog.cryptographyengineering.com/2017/01/21/zero-knowledge-proofs-an-illustrated-primer-part-2/). Currently reading this [Why and How zk-SNARK Works: Definitive Explanation](https://arxiv.org/pdf/1906.07221): ## List of projects As per my interview, I had in mind a project that could start from this one [Prysm: Merkle Proofs of Everything](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#prysm-merkle-proofs-of-everything), extending it to Efficient general purpose prover of CL Data into Execution Layer. With Dencun upgrade, EIP-4788 came to live exposing the BeaconBlockRoot into the EL. The problem comes either when you need to verify information from the bottom of the beacon state (a field from a validator for example, at least 48 sha256 hashes) or when you need to verify many different fields which are also linked to EL information. So, this project would aim at "Generating the Proofs of Everything" while reviewing the state of the art of ZK technologies in order to build a tool capable of proving this information on-chain at least at a flat bounded cost. From the [project ideas list](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md), I would highlight the following ones: - [Erigon: RISCV Executable Proof Sourcing](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#erigon-riscv-executable-proof-sourcing) - [Erigon: L1 Clearing bridge](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#erigon-l1-clearing-bridge) - [Ream Client - A Beam client in Rust: Build Beacon Validator Client](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#ream-client---a-beam-client-in-rust-build-beacon-validator-client) - [Ream Client - A Beam client in Rust: Implement Beacon API Endpoints](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#ream-client---a-beam-client-in-rust-implement-beacon-api-endpoints) - [Ream Client - A Beam client in Rust: Benchmark zkVM performance on Ream's Beacon state transition functions](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#ream-client---a-beam-client-in-rust-benchmark-zkvm-performance-on-reams-beacon-state-transition-functions) - [Grandine: FOCIL (EIP-7805) Implementation and Testnet Deployment](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#grandine-focil-eip-7805-implementation-and-testnet-deployment) - [Grandine: zkVMs for Beacon Chain Snarkification](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#grandine-zkvms-for-beacon-chain-snarkification) - [Implement the Fast Confirmation Rule](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/project-ideas.md#implement-the-fast-confirmation-rule) Another project proposal would be "**Custom validator effective balance ceiling**": After Pectra hard fork, validators can increase their Effective Balance up to 2048 ETH. Consolidating validators is great for reducing the congestion in the gossipsub that could be problematic if Ethereum reached ~2.000.000 validators and also for the upcoming SSF where there will potentially be a redefinition of committees. With these changes, the excess of balance computed for the partial withdrawal (also known as skimming rewards) is computed from 2048ETH. This level is prohibitive even for Staking Pools which would depend on other mechanisms to trigger partial withdrawals. Adding custom ceilings for effective balance helps low-cap stakers and staking pools in being more competitive. This project can range from creating the EIP plus the development of it in a major Consensus Layer client ending up in testing it in Kurtosis ### Next Step - Choose a project and write a proposal - Continue with ZK theory