Ethereum Protocol Fellowship - The Third Cohort (Final Update)

All good things come to an end. This is the final update for Ethereum Protocol Fellowship - The Third Cohort. It's a little bit longer, but there are many things to be said.

Project summary

The project's core goal was to dive deeply into the world of account abstraction and EIP-4337 by implementing some sort of node-equivalent component called bundler in the programming language Rust. The main jobs of the bundlers are accepting user operations (which are similar to transactions) that come from smart contract wallets, bundling them together into bundles, and submitting bundlers to EL (execution layer) clients as standard transactions.

Here is the list of some of the most critical things bundlers must perform (to work correctly and be safe from different attacks, such as DOS):

• When user operation is received, it is validated (so-called sanity checks), e.g., property sender is a contract or initCode is not empty.
• User operations are also simulated on-chain, and the simulation function must always revert. Simulation is executed by calling a specific smart contract function through the debug_traceCall endpoint, and opcodes are verified; e.g., some opcodes that can change when a user operation is actually submitted to the chain are forbidden.
• The whole model of EIP-4337 contains several entities, such as senders/accounts, paymasters, factories, and aggregators. To prevent malicious behavior, all the entities have on-chain/off-chain reputations, influencing the actions allowed for entities.
• By default, bundlers work with canonical mempool, for which the verification rules of user operations and entry point (a smart contract that handles user operations) are defined in the EIP. In the future, multiple mempools will exist for different reasons, e.g., updating the entry point smart contract or more relaxed rules for trusted entities, such as paymasters. The goal is that the bundler can support different mempools.
• P2P network of bundlers, which should be similar to one of EL clients. The main activity on the network is the exchange of user operations, and bundlers can subscribe to specific mempools that interest them. Other teams defined official specs during the fellowship, using libp2p and SSZ serialization.
• And some other things that are not mentioned so that the report is not too long.

Links:

• Description: https://github.com/eth-protocol-fellows/cohort-three/blob/master/projects/4337-bundler-rust.md
• Architecture and specification: https://hackmd.io/@Vid201/aa-bundler-rust
• GitHub repository: https://github.com/Vid201/aa-bundler/

Status report

My goals for the project were:

1. Bundler is fully implemented and tested.
2. Demonstrate successful implementation by connecting and using one of the EIP-4337 compatible wallets.
3. Contribute to official bundler specs and pass the test suite.
4. Successfully connect and form the p2p network with other bundler implementations.
5. Outline the plan and work to push the implementation into Reth's main codebase.

Looking at all the goals at the end of the fellowship, they look very optimistic. Still, they made sense since they cover all the aspects the bundler should have to be production ready. But it was too much for the course of the fellowship. Though the project progressed very well, and it's set up to hit all the goals in the future.

I created two repos:

• Bundler itself, the core codebase for the bundler in Rust: https://github.com/Vid201/aa-bundler
• Bundler spec test executor: https://github.com/Vid201/bundler-test-executor

Since the repo was started from scratch, many things had to be set up and the whole architecture defined from the ground up (check the https://hackmd.io/@Vid201/aa-bundler-rust). Below is the link between the roadmap defined in the project description and different PRs:

• JSON-RPC API: https://github.com/Vid201/aa-bundler/pull/59, https://github.com/Vid201/aa-bundler/pull/56, https://github.com/Vid201/aa-bundler/pull/39
• User operation mempool:
  • In memory mempool: https://github.com/Vid201/aa-bundler/pull/34
  • Sanity checks: https://github.com/Vid201/aa-bundler/pull/24
  • Simulation verification (forbidden opcodes): https://github.com/Vid201/aa-bundler/pull/62
• Reputation: https://github.com/Vid201/aa-bundler/pull/43
• Bundler spec testing:
  • Docker files: https://github.com/Vid201/aa-bundler/pull/52
  • Preparation for test executor: https://github.com/Vid201/bundler-test-executor/commit/8fa4b969dd582b8543c331a651ba13b6bbcaf5f5

During the development, it turned out that the most active library for interacting with the Ethereum blockchain in Rust, ethers-rs, didn't support some functionalities that bundlers need. Therefore, I created two PRs:

• Add support for debug_traceCall: https://github.com/gakonst/ethers-rs/commit/b27c7b0773d7ba329e0e1eebb37db652ac8fa601
• Add support for custom JS tracer in debug endpoints: https://github.com/gakonst/ethers-rs/commit/7e7f9041b3f5a601a8fca8ccbce0287518f8cc33

There were also changes to long-term plans related to integrating bundler to execution client. During the fellowship, the Akula client was deprecated at the time of the release of Reth. Due to Akula stopping being developed and the team behind Reth being quite big and fast, the plans changed from integrating into Akula to Reth. Both projects build upon Erigon architecture, so the higher-level picture and goals of the integration stay similar.

As always - next steps

The work on the project will continue after the fellowship, focusing on the things that were on the initial roadmap and still need to be done. This includes finishing the simulation verification, core bundling part, and P2P protocol. The main goal is to pass all the bundler spec tests and test the P2P protocol with other bundler implementations. After that, the bundler will still be developed, improved, and adapted based on possible changes to the EIP-4337 in the future.

One interesting thing to explore is to create a library for EIP-4337 user operations or extend ethers-rs to support that. Another goal is to integrate bundler in the Reth or use Reth libraries/modules in the codebase to work toward possible tighter integration.

Self-evaluation

Participation in the EPF was one of the most fulfilling and creative programs/projects I participated in. I definitely recommend it to other engineers interested in the Ethereum protocol who want to start working on it.

On the technical front, I learned a lot. Development advanced slower than I thought due to learning about all the technical and implementation details of the EIP (the devil is in the details :) ). I also scrolled through the codebases of Rust-based Ethereum projects to get some ideas and good practices on structuring different things and which libraries/crates to use. Before the fellowship, some big projects seemed scary at first sight, but after getting my hands dirty and receiving some great advice from other fellows, things turned out pretty fun.

The fellowship also helped me develop on a personal level. Presenting the project and work done was really beneficial, especially at the beginning when we had to show some of our early work on new topics. I also met several other people/projects building in the space (especially account abstraction), with several contacting me to chat about the development process. The Ethereum community is very welcoming and fantastic!

"What do you have to teach us, Piper? Absolutely nothing; this is not how it works. Go figure it out for yourself." Piper was not joking when he said that in his talk about the EPF at Devcon 2022. But that's very good since everyone has a different approach to learning about new stuff and chooses his path down the rabbit hole. Thus, the fellowship offers a good balance between independent work, reporting the work on the standup calls, excellent interviews with other devs from the Ethereum community, and the possibility to work with incredible mentors that are the best in the field.

Closing

I want to thank another fellow working with me on the project, Will. He is awesome and gave me some great advice on all the PRs. I would also like to thank Mario Havel and Josh Davis for organizing everything, running the meetings, and being available and happy to help when we had some problems/questions. The final update is being published two days before going to ETH Denver 2023, and I am so excited to attend and meet others in the meatverse!