Week 1 Dev update

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

Vitalik's Serenity (Phase 0) design rationale^[1] helped me understand the thinking behind the beacon chain specification^[2], the Validator life cycle and to formulate a high-level approach on how the class Delegators container can be added while introducing as few consensus-specs breaking changes as possible.

Delegating validators

I studied a closed (late) 2021 consensus-specs PR from @potuz,^[3] regarding delegating validators. Although never materialized, being obsoleted by the withdrawal upgrades, it's a good read on the possibility of in-protocol delegations.
The gist was that by adding new (delegation) fields in existing containers, validators can delegate excess winnings to other validators within the consensus layer, without involving the deposit contract.

p2p messaging in CL

I started diving into the consensus p2p-interface^[4] this week, to get a deeper understanding of how consensus participants gossip consensus payload using messages and topics.

SSF

As I mentioned in my week 0 update, one topic I find most interesting in R&D space, is staking economics in the context of Single Slot Finality. Working on the eODS writeup for epf.wiki, I realized that the vertical dimension of the Operator Delegator separation could have positive externalities for the SSF roadmap^[5], so this week I continued to study Fellowship alumni Lincoln Murr's development updates on his SSF-overview project of cohort-4. I'll continue with studying his MASTER OF SCIENCE paper^[6], and exchanging opinions with him about how splitting staking into a heavy & a light layer could help determining the right validator subsampling and validator economics in an SSF scenario.^[7]

Ethereum PM

I read Nyota ACD, and ethereum/pm issues, as I plan to get up to speed periodically on project management.

I joined the CL call #135 on Thursday, and noted the following:

• Tim Beiko's Review request for the PFI/CFI/SFI status of EIPs: EIP-7723.
  I left a comment, as I think these are good additions, that can bring more clarity in tracking the status of an EIP during the network upgrade process.

• Devs are called to vote for the F-star name for Consensus Layer upgrade after Electra. I voted for Fulu.

• SSZ update. EIP-7688 proposes transitioning consensus SSZ data structures to StableContainer^[8]. I plan to study StableContainer starting next week.

• PeerDAS is added to the list of Pectra EIPs in the Meta EIP.

• Electra devnet-1

  • specs release v1.5.0-alpha.3.
    I'm bound to following Electra specs releases, since the changes in my project will be based on Electra specs.

  • There was debate about introducing new fields in the middle of an existing Container, breaking merkleization of subsequent fields. I needed to deepen my knowledge in serialization so I'm leveraging epf.wiki pages on SSZ^[9] and merkleization^[10], and also the design rationale paper.^[1:1]

Timing Games in Proof of Stake consensus protocols

I thoroughly read during week 1 the Time is Money: Strategic Timing Games in Proof-of-Stake Protocols research paper on Timing Games^[11].
It's the first formal analysis of this relatively new concept in Ethereum, one that will have implications in the way PBS gets implemented and in the Attester Proposer Separation research space.
For the scope of Operator Delegator Separation, and in the context of Timing Games, I will try to find out during my project's research part if there could exist a Nash equilibria, involving Validators and Light service providers^[12] (Delegators or Solo stakers) as preference entropy generators? What would the equilibrium equations look like?

Week 2,3 planning

• Study Deposit contract
• I intend to contact staking pools to get an early sentiment on how the changes I might propose in the project would influence staking. I'll have a call with a permissionless stakin protocol, e.g. Geode or Stakewise
• I intend to write the Timing Games epf.wiki page during next week
• More SSF studies
• Study EIP-7495: SSZ StableContainer^[13]

Resources for week 1

---

1. https://notes.ethereum.org/@vbuterin/serenity_design_rationale ↩︎ ↩︎

2. https://github.com/ethereum/consensus-specs ↩︎

3. https://github.com/ethereum/consensus-specs/pull/2763 ↩︎

4. https://github.com/ethereum/consensus-specs/blob/2360756c8c19c0f7b0e91135f5bbcddecdf0a835/specs/phase0/p2p-interface.md#topics-and-messages ↩︎

5. https://epf.wiki/#/wiki/research/eODS?id=the-two-tier-staking-approach-to-ssf ↩︎

6. https://ir.vanderbilt.edu/bitstream/handle/1803/18820/MURR-THESIS-2024.pdf?sequence=1&isAllowed=y ↩︎

7. https://notes.ethereum.org/@vbuterin/single_slot_finality#What-are-the-key-questions-we-need-to-solve-to-implement-single-slot-finality ↩︎

8. https://eips.ethereum.org/EIPS/eip-7688 ↩︎

9. https://epf.wiki/#/wiki/CL/SSZ ↩︎

10. https://epf.wiki/#/wiki/CL/merkleization ↩︎

11. https://arxiv.org/pdf/2305.09032 ↩︎

12. https://epf.wiki/#/wiki/research/eODS?id=delegators-role-under-eods ↩︎

13. https://eips.ethereum.org/EIPS/eip-7495 ↩︎