diff --git a/docs/docs/glossary.md b/docs/docs/glossary.md index 5a0982458ba2..03c2ceeee8df 100644 --- a/docs/docs/glossary.md +++ b/docs/docs/glossary.md @@ -67,7 +67,7 @@ You can find more info about the LSP [in the Noir docs](https://noir-lang.org/do -To run your own node see [here](./run_node/guides/run_nodes/index.md). +To run your own node see [here](./the_aztec_network/guides/run_nodes/index.md). ### Note diff --git a/docs/docs/run_node/concepts/governance/putting_forward_proposals.md b/docs/docs/run_node/concepts/governance/putting_forward_proposals.md deleted file mode 100644 index b110899e4538..000000000000 --- a/docs/docs/run_node/concepts/governance/putting_forward_proposals.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -sidebar_position: 0 -title: Putting forward Proposals ---- - -Sequencers of the *current* canonical rollup (as indicated by the Registry) can propose changes to the Aztec community for voting. In order for a proposal to be voted on through the governance process, *N* sequencers must nominate the proposal in any given round. A round is defined as a sequence of contiguous M L2 blocks. Both *N* and *M* are governance defined parameters. - -Sequencers can only nominate a proposal during an L1 slot for which they’ve been assigned proposer duties. This minimizes timing games and provides a lower bound on the time required to successfully bring about a vote by governance. - -A mechanism is also proposed whereby any digital asset (“Hypothetical Assetˮ) holder (“Holderˮ) can burn a large quantity of Hypothetical Asset to trigger a vote on a proposal, without having the sequencers nominating the proposal. Note that Hypothetical Asset holders would still need to vote to approve any proposals nominated via this mechanism. - -To nominate a proposal, a validator of the current canonical rollup would deploy two sets of contracts: -1. The upgraded contracts they wish to upgrade to -2. `code` which can be executed by governance to upgrade into these contracts - -Then when it is their turn as the proposer, they call `vote(address _proposal)` on the `Proposals` contract, where `_proposal ` is the address of the `code` payload. - diff --git a/docs/docs/run_node/guides/connecting_to_node.md b/docs/docs/run_node/guides/connecting_to_node.md deleted file mode 100644 index 32ccbcb2bfe4..000000000000 --- a/docs/docs/run_node/guides/connecting_to_node.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -sidebar_position: 0 -title: Connecting to a node -draft: true ---- \ No newline at end of file diff --git a/docs/docs/run_node/guides/node_reference.md b/docs/docs/run_node/guides/node_reference.md deleted file mode 100644 index 4b45fbd9e474..000000000000 --- a/docs/docs/run_node/guides/node_reference.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -sidebar_position: 5 -title: Node reference -draft: true ---- \ No newline at end of file diff --git a/docs/docs/run_node/guides/reacting_to_upgrades.md b/docs/docs/run_node/guides/reacting_to_upgrades.md deleted file mode 100644 index 293922e4c0b3..000000000000 --- a/docs/docs/run_node/guides/reacting_to_upgrades.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -sidebar_position: 4 -title: Reacting to upgrades ---- - -This is a guide for sequencer nodes to understand how to react to protocol upgrades. To learn about how upgrades work, read the [concept section](../concepts/governance/upgrades.md). - -## Deploying the initial contracts - -Assume that there is an initial deployment, which is a set of contracts as described in the [Deployment section](../concepts/deployments/what_is_deployment.md). - -Once an AZIP garners enough buy-in from the community, sequencers can begin adopting the upgrade. - -## New Rollup contract is deployed to L1 and a proposal is initiated - -To upgrade to a new Rollup instance is to: - -1. Convince the Governance contract to call `Registry.upgrade(_addressOfNewRollup)` - -2. Sequencers move stake to the new Rollup contract to be eligible for any Hypothetical Asset rewards. - -To achieve 1, a new Rollup contract is deployed at an address, and the code for calling `Registry.upgrade(_addressOfNewRollup)` is deployed at a separate address. - -Sequencers of the current canonical rollup, that is the current rollup as pointed to by the Registry, must then call `vote(proposal)` on the Proposals contract. Sequencers can only vote during L2 slots for which they’ve been assigned as the block proposer by the L1 Rollup smart contract. For any given L2 slot, there is only one such sequencer. - -Sequencers vote by updating an environment variable `PROPOSAL_PAYLOAD` in their client software. If enough votes are received by the Proposals contract, any Ethereum account can call `pushProposal(_roundNumber)` where `_roundNumber` can be read from the L1. - -## Voting starts and proposal executed after delay - -Holders who locked their Hypothetical Assets in the Governance contract can vote on proposals. Each vote specifies whether it is in support of the upgrade or not, and the amount of locked Hypothetical Assets the holder wishes to vote. - -If the vote passes, a proposal is moved to an Executable state after some delay. - -## Proposal executed - -Anyone can call `execute(_proposalId)` on the Governance contract which in turn will call the proposal code that was deployed. diff --git a/docs/docs/run_node/guides/run_nodes/how_to_run_prover.md b/docs/docs/run_node/guides/run_nodes/how_to_run_prover.md deleted file mode 100644 index 27e44517a3c2..000000000000 --- a/docs/docs/run_node/guides/run_nodes/how_to_run_prover.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -sidebar_position: 2 -title: How to Run a Prover Node ---- - -It is recommended to read the concepts before running a node, specifically the [provers and sequencers](../../concepts/provers-and-sequencers/index.md) section. - -As we are in active development, this guide is actively changing. Please refer to [this HackMD page](https://hackmd.io/@aztec-network/epoch-proving-integration-guide#Running-a-Prover-Node) for the latest information. \ No newline at end of file diff --git a/docs/docs/run_node/guides/run_nodes/how_to_run_prover_draft.md b/docs/docs/run_node/guides/run_nodes/how_to_run_prover_draft.md deleted file mode 100644 index f8b66e71210b..000000000000 --- a/docs/docs/run_node/guides/run_nodes/how_to_run_prover_draft.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -sidebar_position: 2 -title: How to run a prover node (draft) -draft: true ---- - -!! We will update and publish this when ready !! - -It is recommended to read the concepts before running a node, specifically the [provers and sequencers](../../concepts/provers-and-sequencers/index.md) section. - -The Aztec client can be run as a Prover Node. In this mode, the client will automatically monitor L1 for unclaimed epochs and propose bids (i.e. EpochProofQuote) for proving them. The prover node watches the L1 to see when a bid they submitted has been accepted by a sequencer, the prover node will then kick off an epoch proving job which performs the following tasks: - -- Downloads the transaction hashes in the epoch and all L1 to L2 messages from L1. -- Downloads the transaction objects with their ClientIVC proofs from a remote node (to be replaced by loading them from the P2P pool). -- Executes transactions in the epoch in order, generating proving jobs for each of them. -- Generates the inputs for each circuit and kicks off individual proving jobs to prover agents, recursively proving until it gets to the root rollup proof. -- Submits the root rollup proof to L1 to advance the proven chain. - -```mermaid -flowchart TD - style prover-node stroke:#333,stroke-width:4px - - prover-node[Prover Node] - proving-job[Proving Job] - tx-provider[Tx Provider] - l1-publisher[L1 Publisher] - l2-block-source[L2 Block Source] - world-state[World State DB] - tx-processor[Tx Processor] - prover-client[Proving Orchestrator] - proving-queue[Proof Broker] - prover-agent[Prover Agent] - bb[Barretenberg] - - prover-node --trigger--> proving-job - proving-job --"process-tx"--> tx-processor --"add-tx"--> prover-client - proving-job --start-batch--> prover-client - proving-job --get-tx-hashes--> l2-block-source - proving-job --"advance-to"--> world-state - proving-job --"get-txs"--> tx-provider - tx-processor --rw--> world-state - world-state --"get-blocks"--> l2-block-source - prover-client --"rw"--> world-state - proving-job --publish-proof--> l1-publisher - prover-client --"push-job"--> proving-queue - %%prover-agent --"pull-job"--> proving-queue - proving-queue <--"pull-jobs"--o prover-agent - subgraph "Prover Agent" - prover-agent --"prove"--> bb - end - - %% p2p-client --> tx-pool --"save-tx"--> tx-db - %% p2p-client --get-blocks--> l2-block-source -``` - -The Aztec client needed to run a prover node is shipped as a [docker image](https://hub.docker.com/r/aztecprotocol/aztec) The image exposes the Aztec CLI as its `ENTRYPOINT`, which includes a `start` command for starting different components. You can download it directly or use the sandbox scripts which will automatically pull the image and add the aztec shell script to your path. - -Once the `aztec` command is available, you can run a prover node via: - -```bash -aztec start --prover-node --archiver -``` - -To run a prover agent, either run `aztec start --prover`, or add the `--prover` flag to the command above to start an in-process prover. - -## Configuration - -The Aztec client is configured via environment variables, the following ones being relevant for the prover node: - -- **ETHEREUM_HOSTS**: List of URLs of Ethereum nodes (comma separated). -- **L1_CHAIN_ID**: Chain ID for the L1 Ethereum chain. -- **DATA_DIRECTORY**: Local folder where archive and world state data is stored. -- **AZTEC_PORT**: Port where the JSON-RPC APIs will be served. -- **PROVER_PUBLISHER_PRIVATE_KEY**: Private key used for publishing proofs to L1. Ensure it corresponds to an address with ETH to pay for gas. -- **PROVER_AGENT_ENABLED**: Whether to run a prover agent process on the same host running the Prover Node. We recommend setting to `false` and running prover agents on separate hosts. -- **P2P_ENABLED**: Set to `true` so that your node can discover peers, receive tx data and gossip quotes to sequencers. -- **PROVER_COORDINATION_NODE_URL**: Send quotes via http. Only used if `P2P_ENABLED` is `false`. -- **BOOT_NODE_URL**: The URL of the boot node for peer discovery. -- **AZTEC_NODE_URL**: Used by the Prover Node to fetch the L1 contract addresses if they were not manually set via environment variables. - -:::note -For S&P Testnet, we will be providing an Ethereum host, a Boot Node URL and a specific Aztec Image. -::: - -The prover agent, on the other hand, relies on the following environment variables: - -- **PROVER_BROKER_HOST**: URL to the Prover Node that acts as a proving job source. - -Both the prover node and agent also rely on the following: - -- **PROVER_REAL_PROOFS**: Whether to generate actual proofs, as opposed to only simulating the circuit and outputting fake proofs. **Set to `true` for the scope of the S&P Testnet.** -- **LOG_LEVEL**: One of `debug`, `verbose`, `info`, `warn`, or `error`. -- **LOG_JSON**: Set to `true` to output logs in JSON format (unreleased). -- **OTEL_EXPORTER_OTLP_METRICS_ENDPOINT**: Optional URL for pushing telemetry data to a remote OpenTelemetry data collector. diff --git a/docs/docs/run_node/guides/run_nodes/how_to_run_sequencer_draft.md b/docs/docs/run_node/guides/run_nodes/how_to_run_sequencer_draft.md deleted file mode 100644 index dcae47b89512..000000000000 --- a/docs/docs/run_node/guides/run_nodes/how_to_run_sequencer_draft.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -sidebar_position: 1 -title: How to run a Validator/Sequencer Node (draft) -draft: true ---- - -# Running a Sequencer using Aztec Spartan - -This tool helps to boot an Aztec Sequencer and Prover (S&P) Testnet. - -This script does the following: - -- Checks for the presence of Docker in your machine -- Prompts you for some environment variables -- Outputs a templated docker-compose file with your variables -- Runs the docker compose file - -It should work in most UNIX-based machines. - -## Installation - -To configure a new node, create a new directory and run the install script: - -```bash -mkdir val1 && cd val1 -curl -L sp-testnet.aztec.network | bash -``` - -This will install `aztec-spartan.sh` in the current directory. You can now run it: - -```bash -./aztec-spartan.sh config -``` - -If you don't have Docker installed, the script will do it for you. It will then prompt for any required environment variables and output both a `docker-compose.yml` and an `.env` file. You will also be prompted to choose whether to use a [named volume](https://docs.docker.com/engine/storage/volumes/) (default) or if you want to use a local directory to store the node's data. - -Run `./aztec-spartan.sh` without any command to see all available options, and pass them as flags, i.e. `npx aztec-spartan config -p 8080 -p2p 40400`. If you want to use a different key for p2p peer id, pass it with `-pk `. - -For more options, see the [Node Configuration](#node-configuration) section. - -:::tip -Ensure that each validator instance uses unique ports to avoid conflicts. -::: - -## Running - -You can use `npx aztec-spartan [start/stop/logs/update]` to start, stop, output logs or pull the latest docker images. - -:::note -The above deploy script will connect your node to the p2p network where it will register peers and start receiving messages from other nodes on the network. You will not be in the validator set just yet. - -Once you connect and begin to see gossiped messages such as attestations, proposals etc notify notify a team member and they will add you to the validator set. -::: - -## Node Configuration - -The `aztec-spartan.sh` script will set the following required variables on your behalf. You can ofcourse override the variables set by the script by simply changing the `.env` file directly and re-running `./aztec-spartan.sh` - -| Variable | Description | -| -------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -| ETHEREUM_HOSTS | List of URLs of Ethereum nodes (comma separated). For as long as we're on private networks, please use the value in `aztec-spartan.sh` | -| BOOTNODE_URL | URL to a bootnode that supplies L1 contract addresses and the ENR of the bootstrap nodes. | -| IMAGE | The docker image to run | - -In addition, the user is prompted to enter 1) an IP Address and a P2P port to be used for the TCP and UDP addresses (defaults to 40400) 2) A port for your node (8080) 3) an Ethereum private key 4) `COINBASE` which is the Ethereum address associated with the private key and 5) a path to a local directory to store node data if you don't opt for a named volume. - -On a first run, the script will generate a p2p private key and store it in `$DATA_DIR/var/lib/aztec/p2p-private-key`. If you wish to change your p2p private key, you can pass it on as a CLI arg using the flag `-pk` or update the `PEER_ID_PRIVATE_KEY` in the env file. - -### Publisher and Archiver - -The Publisher is the main node component that interacts with the Ethereum L1, for read and write operations. It is mainly responsible for block publishing, proof submission and tx management. - -The Archiver's primary functions are data storage and retrieval (i.e. L1->L2 messages), state synchronization and re-org handling. - -| Variable | Description | -| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | -| ETHEREUM_HOSTS | List of L1 node URLs (comma separated) your validator will connect to. For as long as we're on private networks, please use the value in `aztec-spartan.sh` | -| L1_CHAIN_ID | Chain ID of the L1 | -| DATA_DIRECTORY | Optional dir to store archiver and world state data. If omitted will store in memory | -| ARCHIVER_POLLING_INTERVAL_MS | The polling interval in ms for retrieving new L2 blocks and encrypted logs | -| SEQ_PUBLISHER_PRIVATE_KEY | This should be the same as your validator private key | -| SEQ_PUBLISH_RETRY_INTERVAL_MS | The interval to wait between publish retries | -| SEQ_VIEM_POLLING_INTERVAL_TIME | The polling interval viem uses in ms | - -### Sequencer Config - -The Sequencer Client is a criticial component that coordinates tx validation, L2 block creation, collecting attestations and block submission (through the Publisher). - -| Variable | Description | -| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| VALIDATOR_DISABLED | If this is True, the client won't perform any validator duties. | -| VALIDATOR_ATTESTATIONS_WAIT_TIMEOUT_MS | Wait for attestations timeout. After this, client throws an error and does not propose a block for that slot. | -| VALIDATOR_ATTESTATIONS_POLLING_INTERVAL_MS | If not enough attestations, sleep for this long and check again | -| GOVERNANCE_PROPOSER_PAYLOAD_ADDRESS | To nominate proposals for voting, you must set this variable to the Ethereum address of the `proposal` payload. You must edit this to vote on a governance upgrade. | -| SEQ_ENFORCE_TIME_TABLE | Whether to enforce strict timeliness requirement when building blocks. Refer [here](#sequencer-timeliness-requirements) for more on the timetable | -| SEQ_MAX_TX_PER_BLOCK | Increase this to make larger blocks | -| SEQ_MIN_TX_PER_BLOCK | Increase this to require making larger blocks | -| COINBASE | This is the Ethereum address that will receive the validator's share of block rewards. It defaults to your validator address. | -| FEE_RECIPIENT | This is the Aztec address that will receive the validator's share of transaction fees. Also defaults to your validator's address (but on Aztec L2). | - -#### Sequencer Timeliness Requirements - -During testing, it was helpful to constrain some actions of the sequencer based on the time passed into the slot. The time-aware sequencer can be told to do action A only if there's a certain amount of time left in the slot. - -For example, at the beginning of a slot, the sequencer will first sync state, then request txs from peers then attempt to build a block, then collect attestations then publish to L1. You can create constraints of the form "Only attempt to build a block if under 5 seconds have passed in the slot". - -If this is helpful in your testing as well, you can turn it on using the environment variable `SEQ_ENFORCE_TIME_TABLE`. - -Currently the default timetable values are hardcoded in [sequencer.ts](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/sequencer-client/src/sequencer/sequencer.ts#L72). Time checks are enforced in `this.setState()`. - -### P2P Config - -The P2P client coordinates peer-to-peer communication between Nodes. - -| Variable | Description | -| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| BOOTSTRAP_NODES | A list of bootstrap peer ENRs to connect to. Separated by commas. | -| P2P_IP | The client's public IP address. Defaults to working it out using disv5, otherwise set P2P_QUERY_FOR_IP if you are behind a NAT | -| P2P_PORT | The port that will be used for sending / receiving p2p messages. Defaults to 40400. | -| P2P_LISTEN_ARR | Address to listen on for p2p messages. Defaults to 0.0.0.0 | -| P2P_UDP_LISTEN_ADDR | Format: `:` or can use `0.0.0.0:` to listen on all interfaces | -| P2P_QUERY_FOR_IP | Useful in dynamic environments where your IP is not known in advance. | -| P2P_ENABLED | Whether to run the P2P module. Defaults to False, so make sure to set to True | -| P2P_MAX_PEERS | The max number of peers to connect to. | -| P2P_BLOCK_CHECK_INTERVAL_MS | How milliseconds to wait between each check for new L2 blocks. | - -### Prover Config - -Please refer to the [Prover Guide](./how_to_run_prover.md) for info on how to setup your prover node. - -## Governance Upgrades - -During a governance upgrade, we'll announce details on the discord. At some point we'll also write AZIPs (Aztec Improvement Proposals) and post them to either the github or forum to collect feedback. - -We'll deploy the payload to the L1 and share the address of the payload with the sequencers on discord. - -To participate in the governance vote, sequencers must change the variable `GOVERNANCE_PROPOSER_PAYLOAD_ADDRESS` in the Sequencer Client to vote during the L2 slot they've been assigned sequencer duties. - -## Troubleshooting - -:::tip -Please make sure you are in the Discord server and that you have been assigned the role `S&P Participant`. Say gm in the `sequencer-and-prover` channel and turn on notifications for the announcements channel. -::: - -If you encounter any errors or bugs, please try basic troubleshooting steps like restarting your node, checking ports and configs. - -If issue persists, please share on the sequencer-and-prover channel and tag [Amin](discordapp.com/users/65773032211231539). - -Some issues are fairly light, the group and ourselves can help you within 60 minutes. If the issue isn't resolved, please send more information: - -**Error Logs**: Attach any relevant error logs. If possible, note the timestamp when the issue began. -**Error Description**: Briefly describe the issue. Include details like what you were doing when it started, and any unusual behaviors observed. -**Steps to Reproduce (if known)**: If there’s a clear way to reproduce the error, please describe it. -**System Information**: Share details like your system’s operating system, hardware specs, and any other relevant environment information. - -That way we can dedicate more time to troubleshoot and open Github issues if no known fix. diff --git a/docs/docs/run_node/guides/run_nodes/how_to_run_validator_sequencer.md b/docs/docs/run_node/guides/run_nodes/how_to_run_validator_sequencer.md deleted file mode 100644 index d87d530f9c1c..000000000000 --- a/docs/docs/run_node/guides/run_nodes/how_to_run_validator_sequencer.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -sidebar_position: 1 -title: How to run a Validator/Sequencer Node ---- - -It is recommended to read the concepts before running a node, specifically the [provers and sequencers](../../concepts/provers-and-sequencers/index.md) section. - -As we are in active development, this guide is actively changing. Please refer to [this README](https://github.com/AztecProtocol/aztec-packages/blob/master/spartan/releases/README.md) for the latest information. - - diff --git a/docs/docs/run_node/guides/run_nodes/index.md b/docs/docs/run_node/guides/run_nodes/index.md deleted file mode 100644 index 9d4630ebc616..000000000000 --- a/docs/docs/run_node/guides/run_nodes/index.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -id: index -sidebar_position: 0 -title: Run a Node, Sequencer, or Prover ---- - -## Running Aztec Nodes - -
- - -

Run Aztec Validator Nodes

- - - Participate in the Aztec protocol as a validator (also called a sequencer) that helps form consensus on what goes into a block. Runs on consumer hardware. - - - - -

Run Aztec Prover Nodes

- - - Participate in the Aztec protocol as a prover node, proving the rollup integrity that is pivotal to the protocol. Runs on hardware fit for data centers. - - -
\ No newline at end of file diff --git a/docs/docs/run_node/concepts/_category_.json b/docs/docs/the_aztec_network/concepts/_category_.json similarity index 100% rename from docs/docs/run_node/concepts/_category_.json rename to docs/docs/the_aztec_network/concepts/_category_.json diff --git a/docs/docs/run_node/concepts/deployments/_category_.json b/docs/docs/the_aztec_network/concepts/deployments/_category_.json similarity index 100% rename from docs/docs/run_node/concepts/deployments/_category_.json rename to docs/docs/the_aztec_network/concepts/deployments/_category_.json diff --git a/docs/docs/run_node/concepts/deployments/what_is_deployment.md b/docs/docs/the_aztec_network/concepts/deployments/what_is_deployment.md similarity index 93% rename from docs/docs/run_node/concepts/deployments/what_is_deployment.md rename to docs/docs/the_aztec_network/concepts/deployments/what_is_deployment.md index cd691a0036a4..055422de16cf 100644 --- a/docs/docs/run_node/concepts/deployments/what_is_deployment.md +++ b/docs/docs/the_aztec_network/concepts/deployments/what_is_deployment.md @@ -60,7 +60,7 @@ contract Issuer is Ownable { ## Registry Contract -The governance of Aztec will be community driven - the Aztec community will be able to decide whether to upgrade or migrate to a new rollup instance. Portals / apps donʼt need to follow along with the Aztec governance and can specify the specific instance (i.e. “versionˮ) of the rollup that they view as canonical. +The governance of Aztec will be community driven - the Aztec community will be able to decide whether to upgrade or migrate to a new rollup instance. Portals / apps donʼt need to follow along with the Aztec governance and can specify the specific instance (i.e. “versionˮ) of the rollup that they view as canonical. Therefore it will be necessary to keep track onchain of what versions of the rollup have existed as well as what version the Aztec governance views as the current canonical rollup. Only the current canonical rollup from the perspective of Aztec governance will be eligible to claim any further Hypothetical Asset rewards. @@ -107,9 +107,9 @@ contract Registry is IRegistry, Ownable { This contract distributes ERC20 rewards only to the instance the Registry contract says is canonical. This is separated from the Registry and the Issuer so that the distribution logic can be changed without replacing the Registry. -In practice, the flow is expected to be such that infrequently, the Aztec Governance votes that the Issuer smart contract mints a quantity of Hypothetical Asset and sends them to the Distribution contract. The rollup contract will call the `claim(_to)` on the Distribution contract which checks that the calling Rollup is the current canonical Rollup before releasing a Hypothetical Asset to the rollup. +In practice, the following flow is expected. Infrequently, the Aztec Governance votes for the Issuer smart contract to mint a quantity of Hypothetical Asset and send them to the Distribution contract. The rollup contract will call `claim(_to)` on the Distribution contract. This checks that the calling Rollup is the current canonical Rollup before releasing a Hypothetical Asset to the rollup. -The Rollup smart contract implements custom logic for how to split `BLOCK_REWARDS` amongst the proposers/committee/provers who provide real work in the form of electricity and hardware intensive computational resources to the Rollup smart contract. +The Rollup smart contract implements custom logic for how to split `BLOCK_REWARDS` amongst the proposers/committee/provers who provide real work in the form of electricity and hardware intensive computational resources to the Rollup smart contract. ```mermaid flowchart TD @@ -142,13 +142,13 @@ contract RewardDistribution is Ownable { Rollup contacts implementations should not revert if the `claim()` call reverts because the rollup is no longer canonical. Otherwise, no one could sequence the rollup anymore. -The separation of Distribution and Issuer is primarily for code hygiene purposes. +The separation of Distribution and Issuer is primarily for code hygiene purposes. The protocol inflation rate is defined in the Issuer smart contract as the constant `RATE`. It is not possible to change this inflation rate once the Issuer smart contract has been deployed. Aztec Governance can vote on a proposal to deploy a new Issuer smart contract that contains a new `RATE` -The Aztec Governance will choose how often to call `mint()` on the Issuer smart contract which will send any Hypothetical Assets to the Distribution smart contract. The Distribution smart contract defines a `BLOCK_REWARD` constant value (again cannot be changed). Every epoch, the Rollup contract can call the Distribution smart contract to claim `BLOCK_REWARD` of Hypothetical Assets from the Distribution contract. +The Aztec Governance will choose how often to call `mint()` on the Issuer smart contract which will send any Hypothetical Assets to the Distribution smart contract. The Distribution smart contract defines a `BLOCK_REWARD` constant value (again cannot be changed). Every epoch, the Rollup contract can call the Distribution smart contract to claim `BLOCK_REWARD` of Hypothetical Assets from the Distribution contract. -Both `RATE` and `BLOCK_REWARD` will be set upon deployment of the Aztec Rollup by the Aztec Governance. Both values are immutable and cannot be changed without re-deploying a new smart contract and a successful vote by Aztec Governance to switch to the new smart contracts. +Both `RATE` and `BLOCK_REWARD` will be set upon deployment of the Aztec Rollup by the Aztec Governance. Both values are immutable and cannot be changed without re-deploying a new smart contract and a successful vote by Aztec Governance to switch to the new smart contracts. ## Proposals contract @@ -201,7 +201,7 @@ If the quorum has been reahed, anyone can call `pushProposal(uint256 _roundNumbe ## Governance contract -This contract is the “assembly of Aztec citizensˮ that is the final arbiter of whether to enact the proposals from the Proposals Contract or not. +This contract is the “assembly of Aztec citizensˮ that is the final arbiter of whether to enact the proposals from the Proposals Contract or not. This contract decides what is the canonical instance which gets block rewards. diff --git a/docs/docs/run_node/concepts/governance/_category_.json b/docs/docs/the_aztec_network/concepts/governance/_category_.json similarity index 100% rename from docs/docs/run_node/concepts/governance/_category_.json rename to docs/docs/the_aztec_network/concepts/governance/_category_.json diff --git a/docs/docs/run_node/concepts/governance/governance.md b/docs/docs/the_aztec_network/concepts/governance/governance.md similarity index 85% rename from docs/docs/run_node/concepts/governance/governance.md rename to docs/docs/the_aztec_network/concepts/governance/governance.md index 883d43d73f0e..7fef2e4e2b19 100644 --- a/docs/docs/run_node/concepts/governance/governance.md +++ b/docs/docs/the_aztec_network/concepts/governance/governance.md @@ -12,6 +12,6 @@ This diagram outlines how governance works on Aztec: Sequencers put forward, or “nominate”, proposals for voting by the Aztec citizens. To do this, sequencers interact with the Governance Proposer smart contract. Nominations are “signals” by sequencers that they wish to put up for vote the execution of certain code by the Governance smart contract. -If the Governance Proposer smart contract records a certain number of nominations/signals from sequencers, then the Governance Proposer smart contract initiates a voting process where any holders of any Hypothetical Assets (as defined below) can participate. Holders of such Hypothetical Assets are called Aztec citizens. +If the Governance Proposer smart contract records a certain number of nominations/signals from sequencers, then the Governance Proposer smart contract initiates a voting process where any holders of any Hypothetical Assets can participate. All voting and signalling happen on the L1. diff --git a/docs/docs/the_aztec_network/concepts/governance/putting_forward_proposals.md b/docs/docs/the_aztec_network/concepts/governance/putting_forward_proposals.md new file mode 100644 index 000000000000..d371897e4475 --- /dev/null +++ b/docs/docs/the_aztec_network/concepts/governance/putting_forward_proposals.md @@ -0,0 +1,17 @@ +--- +sidebar_position: 0 +title: Putting forward Proposals +--- + +Sequencers of the _current_ canonical rollup (as indicated by the Registry) can propose changes to the Aztec community for voting. In order for a proposal to be voted on through the governance process, _N_ sequencers must nominate the proposal in any given round. A round is defined as a sequence of contiguous _M_ L2 blocks. Both _N_ and _M_ are governance defined parameters. + +Sequencers can only nominate a proposal during an L2 slot for which they’ve been assigned proposer duties. This minimizes timing games and provides a lower bound on the time required to successfully bring about a vote by governance. + +A mechanism is also proposed whereby any Hypothetical Asset holder (“Holderˮ) can burn a large quantity of Hypothetical Asset to trigger a vote on a proposal, without having the sequencers nominating the proposal. Note that Hypothetical Asset holders would still need to vote to approve any proposals nominated via this mechanism. + +To nominate a proposal, a validator of the current canonical rollup would deploy two sets of contracts: + +1. The upgraded contracts they wish to upgrade to +2. `code` which can be executed by governance to upgrade into these contracts + +Then when it is their turn as the proposer, they call `vote(address _proposal)` on the `Proposals` contract, where `_proposal ` is the address of the `code` payload. Alternatively, validators can set the `GOVERNANCE_PROPOSAL_PAYLOAD=_proposal` env variable which will call `vote(address _proposal)` during a slot they're eligible to signal in. diff --git a/docs/docs/run_node/concepts/governance/upgrades.md b/docs/docs/the_aztec_network/concepts/governance/upgrades.md similarity index 81% rename from docs/docs/run_node/concepts/governance/upgrades.md rename to docs/docs/the_aztec_network/concepts/governance/upgrades.md index 08bd1910cec6..c7de1d5b9e76 100644 --- a/docs/docs/run_node/concepts/governance/upgrades.md +++ b/docs/docs/the_aztec_network/concepts/governance/upgrades.md @@ -7,7 +7,7 @@ Upgrades involve transitioning the network to a new instance of the Rollup contr ## AZIP -It is expected that the community will coordinate upgrade proposals via an AZIP process, which is a design document outlining the upgrade rationale and one that allows for collecting technical input from and by the community. +It is expected that the community will coordinate upgrade proposals via an AZIP process, which is a design document outlining the upgrade rationale and one that allows for collecting technical input from and by the community. Once developers of client software agree to support the upgrade, sequencers can begin signaling to table this proposal from a certain block height. @@ -18,16 +18,18 @@ The initial deployment creates a set of contracts, as described in the [Deployme ## Upgrading the Rollup Contract 1. **Proposal Creation:** + - A new Rollup contract is deployed to the network - Proposal code to execute the upgrade is deployed separately -2. **Governance Approval:** - - Governance contract holders vote to approve or reject the proposal. Votes are proportional to the amount of Hypothetical Asset locked in the Governance contract. +2. **Sequencer Participation:** -3. **Sequencer Participation:** - Sequencers must signal their readiness by voting through the Proposals contract. - This vote occurs during their assigned L2 slot, as dictated by the L1 Rollup smart contract. +3. **Governance Approval:** + - Hypothetical Asset holders vote to approve or reject the proposal. Votes are proportional to the amount of Hypothetical Asset locked in the Governance contract. + ## Proposal Execution After governance approval and a delay period, the proposal becomes executable: @@ -35,4 +37,4 @@ After governance approval and a delay period, the proposal becomes executable: - Any Ethereum account can call `execute(_proposalId)` on the Governance contract. - The `execute` function calls the proposal code, transitioning the network to the new Rollup instance. -For a more hands-on guide to reacting to upgrades as a sequencer/validators, read [this](../../guides/reacting_to_upgrades.md). \ No newline at end of file +For a more hands-on guide to reacting to upgrades as a sequencer/validators, read [this](../../guides/reacting_to_upgrades.md). diff --git a/docs/docs/run_node/concepts/governance/voting.md b/docs/docs/the_aztec_network/concepts/governance/voting.md similarity index 100% rename from docs/docs/run_node/concepts/governance/voting.md rename to docs/docs/the_aztec_network/concepts/governance/voting.md diff --git a/docs/docs/run_node/concepts/proof_of_stake/_category_.json b/docs/docs/the_aztec_network/concepts/proof_of_stake/_category_.json similarity index 100% rename from docs/docs/run_node/concepts/proof_of_stake/_category_.json rename to docs/docs/the_aztec_network/concepts/proof_of_stake/_category_.json diff --git a/docs/docs/run_node/concepts/proof_of_stake/index.md b/docs/docs/the_aztec_network/concepts/proof_of_stake/index.md similarity index 100% rename from docs/docs/run_node/concepts/proof_of_stake/index.md rename to docs/docs/the_aztec_network/concepts/proof_of_stake/index.md diff --git a/docs/docs/run_node/concepts/proof_of_stake/slashing.md b/docs/docs/the_aztec_network/concepts/proof_of_stake/slashing.md similarity index 85% rename from docs/docs/run_node/concepts/proof_of_stake/slashing.md rename to docs/docs/the_aztec_network/concepts/proof_of_stake/slashing.md index f54eaf05aaba..61e0752bd431 100644 --- a/docs/docs/run_node/concepts/proof_of_stake/slashing.md +++ b/docs/docs/the_aztec_network/concepts/proof_of_stake/slashing.md @@ -4,10 +4,10 @@ title: Slashing draft: true --- -We need to make sure that the chain is always (eventually) finalizing new blocks. -These conditions are required for the chain to finalize new blocks: +We need to make sure that the chain is always (eventually) finalizing new blocks. +The following conditions are required for the chain to finalize new blocks: -1. More than 2/3 of the committee is making attestations +1. More than 2/3 of the committee is making attestations 2. Provers are producing proofs. ## Avoiding network halt @@ -16,13 +16,13 @@ There are some actions that impact the chainʼs ability to finalize new blocks: ### Insufficient quorum -In the event that a significant portion of the validator set goes offline (i.e. geopolitical emergency) and proposers are unable to get enough attestations on block proposals, the Aztec Rollup will be unable to finalize new blocks. This will require the community to engage to fix the issue and make sure new blocks are being finalized. +In the event that a significant portion of the validator set goes offline (i.e. large internet outage) and proposers are unable to get enough attestations on block proposals, the Aztec Rollup will be unable to finalize new blocks. This will require the community to engage to fix the issue and make sure new blocks are being finalized. In the event of a prolonged period where the Aztec Rollup is not finalizing new blocks, it may enter Based Fallback mode. The conditions that lead to [Based Fallback (forum link)](https://forum.aztec.network/t/request-for-comments-aztecs-block-production-system/6155) mode are expected to be well defined by the community of sequencers, provers, client teams and all other Aztec Rollup stakeholders and participants. -During Based Fallback mode, anyone can propose blocks if they supply proofs for these blocks alongside them. This is in contrast to the usual condition that only the sequencer assigned to a particular slot can propose blocks during that slot. This means that the inactive validator set is bypassed and anyone can advance the chain in the event of an inactive / non-participating validator set. +During Based Fallback mode, anyone can propose blocks if they supply proofs for these blocks alongside them. This is in contrast to the usual condition that only the sequencer assigned to a particular slot can propose blocks during that slot. This means that the inactive validator set is bypassed and anyone can advance the chain in the event of an inactive / non-participating validator set. -But terminally inactive validators must be removed from the validator set or otherwise we end up in Based Fallback too often. Slashing is a method whereby the validator set votes to “slash” the stake of inactive validators down to a point where they are kicked off the validator set. For example, if we set `MINIMUM_STAKING_BALANCE=50%` then as soon as 50% or more of a validator’s balance is slashed, they will be kicked out of the set. +But terminally inactive validators must be removed from the validator set or otherwise we end up in Based Fallback too often. Slashing is a method whereby the validator set votes to “slash” the stake of inactive validators down to a point where they are kicked off the validator set. For example, if we set `MINIMUM_STAKING_BALANCE=50%` then as soon as 50% or more of a validator’s balance is slashed, they will be kicked out of the set. ### Committee withholding data from the provers @@ -30,11 +30,11 @@ Provers need the transaction data (i.e. `TxObjects`) plus the client-side genera Recall from the [RFC (forum link)](https://forum.aztec.network/t/request-for-comments-aztecs-block-production-system/6155) on block production that the committee is a subset of validators, randomly sampled from the entire validator set. Block proposers are sampled from this committee. ⅔ + 1 of this committee must attest to L2 block proposals before they are posted to the L1 by the block proposer. -A malicious committee may not gossip the transaction data or proofs to the rest of the validator set, nor to the provers. As a result, no prover can produce the proof and the epoch in question will reorg by design.Recall from the RFC on block production that if no proof for epoch N is submitted to L1 by the end of epoch N+1, then epoch N + any blocks built in epoch N+1 are reorged. +A malicious committee may not gossip the transaction data or proofs to the rest of the validator set, nor to the provers. As a result, no prover can produce the proof and the epoch in question will reorg by design. Recall from the RFC on block production that if no proof for epoch N is submitted to L1 by the end of epoch N+1, then epoch N + any blocks built in epoch N+1 are reorged. ### Committee proposing an invalid state root -Committee members who receive a block proposal from a proposer, must execute the block’s transaction to compare the resulting state root with that contained in the proposal. In theory, a committee member should only attest to a block proposal’s validity after checking for the correctness of the state root. +Committee members who receive a block proposal from a proposer, must execute the block’s transaction to compare the resulting state root with that contained in the proposal. In theory, a committee member should only attest to a block proposal’s validity after checking for the correctness of the state root. A committee member could skip re-executing block proposals, for a number of reasons including saving compute, faulty client software or maliciousness. This opens up the possibility of a malicious proposer posting an invalid state transition to L1. Or a malicious entity that bribes ⅔ + 1 of the committee can obtain the required signatures to post an invalid state transition. The epoch will not be proven and will be re-orged. diff --git a/docs/docs/run_node/concepts/provers-and-sequencers/_category_.json b/docs/docs/the_aztec_network/concepts/provers-and-sequencers/_category_.json similarity index 100% rename from docs/docs/run_node/concepts/provers-and-sequencers/_category_.json rename to docs/docs/the_aztec_network/concepts/provers-and-sequencers/_category_.json diff --git a/docs/docs/run_node/concepts/provers-and-sequencers/index.md b/docs/docs/the_aztec_network/concepts/provers-and-sequencers/index.md similarity index 92% rename from docs/docs/run_node/concepts/provers-and-sequencers/index.md rename to docs/docs/the_aztec_network/concepts/provers-and-sequencers/index.md index 262874206b5f..5b7a43f8c724 100644 --- a/docs/docs/run_node/concepts/provers-and-sequencers/index.md +++ b/docs/docs/the_aztec_network/concepts/provers-and-sequencers/index.md @@ -1,13 +1,14 @@ --- sidebar_position: 0 title: Provers and Sequencers +draft: true --- ## Block Production Overview -Both sequencing and proving in the Aztec Network are intended to be fully decentralized. +Both sequencing and proving in the Aztec Network are intended to be fully decentralized. -Sequencers will be chosen via a random election, while provers will be selected by sequencers via an out-of-protocol coordination mechanism. +Sequencers will be chosen via a random election, while provers will be selected by sequencers via an out-of-protocol coordination mechanism. The proposers in the first `C=13` slots in epoch `N+1` will accept quotes to prove epoch N from provers. The winning prover will have until the end of epoch `N+1` to produce and submit the proof to L1. diff --git a/docs/docs/run_node/concepts/provers-and-sequencers/proving_coordination_workflow.md b/docs/docs/the_aztec_network/concepts/provers-and-sequencers/proving_coordination_workflow.md similarity index 98% rename from docs/docs/run_node/concepts/provers-and-sequencers/proving_coordination_workflow.md rename to docs/docs/the_aztec_network/concepts/provers-and-sequencers/proving_coordination_workflow.md index 2b7f6ddebc6a..53b427cc3783 100644 --- a/docs/docs/run_node/concepts/provers-and-sequencers/proving_coordination_workflow.md +++ b/docs/docs/the_aztec_network/concepts/provers-and-sequencers/proving_coordination_workflow.md @@ -1,6 +1,6 @@ --- sidebar_position: 1 -title: Proving Coordination Workflow +title: Prover Coordination Workflow draft: true --- @@ -105,4 +105,4 @@ The Prover Node will call this method at least once per L2 slot to check for unc ## Run a prover -Go to the [Prover Guide](../../guides/run_nodes/how_to_run_prover.md) to run a prover. \ No newline at end of file +Go to the [Prover Guide](../../guides/run_nodes/how_to_run_prover.md) to run a prover. diff --git a/docs/docs/run_node/guides/_category_.json b/docs/docs/the_aztec_network/guides/_category_.json similarity index 100% rename from docs/docs/run_node/guides/_category_.json rename to docs/docs/the_aztec_network/guides/_category_.json diff --git a/docs/docs/the_aztec_network/guides/reacting_to_upgrades.md b/docs/docs/the_aztec_network/guides/reacting_to_upgrades.md new file mode 100644 index 000000000000..9f0eb085b2a1 --- /dev/null +++ b/docs/docs/the_aztec_network/guides/reacting_to_upgrades.md @@ -0,0 +1,20 @@ +--- +sidebar_position: 4 +title: Reacting to upgrades +--- + +This is a guide for sequencer operators to understand how to react to protocol upgrades. To learn about how upgrades work, read the [concept section](../concepts/governance/upgrades.md). + +## Sequencers signal for governance upgrades + +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. + +:::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 alpha-testnet will be communicated to sequencers on the forum and on community channels like discord. +::: + +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. + +:::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. +::: diff --git a/docs/docs/run_node/guides/run_nodes/_category_.json b/docs/docs/the_aztec_network/guides/run_nodes/_category_.json similarity index 100% rename from docs/docs/run_node/guides/run_nodes/_category_.json rename to docs/docs/the_aztec_network/guides/run_nodes/_category_.json diff --git a/docs/docs/the_aztec_network/guides/run_nodes/cli_reference.md b/docs/docs/the_aztec_network/guides/run_nodes/cli_reference.md new file mode 100644 index 000000000000..eba3fc1450c4 --- /dev/null +++ b/docs/docs/the_aztec_network/guides/run_nodes/cli_reference.md @@ -0,0 +1,709 @@ +--- +sidebar_position: 3 +title: Cli Reference +description: A reference of the --help output when running aztec start. +keywords: + [ + aztec, + prover, + node, + blockchain, + L2, + scaling, + ethereum, + zero-knowledge, + ZK, + setup, + ] +tags: + - prover + - node + - tutorial + - infrastructure +--- + +:::note +The environment variable name corresponding to each flag is shown as $ENV_VAR on the right hand side. + +If two subsystems can contain the same configuration option, only one needs to be provided. e.g. `--archiver.blobSinkUrl` and `--sequencer.blobSinkUrl` point to the same value if the node is started with both the `--archiver` and `--sequencer` options. +::: + +```bash + NETWORK + + --network ($NETWORK) + Network to run Aztec on + + API + + --port (default: 8080) ($AZTEC_PORT) + Port to run the Aztec Services on + + --admin-port (default: 8880) ($AZTEC_ADMIN_PORT) + Port to run admin APIs of Aztec Services on on + + --api-prefix ($API_PREFIX) + Prefix for API routes on any service that is started + + ETHEREUM + + --l1-rpc-urls (default: http://localhost:8545) ($ETHEREUM_HOSTS) + List of URLs of the Ethereum RPC nodes that services will connect to (comma separated) + + --l1-chain-id (default: 31337) ($L1_CHAIN_ID) + The L1 chain ID + + --l1-mnemonic (default: test test test test test test test test test test test junk)($MNEMONIC) + Mnemonic for L1 accounts. Will be used if no publisher private keys are provided + + --l1-consensus-host-urls (default: ) ($L1_CONSENSUS_HOST_URLS) + List of URLs of the Ethereum consensus nodes that services will connect to (comma separated) + + --l1-consensus-host-api-keys (default: ) ($L1_CONSENSUS_HOST_API_KEYS) + List of API keys for the corresponding Ethereum consensus nodes + + --l1-consensus-host-api-key-headers (default: ) ($L1_CONSENSUS_HOST_API_KEY_HEADERS) + List of API key headers for the corresponding Ethereum consensus nodes. If not set, the api key for the corresponding node will be appended to the URL as ?key= + + STORAGE + + --data-directory ($DATA_DIRECTORY) + Where to store data for services. If not set, will store temporarily + + --data-store-map-size-kb ($DATA_STORE_MAP_SIZE_KB) + The maximum possible size of the data store DB in KB. Can be overridden by component-specific options. + + L1 CONTRACT ADDRESSES + + --rollup-address ($ROLLUP_CONTRACT_ADDRESS) + The deployed L1 rollup contract address + + --registry-address ($REGISTRY_CONTRACT_ADDRESS) + The deployed L1 registry contract address + + --inbox-address ($INBOX_CONTRACT_ADDRESS) + The deployed L1 -> L2 inbox contract address + + --outbox-address ($OUTBOX_CONTRACT_ADDRESS) + The deployed L2 -> L1 outbox contract address + + --fee-juice-address ($FEE_JUICE_CONTRACT_ADDRESS) + The deployed L1 Fee Juice contract address + + --staking-asset-address ($STAKING_ASSET_CONTRACT_ADDRESS) + The deployed L1 Staking Asset contract address + + --fee-juice-portal-address ($FEE_JUICE_PORTAL_CONTRACT_ADDRESS) + The deployed L1 Fee Juice portal contract address + + AZTEC NODE + + --node + Starts Aztec Node with options + + --node.archiverUrl ($ARCHIVER_URL) + URL for an archiver service + + --node.deployAztecContracts ($DEPLOY_AZTEC_CONTRACTS) + Deploys L1 Aztec contracts before starting the node. Needs mnemonic or private key to be set. + + --node.deployAztecContractsSalt ($DEPLOY_AZTEC_CONTRACTS_SALT) + Numeric salt for deploying L1 Aztec contracts before starting the node. Needs mnemonic or private key to be set. Implies --node.deployAztecContracts. + + --node.assumeProvenThroughBlockNumber ($ASSUME_PROVEN_THROUGH_BLOCK_NUMBER) + Cheats the rollup contract into assuming every block until this one is proven. Useful for speeding up bootstraps. + + --node.publisherPrivateKey ($L1_PRIVATE_KEY) + Private key of account for publishing L1 contracts + + --node.worldStateBlockCheckIntervalMS (default: 100) ($WS_BLOCK_CHECK_INTERVAL_MS) + Frequency in which to check for blocks in ms + + --node.syncMode (default: snapshot) ($SYNC_MODE) + Set sync mode to `full` to always sync via L1, `snapshot` to download a snapshot if there is no local data, `force-snapshot` to download even if there is local data. + + --node.snapshotsUrl ($SYNC_SNAPSHOTS_URL) + Base URL for downloading snapshots for snapshot sync. + + P2P SUBSYSTEM + + --p2p-enabled [value] ($P2P_ENABLED) + Enable P2P subsystem + + --p2p.blockCheckIntervalMS (default: 100) ($P2P_BLOCK_CHECK_INTERVAL_MS) + The frequency in which to check for new L2 blocks. + + --p2p.debugDisableColocationPenalty ($DEBUG_P2P_DISABLE_COLOCATION_PENALTY) + DEBUG: Disable colocation penalty - NEVER set to true in production + + --p2p.peerCheckIntervalMS (default: 30000) ($P2P_PEER_CHECK_INTERVAL_MS) + The frequency in which to check for new peers. + + --p2p.l2QueueSize (default: 1000) ($P2P_L2_QUEUE_SIZE) + Size of queue of L2 blocks to store. + + --p2p.listenAddress (default: 0.0.0.0) ($P2P_LISTEN_ADDR) + The listen address. ipv4 address. + + --p2p.p2pPort (default: 40400) ($P2P_PORT) + The port for the P2P service. + + --p2p.p2pIp ($P2P_IP) + The IP address for the P2P service. ipv4 address. + + --p2p.peerIdPrivateKey ($PEER_ID_PRIVATE_KEY) + An optional peer id private key. If blank, will generate a random key. + + --p2p.bootstrapNodes (default: ) ($BOOTSTRAP_NODES) + A list of bootstrap peer ENRs to connect to. Separated by commas. + + --p2p.bootstrapNodeEnrVersionCheck ($P2P_BOOTSTRAP_NODE_ENR_VERSION_CHECK) + Whether to check the version of the bootstrap node ENR. + + --p2p.bootstrapNodesAsFullPeers ($P2P_BOOTSTRAP_NODES_AS_FULL_PEERS) + Whether to consider our configured bootnodes as full peers + + --p2p.maxPeerCount (default: 100) ($P2P_MAX_PEERS) + The maximum number of peers to connect to. + + --p2p.queryForIp ($P2P_QUERY_FOR_IP) + If announceUdpAddress or announceTcpAddress are not provided, query for the IP address of the machine. Default is false. + + --p2p.keepProvenTxsInPoolFor ($P2P_TX_POOL_KEEP_PROVEN_FOR) + How many blocks have to pass after a block is proven before its txs are deleted (zero to delete immediately once proven) + + --p2p.keepAttestationsInPoolFor (default: 96) ($P2P_ATTESTATION_POOL_KEEP_FOR) + How many slots to keep attestations for. + + --p2p.gossipsubInterval (default: 700) ($P2P_GOSSIPSUB_INTERVAL_MS) + The interval of the gossipsub heartbeat to perform maintenance tasks. + + --p2p.gossipsubD (default: 8) ($P2P_GOSSIPSUB_D) + The D parameter for the gossipsub protocol. + + --p2p.gossipsubDlo (default: 4) ($P2P_GOSSIPSUB_DLO) + The Dlo parameter for the gossipsub protocol. + + --p2p.gossipsubDhi (default: 12) ($P2P_GOSSIPSUB_DHI) + The Dhi parameter for the gossipsub protocol. + + --p2p.gossipsubDLazy (default: 8) ($P2P_GOSSIPSUB_DLAZY) + The Dlazy parameter for the gossipsub protocol. + + --p2p.gossipsubFloodPublish (default: true) ($P2P_GOSSIPSUB_FLOOD_PUBLISH) + Whether to flood publish messages. - For testing purposes only + + --p2p.gossipsubMcacheLength (default: 6) ($P2P_GOSSIPSUB_MCACHE_LENGTH) + The number of gossipsub interval message cache windows to keep. + + --p2p.gossipsubMcacheGossip (default: 3) ($P2P_GOSSIPSUB_MCACHE_GOSSIP) + How many message cache windows to include when gossiping with other pears. + + --p2p.gossipsubTxTopicWeight (default: 1) ($P2P_GOSSIPSUB_TX_TOPIC_WEIGHT) + The weight of the tx topic for the gossipsub protocol. + + --p2p.gossipsubTxInvalidMessageDeliveriesWeight (default: -20) ($P2P_GOSSIPSUB_TX_INVALID_MESSAGE_DELIVERIES_WEIGHT) + The weight of the tx invalid message deliveries for the gossipsub protocol. + + --p2p.gossipsubTxInvalidMessageDeliveriesDecay (default: 0.5) ($P2P_GOSSIPSUB_TX_INVALID_MESSAGE_DELIVERIES_DECAY) + Determines how quickly the penalty for invalid message deliveries decays over time. Between 0 and 1. + + --p2p.peerPenaltyValues (default: 2,10,50) ($P2P_PEER_PENALTY_VALUES) + The values for the peer scoring system. Passed as a comma separated list of values in order: low, mid, high tolerance errors. + + --p2p.doubleSpendSeverePeerPenaltyWindow (default: 30) ($P2P_DOUBLE_SPEND_SEVERE_PEER_PENALTY_WINDOW) + The "age" (in L2 blocks) of a tx after which we heavily penalize a peer for sending it. + + --p2p.blockRequestBatchSize (default: 20) ($P2P_BLOCK_REQUEST_BATCH_SIZE) + The number of blocks to fetch in a single batch. + + --p2p.archivedTxLimit ($P2P_ARCHIVED_TX_LIMIT) + The number of transactions that will be archived. If the limit is set to 0 then archiving will be disabled. + + --p2p.trustedPeers (default: ) ($P2P_TRUSTED_PEERS) + A list of trusted peers ENRs. Separated by commas. + + --p2p.p2pStoreMapSizeKb ($P2P_STORE_MAP_SIZE_KB) + The maximum possible size of the P2P DB in KB. Overwrites the general dataStoreMapSizeKB. + + --p2p.txPublicSetupAllowList ($TX_PUBLIC_SETUP_ALLOWLIST) + The list of functions calls allowed to run in setup + + --p2p.maxTxPoolSize (default: 100000000) ($P2P_MAX_TX_POOL_SIZE) + The maximum cumulative tx size of pending txs (in bytes) before evicting lower priority txs. + + --p2p.overallRequestTimeoutMs (default: 4000) ($P2P_REQRESP_OVERALL_REQUEST_TIMEOUT_MS) + The overall timeout for a request response operation. + + --p2p.individualRequestTimeoutMs (default: 2000) ($P2P_REQRESP_INDIVIDUAL_REQUEST_TIMEOUT_MS) + The timeout for an individual request response peer interaction. + + --p2p.rollupVersion ($ROLLUP_VERSION) + The version of the rollup. + + TELEMETRY + + --tel.metricsCollectorUrl ($OTEL_EXPORTER_OTLP_METRICS_ENDPOINT) + The URL of the telemetry collector for metrics + + --tel.tracesCollectorUrl ($OTEL_EXPORTER_OTLP_TRACES_ENDPOINT) + The URL of the telemetry collector for traces + + --tel.logsCollectorUrl ($OTEL_EXPORTER_OTLP_LOGS_ENDPOINT) + The URL of the telemetry collector for logs + + --tel.otelCollectIntervalMs (default: 60000) ($OTEL_COLLECT_INTERVAL_MS) + The interval at which to collect metrics + + --tel.otelExportTimeoutMs (default: 30000) ($OTEL_EXPORT_TIMEOUT_MS) + The timeout for exporting metrics + + --tel.otelExcludeMetrics (default: ) ($OTEL_EXCLUDE_METRICS) + A list of metric prefixes to exclude from export + + PXE + + --pxe + Starts Aztec PXE with options + + --pxe.dataStoreMapSizeKB (default: 134217728) ($DATA_STORE_MAP_SIZE_KB) + DB mapping size to be applied to all key/value stores + + --pxe.rollupVersion ($ROLLUP_VERSION) + The version of the rollup. + + --pxe.l2StartingBlock (default: 1) ($PXE_L2_STARTING_BLOCK) + L2 block to start scanning from for new accounts + + --pxe.l2BlockBatchSize (default: 200) ($PXE_L2_BLOCK_BATCH_SIZE) + Maximum amount of blocks to pull from the stream in one request when synchronizing + + --pxe.bbBinaryPath ($BB_BINARY_PATH) + Path to the BB binary + + --pxe.bbWorkingDirectory ($BB_WORKING_DIRECTORY) + Working directory for the BB binary + + --pxe.bbSkipCleanup ($BB_SKIP_CLEANUP) + True to skip cleanup of temporary files for debugging purposes + + --pxe.proverEnabled (default: true) ($PXE_PROVER_ENABLED) + Enable real proofs + + --pxe.network ($NETWORK) + External Aztec network to connect to. e.g. devnet + + --pxe.apiKey ($API_KEY) + API Key required by the external network's node + + --pxe.nodeUrl ($AZTEC_NODE_URL) + Custom Aztec Node URL to connect to + + ARCHIVER + + --archiver + Starts Aztec Archiver with options + + --archiver.blobSinkUrl ($BLOB_SINK_URL) + The URL of the blob sink + + --archiver.archiveApiUrl ($BLOB_SINK_ARCHIVE_API_URL) + The URL of the archive API + + --archiver.archiverPollingIntervalMS (default: 500) ($ARCHIVER_POLLING_INTERVAL_MS) + The polling interval in ms for retrieving new L2 blocks and encrypted logs. + + --archiver.archiverBatchSize (default: 100) ($ARCHIVER_BATCH_SIZE) + The number of L2 blocks the archiver will attempt to download at a time. + + --archiver.maxLogs (default: 1000) ($ARCHIVER_MAX_LOGS) + The max number of logs that can be obtained in 1 "getPublicLogs" call. + + --archiver.archiverStoreMapSizeKb ($ARCHIVER_STORE_MAP_SIZE_KB) + The maximum possible size of the archiver DB in KB. Overwrites the general dataStoreMapSizeKB. + + --archiver.rollupVersion ($ROLLUP_VERSION) + The version of the rollup. + + --archiver.viemPollingIntervalMS (default: 1000) ($ARCHIVER_VIEM_POLLING_INTERVAL_MS) + The polling interval viem uses in ms + + --archiver.ethereumSlotDuration (default: 12) ($ETHEREUM_SLOT_DURATION) + How many seconds an L1 slot lasts. + + --archiver.aztecSlotDuration (default: 24) ($AZTEC_SLOT_DURATION) + How many seconds an L2 slots lasts (must be multiple of ethereum slot duration). + + --archiver.aztecEpochDuration (default: 16) ($AZTEC_EPOCH_DURATION) + How many L2 slots an epoch lasts (maximum AZTEC_MAX_EPOCH_DURATION). + + --archiver.aztecTargetCommitteeSize (default: 48) ($AZTEC_TARGET_COMMITTEE_SIZE) + The target validator committee size. + + --archiver.aztecProofSubmissionWindow (default: 31) ($AZTEC_PROOF_SUBMISSION_WINDOW) + The number of L2 slots that a proof for an epoch can be submitted in, starting from the beginning of the epoch. + + --archiver.minimumStake (default: 100000000000000000000) ($AZTEC_MINIMUM_STAKE) + The minimum stake for a validator. + + --archiver.slashingQuorum (default: 6) ($AZTEC_SLASHING_QUORUM) + The slashing quorum + + --archiver.slashingRoundSize (default: 10) ($AZTEC_SLASHING_ROUND_SIZE) + The slashing round size + + --archiver.governanceProposerQuorum (default: 51) ($AZTEC_GOVERNANCE_PROPOSER_QUORUM) + The governance proposing quorum + + --archiver.governanceProposerRoundSize (default: 100) ($AZTEC_GOVERNANCE_PROPOSER_ROUND_SIZE) + The governance proposing round size + + --archiver.manaTarget (default: 10000000000) ($AZTEC_MANA_TARGET) + The mana target for the rollup + + --archiver.provingCostPerMana (default: 100) ($AZTEC_PROVING_COST_PER_MANA) + The proving cost per mana + + --archiver.gasLimitBufferPercentage (default: 20) ($L1_GAS_LIMIT_BUFFER_PERCENTAGE) + How much to increase calculated gas limit by (percentage) + + --archiver.maxGwei (default: 500) ($L1_GAS_PRICE_MAX) + Maximum gas price in gwei + + --archiver.maxBlobGwei (default: 1500) ($L1_BLOB_FEE_PER_GAS_MAX) + Maximum blob fee per gas in gwei + + --archiver.priorityFeeBumpPercentage (default: 20) ($L1_PRIORITY_FEE_BUMP_PERCENTAGE) + How much to increase priority fee by each attempt (percentage) + + --archiver.priorityFeeRetryBumpPercentage (default: 50) ($L1_PRIORITY_FEE_RETRY_BUMP_PERCENTAGE) + How much to increase priority fee by each retry attempt (percentage) + + --archiver.fixedPriorityFeePerGas ($L1_FIXED_PRIORITY_FEE_PER_GAS) + Fixed priority fee per gas in Gwei. Overrides any priority fee bump percentage + + --archiver.maxAttempts (default: 3) ($L1_TX_MONITOR_MAX_ATTEMPTS) + Maximum number of speed-up attempts + + --archiver.checkIntervalMs (default: 1000) ($L1_TX_MONITOR_CHECK_INTERVAL_MS) + How often to check tx status + + --archiver.stallTimeMs (default: 45000) ($L1_TX_MONITOR_STALL_TIME_MS) + How long before considering tx stalled + + --archiver.txTimeoutMs (default: 300000) ($L1_TX_MONITOR_TX_TIMEOUT_MS) + How long to wait for a tx to be mined before giving up. Set to 0 to disable. + + --archiver.txPropagationMaxQueryAttempts (default: 3) ($L1_TX_PROPAGATION_MAX_QUERY_ATTEMPTS) + How many attempts will be done to get a tx after it was sent + + SEQUENCER + + --sequencer + Starts Aztec Sequencer with options + + --sequencer.validatorPrivateKey ($VALIDATOR_PRIVATE_KEY) + The private key of the validator participating in attestation duties + + --sequencer.disableValidator ($VALIDATOR_DISABLED) + Do not run the validator + + --sequencer.attestationPollingIntervalMs (default: 200) ($VALIDATOR_ATTESTATIONS_POLLING_INTERVAL_MS) + Interval between polling for new attestations + + --sequencer.validatorReexecute (default: true) ($VALIDATOR_REEXECUTE) + Re-execute transactions before attesting + + --sequencer.transactionPollingIntervalMS (default: 500) ($SEQ_TX_POLLING_INTERVAL_MS) + The number of ms to wait between polling for pending txs. + + --sequencer.maxTxsPerBlock (default: 32) ($SEQ_MAX_TX_PER_BLOCK) + The maximum number of txs to include in a block. + + --sequencer.minTxsPerBlock (default: 1) ($SEQ_MIN_TX_PER_BLOCK) + The minimum number of txs to include in a block. + + --sequencer.maxL2BlockGas (default: 10000000000) ($SEQ_MAX_L2_BLOCK_GAS) + The maximum L2 block gas. + + --sequencer.maxDABlockGas (default: 10000000000) ($SEQ_MAX_DA_BLOCK_GAS) + The maximum DA block gas. + + --sequencer.coinbase ($COINBASE) + Recipient of block reward. + + --sequencer.feeRecipient ($FEE_RECIPIENT) + Address to receive fees. + + --sequencer.acvmWorkingDirectory ($ACVM_WORKING_DIRECTORY) + The working directory to use for simulation/proving + + --sequencer.acvmBinaryPath ($ACVM_BINARY_PATH) + The path to the ACVM binary + + --sequencer.maxBlockSizeInBytes (default: 1048576) ($SEQ_MAX_BLOCK_SIZE_IN_BYTES) + Max block size + + --sequencer.enforceTimeTable (default: true) ($SEQ_ENFORCE_TIME_TABLE) + Whether to enforce the time table when building blocks + + --sequencer.governanceProposerPayload (default: 0x0000000000000000000000000000000000000000) ($GOVERNANCE_PROPOSER_PAYLOAD_ADDRESS) + The address of the payload for the governanceProposer + + --sequencer.maxL1TxInclusionTimeIntoSlot ($SEQ_MAX_L1_TX_INCLUSION_TIME_INTO_SLOT) + How many seconds into an L1 slot we can still send a tx and get it mined. + + --sequencer.txPublicSetupAllowList ($TX_PUBLIC_SETUP_ALLOWLIST) + The list of functions calls allowed to run in setup + + --sequencer.viemPollingIntervalMS (default: 1000) ($L1_READER_VIEM_POLLING_INTERVAL_MS) + The polling interval viem uses in ms + + --sequencer.customForwarderContractAddress (default: 0x0000000000000000000000000000000000000000) ($CUSTOM_FORWARDER_CONTRACT_ADDRESS) + The address of the custom forwarder contract. + + --sequencer.publisherPrivateKey (default: 0x0000000000000000000000000000000000000000000000000000000000000000)($SEQ_PUBLISHER_PRIVATE_KEY) + The private key to be used by the publisher. + + --sequencer.l1PublishRetryIntervalMS (default: 1000) ($SEQ_PUBLISH_RETRY_INTERVAL_MS) + The interval to wait between publish retries. + + --sequencer.gasLimitBufferPercentage (default: 20) ($L1_GAS_LIMIT_BUFFER_PERCENTAGE) + How much to increase calculated gas limit by (percentage) + + --sequencer.maxGwei (default: 500) ($L1_GAS_PRICE_MAX) + Maximum gas price in gwei + + --sequencer.maxBlobGwei (default: 1500) ($L1_BLOB_FEE_PER_GAS_MAX) + Maximum blob fee per gas in gwei + + --sequencer.priorityFeeBumpPercentage (default: 20) ($L1_PRIORITY_FEE_BUMP_PERCENTAGE) + How much to increase priority fee by each attempt (percentage) + + --sequencer.priorityFeeRetryBumpPercentage (default: 50) ($L1_PRIORITY_FEE_RETRY_BUMP_PERCENTAGE) + How much to increase priority fee by each retry attempt (percentage) + + --sequencer.fixedPriorityFeePerGas ($L1_FIXED_PRIORITY_FEE_PER_GAS) + Fixed priority fee per gas in Gwei. Overrides any priority fee bump percentage + + --sequencer.maxAttempts (default: 3) ($L1_TX_MONITOR_MAX_ATTEMPTS) + Maximum number of speed-up attempts + + --sequencer.checkIntervalMs (default: 1000) ($L1_TX_MONITOR_CHECK_INTERVAL_MS) + How often to check tx status + + --sequencer.stallTimeMs (default: 45000) ($L1_TX_MONITOR_STALL_TIME_MS) + How long before considering tx stalled + + --sequencer.txTimeoutMs (default: 300000) ($L1_TX_MONITOR_TX_TIMEOUT_MS) + How long to wait for a tx to be mined before giving up. Set to 0 to disable. + + --sequencer.txPropagationMaxQueryAttempts (default: 3) ($L1_TX_PROPAGATION_MAX_QUERY_ATTEMPTS) + How many attempts will be done to get a tx after it was sent + + --sequencer.blobSinkUrl ($BLOB_SINK_URL) + The URL of the blob sink + + --sequencer.archiveApiUrl ($BLOB_SINK_ARCHIVE_API_URL) + The URL of the archive API + + --sequencer.rollupVersion ($ROLLUP_VERSION) + The version of the rollup. + + --sequencer.ethereumSlotDuration (default: 12) ($ETHEREUM_SLOT_DURATION) + How many seconds an L1 slot lasts. + + --sequencer.aztecSlotDuration (default: 24) ($AZTEC_SLOT_DURATION) + How many seconds an L2 slots lasts (must be multiple of ethereum slot duration). + + --sequencer.aztecEpochDuration (default: 16) ($AZTEC_EPOCH_DURATION) + How many L2 slots an epoch lasts (maximum AZTEC_MAX_EPOCH_DURATION). + + --sequencer.aztecProofSubmissionWindow (default: 31) ($AZTEC_PROOF_SUBMISSION_WINDOW) + The number of L2 slots that a proof for an epoch can be submitted in, starting from the beginning of the epoch. + + BLOB SINK + + --blob-sink + Starts Aztec Blob Sink with options + + --blobSink.port ($BLOB_SINK_PORT) + The port to run the blob sink server on + + --blobSink.archiveApiUrl ($BLOB_SINK_ARCHIVE_API_URL) + The URL of the archive API + + --blobSink.dataStoreMapSizeKB (default: 134217728) ($DATA_STORE_MAP_SIZE_KB) + DB mapping size to be applied to all key/value stores + + --blobSink.rollupVersion ($ROLLUP_VERSION) + The version of the rollup. + + --blobSink.viemPollingIntervalMS (default: 1000) ($L1_READER_VIEM_POLLING_INTERVAL_MS) + The polling interval viem uses in ms + + PROVER NODE + + --prover-node + Starts Aztec Prover Node with options + + --proverNode.archiverUrl ($ARCHIVER_URL) + URL for an archiver service + + --proverNode.acvmWorkingDirectory ($ACVM_WORKING_DIRECTORY) + The working directory to use for simulation/proving + + --proverNode.acvmBinaryPath ($ACVM_BINARY_PATH) + The path to the ACVM binary + + --proverNode.bbWorkingDirectory ($BB_WORKING_DIRECTORY) + The working directory to use for proving + + --proverNode.bbBinaryPath ($BB_BINARY_PATH) + The path to the bb binary + + --proverNode.bbSkipCleanup ($BB_SKIP_CLEANUP) + Whether to skip cleanup of bb temporary files + + --proverNode.nodeUrl ($AZTEC_NODE_URL) + The URL to the Aztec node to take proving jobs from + + --proverNode.proverId ($PROVER_ID) + Hex value that identifies the prover. Defaults to the address used for submitting proofs if not set. + + --proverNode.failedProofStore ($PROVER_FAILED_PROOF_STORE) + Store for failed proof inputs. Google cloud storage is only supported at the moment. Set this value as gs://bucket-name/path/to/store. + + --proverNode.worldStateBlockCheckIntervalMS (default: 100) ($WS_BLOCK_CHECK_INTERVAL_MS) + The frequency in which to check. + + --proverNode.worldStateProvenBlocksOnly ($WS_PROVEN_BLOCKS_ONLY) + Whether to follow only the proven chain. + + --proverNode.worldStateBlockRequestBatchSize ($WS_BLOCK_REQUEST_BATCH_SIZE) + Size of the batch for each get-blocks request from the synchronizer to the archiver. + + --proverNode.worldStateDbMapSizeKb ($WS_DB_MAP_SIZE_KB) + The maximum possible size of the world state DB in KB. Overwrites the general dataStoreMapSizeKB. + + --proverNode.worldStateDataDirectory ($WS_DATA_DIRECTORY) + Optional directory for the world state database + + --proverNode.worldStateBlockHistory (default: 64) ($WS_NUM_HISTORIC_BLOCKS) + The number of historic blocks to maintain. Values less than 1 mean all history is maintained + + --proverNode.l1PublishRetryIntervalMS (default: 1000) ($PROVER_PUBLISH_RETRY_INTERVAL_MS) + The interval to wait between publish retries. + + --proverNode.customForwarderContractAddress (default: 0x0000000000000000000000000000000000000000) ($CUSTOM_FORWARDER_CONTRACT_ADDRESS) + The address of the custom forwarder contract. + + --proverNode.publisherPrivateKey (default: 0x0000000000000000000000000000000000000000000000000000000000000000)($PROVER_PUBLISHER_PRIVATE_KEY) + The private key to be used by the publisher. + + --proverNode.proverCoordinationNodeUrl ($PROVER_COORDINATION_NODE_URL) + The URL of the tx provider node + + --proverNode.proverNodeMaxPendingJobs (default: 10) ($PROVER_NODE_MAX_PENDING_JOBS) + The maximum number of pending jobs for the prover node + + --proverNode.proverNodePollingIntervalMs (default: 1000) ($PROVER_NODE_POLLING_INTERVAL_MS) + The interval in milliseconds to poll for new jobs + + --proverNode.proverNodeMaxParallelBlocksPerEpoch (default: 32) ($PROVER_NODE_MAX_PARALLEL_BLOCKS_PER_EPOCH) + The Maximum number of blocks to process in parallel while proving an epoch + + --proverNode.txGatheringTimeoutMs (default: 60000) ($PROVER_NODE_TX_GATHERING_TIMEOUT_MS) + The maximum amount of time to wait for tx data to be available + + --proverNode.txGatheringIntervalMs (default: 1000) ($PROVER_NODE_TX_GATHERING_INTERVAL_MS) + How often to check that tx data is available + + --proverNode.txGatheringMaxParallelRequests (default: 100) ($PROVER_NODE_TX_GATHERING_MAX_PARALLEL_REQUESTS) + How many txs to load up a time + + --proverNode.testAccounts ($TEST_ACCOUNTS) + Whether to populate the genesis state with initial fee juice for the test accounts. + + --proverNode.sponsoredFPC ($SPONSORED_FPC) + Whether to populate the genesis state with initial fee juice for the sponsored FPC. + + --proverNode.syncMode (default: snapshot) ($SYNC_MODE) + Set sync mode to `full` to always sync via L1, `snapshot` to download a snapshot if there is no local data, `force-snapshot` to download even if there is local data. + + --proverNode.snapshotsUrl ($SYNC_SNAPSHOTS_URL) + Base URL for snapshots index. + + PROVER BROKER + + --prover-broker + Starts Aztec proving job broker + + --proverBroker.proverBrokerJobTimeoutMs (default: 30000) ($PROVER_BROKER_JOB_TIMEOUT_MS) + Jobs are retried if not kept alive for this long + + --proverBroker.proverBrokerPollIntervalMs (default: 1000) ($PROVER_BROKER_POLL_INTERVAL_MS) + The interval to check job health status + + --proverBroker.proverBrokerJobMaxRetries (default: 3) ($PROVER_BROKER_JOB_MAX_RETRIES) + If starting a prover broker locally, the max number of retries per proving job + + --proverBroker.proverBrokerBatchSize (default: 100) ($PROVER_BROKER_BATCH_SIZE) + The prover broker writes jobs to disk in batches + + --proverBroker.proverBrokerBatchIntervalMs (default: 50) ($PROVER_BROKER_BATCH_INTERVAL_MS) + How often to flush batches to disk + + --proverBroker.proverBrokerMaxEpochsToKeepResultsFor (default: 1) ($PROVER_BROKER_MAX_EPOCHS_TO_KEEP_RESULTS_FOR) + The maximum number of epochs to keep results for + + --proverBroker.proverBrokerStoreMapSizeKB ($PROVER_BROKER_STORE_MAP_SIZE_KB) + The size of the prover broker's database. Will override the dataStoreMapSizeKB if set. + + --proverBroker.dataStoreMapSizeKB (default: 134217728) ($DATA_STORE_MAP_SIZE_KB) + DB mapping size to be applied to all key/value stores + + --proverBroker.viemPollingIntervalMS (default: 1000) ($L1_READER_VIEM_POLLING_INTERVAL_MS) + The polling interval viem uses in ms + + --proverBroker.rollupVersion ($ROLLUP_VERSION) + The version of the rollup. + + PROVER AGENT + + --prover-agent + Starts Aztec Prover Agent with options + + --proverAgent.proverAgentCount (default: 1) ($PROVER_AGENT_COUNT) + Whether this prover has a local prover agent + + --proverAgent.proverAgentPollIntervalMs (default: 100) ($PROVER_AGENT_POLL_INTERVAL_MS) + The interval agents poll for jobs at + + --proverAgent.proverAgentProofTypes ($PROVER_AGENT_PROOF_TYPES) + The types of proofs the prover agent can generate + + --proverAgent.proverBrokerUrl ($PROVER_BROKER_HOST) + The URL where this agent takes jobs from + + --proverAgent.realProofs (default: true) ($PROVER_REAL_PROOFS) + Whether to construct real proofs + + --proverAgent.proverTestDelayType (default: fixed) ($PROVER_TEST_DELAY_TYPE) + The type of artificial delay to introduce + + --proverAgent.proverTestDelayMs ($PROVER_TEST_DELAY_MS) + Artificial delay to introduce to all operations to the test prover. + + --proverAgent.proverTestDelayFactor (default: 1) ($PROVER_TEST_DELAY_FACTOR) + If using realistic delays, what percentage of realistic times to apply. + + P2P BOOTSTRAP + + --p2p-bootstrap + Starts Aztec P2P Bootstrap with options + + --p2pBootstrap.dataStoreMapSizeKB (default: 134217728) ($DATA_STORE_MAP_SIZE_KB) + DB mapping size to be applied to all key/value stores + +``` 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 new file mode 100644 index 000000000000..4b3af5b57d60 --- /dev/null +++ b/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_prover.md @@ -0,0 +1,136 @@ +--- +sidebar_position: 2 +title: How to Run a Prover Node +description: A comprehensive guide to setting up and running an Aztec Prover node on testnet or mainnet, including hardware requirements, configuration options, and performance optimization tips. +keywords: + [ + aztec, + prover, + node, + blockchain, + L2, + scaling, + ethereum, + zero-knowledge, + ZK, + setup, + tutorial, + ] +tags: + - prover + - node + - tutorial + - infrastructure +--- + +## Background + +Prover nodes are a critical part of the Aztec network's infrastructure. They generate cryptographic proofs that attest to the correctness of public transactions, ultimately producing a single rollup proof that is submitted to Ethereum. + +Operating a prover node requires a solid grasp of blockchain protocols, cryptographic systems, DevOps best practices, and high-performance hardware. It’s a resource-intensive role typically undertaken by experienced engineers or specialized teams due to its technical and operational complexity. + +## Prerequisites + +Before following this guide, make sure you: + +- Have the `aztec` tool [installed](../../../developers/getting_started.md#install-the-sandbox) +- Have sufficient hardware resources for proving operations +- Your confidence level is expected to be around "I'd be able to run a Prover _without_ this guide" + +## Understanding Prover Architecture + +The Aztec prover involves three key components: the Prover Node, the Proving Broker, and the Proving Agent. + +#### Prover Node + +The Prover Node is responsible for polling the L1 for unproven epochs and initiating the proof process. When an epoch is ready to be proven, the prover node creates proving jobs and distributes them to the broker. The Prover Node is also responsible for submitting the final rollup proof to the rollup contract. + +- **Resources**: Up to 8 cores, 16GB RAM, ~1TB disk for storing state. + +#### Proving Broker + +Manages a queue of proving jobs, distributing them to available agents and forwarding results back to the node. + +- **Resources**: Up to 4 cores, 16GB RAM, ~1GB disk. + +#### Proving Agents + +Executes the actual proof jobs. Agents are stateless, fetch work from the broker, and return the results. + +- **Resources**: Each agent may use up to 16 cores and 128GB RAM. + +## Setting Up Your Prover + +### Using Docker Compose + +```yml +name: aztec-prover +services: + prover-node: + image: aztecprotocol/aztec:0.85.0-alpha-testnet.2 # Always refer to the docs to check that you're using the correct image. + command: + - node + - --no-warnings + - /usr/src/yarn-project/aztec/dest/bin/index.js + - start + - --prover-node + - --archiver + - --network + - alpha-testnet + depends_on: + broker: + condition: service_started + required: true + environment: + # PROVER_COORDINATION_NODE_URL: "http://:8080" # this can point to your own validator - using this replaces the need for the prover node to be on the P2P network and uses your validator as a sentry node of some sort. + # P2P_ENABLED: "false" # Switch to false if you provide a PROVER_COORDINATION_NODE_URL + DATA_DIRECTORY: /data + DATA_STORE_MAP_SIZE_KB: "134217728" + ETHEREUM_HOSTS: # EL RPC endpoint + L1_CONSENSUS_HOST_URL: # CL RPC endpoint + LOG_LEVEL: info + PROVER_BROKER_HOST: http://broker:8080 + PROVER_PUBLISHER_PRIVATE_KEY: # The node needs to publish proofs to L1. Replace with your private key + ports: + - "8080:8080" + - "40400:40400" + - "40400:40400/udp" + volumes: + - /home/my-node/node:/data # Local directory + + + agent: + image: aztecprotocol/aztec:0.85.0-alpha-testnet.2 # Always refer to the docs to check that you're using the correct image. + command: + - node + - --no-warnings + - /usr/src/yarn-project/aztec/dest/bin/index.js + - start + - --prover-agent + - --network + - alpha-testnet + environment: + PROVER_AGENT_COUNT: "1" + PROVER_AGENT_POLL_INTERVAL_MS: "10000" # Just to reduce the log spamming if you're using debug logging. + PROVER_BROKER_HOST: http://broker:8080 + PROVER_ID: # this should be the address corresponding to the PROVER_PUBLISHER_PRIVATE_KEY you set on the node. + pull_policy: always + restart: unless-stopped + + broker: + image: aztecprotocol/aztec:0.85.0-alpha-testnet.2 # Always refer to the docs to check that you're using the correct image. + command: + - node + - --no-warnings + - /usr/src/yarn-project/aztec/dest/bin/index.js + - start + - --prover-broker + - --network + - alpha-testnet + environment: + DATA_DIRECTORY: /data + ETHEREUM_HOSTS: # Your EL RPC endpoint + LOG_LEVEL: info + volumes: + - /home/my-node/node:/data # Local directory +``` 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 new file mode 100644 index 000000000000..f2d634e43ee6 --- /dev/null +++ b/docs/docs/the_aztec_network/guides/run_nodes/how_to_run_sequencer.md @@ -0,0 +1,201 @@ +--- +sidebar_position: 1 +title: How to Run a Sequencer Node +description: A comprehensive guide to setting up and running an Aztec Sequencer node on testnet or mainnet, including infrastructure requirements, configuration options, and troubleshooting tips. +keywords: + [ + aztec, + sequencer, + node, + blockchain, + L2, + scaling, + ethereum, + validator, + setup, + tutorial, + ] +tags: + - sequencer + - node + - tutorial + - infrastructure +--- + +## Background + +The Aztec sequencer node is critical infrastructure responsible for ordering transactions and producing blocks. + +When transactions enter the network, the sequencer node bundles 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 (validators in this context) who re-execute the transactions to verify their correctness. These validators attest to the block's validity by signing it, and once enough attestations are collected (two-thirds of the committee plus one), the sequencer can submit the block 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. + +## Prerequisites + +Before following this guide, make sure you: + +- Have the `aztec` tool [installed](../../../developers/getting_started.md#install-the-sandbox) +- Are running a Linux or MacOS machine with access to a terminal + +## Setting Up Your Sequencer + +This guide will describe how to setup your sequencer using the `aztec start` command. For more advanced setups, refer to the Advanced Configuration section below. + +The `aztec start` tool is a one-stop-shop for running your sequencer on any Aztec Network. It assigns default values to several config variables based on a `--network` flag and launches a docker container running the sequencer software. + +To use the `aztec start` command, you need to obtain the following: + +#### RPCs + +- An L1 execution client (for reading transactions and state). It can be specified via the `--l1-rpc-urls` flag when using `aztec start` or via the env var `ETHEREUM_HOSTS`. + +- An L1 consensus client (for blobs). It can be specified via the `--l1-consensus-host-urls` flag when using `aztec start` or via the env var `L1_CONSENSUS_HOST_URLS`. + +- To reduce load on your consensus endpoint, the Aztec sequencer supports an optional (but recommended) remote server that serves blobs to the client. You can pass your own or use one provided by a trusted party via the `--sequencer.blobSinkUrl` flag when using `aztec start`, or via the env var `BLOB_SINK_URL`. + +#### Ethereum Keys + +You will need an Ethereum private key and the corresponding public address. The private key is set via the `--sequencer.validatorPrivateKey` flag while the public address should be specified via the `--sequencer.coinbase ` flag. + +The private key is needed as your validator will post blocks to Ethereum, and the public address will be the recipient of any block rewards. + +#### Networking + +You MUST forward your ports. Your router must send UDP and TCP traffic on port `40400` (unless you changed the default) to your IP address on your local network. Failure to do so may result in your sequencer not participating on the p2p network. + +As a tip, configure your router to give your MAC address the same IP address every time it does a DHCP refresh. + +You also need to grab your external IP address and pass it along to the `--p2p.p2pIp` when using `aztec start`. + +#### Sepolia ETH + +You'll need Sepolia ETH to cover gas costs. Here are some options: + +- Use a PoW faucet like [Sepolia PoW Faucet](https://sepolia-faucet.pk910.de/) +- Ask in our Discord community (and remember to pay it forward when you can!) + +### Now Start Your Sequencer + +To boot up a sequencer using `aztec start`, run the following command: + +```bash +aztec start --network alpha-testnet \ + --l1-rpc-urls https://example.com \ + --l1-consensus-host-urls https://example.com \ + --sequencer.validatorPrivateKey 0xYourPrivateKey \ + --sequencer.coinbase 0xYourAddress + --p2p.p2pIp 999.99.999.99 +``` + +:::tip + +For a full overview of all available commands, check out the [CLI reference sheet](./cli_reference.md). +::: + +:::tip + +If you are unable to determine your public ip. Running the command `curl ifconfig.me` can retrieve it for you. +::: + +### Register as a Validator + +Once your node is fully synced, you can register as a validator using the `add-l1-validator` command: + +```bash +aztec add-l1-validator \ + --network alpha-testnet \ + --l1-rpc-urls https://eth-sepolia.g.example.com/example/your-key \ + --private-key your-private-key \ + --attester your-validator-address \ + --proposer-eoa your-validator-address \ + --staking-asset-handler 0xF739D03e98e23A7B65940848aBA8921fF3bAc4b2 \ + --l1-chain-id 11155111 \ +``` + +## Advanced Configuration + +### Using Environment Variables + +Every flag in the `aztec start` command corresponds to an environment variable. You can see the variable names by running `aztec start --help`. A reference is provided [here](./cli_reference.md). + +For example: + +- `--l1-rpc-urls` maps to `ETHEREUM_HOSTS` +- `--l1-consensus-host-urls` maps to `L1_CONSENSUS_HOSTS_URLS` + +You can create a `.env` file with these variables: + +```bash +ETHEREUM_HOSTS=https://example.com +L1_CONSENSUS_HOST_URLS=https://example.com +# Add other configuration variables as needed +``` + +Then source this file before running your command: + +```bash +source .env +aztec start --network alpha-testnet --archiver --node --sequencer # other flags... +``` + +### Using a Docker Compose + +If you would like to run in a docker compose, you can use a configuration like the one below: + +```yml +name: aztec-node +services: + network_mode: host # Optional, run with host networking + node: + image: aztecprotocol/aztec:0.85.0-alpha-testnet.2 + environment: + ETHEREUM_HOSTS: "" + L1_CONSENSUS_HOST_URLS: "" + DATA_DIRECTORY: /data + VALIDATOR_PRIVATE_KEY: $VALIDATOR_PRIVATE_KEY + P2P_IP: $P2P_IP + LOG_LEVEL: debug + entrypoint: > + sh -c 'node --no-warnings /usr/src/yarn-project/aztec/dest/bin/index.js start --network alpha-testnet start --node --archiver --sequencer' + ports: + - 40400:40400/tcp + - 40400:40400/udp + - 8080:8080 + + volumes: + - /home/my-node/node:/data # Local directory +``` + +## Troubleshooting + +### L1 Access + +If you're hosting your own Ethereum execution or consensus client locally (rather than using an external RPC like Alchemy), you need to ensure that the prover node inside Docker can reach it. + +By default, Docker runs containers on a bridge network that isolates them from the host machine’s network interfaces. This means localhost inside the container won’t point to the host’s localhost. + +To fix this: + +Option 1: Use the special hostname host.docker.internal +This tells Docker to route traffic from the container to the host machine. For example: + +```bash +--l1-rpc-urls http://host.docker.internal:8545 +``` + +Option 2: Add a host network entry to your Docker Compose file (advanced users) +This gives your container direct access to the host’s network stack, but removes Docker’s network isolation. Add to your `docker-compose.yml` + +```yaml +network_mode: "host" +``` + +⚠️ Note: network_mode: "host" only works on Linux. On macOS and Windows, use `host.docker.internal`. + +:::info + +You can run your own Sepolia ETH Node. However, at the moment only [`geth`](https://github.com/ethereum/go-ethereum) and [`reth`](https://github.com/paradigmxyz/reth) nodes are confirmed to work reliably with the Aztec client. + +::: + +Happy sequencing! diff --git a/docs/docs/the_aztec_network/guides/run_nodes/index.md b/docs/docs/the_aztec_network/guides/run_nodes/index.md new file mode 100644 index 000000000000..2d1ab4d65ee1 --- /dev/null +++ b/docs/docs/the_aztec_network/guides/run_nodes/index.md @@ -0,0 +1,26 @@ +--- +id: index +sidebar_position: 0 +title: Run a Node, Sequencer, or Prover +--- + +## Running Aztec Nodes + +
+ + +

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. + + + + +

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. + + +
diff --git a/docs/docs/the_aztec_network/guides/useful_commands.md b/docs/docs/the_aztec_network/guides/useful_commands.md new file mode 100644 index 000000000000..108bd05d76e9 --- /dev/null +++ b/docs/docs/the_aztec_network/guides/useful_commands.md @@ -0,0 +1,90 @@ +--- +sidebar_position: 5 +title: Useful commands +--- + +These commands are useful to sequencer operators. If you're trying to do something that is not listed here, ask in the appropriate discord channel. + +## Prerequisites + +- You'll need a way to query the L1 contracts, this guide assumes you have `foundry` installed. +- Have the `aztec` tool [installed](../../developers/getting_started.md#install-the-sandbox) +- Ethereum EL RPC endpoint + +## Basics + +### Get the Registry contract address + +The Registry contract is your entrypoint into almost all other contracts for a particular deployment of the Aztec Network. Armed with this address, you can retrieve almost all other useful contracts. + +Assume there are two "deployments" of Aztec i.e. an `alpha-testnet` and a `ignition-testnet`. Then each deployment will have a unique Registry contract that does not change with upgrades. If a governance upgrade on `alpha-testnet` deploys a new rollup contract, the Registry contract for the `alpha-testnet` deployment will not change. + + + +### Get the Rollup contract + +Run + +```bash +cast call "getCanonicalRollup()" --rpc-url https://example.com +``` + +:::info +The rest of the guide will omit the `--rpc-url` flag for legibility. +::: + +## Query the Validator Set + +### Retrieve a list of all validators + +Run + +```bash +cast call "getAttesters()" --rpc-url +``` + +### What is the status of a particular validator? + +Run + +```bash +cast call "getInfo(address)" +``` + +This will return in order: 1) the validator's balance 2) their `withdrawer` address 3) their `proposer` address and 4) their current status. + +| Status | Meaning | +| ------ | -------------------------------------------------------------------------------------------------------------------- | +| 0 | The validator is not in the validator set | +| 1 | The validator is currently in the validator set. | +| 2 | The validator is not active in the set. This could mean that they initiated a withdrawal and are awaiting final exit | +| 3 | The validator has completed their exit delay and can be exited from the validator set | + +## Governance Upgrades + +### Get the GovernanceProposer contract + +First get the Governance contract from the Registry, and query it for the GovernanceProposer contract. + +```bash +cast call "getGovernance()" +cast call "governanceProposer()" +``` + +### Check what the governance quorums are + +Run + +```bash +cast call "M()" # The size of any signalling round in L2 blocks. +cast call "N()" # The number of signals that must be received in any single signalling round. +``` + +### Check how many signals a payload has received + +You can check how many signals a `payload` has received in a specific round. To do so, you need the rollup address, the payload address and the round number. To find the round number at a specific point in time, you can compute it using an L2 slot number. + +```bash +cast call "computeRound(uint256)" # returns a round number (in hex) +cast call "yeaCount(address,uint256,address)" # round number should is an integer +``` diff --git a/docs/docs/run_node/index.md b/docs/docs/the_aztec_network/index.md similarity index 68% rename from docs/docs/run_node/index.md rename to docs/docs/the_aztec_network/index.md index 29fdc991272d..5b9001d301b7 100644 --- a/docs/docs/run_node/index.md +++ b/docs/docs/the_aztec_network/index.md @@ -1,7 +1,7 @@ --- id: index sidebar_position: 0 -title: Run a node +title: The Aztec Network --- In this section, you can explore how governance works on Aztec, the types of nodes that can be run, and how to contribute to decentralization on the Aztec Testnet. @@ -9,7 +9,7 @@ In this section, you can explore how governance works on Aztec, the types of nod ## Learn about governance on Aztec
- +

Governance

 @@ -19,10 +19,10 @@ In this section, you can explore how governance works on Aztec, the types of nod
-## Decentralization Components + ## Run a node
- +

Run a validator node (sequencer)

 - +

Run a prover node

 diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js index cd1e84c10bcc..072b10b9927b 100644 --- a/docs/docusaurus.config.js +++ b/docs/docusaurus.config.js @@ -62,10 +62,8 @@ const config = { ); }, routeBasePath: "/", - disableVersioning: process.env.ENV === "dev", - include: process.env.SHOW_PROTOCOL_SPECS - ? ["**/*.{md,mdx}"] - : ["**/*.{md,mdx}", "!protocol-specs/**"], + include: ["**/*.{md,mdx}"], + exclude: !process.env.PROTOCOL_SPECS ? ['protocol-specs/**'] : [], remarkPlugins: [math], rehypePlugins: [ @@ -301,16 +299,6 @@ const config = { label: "Roadmap", className: "no-external-icon", }, - ...(process.env.SHOW_PROTOCOL_SPECS - ? [ - { - type: "docSidebar", - sidebarId: "protocolSpecSidebar", - label: "Protocol Specification", - className: "no-external-icon", - }, - ] - : []), { to: "https://noir-lang.org/docs", label: "Noir docs", @@ -442,4 +430,18 @@ const config = { }), }; +if (process.env.PROTOCOL_SPECS) { + //@ts-ignore + const index = config.themeConfig.navbar.items.findIndex( + (e) => e.type == "dropdown" + ); + + //@ts-ignore + config.themeConfig.navbar.items.splice(index, 0, { + type: "docSidebar", + sidebarId: "protocolSpecSidebar", + label: "Protocol Specification", + }); +} + module.exports = config; diff --git a/docs/package.json b/docs/package.json index 5e7997514719..209476f01ea7 100644 --- a/docs/package.json +++ b/docs/package.json @@ -4,9 +4,10 @@ "private": true, "scripts": { "docs": "yarn preprocess && yarn typedoc && docusaurus start --host ${HOST:-localhost}", - "dev": "HOST=0.0.0.0 ENV=dev SHOW_PROTOCOL_SPECS=true yarn docs", - "dev:local": "ENV=dev SHOW_PROTOCOL_SPECS=true yarn docs", + "dev": "PROTOCOL_SPECS=true HOST=0.0.0.0 ENV=dev yarn docs", + "dev:local": "PROTOCOL_SPECS=true ENV=dev yarn docs", "build": "yarn clean && yarn preprocess && yarn typedoc && yarn preprocess:move && docusaurus build", + "build:with-specs": "yarn clean &&PROTOCOL_SPECS=true yarn preprocess && yarn typedoc && yarn preprocess:move && PROTOCOL_SPECS=true docusaurus build", "swizzle": "docusaurus swizzle", "clean": "./scripts/clean.sh", "serve": "docusaurus serve", diff --git a/docs/sidebars.js b/docs/sidebars.js index bbd54363c5d5..81d2b3d45045 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -3,8 +3,7 @@ const fs = require("fs"); const path = require("path"); -/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ -export default { +const sidebar = { sidebar: [ { type: "doc", @@ -140,7 +139,7 @@ export default { nodesSidebar: [ { type: "doc", - id: "run_node/index", + id: "the_aztec_network/index", }, { type: "html", @@ -149,7 +148,7 @@ export default { }, { type: "autogenerated", - dirName: "run_node/concepts", + dirName: "the_aztec_network/concepts", }, { type: "html", @@ -162,250 +161,252 @@ export default { }, { type: "autogenerated", - dirName: "run_node/guides", + dirName: "the_aztec_network/guides", }, ], - ...(process.env.SHOW_PROTOCOL_SPECS - ? { - protocolSpecSidebar: [ - "protocol-specs/intro", - { - label: "Cryptography", - type: "category", - link: { type: "doc", id: "protocol-specs/cryptography/index" }, - items: [ - { - label: "Proving System", - type: "category", - items: [ - "protocol-specs/cryptography/proving-system/performance-targets", - "protocol-specs/cryptography/proving-system/overview", - "protocol-specs/cryptography/proving-system/data-bus", - ], - }, - { - label: "Hashing", - type: "category", - items: [ - "protocol-specs/cryptography/hashing/hashing", - "protocol-specs/cryptography/hashing/poseidon2", - "protocol-specs/cryptography/hashing/pedersen", - ], - }, - "protocol-specs/cryptography/merkle-trees", - ], - }, - { - label: "Addresses & Keys", - type: "category", - link: { - type: "doc", - id: "protocol-specs/addresses-and-keys/index", - }, - items: [ - "protocol-specs/addresses-and-keys/address", - "protocol-specs/addresses-and-keys/keys-requirements", - "protocol-specs/addresses-and-keys/keys", - { - label: "Example Usage of Keys", - type: "category", - items: [ - "protocol-specs/addresses-and-keys/example-usage/nullifier", - "protocol-specs/addresses-and-keys/example-usage/diversified-and-stealth-keys", - "protocol-specs/addresses-and-keys/example-usage/tag-sequence-derivation", - "protocol-specs/addresses-and-keys/example-usage/encrypt-and-tag", - ], - }, - "protocol-specs/addresses-and-keys/precompiles", - "protocol-specs/addresses-and-keys/diversified-and-stealth", - ], - }, - { - label: "State", - type: "category", - link: { type: "doc", id: "protocol-specs/state/index" }, - items: [ - "protocol-specs/state/tree-implementations", - "protocol-specs/state/archive", - "protocol-specs/state/note-hash-tree", - "protocol-specs/state/nullifier-tree", - "protocol-specs/state/public-data-tree", - "protocol-specs/state/wonky-tree", - ], - }, - { - label: "Transactions", - type: "category", - link: { type: "doc", id: "protocol-specs/transactions/index" }, - items: [ - "protocol-specs/transactions/local-execution", - "protocol-specs/transactions/public-execution", - "protocol-specs/transactions/tx-object", - "protocol-specs/transactions/validity", - ], - }, - { - label: "Bytecode", - type: "category", - link: { type: "doc", id: "protocol-specs/bytecode/index" }, - items: [], - }, - { - label: "Contract Deployment", - type: "category", - link: { - type: "doc", - id: "protocol-specs/contract-deployment/index", - }, - items: [ - "protocol-specs/contract-deployment/classes", - "protocol-specs/contract-deployment/instances", - ], - }, - { - label: "Calls", - type: "category", - link: { type: "doc", id: "protocol-specs/calls/index" }, - items: [ - "protocol-specs/calls/sync-calls", - "protocol-specs/calls/enqueued-calls", - "protocol-specs/calls/batched-calls", - "protocol-specs/calls/static-calls", - "protocol-specs/calls/unconstrained-calls", - "protocol-specs/calls/public-private-messaging", - ], - }, - { - label: "L1 smart contracts", - type: "category", - link: { - type: "doc", - id: "protocol-specs/l1-smart-contracts/index", - }, - items: ["protocol-specs/l1-smart-contracts/frontier"], - }, - { - label: "Data availability", - type: "category", - link: { - type: "doc", - id: "protocol-specs/data-publication-and-availability/index", - }, - items: [ - "protocol-specs/data-publication-and-availability/overview", - "protocol-specs/data-publication-and-availability/published-data", - "protocol-specs/data-publication-and-availability/blobs", - ], - }, - { - label: "Logs", - type: "category", - link: { type: "doc", id: "protocol-specs/logs/index" }, - items: [], - }, - { - label: "Pre-compiled Contracts", - type: "category", - link: { - type: "doc", - id: "protocol-specs/pre-compiled-contracts/index", - }, - items: ["protocol-specs/pre-compiled-contracts/registry"], - }, - { - label: "Private Message Delivery", - type: "category", - link: { - type: "doc", - id: "protocol-specs/private-message-delivery/index", - }, - items: [ - "protocol-specs/private-message-delivery/private-msg-delivery", // renamed to avoid routing problems - "protocol-specs/private-message-delivery/send-note-guidelines", - ], - }, - { - label: "Gas & Fees", - type: "category", - link: { type: "doc", id: "protocol-specs/gas-and-fees/index" }, - items: [ - "protocol-specs/gas-and-fees/fee-juice", - "protocol-specs/gas-and-fees/specifying-gas-fee-info", - "protocol-specs/gas-and-fees/tx-setup-and-teardown", - "protocol-specs/gas-and-fees/kernel-tracking", - "protocol-specs/gas-and-fees/fee-schedule", - "protocol-specs/gas-and-fees/published-gas-and-fee-data", - ], - }, - { - label: "Decentralization", - type: "category", - items: [ - "protocol-specs/decentralization/actors", - "protocol-specs/decentralization/governance", - "protocol-specs/decentralization/block-production", - "protocol-specs/decentralization/p2p-network", - ], - }, - { - label: "Circuits", - type: "category", - link: { - type: "doc", - id: "protocol-specs/circuits/high-level-topology", - }, - items: [ - "protocol-specs/circuits/private-function", - "protocol-specs/circuits/private-kernel-initial", - "protocol-specs/circuits/private-kernel-inner", - "protocol-specs/circuits/private-kernel-reset", - "protocol-specs/circuits/private-kernel-tail", - "protocol-specs/circuits/public-kernel-initial", - "protocol-specs/circuits/public-kernel-inner", - "protocol-specs/circuits/public-kernel-tail", - ], - }, - { - label: "Rollup Circuits", - type: "category", - link: { type: "doc", id: "protocol-specs/rollup-circuits/index" }, - items: [ - "protocol-specs/rollup-circuits/base-rollup", - "protocol-specs/rollup-circuits/merge-rollup", - "protocol-specs/rollup-circuits/tree-parity", - "protocol-specs/rollup-circuits/root-rollup", - ], - }, - { - label: "Aztec (Public) VM", - type: "category", - link: { type: "doc", id: "protocol-specs/public-vm/index" }, - items: [ - "protocol-specs/public-vm/intro", - "protocol-specs/public-vm/state", - "protocol-specs/public-vm/memory-model", - "protocol-specs/public-vm/context", - "protocol-specs/public-vm/execution", - "protocol-specs/public-vm/nested-calls", - "protocol-specs/public-vm/instruction-set", - { - label: "AVM Circuit", - type: "category", - link: { - type: "doc", - id: "protocol-specs/public-vm/circuit-index", - }, - items: [ - "protocol-specs/public-vm/avm-circuit", - "protocol-specs/public-vm/control-flow", - "protocol-specs/public-vm/alu", - "protocol-specs/public-vm/bytecode-validation-circuit", - ], - }, - "protocol-specs/public-vm/type-structs", - ], - }, - ], - } - : {}), }; + +const protocolSpecSidebar = [ + "protocol-specs/intro", + { + label: "Cryptography", + type: "category", + link: { type: "doc", id: "protocol-specs/cryptography/index" }, + items: [ + { + label: "Proving System", + type: "category", + items: [ + "protocol-specs/cryptography/proving-system/performance-targets", + "protocol-specs/cryptography/proving-system/overview", + "protocol-specs/cryptography/proving-system/data-bus", + ], + }, + { + label: "Hashing", + type: "category", + items: [ + "protocol-specs/cryptography/hashing/hashing", + "protocol-specs/cryptography/hashing/poseidon2", + "protocol-specs/cryptography/hashing/pedersen", + ], + }, + "protocol-specs/cryptography/merkle-trees", + ], + }, + { + label: "Addresses & Keys", + type: "category", + link: { + type: "doc", + id: "protocol-specs/addresses-and-keys/index", + }, + items: [ + "protocol-specs/addresses-and-keys/address", + "protocol-specs/addresses-and-keys/keys-requirements", + "protocol-specs/addresses-and-keys/keys", + { + label: "Example Usage of Keys", + type: "category", + items: [ + "protocol-specs/addresses-and-keys/example-usage/nullifier", + "protocol-specs/addresses-and-keys/example-usage/diversified-and-stealth-keys", + "protocol-specs/addresses-and-keys/example-usage/tag-sequence-derivation", + "protocol-specs/addresses-and-keys/example-usage/encrypt-and-tag", + ], + }, + "protocol-specs/addresses-and-keys/precompiles", + "protocol-specs/addresses-and-keys/diversified-and-stealth", + ], + }, + { + label: "State", + type: "category", + link: { type: "doc", id: "protocol-specs/state/index" }, + items: [ + "protocol-specs/state/tree-implementations", + "protocol-specs/state/archive", + "protocol-specs/state/note-hash-tree", + "protocol-specs/state/nullifier-tree", + "protocol-specs/state/public-data-tree", + "protocol-specs/state/wonky-tree", + ], + }, + { + label: "Transactions", + type: "category", + link: { type: "doc", id: "protocol-specs/transactions/index" }, + items: [ + "protocol-specs/transactions/local-execution", + "protocol-specs/transactions/public-execution", + "protocol-specs/transactions/tx-object", + "protocol-specs/transactions/validity", + ], + }, + { + label: "Bytecode", + type: "category", + link: { type: "doc", id: "protocol-specs/bytecode/index" }, + items: [], + }, + { + label: "Contract Deployment", + type: "category", + link: { + type: "doc", + id: "protocol-specs/contract-deployment/index", + }, + items: [ + "protocol-specs/contract-deployment/classes", + "protocol-specs/contract-deployment/instances", + ], + }, + { + label: "Calls", + type: "category", + link: { type: "doc", id: "protocol-specs/calls/index" }, + items: [ + "protocol-specs/calls/sync-calls", + "protocol-specs/calls/enqueued-calls", + "protocol-specs/calls/batched-calls", + "protocol-specs/calls/static-calls", + "protocol-specs/calls/unconstrained-calls", + "protocol-specs/calls/public-private-messaging", + ], + }, + { + label: "L1 smart contracts", + type: "category", + link: { + type: "doc", + id: "protocol-specs/l1-smart-contracts/index", + }, + items: ["protocol-specs/l1-smart-contracts/frontier"], + }, + { + label: "Data availability", + type: "category", + link: { + type: "doc", + id: "protocol-specs/data-publication-and-availability/index", + }, + items: [ + "protocol-specs/data-publication-and-availability/overview", + "protocol-specs/data-publication-and-availability/published-data", + "protocol-specs/data-publication-and-availability/blobs", + ], + }, + { + label: "Logs", + type: "category", + link: { type: "doc", id: "protocol-specs/logs/index" }, + items: [], + }, + { + label: "Pre-compiled Contracts", + type: "category", + link: { + type: "doc", + id: "protocol-specs/pre-compiled-contracts/index", + }, + items: ["protocol-specs/pre-compiled-contracts/registry"], + }, + { + label: "Private Message Delivery", + type: "category", + link: { + type: "doc", + id: "protocol-specs/private-message-delivery/index", + }, + items: [ + "protocol-specs/private-message-delivery/private-msg-delivery", // renamed to avoid routing problems + "protocol-specs/private-message-delivery/send-note-guidelines", + ], + }, + { + label: "Gas & Fees", + type: "category", + link: { type: "doc", id: "protocol-specs/gas-and-fees/index" }, + items: [ + "protocol-specs/gas-and-fees/fee-juice", + "protocol-specs/gas-and-fees/specifying-gas-fee-info", + "protocol-specs/gas-and-fees/tx-setup-and-teardown", + "protocol-specs/gas-and-fees/kernel-tracking", + "protocol-specs/gas-and-fees/fee-schedule", + "protocol-specs/gas-and-fees/published-gas-and-fee-data", + ], + }, + { + label: "Decentralization", + type: "category", + items: [ + "protocol-specs/decentralization/actors", + "protocol-specs/decentralization/governance", + "protocol-specs/decentralization/block-production", + "protocol-specs/decentralization/p2p-network", + ], + }, + { + label: "Circuits", + type: "category", + link: { + type: "doc", + id: "protocol-specs/circuits/high-level-topology", + }, + items: [ + "protocol-specs/circuits/private-function", + "protocol-specs/circuits/private-kernel-initial", + "protocol-specs/circuits/private-kernel-inner", + "protocol-specs/circuits/private-kernel-reset", + "protocol-specs/circuits/private-kernel-tail", + "protocol-specs/circuits/public-kernel-initial", + "protocol-specs/circuits/public-kernel-inner", + "protocol-specs/circuits/public-kernel-tail", + ], + }, + { + label: "Rollup Circuits", + type: "category", + link: { type: "doc", id: "protocol-specs/rollup-circuits/index" }, + items: [ + "protocol-specs/rollup-circuits/base-rollup", + "protocol-specs/rollup-circuits/merge-rollup", + "protocol-specs/rollup-circuits/tree-parity", + "protocol-specs/rollup-circuits/root-rollup", + ], + }, + { + label: "Aztec (Public) VM", + type: "category", + link: { type: "doc", id: "protocol-specs/public-vm/index" }, + items: [ + "protocol-specs/public-vm/intro", + "protocol-specs/public-vm/state", + "protocol-specs/public-vm/memory-model", + "protocol-specs/public-vm/context", + "protocol-specs/public-vm/execution", + "protocol-specs/public-vm/nested-calls", + "protocol-specs/public-vm/instruction-set", + { + label: "AVM Circuit", + type: "category", + link: { + type: "doc", + id: "protocol-specs/public-vm/circuit-index", + }, + items: [ + "protocol-specs/public-vm/avm-circuit", + "protocol-specs/public-vm/control-flow", + "protocol-specs/public-vm/alu", + "protocol-specs/public-vm/bytecode-validation-circuit", + ], + }, + "protocol-specs/public-vm/type-structs", + ], + }, +]; + +/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ +module.exports = process.env.PROTOCOL_SPECS + ? { ...sidebar, protocolSpecSidebar } + : sidebar; diff --git a/spartan/releases/README.md b/spartan/releases/README.md deleted file mode 100644 index 7a174263d146..000000000000 --- a/spartan/releases/README.md +++ /dev/null @@ -1,144 +0,0 @@ -# Aztec Spartan - -This tool helps easing the entry barrier to boot an Aztec Sequencer and Prover (S&P) Testnet. - -![Aztec Sparta Meme](./assets/banner.jpeg) - -For once, there's no rocket science here. This script does the following: - -- Checks for the presence of Docker in your machine -- Prompts you for some environment variables -- Outputs a templated docker-compose file with your variables -- Runs the docker compose file - -It should work in most UNIX-based machines. - -## Installation - -To configure a new node, create a new directory and run the install script: - -```bash -mkdir val1 && cd val1 -curl -L sp-testnet.aztec.network | bash -``` - -This will install `aztec-sequencer.sh` in the current directory. You can now run it: - -```bash -./aztec-sequencer.sh config -``` - -If you don't have Docker installed, the script will do it for you. It will then prompt for any required environment variables and output both a `docker-compose.yml` and an `.env` file. You will also be prompted to choose whether to use a [named volume](https://docs.docker.com/engine/storage/volumes/) (default) or if you want to use a local directory to store the node's data. - -Run `./aztec-sequencer.sh` without any command to see all available options, and pass them as flags, i.e. `./aztec-sequencer config -p 8080 -p2p 40400`. If you want to use a different key for p2p peer id, pass it with `-pk `. - -For more options, see the [Node Configuration](#node-configuration) section. - -> [!TIP] -> Ensure that each validator instance uses unique ports to avoid conflicts. - -## Running - -To spare you a few keystrokes, you can use `./aztec-sequencer [start/stop/logs/update]` to start, stop, output logs or pull the latest docker images. - -> [!NOTE] -> The above deploy script will connect your node to the p2p network where it will register peers and start receiving messages from other nodes on the network. You will not be in the validator set just yet. -> -> Once you connect and begin to see gossiped messages such as attestations, proposals etc notify notify a team member and they will add you to the validator set. - -## Node Configuration - -The user is prompted to enter some values which will map to corresponding ENV variables. Some are required: - -1. A Sepolia execution node RPC (for example on [alchemy](https://dashboard.alchemy.com/)) -2. A Sepolia beacon node RPC (for example from [drpc](https://drpc.org)) -3. An Ethereum private key -4. `COINBASE` which is the Ethereum address associated with the private key - -On a first run, the script will generate a p2p private key and store it in `$DATA_DIR/var/lib/aztec/p2p-private-key`. If you wish to change your p2p private key, you can pass it on as a CLI arg using the flag `-pk` or update the `PEER_ID_PRIVATE_KEY` in the env file. - -### Publisher and Archiver - -The Publisher is the main node component that interacts with the Ethereum L1, for read and write operations. It is mainly responsible for block publishing, proof submission and tx management. - -The Archiver's primary functions are data storage and retrieval (i.e. L1->L2 messages), state synchronization and re-org handling. - -| Variable | Description | -| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| ETHEREUM_HOSTS | List of Ethereum nodes URLs your validator will connect to (comma separated). For as long as we're on private networks, please use the value in `aztec-sequencer.sh` | -| L1_CHAIN_ID | Chain ID of the L1 | -| DATA_DIRECTORY | Optional dir to store archiver and world state data. If omitted will store in memory | -| ARCHIVER_POLLING_INTERVAL_MS | The polling interval in ms for retrieving new L2 blocks and encrypted logs | -| SEQ_PUBLISHER_PRIVATE_KEY | This should be the same as your validator private key | -| SEQ_PUBLISH_RETRY_INTERVAL_MS | The interval to wait between publish retries | -| SEQ_VIEM_POLLING_INTERVAL_TIME | The polling interval viem uses in ms | - -### Sequencer Config - -The Sequencer Client is a criticial component that coordinates tx validation, L2 block creation, collecting attestations and block submission (through the Publisher). - -| Variable | Description | -| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| VALIDATOR_DISABLED | If this is True, the client won't perform any validator duties. | -| VALIDATOR_ATTESTATIONS_POLLING_INTERVAL_MS | If not enough attestations, sleep for this long and check again | -| GOVERNANCE_PROPOSER_PAYLOAD_ADDRESS | To nominate proposals for voting, you must set this variable to the Ethereum address of the `proposal` payload. You must edit this to vote on a governance upgrade. | -| SEQ_ENFORCE_TIME_TABLE | Whether to enforce strict timeliness requirement when building blocks. Refer [here](#sequencer-timeliness-requirements) for more on the timetable | -| SEQ_MAX_TX_PER_BLOCK | Increase this to make larger blocks | -| SEQ_MIN_TX_PER_BLOCK | Increase this to require making larger blocks | -| COINBASE | This is the Ethereum address that will receive the validator's share of block rewards. It defaults to your validator address. | -| FEE_RECIPIENT | This is the Aztec address that will receive the validator's share of transaction fees. Also defaults to your validator's address (but on Aztec L2). | - -#### Sequencer Timeliness Requirements - -During testing, it was helpful to constrain some actions of the sequencer based on the time passed into the slot. The time-aware sequencer can be told to do action A only if there's a certain amount of time left in the slot. - -For example, at the beginning of a slot, the sequencer will first sync state, then request txs from peers then attempt to build a block, then collect attestations then publish to L1. You can create constraints of the form "Only attempt to build a block if under 5 seconds have passed in the slot". - -If this is helpful in your testing as well, you can turn it on using the environment variable `SEQ_ENFORCE_TIME_TABLE`. - -Currently the default timetable values are hardcoded in [sequencer.ts](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/sequencer-client/src/sequencer/sequencer.ts#L72). Time checks are enforced in `this.setState()`. - -### P2P Config - -The P2P client coordinates peer-to-peer communication between Nodes. - -| Variable | Description | -| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| BOOTSTRAP_NODES | A list of bootstrap peer ENRs to connect to. Separated by commas. | -| P2P_IP | The client's public IP address. Defaults to working it out using disv5, otherwise set P2P_QUERY_FOR_IP if you are behind a NAT | -| P2P_PORT | The port that will be used for sending / receiving p2p messages. Defaults to 40400. | -| P2P_LISTEN_ARR | Address to listen on for p2p messages. Defaults to 0.0.0.0 | -| P2P_QUERY_FOR_IP | Useful in dynamic environments where your IP is not known in advance. Set this to True, and only supply `:TCP_PORT` and `:UDP_PORT` for the `ANNOUNCE_ADDR` variables. If you know your public IP address in advance, set this to False or just provide the full announce addresses. | -| P2P_ENABLED | Whether to run the P2P module. Defaults to False, so make sure to set to True | -| P2P_MAX_PEERS | The max number of peers to connect to. | -| P2P_BLOCK_CHECK_INTERVAL_MS | How milliseconds to wait between each check for new L2 blocks. | - -### Prover Config - -Please refer to the Epoch Proving Integration [Guide](https://hackmd.io/@aztec-network/epoch-proving-integration-guide) for info on how to setup your prover node. - -## Governance Upgrades - -During a governance upgrade, we'll announce details on the discord. At some point we'll also write AZIPs (Aztec Improvement Proposals) and post them to either the github or forum to collect feedback. - -We'll deploy the payload to the L1 and share the address of the payload with the sequencers on discord. - -To participate in the governance vote, sequencers must change the variable `GOVERNANCE_PROPOSER_PAYLOAD_ADDRESS` in the Sequencer Client to vote during the L2 slot they've been assigned sequencer duties. - -## Troubleshooting - -> [!TIP] -> Please make sure you are in the Discord server and that you have been assigned the role `S&P Participant`. Say gm in the `sequencer-and-prover` channel and turn on notifications for the announcements channel. - -If you encounter any errors or bugs, please try basic troubleshooting steps like restarting your node, checking ports and configs. - -If issue persists, please share on the sequencer-and-prover channel and tag [Amin](discordapp.com/users/65773032211231539). - -Some issues are fairly light, the group and ourselves can help you within 60 minutes. If the issue isn't resolved, please send more information: - -**Error Logs**: Attach any relevant error logs. If possible, note the timestamp when the issue began. -**Error Description**: Briefly describe the issue. Include details like what you were doing when it started, and any unusual behaviors observed. -**Steps to Reproduce (if known)**: If there’s a clear way to reproduce the error, please describe it. -**System Information**: Share details like your system’s operating system, hardware specs, and any other relevant environment information. - -That way we can dedicate more time to troubleshoot and open Github issues if no known fix. diff --git a/spartan/releases/create-spartan.sh b/spartan/releases/create-spartan.sh deleted file mode 100755 index 3b42d7e66757..000000000000 --- a/spartan/releases/create-spartan.sh +++ /dev/null @@ -1,37 +0,0 @@ -#!/usr/bin/env bash - -# URL of the aztec-sequencer.sh script -DEFAULT_URL="https://raw.githubusercontent.com/AztecProtocol/aztec-packages/refs/heads/master/spartan/releases/testnet/aztec-sequencer.sh" - -# Colors for output -GREEN='\033[0;32m' -RED='\033[0;31m' -NC='\033[0m' # No Color - -# Download the script -echo "Downloading aztec-sequencer.sh..." -if curl -L -o aztec-sequencer.sh "${1:-$DEFAULT_URL}"; then - chmod +x aztec-sequencer.sh - echo -e "${GREEN}✓ aztec-sequencer.sh has been downloaded and made executable${NC}" - echo "You can now run it with: ./aztec-sequencer.sh" -else - echo -e "${RED}✗ Failed to download aztec-sequencer.sh${NC}" - exit 1 -fi - -# Check if jq is installed -if ! command -v jq &> /dev/null; then - echo "jq is not installed. Installing jq..." - if command -v apt-get &> /dev/null; then - sudo apt-get update - sudo apt-get install -y jq - elif command -v yum &> /dev/null; then - sudo yum install -y jq - elif command -v brew &> /dev/null; then - brew install jq - else - echo -e "${RED}✗ Could not install jq. Please install it manually.${NC}" - exit 1 - fi - echo -e "${GREEN}✓ jq has been installed${NC}" -fi diff --git a/spartan/releases/testnet/aztec-sequencer.sh b/spartan/releases/testnet/aztec-sequencer.sh deleted file mode 100755 index 71bfb932c7ce..000000000000 --- a/spartan/releases/testnet/aztec-sequencer.sh +++ /dev/null @@ -1,395 +0,0 @@ -#!/usr/bin/env bash - -set -e - -# Colors and formatting -BLUE='\033[0;34m' -GREEN='\033[0;32m' -RED='\033[0;31m' -YELLOW='\033[1;33m' -NC='\033[0m' # No Color - -# Global variables -DEFAULT_P2P_PORT="40500" -DEFAULT_PORT="8080" -DEFAULT_KEY="0x0000000000000000000000000000000000000000000000000000000000000001" -# Try to get default IP from ipify API, otherwise leave empty to require user input -DEFAULT_IP=$(curl -s --connect-timeout 5 https://api.ipify.org?format=json | grep -o '"ip":"[^"]*' | cut -d'"' -f4 || echo "") -DEFAULT_BIND_MOUNT_DIR="$HOME/aztec-data" - -# unset these to avoid conflicts with the host's environment -ETHEREUM_HOSTS= -L1_CONSENSUS_HOST_URLS= -IMAGE= -BOOTNODE_URL= -LOG_LEVEL=info -# Parse command line arguments -parse_args() { - while [[ $# -gt 0 ]]; do - case $1 in - -b | --bootnode-url) - BOOTNODE_URL="$2" - shift 2 - ;; - -n | --network) - NETWORK="$2" - shift 2 - ;; - -i | --image) - IMAGE="$2" - shift 2 - ;; - -e | --ethereum-hosts) - ETHEREUM_HOSTS="$2" - shift 2 - ;; - -l | --l1-consensus-host-urls) - L1_CONSENSUS_HOST_URLS="$2" - shift 2 - ;; - -p | --port) - CLI_PORT="$2" - shift 2 - ;; - -p2p | --p2p-port) - CLI_P2P_PORT="$2" - shift 2 - ;; - -ip | --ip) - CLI_IP="$2" - shift 2 - ;; - -k | --key) - CLI_KEY="$2" - shift 2 - ;; - -d | --data-dir) - BIND_MOUNT_DIR="$2" - shift 2 - ;; - -pk | --p2p-id-private-key) - PEER_ID_PRIVATE_KEY="$2" - shift 2 - ;; - -v | --verbose) - LOG_LEVEL=debug - shift - ;; - *) - shift - ;; - esac - done -} - -# Show banner function -show_banner() { - echo -e "${BLUE}" - echo " _ ____ _____ _____ _____ _____ _____ ____ _____ _ _ _____ _____ " - echo " / \ |_ /|_ _| _____| __/|_ _| ____/ ___|_ _| \ | | ____|_ _|" - echo " / _ \ / / | | | _| | | | | | _| \___ \ | | | \| | _| | | " - echo " / ___ \/ /_ | | | |___ | |__ | | | |___ ___) || | | |\ | |___ | | " - echo "/_/ \_\___| |_| |______|____\ |_| |_____|____/ |_| |_| \_|_____| |_| " - echo -e "${NC}" -} - -# Get public IP -get_public_ip() { - echo -e "${BLUE}Fetching public IP...${NC}" - PUBLIC_IP=$(curl -s https://api.ipify.org?format=json | grep -o '"ip":"[^"]*' | cut -d'"' -f4) - if [ -n "$PUBLIC_IP" ]; then - echo -e "${GREEN}Public IP: $PUBLIC_IP${NC}" - return 0 - else - echo -e "${YELLOW}Failed to get public IP${NC}" - return 1 - fi -} - -# Configure environment -configure_environment() { - local args=("$@") - parse_args "${args[@]}" - - echo -e "${BLUE}Configuring environment...${NC}" - if [ -n "$NETWORK" ]; then - NETWORK="$NETWORK" - else - read -p "Network [ignition-testnet]: " NETWORK - NETWORK=${NETWORK:-ignition-testnet} - fi - - # if the network is `ignition-testnet` - if [ "$NETWORK" = "ignition-testnet" ]; then - REGISTRY_CONTRACT_ADDRESS="${REGISTRY_CONTRACT_ADDRESS:-0x12b3ebc176a1646b911391eab3760764f2e05fe3}" - # Determine architecture and set the image accordingly - if [[ "$(uname -m)" == "x86_64" ]]; then - IMAGE="${IMAGE:-aztecprotocol/aztec:1dc66419e0e7e1543bee081471701f90192fa33e-amd64}" - else - IMAGE="${IMAGE:-aztecprotocol/aztec:1dc66419e0e7e1543bee081471701f90192fa33e-arm64}" - fi - else - # unknown network - echo -e "${RED}Unknown network: $NETWORK${NC}" - fi - - if [ -z "$IMAGE" ] || [ -z "$REGISTRY_CONTRACT_ADDRESS" ]; then - echo -e "${RED}Bootstrap Nodes, Ethereum host, image and Registry contract address are required${NC}" - exit 1 - fi - - if [ -n "$ETHEREUM_HOSTS" ]; then - ETHEREUM_HOSTS="$ETHEREUM_HOSTS" - else - while true; do - read -p "Sepolia Ethereum Host (ex. Infura, Alchemy, etc.): " ETHEREUM_HOSTS - if [ -z "$ETHEREUM_HOSTS" ]; then - echo -e "${RED}Error: Ethereum Hosts is required${NC}" - else - break - fi - done - fi - - if [ -n "$L1_CONSENSUS_HOST_URLS" ]; then - L1_CONSENSUS_HOST_URLS="$L1_CONSENSUS_HOST_URLS" - else - while true; do - read -p "L1 Consensus Host URLs: " L1_CONSENSUS_HOST_URLS - if [ -z "$L1_CONSENSUS_HOST_URLS" ]; then - echo -e "${RED}Error: L1 Consensus Host URLs are required${NC}" - else - break - fi - done - fi - - # # get the node info - # get_node_info - - if [ -n "$CLI_P2P_PORT" ]; then - P2P_PORT="$CLI_P2P_PORT" - else - read -p "P2P Port [$DEFAULT_P2P_PORT]: " P2P_PORT - P2P_PORT=${P2P_PORT:-$DEFAULT_P2P_PORT} - fi - - if [ -n "$CLI_PORT" ]; then - PORT="$CLI_PORT" - else - read -p "Node Port [$DEFAULT_PORT]: " PORT - PORT=${PORT:-$DEFAULT_PORT} - fi - - if [ -n "$CLI_KEY" ]; then - KEY="$CLI_KEY" - else - while true; do - read -p "Validator Private Key: " KEY - if [ -z "$KEY" ]; then - echo -e "${RED}Error: Validator Private Key is required${NC}" - else - break - fi - done - fi - - if [ -n "$CLI_COINBASE" ]; then - COINBASE="$CLI_COINBASE" - else - while true; do - read -p "Validator Address (Coinbase): " COINBASE - - if [ -z "$COINBASE" ]; then - echo -e "${RED}Error: Validator Address (Coinbase) is required${NC}" - else - if [[ "$COINBASE" =~ ^0x[a-fA-F0-9]{40}$ ]]; then - break - else - echo -e "${RED}Error: Invalid COINBASE address. Please enter a valid Ethereum address.${NC}" - fi - fi - - done - fi - - if [ -n "$CLI_IP" ]; then - IP="$CLI_IP" - else - if [ -z "$DEFAULT_IP" ]; then - while true; do - read -p "Public IP: " IP - if [ -z "$IP" ]; then - echo -e "${RED}Error: Public IP is required${NC}" - else - break - fi - done - else - read -p "Public IP [$DEFAULT_IP]: " IP - IP=${IP:-$DEFAULT_IP} - fi - fi - - if [ -n "$BIND_MOUNT_DIR" ]; then - BIND_MOUNT_DIR="$BIND_MOUNT_DIR" - else - read -p "Use docker volume for data directory? [Y/n] " -n 1 -r - echo - if [[ $REPLY =~ ^[Nn]$ ]]; then - read -p "Relative path for data directory [${DEFAULT_BIND_MOUNT_DIR}]: " BIND_MOUNT_DIR - BIND_MOUNT_DIR=${BIND_MOUNT_DIR:-$DEFAULT_BIND_MOUNT_DIR} - fi - fi - - # Generate .env file - cat >.env <docker-compose.yml < - sh -c ' - - test -z "\$PEER_ID_PRIVATE_KEY" -a ! -f /var/lib/aztec/p2p-private-key && node /usr/src/yarn-project/aztec/dest/bin/index.js generate-p2p-private-key | head -1 | cut -d" " -f 3 | tee /var/lib/aztec/p2p-private-key || echo "Re-using existing P2P private key" - test -z "\$PEER_ID_PRIVATE_KEY" && export PEER_ID_PRIVATE_KEY=\$(cat /var/lib/aztec/p2p-private-key) - - node --no-warnings /usr/src/yarn-project/aztec/dest/bin/index.js start --node --archiver --sequencer' -EOF - - # Add volume configuration based on user choice - if [ -n "$BIND_MOUNT_DIR" ]; then - cat >>docker-compose.yml <>docker-compose.yml <