# EPF Week 4 Update

## Lodestar progress
I managed to further explore the code and made some notes about the architecture. I also spent some time looking at the issues in the github repo, and trying to make a plan on how I want to tackle this. The idea is to get familiar **fast** with the basecode, so before taking ant big tasks I could maybe handle some bugfixing. I will decide this with the team.

## eODS
This was again my main focus, and this week marks the end of the bulk work, research, bugfixing and testing of the specs. I will move more and more towards writing the tests and planning a Lodestar POC.

This week was very busy because withdrawing funds from an undelegated amount account to a wallet was more work than initially planned. Kind of taken me by surprise.

The point of pain was moving the requested amount back to EL, from CL. To better understand the system as it is now, I've:
1. Again looked at the entire withdrawal process from CL.
2. Dived into some EIP's that were relevant to the topic, namely:
- [EIP-4895 Beacon chain push withdrawals as operations](https://eips.ethereum.org/EIPS/eip-4895)
- [EIP-3675 Upgrade consensus to Proof-of-Stake](https://eips.ethereum.org/EIPS/eip-3675)

### Withdraw from delegator
Withdraw from delegator means: I want to take an amount from the UNDELEGATED account in CL and move it to a wallet in EL.

### How will this work in eODS
eODS will modify the execution payload, adding a new withdrawal type. There withdrawals will be applied during the state transition function.

Let's walk through a simplified flow:

1. Multiple withdraw from delegator requests are queued in the state. These are requests triggered by the Delegation Operations Contract and ended up in CL. We can't process them all so we created a special queue from where we dequeue what we can process.
2. Whenever a proposer starts building a block, it will read some of those requests, and append a list of `WithdrawalFromDelegator` in the PayloadAttributes of forkchoiceUpdated.
3. During the state transition function, each `WithdrawalFromDelegator` is processed, we remove the coresponding request from the queue, and settle the amounts as requested.

`WithdrawalFromDelegator` follows closely the `Withdrawal` and it looks like this:

class WithdrawalFromDelegate(Container):
    index: WithdrawalIndex
    delegator_index: DelegatorIndex
    address: ExecutionAddress
    amount: Gwei

Things to note:

The amount of `WithdrawalFromDelegate` sent to EL via the payload attributes is capped by `MAX_PENDING_WITHDRAWALS_FROM_DELEGATOR_PER_PAYLOAD` currently set to 16, so that we avoid adding any substantial overhead to the payload.

This list is compiled by `get_expected_withdrawals_from_delegate`, and it will be called both by a proposer via `prepare_execution_payload` and by `process_withdrawals_from_delegators` which is a method that will actually update the amounts in the CL, during state transition.

In a nutshell we followed closely the partial withdrawal process, but adapted it to the delegation scope.

## Dev post
I have planned to release a post about eODS written from a developer's point of view. There are a lot of things to explain, justify, or just simply draw attention to. We can't pollute the specs themselves with a ton of comments and research posts are not exactly the place for all this.

I want to put all this information into a post, that is basically an X-RAY of the proposed eODS. It will act as a TDD and will accompany the specs.

This post has proven to be a much-bigger-than-expected task, but progress is steady and I will get to the end of it eventually.