EPF Dev Update #3

This week's update came a bit late, as I've finally made it back to Australia and have been busy with settling back into life here with family.

My area of focus in the last week:

• Learning Rust
• Exploring Lighthouse's EF Consensus Spec Tests
• Adding Lighthouse to the eip4844-interop repo
• Preparing project proposal

My Rust Journey

Contents moved to this page

Running EF Consensus Tests on Lighthouse

Gabi and I recently reached out to the Lighthouse team and expressed our interest in contributing to Lighthouse's EIP-4844 implementation. Paul from Lighthouse was very kind to introduce us to the main contributors in his team and openly explain their work and approach to us. The overview was super helpful and we now understand the missing peices and areas that may need help. Sean has listed the outstanding tasks required to join the next devnet in this issue.

With Sean focusing on the consensus part, and Pawan working on KZG crypto integration, We could possibly look into the tests - consensus spec tests and/or local testnet, which would help us understand how the client works.

The consensus spec tests are tests that execute and consume test vectors hosted on EF's consensus-spec-tests repository. These tests are executed as part of every CI build and help verify that Lighthouse behaves the same way as defined in the consensus spec. With large amount of progress already being made in the eip4844 branch, it would be very useful to run these tests against the latest consensus spec (and potentially the devnet v3 spec) before we start interop testing with other clients on devnet v3.

The code for the consensus spec tests are here, and the tests can be executed by running the following:

# Downloads and runs the EF test vectors.
make test-ef

# Or, if specs are already downloaded, this only runs the tests:
make run-ef-tests`

I was able to run tests locally. Although I had to replace wget with curl to make it run on MacOS):

The next step for me was to look into the issues with fake_crypto tests and running the tests against the latest v1.3.0-alpha.0 release. Then I realised @michaelsproul recently made some fixes to make EF capella tests to pass on the branch, so it looks like we're on track! I'm now just getting my head around the changes and see if there's anything I can help in this area.

Adding Lighthouse to eip4844-interop

In my last update, I mentioned that I created a draft PR to add Lighthouse to the eip4844-interop repo. There are still a few outstanding tasks listed here before Lighthouse is ready for interop testing. My original goal was to get this PR to a stage where it passes the pre-4844 tests, so that we can start interop testing once the Lighthouse implementation is ready.

Then I ran into some issues and have been working through it with @Inphi. The investigation and conversation can be found on the PR. Currently the peers get disconnected after a few slots. @Inphi discovered that the Lighthouse node's SLOTS_PER_EPOCH is not the same as the Prysm node. Both nodes uses a shared beacon config file, which uses the mainnet preset (default), however the config overrides the SLOTS_PER_EPOCH to 3 (this is 32 in the mainnet preset). It appeared that Prysm accepts the override and has SLOTS_PER_EPOCH = 3, however Lighthouse ignores the value and uses the mainnet preset value of 32. It appears that Lighthouse ignores overrides in config file, so we may have to either use the minimal preset or create a new preset in Lighthouse.

I'll continue investigating when I have a chance, and hopefully we can get this in for devnet v3 🤞

Project Proposal

So, I'm still a bit behind on this due to travels and also not being able to find a suitable candidate related to what I have been investigating (EIP-4844 Lighthouse implementation). There are some small task that I could potentially work on but doesn't really fits the project format & duration. I still hope to contribute as much as I can to scaling Ethereum in the next 3 months (hopefuly more!). I'm planning to discuss with mentors from Lighthouse and at the same time continue to brainstorm on ideas.

I'm also quite interested in the Builder API for blobs - I will spend some time looking into some materials and past discussions on this as well.

Other Stuff

Mario recently initiated a "Stakers Testnet" initiative - to address the Goerli supply issue, and has a good write up here on proposals. With some past experience running staking infrastructure and rolling out our own solution, I naturally got interested in the conversation and started particpating as well.

I suggested a possible solution here. We could potentially add a dedicated profile (e.g. stakers-testnet or ephermal-testnet, which has a network config that gets updated every time the community wants to "reset" the network (possibly just a small network ID bump). The upside is that it requires no logic change in client code, and little change in config file (by cleint teams). This means we avoid implementing custom logic that are not expected to happen in a real network. With enough automation from infrastructure providers (explorers, faucets etc), the overhead could be kept to a minimum.

Potential downside I see with this approach is validators running older versions of the clients would stay on the old testnet until it dies, and updating the client version would force them to join the new testnet - in other words, it's not possible to do multi version interop on this testnet. There are also concerns about network stability of this approach.

There are some other proposals from the group as well, and there are currently some PoCs being carried out. It's great to see the community coming together to solve this long standing problem. Kudos to Mario for leading this initiative

Meeting notes from this week

Link here