Skip to content
62 changes: 62 additions & 0 deletions docs/developers/l2/integration-tests.md
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running the whole workflow gives me an error about the final balance of the base fee vault being 0. Requesting the current base fee vault address to the L2 node returns null, so I suspect the base fee vault is somehow being set to None.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the command options and also added some explanation on the newly added flags.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note on this:
We can run the integration tests without the following flags:

 --block-producer.operator-fee-vault-address
 --block-producer.l1-fee-vault-address
 --block-producer.operator-fee-per-gas

Our integration tests verify that the fees are correct based on the network configuration.
If operator_fee is not set, the tests will assert that the final balance of the operator fee vault is 0 (the same applies to the L1 fee vault).

The base fee vault is a special case. If no vault is set, we need to manually pass INTEGRATION_TEST_SKIP_BASE_FEE_VAULT_CHECK=true to the integration tests (this could be updated to behave like the other fee checks).

We can then encourage testers to try different network configurations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR enables running the integration tests with any fee configuration without any additional steps.

Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# Running integration tests

In this section, we will explain how to run integration tests for ethrex L2 with the objective of validating the correct functioning of our stack in our releases. For this, we will use ethrex as a local L2 dev node.

## Prerequisites
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should mention docker is required. I just ran everything without starting docker and it wasn't clear what was failing 🤡

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wrong about this. Docker is not needed. The L1 dev node is started using the binary.


- This guide assumes that you have ethrex L2 installed. If you haven't done so, follow one of the installation methods in the [installation guide](https://docs.ethrex.xyz/getting-started/installation/).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As this is going to be mostly for testing our releases, on the prerequisites besides sending people to the docs I suggest some extract like... if you need to run the latest realease just install it like this

- For running the tests, you'll need a fresh clone of [ethrex](https://github.com/lambdaclass/ethrex/).

## Setting up the environment

Our integration tests assume that there is an ethrex L1 node, an ethrex L2 node, and an ethrex L2 prover up and running. So before running them, we need to start the nodes.

### Running ethrex L2 dev node

For this, we are using the `ethrex l2 --dev` command, which does this job for us. In one console, run the following:

```
ethrex l2 --dev \
--committer.commit-time 150000 \
--block-producer.block-time 1000
```

> [!NOTE]
> ethrex's MPT trie implementation is path-based, and the database commit threshold is set to `128`. In simple words, the latter implies that the database only stores the state 128 blocks before the current one (e.g., if the current block is block 256, then the database stores the state at block 128), while the state of the blocks within lives in in-memory diff layers (which are lost during node shutdowns).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"MPT trie" is redundant

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

> In ethrex L2, this has a direct impact since if our sequencer seals batches with more than 128 blocks, it won't be able to retrieve the state previous to the first block of the batch being sealed because it was pruned; therefore, it won't be able to commit.
> To solve this, after a batch is sealed, we create a checkpoint of the database at that point to ensure the state needed at the time of commitment is available for the sequencer.
> For this test to be valuable, we need to ensure this edge case is covered. To ensure this is covered, we set up an L2 with batches of ~150 blocks by setting the flag `--block-producer.block-time` (specifies the interval in milliseconds in which we want our builder to build an L2 block) to 1 second, meaning that the L2 block builder will build blocks every 1 second; and by setting the flag `--committer.commit-time` (specifies the interval in milliseconds in which we want to commit to the L1) to 150s (2m 30s) to ensure that enough blocks are included in the batch.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This note is technical and valuable, but it's dense. It provides the necessary context to understand why we are configuring the L2 the way it is specified.

Any feedback on how to improve this part is more than welcome.


So far, we have an ethrex L1 and an ethrex L2 node up and running. We only miss the ethrex L2 prover, which we are going to spin up in `exec` mode, meaning that it won't generate ZK proofs.

### Running ethrex L2 prover

In another terminal, run the following to spin up an ethrex L2 prover in exec mode:

```
ethrex l2 prover \
--backend exec \
--proof-coordinators http://localhost:3900
```

> [!NOTE]
> The flag `--proof-coordinators` is used to specify one or more proof coordinator URLs. This is so because the prover is capable of proving ethrex L2 batches from multiple sequencers. We are particularly setting it to `localhost:3900` because the `ethrex l2 --dev` command uses the port `3900` for the proof coordinator by default.
> To see more about the proof coordinator, read the [ethrex L2 sequencer](https://docs.ethrex.xyz/l2/architecture/sequencer.html#ethrex-l2-sequencer) and [ethrex L2 prover](https://docs.ethrex.xyz/l2/architecture/prover.html#ethrex-l2-prover) sections.

## Running the integration tests

During the execution of `ethrex l2 --dev`, a `.env` file is created and filled with environment variables containing contract addresses. This `.env` file is always needed for dev environments, so we need it for running the integration tests. Therefore, before running the integration tests, copy the `.env` file into `ethrex/cmd`:

```
cp .env ethrex/cmd
```
Comment on lines +68 to +72
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this assume we cloned the ethrex repo and are not inside it?


Finally, in another terminal (should be a third one at this point), change your current directory to `ethrex/crates/l2` and run:

```
make test
```

## Troubleshooting

TODO
1 change: 1 addition & 0 deletions docs/developers/l2/introduction.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,3 +7,4 @@ This section provides information about the internals of the L2 side of the proj
## Table of contents

- [Dev mode](./dev-mode.md)
- [Running integration tests](./integration-tests.md)
Loading