# EPF Final update This is the wrap up and final update for the Ethereum Protocol Fellowship 3. ## Project Overview Improving censorship-resistance under proposer-builder separation (PBS). Since the merge, PoS validators have the option to outsource their block production to specialized entities that can extract value. Basically out-sourcing their duties to the highest bidder to increase their APR. There are currently 8 major relays (update: 10 relays, since Dec 6) of which 50% have some sort of censoring. This means that currently +70% of all blocks have some sort of OFAC censoring. This goes against the core protocol values of - Censorship resistance - Credible neutrality ### Additional links 1. [Original EPF proposal](https://notes.ethereum.org/@wslyvh/epf-3-proposal) 2. [Reading list & resources](https://notes.ethereum.org/@wslyvh/epf-3) 3. [execution-api PR](https://github.com/ethereum/execution-apis/pull/353) and [original proposal](https://notes.ethereum.org/@wslyvh/txpool-api) 4. [Dune dashboard](https://dune.com/wslyvh/network-utilization) 5. [txpool explorer](https://txpool-explorer.vercel.app/) ## Status For my project I've explored several directions. Not all of them successful. My roadmap described for 4 main tasks. - [x] Create a Dune dashboard / explorer to track network health and block utilization. - Available at https://dune.com/wslyvh/network-utilization - [x] Use same metrics to create a new mempool explorer to analyze censored transactions. - Available at https://txpool-explorer.vercel.app/ - Contributed to [wagmi](https://github.com/wagmi-dev/wagmi/) to fetch pending transaction - [x] Create proposal to standardize 'txpool' API for execution clients. - PR ready at https://github.com/ethereum/execution-apis/pull/353 - Presented at ACD 155 https://github.com/ethereum/pm/issues/720 - [ ] Use the methodology from 1/2 to integrate with exising tools (e.g. mev-boost, relay-monitor) to keep relays honest. - Not finished. One of the challenges was that both of these tools were in languages I'm not familiar with. More importantly, after monitoring the network for a while, I realized tracking utilization wasn't the right way to go. These are 'smoothed out' because of 1559. Not fully utilizing blockspace is more likely a side effect of bad networking conditions at the client then it is from censoring. ## Future of the project The biggest achievement for me was contributing to the execution API and help standardize the txpool API. The proposal has been discussed on the [ACD call](https://github.com/ethereum/pm/issues/720) and people were receptive to it, although I can imagine implementation will take some time. Standardizing the namespace is just the first step towards more reliable integrations and better accessibility to mempool information. One the use-cases would be a [crLists](https://github.com/flashbots/mev-boost/issues/215) for mev-boost. ## Self-evaluation At the start of the program, we were at a peak of ~80% of the blocks getting censored according to [MEV watch](https://www.mevwatch.info/). This shocking number was a huge impact for my decision to explore and try to work in this area. During the past months, the community as a whole seemed to have acted upon this as well. The current number down to <45%. The biggest change is a more competitive market for (non-censoring) relays and block builders. These developments have somewhat influenced my motivation during the past months as it became a 'less urgent' problem. A personal learning is to focus more on problems I'm genuinely interested in, instead of following the latest 'issues' or trends. Privacy has been one of the topics I was initially interested in to explore. Either way, I'm proud of what I achieved the past months. A standardized Txpool API provides a more robuts and reliable foundation for other projects, such as mev-boost. It is hopefully, just the first step towards new integrations and other use-cases. Big thanks to Mario, Josh, the mentors, other fellows and everyone else involved. It's been an amazing journey and proud to have been part of this!
Last changed by  
 
Wesley
149

Read more

txpool API proposal (draft)

This proposal is an initial draft to standardize the txpool JSON-RPC API for Ethereum execution clients. All clients provide some access to txpool information, but currently all have their own implementations. See more details below. Standardizing the txpool namespace would be beneficial for interoperability, and hopefully allows for more reliable integrations that enable for example crLists. Current state Geth Nethermind Hyperledger Besu Erigon

2/16/2023
EPF Project Proposal

Improving censorship-resistance under proposer-builder separation (PBS). Motivation What problem is your project is solving? Why is it important and what area of the protocol will be affected? Since the merge, PoS validators have the option to outsource their block production to specialized entities that can extract value. Basically out-sourcing their duties to the highest bidder to increase their APR. There are currently 8 major relays (update: 10 relays, since Dec 6) of which 50% have some sort of censoring. This means that currently +70% of all blocks have some sort of OFAC censoring. This goes against the core protocol values of Censorship resistance Credible neutrality

12/6/2022
Ethereum Protocol Fellowship

This document will be living document on my learnings, updates and progress on the Ethereum Protocol Fellowship (EPF). I'm very excited to be part of the 3rd cohort and dive deeper into Ethereum and protocol development. I'll also try to build in public and regularly share updates about my progress on Twitter. Resources What is the Fellowship Program EPF cohort 3 Program details Mentors Project Ideas

11/18/2022
Read more from Wesley
Published on HackMD