Try   HackMD

Ethereum Protocol Fellowship - Fourth Cohort

I will be participating in the fourth cohort of the Ethereum Protocol Fellowship program and this document will serve as a summary of my progress.
I intend to work part-time and I'll post regular updates here while keeping things concise.
My current goal is to familiarize myself with the Ethereum protocol and gain enough context to identify a topic that best fits my interests and schedule.

Phase 1

Week 0

I immersed myself in the Ethereum protocol by going through some of the suggested reading materials. Here are some interesting topics about the future of Ethereum worth exploring further. Potentially, I could work on projects related to these:

  • Stateless
  • Light clients
  • Sharding
  • Space Renting
  • EVM 2.0 / VM upgrades

General resources

Week 1

I explored various projects from the proposed ideas to gain a better understanding of the scope and implications of each project and to identify a topic to work on. Unfortunately, I didn't have enough time to explore all of the proposed ideas.

I have explored the following projects:

Fuzzing - Create new fuzzers for software in order to find potential vulnerabilities, or improve on existing fuzzing frameworks. Networking in particular is an area where this could see some improvements on, but clients on the execution layer and consensus layer could also benefit from additional fuzzing.

Unfortunately, there isn't much context or detail provided to describe the current limitations or what needs improvement. I've gone through the suggested repositories and explored all open issues, but there aren't many.

Improving hive for End-to-End Testing - Hive can evolve into more sophisticated tool for e2e testing which allows to run the Consensus and Execution clients as they would be run by the end users.

Ephemery testnet - Contribute to integration of public ephemeral testnet. Research and feedback the spec, create implementations in clients and/or client testing, end user tooling, e.g. dappnode, nicenode, stereum. Check the specs and network details.

P2P protocol tests

Ipsilon - Research around the EVM, specifically (but limited to):
EOF-compatible 4337
Consensus-level eth supply calculation and exposing it as an opcode
EVM memory repricing – analysis and proposing a solution
EVM analysis and design of transfer functions (executing and non-executing)

I'm interested in this project. However, given the timeframe and my current schedule, I'm concerned about the scope being too large. I might consider a different project.

Portal Network - Improve Portal Network interop tests (portal-hive), Portal State Network R&D, Portal DAS network R&D

Conesnsus specs

https://notes.ethereum.org/@hww/consensus-specs-wishlist

By Tomasz Stanczak
By Zahary Karadjov
Ethereum Deb Repo
Teku
Besu

I didn't have time to explore these projects:

Devops tooling wishlist
Lodestar
Prysm
Lighthouse
Alex Stokes
RIG Opened Problems
API for ETH supply
By Yoav Weiss
JSON-RPC improvements

Week 2

I decided to work on the "Fuzzing" project for two main reasons. On one hand, I'm interested in the security aspects of the protocol. On the other, I believe its scope aligns well with my schedule. So I've dedicated time to researching various fuzzing techniques, libraries, and related resources.

I also explored Ethereum's fuzz tooling to identify what is missing and which areas can be improved. Unfortunately, since there are not many issues documented in the repositories and no context is provided on the problem, it would require investing a significant amount of time in actually using the tools to identify the issues:

I invested more time to gain a better understanding of the various parts of the protocol and to determine which areas could benefit the most from fuzzing.

Apart from that, I delved into the Geth/Reth implementations and started working on a simple CLI to conduct very naive fuzz tests. This helped me explore how to interact with a node via the JSON-RPC interface.

Phase 2

Week 3

Last week, I finally began working on the project proposal. Since I haven't extensively used the existing tools and lack a deep understanding of the protocol, I'm not fully aware of their limitations. I've been pondering which layer of the protocol and which aspect would benefit most from fuzzing. As a result, I decided to start with the upcoming protocol changes, focusing specifically on the EVM.
I'm considering creating a CLI tool to test newer protocol upgrades, believing that hands-on experience is the best way to learn. I'm still uncertain whether to stick with Go or opt for Rust for the development of the CLI tool.

Week 4

I continued to progress on the project proposal. In addition to this primary task, I also dedicated time to familiarize myself with the upcoming upgrade, identifying opportunities where I could apply fuzzing techniques as well. This was not an easy task. To effectively fuzz test and exploit the upcoming changes, one needs to gain a deep understanding of them. This requires a significant investment of time, effort, and in-depth knowledge.

Phase 3

Week 5

I began by reviewing the documentation for EL clients (geth, reth) and CL clients (lighthouse) on setting up a node for syncing on Sepolia. Subsequently, I established a local private network for testing purposes. I used my own CLI tool to send malicious payloads, aiming to understand how the node interacts and processes the inputs.
Later, I opted to use an existing fuzzing tool for quicker tests. However, I encountered an issue when trying to run it based on the instructions in the readme. The specific problem can be found here: https://github.com/MariusVanDerWijden/tx-fuzz/issues/24. After some investigation, I managed to resolve my issue and successfully ran the fuzzer. The results were as expected, with no unexpected outcomes.

Week 6

Last week, I delved deeper into the capabilities of FuzzyVM to better understand its functionalities. However, I encountered an issue and subsequently submitted a pull request: https://github.com/MariusVanDerWijden/FuzzyVM/pull/30. After resolving the issue, I ran the fuzzer, which generated several test cases. I tested these cases with Geth's EVM. The plan was to proceed with the remaining clients, however, I didn't have enough time to work further on this project.

Week 7

After experimenting with FuzzyVM, I noticed that it employs goevmlab for test execution, so I decided to explore it further. While I'm not yet fully aware of all its capabilities, I observed that it supports several different EVMs, with the exception of reth's revm. This might be a valuable addition.

Week 8

I explored how to use the testing infrastructure of Ethereum, particularly the tests and the execution tool retesteth. Here is a step-by-step guide on writing state tests which FuzzyVM employs for its fuzzing tests.

There are different types of tests: vm, state, etc. and to be able to fuzz test the upcoming changes, the tests format should reflect those changes. The required Dencun modifications on the state test format are still not proposed, so maybe I should look into the specs and see what needs to be changed.

Resources:

Week 9

Here's an interesting resource describing the FuzzyVM, shared by Marius Van Der Wijden.

He also highlighted that there is a shift going on from the ethereum/tests, which are YAML test descriptions filled with data using the t8n tool (available in most execution clients). He emphasized that for the FuzzyVM to support testing the Cancun changes, up-to-date state tests are required. Unfortunately, these tests aren't easy to update, and typically only the people directly involved can do so, this is currently a blocker. However, there's an ongoing effort to transition to the ethereum/execution-spec-tests, aiming to use it exclusively in the future. This could be a promising starting point for fuzzing the Cancun changes.

Week 10

I transitioned to using the ethereum/execution-spec-tests to generate test fillers for Cancun. An important note is that specific t8n implementations and branches should be used when developing tests for upcoming EIPs. For the EIPs related to Cancun (4844, 4788, 1153, 6780), there's a fork of geth supporting them at marioevz/go-ethereum@cancun-t8n.

Here are the steps to execute the tests for features that are not yet merged into main.

Work on implementing the t8n functionality in reth has been stalled.

Last changed by 
 
Rado
0
521
Published on HackMD