Intro to Ethereum Execution Layer Testing

Background

I want to explain how Ethereum testing works. Testing in general is a critical component of ensuring the Ethereum protocol stays up and running and avoids any network forks. As Ethereum evolves, there are various upgrades to consider. At the time of writing, the next upgrade coming is the Pectra fork. Of course before going live, client teams and core devs need to do a thorough job of testing the protocol, looking at every possible use case and scenario to minimize any impact on end users and ensure security and stability.

There are multiple tests that can be conducted for execution layer testing and how it ensures an Ethereum Execution Client is adhering to set specifications. A recent Testing presentation for the EPF study group has a quote from one slide that I think summarizes the purpose of execution layer testing: “All clients must produce the same output when given the same input in the form of a single or multiple transactions, an environment, a pre-state, and hard-fork activation rules.”

The pre-state is where smart contracts, balances, code and storage exist. To mimic real life situations, the pre-state has to have the intention of doing something worthwhile or interesting, otherwise why else would a test be needed for the situation?

The environment will look at specific items such as the timestamp, prev-randao, block number, total gas limit and base fee. This is dependent on what type of test you plan to conduct.

The transaction(s) contain the account source and destination, ether value, gas and data.

The post-state is what happens after the transactions occur based on the pre-state and environment parameters. There will be new smart contracts, modified balances, new code, modified storage and there will be an updated state-root.

ethereum/tests

The ethereum/tests repo houses common tests that all clients can test against. These include State Tests, Blockchain Tests and Transaction Tests to name a few.

These tests use Retesteth tool. Retesteth is a filler written in C++ that takes your source code (Simple JSON or YAML) and makes it consumable for any execution client to use.

ethereum/execution-spec-tests

The ethereum/execution-spec-tests repo houses tests that are aimed at ethereum execution client specification network upgrades and the pyspec, which is why this is implemented in Python. Similar to ethereum/tests, ethereum/execution-spec-tests also generates JSON files that are consumable for any execution client to use.

Put into Action

Both of these repos contain the necessary instructions for anybody to test out current tests or create your own tests. As I've gone through this in a relatively short period of time, the challenge is how to create a quicker onboarding process for somebody who is completely new to testing to understand it and begin contributing right away.

While this essay is aimed for the EPF5 application, I will edit it as I continue to dig deeper into Testing and acquire more knowledge around the space. I am particularly keen to pick some EVM opcodes, write my own tests and create and demo an environment to run ethereum/tests. NOTE: Found this as a take home assignment idea.