# EPF weeks 17 and 18

The main focus of these weeks has been concentrated into the architecture side of porting eODS into Lean.

### Challenges
The eODS codebase is quite large, sitting at 2.5k lines of code.
When we wrote eODS we wanted to build a simple to understand system. We wanted it to be fast, and most importantly maybe, to be unobtrusive with the existing code.

To avoid messing too much with the existing code - here mainly the consensus layer specs - we did a couple of things:

#### 1. We defined all the intersection points between eODS and CL.
As an example, an intersection point would be the place in the code where slashing is applied to a validator. eODS needs to intersect in that point with the CL specs, because eODS needs the slashing feature also.

#### 2. We wrapped as much as we could
Instead of aggresively modifying existing entities, we created new ones that wrapped them, for example the DelegatedValidator.

The fact that Lean is in very early stages is both a blessing and a curse. There are very little things on top of which Rainbow Staking and Delegation can be implemented. But there are no legacy hard-to-change containers.

If one thing is clear, eODS can't be just 'ported' on top of Lean. Not with its 2.5k lines of code and not with all the legacy that it would bring into the new chain.

### Solutions
### Simplify
#### Attester only
The Validator will be renamed to Staker, and the Staker will have certain roles. After taking part in some discussion in Cambridge on this topic, the consensus was to only have Delegations for the Attester role. At least for now. Otherwise there are some tokenomic-wise implications that are beyond my understanding at this point.

So Delegation will only be possible, in the beginning, for the Attester role.

#### Delegate the whole role
eODS allowed partial delegations. From a given balance, multiple fractionary delegations were possible. This changes now to delegating the whole role (entire balance) towards one single Operator. We don't need to keep quotas anymore, at least not for the first phases.

#### Work in phases
Lean is designed to be implemented, tested in multiple phases. The Rainbow Staking Delegation will follow those phases also. This means that in the first few phases there will be no rewards/penalties/slashings, just the barebones delegation.

### No more wrapping
One of the first architectural gotchas was the fact that we don't need to wrap anything anymore, we can design the entities as first class citizens. The DelegatedValidator was augumenting the Validator with fields related to quotas and delegated amounts. We don't need those fields anymore, because of the "Delegate the whole role" change.

There will still be some quotas to calculate, but at the Operator level. The Operator WILL be able to receive multiple (whole) delegations, increasing its weight.

### Simple interaction
I [proposed](https://hackmd.io/C7Y0uegiT8GZ18PPFTNyHA#Define-an-iterface-that-can-be-used-for-interacting-with-the-stakers-settings) an interface used to interact with the protocol.

The eODS iteration of this communication was a special contract with multiple switches, based on the action desired. Now that morphed into sending a configuration matrix, and having the protocol calculate the deltas and apply them accordingly.

By doing this we can give the app builders more flexibility towards building a nice UX around delegations.

The [Staker Matrix](https://hackmd.io/5Qilm6BgQFmyDux6Gy_ICw#242-Stakers-matrix) has been described here, no need for me to repeat that information.

### The accounting
The only real large piece of code will be the accounting module of these delegations. That will be part of the rainbow staking submodule, and handle eventually all the delegations, undelegations, exits, rewards penalties and slashings.