diff --git a/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_prover.md b/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_prover.md index 9d4125a27ee6..e68abd8ddfd7 100644 --- a/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_prover.md +++ b/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_prover.md @@ -161,12 +161,13 @@ Required environment variables: - `PROVER_BROKER_HOST`: Broker endpoint for job submission - `PROVER_ID`: Ethereum address corresponding to `PROVER_PUBLISHER_PRIVATE_KEY` +**Note**: Some variables overlap with the prover node configuration. In this case we use the same value for `PROVER_BROKER_HOST`, so we will not duplicate it in our `.env` file. + Add to your `.env` file: ```sh PROVER_AGENT_COUNT=10 PROVER_AGENT_POLL_INTERVAL_MS=10000 -PROVER_BROKER_HOST=http://prover-broker:8080 PROVER_ID= ``` @@ -199,15 +200,14 @@ name: aztec-prover services: prover-node: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-node - - --archiver - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-node + --archiver + --network testnet depends_on: prover-broker: condition: service_started @@ -219,6 +219,7 @@ services: LOG_LEVEL: ${LOG_LEVEL} PROVER_BROKER_HOST: ${PROVER_BROKER_HOST} PROVER_PUBLISHER_PRIVATE_KEY: ${PROVER_PUBLISHER_PRIVATE_KEY} + P2P_IP: ${P2P_IP} P2P_PORT: ${P2P_PORT} AZTEC_PORT: ${AZTEC_PORT} ports: @@ -230,14 +231,13 @@ services: prover-broker: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-broker - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-broker + --network testnet environment: DATA_DIRECTORY: /var/lib/data ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} @@ -248,14 +248,13 @@ services: prover-agent: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-agent - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-agent + --network testnet environment: PROVER_AGENT_COUNT: ${PROVER_AGENT_COUNT} PROVER_AGENT_POLL_INTERVAL_MS: ${PROVER_AGENT_POLL_INTERVAL_MS} diff --git a/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md b/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md index a98c8bf9f25b..753258667d1b 100644 --- a/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md +++ b/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md @@ -24,17 +24,17 @@ tags: ## Background -This guide covers the steps required to run a sequencer node on Aztec. It will also provide context to ensure users are comfortable with the steps they are taking. +This guide covers the steps required to run a sequencer node on the Aztec network. The Aztec sequencer node is critical infrastructure responsible for ordering transactions and producing blocks. -The sequencer node takes part in three key actions: +The sequencer node performs three key actions: -1. Assemble unprocessed transactions and propose the next block -2. Attest to correct execution of txs in the proposed block (if part of the sequencer committee) -3. Submit the successfully attested block to L1 +1. Assembles unprocessed transactions and proposes the next block +2. Attests to correct execution of transactions in proposed blocks (when part of the sequencer committee) +3. Submits successfully attested blocks to L1 -When transactions are sent to the Aztec network, sequencer nodes bundle them into blocks, checking various constraints such as gas limits, block size, and transaction validity. Before a block can be published, it must be validated by a committee of other sequencer nodes who re-execute public transactions and verify private function proofs so they can attest to correct execution. These sequencers attest to the block's validity by signing the block header, and once enough attestations are collected (two-thirds of the committee plus one), the sequencer can submit the block to L1. +Sequencer nodes bundle transactions into blocks while checking constraints like gas limits, block size, and validity. Before publication, blocks must be validated by a committee of sequencer nodes who re-execute public transactions and verify private function proofs. Committee members attest to validity by signing the block header. Once sufficient attestations are collected (two-thirds of the committee plus one), the block can be submitted to L1. The archiver component complements this process by maintaining historical chain data. It continuously monitors L1 for new blocks, processes them, and maintains a synchronized view of the chain state. This includes managing contract data, transaction logs, and L1-to-L2 messages, making it essential for network synchronization and data availability. @@ -49,33 +49,38 @@ Minimum hardware requirements: Please note that these requirements are subject to change as the network throughput increases. -This guide expects you to be using a "standard" Linux distribution like Debian / Ubuntu when following along with the steps. +This guide assumes you are using a standard Linux distribution (Debian or Ubuntu). -It also is assumed that you have installed Docker and the aztec toolchain via aztec-up as described in the [getting started section](../../index.md). +### Required Software -Furthermore, as this guide uses Docker compose, you will need to install it. Please follow [this](https://docs.docker.com/compose/install/) guide to do so. +- Docker and the Aztec toolchain installed via aztec-up (see the [getting started section](../../index.md)) +- Docker Compose ([installation guide](https://docs.docker.com/compose/install/)) +- Access to L1 node endpoints (execution and consensus clients). See [Eth Docker's guide](https://ethdocker.com/Usage/QuickStart) if you need to set these up. -Finally, this guide requires you to have endpoints of an L1 node stack of an execution and consensus client. If you do not have one set up, you can see a good guide on how to do that [here at Eth Docker](https://ethdocker.com/Usage/QuickStart). +## Configure the Sequencer +Setting up a sequencer involves configuring keys, environment variables, and Docker Compose. -## Configure the sequencer +### Setup Steps -There are a few important things to note when setting up a sequencer. This guide will guide you in setting up and running a sequencer with a standard setup using Docker compose with a .env file. +1. Define private keys and accounts for sequencer duties +2. Configure node settings via environment variables +3. Enable auto-update and auto-restart functionality +4. Deploy with Docker Compose -The setup of the sequencer has four important steps. +First, create the directory structure for sequencer data storage: -1. Define private keys / accounts used for sequencer duties -2. Set required node configuration -3. Ensure auto-update / auto-restart is enabled -4. Apply your Docker compose file - -Let's start by creating a new directory called `aztec-sequencer`, with two subdirectories, `keys`, and `data`. This is where all the information used by the sequencer will be stored. Please also create an empty `.env` file in `aztec-sequencer` to define your settings before moving on to the next step. +```sh +mkdir -p aztec-sequencer/keys aztec-sequencer/data +cd aztec-sequencer +touch .env +``` -### Define private keys / accounts +### Define Private Keys and Accounts -A sequencer must hold and use private keys identifying it as a valid proposer or attester. This is done by defining a keystore file. +Sequencers require private keys to identify themselves as valid proposers or attesters. Configure these through a keystore file. -An example keystore file is below. Copy this file and save it as `keystore.json` into your `aztec-sequencer/keys` folder. +Create a `keystore.json` file in your `aztec-sequencer/keys` folder: ```json { @@ -91,20 +96,18 @@ An example keystore file is below. Copy this file and save it as `keystore.json` } ``` -The keystore defines a few important keys and addresses for sequencer operation. They include but are not limited to: +The keystore defines keys and addresses for sequencer operation: -- `attester`: the private key of the sequencer, used for signing block proposals and attestations on block proposals produced by other sequencers. The corresponding Ethereum address of the private key is the identity of the sequencer. -- `publisher`: the private key of the Ethereum EOA used for sending the block proposal to L1. This defaults to the attester private key if not set. -- `coinbase`: the Ethereum address set in a block proposal. L1 rewards and fees are sent to this address. This falls back to the address derived by the attester private key if not set. -- `feeRecipient`: the Aztec Address of the fee recipient address when proposing blocks. The unburnt portion of the tx fees in a given block are sent to this address. +- `attester`: Private key for signing block proposals and attestations. The corresponding Ethereum address identifies the sequencer. +- `publisher`: Private key for sending block proposals to L1. Defaults to attester key if not set. +- `coinbase`: Ethereum address receiving L1 rewards and fees. Defaults to attester address if not set. +- `feeRecipient`: Aztec address receiving unburnt transaction fees from blocks. -Please set these values with the ones you want and save `keystore.json`. +Replace the placeholder values with your actual keys and addresses. -### Node configuration +### Node Configuration -Next you will need to define some environment variables that set important configuration for your node. - -These include: +Required environment variables: - `DATA_DIRECTORY`: the folder where the data of the sequencer is stored - `KEY_STORE_DIRECTORY`: can be a path to the file or directory where keystores are located. In our case it is the path to the folder containing the `keystore.json` file created above @@ -115,7 +118,7 @@ These include: - `P2P_PORT`: The port that P2P communication happens on - `AZTEC_PORT`: The port that the sequencer node API is exposed on -Please paste this sample `.env` file into the empty one currently residing in your `aztec-sequencer` folder. Please note that we are assuming you are using the default ports of 8080 for the sequencer itself, and 40400 for p2p connectivity. If this is not the case, please overwrite the defaults below. +Add the following to your `.env` file (using default ports 8080 and 40400): ```sh DATA_DIRECTORY=./data @@ -129,27 +132,23 @@ AZTEC_PORT=8080 ``` :::tip -Forward your ports. Your router must send UDP and TCP traffic on the port specified by `P2P_PORT` to your IP address on your local network. +You MUST forward ports for P2P connectivity. Configure your router to forward both UDP and TCP traffic on the port specified by `P2P_PORT` to your local IP address. -Running the command `curl ipv4.icanhazip.com` can retrieve your public IP address for you. +To find your public IP address, run: `curl ipv4.icanhazip.com` ::: -### Enable auto-update / auto-restart - -It is imperative that the built in auto-updating functionality of the sequencer is not disabled. The update-checker is a background module in the Aztec node that enables global coordination of updates. It allows the protocol team to: +### Enable Auto-Update and Auto-Restart -- Push configuration changes to all nodes -- Trigger shutdowns so that nodes can pull the latest image version -- Apply hot-fixes quickly -- Coordinate node resets after a governance upgrade, especially when a new canonical rollup is published to the Registry +The sequencer's auto-update functionality is critical for network coordination. This background module enables: -This module ensures that upgrades and fixes propagate smoothly without requiring manual intervention from every node operator. +- Configuration updates across all nodes +- Automated image updates via controlled shutdowns +- Rapid hot-fix deployment +- Coordinated resets after governance upgrades -Please ensure environment variables: +**Important**: Do NOT set `AUTO_UPDATE_URL` or `AUTO_UPDATE` environment variables. These must use their default values for proper operation. -`AUTO_UPDATE_URL` and `AUTO_UPDATE` remain unset, as to take their default values (which are the s3 bucket being used to host the update information, and `config-and-version` respectively). - -Because docker-compose does not respect pull policies on container restarts, to handle updates properly, add Watchtower to your stack by running: +Since Docker Compose doesn't respect pull policies on container restarts, install Watchtower for automatic updates: ```sh docker run -d \ @@ -158,9 +157,9 @@ docker run -d \ containrrr/watchtower ``` -### Applying your Docker compose file +### Deploy with Docker Compose -Now that you have done all the setup, create a Docker compose file named `compose.yml` in your `aztec-sequencer` directory and paste the below code into it. +Create a `docker-compose.yml` file in your `aztec-sequencer` directory: ```yaml services: @@ -175,21 +174,23 @@ services: - ${DATA_DIRECTORY}:/var/lib/data - ${KEY_STORE_DIRECTORY}:/var/lib/keystore environment: - KEY_STORE_DIRECTORY: /var/lib/keystore - DATA_DIRECTORY: /var/lib/data - LOG_LEVEL: ${LOG_LEVEL} - ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} - L1_CONSENSUS_HOST_URLS: ${L1_CONSENSUS_HOST_URLS} - P2P_IP: ${P2P_IP} - P2P_PORT: ${P2P_PORT} - AZTEC_PORT: ${AZTEC_PORT} - entrypoint: node /usr/src/yarn-project/aztec/dest/bin/index.js - command: >- + KEY_STORE_DIRECTORY: /var/lib/keystore + DATA_DIRECTORY: /var/lib/data + LOG_LEVEL: ${LOG_LEVEL} + ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} + L1_CONSENSUS_HOST_URLS: ${L1_CONSENSUS_HOST_URLS} + P2P_IP: ${P2P_IP} + P2P_PORT: ${P2P_PORT} + AZTEC_PORT: ${AZTEC_PORT} + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js start - --network testnet --node --archiver --sequencer + --network testnet networks: - aztec restart: always @@ -199,11 +200,19 @@ networks: name: aztec ``` -Please note that we are setting only the necessary configuration for running this sequencer. The full list of settings and flags can be explored here at the [cli reference](../../reference/cli_reference.md). A lot of these options are preset to defaults by the `--network` flag above. This downloads defaults for the specified network and applies them to the node. +**Note**: This configuration includes only essential settings. The `--network testnet` flag applies network-specific defaults. See the [CLI reference](../../reference/cli_reference.md) for all available options. -Now, you can run `docker compose up` inside your `aztec-sequencer` folder to start the sequencer! +Start the sequencer: -To check if your sequencer is currently synced, which may take a few minutes, run this command and compare its output to any of the Aztec block explorers. (See [Aztec Scan](https://aztecscan.xyz/) or [Aztec Explorer](https://aztecexplorer.xyz/)) +```sh +docker compose up -d +``` + +## Verification + +To verify your sequencer is running correctly: + +1. Check the current sync status (this may take a few minutes): ```sh curl -s -X POST -H 'Content-Type: application/json' \ @@ -211,8 +220,57 @@ curl -s -X POST -H 'Content-Type: application/json' \ http://localhost:8080 | jq -r ".result.proven.number" ``` -## Add yourself to the testnet sequencer set +Compare the output with block explorers like [Aztec Scan](https://aztecscan.xyz/) or [Aztec Explorer](https://aztecexplorer.xyz/). + +2. View sequencer logs: + +```sh +docker compose logs -f aztec-sequencer +``` + +3. Check node status: + +```sh +curl http://localhost:8080/status +``` + +## Troubleshooting + +### Common Issues + +**Port forwarding not working:** + +- Verify your external IP address matches the `P2P_IP` setting +- Check firewall rules on your router and local machine +- Test connectivity using: `nc -zv ` + +**Sequencer not syncing:** + +- Check L1 endpoint connectivity +- Verify both execution and consensus clients are fully synced +- Review logs for specific error messages + +**Keystore issues:** + +- Ensure keystore.json is properly formatted +- Verify private keys are valid Ethereum private keys +- Check file permissions on the keys directory + +**Docker issues:** + +- Ensure Docker and Docker Compose are up to date +- Check disk space availability +- Verify container has sufficient resources + +## Join the Sequencer Set + +After setting up your node, you must request to be added to the sequencer set. + +Complete the onboarding process at [testnet.aztec.network](https://testnet.aztec.network) using zkPassport. -After setting up your node you must explicitly request to be added to the sequencer set. +## Next Steps -To complete this final step you can now head to [testnet.aztec.network](https://testnet.aztec.network) and complete the onboarding flow there utilizing zkPassport! +- Monitor your sequencer's performance and attestation rate +- Join the [Aztec Discord](https://discord.gg/aztec) for operator support +- Review [Reacting to Upgrades](../../reference/reacting_to_upgrades.md) guide +- Consider implementing monitoring and alerting for production deployments diff --git a/docs/docs/the_aztec_network/guides/run_nodes/index.md b/docs/docs/the_aztec_network/guides/run_nodes/index.md index 8465befbfd62..59e8926f9623 100644 --- a/docs/docs/the_aztec_network/guides/run_nodes/index.md +++ b/docs/docs/the_aztec_network/guides/run_nodes/index.md @@ -13,7 +13,7 @@ description: Learn how to participate in the Aztec Network by running different

