Table of contents

• SSZ block proposal flow in lighthouse
• Improve transport connection errors
• Lighthouse Slasher DB
• Looking at libp2p
• Learning networking

SSZ block proposal flow in lighthouse

According to benchmarks related to encoding and decoding of signed-blinded-beacon-block payloads with SSZ vs JSON

SSZ seems 40-50x faster
Considering 20-40ms per coding on average, that's up to 200-300ms JSON latency (or more).

Sending the data SSZ encoded could reliably shave 200-250ms off each getPayload roundtrip.

Recently I've worked to support SSZ request bodies in lighthouse in POST beacon/blocks and POST beacon/blinded_blocks endpoints via the PRs below:

• Support SSZ request body for POST /beacon/blinded_blocks endpoints (v1 & v2)
• add ssz support in request body for /beacon/blocks endpoints (v1 & v2)

To support the block proposal flow using SSZ end-to-end, I have added SSZ support to the following block production endpoints:

• GET /eth/v2/validator/blocks/{slot}
• GET /eth/v1/validator/blinded_blocks/{slot}

via this PR Add SSZ support to validator block production endpoints

Per the benchmarks this should be a nice optimization for the block proposal flow.

There is also a related issue to using SSZ in builder API queries: #3701

If/when that is ready to be worked on I will most likely pick that issue up next.

Lighthouse Slasher DB

See my notes here for updates on implementing redb to the slasher backend in Lighthouse

https://hackmd.io/Nb-Y4cq2SkOTlPu5RO8kSw

Improve transport connection errors

Libp2p spits out std::io Errors that are hard to read. The goal is to try and grab useful information of the wrapped errors and print them in a consumable way. The main errors to focus on are transport errors that occur often when attempting to connect to peers.

Example error message:

Transport([("/ip4/x.x.x.x/tcp/9000/p2p/16Uiu2HAm414GH2X4sLtWyRujBak6euCdZiWfbjCRnpLyk4L4Hw6i", Other(Custom { kind: Other, error: Custom { kind: Other, error: Other(Left(Right(Select(ProtocolError(IoError(Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" })))))) } }))])

See this issue for more details

In order to make these error messages more readable I created a newwrapper type around the DialError and added some custom logic to handle each error variation. See this PR for more details

Looking at libp2p

My work on improving transport connection errors in Lighthouse led me to start looking at libp2p. Libp2p is the peer to peer networking stack that is used by Lighthouse (and other Ethereum consensus layer clients).

Heres a quick history of how/why libp2p was implemented in the ETH consesnsus layer: https://blog.libp2p.io/libp2p-and-ethereum/#how-libp2p-was-integrated-into-ethereum-🤝

I've recently become very interested in the peer to peer networking stack used within the Ethereum consesnsu layer. Therefore I thought it'd be interesting to start contributing to the Rust implementation of libp2p to gain a deeper understanding of libp2p. I believe by gaining more knowledge in this domain, I can be better prepared to make bigger/better contributions to the ethereum ecosystem.

This is the first issue I picked up: quic: ability to listen on ipv4 and v6

I will add more updates as I progress on this issue

Learning networking

Since I'm working on libp2p I thought it'd be a good opportunitiy to brush up on my networking skills. I added a non extensive TODO list below.

• First, understand the OSI. Memorize that bad boy, write lines if you have to. Test yourself later by pairing protocols with the OSI model ("Probably Didn't Need Those Stupid Packets, Anyway" is my favorite acronym)

• Understand how it can be used for troubleshooting (start at the bottom and work your way up. Is the cable plugged in is always a good first step)

• Learn how IPv4 addresses work (Public IPs, Private IPs, subnets, routing tables, NAT)

• Learn how MAC addresses work (ARP tables, switches, DHCP)

• Learn about routers

• Learn about switches

• Learn the difference between routers and switches (L2 vs L3 OSI)

• Learn about TCP and UDP (TCP = ALL the data will be received correctly, in order. UDP = All data will be sent, but it may not arrive, or it may arrive mangled, and that's OK)

• Learn a little about VLANs (TBH I need to brush up on these)

• Learn about DHCP (Static IPs vs Dynamic, IP reservations)

• Learn about DNS (A records, CNAME records, MX records, NS records, SRV records)

• Learn about IPv6 (Unfortunately, not extremely useful right now. Most companies are IPv4 only)

• Learn about VPNs (WireGuard is an excellent one to get started with, and will probably be the standard going forward. IPSec / OpenVPN if you want a challenge)

• Learn a bit how the "greater" internet works (BGP, carriers, IP blocks, IANA). You probably won't need to worry about these technologies / groups, but they're useful background knowledge