-
Notifications
You must be signed in to change notification settings - Fork 117
docs(l2): add integration tests section #5126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 2 commits
abe0ae3
a749763
3c30010
eff1ae4
daf08a0
7271cc0
d3fd90d
9f57c4e
ffe23fe
b749d81
d921550
2d1cb32
2c89eb2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| 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 | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 🤡 There was a problem hiding this comment. Choose a reason for hiding this commentThe 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/). | ||
|
||
| - 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). | ||
|
||
| > 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. | ||
ilitteri marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| > 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 do so, we set up an L2 with batches of approximately 150 blocks. We achieve this by setting the flag `--block-producer.block-time` to 1 second, which specifies the interval in milliseconds for our builder to build an L2 block. This means the L2 block builder will build blocks every 1 second. We also set the flag `--committer.commit-time` to 150 seconds (2 minutes and 30 seconds), which specifies the interval in milliseconds in which we want to commit to the L1. This ensures that enough blocks are included in each batch. | ||
|
|
||
| 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
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does this assume we cloned the |
||
|
|
||
| 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 | ||
ilitteri marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
There was a problem hiding this comment.
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 toNone.There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
Our integration tests verify that the fees are correct based on the network configuration.
If
operator_feeis not set, the tests will assert that the final balance of theoperator fee vaultis 0 (the same applies to theL1 fee vault).The
base fee vaultis a special case. If no vault is set, we need to manually passINTEGRATION_TEST_SKIP_BASE_FEE_VAULT_CHECK=trueto the integration tests (this could be updated to behave like the other fee checks).We can then encourage testers to try different network configurations.
There was a problem hiding this comment.
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.