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

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

Project Proposal

Updates

Dev Update Week 1:

Reading

Dev Update Week 2/3:

This week

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):

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

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

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

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.

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:

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

Dev Update Week 10:

This week I worked on modifying the Capella specification and added new functionality that would allow pub key change.

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