Week0 - notes on my EPF Project: Two dimensional, enshrined Operator-Delegator Separation (eODS)

# Week0 - notes on my EPF Project: Two dimensional, enshrined Operator-Delegator Separation (eODS) | References | TL;DR | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | [eODS wiki page](https://epf.wiki/#/wiki/research/eODS) | In-protocol separation and disambiguation of Validator role, between Operator and Delegator, separated in a Heavy staked layer and a Light staked layer | ## Project motivation One topic I find most interesting in R&D space, is **staking economics in the context of Single Slot Finality(SSF)** - the Consensus $<->$ Staking interaction. Community debates [spurred again recently](https://vitalik.eth.limo/general/2024/05/17/decentralization.html#liquid-staking), part of a [wider devs-researchers discussion](https://x.com/dankrad/status/1791379755922498027) on whether the community is building toward the right goals or not. >*Another important part of this [...] is the economics of staking. A key question is: do we want staking to be a relatively niche activity, or do we want everyone or almost everyone to stake all of their ETH? If everyone is staking, then what is the responsibility that we want everyone to take on? If people end up simply delegating this responsibility because they are lazy, that could end up leading to centralization. There are important and deep philosophical questions here. Incorrect answers could lead Ethereum down a path of centralization and "re-creating the traditional financial system with extra steps"; correct answers could create a shining example of a successful ecosystem with a wide and diverse set of solo stakers and highly decentralized staking pools. These are questions that touch on core Ethereum economics and values, and so we need more diverse participation here.* - Vitalik Buterin ### The inevitability of SSF Ethereum is constantly improving and growing on its way to becoming the envisioned global-scale network. In this scenario, single-slot finality is not only desirable but most likely mandatory, and I feel that if we're building towards the right goals, we better be building towards SSF. However, good trade-offs are needed on the path towards SSF, and these trade-offs are not an easy task to identify, disambiguate, or solve, as they depend on a wide range of challenges and limitations that range from physical network limitations (e.g. computing power) to technical limitations (e.g. per slot BLS signatures aggregation), to not-just-technical fundamentals (e.g. community goals and values vs. out-of-protocol market forces). Regardless what the goals set by the Ethereum community turn out to be, enshrining ODS would help the community impose those goals, by exercising better control over the validators that execute the protocol, while addressing the challenges mentioned above. ### Enters eODS :::info The correct acronym for the implementation would be 2D-eODS (Two dimensional, enshrined Operator-Delegator Separation), but for simplicity and elegance, I went for a more generic name of eODS. ::: Implementing eODS implies a two dimensional **separation** of the **Validator** role, implemented at protocol level: * **Horizontal separation**: unbundling the Validator role between Operator and Delegator. In practice, the separation, as first dimension of eODS, can be done by requesting node Operators to conduct self-accountability, i.e. protocol requests staking pools and delegated solo stakers to maintain a delegators balance sheet in a pre-defined, protocol legible format, that can be parsed in protocol, the same way deposit contract events data is being parsed today, in order to build a virtual Balance of delegated ETH in the Beacon state. The operators would be requested to declare that ETH delegation registry to the protocol and reference it when performing validator duties for the staking pools / capital delegators, so that the protocol is able to construct and disambiguate between message and delegator stake message. * **Vertical separation**: a further separation of each Validator roles resulted from the horizontal dimension of the separation (Operators & Delegators), between Heavy protocol services providers and Light protocol services providers, based on the [Two-tier staking approach to SSF](https://epf.wiki/#/wiki/research/eODS?id=the-two-tier-staking-approach-to-ssf). The difference between Heavy and Light, services comes from the capital requirements set upon the protocol services providers. In practice the separation between heavy services providers and light services providers can be done in-protocol, after increasing the MAX_EFFECTIVE_BALANCE (EIP-7251), by implementing a balance threshold (e.g. 2048 ETH) to determine which existing validators enter which complexity tier and use the threshold subsequently for attributing the appropriate tier to new depositors (Operators). The following protocol structure emerges: | eODS | | | | -------------- | --------------- | ------------- | | Light OPERATOR | Light DELEGATOR | non-slashable | | Heavy OPERATOR | Heavy DELEGATOR | slashable | ## Main protocol improvements eODS brings, relatively to the previously presented challenges: One important aspect I want to underline is that **eODS does not need SSF, but enables protocol improvements towards Single Slot Finality.** ### Improved protocol credibility Ethereum Protocol's credibility comes from the power it has over the Validators that execute the protocol. But it can only control what it sees, and it can't see ETH delegations. Extending these limits allows for the protocol to have the capacity to react with automated defense systems, in the context of ETH staking. Enshrining a way for the protocol to distinguish between Operators and Delegators would improve staking UX in general, by clearly mapping [Principal-Agent relationships]() at protocol level. ### Incentivized Delegator role Under eODS, Delegators are incentivized to have a [meaningful role](https://epf.wiki/#/wiki/research/eODS?id=the-role-of-delegators) and actively participate in Consensus: * The curation of operator set: opinionated delegators may decide to choose between different operators based on e.g., fees or reliability. * The provision of light services: 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. Delegators under this model do not contribute to the economic security of FFG, i.e. Delegators do not partake in Finality (non-slashable stake), but they would have the option to take on a role which would be “lighter” than full staking and [not subject to long withdrawal periods and slashing risk](https://notes.ethereum.org/@vbuterin/staking_2023_10#If-delegators-can-have-a-meaningful-role-what-might-that-role-be), but would still function as a check on node operators. Their services can be compensated by re-allocated aggregated issuance. ### Solo-stakers friendly staking design Solo stakers embody 2 very important core value propositions under eODS: * Bolster network resilience: Solo stakers bolster the resilience of the network to failures of larger operators, e.g. by progressing the (dynamically available) chain while large operators go offline. It would not be their main line of operations due to capital and cost-efficiency limitations, but it could be a strong fallback in the worst case scenario. * Generators of preference entropy: Solo stakers may contribute as censorship-resistance agents, allowing the protocol to see more and serve a wider spectrum of users. Performing such a light service is at hand for a wide class of low-powered participants. Multiplicity gadgets could reward the contributions of operators who increase [preference entropy](https://ethresear.ch/t/unbundling-staking-towards-rainbow-staking/18683#staking-economics-in-the-rainbow-world-6). ### Improved decentralization of staking pools 2D-eODS is a mix between Approach 1 and 2 presented in the [Sticking to 8192 signatures per slot post SSF](https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989) research post: * A Heavy layer, liquefied as it is today, all in on decentralized staking pools with help from enshrined protocol gadgets (e.g., LSM-type enshrined gadgets); * A solo-staker-friendly Light layer as the second-tier, with its own Light LSTs. And since ETH staked as provision of Light services is non-slashable, the LLSTs (LightLSTs) would be mostly risk-free and could be used as pristine collateral type in app layer protocols, e.g. a version of the governance-minimized, ungoverned RAI stablecoin that accepts staked ETH. >[...] *The purpose of this [-ed. sticking to 8192 signatures per slot post SSF] is to support decentralization, allowing even regular individuals to participate in staking, without requiring everyone to give up their agency and cede control to one of a small number of staking pools.*- Vitalik Buterin ### One step forward towards Single Slot Finality AND increasing validator count A daunting aspect about building towards SSF is the need to drastically reduce the validator set size (measured in *individual message signers*, not in *stake weight*), while encouraging an ever increasing validators count, for the scope of overall increased resilience(a broader range of proposers, a wider array of attesters, whistle-blowers and censorship-resistance agents). These seemingly conflictual goals can be resolved by the realization that: >We need to move away from the concept that every participant signs in every slot - Vitalik Buterin In the SSF context, we can assume a limit of 1.8 million$ BLS signatures that could be processed every slot. eODS proposes the reduction of the Validators count, as Finality participants(Heavy services providers) to ~10,000, reducing the number of BLS signatures that need to be processed every slot, even assuming the two-round consensus protocol SSF would inevitably use, thus significantly reducing consensus node overhead. The Light layer participants would be encouraged to participate in as many numbers as possible. The number of heavy tier participants is constrained by the efficiency of cryptographic constructions (aggregating signatures), but as cryptographic methods or simply hardware progress, the number of "seats" may increase. ### Unlocks side infrastructure, e.g. Light clients Implementing eODS would make it much more easier for anyone to run a consensus client, and also would make light clients safer, as they would be able to verify the full set of signatures and not rely on sync committees anymore. This would send the proper signal to developers, builders and Ethereum enthusiasts to further develop side infrastructure. ### Unlocks the possibility to design a "plug & play" interface for future Protocol Services integration. The vertical separation unlocks the introduction of two distinct types of future protocol services, each tier inducing within itself a market structure of delegators and operators: * Heavy Services * Light Services I'm referencing here a slide [Barnabé Monnot](https://github.com/barnabemonnot) used for his [EPS week8-Research presentation](https://epf.wiki/#/eps/week8-research), picturing future - validator provided - Light & Heavy protocol services: ![Future Validator services](https://hackmd.io/_uploads/SylCaqvX0.png) Validator economics is one of the [3 key riddles](https://notes.ethereum.org/@vbuterin/single_slot_finality#What-are-the-key-questions-we-need-to-solve-to-implement-single-slot-finality) we need to solve to implement SSF, so finding out the proper MVI for both the heavy and the light tier would be a key factor for the proper implementation of eODS. More information on [Economics of heavy services](https://epf.wiki/#/wiki/research/eODS?id=economics-of-heavy-services) and the [Economics of light services](https://epf.wiki/#/wiki/research/eODS?id=economics-of-light-services) can be found in the EPS.wiki eODS page. ## Week1 TODOs Next week, I plan to: - finalize the slides for the EPF project proposal presentation - include the motivation from week0 in the presentation and the project proposal - submit project proposal and EPF application :clap: