# Ethereum Protocol Fellowship Week 0
### Tuesday June 20th, 2023

Today I did some light reading. Just starting out!

### Wednesday June 21st, 2023

A few weeks back I submitted a PR for implementing the expected_withdrawals HTTP API in Lighthouse.

**Issue**
https://github.com/sigp/lighthouse/issues/4029

**PR**
https://github.com/sigp/lighthouse/pull/4390

**Spec**
https://github.com/ethereum/beacon-APIs/issues/301

**Helpful link for beacon API specs**
https://ethereum.github.io/beacon-APIs/

Today I received some feedback. I need to:
- [x] run clippy, make lint, and cargo fmt --all to fix some formatting issues
- [x] support ssz responses
- [x] add optional propsoal slot query param
- [x] fix chain.get_expected_withdrawals arguements. second arg should be `state.slot() + 1`
- [x] check if expected_withdrawals_invalid_state test requires `builder_threshold`. might be good enough to just use `ApiTesterConfig::default()?`

I will update the list above as I complete these tasks

**other notes:**
- run a specific test in lighthouse using this command `cargo test --release tests::expected_withdrawals_valid_capella -- --nocapture`

### Thursday June 22nd, 2023

I received an email last night from Mario and Josh to schedule an interview for the EPF cohort #4! Super excited to chat with them, I'm going to spend the next few days making sure I'm ready for the interview. I also want to make sure I write down some questions I have about the cohort so I dont forget to ask.

Today I continued work on implementing the requested changes for the expected_withdrawals HTTP endpoint in Lighthouse.

I'm working specificially on the SSZ seralization portion. I left the following question in the Eth R&D discord
>
> Hello, I have a question regarding the getNextWithdrawals spec
>
> https://github.com/ethereum/beacon-APIs/commit/8fc2729b555ac03250731923a63d424d49cb8445
>
> for the application/json response schema, we want to return a json object with the following properties
> ```
> {
> execution_optimistic: bool,
> finalized: bool,
> data: array of Withdrawals
> }
> ```
>
>
> that all makes sense to me. however for application/octet-stream response type, the response schema is definied as
>
> `SSZ serialized Withdrawals list. Use Accept header to choose this response type`
>
>
> Does that mean, only the withdrawals list is ssz serialized? `execution_optimistic` and `finalized` wouldnt be part of the serialized response?

Based on my discussions in Eth R&D it seems that it is the case that, when ssz serialization is specified, `execution_optimistic` and `finalized` are not part of the serialized response.

This allowed me to progress with implementing SSZ serialization for this endpoint. The plan is to now submit my PR for an additional review tomorrow.

### Friday June 23rd, 2023

I cleaned up some of the code I was working on yesterday related to the expected withdrawals http endpoint. I also removed some unecessary configurations I made in my integration tests, i.e.:

> check if expected_withdrawals_invalid_state test requires builder_threshold. might be good enough to just use ApiTesterConfig::default()?

I pushed up my changes, and pinged the lighthouse devs to inform them that my PR is ready. for another review.

### Monday June 26th, 2023

Did a bunch of work on starting up the redb implementation is the slasher backend. I actually teamed up with a potential fellow to begin work on this! Here is our PR

https://github.com/sigp/lighthouse/pull/4430

### Tuesday June 27th, 2023

I've added some notes here regarding the redb implementation

https://hackmd.io/6W9QPfw_TzyZT8nH6ub2dQ

I have some additional feedback regarding my PR for updating the Node health endpoint in Lighthouse to match the spec

PR: https://github.com/sigp/lighthouse/pull/4310

Issue: https://github.com/sigp/lighthouse/issues/4292

Spec: https://ethereum.github.io/beacon-APIs/#/Node/getHealth

I have some TODOs to work on:
- [x] linting fixes
- [x] ensure we dont lose previous `Sync::Stalled` behaviour

I ended up getting these fixes pushed up today for another review

### Wedsday June 28th, 2023

Continued brainstorming and making progress on the redb implementation for the slasher backend

I have some additional feedback regarding my PR for implementing the expected_withdrawals HTTP API in Lighthouse.

https://github.com/sigp/lighthouse/pull/4390

I have some TODOs to work on:
- [x] Add query after path param for better readability
- [x] Fix proposal slot calculation, should be something like `let proposal_slot = query.proposal_slot.unwrap_or(state.slot() + 1);`
- [x] Validate that the proposal_slot is greater than state.slot
- [x] Try to answer the question: I wonder how far ahead of the prestate we should allow proposal_slot?
- [x] use the max_seed_look_ahead to calculate a look ahead limit
- [x] We can safely ? the state_id.state as the "state not found" is handled in the function itself
- [x] chain.get_expected_withdrawals does not indicate that the state isn't a capella state. It seems like errors from this function indicates an expected condition and should probably return 500.
- [x] verify the withdrawals in the test case response
- [x] validate that proposal_slot is a slot after the capella fork
- [x] advance through the epochs and correctly call get_expected_withdrawals

