Ethereum Protocol Fellowship Week 9-10

Over the last few weeks I've started to reach the later stages of some of my big projects.

• Redb slasher db implementation
• Sqlite slasher db implementation
• Tracing in libp2p
• Block v3 endpoint
• Lighthouse v4.5.0

Redb Slasher db implementation

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

Metrics for the redb slasher db implementation: https://snapshots.raintank.io/dashboard/snapshot/Gm2SFg6pKT3iqTyvj1oRt2HY4cP5E17A

Batch times are between 4-5 seconds. Batch times for LMDB are roughly 2 seconds, so redb is a bit slower. But its still in the same performance range, and since the slasher doesnt need to be highly performant this seems to be a completely acceptable result.

I received some feedback from Michael Sproul (Lighthouse core dev) regarding my implementation and it should be ready to be merged in the next few days.

Sqlite Slasher db implementatiopn

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

Initial metrics for the sqlite implementation were very bad. Batch times were at roughly 18 minutes, which is a completely unacceptable timeframe.

One issue im seeing is that in the sqlite implementation I immediately write to the db each time put is called. commit actually doesnt do anything and is just a placeholder at the moment. I could try to instead append to a query string at each call to put and only commit to the db when commit is called.

Another issue could be my schema

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

I'm going to spend the next few days tweaking the sqlite implementation to see if I can make any improvements here. will also post the results for redb shortly

Tracing in Libp2p

PR: https://github.com/libp2p/rust-libp2p/pull/4282

Adding tracing in rust-libp2p has turned out to be a big undertaking. I've touched almost every file in the codebase and rececived some great feedback from the rust-libp2p team throughout this process. What turned out to be a small exploration into rust-libp2p has turned into what I feel is a meaningful contribution to the ecosystem. We've added structured logging across the full codebase in the hope that reading and understanding logs becomes easier for developers.

We're prepping to get this merged in the next major version launch. Theres a few small things I'm still working on

• small fixes/changes
• adding a simple example that shows how a developer can use tracing within rust-libp2p.
• explore additional followups to further improve logging in rust-libp2p

Im excited to see this land in the next major version of rust-libp2p!

Block v3 endpoint

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

Theres been an update to the deneb spec regarding the block v3 endpoint.

Spec change: https://github.com/ethereum/beacon-APIs/pull/358

To summarize the changes, we'll be adding the conesus payload value to the header of the block v3 response.

We'll look to accomplish this in Lighthouse reusing the code that computes rewards for the HTTP API, i.e. BeaconChain::compute_beacon_block_reward

I'm looking to get this ready for a review this week.

Lighthouse v4.5.0

Lighthouse v4.5.0 was released and it includes another PR of mine regarding SSZ block production flow. Now Lighthouse officially supports SSZ for the full block production/submission flow. Supporting the full SSZ block production flow was a multi phased project that I took up at the begining of the EPF cohort. Its exciting to see it fully deployed in production.