eODS (enshrined Operator-Delegator Separation) - modelling the logic with a toy Python project Introduction After EPF cohort-five ended, I hacked an eODS toy project, based on the beacon-chain-accounting model I worked on during EPF. The aim is to explore and test (locally) one possible functional model for implementing delegations in Ethereum, at protocol level, with the minimal possible disruption to the current protocol. The logic The logic is built on top of Electra upgrade logic, and is based on the eODS design notes. The minimal requirements of functionality that were proven by the project:

1. Motivation Today, ETH delegators allocate their principal to node operators off-protocol, via staking pools. In current Ethereum, capital providers do not actively participate in Consensus. We can improve this by allowing the Protocol to identify delegated stake and incentivize the Delegator role selection. Allowing in-protocol delegations and having a meaningful role for delegators is a health indicator of any staking system. The current role principal providers play in delegated proof-of-stake is limited to voting within pools, which ultimately is just a flawed type of voting. 2. The current status of delegations In regards to enshrining delegations in the context of Ethereum staking, at least to the author's knowledge, there is no ongoing research or design reaching community consensus.

1. Abstract Five incredible months have passed since the start of this year's EPF program and now, I feel at the end of a trail and the beginning of a road. The following constitutes both my final development update (project-wise) and a manifesto for continuing the research & development work related to introducing Delegations in Ethereum, work initiated during this 5th cohort of the Ethereum Protocol Fellowship. As I would find out during the implementation of the project, delegations in the Ethereum protocol is a feature that would be "cool to have", but is extremely underrated. At least to my own knowledge, there is no reference of prior work being done on this topic, in the R&D community. During the project-proposal phase and the design phase, there was quite a bit of back and forth on the philosophy and fundamentals behind having such a feature and how should it look like at protocol level. Three main reasons for having delegations enshrined in the protocol that created a reverberating effect in my work during EPF: 1.1 We need strong protocol role for ETH holders (Delegators) This is a key property of any healthy staking system. Looking ahead, we can safely assume that there could be any number of ETH holders that would prefer to be given the option to take on a role to play in consensus, which would be "lighter” than full staking, but still meaningful: The curation of operator sets: Opinionated delegators may decide to choose between different operators based on e.g., fees or reliability. The provision of light services: The delegators may be called upon to provide non-slashable, yet critical services, like:input their view into censorship-resistance gadgets such as inclusion lists or multiplicity gadgets.

As I mentioned in the Accounting section of eODS design notes, beacon chain accounting already exists under the current protocol, in the form of beacon chain operations, or beacon state mutators, e.g. process_deposit, increase_balance, etc. Since Accounting is an important part of eODS model, it proved useful to group these functions in a virtual group based on functionality (i.e. accounting) rather than beacon-chain specification appartenance. This document is a study I made on beacon chain accounting under the current Ethereum protocol. The following is a design validation document (pseudocode), with a python project and pytests attached, in order to prove the beacon-chain accounting model I proposed for the eODS feature. 1. Validator balances 1.1 Validator records We can add delegated boolean entry in the records:

During the last 2 weeks of the 5th EPF cohort, my work was focused on a design validation document (pseudocode), with a Python project and pytests attached, in order to prove the beacon-chain accounting model I proposed for the eODS feature. As I mentioned in the Accounting section of eODS design notes, beacon chain accounting already exists under the current protocol, in the form of beacon chain operations, or beacon state mutators, e.g. process_deposit, increase_balance, etc. Since Accounting is an important part of eODS model, it proved useful to group these functions in a virtual group based on functionality (i.e. accounting) rather than beacon-chain specification appartenance. This document is a study I made on beacon chain accounting under the current Ethereum protocol. This is the document: Beacon chain accounting - eODS feature 4. Post EPF work for this topic I plan to fix the remaining tests and functions (marked as BROKEN), so that all minimal eODS functionalities in terms of delegators and delegated validators are met, during next 4 weeks and refactor where appropriate, in order to have this Python implementation as close to the logic of beacon-chain specs as possible.

1. Validator balances The beacon chain maintains two separate records of each validator's balance: its actual balance and its effective balance - Ben Edgington's "Upgrading Ethereum" on Balances 1.1. Actual balance A validator's actual balance $= deposits + rewards - penalties - withdrawals$ 1.1.1 Beacon chain records Actual balance is stored in the BeaconState records, as a registry of validators and their balances: # Registry

I put together a beacon-chain accounting design validation document (pseudocode) and a python project, including pytests to prove the eODS beacon-chain accounting design. Beacon chain accounting - eODS feature 1. Validator balances 1.1 Validator records We can add delegated boolean entry in the records: class Validator(Container): pubkey: BLSPubkey withdrawal_credentials: Bytes32 # Commitment to pubkey for withdrawals

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