One of the guys at lighthouse left the following comment on my PR

> I wonder how far ahead of the prestate we should allow proposal_slot to be - if user provides a far future slot, we should probably return an error rather than computing it - although I haven't seen any specific number in the spec.

Looking at the prysm implementation of this endpoint they calculated a look ahead limit using MaxSeedLookahead

`lookAheadLimit := uint64(params.BeaconConfig().SlotsPerEpoch.Mul(uint64(params.BeaconConfig().MaxSeedLookahead)))`

and then returned an error if `proposal slot >= state.slot + lookAheadlimit`

I'm going to add this as a TODO

### Thursday June 29, 2023

Two PRs were approved today for v4.3.0 of Lighthouse

PR: [Update Node Health Endpoint](https://github.com/sigp/lighthouse/pull/4310)

PR: [Added debouncing and metric counting to logs](https://github.com/sigp/lighthouse/pull/4269)

These are some of my biggest contributions to Lighthouse so far and I'm really excited that they will be part of v4.3.0.

I also completed the above TODOS for the expected withdrawls endpoint and pushed up my changes for another review. Hopefully this endpoint will also make it to v4.3.0

### Friday June 30, 2023

I recieved some more feedback regarding my PR for implementing the expected_withdrawals HTTP API in Lighthouse.

https://github.com/sigp/lighthouse/pull/4390

- [x] refactor & move api logic to separate file
- [x] remove the unwrap calls
- [x] use dedicated const for look ahead limit. set to two
- [x] more accurate error messages
- [x] proposal slot must be greater than state slot

I'm a bit disappointed in myself, I should have caught some of these fixes. I really want to reduce the amount of back and forth needed for future pull requests so that I don't waste the core Lighthouse teams time.

### Monday July 3, 2023

I implemented changes based on the feedback that was given to me on Friday. I am now waiting for another review

### Tuesday July 4, 2023

I spent a good chunk of the day writing up a test redb db implementation using some of the interfaces that exist in lighthouse. I have issues with some of the types being used in the interfaces vs the types that the redb implementation expects. For example, REDB keys must impleement the std::Borrow interface, but the existing interface doesnt implement that. Changing the existing interface will make things backwords incompatible, which is a bit of an issue

### Wednesday July 5, 2023

I investigated what it would take to work on the following issue: https://github.com/sigp/lighthouse/issues/4457

This enables SSZ requests in the post beacon block endpoints. I added some comments regarding how I think it would work, and I may pick this issue up soon.

### Thursday July 6, 2023

I started working on the following issue https://github.com/sigp/lighthouse/issues/4457

This will add SSZ support in the request body for beacon/blocks v1 and v2 endpoints. I broke up this feature into a few parts

- [ ] Create specific ssz beacon/blocks v1 and v2 route handlers
- [ ] add logic to existing http routing so that when application/octet-stream is provided in the Content-Type header, send to the new ssz route handler
- [ ] Write integration tests for the new ssz beacon/blocks v1 and v2 route handlers
- [ ] Ensure that existing beacon/blocks v1 and v2 routes are unaffected by the new ssz route handlers

### Friday July 7, 2023

I put together the new ssz route handlers, added the relevant logic to the existing http routing and began putting together some integration tests.

I'm having issues with de-decoding ssz `SignedBeaconBlock` encoded data in my integration tests. I'm getting an exception when Decoding the data. In the `SignedBeaconBlock` struct I added the Decode macro, which should allow me to decode appropriately formatted `SignedBeaconBlock` data. I also had to change the the ssz enum behavior from transparent to union on this struct because of the Decode macro I added. I have a feeling this is whats causing the issue

Just to add some more info here: changing the ssz enum behavior from transaparent to union causes other related integration tests to fail. I think I need to step back and rethink how im decoding ssz encoded `SignedBeaconBlock` data.

### Monday July 10, 2023

I spent Sunday and today continuing my work on adding SSZ support in the request body for beacon/blocks v1 and v2 endpoints. I was able to resolve the issues I was having decoding `SignedBeaconBlock` data

Initially I had added the Decode macro to the `SignedBeaconBlock` struct and attempted to decode the ssz data like so

let block = Decode::from_ssz_bytes(&block_bytes)?;

However this was throwing an exception. After some investigation, I realized there were existing functions to decode an SSZ encoded `SignedBeaconBlock`

let block = SignedBeaconBlock::<T::EthSpec>::from_ssz_bytes(
                &block_bytes, 
                &chain.spec
            )?

The fork name (provided in `chain.spec`) has an affect on how `SignedBeaconBlock` data should be ssz encoded/decoded.