DanGoron: week 16-17 development update

Phase I.2 of my EPF project has come to an end with writing use cases, and prototyping the APIs of eODS protocol objects. Starting next week (Week 18), I enter the project's last official month, and into Phase II. Research Delegator role selection & incentivization.

Week 16

1. I finalized writing the general eODS use cases, as planned.

As prep work for writing the specs for the eODS feature, I started working on two sub-tasks:

2. I wanted to have a consolidated view of the consensus specs and realized that there isn't such a resource, for various reasons. As I discussed with my EPF peers and mentors during our last Monday standup, the reason could be that it was not considered an absolute need, and most devs are happy enough with just having fork-specific changes presented in the specs. That might be the case, but for my own use, I considered this to be an addition, and in the end it seems it just might be a good EPF wiki project. These are the beacon-chain consolidated consensus-specs, up to Bellatrix. I'm working on Cappella at this point, and 2 other wiki contributors work on validator. We plan to push the repo to the wiki after EPF5 ends, as a resource.

3. From the same category of "We did it because we needed it", I put together Size compute - a python script for the heuristical calculation of StateSize, using classes, that can be declared based on consensus-specs class attributes. I will improve it and use it as needed during the specs writing phase.

Week 17

1. This week I had a call with Mikhail Kalinin, following his AMA with the EPF cohort, on analyzing a possible minimal specification and implementation of eODS.

Meeting highlights:

• most eODS-proposed API interactions and operations can be done with existing protocol functionality
• In order to get pragmatic and think about clear specifications that can lead to eODS implementation, it would be recommended to separate the actual enshrinement of delegations from the research / design of delegator role in Ethereum PoS. In other words, focus on introducing in-protocol delegations, and just specificate / implement delegation towards heavy validators . Basically, that means leaving validator role as is today and just introduce the delegator entity inside beacon-chain registry and accounting.
• Beacon chain accounting is the thing to focus on, short-term (in parallel to the research phase, and mostly after EPF ends), in order to solidify the eODS design and have a functional model.

2. After the meeting with Mikhail, I started to take a dive into Beacon chain accounting, taking notes and writing down the first chapter of the summary - Validator balances.

Organizing last 4 weeks of the project

• I set a call with Barnabe Monnot (Week 18), related to the scope of the research phase (last 4 weeks of the project), on Delegator attributes, and practical applications in light validator actions set and incentivization.

• More beacon chain accounting

• I want to study more about Operations, including the open issue of withdrawals, left from prior weeks:

• Delegator triggered 0x01 withdrawals