In-Memory Node

Learn how to setup a local in-memory era_test_node.


This section provides instructions on setting up and using the In-Memory Node, era_test_node, for local testing. It covers installation, network forking, transaction details viewing, replaying transactions, and testing local bootloader and system contracts.

Please keep in mind that era-test-node is still in its alpha stage, some features might not be fully supported yet and may not work as fully intended. It is open-sourced and contributions are welcomed.

Understand the In-Memory Node

The In-Memory Node uses an in-memory database for storing state information and simplified hashmaps for tracking blocks and transactions. In fork mode, it retrieves missing storage data from a remote source when not available locally. Moreover it also uses the remote server (openchain) to resolve the ABI and topics to human readable names.

You can visit the era-test-node repository to learn more.

Run actions with zksync-cli

You can setup the In-Memory Node quickly with zksync-cli dev start. If you don't have zksync-cli setup, see the Overview guide.

Note: at the moment this method won't allow you to use additional features like forking networks or replaying transactions.

Install and set up era_test_node

  1. Download era_test_node from latest Release.

  2. Extract the binary and mark as executable:

    tar xz -f /path/to/downloaded/binary/era_test_node.tar.gz -C /usr/local/bin/
    chmod +x /usr/local/bin/era_test_node
  3. Start the node:

    era_test_node run

The expected output will be as follows:

When utilizing era_test_node with MetaMask, it's essential to note that any restart of the in-memory node will necessitate a reset of MetaMask's cached account data (nonce, etc). In the MetaMask app, navigate to 'Settings', then 'Advanced', and finally, select 'Clear activity tab data'.

Network details

The era_test_node has the following default network configurations:

  • L2 RPC: http://localhost:8011

  • Network Id: 260

These can be configured to your preference.

Please note that the existing implementation does not facilitate communication with Layer 1. As a result, an L1 RPC is not available.

Pre-configured rich wallets

In-Memory node includes pre-configured "rich" accounts for testing:

Rich walletsSame mnemonic rich wallets


Debug Transactions & Smart Contracts

The default configuration of era_test_node displays minimal data in the terminal to keep the output clean. However, if you are having issues with your smart contracts and need more details why a transaction is failing, try enabling --debug-mode (or just -d).

This will:

  • Show the full call stack and each call's output for transactions

  • Show more details about the breakdown of gas cost per transaction

  • Resolve known hashes into human-readable strings


Fork a network

To fork the mainnet, use the following command, replacing [network] with either mainnet or sepolia-testnet:

Expected output

This command starts the node, forked at the current head of the selected network.

You also have the option to specify a custom http endpoint and a custom forking height:


Replay remote transactions locally

If you wish to replay a remote transaction locally for deep debugging, use the following command:

For more detailed transaction information, such as call traces, add the --show-calls flag. If you want to see ABI names, add the --resolve-hashes flag:

Alternatively (if your node is already running) you can use config_setShowCalls and config_setResolveHashes RPC endpoints to configure these values:

Here's an example of what you should expect to see when show-calls and resolve-hashes are configured:

Expected output


Send network calls

You can send network calls against a running era_test_node.

Launch the local in-memory node:

  • Use curl to send a network call:curlexpected output

  • Use foundry-zksync. Make sure to install and configure foundry-zksync before proceeding (for installation instructions, please see Foundry with ZKsync Era):foundry-zksyncexpected output

    Retrieve the balance of a particular contract:foundry-zksyncexpected output


Deploy contracts

For the deployment of your contracts, you have the flexibility to choose between two preferred methods: either by using Hardhat with the @matter-labs/hardhat-zksync plugin, or via foundry-zksync.

The following example will detail the process using foundry-zksync.

Before proceeding, ensure that you've compiled your contracts using forge build --zksync.

foundry-zksync


Test bootloader and system contracts

In-memory node allows testing of the currently compiled bootloader and system contracts. This makes it possible to examine the effects of changes on already deployed contracts.

These commands assume you have set $ZKSYNC_HOME in your shell profile file (e.g. ~/.bash_profile, ~/.zshrc) to target your local copy of era_test_node. For instance,

  1. Preprocess and compile the contracts:

  2. To use the locally compiled bootloader and system contracts, run:

Writing and running tests locally

This section demonstrates how to author and execute tests locally against era_test_node using the mocha and chai testing frameworks with Hardhat.

Project configuration

  1. Start by creating a new Hardhat project. If you need guidance, follow the getting started guide.

  2. To incorporate the test libraries, execute:yarnnpmbun

  3. Add the following lines to your package.json in the root folder:package.json

This script makes it possible to run tests in a Hardhat environment with the NODE_ENV env variable set as test.

Configure tests

Adjust hardhat.config.ts to use the local node for testing:

Ensure era_test_node is running in another process before executing the test command.hardhat.config.ts

Write test scripts

Construct a test/main.test.ts file with the following code:

test/main.test.ts

To run the test file, execute:

npmyarnpnpmbun

Well done! You've successfully run your first local tests with Validium and era_test_node.


Troubleshooting

If running era_test_node run provides the following error:

You may require the use of sudo. On macOS, the binary may need to have its quarantine attribute cleared:

Last updated