The past three weeks have been dedicated to the following topics

• Implementing feedback from block v3 endpoint review
• Adding Block v3 endpoint to the Lighthouse validator client
• Sqlite slasher db improvements
• Adding tracing examples in rust-libp2p

Feedback from Block v3 endpoint review

We found some additional opportunities to refactor and delete some code. I had combined most of the v2 and v3 logic into one "flow", however the code branched out at certain places to handle the different endpoint versions. We found a way to combine these branches into one fully coherent flow, and were able to delete around 400+ lines of code in the process. The refactor here mostly involved playing with types and adding a conversion from a full payload to a blinded payload.

Adding Block V3 endpoint to the Lighthouse Validator Client

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

Currently the Lighthouse validator client uses the block v2 endpoint to produce blocks. Once the deneb fork occurs, VCs should migrate from using the v2 endpoint to v3. Migrating from v2 to v3 on the users end will require an upgrade to both the users beacon node and validator client. This means we need to come up with a sensible upgrade strategy.

We should:

• Ship this upgrade to the validator client alongside the Block v3 update to the beacon node
• Handle the situation where a user is running an upgraded VC with a non upgraded BN (some users may be using a different consensus client alongside a Lighthouse VC)
  • Pre deneb we should have some type of flag that allows users to disable the block v3 endpoint logic in the VC
  • Post deneb all consensus clients should have the block v3 endpoint implemented. the new config were introducing should no longer be relevant post deneb

My PR introduces a new config value produce-block-v3 that when set, will use the new block v3 endpoint in the VC. This config value is only relevant pre deneb, post deneb the VC will always use the v3 endpoint

The VC also contains some logic that decides wether to try to fetch a blinded payload or a full payload. This logic is now handled downstream inside the block v3 endpoint itself, so I also found an opportunity to remove some logic from the VC itself.

Sqlite slasher db improvements

Initially I was able to get batch times down to around 50 seconds by altering two pragma values:
journal_mode: wal and synchronous: NORMAL (https://www.sqlite.org/pragma.html)

Updated metrics:
https://snapshots.raintank.io/dashboard/snapshot/GJ1PseLyV5RLTDcvoJuSx93jruw6Vsc3

My most recent changes have gotten batch times down to around 23 seconds

https://snapshots.raintank.io/dashboard/snapshot/hIwPCJmC26Yjg2REEAdb0ueJFPpyNz22

These changes include

• Removing the ID primary key
• using prepare_cached which prepares a SQL statement for execution, returning a previously prepared statement from the cache if one is available.
• Updating locking_mode pragma to EXCLUSIVE
• Updating cache_size pragma to 10000
• There may still be some optimizations to be made in delete_while, though I'm not sure that will get us down to sub 5 second batch times

Adding tracing examples in rust-libp2p