Run Aztec Sequencer Nodes

- Participate in the Aztec protocol as a sequencer that orders transactions in a block and proposed them to the L1. Runs on consumer hardware. + Participate in the Aztec protocol as a sequencer that orders transactions in blocks and proposes them to L1. Runs on consumer hardware. @@ -21,7 +21,7 @@ description: Learn how to participate in the Aztec Network by running different

Run Aztec Prover Nodes

- Participate in the Aztec protocol as a prover, proving the rollup integrity that is pivotal to the protocol. Runs on hardware fit for data centers. + Participate in the Aztec protocol as a prover, generating proofs that ensure rollup integrity. Requires high-performance hardware suitable for data centers.
diff --git a/docs/docs/the_aztec_network/index.md b/docs/docs/the_aztec_network/index.md index cd2ca16918a4..669f75a6ba33 100644 --- a/docs/docs/the_aztec_network/index.md +++ b/docs/docs/the_aztec_network/index.md @@ -93,14 +93,18 @@ mkdir aztec-node && cd ./aztec-node Next, set some required configuration options. This guide will use `custom_named` environment variables (e.g. `AZTEC_NODE_P2P_IP`) but this is not necessary; you can pass values directly into the command without specifying them as environment variables. The external IP address of the node, and the L1 RPC endpoints must be defined when starting a node. Also, configuration defining the network version should be set, as this will let the node define the other required protocol variables, like rollup address, registry address etc. Note that the specified RPC endpoints must support high throughput, otherwise the node will suffer degraded performance. ```console -# If the external IP of the machine the node is running on is unknown, it can be obtained by running `curl ifconfig.me`. -export AZTEC_NODE_P2P_IP=IP export AZTEC_NODE_NETWORK=testnet +export AZTEC_NODE_P2P_IP=IP export AZTEC_NODE_ETH_HOSTS= export AZTEC_NODE_CONSENSUS_HOSTS= ``` -Finally, the ports used by the node must be accessible to other Aztec nodes on the internet. This will require disabling the firewall for and / or forwarding these ports. The router must be able to send UDP and TCP traffic on port 40400 (unless the defaults were changed) to the node IP address on its local network. Failure to do so may result in the node not participating in p2p duties. +:::tip + +The ports used by the node must be accessible to other Aztec nodes on the internet. This will require disabling the firewall for and / or forwarding these ports. The router must be able to send UDP and TCP traffic on port 40400 (unless the defaults were changed) to the node IP address on its local network. Failure to do so may result in the node not participating in p2p duties. + +Running the command `curl ipv4.icanhazip.com` can retrieve your public IP address for you. +::: ## Run the node diff --git a/docs/docs/the_aztec_network/reference/reacting_to_upgrades.md b/docs/docs/the_aztec_network/reference/reacting_to_upgrades.md index b690fb938014..d272f1e69425 100644 --- a/docs/docs/the_aztec_network/reference/reacting_to_upgrades.md +++ b/docs/docs/the_aztec_network/reference/reacting_to_upgrades.md @@ -4,17 +4,89 @@ title: Reacting to Upgrades description: Learn how to react to upgrades on the Aztec network. --- -This is a guide for sequencer operators to understand how to react to protocol upgrades. -## Sequencers signal for governance upgrades +This guide helps sequencer operators understand and respond to protocol upgrades on the Aztec network. -To signal for governance upgrades, sequencers must set their `GOVERNANCE_PROPOSER_PAYLOAD` on their sequencer node to the address of a `payload`. This will register their signal with the GovernanceProposer contract. +## Overview -:::info -the `payload` is a contract on L1 that specifies the address of the new rollup contract to be upgraded to. The payloads to be voted on during testnet will be communicated to sequencers on the forum and on community channels like discord. -::: +Protocol upgrades on Aztec require coordination between sequencers to ensure smooth transitions. This process involves signaling support for upgrades and executing them once consensus is reached. + +## Signaling for Governance Upgrades + +Sequencers participate in governance by signaling support for proposed upgrades. -This signalling phase will pass once `N` sequencers in a round of `M` L2 blocks have signalled for the same payload. Once the quorum is met, anyone can call the `executeProposal(roundNumber)` function on the Governance Proposer contract to advance the upgrade into the next stage. +### How to Signal + +Set the `GOVERNANCE_PROPOSER_PAYLOAD` environment variable on your sequencer node to the address of the proposed `payload` contract. This registers your support with the GovernanceProposer contract. + +```sh +# Example: Set the governance payload in your environment +export GOVERNANCE_PROPOSER_PAYLOAD= + +# Restart your sequencer to apply the change +docker compose restart aztec-sequencer +``` :::info -The `N` and `M` are public variables on the Governance Proposer contract, and can be read by anyone (i.e. using a `cast call`). To get the round number, you can call the `computeRound(slotNumber)` on the Governance Proposer contract. +The `payload` is an L1 contract specifying the new rollup contract address for the upgrade. Payloads for voting during alpha-testnet are communicated through official channels including the forum and Discord. ::: + +### Quorum Requirements + +The signaling phase completes when: + +- `N` sequencers signal for the same payload +- Within a round of `M` L2 blocks + +Once quorum is reached, anyone can execute the proposal by calling `executeProposal(roundNumber)` on the Governance Proposer contract. + +## Monitoring Upgrades + +Stay informed about upcoming upgrades: + +1. **Monitor official channels:** + + - Aztec forum for formal proposals + - Discord for discussions and announcements + - GitHub for technical details + +2. **Check upgrade status:** + - Query the Governance Proposer contract for active proposals + - Monitor signaling progress toward quorum + - Track execution status + +## Post-Upgrade Actions + +After an upgrade executes: + +1. **Verify your node updates automatically** - The auto-update module should handle this +2. **Monitor logs** for any issues during the transition +3. **Confirm your sequencer reconnects** to the network successfully +4. **Resume normal operations** once synchronized + +## Troubleshooting + +### Common Issues + +**Node not updating after upgrade:** + +- Verify auto-update is enabled (check `AUTO_UPDATE` is not set) +- Ensure Watchtower is running for automatic container updates +- Manually pull latest image if needed: `docker pull aztecprotocol/aztec:latest` + +**Sequencer not reconnecting:** + +- Check network configuration matches new requirements +- Review logs for connection errors +- Verify L1 endpoints are accessible + +**Missing governance signals:** + +- Confirm `GOVERNANCE_PROPOSER_PAYLOAD` is set correctly +- Restart sequencer after setting environment variable +- Verify transaction was sent to L1 + +## Next Steps + +- Join the [governance forum](https://forum.aztec.network) to participate in discussions +- Review the [Sequencer Guide](../guides/run_nodes/how_to_run_sequencer.md) for setup details +- Monitor the [Aztec Discord](https://discord.gg/aztec) for real-time updates diff --git a/docs/versioned_docs/version-v1.2.0/the_aztec_network/guides/run_nodes/how_to_run_prover.md b/docs/versioned_docs/version-v1.2.0/the_aztec_network/guides/run_nodes/how_to_run_prover.md index 9d4125a27ee6..e68abd8ddfd7 100644 --- a/docs/versioned_docs/version-v1.2.0/the_aztec_network/guides/run_nodes/how_to_run_prover.md +++ b/docs/versioned_docs/version-v1.2.0/the_aztec_network/guides/run_nodes/how_to_run_prover.md @@ -161,12 +161,13 @@ Required environment variables: - `PROVER_BROKER_HOST`: Broker endpoint for job submission - `PROVER_ID`: Ethereum address corresponding to `PROVER_PUBLISHER_PRIVATE_KEY` +**Note**: Some variables overlap with the prover node configuration. In this case we use the same value for `PROVER_BROKER_HOST`, so we will not duplicate it in our `.env` file. + Add to your `.env` file: ```sh PROVER_AGENT_COUNT=10 PROVER_AGENT_POLL_INTERVAL_MS=10000 -PROVER_BROKER_HOST=http://prover-broker:8080 PROVER_ID= ``` @@ -199,15 +200,14 @@ name: aztec-prover services: prover-node: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-node - - --archiver - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-node + --archiver + --network testnet depends_on: prover-broker: condition: service_started @@ -219,6 +219,7 @@ services: LOG_LEVEL: ${LOG_LEVEL} PROVER_BROKER_HOST: ${PROVER_BROKER_HOST} PROVER_PUBLISHER_PRIVATE_KEY: ${PROVER_PUBLISHER_PRIVATE_KEY} + P2P_IP: ${P2P_IP} P2P_PORT: ${P2P_PORT} AZTEC_PORT: ${AZTEC_PORT} ports: @@ -230,14 +231,13 @@ services: prover-broker: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-broker - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-broker + --network testnet environment: DATA_DIRECTORY: /var/lib/data ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} @@ -248,14 +248,13 @@ services: prover-agent: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-agent - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-agent + --network testnet environment: PROVER_AGENT_COUNT: ${PROVER_AGENT_COUNT} PROVER_AGENT_POLL_INTERVAL_MS: ${PROVER_AGENT_POLL_INTERVAL_MS} diff --git a/docs/versioned_docs/version-v1.2.0/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md b/docs/versioned_docs/version-v1.2.0/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md index a98c8bf9f25b..753258667d1b 100644 --- a/docs/versioned_docs/version-v1.2.0/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md +++ b/docs/versioned_docs/version-v1.2.0/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md @@ -24,17 +24,17 @@ tags: ## Background -This guide covers the steps required to run a sequencer node on Aztec. It will also provide context to ensure users are comfortable with the steps they are taking. +This guide covers the steps required to run a sequencer node on the Aztec network. The Aztec sequencer node is critical infrastructure responsible for ordering transactions and producing blocks. -The sequencer node takes part in three key actions: +The sequencer node performs three key actions: -1. Assemble unprocessed transactions and propose the next block -2. Attest to correct execution of txs in the proposed block (if part of the sequencer committee) -3. Submit the successfully attested block to L1 +1. Assembles unprocessed transactions and proposes the next block +2. Attests to correct execution of transactions in proposed blocks (when part of the sequencer committee) +3. Submits successfully attested blocks to L1 -When transactions are sent to the Aztec network, sequencer nodes bundle them into blocks, checking various constraints such as gas limits, block size, and transaction validity. Before a block can be published, it must be validated by a committee of other sequencer nodes who re-execute public transactions and verify private function proofs so they can attest to correct execution. These sequencers attest to the block's validity by signing the block header, and once enough attestations are collected (two-thirds of the committee plus one), the sequencer can submit the block to L1. +Sequencer nodes bundle transactions into blocks while checking constraints like gas limits, block size, and validity. Before publication, blocks must be validated by a committee of sequencer nodes who re-execute public transactions and verify private function proofs. Committee members attest to validity by signing the block header. Once sufficient attestations are collected (two-thirds of the committee plus one), the block can be submitted to L1. The archiver component complements this process by maintaining historical chain data. It continuously monitors L1 for new blocks, processes them, and maintains a synchronized view of the chain state. This includes managing contract data, transaction logs, and L1-to-L2 messages, making it essential for network synchronization and data availability. @@ -49,33 +49,38 @@ Minimum hardware requirements: Please note that these requirements are subject to change as the network throughput increases. -This guide expects you to be using a "standard" Linux distribution like Debian / Ubuntu when following along with the steps. +This guide assumes you are using a standard Linux distribution (Debian or Ubuntu). -It also is assumed that you have installed Docker and the aztec toolchain via aztec-up as described in the [getting started section](../../index.md). +### Required Software -Furthermore, as this guide uses Docker compose, you will need to install it. Please follow [this](https://docs.docker.com/compose/install/) guide to do so. +- Docker and the Aztec toolchain installed via aztec-up (see the [getting started section](../../index.md)) +- Docker Compose ([installation guide](https://docs.docker.com/compose/install/)) +- Access to L1 node endpoints (execution and consensus clients). See [Eth Docker's guide](https://ethdocker.com/Usage/QuickStart) if you need to set these up. -Finally, this guide requires you to have endpoints of an L1 node stack of an execution and consensus client. If you do not have one set up, you can see a good guide on how to do that [here at Eth Docker](https://ethdocker.com/Usage/QuickStart). +## Configure the Sequencer +Setting up a sequencer involves configuring keys, environment variables, and Docker Compose. -## Configure the sequencer +### Setup Steps -There are a few important things to note when setting up a sequencer. This guide will guide you in setting up and running a sequencer with a standard setup using Docker compose with a .env file. +1. Define private keys and accounts for sequencer duties +2. Configure node settings via environment variables +3. Enable auto-update and auto-restart functionality +4. Deploy with Docker Compose -The setup of the sequencer has four important steps. +First, create the directory structure for sequencer data storage: -1. Define private keys / accounts used for sequencer duties -2. Set required node configuration -3. Ensure auto-update / auto-restart is enabled -4. Apply your Docker compose file - -Let's start by creating a new directory called `aztec-sequencer`, with two subdirectories, `keys`, and `data`. This is where all the information used by the sequencer will be stored. Please also create an empty `.env` file in `aztec-sequencer` to define your settings before moving on to the next step. +```sh +mkdir -p aztec-sequencer/keys aztec-sequencer/data +cd aztec-sequencer +touch .env +``` -### Define private keys / accounts +### Define Private Keys and Accounts -A sequencer must hold and use private keys identifying it as a valid proposer or attester. This is done by defining a keystore file. +Sequencers require private keys to identify themselves as valid proposers or attesters. Configure these through a keystore file. -An example keystore file is below. Copy this file and save it as `keystore.json` into your `aztec-sequencer/keys` folder. +Create a `keystore.json` file in your `aztec-sequencer/keys` folder: ```json { @@ -91,20 +96,18 @@ An example keystore file is below. Copy this file and save it as `keystore.json` } ``` -The keystore defines a few important keys and addresses for sequencer operation. They include but are not limited to: +The keystore defines keys and addresses for sequencer operation: -- `attester`: the private key of the sequencer, used for signing block proposals and attestations on block proposals produced by other sequencers. The corresponding Ethereum address of the private key is the identity of the sequencer. -- `publisher`: the private key of the Ethereum EOA used for sending the block proposal to L1. This defaults to the attester private key if not set. -- `coinbase`: the Ethereum address set in a block proposal. L1 rewards and fees are sent to this address. This falls back to the address derived by the attester private key if not set. -- `feeRecipient`: the Aztec Address of the fee recipient address when proposing blocks. The unburnt portion of the tx fees in a given block are sent to this address. +- `attester`: Private key for signing block proposals and attestations. The corresponding Ethereum address identifies the sequencer. +- `publisher`: Private key for sending block proposals to L1. Defaults to attester key if not set. +- `coinbase`: Ethereum address receiving L1 rewards and fees. Defaults to attester address if not set. +- `feeRecipient`: Aztec address receiving unburnt transaction fees from blocks. -Please set these values with the ones you want and save `keystore.json`. +Replace the placeholder values with your actual keys and addresses. -### Node configuration +### Node Configuration -Next you will need to define some environment variables that set important configuration for your node. - -These include: +Required environment variables: - `DATA_DIRECTORY`: the folder where the data of the sequencer is stored - `KEY_STORE_DIRECTORY`: can be a path to the file or directory where keystores are located. In our case it is the path to the folder containing the `keystore.json` file created above @@ -115,7 +118,7 @@ These include: - `P2P_PORT`: The port that P2P communication happens on - `AZTEC_PORT`: The port that the sequencer node API is exposed on -Please paste this sample `.env` file into the empty one currently residing in your `aztec-sequencer` folder. Please note that we are assuming you are using the default ports of 8080 for the sequencer itself, and 40400 for p2p connectivity. If this is not the case, please overwrite the defaults below. +Add the following to your `.env` file (using default ports 8080 and 40400): ```sh DATA_DIRECTORY=./data @@ -129,27 +132,23 @@ AZTEC_PORT=8080 ``` :::tip -Forward your ports. Your router must send UDP and TCP traffic on the port specified by `P2P_PORT` to your IP address on your local network. +You MUST forward ports for P2P connectivity. Configure your router to forward both UDP and TCP traffic on the port specified by `P2P_PORT` to your local IP address. -Running the command `curl ipv4.icanhazip.com` can retrieve your public IP address for you. +To find your public IP address, run: `curl ipv4.icanhazip.com` ::: -### Enable auto-update / auto-restart - -It is imperative that the built in auto-updating functionality of the sequencer is not disabled. The update-checker is a background module in the Aztec node that enables global coordination of updates. It allows the protocol team to: +### Enable Auto-Update and Auto-Restart -- Push configuration changes to all nodes -- Trigger shutdowns so that nodes can pull the latest image version -- Apply hot-fixes quickly -- Coordinate node resets after a governance upgrade, especially when a new canonical rollup is published to the Registry +The sequencer's auto-update functionality is critical for network coordination. This background module enables: -This module ensures that upgrades and fixes propagate smoothly without requiring manual intervention from every node operator. +- Configuration updates across all nodes +- Automated image updates via controlled shutdowns +- Rapid hot-fix deployment +- Coordinated resets after governance upgrades -Please ensure environment variables: +**Important**: Do NOT set `AUTO_UPDATE_URL` or `AUTO_UPDATE` environment variables. These must use their default values for proper operation. -`AUTO_UPDATE_URL` and `AUTO_UPDATE` remain unset, as to take their default values (which are the s3 bucket being used to host the update information, and `config-and-version` respectively). - -Because docker-compose does not respect pull policies on container restarts, to handle updates properly, add Watchtower to your stack by running: +Since Docker Compose doesn't respect pull policies on container restarts, install Watchtower for automatic updates: ```sh docker run -d \ @@ -158,9 +157,9 @@ docker run -d \ containrrr/watchtower ``` -### Applying your Docker compose file +### Deploy with Docker Compose -Now that you have done all the setup, create a Docker compose file named `compose.yml` in your `aztec-sequencer` directory and paste the below code into it. +Create a `docker-compose.yml` file in your `aztec-sequencer` directory: ```yaml services: @@ -175,21 +174,23 @@ services: - ${DATA_DIRECTORY}:/var/lib/data - ${KEY_STORE_DIRECTORY}:/var/lib/keystore environment: - KEY_STORE_DIRECTORY: /var/lib/keystore - DATA_DIRECTORY: /var/lib/data - LOG_LEVEL: ${LOG_LEVEL} - ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} - L1_CONSENSUS_HOST_URLS: ${L1_CONSENSUS_HOST_URLS} - P2P_IP: ${P2P_IP} - P2P_PORT: ${P2P_PORT} - AZTEC_PORT: ${AZTEC_PORT} - entrypoint: node /usr/src/yarn-project/aztec/dest/bin/index.js - command: >- + KEY_STORE_DIRECTORY: /var/lib/keystore + DATA_DIRECTORY: /var/lib/data + LOG_LEVEL: ${LOG_LEVEL} + ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} + L1_CONSENSUS_HOST_URLS: ${L1_CONSENSUS_HOST_URLS} + P2P_IP: ${P2P_IP} + P2P_PORT: ${P2P_PORT} + AZTEC_PORT: ${AZTEC_PORT} + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js start - --network testnet --node --archiver --sequencer + --network testnet networks: - aztec restart: always @@ -199,11 +200,19 @@ networks: name: aztec ``` -Please note that we are setting only the necessary configuration for running this sequencer. The full list of settings and flags can be explored here at the [cli reference](../../reference/cli_reference.md). A lot of these options are preset to defaults by the `--network` flag above. This downloads defaults for the specified network and applies them to the node. +**Note**: This configuration includes only essential settings. The `--network testnet` flag applies network-specific defaults. See the [CLI reference](../../reference/cli_reference.md) for all available options. -Now, you can run `docker compose up` inside your `aztec-sequencer` folder to start the sequencer! +Start the sequencer: -To check if your sequencer is currently synced, which may take a few minutes, run this command and compare its output to any of the Aztec block explorers. (See [Aztec Scan](https://aztecscan.xyz/) or [Aztec Explorer](https://aztecexplorer.xyz/)) +```sh +docker compose up -d +``` + +## Verification + +To verify your sequencer is running correctly: + +1. Check the current sync status (this may take a few minutes): ```sh curl -s -X POST -H 'Content-Type: application/json' \ @@ -211,8 +220,57 @@ curl -s -X POST -H 'Content-Type: application/json' \ http://localhost:8080 | jq -r ".result.proven.number" ``` -## Add yourself to the testnet sequencer set +Compare the output with block explorers like [Aztec Scan](https://aztecscan.xyz/) or [Aztec Explorer](https://aztecexplorer.xyz/). + +2. View sequencer logs: + +```sh +docker compose logs -f aztec-sequencer +``` + +3. Check node status: + +```sh +curl http://localhost:8080/status +``` + +## Troubleshooting + +### Common Issues + +**Port forwarding not working:** + +- Verify your external IP address matches the `P2P_IP` setting +- Check firewall rules on your router and local machine +- Test connectivity using: `nc -zv ` + +**Sequencer not syncing:** + +- Check L1 endpoint connectivity +- Verify both execution and consensus clients are fully synced +- Review logs for specific error messages + +**Keystore issues:** + +- Ensure keystore.json is properly formatted +- Verify private keys are valid Ethereum private keys +- Check file permissions on the keys directory + +**Docker issues:** + +- Ensure Docker and Docker Compose are up to date +- Check disk space availability +- Verify container has sufficient resources + +## Join the Sequencer Set + +After setting up your node, you must request to be added to the sequencer set. + +Complete the onboarding process at [testnet.aztec.network](https://testnet.aztec.network) using zkPassport. -After setting up your node you must explicitly request to be added to the sequencer set. +## Next Steps -To complete this final step you can now head to [testnet.aztec.network](https://testnet.aztec.network) and complete the onboarding flow there utilizing zkPassport! +- Monitor your sequencer's performance and attestation rate +- Join the [Aztec Discord](https://discord.gg/aztec) for operator support +- Review [Reacting to Upgrades](../../reference/reacting_to_upgrades.md) guide +- Consider implementing monitoring and alerting for production deployments diff --git a/docs/versioned_docs/version-v1.2.0/the_aztec_network/index.md b/docs/versioned_docs/version-v1.2.0/the_aztec_network/index.md index 2a193d2736e0..9e15f5f3853e 100644 --- a/docs/versioned_docs/version-v1.2.0/the_aztec_network/index.md +++ b/docs/versioned_docs/version-v1.2.0/the_aztec_network/index.md @@ -93,14 +93,18 @@ mkdir aztec-node && cd ./aztec-node Next, set some required configuration options. This guide will use `custom_named` environment variables (e.g. `AZTEC_NODE_P2P_IP`) but this is not necessary; you can pass values directly into the command without specifying them as environment variables. The external IP address of the node, and the L1 RPC endpoints must be defined when starting a node. Also, configuration defining the network version should be set, as this will let the node define the other required protocol variables, like rollup address, registry address etc. Note that the specified RPC endpoints must support high throughput, otherwise the node will suffer degraded performance. ```console -# If the external IP of the machine the node is running on is unknown, it can be obtained by running `curl ifconfig.me`. -export AZTEC_NODE_P2P_IP=IP export AZTEC_NODE_NETWORK=testnet +export AZTEC_NODE_P2P_IP=IP export AZTEC_NODE_ETH_HOSTS= export AZTEC_NODE_CONSENSUS_HOSTS= ``` -Finally, the ports used by the node must be accessible to other Aztec nodes on the internet. This will require disabling the firewall for and / or forwarding these ports. The router must be able to send UDP and TCP traffic on port 40400 (unless the defaults were changed) to the node IP address on its local network. Failure to do so may result in the node not participating in p2p duties. +:::tip + +The ports used by the node must be accessible to other Aztec nodes on the internet. This will require disabling the firewall for and / or forwarding these ports. The router must be able to send UDP and TCP traffic on port 40400 (unless the defaults were changed) to the node IP address on its local network. Failure to do so may result in the node not participating in p2p duties. + +Running the command `curl ipv4.icanhazip.com` can retrieve your public IP address for you. +::: ## Run the node diff --git a/docs/versioned_docs/version-v2.0.2/the_aztec_network/guides/run_nodes/how_to_run_prover.md b/docs/versioned_docs/version-v2.0.2/the_aztec_network/guides/run_nodes/how_to_run_prover.md index 9d4125a27ee6..e68abd8ddfd7 100644 --- a/docs/versioned_docs/version-v2.0.2/the_aztec_network/guides/run_nodes/how_to_run_prover.md +++ b/docs/versioned_docs/version-v2.0.2/the_aztec_network/guides/run_nodes/how_to_run_prover.md @@ -161,12 +161,13 @@ Required environment variables: - `PROVER_BROKER_HOST`: Broker endpoint for job submission - `PROVER_ID`: Ethereum address corresponding to `PROVER_PUBLISHER_PRIVATE_KEY` +**Note**: Some variables overlap with the prover node configuration. In this case we use the same value for `PROVER_BROKER_HOST`, so we will not duplicate it in our `.env` file. + Add to your `.env` file: ```sh PROVER_AGENT_COUNT=10 PROVER_AGENT_POLL_INTERVAL_MS=10000 -PROVER_BROKER_HOST=http://prover-broker:8080 PROVER_ID= ``` @@ -199,15 +200,14 @@ name: aztec-prover services: prover-node: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-node - - --archiver - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-node + --archiver + --network testnet depends_on: prover-broker: condition: service_started @@ -219,6 +219,7 @@ services: LOG_LEVEL: ${LOG_LEVEL} PROVER_BROKER_HOST: ${PROVER_BROKER_HOST} PROVER_PUBLISHER_PRIVATE_KEY: ${PROVER_PUBLISHER_PRIVATE_KEY} + P2P_IP: ${P2P_IP} P2P_PORT: ${P2P_PORT} AZTEC_PORT: ${AZTEC_PORT} ports: @@ -230,14 +231,13 @@ services: prover-broker: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-broker - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-broker + --network testnet environment: DATA_DIRECTORY: /var/lib/data ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} @@ -248,14 +248,13 @@ services: prover-agent: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-agent - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-agent + --network testnet environment: PROVER_AGENT_COUNT: ${PROVER_AGENT_COUNT} PROVER_AGENT_POLL_INTERVAL_MS: ${PROVER_AGENT_POLL_INTERVAL_MS} diff --git a/docs/versioned_docs/version-v2.0.2/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md b/docs/versioned_docs/version-v2.0.2/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md index a98c8bf9f25b..753258667d1b 100644 --- a/docs/versioned_docs/version-v2.0.2/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md +++ b/docs/versioned_docs/version-v2.0.2/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md @@ -24,17 +24,17 @@ tags: ## Background -This guide covers the steps required to run a sequencer node on Aztec. It will also provide context to ensure users are comfortable with the steps they are taking. +This guide covers the steps required to run a sequencer node on the Aztec network. The Aztec sequencer node is critical infrastructure responsible for ordering transactions and producing blocks. -The sequencer node takes part in three key actions: +The sequencer node performs three key actions: -1. Assemble unprocessed transactions and propose the next block -2. Attest to correct execution of txs in the proposed block (if part of the sequencer committee) -3. Submit the successfully attested block to L1 +1. Assembles unprocessed transactions and proposes the next block +2. Attests to correct execution of transactions in proposed blocks (when part of the sequencer committee) +3. Submits successfully attested blocks to L1 -When transactions are sent to the Aztec network, sequencer nodes bundle them into blocks, checking various constraints such as gas limits, block size, and transaction validity. Before a block can be published, it must be validated by a committee of other sequencer nodes who re-execute public transactions and verify private function proofs so they can attest to correct execution. These sequencers attest to the block's validity by signing the block header, and once enough attestations are collected (two-thirds of the committee plus one), the sequencer can submit the block to L1. +Sequencer nodes bundle transactions into blocks while checking constraints like gas limits, block size, and validity. Before publication, blocks must be validated by a committee of sequencer nodes who re-execute public transactions and verify private function proofs. Committee members attest to validity by signing the block header. Once sufficient attestations are collected (two-thirds of the committee plus one), the block can be submitted to L1. The archiver component complements this process by maintaining historical chain data. It continuously monitors L1 for new blocks, processes them, and maintains a synchronized view of the chain state. This includes managing contract data, transaction logs, and L1-to-L2 messages, making it essential for network synchronization and data availability. @@ -49,33 +49,38 @@ Minimum hardware requirements: Please note that these requirements are subject to change as the network throughput increases. -This guide expects you to be using a "standard" Linux distribution like Debian / Ubuntu when following along with the steps. +This guide assumes you are using a standard Linux distribution (Debian or Ubuntu). -It also is assumed that you have installed Docker and the aztec toolchain via aztec-up as described in the [getting started section](../../index.md). +### Required Software -Furthermore, as this guide uses Docker compose, you will need to install it. Please follow [this](https://docs.docker.com/compose/install/) guide to do so. +- Docker and the Aztec toolchain installed via aztec-up (see the [getting started section](../../index.md)) +- Docker Compose ([installation guide](https://docs.docker.com/compose/install/)) +- Access to L1 node endpoints (execution and consensus clients). See [Eth Docker's guide](https://ethdocker.com/Usage/QuickStart) if you need to set these up. -Finally, this guide requires you to have endpoints of an L1 node stack of an execution and consensus client. If you do not have one set up, you can see a good guide on how to do that [here at Eth Docker](https://ethdocker.com/Usage/QuickStart). +## Configure the Sequencer +Setting up a sequencer involves configuring keys, environment variables, and Docker Compose. -## Configure the sequencer +### Setup Steps -There are a few important things to note when setting up a sequencer. This guide will guide you in setting up and running a sequencer with a standard setup using Docker compose with a .env file. +1. Define private keys and accounts for sequencer duties +2. Configure node settings via environment variables +3. Enable auto-update and auto-restart functionality +4. Deploy with Docker Compose -The setup of the sequencer has four important steps. +First, create the directory structure for sequencer data storage: -1. Define private keys / accounts used for sequencer duties -2. Set required node configuration -3. Ensure auto-update / auto-restart is enabled -4. Apply your Docker compose file - -Let's start by creating a new directory called `aztec-sequencer`, with two subdirectories, `keys`, and `data`. This is where all the information used by the sequencer will be stored. Please also create an empty `.env` file in `aztec-sequencer` to define your settings before moving on to the next step. +```sh +mkdir -p aztec-sequencer/keys aztec-sequencer/data +cd aztec-sequencer +touch .env +``` -### Define private keys / accounts +### Define Private Keys and Accounts -A sequencer must hold and use private keys identifying it as a valid proposer or attester. This is done by defining a keystore file. +Sequencers require private keys to identify themselves as valid proposers or attesters. Configure these through a keystore file. -An example keystore file is below. Copy this file and save it as `keystore.json` into your `aztec-sequencer/keys` folder. +Create a `keystore.json` file in your `aztec-sequencer/keys` folder: ```json { @@ -91,20 +96,18 @@ An example keystore file is below. Copy this file and save it as `keystore.json` } ``` -The keystore defines a few important keys and addresses for sequencer operation. They include but are not limited to: +The keystore defines keys and addresses for sequencer operation: -- `attester`: the private key of the sequencer, used for signing block proposals and attestations on block proposals produced by other sequencers. The corresponding Ethereum address of the private key is the identity of the sequencer. -- `publisher`: the private key of the Ethereum EOA used for sending the block proposal to L1. This defaults to the attester private key if not set. -- `coinbase`: the Ethereum address set in a block proposal. L1 rewards and fees are sent to this address. This falls back to the address derived by the attester private key if not set. -- `feeRecipient`: the Aztec Address of the fee recipient address when proposing blocks. The unburnt portion of the tx fees in a given block are sent to this address. +- `attester`: Private key for signing block proposals and attestations. The corresponding Ethereum address identifies the sequencer. +- `publisher`: Private key for sending block proposals to L1. Defaults to attester key if not set. +- `coinbase`: Ethereum address receiving L1 rewards and fees. Defaults to attester address if not set. +- `feeRecipient`: Aztec address receiving unburnt transaction fees from blocks. -Please set these values with the ones you want and save `keystore.json`. +Replace the placeholder values with your actual keys and addresses. -### Node configuration +### Node Configuration -Next you will need to define some environment variables that set important configuration for your node. - -These include: +Required environment variables: - `DATA_DIRECTORY`: the folder where the data of the sequencer is stored - `KEY_STORE_DIRECTORY`: can be a path to the file or directory where keystores are located. In our case it is the path to the folder containing the `keystore.json` file created above @@ -115,7 +118,7 @@ These include: - `P2P_PORT`: The port that P2P communication happens on - `AZTEC_PORT`: The port that the sequencer node API is exposed on -Please paste this sample `.env` file into the empty one currently residing in your `aztec-sequencer` folder. Please note that we are assuming you are using the default ports of 8080 for the sequencer itself, and 40400 for p2p connectivity. If this is not the case, please overwrite the defaults below. +Add the following to your `.env` file (using default ports 8080 and 40400): ```sh DATA_DIRECTORY=./data @@ -129,27 +132,23 @@ AZTEC_PORT=8080 ``` :::tip -Forward your ports. Your router must send UDP and TCP traffic on the port specified by `P2P_PORT` to your IP address on your local network. +You MUST forward ports for P2P connectivity. Configure your router to forward both UDP and TCP traffic on the port specified by `P2P_PORT` to your local IP address. -Running the command `curl ipv4.icanhazip.com` can retrieve your public IP address for you. +To find your public IP address, run: `curl ipv4.icanhazip.com` ::: -### Enable auto-update / auto-restart - -It is imperative that the built in auto-updating functionality of the sequencer is not disabled. The update-checker is a background module in the Aztec node that enables global coordination of updates. It allows the protocol team to: +### Enable Auto-Update and Auto-Restart -- Push configuration changes to all nodes -- Trigger shutdowns so that nodes can pull the latest image version -- Apply hot-fixes quickly -- Coordinate node resets after a governance upgrade, especially when a new canonical rollup is published to the Registry +The sequencer's auto-update functionality is critical for network coordination. This background module enables: -This module ensures that upgrades and fixes propagate smoothly without requiring manual intervention from every node operator. +- Configuration updates across all nodes +- Automated image updates via controlled shutdowns +- Rapid hot-fix deployment +- Coordinated resets after governance upgrades -Please ensure environment variables: +**Important**: Do NOT set `AUTO_UPDATE_URL` or `AUTO_UPDATE` environment variables. These must use their default values for proper operation. -`AUTO_UPDATE_URL` and `AUTO_UPDATE` remain unset, as to take their default values (which are the s3 bucket being used to host the update information, and `config-and-version` respectively). - -Because docker-compose does not respect pull policies on container restarts, to handle updates properly, add Watchtower to your stack by running: +Since Docker Compose doesn't respect pull policies on container restarts, install Watchtower for automatic updates: ```sh docker run -d \ @@ -158,9 +157,9 @@ docker run -d \ containrrr/watchtower ``` -### Applying your Docker compose file +### Deploy with Docker Compose -Now that you have done all the setup, create a Docker compose file named `compose.yml` in your `aztec-sequencer` directory and paste the below code into it. +Create a `docker-compose.yml` file in your `aztec-sequencer` directory: ```yaml services: @@ -175,21 +174,23 @@ services: - ${DATA_DIRECTORY}:/var/lib/data - ${KEY_STORE_DIRECTORY}:/var/lib/keystore environment: - KEY_STORE_DIRECTORY: /var/lib/keystore - DATA_DIRECTORY: /var/lib/data - LOG_LEVEL: ${LOG_LEVEL} - ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} - L1_CONSENSUS_HOST_URLS: ${L1_CONSENSUS_HOST_URLS} - P2P_IP: ${P2P_IP} - P2P_PORT: ${P2P_PORT} - AZTEC_PORT: ${AZTEC_PORT} - entrypoint: node /usr/src/yarn-project/aztec/dest/bin/index.js - command: >- + KEY_STORE_DIRECTORY: /var/lib/keystore + DATA_DIRECTORY: /var/lib/data + LOG_LEVEL: ${LOG_LEVEL} + ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} + L1_CONSENSUS_HOST_URLS: ${L1_CONSENSUS_HOST_URLS} + P2P_IP: ${P2P_IP} + P2P_PORT: ${P2P_PORT} + AZTEC_PORT: ${AZTEC_PORT} + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js start - --network testnet --node --archiver --sequencer + --network testnet networks: - aztec restart: always @@ -199,11 +200,19 @@ networks: name: aztec ``` -Please note that we are setting only the necessary configuration for running this sequencer. The full list of settings and flags can be explored here at the [cli reference](../../reference/cli_reference.md). A lot of these options are preset to defaults by the `--network` flag above. This downloads defaults for the specified network and applies them to the node. +**Note**: This configuration includes only essential settings. The `--network testnet` flag applies network-specific defaults. See the [CLI reference](../../reference/cli_reference.md) for all available options. -Now, you can run `docker compose up` inside your `aztec-sequencer` folder to start the sequencer! +Start the sequencer: -To check if your sequencer is currently synced, which may take a few minutes, run this command and compare its output to any of the Aztec block explorers. (See [Aztec Scan](https://aztecscan.xyz/) or [Aztec Explorer](https://aztecexplorer.xyz/)) +```sh +docker compose up -d +``` + +## Verification + +To verify your sequencer is running correctly: + +1. Check the current sync status (this may take a few minutes): ```sh curl -s -X POST -H 'Content-Type: application/json' \ @@ -211,8 +220,57 @@ curl -s -X POST -H 'Content-Type: application/json' \ http://localhost:8080 | jq -r ".result.proven.number" ``` -## Add yourself to the testnet sequencer set +Compare the output with block explorers like [Aztec Scan](https://aztecscan.xyz/) or [Aztec Explorer](https://aztecexplorer.xyz/). + +2. View sequencer logs: + +```sh +docker compose logs -f aztec-sequencer +``` + +3. Check node status: + +```sh +curl http://localhost:8080/status +``` + +## Troubleshooting + +### Common Issues + +**Port forwarding not working:** + +- Verify your external IP address matches the `P2P_IP` setting +- Check firewall rules on your router and local machine +- Test connectivity using: `nc -zv ` + +**Sequencer not syncing:** + +- Check L1 endpoint connectivity +- Verify both execution and consensus clients are fully synced +- Review logs for specific error messages + +**Keystore issues:** + +- Ensure keystore.json is properly formatted +- Verify private keys are valid Ethereum private keys +- Check file permissions on the keys directory + +**Docker issues:** + +- Ensure Docker and Docker Compose are up to date +- Check disk space availability +- Verify container has sufficient resources + +## Join the Sequencer Set + +After setting up your node, you must request to be added to the sequencer set. + +Complete the onboarding process at [testnet.aztec.network](https://testnet.aztec.network) using zkPassport. -After setting up your node you must explicitly request to be added to the sequencer set. +## Next Steps -To complete this final step you can now head to [testnet.aztec.network](https://testnet.aztec.network) and complete the onboarding flow there utilizing zkPassport! +- Monitor your sequencer's performance and attestation rate +- Join the [Aztec Discord](https://discord.gg/aztec) for operator support +- Review [Reacting to Upgrades](../../reference/reacting_to_upgrades.md) guide +- Consider implementing monitoring and alerting for production deployments diff --git a/docs/versioned_docs/version-v2.0.2/the_aztec_network/index.md b/docs/versioned_docs/version-v2.0.2/the_aztec_network/index.md index 28eb1ff2dac0..118183cd71a3 100644 --- a/docs/versioned_docs/version-v2.0.2/the_aztec_network/index.md +++ b/docs/versioned_docs/version-v2.0.2/the_aztec_network/index.md @@ -5,6 +5,8 @@ title: Running a Full Node description: A guide about how to run a full node on the Aztec network. --- +## Background + This guide will go over the steps required to run a full node on Aztec with a basic setup. A full node allows users to connect and interact with the network. It provides users an interface to send and receive transactions and state updates without relying on a third party. @@ -18,24 +20,24 @@ Please note that there are two other types of nodes available that we are not co Minimum hardware requirements: - 2 core / 4 vCPU -- 8 GB RAM -- 10 GB SDD +- 16 GB RAM +- 1 TB NVMe SDD - 25 Mbps network connection Please note that these requirements are subject to change as the network throughput increases. -Along with the above minimum hardware requirements, it is assumed that the user has access to a performant ethereum RPC endpoint. Furthermore, this guide expects the user to be using a "standard" Linux distribution like Debian / Ubuntu when following along with the steps. +Along with the above minimum hardware requirements, it is assumed that the user has access to a performant Ethereum RPC endpoint. Furthermore, this guide expects the user to be using a "standard" Linux distribution like Debian / Ubuntu when following along with the steps. -Overview +## Overview 1. Install Docker -2. Install aztec +2. Install Aztec 3. Configure the node 4. Start the node! ## Install and set up Docker -Please ensure that docker is installed. If not, here is a convenient way to install it. +Ensure Docker is installed. If not, here is a convenient way to install it. This uses the script at [https://get.docker.com/](https://get.docker.com/) to install the latest stable release of Docker on Linux: @@ -45,7 +47,7 @@ curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh ``` -Afterwards, the currently logged in user must be added to the docker group, so sudo is not needed to invoke docker. +Afterwards, the currently logged in user must be added to the docker group, so `sudo` is not needed to invoke docker. ```console sudo groupadd docker @@ -57,13 +59,13 @@ docker run hello-world ## Install Aztec -Run these commands to grab the aztec stack and add them to path. +Run these commands to grab the Aztec stack and add them to path. ```console bash -i <(curl -s https://install.aztec.network) # Users should check that it is installed by using ls ~/.aztec/bin -# aztec, aztec-up aztec-nargo and aztec-wallet should show up here +# aztec, aztec-up, aztec-nargo and aztec-wallet should show up here echo 'export PATH="$HOME/.aztec/bin:$PATH"' >> ~/.bashrc source ~/.bashrc ``` @@ -88,17 +90,21 @@ Now that the correct version of the node is installed, it needs to be configured mkdir aztec-node && cd ./aztec-node ``` -Next, set some required configuration options. This guide will use `custom_named` environment variables (e.g. `AZTEC_NODE_P2P_IP`) but this is not necessary; you can pass valued directly into the command without specifying them as environment variables. The external IP address of the node, and the L1 RPC endpoints must be defined when starting a node. Also, configuration defining the network version should be set, as this will let the node define the other required protocol variables, like rollup address, registry address etc. Please note that the specified RPC endpoints must support high throughput, otherwise the node will suffer degraded performance. +Next, set some required configuration options. This guide will use `custom_named` environment variables (e.g. `AZTEC_NODE_P2P_IP`) but this is not necessary; you can pass values directly into the command without specifying them as environment variables. The external IP address of the node, and the L1 RPC endpoints must be defined when starting a node. Also, configuration defining the network version should be set, as this will let the node define the other required protocol variables, like rollup address, registry address etc. Note that the specified RPC endpoints must support high throughput, otherwise the node will suffer degraded performance. ```console -# If the external IP of the machine the node is running on is unknown, it can be obtained by running `curl ifconfig.me`. -export AZTEC_NODE_P2P_IP=IP export AZTEC_NODE_NETWORK=testnet +export AZTEC_NODE_P2P_IP=IP export AZTEC_NODE_ETH_HOSTS= export AZTEC_NODE_CONSENSUS_HOSTS= ``` -Finally, the ports used by the node must be accessible to other Aztec nodes on the internet. This will require disabling the firewall for and / or forwarding these ports. The router must be able to send UDP and TCP traffic on port 40400 (unless the defaults were changed) to the node IP address on its local network. Failure to do so may result in the node not participating in p2p duties. +:::tip + +The ports used by the node must be accessible to other Aztec nodes on the internet. This will require disabling the firewall for and / or forwarding these ports. The router must be able to send UDP and TCP traffic on port 40400 (unless the defaults were changed) to the node IP address on its local network. Failure to do so may result in the node not participating in p2p duties. + +Running the command `curl ipv4.icanhazip.com` can retrieve your public IP address for you. +::: ## Run the node @@ -110,16 +116,16 @@ To verify the node is working, run these commands in another terminal window: ```console # Rule 1: For HTTP traffic on port 8080 -curl -X POST --data '{"method": "node_getL2Tips"}' +curl -X POST http://localhost:8080 --data '{"method": "node_getL2Tips"}' # should return JSON data in the format of "{"result":{"latest":{"number":"...}}}" # Rule 2: For TCP traffic on port 40400 (set by default) -nc -vz IP 40400 -# should return "Connection to IP 40400 port [tcp/*] succeeded!" if port open +nc -vz [YOUR_EXTERNAL_IP] 40400 +# should return "Connection to [YOUR_EXTERNAL_IP] 40400 port [tcp/*] succeeded!" if port open # Rule 3: For UDP traffic on port 40400 (set by default) -nc - vu IP 40400 -# should return "Connection to IP 40400 port [udp/*] succeeded!" if port open +nc -vu [YOUR_EXTERNAL_IP] 40400 +# should return "Connection to [YOUR_EXTERNAL_IP] 40400 port [udp/*] succeeded!" if port open ``` Congrats, the node should be up, running, and connected to the network! diff --git a/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/guides/run_nodes/how_to_run_prover.md b/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/guides/run_nodes/how_to_run_prover.md index 9d4125a27ee6..e68abd8ddfd7 100644 --- a/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/guides/run_nodes/how_to_run_prover.md +++ b/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/guides/run_nodes/how_to_run_prover.md @@ -161,12 +161,13 @@ Required environment variables: - `PROVER_BROKER_HOST`: Broker endpoint for job submission - `PROVER_ID`: Ethereum address corresponding to `PROVER_PUBLISHER_PRIVATE_KEY` +**Note**: Some variables overlap with the prover node configuration. In this case we use the same value for `PROVER_BROKER_HOST`, so we will not duplicate it in our `.env` file. + Add to your `.env` file: ```sh PROVER_AGENT_COUNT=10 PROVER_AGENT_POLL_INTERVAL_MS=10000 -PROVER_BROKER_HOST=http://prover-broker:8080 PROVER_ID= ``` @@ -199,15 +200,14 @@ name: aztec-prover services: prover-node: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-node - - --archiver - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-node + --archiver + --network testnet depends_on: prover-broker: condition: service_started @@ -219,6 +219,7 @@ services: LOG_LEVEL: ${LOG_LEVEL} PROVER_BROKER_HOST: ${PROVER_BROKER_HOST} PROVER_PUBLISHER_PRIVATE_KEY: ${PROVER_PUBLISHER_PRIVATE_KEY} + P2P_IP: ${P2P_IP} P2P_PORT: ${P2P_PORT} AZTEC_PORT: ${AZTEC_PORT} ports: @@ -230,14 +231,13 @@ services: prover-broker: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-broker - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-broker + --network testnet environment: DATA_DIRECTORY: /var/lib/data ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} @@ -248,14 +248,13 @@ services: prover-agent: image: aztecprotocol/aztec:latest - command: - - node - - --no-warnings - - /usr/src/yarn-project/aztec/dest/bin/index.js - - start - - --prover-agent - - --network - - testnet + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js + start + --prover-agent + --network testnet environment: PROVER_AGENT_COUNT: ${PROVER_AGENT_COUNT} PROVER_AGENT_POLL_INTERVAL_MS: ${PROVER_AGENT_POLL_INTERVAL_MS} diff --git a/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md b/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md index a98c8bf9f25b..753258667d1b 100644 --- a/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md +++ b/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md @@ -24,17 +24,17 @@ tags: ## Background -This guide covers the steps required to run a sequencer node on Aztec. It will also provide context to ensure users are comfortable with the steps they are taking. +This guide covers the steps required to run a sequencer node on the Aztec network. The Aztec sequencer node is critical infrastructure responsible for ordering transactions and producing blocks. -The sequencer node takes part in three key actions: +The sequencer node performs three key actions: -1. Assemble unprocessed transactions and propose the next block -2. Attest to correct execution of txs in the proposed block (if part of the sequencer committee) -3. Submit the successfully attested block to L1 +1. Assembles unprocessed transactions and proposes the next block +2. Attests to correct execution of transactions in proposed blocks (when part of the sequencer committee) +3. Submits successfully attested blocks to L1 -When transactions are sent to the Aztec network, sequencer nodes bundle them into blocks, checking various constraints such as gas limits, block size, and transaction validity. Before a block can be published, it must be validated by a committee of other sequencer nodes who re-execute public transactions and verify private function proofs so they can attest to correct execution. These sequencers attest to the block's validity by signing the block header, and once enough attestations are collected (two-thirds of the committee plus one), the sequencer can submit the block to L1. +Sequencer nodes bundle transactions into blocks while checking constraints like gas limits, block size, and validity. Before publication, blocks must be validated by a committee of sequencer nodes who re-execute public transactions and verify private function proofs. Committee members attest to validity by signing the block header. Once sufficient attestations are collected (two-thirds of the committee plus one), the block can be submitted to L1. The archiver component complements this process by maintaining historical chain data. It continuously monitors L1 for new blocks, processes them, and maintains a synchronized view of the chain state. This includes managing contract data, transaction logs, and L1-to-L2 messages, making it essential for network synchronization and data availability. @@ -49,33 +49,38 @@ Minimum hardware requirements: Please note that these requirements are subject to change as the network throughput increases. -This guide expects you to be using a "standard" Linux distribution like Debian / Ubuntu when following along with the steps. +This guide assumes you are using a standard Linux distribution (Debian or Ubuntu). -It also is assumed that you have installed Docker and the aztec toolchain via aztec-up as described in the [getting started section](../../index.md). +### Required Software -Furthermore, as this guide uses Docker compose, you will need to install it. Please follow [this](https://docs.docker.com/compose/install/) guide to do so. +- Docker and the Aztec toolchain installed via aztec-up (see the [getting started section](../../index.md)) +- Docker Compose ([installation guide](https://docs.docker.com/compose/install/)) +- Access to L1 node endpoints (execution and consensus clients). See [Eth Docker's guide](https://ethdocker.com/Usage/QuickStart) if you need to set these up. -Finally, this guide requires you to have endpoints of an L1 node stack of an execution and consensus client. If you do not have one set up, you can see a good guide on how to do that [here at Eth Docker](https://ethdocker.com/Usage/QuickStart). +## Configure the Sequencer +Setting up a sequencer involves configuring keys, environment variables, and Docker Compose. -## Configure the sequencer +### Setup Steps -There are a few important things to note when setting up a sequencer. This guide will guide you in setting up and running a sequencer with a standard setup using Docker compose with a .env file. +1. Define private keys and accounts for sequencer duties +2. Configure node settings via environment variables +3. Enable auto-update and auto-restart functionality +4. Deploy with Docker Compose -The setup of the sequencer has four important steps. +First, create the directory structure for sequencer data storage: -1. Define private keys / accounts used for sequencer duties -2. Set required node configuration -3. Ensure auto-update / auto-restart is enabled -4. Apply your Docker compose file - -Let's start by creating a new directory called `aztec-sequencer`, with two subdirectories, `keys`, and `data`. This is where all the information used by the sequencer will be stored. Please also create an empty `.env` file in `aztec-sequencer` to define your settings before moving on to the next step. +```sh +mkdir -p aztec-sequencer/keys aztec-sequencer/data +cd aztec-sequencer +touch .env +``` -### Define private keys / accounts +### Define Private Keys and Accounts -A sequencer must hold and use private keys identifying it as a valid proposer or attester. This is done by defining a keystore file. +Sequencers require private keys to identify themselves as valid proposers or attesters. Configure these through a keystore file. -An example keystore file is below. Copy this file and save it as `keystore.json` into your `aztec-sequencer/keys` folder. +Create a `keystore.json` file in your `aztec-sequencer/keys` folder: ```json { @@ -91,20 +96,18 @@ An example keystore file is below. Copy this file and save it as `keystore.json` } ``` -The keystore defines a few important keys and addresses for sequencer operation. They include but are not limited to: +The keystore defines keys and addresses for sequencer operation: -- `attester`: the private key of the sequencer, used for signing block proposals and attestations on block proposals produced by other sequencers. The corresponding Ethereum address of the private key is the identity of the sequencer. -- `publisher`: the private key of the Ethereum EOA used for sending the block proposal to L1. This defaults to the attester private key if not set. -- `coinbase`: the Ethereum address set in a block proposal. L1 rewards and fees are sent to this address. This falls back to the address derived by the attester private key if not set. -- `feeRecipient`: the Aztec Address of the fee recipient address when proposing blocks. The unburnt portion of the tx fees in a given block are sent to this address. +- `attester`: Private key for signing block proposals and attestations. The corresponding Ethereum address identifies the sequencer. +- `publisher`: Private key for sending block proposals to L1. Defaults to attester key if not set. +- `coinbase`: Ethereum address receiving L1 rewards and fees. Defaults to attester address if not set. +- `feeRecipient`: Aztec address receiving unburnt transaction fees from blocks. -Please set these values with the ones you want and save `keystore.json`. +Replace the placeholder values with your actual keys and addresses. -### Node configuration +### Node Configuration -Next you will need to define some environment variables that set important configuration for your node. - -These include: +Required environment variables: - `DATA_DIRECTORY`: the folder where the data of the sequencer is stored - `KEY_STORE_DIRECTORY`: can be a path to the file or directory where keystores are located. In our case it is the path to the folder containing the `keystore.json` file created above @@ -115,7 +118,7 @@ These include: - `P2P_PORT`: The port that P2P communication happens on - `AZTEC_PORT`: The port that the sequencer node API is exposed on -Please paste this sample `.env` file into the empty one currently residing in your `aztec-sequencer` folder. Please note that we are assuming you are using the default ports of 8080 for the sequencer itself, and 40400 for p2p connectivity. If this is not the case, please overwrite the defaults below. +Add the following to your `.env` file (using default ports 8080 and 40400): ```sh DATA_DIRECTORY=./data @@ -129,27 +132,23 @@ AZTEC_PORT=8080 ``` :::tip -Forward your ports. Your router must send UDP and TCP traffic on the port specified by `P2P_PORT` to your IP address on your local network. +You MUST forward ports for P2P connectivity. Configure your router to forward both UDP and TCP traffic on the port specified by `P2P_PORT` to your local IP address. -Running the command `curl ipv4.icanhazip.com` can retrieve your public IP address for you. +To find your public IP address, run: `curl ipv4.icanhazip.com` ::: -### Enable auto-update / auto-restart - -It is imperative that the built in auto-updating functionality of the sequencer is not disabled. The update-checker is a background module in the Aztec node that enables global coordination of updates. It allows the protocol team to: +### Enable Auto-Update and Auto-Restart -- Push configuration changes to all nodes -- Trigger shutdowns so that nodes can pull the latest image version -- Apply hot-fixes quickly -- Coordinate node resets after a governance upgrade, especially when a new canonical rollup is published to the Registry +The sequencer's auto-update functionality is critical for network coordination. This background module enables: -This module ensures that upgrades and fixes propagate smoothly without requiring manual intervention from every node operator. +- Configuration updates across all nodes +- Automated image updates via controlled shutdowns +- Rapid hot-fix deployment +- Coordinated resets after governance upgrades -Please ensure environment variables: +**Important**: Do NOT set `AUTO_UPDATE_URL` or `AUTO_UPDATE` environment variables. These must use their default values for proper operation. -`AUTO_UPDATE_URL` and `AUTO_UPDATE` remain unset, as to take their default values (which are the s3 bucket being used to host the update information, and `config-and-version` respectively). - -Because docker-compose does not respect pull policies on container restarts, to handle updates properly, add Watchtower to your stack by running: +Since Docker Compose doesn't respect pull policies on container restarts, install Watchtower for automatic updates: ```sh docker run -d \ @@ -158,9 +157,9 @@ docker run -d \ containrrr/watchtower ``` -### Applying your Docker compose file +### Deploy with Docker Compose -Now that you have done all the setup, create a Docker compose file named `compose.yml` in your `aztec-sequencer` directory and paste the below code into it. +Create a `docker-compose.yml` file in your `aztec-sequencer` directory: ```yaml services: @@ -175,21 +174,23 @@ services: - ${DATA_DIRECTORY}:/var/lib/data - ${KEY_STORE_DIRECTORY}:/var/lib/keystore environment: - KEY_STORE_DIRECTORY: /var/lib/keystore - DATA_DIRECTORY: /var/lib/data - LOG_LEVEL: ${LOG_LEVEL} - ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} - L1_CONSENSUS_HOST_URLS: ${L1_CONSENSUS_HOST_URLS} - P2P_IP: ${P2P_IP} - P2P_PORT: ${P2P_PORT} - AZTEC_PORT: ${AZTEC_PORT} - entrypoint: node /usr/src/yarn-project/aztec/dest/bin/index.js - command: >- + KEY_STORE_DIRECTORY: /var/lib/keystore + DATA_DIRECTORY: /var/lib/data + LOG_LEVEL: ${LOG_LEVEL} + ETHEREUM_HOSTS: ${ETHEREUM_HOSTS} + L1_CONSENSUS_HOST_URLS: ${L1_CONSENSUS_HOST_URLS} + P2P_IP: ${P2P_IP} + P2P_PORT: ${P2P_PORT} + AZTEC_PORT: ${AZTEC_PORT} + entrypoint: >- + node + --no-warnings + /usr/src/yarn-project/aztec/dest/bin/index.js start - --network testnet --node --archiver --sequencer + --network testnet networks: - aztec restart: always @@ -199,11 +200,19 @@ networks: name: aztec ``` -Please note that we are setting only the necessary configuration for running this sequencer. The full list of settings and flags can be explored here at the [cli reference](../../reference/cli_reference.md). A lot of these options are preset to defaults by the `--network` flag above. This downloads defaults for the specified network and applies them to the node. +**Note**: This configuration includes only essential settings. The `--network testnet` flag applies network-specific defaults. See the [CLI reference](../../reference/cli_reference.md) for all available options. -Now, you can run `docker compose up` inside your `aztec-sequencer` folder to start the sequencer! +Start the sequencer: -To check if your sequencer is currently synced, which may take a few minutes, run this command and compare its output to any of the Aztec block explorers. (See [Aztec Scan](https://aztecscan.xyz/) or [Aztec Explorer](https://aztecexplorer.xyz/)) +```sh +docker compose up -d +``` + +## Verification + +To verify your sequencer is running correctly: + +1. Check the current sync status (this may take a few minutes): ```sh curl -s -X POST -H 'Content-Type: application/json' \ @@ -211,8 +220,57 @@ curl -s -X POST -H 'Content-Type: application/json' \ http://localhost:8080 | jq -r ".result.proven.number" ``` -## Add yourself to the testnet sequencer set +Compare the output with block explorers like [Aztec Scan](https://aztecscan.xyz/) or [Aztec Explorer](https://aztecexplorer.xyz/). + +2. View sequencer logs: + +```sh +docker compose logs -f aztec-sequencer +``` + +3. Check node status: + +```sh +curl http://localhost:8080/status +``` + +## Troubleshooting + +### Common Issues + +**Port forwarding not working:** + +- Verify your external IP address matches the `P2P_IP` setting +- Check firewall rules on your router and local machine +- Test connectivity using: `nc -zv ` + +**Sequencer not syncing:** + +- Check L1 endpoint connectivity +- Verify both execution and consensus clients are fully synced +- Review logs for specific error messages + +**Keystore issues:** + +- Ensure keystore.json is properly formatted +- Verify private keys are valid Ethereum private keys +- Check file permissions on the keys directory + +**Docker issues:** + +- Ensure Docker and Docker Compose are up to date +- Check disk space availability +- Verify container has sufficient resources + +## Join the Sequencer Set + +After setting up your node, you must request to be added to the sequencer set. + +Complete the onboarding process at [testnet.aztec.network](https://testnet.aztec.network) using zkPassport. -After setting up your node you must explicitly request to be added to the sequencer set. +## Next Steps -To complete this final step you can now head to [testnet.aztec.network](https://testnet.aztec.network) and complete the onboarding flow there utilizing zkPassport! +- Monitor your sequencer's performance and attestation rate +- Join the [Aztec Discord](https://discord.gg/aztec) for operator support +- Review [Reacting to Upgrades](../../reference/reacting_to_upgrades.md) guide +- Consider implementing monitoring and alerting for production deployments diff --git a/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/index.md b/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/index.md index 2a193d2736e0..9e15f5f3853e 100644 --- a/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/index.md +++ b/docs/versioned_docs/version-v3.0.0-nightly.20250917/the_aztec_network/index.md @@ -93,14 +93,18 @@ mkdir aztec-node && cd ./aztec-node Next, set some required configuration options. This guide will use `custom_named` environment variables (e.g. `AZTEC_NODE_P2P_IP`) but this is not necessary; you can pass values directly into the command without specifying them as environment variables. The external IP address of the node, and the L1 RPC endpoints must be defined when starting a node. Also, configuration defining the network version should be set, as this will let the node define the other required protocol variables, like rollup address, registry address etc. Note that the specified RPC endpoints must support high throughput, otherwise the node will suffer degraded performance. ```console -# If the external IP of the machine the node is running on is unknown, it can be obtained by running `curl ifconfig.me`. -export AZTEC_NODE_P2P_IP=IP export AZTEC_NODE_NETWORK=testnet +export AZTEC_NODE_P2P_IP=IP export AZTEC_NODE_ETH_HOSTS= export AZTEC_NODE_CONSENSUS_HOSTS= ``` -Finally, the ports used by the node must be accessible to other Aztec nodes on the internet. This will require disabling the firewall for and / or forwarding these ports. The router must be able to send UDP and TCP traffic on port 40400 (unless the defaults were changed) to the node IP address on its local network. Failure to do so may result in the node not participating in p2p duties. +:::tip + +The ports used by the node must be accessible to other Aztec nodes on the internet. This will require disabling the firewall for and / or forwarding these ports. The router must be able to send UDP and TCP traffic on port 40400 (unless the defaults were changed) to the node IP address on its local network. Failure to do so may result in the node not participating in p2p duties. + +Running the command `curl ipv4.icanhazip.com` can retrieve your public IP address for you. +::: ## Run the node