Final Dev Update - eODS (enshrined Operator Delegator Separation) specification

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.
  • sign off on their view of the current head of the chain, as alternative signal to that of the bonded Gasper operators.

1.2 ETH delegations are easily captured outside the protocol

In a functional enshrined delegation mechanism ETH holders will have a way to get the revenue they want for participating in protocol, in a direct relation with the validators (delegates/operators) executing the Protocol, mitigating the "grip" liquid staking currently has over staking.

1.3 It would increase protocol security

By creating the premises for a light class of protocol participants (light delegated validators) that would be the most decentralized type of participants (home stakers included).
Light Validators could run “light clients” in the sense that they will not require a full node to run.

Verifying the consensus layer only would be sufficient. Hence, they could be implemented through apps or browser plugins that are mostly passive and have very low computational overhead, hardware requirements or technical know-how requirements - V.B on notes.ethereum

2. Status report

The project consisted of two parts:

• Part 1 opened the possibility to enshrine delegations and allow Delegators to play a meaningfull role inside the protocol

• Part 2 focused on defining the possible role the Delegator could take at protocol level, and the attributes for light, delegated validators

2.1 Part 1 - eODS Specification

The goal for the first part of the project was to design (and eventually specificate) an explicit ETH delegation mechanism, in a manner that is both permissionless, and in-protocol.

This would produce an effect of unbundling the Validator role as we know it in today's day and age, in two protocol entities: Operator and Delegator

Project implementation phases

2.1.1 Prototyping

The conceptual design of eODS is a HackMD note containing the feature's design notes, analyzing the current status of delegations in the ecosystem and defining:

• The main players / entities under eODS
• Minimum set of requirements for eODS design
• Minimum viable design constraints
• Terminology
• eODS accounting and operations
• Predefined conditional relations - how the APIs of each protocol object under eODS gets activated and interact with each other.
• Workflow diagrams
• 4 eODS use cases

2.1.2 eODS accounting

Accounting is a very important part of the eODS model, so I wrote a design validation document in pseudocode, in order to define a possible workflow for a functional protocol accounting gadget, in the context of ETH delegations. Since 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, it proved useful to group these functions in a virtual group based on functionality (i.e. accounting) rather than beacon-chain specification appartenance.

2.1.3 eODS specification

My first step towards specificating eODS was to prove the beacon-chain accounting model I proposed for the feature, with a Python project and pytests attached.

The minimal requirements of functionality that were proven by tests:

• Initiating delegators, in delegators_registry, as a list of Delegator class instances.
• Deposit from outside the system, to a delegator’s balance. Delegator balances are stored as lists inside BeaconState registry
• Transfer capital from a delegator's balance to a specific validator's active balance
• Store delegators’ quotas, as lists, across all delegated validators
• Delegator initiated withdrawals from a certain validator’s delegated balance
• Adjusting delegators’ balances, according to their quota in the delegated validator’s balance, when the validator’s balance increases or decreases, due to rewards, penalties and slashing.

I didn't manage to write the python specification of eODS during EPF time span (the focus was more on design than on specificating), but the python project I referred to above will be a great starting point for me and anybody looking to contribute to specificating this feature.

2.2 Part 2 - Research Delegator role selection & incentivization

2.2.1 Introduction of light validators:

One of the main research points of the project was to identify a viable way to introduce light validators in Ethereum, so that Delegators could re-delegate stake to node operators running light validators, making that "restaked" stake un-slashable.

Theoretically, we can list a number of current and in research Validator attributes that could be removed from the Validator actions set and added to light Validator actions set, e.g.:

• Participation in sync-committee
• ILs
• Whistleblower

2.2.2 Actively Validated Service (AVS), as Delegator role selection

During the research part of the project, I advanced on the conceptual design for an interface that would allow future integration of light protocol services provisioned by a light class of validators that are "backed" by delegated, re-staked ETH. All this in a permissionless and in protocol manner and with the minimal possible disturbance on the way Ethereum consensus currently works.

The distinction between different types of protocol services, under eODS:

• Consensus (Finality) services - FFG type, provisioned by "heavy" validators

• Light (Non-finality) services - AVS type, provisioned by "light" validators

  Delegators could use the delegation proof, received after delegating towards operators (running validators) participating in FFG, for "backing" operators (running validators) participating in light protocol services e.g. CR services, committing to the provision of an “actively validated service” (AVS) and possibly receiving rewards for good service provision.

Possible separation of protocol services:

More research is needed, in order to assess IF and WHICH of the validator attributes can be SAFELY abstracted from the Validator actions set, into the light Validator's actions set.

