Ethereum Protocol Fellowship - Cohort 3 === Hello Everyone :wave:, My name is Alpesh and I am a finaly PhD student at Royal Holloway, University of London. Over the next months, I will be participating in the 2022 Ethereum Protocol Fellowship. I will publish my findings and progress updates here on weekly basis. # Table of content - [Program](#id-program) - [Project-Proposal](#id-proposal) - [Updates](#id-updates) - [Week1](#id-week1) - [Week2](#id-week2) - [Week3](#id-week3) - [Week4](#id-week4) - [Week5](#id-week5) - [Week7](#id-week7) - [Week8](#id-week8) - [Week9](#id-week9) - [Week10](#id-week10) - [Week11](#id-week11) <div id='id-program'/> ## Program #### Phase 1 (Week 1): - Learn about Ethereum protocol and read through the recommended reading material. - Set up a validator on goerli testnet to understand its inner workings. #### Phase 2 (Week 2-3): - Deep dive into specific areas of interest - Connect and discuss with mentors about your chosen topic - Outline project proposal #### Phase3 (Week 3-14): - Continue participating in calls - Continue making weekly-biweekly updates on one’s research and development - Work to execute and deliver your project proposal. - Develop a mini-spec document highlighting how the solution will be implemented. - Discuss the solution with the mentors. #### Phase4 (Week 14-16): Create a summary report and presentation outlining what you worked on, the challenges faced, and the problems that were addressed and solved. #### Project Mentors - Fredrik - Hsiao-wei <div id='id-proposal'/> ## Project Proposal <div id='id-updates'/> ## Updates <div id='id-week1'/> #### Dev Update Week 1: ##### Reading - Upgrading Ethereum: https://eth2book.info/bellatrix/ - Withdrawal Mechanism: https://eips.ethereum.org/EIPS/eip-4736 - Setting up Validator Georli Testnet: https://someresat.medium.com/guide-to-staking-on-ethereum-ubuntu-prysm-581fb1969460 - Ethereum Core Devs Meeting: https://www.youtube.com/watch?v=oQfEW8LdE88 - Read the Yellow Paper: https://ethereum.github.io/yellowpaper/paper.pdf - Consensus Layer Reading: * Beacon Chain: https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md * Combining Ghost and Casper: https://arxiv.org/pdf/2003.03052.pdf * Different Types of Nodes: https://ethereum.org/en/developers/docs/nodes-and-clients/ * The Fork-choice Rule: https://notes.ethereum.org/@djrtwo/Bkn3zpwxB?type=view#Fork-Choice-Rule <div id='id-week2'/> <div id='id-week3'/> #### Dev Update Week 2/3: ##### This week - Review the specs: https://github.com/ethereum/consensus-specs/blob/dev/tests/core/pyspec/README.md - Review the code base for Prysm: - Learning how to use the executable consesus Pyspec > https://github.com/ethereum/consensus-specs #### Summary: Using the Executable Consensus Pyspec The project has three main purposes: 1. It's a collection of Ethereum core **consensus specifications** - define the consensus protocol that running by the consensus layer (CL) clients. 2. It's **executable** and **verifiable** python program - it can be built into a Python program that can be executed. 3. It's a **test vector generator** - it can generate the test vectors (CL implementations) for CL clients to run with and test against the consensus rules. ***Adding new feature patch:*** 1. Implement new features in Pyspec markdown files 2. Release new Pyspec with test vector suite 3. CL clients implement and test against test vectors Note: The project is useful when adding new feature/s to the CL i.e. the beacon chain side of things. A developer can prototype with the markdown files and perform tests on their implementations. The test vectors are generated with the python programs test case, such as pi test. ***Spec Structure* | /consensus-spec/specs dir** - **altair** - **bellatrix** - *capella* - Interested in modifying this version - *custody_game* - *das* - *eip4844* - **phase0**** - beacon-chain .md //the most important entry - deposit-contract .md - fork-choice .md // as well as the fork choice - p2p-interface .md // and p2p interface in it. - validator .md - weak-subjectivity .md - *sharding* Note: (**bold**): Mainnet protocol upgrades already applied & (*italic*): WIP features (work-in-progress features) **An example showing specs inside **phase0** directory. ***Type and values definitions*** Note: The beacon chain uses a novel serialisation method called **Simple Serialize (SSZ)** /consensus-spec/ssz dir. E.g. A cooking recipe is a kind of serialisation. The Types, Constants, Presets, and Configuration can be defined: - Custom Types - Each type has a name, an "SSZ equivalent", and description. SSZ is encoding method used to pass data between clients, among other things aka primitive data type. - **BLSPubkey** type holds a validator's public key, or the aggregation of several validator's public keys. - Boneh-Lynn-Shacham is the digital signature scheme used by Eth2. It's unique properties allow signatures to be aggregated. This allows many validators to sign the same message (e.g. supporting a particular block X) and their signatures to be efficiently aggregated into a single signature for verification. In Eth2.0, BLS public keys are elliptic curve points from the BLS12-318 G1 group, as such they are 48 bytes long when compressed. - Each protocol's signature types is augmented with the appropriate domain before signed: - Signed block proposal incorporate **DOMAIN_BEACON_PROPOSER** - Signed attestations incorporate **DOMAIN_BEACON_ATTESTER** - RANDAO reveals are BLS signatures, and use **DOMAIN_RANDAO** - Deposit data messages exit messages incorporate **DOMAIN_VOLUNTARY_EXIT** - Sync committee signatures incorporate **DOMAIN_SYNC_COMMITTEE** - Constants - Things that are expected to never to change for the beacon chain, no matter what fork or test network it is running. - Preset - These are consisten collections of configuration variables that are bundled together. The spec repo currently defines two sets of presents: - **Mainnet:** The mainnet configuration is running in production on the beacon chain - **Minimal:** often used for testing - Configuration - Genesis Settings. Note: The default mainnet configuration values are included here for illustrative purposes.Defaults for this more dynamic type of configuration are available with the presets in the configs directory. Testnets and other types of chain instances may use a different configuration. ***SSZ Containers*** Note: Classes are also defined; the SSZ containers - it is used to do serialization in the consensus object. Use SSZ hash tree root as the digests of concensus objects. ***SSZ Containers*** State transition function - all are pure functions. - Beacon chain state transition function - The post-state corresponding to a pre-state **state** and a signed block **signed_block** is defined as **state_transition(state, signed_block)** Note: A developer can write down python functions in the code block of in the markdown files. This function also contains the **assertions** so if there is an error then it means the input has errors, thus, it does not pass the test. ***Setup.py file*** `def _build_spec(preset_name: str, fork: str,` This program helps pass the markdown files and convert them into a python program. BellatrixSpecBuilder: `class BellatrixSpecBuilder(AltairSpecBuilder):` ![](https://i.imgur.com/pn0NnAt.png) Note: i) the phase 0 is the base layer of all the consensus specs. ii) In order to understand the Altair, developer needs to merge/extend the phase0 specs and the new features in the Altair. Similarly for Bellatrix, all three specs needs to be merged. ***How to use Pyspec*** 1. Install from PyPI: `pip install eth2spec` 2. Install from source with venv: a. Download the source code:`git clone https://github.com/ethereum/consensus-specs.git` b. Install with Makefile commands: `cd consensus-specs` `make install_test && make pyspec` <div id='id-week4'/> #### Dev Update Week 4: - Finalise the project proposal and set up meetings with the mentors - completed. - Mentors: Fredrik and Hsiao-wei - Project Proposal: [See above](#id-proposal) <div id='id-week5'/> #### Dev Update Week 5: - This week I am planning to start working on developing a mini spec document capturing the problem/solution. - My first goal is to understand the current key management process for both withdrawal key and the signing key. ##### Mini-Specification <!--- Validator signing key rotation mini-spec --> A design draft to extend the staking-deposit-cli for validator signing key rotation upon compromise. There is an existing EIP request "design draft to extend staking-deposit-cli for withdrawals" where two new types will be added: SignedBLSExecutionChange and the BLSToExecutionChange. Validators with the "legacy" 0x00-type withdrawal credentials will need to issue a one-time message on-chain to change to the 0x00-type withdrawal credential that points to the some address at the execution layer. <div id='id-week7'/> #### Dev Update Week 7: This week I worked to defining the project scope and discuss the specifications\deliverables with mentors. The project scope can be found at: <div id='id-week8'/> #### Dev Update Week 8: Started analysing the PySpec - Capella and modifying the specification to allow key revocation mechanism. Detailed analysis is available at: https://hackmd.io/VYSDLKlTQBW5UQ8yqbZFAw?both <div id='id-week10'/> #### Dev Update Week 10: This week I worked on modifying the Capella specification and added new functionality that would allow pub key change. <div id='id-week11'/> #### Dev Update Week 11: This week I am planning to continue development work and write test cases for the new functionality. #### Dev Update Week 12: #### Dev Update Week 13: 23th Jan: This week I implemented the pubkey change feature in the PySpec which is ready for review. Initially was experiencing some issues with getting new specs to executable; #### Dev Update Week 14: 30th Jan 2023 This week I am working on writing some test cases for the pubkey change feature to check the sanity acros; #### Dev Update Week 15: 6th Feb 2023 Last week I discussed with mentors the current implementation of the pubkey-change feature. I was having compile errors and mentors advised the steps to resolve the issues. I modified the constant and context files to include the execution of of the new project specifications. The pyspecs are now executable and tests cases are working. This week I am aiming to write a specific test case for the pubkey-change and performing some sanity checks against the specs. Updated the block_processing test case and ran it against the new feature. Currently debugging the errors. My aim is to wrap up development by next week so I can focus on project write up/presentation - ready for ETHDenver. ##### High-level architecture ##### Security Design