HackMD
🌟 EPF-5| Week 1 🌟
Sections
Update 📅
As I mentioned in my previous update, privacy and censorship resistance are my areas of interest. At the beginning of the week, I started exploring the ecosystem to find related ideas and projects that align with my interests for the program.
After initial research, I realized that having a censorship-resistant protocol is a prerequisite for privacy. So, I decided to focus more on censorship resistance.
The following website provides insights into the current status of network censorship:
builders has power to censoring some non-compliant transactions and it's possible they decide to adding more types of transactions to their non-compliant list in future.
During my next wave of exploration on the second day, I found EIP-7547 (Inclusion List). After reading the initial proposal, I saw potential in this area and began a deep dive into the Inclusion List:
1. Watched recorded videos of Inclusion List breakout rooms 1, 2,
and 3 (links available in the Resources section).
2. Identified some problems and challenges through the breakout sessions.
3. Read all related posts on EthResearch and EthMag.
4. Reviewed most of the old messages in the cross-layer/inclusion-list channel
on the Eth R&D Discord server.
5. Connected with one of the authors of EIP-7547 and discussed
about eip7547 and its current state.
Additionally, I reviewed the consensus spec for EIP-7547 and examined the Reth implementation for the Engine API. These steps have further solidified my interest in working on this idea and its implementation because I realized that implementing this EIP would require me to get involved in different layers of the system (Execution Layer, Engine API, Consensus Layer). This experience would be beneficial for my journey of becoming a core developer.
After these steps, I am confident that I want to work on this idea and its implementation. In the coming sections, I’ll explain my thoughts on the implementation, some of the challenges I need to address, and my plans for the coming week.
Inclusion List Challenges ⚠️
The Inclusion List idea was published last fall. At that time, there were no major concerns regarding its implementation, and everything seemed feasible for incorporating it into the protocol.
However, in the following winter, new ideas for native account abstraction on Ethereum, such as EIP-3074 and EIP-7702, were introduced. These types of transactions could invalidate a transaction in the Inclusion List, presenting a new challenge that needs to be addressed. I believe a more viable solution is to maintain a list of addresses whose balances were affected in the last block within the execution client and use that list for validating the Inclusion List.
The second challenge is that the Inclusion List has the potential to create a new MEV-like market and provide Free Data Availability (DA) to L2. This challenge is also addressed in the new approach discussed by the EIP authors in Breakout Room 3. Instead of committing to the Inclusion List, the proposed solution involves using a non-committing and forward Inclusion List.
From Breakout Room Session #3
Vitalik’s EthResearch Post on Inclusion List 📝
During a conversation with one of the EIP authors, it was mentioned that due to various challenges, the Inclusion List had been dropped from the next protocol upgrade (Electra). Different teams lost interest in implementing it this year, and it seems likely that the whole structure of the EIP will need to be revised to be part of ePBS next year. After this conversation, I was uncertain whether I should explore a new idea or continue with this one.
Then, unexpectedly, Vitalik posted a new post on EthResearch that related to Inclusion List. He introduced an approach that allows validators to have semi-deniability regarding the transactions in the inclusion list.
This renewed my interest and convinced me that I could help the ecosystem by implementing this idea. My implementation could serve as an example for different teams that may want to implement this idea in next year.
Vitalik’s post: (One-bit-per-attester Inclusion Lists)
https://ethresear.ch/t/one-bit-per-attester-inclusion-lists/19797
Inclusion lists are a technology for distributing the authority for choosing which transactions to include into the next block. Currently, the best idea for them is to have an actor that is from a set that is likely to be highly decentralized (eg. consensus block proposers) generate the list. This authority is decoupled from the right to order (or prepend) transactions, which is an inherently economies-of-scale-demanding and so likely to be highly concentrated in practice.
But what if we could avoid putting the responsibility onto a single actor, and instead put it on a large set of actors? In fact, we can even do it in such a way that it’s semi-deniable: from each attester’s contribution, there is no clear evidence of which transaction they included, because one individual piece of provided data could come from multiple possible transactions.
Project Proposal: Initial idea 📃
For implementing the Inclusion List, I will need to work on both the Execution Layer and the Consensus Layer.
I've chose to use the Reth and Lighthouse clients for my implementation.
The specification for the implementation will be similar to the old spec from the EIP authors, which can be found here. However, I will modify some parts of it based on the new approach (One-bit-per-attester Inclusion Lists).
I plan to publish the updated version of the spec in the coming weeks.
If time permits, I will also explore different strategies for transaction selection for the Inclusion List in the Execution Layer when i get done with implementation.
This is a very initial draft of my project idea, and I am excited to share the ideas I have for it. Once ready, I will open a pull request for it in the project section of EPF repo with sufficient technical details.
Next Week Plan 📆
- Understand the Algorithm Behind One-bit-per-attester (Committing and Decoding)
- Deep Dive on Reth Engine API Implementation
- Getting onboard on the Lighthouse Codebase
- checking eip-7702 reth implementation
- Work on the Final Architecture for Implementation
- Create diagrams and documentation to outline the architecture
- Create diagrams and documentation to outline the architecture
Resources 📚
| Title | Link | |
|---|---|---|
| eth roadmap | https://ethroadmap.com/ | website |
| censorship dashboard | http://censorship.pics/ | website |
| One-bit-per-attester inclusion lists | https://ethresear.ch/t/one-bit-per-attester-inclusion-lists/19797 | post |
| Inclusion List Breakout Room 3 | link | zoom (Passcode: 38%%qe1C) |
| Inclusion List Breakout Room #2 | https://www.youtube.com/watch?v=GVdkDXZTtnw | youtube |
| Inclusion List Breakout Room #1 | https://www.youtube.com/watch?v=LhZSunC8Ep | youtube |
| PEEPanEIP#130 :EIP-7547 | https://www.youtube.com/watch?v=oRjG0RMnK5U | youtube |
| eip-7547 | https://eips.ethereum.org/EIPS/eip-7547 | eip |
https://ethresear.ch/t/inclusion-list-eip-7547-end-to-end-workflow/18810
https://hackmd.io/@ttsao/ryCG0cTJA
https://ethresear.ch/t/inclusion-list-eip-7547-end-to-end-workflow/18810
https://gist.github.com/michaelneuder/ba32e608c75d48719a7ecba29ec3d64b
https://notes.ethereum.org/@mikeneuder/il-poc-spec
https://github.com/ethereum/pm/issues/981
https://github.com/search?q=repo%3Aethereum%2Fpm Inclusion List&type=code
https://hackmd.io/@potuz/Sk_Xg0x06
