# Ethereum Protocol Fellowship Week 5 and 6

Most of week 5 and 6 have been dedicated to the following issues

- Block v3 endpoint
- Handling genesis files in lighthouse
- Sqlite impl in slasher backend
- Begin modularizing beacon node backend

## Block v3 endpoint

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

Up until this point, i've sort of just "cloned" the existing block fetching flow and added the ability to return either a full or blinded payload. I've added several enums and structs to make this possible.

Note that there is some additional refactoring/consolidation that needs to happen here. Theres some code on both the old flow and new flow that can be extracted and shared between the two. The code at this point can be viewed as a starting point for some additional refactoring.

It's also important to mention that the old flow is technically deprecated post deneb fork. So a lot of the refactoring here may technically be a waste of time? I guess it depends how the Lighthouse team/Ethereum foundation treats deprecated code. If we expect the old block fetching flow to exist forever, then maybe its worth it to put significant effort here into really cleaning this up.

## Handling genesis files in Lighthouse

As mentioned in previous updates, a good chunk of Lighthouse binary size can be attributed to the genesis files of several testnets. Theres been a significant amount of back and forth discussion over how exactly to handle genesis files. We came to the conclusion that all testnet genesis files should be fetched via a remote url, while mainnet should still be included in the binary (due to security reasons).

I had done some initial work on this issue here: https://github.com/sigp/lighthouse/pull/4644

However offline there was some back and forth discussion within the Lighthouse team on how to handle th holesky genesis file specifically. Because of time constraints, the Sigma Prime team decided to quickly add holesky to the list olf supported Lighthouse testnets. The optimization work will now be based off of changes made in this branch:

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

## Sqlite impl in the slasher backend

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

This PR addes a relational database as one of the available databse implementations to the slasher backend. The datbase schema I chose is

CREATE TABLE {} (
    id    INTEGER PRIMARY KEY AUTOINCREMENT,
    key   BLOB UNIQUE,
    value BLOB
);

- the ID is also used as a cursor to track the current value, next value etc.
- I believe the key unique constraint is required. The put function does a INSERT OR REPLACE to replace value if key already exists.
- I was able to get all slasher backend tests to pass

## Modularizing the beacon node backend

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

I have begun the initial work of modularizing the beacon node backend as part of my project proposal. The initial goal is to abstract over the current LevelDB implementation. Once that work is done, I can begin the work of adding another database implementation.

## Lighthouse v4.4.0

The upcoming Lighthouse v4.4.0 release is slated for end of August/early September. I have several features that will be included in this release:

- [Expected Withdrawals endpoint](https://github.com/sigp/lighthouse/pull/4390)
- [Improve transport connection errors](https://github.com/sigp/lighthouse/pull/4540)
- [Support SSZ for POST blinded block v1 and v2 endpoints](https://github.com/sigp/lighthouse/pull/4504)
- [Support SSZ for POST beacon block v1 and v2 endpoints](https://github.com/sigp/lighthouse/pull/4479)

I am very excited to see the features I've worked on make it into the upcoming Lighthouse release!!