DanGoron: Week 10-11 dev-update

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

eODS Prototyping

I synthtized the conceptual design I worked on up to this point in a HackMD note containing the feature's design notes.

A summary:

• 1. The current status of delegations
  Prerequisite reading

  • Semantics of Staking 1: Liquefaction, [archived]
  • Semantics of Staking 2: Re-staking, [archived]
  • Semantics of Staking 3: Advanced Constructions, [archived]

  The series analizes the off-protocol and in-protocol mechanisms and constructions of staking, re-staking, liquid staking, node operators, capital providers, and others, starting from the protocol’s own staking mechanism.

• 2. The main players under eODS

  • Delegator
  • Operator

  Operators run:

  • heavy Validators (or Validators - for simplicity) participating in FFG
  • light Validators participating in non-Finality (light) Protocol services

• 3. Minimum set of requirements for eODS design

  • New DELEGATION_CONTRACT
  • New entity in beacon state: Delegators as a new class
  • Mapping in-protocol Principal-Agent relationship by using balance sheets of assets and liabilities between parties
  • Delegator triggered 0x01 withdrawals.
  • Define actions set/ attributes for delegators

• 4. Minimum viable design constraints

  • Terminology
    • DELEGATION_CONTRACT
    • ASSET
      • ETH
      • PRINCIPAL
      • SHARE
    • RECEIPT
  • Balance sheets
    • ASSET transfer
    • RECEIPT minting
  • Predefined conditional relations (API). This section defines how the APIs of each protocol object under eODS gets activated and interact with each other.

• 5. What eODS is NOT

• 6. Workflow diagram

  • Increase readibility (add LEGEND, detailing)

• 7. Case studies

  • New self-funded heavy operator
  • New delegated heavy operator
  • New Delegator, with the intent to delegate to heavy Operators and light Operators
  • New delegated ligh operator

Week 12 and 13 planning

• Continue with eODS prototyping, close the open topics

Post week 13 planning

• Move on to API design and case studies (Week 14-17)