eODS Prototyping Here are the updated eODS Design notes. Summary The design defines design constraints, entities and the conditional relations between them. During Weeks 14 and 15, I also added 3 case studies. Week 14, 15 development 1. Open issues from prior weeks

eODS Prototyping Here are the eODS Design notes. The design defines minimal Design constraints, ENTITIES and the Conditioned relations between them. Week 12, 13 The following eODS elements were defined and finalized: Balance sheetsBalance sheets are built as described in the prerequisite reading of my previous dev-update, based on assets and liabilities, and the operations that manage them. minimal Design constraintsFor prototyping eODS, a basic suite of features was defined. They are essential for any viable implementation of introducing in-protocol delegations. By deciding on basic design constraints, the range of potential solutions becomes narrowed:Validators are funded with ASSETs (virtual tokens representing the balances of entities), in order to provide services for the heavy Consensus (slashable) or light Consensus (non-slashable).

Project implementation Week 10 I made the final commits to the project proposal, after the reviews and comments phase. Notable changes to my proposal: After reviews and DMs with Barnabe Monnot, I concluded that it would be optimal to work with a new DELEGATION_CONTRACT, instead of modifying the current DEPOSIT_CONTRACT to accomodate delegations I updated the project's roadmap based on current dynamics, meaning that the research phase I had in mind at the end of the project for identifying possible delegators roles in consensus, is now integrated with the eODS prototyping phase, because the reality is that I can't settle on minimum viable design constrains for eODS actors, without knowing their possible roles first, and this is important for a functional design. Week 11

Project implementation Notable aspects of this week: I've answered reviews and re-requested reviews from mentors on the project proposal More discussions with peers and mentors on the conceptual design. The diagram of the current state of the concept is in last week's update Week 10 planning More discussions with mentors, on the current level of the design. Finalize the strawman for the eODS specs.

Project implementation Notable aspects of this week: getting and answering reviews from mentors on the project and eODS strawman (the conceptual design document). The diagram of the current state of the concept: Screenshot from 2024-08-04 13-39-29 working on finalizing the strawman Week 9, 10 planning More discussions with mentors, on the current level of the design. Finalize the strawman for the eODS specs.

Project implementation Second week of project implementation. This week was mostly about working on the strawman for eODS design notes Solved (at strawman level) Deposit process Reading delegations from deposit Adding delegators to registry / consolidate delegations if pubkey exists and is_delegator is set to true Partially: Accounting - Capital<->Liability transfer between Delegator and target Validator by adding Delegation message signed by Delegator with the private withdrawal key

Project Proposal This week's work was mostly about refining and submitting my Project Proposal, the associated PR can be found here. Project implementation (Week 6) It was the first week of actual project implementation. I progressed with writing the specification notes for the beacon chain deposit-contract.md (Phase 0) and validator.md changes to accommodate delegations, to a phase where I can open a PR on my Github remote branch. Week 7,8 planning Finalize a strawman for the eODS specs, that I can discuss with mentors

ETHCC meeting with permissionless staking pool representative Got in contact with a permissionless staking framework provider, and met at ETHCC. Discussion points: Analyze how the separation of the Validator role between Operator and Delegator will influence staking pools and staking overall. Analyze how the two-tiers staking split will influence staking pools and staking overall. Forking the staking-deposit-cli to accommodate ETH Delegators Key takeaway after the meeting:

eODS design rationale development I settled on a design rationale detail, regarding enshrining Delegators. Related to building the beacon-chain Delegators registry, I'm going for adding the new class Delegator container in the beacon-chain specs and NOT alter existing containers with new fields (as previously intended), in order to introduce as few breaking changes as possible. This reflected in the Project Proposal, and in the: Project presentation slides - for EPF day at ETHCC week This is the presentation I used at EPF day in Brussels

SSF After reading Week 1 material on SSF^1, I conclude that the two-tier staking approach^2^4 can have real positive externalities for the Ethereum network, in the SSF scenario, but not limited to that as I will show further in my update. Python error handling Python exceptions^5 Raising an exception number = 10 if number > 5: raise Exception(f"The number should not exceed 5. ({number=})") print(number)

Thrilled to be part of the 5th Ethereum Protocol Fellowship cohort! We had the kick-off call on Monday the 10th June, and the office hours meeting on Tuesday. One thing that stuck with me is to approach the core development/research in a holistic way, outside of just the strict scope of my project and get a bird's-eye view of the protocol's roadmap and where everything is heading to, while understanding that there are real people all around the world involved in the process and that implementing one's goals in core dev/research means interacting with peers and disseminating as much as possible. Week 1 topics This week I started broadening my protocol study and research on topics I feel will help me better understand the protocol and core development / research, and take the deep dive into these topics while advancing towards my objectives. The broader goals of my project, being to introduce Delegators as a new class in beacon state and to separate protocol services into a heavy class and a light class, is reflected in this week's study. Serenity design rationale