3. Project Components

• EPF Cohort 5 Project Proposal
• eODS Design notes
• Beacon chain accounting - eODS feature - Hackmd note
• eODS specification - Github repository
• eODS Python toy project

4. Mentors and collaborators

I had Barnabe Monnot from RIG, that I turned to for mentorship. Many thanks go to him, Potuz and Mikhail Kalinin for the discussions that put the project on a path that made sense for the Protocol and that offers eODS feature the best chances of attracting community interest and support.

5. What comes next . . .

5.1. The Goal

The broader goal here is to develop better UX for onboarding ETH holders to provide light protocol services as a form or AVS, e.g. increasing CR. A future where not everybody fully stakes and ETH holders that want to meaningfully participate in the protocol can get returns by increasing the protocol's censorship resistance and safety, seems more and more plausible, especially with the AA and ZK breakthroughs of the last year. This view on the future got even more confirmed for me, these days, after Justin Drake's beam-chain proposal in Devcon Bangkok.

5.2. Specs work

Post EPF I continue to contribute to this project, as, after finalizing the prototyping part of eODS and Beacon-chain accounting during EPF, I aim to write the python specification of eODS in the months to come, leveraging my R&D work from the EPF project and advancing alongside the same scope. This strictly adds delegations as an optional way of introducing ETH in the system, from the outside, in parallel to how ETH deposit currently works, is not related to validator attributes or behaviour.

5.3. Research work

The project needs more work along these two main research topics:

• Introduction of light validators, and
• Delegator role selection & incentivization

A possible direction for participants looking to contribute and leverage the work I did for the EPF project, could be to develop a framework for adding light protocol services:

Conceptual design of an interface for adding light protocol services:

• General design principle
  • Design constraints
  • Define main entities: Delegators, light & heavy Operators and light & heavy Validators
  • Identify services
    • Finality gadget
    • Censorship-resistance gadgets (e.g. FOCIL)
  • Economics of consensus services
  • Economics of AVS
  • MVI of the different protocol services
• Specification notes referencing:
  • An adaptation of the slashing mechanism to account for partially slashable light services
  • Liveness
  • Protocol safety

6. My experience with the Fellowship

Protocol level R&D can be challenging for newcomers, so I had to make sure I'm improving my technical knowledge of the protocol and it's intricate logic.

During project implementation, I:

• Got better with collaborative work using Git
• I had to step up my Python skills so I can understand the logic behind the consensus-specs, and apply it to the eODS prototype I proposed
• I learned to run testnets and beacon-chain spec tests
• I wrote eODS use cases and pytests. There is room for improvement but I'm sure the work done for the project will come in handy when writing the actual specification of eODS
• Built my own tools, because I needed them, and maybe others will find them useful too:
  • Compute allocated memory of a defined class
  • Consolidated consensus-specs

7. EPF program feedback

The program was well organized, the new 5-months structure offering enough time to explore, and put in some serious work towards achieving project milestones, depending on our topic of choice. However, the cohort had projects that have a complex scope, too complex to be implemented in the allocated cohort time (my project included), and the fellows seem to be determined for seeing their projects trough. I also intend to continue putting effort in reaching longer term project milestones.

There were weekly stand-up calls on Mondays, and Office Hours, Tuesdays. We had the chance of presenting our weekly development updates during stand-ups, while Office Hours was a great opportunity to connect with protocol people, ask questions and go deeper in protocol topics, guided by mentors and guests.

Hats off to Josh and Mario for their flawless organizational skills, and their support during the cohort. A big thank you to the Ethereum Foundation for this great opportunity to work on protocol level.

In conclusion, EPF was a fun experience for me, but also a trip of initiation into the protocol world. Although we were not taken by the hand, au contraire, we were allways encouraged to do our own research and put in the time and effort before asking for help, I never had one moment of feeling out of place, or not guided towards the answers I was looking for. I now have protocol people (less or more experienced), from all over the world, that I can call collegues, and more than that, friends, that I know I will meet again in the infinite garden!

8. Resources

• EPF Wiki
• Barnabé Monnot's research post Unbundling staking
• Semantics of Staking 1: Liquefaction, [archived]
• Semantics of Staking 2: Re-staking, [archived]
• Semantics of Staking 3: Advanced Constructions, [archived]
• Ben Edgington's Eth2book
  
• V.B. - Protocol and staking pool changes that could improve decentralization and reduce consensus overhead
• V.B. - Enshrining liquid staking
• Ethereum consensus-specs