Introduction

This past week I focused on an adjacent issue about optimizing attestation signature decompression. Additionaly, Ankur Dubey and I wrote our project proposal and received feedback from Michael Sproul on it. Also I continued research on another area of interest of mine that I mentioned in my initial update, namely proposer builder separation.

Lazy Attestation Signature Decompression

The issue and PR which aims to resolve said issue can be found here:

Issue: https://github.com/sigp/lighthouse/issues/4398
Pull Request: https://github.com/sigp/lighthouse/pull/4567

This still needs to be tested to see if it's achieving the goal of reducing the CPU usage of decompression. The key idea is just to keep the data structure as sent over the wire until neccessary to avoid decompressing unnecessary attestation signatures. Hence, Lazy attestation signature decompression.

Following are the main changes:

• Added a filtering stage in process_gossip_aggregate_batch prior to batch_verify_aggregated_attestations_for_gossip call
• Added LazyAttestation, LazyAggregateAndProof, and LazySignedAggregateAndProof types
• Changed GossipAggregatePackage aggregate field to LazySignedAggregateAndProof
• Changed PubsubMessage::AggregateAndProofAttestation data to Box<LazySignedAggregateAndProof> instead of Box<SignedAggregateAndProof>

Project Proposal

As I said at the beginning Ankur and I wrote the project proposal during the week to formalize our plan for the project. This was our first time collaborating on a single document and it went really smoothly. So I'm excited continue forward with the project next week through testing the aggregation phase. But first I'll need to handle some logistical issues with my computer before I'll be able to run the tests.

https://github.com/eth-protocol-fellows/cohort-four/pull/159

Rambling about PBS

To me, this is the most interesting problem facing Ethereum. In my initial update I wrote that enshrined proposer separation seems like a necessary step to securing the core values of censorship resistance and decentralization in Ethereum. However, reading more on the topic I've become less convinced. One of the more interesting proposals with regards to PBS is that of Barnabe's Protocol Enforced Proposer Commitments PEPC. One of the main objectives that PEPC succeeds where most other PBS proposals fail is allowing the block proposer to engage in a more dynamic market for blockspace where the builder might only pay to have some particular transaction included at the top od the block and the rest would be sold off in some other way. In general PEPC proposes that proposer's can engage in arbitrary contracts with builders to split up the block space. This begins to approach some of the topics that have been at the forefront of the leading MEV research team in the Ethereum community, Flashbots. Where proposals like Payload-Timeliness Committee concede that the set of builders will be small due to computational and knowledge constraints, Flashbots and PEPC believe that the builder market can become more decentralized. Using the more complicated market model of PEPC, could lead to a larger set of 'builders'. I'm not so sure in this model they should even really be called builders, because a fairly normal case of someone wanting their transaction to be at the top of the block might habe an associated contract that allows different users to bid for the right to engage in that contract with the proposer during the particualar block. At this point they aren't really building the block in the sense of the current builder market. And there would be many more examples of this you might have a contract that maintains the relationship that two transactions must be consecutive in a block. Effectively this approacches the rather vague concept of intents, that circulates the Ethereum ecosystem these days. Although this idea is rather elegant I can't imagine it working too well in practice. I mean it seems like a nightmare to engage in this sort of extended builder market when there is already significant layency caused by the reliance on the mev-boost relays. However there are people with much more ecperence than I that will surely take a stab at the issue. Propser builder separation represents one of the most interesting explicit mechanism design issues I've ever seen. Of course the message communication complexirt cannot be too large in practice, but that only makes things more interesting not less.