chore(docs): node docs to v2

docs/docs/the_aztec_network/concepts/deployments/what_is_deployment.md

@@ -22,7 +22,7 @@ Hypothetical Asset would live on Ethereum L1. It may have a minter which would b
 
 This is brought up to the community for discussion purposes only to illustrate how proposed governance mechanisms could work with a Hypothetical Asset.
 
-- **Validators** must stake the Hypothetical Asset within the instance's contract to join that instance's validator set.
+- **Sequencers** must stake the Hypothetical Asset within the instance's contract to join that instance's sequencer set.
 - **Holders** must lock Hypothetical Asset with the Governance contract to be able to vote on proposals.
 - **Provers** must deposit Hypothetical Asset in the escrow contract in order to bid for the right to create a proof for an epoch.
 

docs/docs/the_aztec_network/concepts/governance/putting_forward_proposals.md

@@ -10,9 +10,9 @@ Sequencers can only nominate a proposal during an L2 slot for which they’ve be
 
 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:
+To nominate a proposal, a sequencer 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.
+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, sequencers can set the `GOVERNANCE_PROPOSAL_PAYLOAD=_proposal` env variable which will call `vote(address _proposal)` during a slot they're eligible to signal in.

docs/docs/the_aztec_network/concepts/governance/upgrades.md

@@ -38,4 +38,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](../../reference/reacting_to_upgrades.md).
+For a more hands-on guide to reacting to upgrades as a sequencer, read [this](../../reference/reacting_to_upgrades.md).

docs/docs/the_aztec_network/concepts/governance/voting.md

@@ -8,4 +8,4 @@ Holders have the ability to vote on proposals as long as they lock any Hypotheti
 
 Hypothetical Assets locked in the Governance contract are simply locked and not “at stakeˮ i.e. there are no slashing conditions.
 
-Since sequencers may be able to stake Hypothetical Assets with the rollup instances in order to join the validator set, the rollup instance could in turn lock those Hypothetical Assets in the Governance contract and vote on behalf of the sequencers. This is expected behavior.
+Since sequencers may be able to stake Hypothetical Assets with the rollup instances in order to join the sequencer set, the rollup instance could in turn lock those Hypothetical Assets in the Governance contract and vote on behalf of the sequencers. This is expected behavior.

docs/docs/the_aztec_network/concepts/proof_of_stake/slashing.md

@@ -17,21 +17,21 @@ 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. 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 that a significant portion of the sequencer 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 sequencer set is bypassed and anyone can advance the chain in the event of an inactive / non-participating sequencer 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 sequencers must be removed from the sequencer set or otherwise we end up in Based Fallback too often. Slashing is a method whereby the sequencer set votes to “slash” the stake of inactive sequencers down to a point where they are kicked off the sequencer set. For example, if we set `MINIMUM_STAKING_BALANCE=50%` then as soon as 50% or more of a sequencer's balance is slashed, they will be kicked out of the set.
 
 ### Committee withholding data from the provers
 
 Provers need the transaction data (i.e. `TxObjects`) plus the client-side generated proofs to produce the final rollup proof, none of which are posted onchain. Client side proofs + transaction data are gossiped on the p2p instead so that committee members can re-execute block proposals and verify that the proposed state root is correct.
 
-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.
+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 sequencers, randomly sampled from the entire sequencer 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 sequencer 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
 
@@ -48,6 +48,6 @@ An honest prover who has funds at stake (i.e. posted a bond to produce the epoch
 
 In all the previous cases, it is very hard to verify and automatically slash for these events onchain. This is mainly due to the fact that neither TxObjects nor client side proofs are posted onchain. Committee members also gossip attestations on the p2p and do not post them directly on chain.
 
-Therefore a slashing mechanism is required as a deterrence against the malicious behaviour by validators and to make sure that the Aztec Rollup retains liveness. The validator set votes to slash dishonest validators based on evidence that is collected onchain + offchain, and discussed and analyzed offchain (i.e. on a forum).
+Therefore a slashing mechanism is required as a deterrence against the malicious behaviour by sequencers and to make sure that the Aztec Rollup retains liveness. The sequencer set votes to slash dishonest sequencers based on evidence that is collected onchain + offchain, and discussed and analyzed offchain (i.e. on a forum).
 
-A validator must aggregate BLS signatures on slashing proposals and post them to the L1 for slash execution.
+A sequencer must aggregate BLS signatures on slashing proposals and post them to the L1 for slash execution.

docs/docs/the_aztec_network/concepts/provers-and-sequencers/index.md

@@ -13,4 +13,4 @@ Sequencers will be chosen via a random election, while provers will be selected
 
 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.
 
-If are you interested in running a validator node (also known as a sequencer node) or a prover node, you can refer to [the guides section](./../../guides/run_nodes/index.md).
+If are you interested in running a sequencer node or a prover node, you can refer to [the guides section](./../../guides/run_nodes/index.md).