HackMD
Final Dev Update for EPF Cohort 4
Hey there, I am Manav Darji and these are my final dev updates for the Ethereum Protocol Fellowship - Cohort 4. It was a really fun ride and I genuinely enjoyed being a part of this fellowship, working on complex problems and meeting new people.
TL;DR
Throughout the fellowship, I worked on ePBS (enshrined proposer builder separation) with forward inclusion list design project under the mentorship of Potuz and Terence from Prysm team. We as a team were able to help them review the consensus specifications and also kicked off some aspects of the implementation.
Project Abstract
Currently, PBS (Proposer Builder Separation) exists outside of the protocol by builders helping in block building through entities like relays. This design relies on small set of trusted relays and even builders which introduces centralisation risks and makes Ethereum more vulnerable to censorship. This ethereum research post advocates for having in-protocol PBS overcoming the problems which exist in an out of protocol solution while still maintaining the core properties of PBS. ePBS has multiple designs and we worked on the Payload-timeliness committee (PTC) design. This design was also coupled with a flavour of forward inclusion lists design known as no free lunch.
At a high level, this design will allow builders to be part of the ethereum validator set by staking a relatively high amount compared to normal validators. This allows builders to propagate bids to the proposer which further chooses the best bid and builds a block without payload. Once enough votes are gathered on the blinded beacon block (without payload), builder reveals the payload and the PTC committee (a subset of selected validators) will vote on that payload. Based on the beacon block and PTC votes, the next proposer decides which fork to build the next block on. Additionally, the proposer of the current block can include transactions as a part of inclusion list forcing the builder of next block to include them in their payload, preventing censorship.
Project updates and status
The project involved reading existing literature of PBS and earlier proposed ePBS designs along with solutions to mitigate censorship. As the design was only proposed as an idea, Potuz and Terence started working on consensus specifications for the same which can be later used by implementors. I participated in reviews and discussion calls of these specifications.
Additionally, I contributed to the engine API specs for the execution layer. Using those specs, I implemented a very simplistic and naive proof of concept of forward inclusion list in geth.
All the work done by the mentors and us can be found here:
- Consensus specs (beacon chain, fork choice)
- Consensus specs (builder, validator, p2p)
- Engine API specs
- Inclusion list implementation in geth
Devconnect Istanbul Presentation by the team can be found here:
Future Plans
I, personally am interested to continue working on this project as I am in favour of this in-protocol approach to PBS. I'd say, implementation wise, the project hasn't even started fully so there's a lot of work to do. I'm already in touch with the mentors for the same as they're willing to push the first iteration of the client implementation to completion. As the specifications are now laid out and aren't changing much, I plan to work on the some components of the prysm implementation. Eventually, we plan to spin up a devnet with the new changes.
Self Evaluation
I am satisfied with the kind of things I got to work on or at least experience. Seeing mentors gradually building up on a research idea and turning it into well defined specifications was the most interesting part and helped me a lot in understanding their thought process and way such complex research projects evolve.
Few things that I should have done better are:
- I couldn't spend much time in exploring projects in the initial few weeks. As projects were quite open-ended, it was a bit challenging to find out the current progress of them and problem statements to work on. This led me to only explore 2-3 projects in total.
- Working in a team wasn't as fruitful as I thought it would be. I couldn't guage expecations correctly from my team mates and there was a bit of disconnect. It was hard to manage.
- Although I wanted to, I couldn't get involved in the spec writing process (at least the consensus ones). The mentors even gave us chance to get involved in the writing process but I wasn't much proactive to take that up.
- I could have been better at writing updates including more nuanced discussions which happened during our calls with mentors.
EPF Experience
EPF was an amazing experience and totally aligned with my interests in Ethereum R&D projects. The programme was well structured with it being cohesive (tightly binding) and quite open (to exploration and work) at the same time. Huge thanks to Josh and Mario for setting this up and being there for all the queries. All the mentors have been really helpful and involved in their best capacity. Devconnect Istanbul was cherry on the cake. Thank you and Godspeed ⚡️
