# DanGoron: Week 12-13 dev-update

## eODS Prototyping

Here are the [eODS Design notes](https://hackmd.io/@kboomro/r1csps2MR).

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 sheets**

Balance sheets are built as described in the prerequisite reading of my [previous dev-update](https://hackmd.io/@kboomro/B1v6pvvjC), based on assets and liabilities, and the operations that manage them.

- minimal **Design constraints**

For 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).

- OPERATIONS consist of ASSET transfers and RECEIPTs minting

- RECEIPTs are minted when ASSETS get transferred inter-parties.

- PROOFs are minted to ensure the Accountability of certain events and actions (e.g. Deposits or Delegations, and others)

- BALANCE SHEETS track OPERATIONS that function based on the Conditioned inter-partes relations. ASSETs, PROOFs and RECEIPTs are passed either as asset or as liability on one entity's balance sheet.

- **Conditioned *inter-partes* relations**

Depositor $<->$ Validator (current deposit process)

Depositor $<->$ Delegator (the proposed deposit process in delegated PoS)

Delegator $<->$ Operator (the proposed delegation process in delegated PoS, of a Delegator backing-up an Operator with the intent to fund a validator and participate in FFG)

Delegator $<->$ light Operator (the proposed delegation process in delegated PoS, of a Delegator backing-up a light Operator with the intent to fund a light validator and participate in AVS)

### Week 13

Based on the research of the last weeks, and after the [EPF5 Office hours #11](https://www.youtube.com/watch?v=NVKD7hDZ6AI) with Alex Stokes, I identified the Non-Finality Validator attributes in Consensus as current, remunerated attributes that could be removed from the Validator actions set and added to light Validator actions set.

These are:
- Sync-committee
- FOCIL
- Whistleblower

Having this part done now will help me in the second part of the project: **Research Delegator role selection & incentivization (Week 17 - Week 21)**

### Week 14, 15 planning
Starting next week, my project enters the second phase of Part 1: **Write case studies, and prototype the APIs of eODS defined protocol objects (Week 14 - Week 17).**

#### 1. Open issues from prior weeks

- [ ] New DELEGATION_CONTRACT - this point is going to be left for the post-EPF part of the project, in the eODS specs PR
- [ ] Delegator triggered `0x01` withdrawals - this point is going to be covered in the case studies phase
- [ ] Increase readability of the Class diagram (add LEGEND, detailing) - this point is going to be covered in the case studies phase, I plan to break the rather big diagram into smaller, more legible diagrams, that will most likely allow readers to grasp the concept better.

#### 2. Start writing the case studies

Case studies
- [x] New self-funded heavy operator - this case study is straightforward, as it depicts the current Deposit-Validator activation process, which eODS does not propose to be modified, as eODS is rather a parallel, opt-in functionality.
- [ ] New delegated heavy operator
- [ ] New Delegator, with the intent to delegate to heavy Operators and light Operators
- [ ] New delegated light operator

In the Design constraints chapter of the [design notes](https://hackmd.io/@kboomro/r1csps2MR), I defined the **Conditioned relations** between eODS proposed protocol entities. Writing the case studies will allow me to better represent how the APIs of each of these protocol objects get activated and interact with each other.