# EPF Week 3 Update

### Lodestar
This week I went ahead and cloned and compiled the Lodestar client. I started exploring the docs, the various modules and the code.

### eODS
My main focus is still on eODS and delivering the specs, so a lot of time and work went into this.

Notably, this week I went again through slashing - the slashing that occurs already in the consensus layer - and made sure we have a proper solution for slashing delegations also.

One important feedback we got regarding eODS was the need to take into consideration the topic of weak subjectivity. This meant we had to hold the delegated amounts accountable for the operator's actions for longer than we initially planned.

### Undelegate
*Undelegatge* is the action of removing a delegated amount of Gwei from a DelegatedValidator. Two things happen here:
- The DelegatedValidator looses that amount (and the weight associated with it)
- The delegator receives that amount into its undelegated balance account

Because Weak Subjectivity is a serious concern, we can't execute the actions above in a fast succesion. We need to introduce N Epochs of wait before the amount becomes undelegated, and an extra M Epochs (in which that amount is slashable) before that amount gets moved into the undelegated balance of the delegator - and is no longer held accountable.

Let's try to visualize this:


We created a container called `UndelegationExit`. This represents a request for an undelegation. When a delegator wants to undelegate an amount, a new UndelegationExit is created and queued.

To prevent WS attacks, we store the `exit_epoch` (when the amount actually leaves the DelegatedValidator) and the `withdrawability_epoch` (when the funds can be released). If the current epoch is between `exit_epoch` and `withdrawability_epoch` the `amount` is **slashable**. How these epochs are computed is beyond the scope of this post.

Let's assume we have 4 undelegation requests queued. They are from the same delegator (execution address `11111`). The validator with pubkey `abcd` has just been slashed. That validator has some delegations, and 2 UndelegationExits queued.

This is how we will slash them:
1. Slash the exit queue:
- identify all the UndelegationExits that belong to this validator
- check if they are between `exit` and `withdrawability` epochs
- compute the slashing amount needed - this is based on the quota this delegation had in the DelegatedValidator, when `exit_epoch` hit. Slash the matching elements accordingly
2. Slash the Validator and the current delegated amounts
- from the total slash amount we subtract how much it was slashed in the exit queue, and divide the rest between the Validator and the current delegations, based on a quota system not explained here.

The main focus of the week was making sure that every amount that contributes to the financial security of the protocol is also held accountable until needed. This complicates a bit the flow of undelegations but increases the security of the operation.