Write your first contract
+
+
+
+
+ Get started on Aztec by installing the sandbox and playing with it
+
+
+
+
+## Build applications
+
+Getting Started
+
+
+
+
+
+ Go from zero to hero by following these tutorials in order, starting with a counter contract
+
+
+
+
+
+
+
+ Learn how everything works together by building an app in JavaScript that connects to a contract
+
+
+
+
+## Clone a repo
+
+Contract Tutorials
+Full stack app on Aztec
+
+
+ Full stack app on Aztec
+
-
-
-
-
- Get started on Aztec by installing the sandbox and playing with it
-
-
-
-
-## Building applications
-
-Getting Started
-
-
-
-
-
- Go from zero to hero by following these tutorials in order, starting with a counter contract
-
-
-
-
-
-
-
- Learn how everything works together by building an app in JavaScript that connects to a contract
-
-
-
diff --git a/docs/docs/index.mdx b/docs/docs/index.mdx
index c4a07c696521..79431c7fa54f 100644
--- a/docs/docs/index.mdx
+++ b/docs/docs/index.mdx
@@ -22,12 +22,12 @@ On Ethereum today, everything is publicly visible, by everyone. In the real worl
To make this possible, Aztec is *not EVM compatible* and is extending the Ethereum ecosystem by creating a new alt-VM!
-To learn more about how Aztec achieves these things, check out the [Aztec concepts overview](/aztec/concepts_overview).
+To learn more about how Aztec achieves these things, check out the [Aztec concepts overview](/aztec).
## Start coding
Contract Tutorials
-Full stack app on Aztec
-
-
+
@@ -40,7 +40,7 @@ To learn more about how Aztec achieves these things, check out the [Aztec concep
## Learn how Aztec works
Developer Getting Started Guide
-
+
diff --git a/docs/docs/protocol-specs/calls/public-private-messaging.md b/docs/docs/protocol-specs/calls/public-private-messaging.md
index a1121fbad46e..3dc4ab83e5ea 100644
--- a/docs/docs/protocol-specs/calls/public-private-messaging.md
+++ b/docs/docs/protocol-specs/calls/public-private-messaging.md
@@ -19,10 +19,7 @@ Since private functions execute first, they cannot 'wait' on the results of thei
By way of example, suppose a function makes a call to a public function, and then to a private function. The public function will not be executed immediately, but will instead be enqueued for the sequencer to execute later.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph LR
A[Private Function 1] --> |1st call| B(Public Function 1)
A --> |2nd call| C[Private Function 2]
@@ -30,15 +27,11 @@ graph LR
A --> |3rd call| D(Public Function 2)
A --> |4th call| E[Private Function 3]
E --> |return values| A
-
```
The order of execution will actually be:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph LR
A[Private Function 1] --> C[Private Function 2]
C --> |return values| A
@@ -46,18 +39,13 @@ graph LR
E --> |return values| A
A -----> |Enqueued| B(Public Function 1)
A -----> |Enqueued| D(Public Function 2)
-
```
And the order of proving will actually be:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
flowchart LR
A[Private Function 1] --> C[Private Function 2] --> E[Private Function 3] ----> B(Public Function 1) --> D(Public Function 2)
-
```
## Private to Public Messaging
diff --git a/docs/docs/protocol-specs/circuits/high-level-topology.md b/docs/docs/protocol-specs/circuits/high-level-topology.md
index caca2bee49b9..43f00cb05ea1 100644
--- a/docs/docs/protocol-specs/circuits/high-level-topology.md
+++ b/docs/docs/protocol-specs/circuits/high-level-topology.md
@@ -15,10 +15,7 @@ A note for Aztec protocol developers: In this protocol spec, the order in which
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
flowchart LR
f0([f0]) --> f1([f1])
f0 --> f2([f2])
@@ -30,15 +27,11 @@ flowchart LR
f3 --> f4([f4])
f3 -.-> F4
f3 --> f5([f5])
-
```
This transaction contains 6 private functions (f0 to f5) and 5 public functions (F0 to F4), with `f0` being the entrypoint. The entire transaction is processed as follows:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
flowchart TB
subgraph Transaction A
subgraph Private Functions
@@ -133,7 +126,6 @@ flowchart TB
MR1 --> MR2
MR2 --> ROOT
MR3 --> ROOT
-
```
A few things to note:
diff --git a/docs/docs/protocol-specs/circuits/private-kernel-initial.mdx b/docs/docs/protocol-specs/circuits/private-kernel-initial.mdx
index 2258bd682515..4d414ea9909e 100644
--- a/docs/docs/protocol-specs/circuits/private-kernel-initial.mdx
+++ b/docs/docs/protocol-specs/circuits/private-kernel-initial.mdx
@@ -296,10 +296,7 @@ Key:
+```mermaid
classDiagram
direction TB
@@ -552,6 +549,7 @@ PrivateKernelPublicInputs ..> KERNEL_PROOF_VERIFICATION
KernelVerificationKey ..> KERNEL_VK_EXISTENCE_CHECK
KernelVKMembershipWitness ..> KERNEL_VK_EXISTENCE_CHECK
+
```
diff --git a/docs/docs/protocol-specs/cryptography/hashing/hashing.md b/docs/docs/protocol-specs/cryptography/hashing/hashing.md
index 6f83f0b8f98e..bb093888eb67 100644
--- a/docs/docs/protocol-specs/cryptography/hashing/hashing.md
+++ b/docs/docs/protocol-specs/cryptography/hashing/hashing.md
@@ -14,7 +14,7 @@ To minimize the potential for collisions between distinct hashing contexts, all
In the case of using Poseidon2 for hashing (which is the case for most hashing in the Aztec protocol), the string is converted from a big-endian byte representation into a `Field` element, and passed as a first argument into the hash. In the case of using non-algebraic hash functions (such as sha256), the string is converted from a big-endian byte representation into bits, and passed as the first bits into the hash. These details are conveyed more clearly as pseudocode in the relevant sections of the spec.
-For some hashes there is further domain-separation. For example, [Merkle tree hashing](../../../aztec/concepts/storage/trees/index.md#layers) of the tree.
+For some hashes there is further domain-separation. For example, [Merkle tree hashing](../merkle-trees.md#hashing) of the tree.
### Pseudo-randomness
diff --git a/docs/docs/protocol-specs/decentralization/block-production.md b/docs/docs/protocol-specs/decentralization/block-production.md
index 0306f1fd119d..a344e68efff9 100644
--- a/docs/docs/protocol-specs/decentralization/block-production.md
+++ b/docs/docs/protocol-specs/decentralization/block-production.md
@@ -1,4 +1,8 @@
-# Aztec Block Production
+---
+title: Block Production
+draft: true
+---
+
:::info
This document aims to be the latest source of truth for the Fernet sequencer selection protocol, and reflect the decision to implement the [Sidecar](https://forum.aztec.network/t/proposal-prover-coordination-sidecar/2428) proving coordination protocol. Notably, this is written within the context of the first instance or deployment of Aztec. The definitions and protocol may evolve over time with each version.
@@ -88,12 +92,7 @@ What is Aztec's economic security needs? Please clarify.
Currently, Provers don't need to register but must commit a bond during the `prover commitment phase` articulated below. This ensures economic guarantees for timely proof generation, and therefore short-term liveness. If the prover is unable or unwilling to produce a proof for which they committed to in the allotted time their bond will be slashed.
-Future updates may introduce a registration process for Provers, possibly leading to a smaller, more consistent group, but this is currently not suggested to be required.
-
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Anyone
@@ -101,9 +100,8 @@ participant Contract as Aztec L1 Contract
participant Network as Aztec Network
Anyone ->> Contract: register as a sequencer
-Anyone --> Anyone: Wait 7 days
+Anyone --> Anyone: Wait epoch
Anyone ->> Network: eligible as a sequencer
-
```
## Block production
@@ -130,10 +128,7 @@ Every staked sequencers participate in the following phases, comprising an Aztec
- For data layers that is not on the host, the host must have learned of the publication from the **Reveal** before the **Finalization** can begin.
6. **Backup:** Should no prover commitment be put down, or should the block not get finalized, then an additional phase is opened where anyone can submit a block with its proof, in a based-rollup mode. In the backup phase, the first rollup verified will become canonical.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Contract as Aztec L1 Contract
@@ -156,7 +151,6 @@ loop Happy Path Block Production
Contract --> Contract: validates proofs and state transition
Note right of Contract: "block confirmed!"
end
-
```
### Constraining Randao
@@ -185,10 +179,7 @@ When a sequencer move to `exiting`, they might have to await for an additional d
**Lasse Comment**: I'm unsure what you mean by "active" here. Is active that you are able to produce blocks? Is so, active seems fine. Also, not clear to me if `exiting` means that they be unable to propose blocks? If they are voting in them, sure put a delay in there, but otherwise I don't see why they should be unable to leave (when we don't have consensus for block production).
:::
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Anyone as Sequencer
@@ -199,8 +190,6 @@ Anyone ->> Contract: exit() from being a sequencer
Note left of Contract: Sequencer no longer eligible for Fernet elections
Anyone --> Anyone: Wait 7-21 days
Anyone ->> Network: exit successful, stake unlocked
-
-
```
## Confirmation rules
@@ -220,10 +209,7 @@ Below, we outline the stages of confirmation.
6. In a proven block that has been verified / validated by the L1 rollup contracts
7. In a proven block that has been finalized on the L1
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Anyone as User
@@ -243,15 +229,11 @@ Contract --> Contract: waits N more blocks
Contract --> Contract: finalizes block
Network --> Contract: updates state to reflect finality
Anyone ->> Network: confirms on their own node or block explorer
-
```
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
journey
title Wallet use case, basic transfer (tx confirmation happy path)
section User Device
@@ -264,7 +246,6 @@ journey
section L1
Tx in block verified on L1: 6: Sequencer
Tx in block finalized on L1: 7: Sequencer
-
```
## Economics
@@ -306,10 +287,7 @@ Initially it's expected that the negotiations and commitment could be facilitate
I'm not fully understanding the different groups, is the aztec network just the node software or 👀? Maybe coloring is nice to mark what is contracts and entities or groups of entities. Otherwise seems quite nice.
:::
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Anyone
@@ -319,7 +297,7 @@ participant Sequencers
participant Provers
Anyone ->> Contract: register()
-Anyone --> Anyone: Wait 7 days
+Anyone --> Anyone: Wait epoch
Anyone ->> Network: eligible as a sequencer
loop Happy Path Block Production
Sequencers --> Sequencers: Generate random hashes and rank them
@@ -337,18 +315,14 @@ loop Happy Path Block Production
Note right of Contract: "block confirmed!"
end
Sequencers ->> Contract: exit()
-Sequencers --> Sequencers: wait 7 days
-
+Sequencers --> Sequencers: wait epoch
```
### Voting on upgrades
In the initial implementation of Aztec, sequencers may vote on upgrades alongside block proposals. If they wish to vote alongside an upgrade, they signal by updating their client software or an environment configuration variable. If they wish to vote no or abstain, they do nothing. Because the "election" is randomized, the voting acts as a random sampling throughout the current sequencer set. This implies that the specific duration of the vote must be sufficiently long and RANDAO sufficiently randomized to ensure that the sampling is reasonably distributed.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Contract as Aztec L1 Contract
@@ -371,17 +345,13 @@ loop Happy Path Block Production
Contract --> Contract: validates proofs and state transition
Note right of Contract: "block confirmed! votes counted for upgrade!"
end
-
```
### Backup mode
In the event that no one submits a valid block proposal, we introduce a "backup" mode which enables a first come first serve race to submit the first proof to the L1 smart contracts.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Anyone
@@ -398,7 +368,6 @@ loop Happy Path Block Production
Contract --> Contract: validates proofs and state transition
Note right of Contract: "block confirmed!"
end
-
```
:::danger
@@ -407,10 +376,7 @@ There is an outstanding concern that this may result in L1 censorship. L1 builde
We also introduce a similar backup mode in the event that there is a valid proposal, but no valid prover commitment (deposit) by the end of the prover commitment phase.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Anyone
@@ -431,7 +397,6 @@ loop Happy Path Block Production
Contract --> Contract: validates proofs and state transition
Note right of Contract: "block confirmed!"
end
-
```
## Glossary
diff --git a/docs/docs/protocol-specs/decentralization/governance.md b/docs/docs/protocol-specs/decentralization/governance.md
index c4484f26e814..ee7208b76f93 100644
--- a/docs/docs/protocol-specs/decentralization/governance.md
+++ b/docs/docs/protocol-specs/decentralization/governance.md
@@ -128,10 +128,7 @@ Importantly we differentiate between `Aztec Governance`, and the governance of a
### Happy path
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Current Canonical Rollup as Current Rollup
@@ -155,17 +152,13 @@ Version Registry ->> Version Registry: markPendingCanonical(nextRollup)
Note right of Version Registry: Wait at least 30 days!
Next Rollup ->> Version Registry: markCanonical(nextRollup)
Sequencers ->> Next Rollup: Proposing new blocks here!
-
```
### "Bricked" rollup proposals
In this diagram, we articulate the scenario in which the current canonical rollup contains bugs that result in it being unable to produce not only a block, but a vote of any kind. In this scenario, someone or a group (Lasse refers to as the "unbrick DAO") may lock 1% (specific # TBD) of total supply in order to propose a new canonical rollup. It is expected that this scenario is very unlikely, however, we believe it to be a nice set of checks and balances between the token holders and the decisions of the current rollup implementation.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Current Canonical Rollup as Current Rollup
@@ -185,7 +178,6 @@ Note right of Version Registry: Wait at least 30 days!
Note left of Sequencers: Upgrade to new client
Next Rollup ->> Version Registry: markCanonical(nextRollup)
Sequencers ->> Next Rollup: Proposing new blocks here!
-
```
### Vote Delegation
@@ -198,10 +190,7 @@ Any token holder can delegate their token's voting weight to another address, in
The diagram below articulates calling delegateTo(address) on both the governance contract and specifying a particular address. Additionally calling delegateTo() on the current canonical rollup if you wish to align with whatever voting mechanism that system currently as in place.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
participant Current Canonical Rollup as Current Rollup
@@ -229,7 +218,6 @@ Version Registry ->> Version Registry: markPendingCanonical(nextRollup)
Note right of Version Registry: Wait at least 30 days!
Next Rollup ->> Version Registry: markCanonical(nextRollup)
Sequencers ->> Next Rollup: Proposing new blocks here!
-
```
## Emergency mode
diff --git a/docs/docs/protocol-specs/gas-and-fees/kernel-tracking.md b/docs/docs/protocol-specs/gas-and-fees/kernel-tracking.md
index 47ad4edb8f9c..738c4ba5ffe8 100644
--- a/docs/docs/protocol-specs/gas-and-fees/kernel-tracking.md
+++ b/docs/docs/protocol-specs/gas-and-fees/kernel-tracking.md
@@ -16,10 +16,7 @@ On the private side, the ordering of the circuits is:
The structs are (irrelevant fields omitted):
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
class PrivateContextInputs {
@@ -147,7 +144,7 @@ class PrivateKernelTailToPublicCircuitPrivateInputs {
+PrivateKernelData previous_kernel
}
PrivateKernelTailToPublicCircuitPrivateInputs --> PrivateKernelData
-
+
```
## Private Context Initialization
@@ -275,10 +272,7 @@ On the public side, the order of the circuits is:
The structs are (irrelevant fields omitted):
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
class Gas {
@@ -411,7 +405,7 @@ class GasFees {
+Fr fee_per_da_gas
+Fr fee_per_l2_gas
}
-
+
```
## Public Context Initialization
diff --git a/docs/docs/protocol-specs/gas-and-fees/specifying-gas-fee-info.md b/docs/docs/protocol-specs/gas-and-fees/specifying-gas-fee-info.md
index cede01d0c097..274afac824fd 100644
--- a/docs/docs/protocol-specs/gas-and-fees/specifying-gas-fee-info.md
+++ b/docs/docs/protocol-specs/gas-and-fees/specifying-gas-fee-info.md
@@ -8,10 +8,7 @@ When users submit a `TxExecutionRequest` on the Aztec Network, they provide a `T
An abridged version of the class diagram is shown below:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
class TxExecutionRequest {
+TxContext txContext
@@ -41,7 +38,6 @@ class GasFees {
TxContext --> GasSettings
GasSettings --> Gas
GasSettings --> GasFees
-
```
:::note
@@ -77,10 +73,7 @@ Separately, the **protocol** specifies the current `feePerGas` for each dimensio
These are held in the L2 blocks `Header`
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
class Header {
+GlobalVariables globalVariables
@@ -100,7 +93,6 @@ class GasFees {
Header --> GlobalVariables
GlobalVariables --> GasFees
-
```
A transaction cannot be executed if the `maxFeesPerGas` is less than the `feePerGas` for any dimension.
diff --git a/docs/docs/protocol-specs/intro.md b/docs/docs/protocol-specs/intro.md
index f9842bd3ead5..58966b25c73b 100644
--- a/docs/docs/protocol-specs/intro.md
+++ b/docs/docs/protocol-specs/intro.md
@@ -26,10 +26,7 @@ To increase the probability of diagrams being up-to-date we encourage you to wri
You simply create a codeblock specifying the language as `mermaid` and write your diagram in the codeblock. For example:
````txt
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph LR
A --> B
B --> C
@@ -37,10 +34,7 @@ graph LR
```
````
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph LR
A --> B
B --> C
@@ -52,10 +46,7 @@ Mermaid supports multiple types of diagrams, so finding one that suits your need
When writing class diagrams, we recommend using the `classDiagram` type and composition arrows `*--` to represent extensions. Also for the sake of readability, add all the components in the class itself, including composite types. For example:
````txt
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
class A{
foo: Bar
@@ -74,10 +65,7 @@ classDiagram
```
````
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
class A{
foo: Bar
diff --git a/docs/docs/protocol-specs/l1-smart-contracts/index.md b/docs/docs/protocol-specs/l1-smart-contracts/index.md
index db1326fede21..845c77e36aaa 100644
--- a/docs/docs/protocol-specs/l1-smart-contracts/index.md
+++ b/docs/docs/protocol-specs/l1-smart-contracts/index.md
@@ -63,10 +63,7 @@ For more information around the requirements we have for the availability, see [
Using the data structures defined throughout the [rollup circuits](./../rollup-circuits/index.md) section, we can outline the validating light node structure as follows:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
class Inbox {
@@ -88,7 +85,6 @@ class StateTransitioner {
StateTransitioner --> Inbox: consume()
StateTransitioner --> Outbox: insert()
StateTransitioner --> Verifier: verify()
-
```
### State transitioner
@@ -481,10 +477,7 @@ Below, we will outline the **LOGICAL** execution of a L2 block and how the contr
We will be executing cross-chain communication before and after the block itself.
Note that the L2 inbox only exists conceptually and its functionality is handled by the kernel and the rollup circuits.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
sequenceDiagram
autonumber
title Logical Interactions of Crosschain Messages
@@ -547,7 +540,6 @@ sequenceDiagram
P->>O: Consume a msg
O->>O: Validate msg
O->>O: Update state (nullify)
-
```
We will walk briefly through the steps of the diagram above.
diff --git a/docs/docs/protocol-specs/rollup-circuits/base-rollup.md b/docs/docs/protocol-specs/rollup-circuits/base-rollup.md
index 32df2e70bf42..a4859a4b4f46 100644
--- a/docs/docs/protocol-specs/rollup-circuits/base-rollup.md
+++ b/docs/docs/protocol-specs/rollup-circuits/base-rollup.md
@@ -6,23 +6,16 @@ The base rollup circuit is the most complex of the rollup circuits, as it has to
Take `BaseRollupInputs` as an input value, and transform it to `BaseOrMergeRollupPublicInputs` as an output value while making sure that the validity conditions are met.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph LR
A[BaseRollupInputs] --> C[BaseRollupCircuit] --> B[BaseOrMergeRollupPublicInputs]
-
```
## Overview
Below is a subset of the figure from [earlier](./index.md) (granted, not much is removed). The figure shows the data structures related to the Base Rollup circuit.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction TB
@@ -233,7 +226,6 @@ class BaseOrMergeRollupPublicInputs {
BaseOrMergeRollupPublicInputs *-- ConstantRollupData : constants
BaseOrMergeRollupPublicInputs *-- PartialStateReference : start
BaseOrMergeRollupPublicInputs *-- PartialStateReference : end
-
```
:::warning TODO
diff --git a/docs/docs/protocol-specs/rollup-circuits/index.md b/docs/docs/protocol-specs/rollup-circuits/index.md
index 1c7ca403926a..d85df805dd27 100644
--- a/docs/docs/protocol-specs/rollup-circuits/index.md
+++ b/docs/docs/protocol-specs/rollup-circuits/index.md
@@ -33,10 +33,7 @@ And for the message parity we have:
In the diagram the size of the tree is limited for demonstration purposes, but a larger tree would have more layers of merge rollups proofs. Exactly how many layers and what combination of `base` and/or `merge` circuits are consumed is based on filling a [wonky tree](../state/tree-implementations.md#wonky-merkle-trees) with N transactions.
Circles mark the different types of proofs, while squares mark the different circuit types.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
R_p((Root))
R_c[Root]
@@ -139,7 +136,6 @@ graph BT
style I1 fill:#1976D2;
style I2 fill:#1976D2;
style I3 fill:#1976D2;
-
```
To understand what the circuits are doing and what checks they need to apply it is useful to understand what data is going into the circuits and what data is coming out.
@@ -153,10 +149,7 @@ Note that the diagram does not include much of the operations for kernels, but m
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction TB
@@ -433,10 +426,7 @@ If this is not the case, the kernel proof might be valid, but the state changes
It is therefore of the highest importance that the circuits ensure that the state is progressed correctly across circuit types and proofs.
Logically, taking a few of the kernels from the above should be executed/proven as shown below, $k_n$ applied on top of the state that applied $k_{n-1}$
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph LR
SM[State Machine]
S0((State n-1))
@@ -478,10 +468,7 @@ We can do so by building merkle trees of partial "commitments", whose roots are
Below, we outline the `TxsHash` merkle tree that is based on the `TxEffect`s and a `OutHash` which is based on the `l2_to_l1_msgs` (cross-chain messages) for each transaction, with four transactions in this rollup.
While the `TxsHash` implicitly includes the `OutHash` we need it separately such that it can be passed to the `Outbox` for consumption by the portals with minimal work.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
R[TxsHash]
M0[Hash 0-1]
@@ -515,10 +502,7 @@ graph BT
K7 --> B3
```
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
R[OutHash]
M0[Hash 0-1]
@@ -568,10 +552,7 @@ graph BT
K15 --> K7
```
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
R[InHash]
M0[Hash 0-1]
diff --git a/docs/docs/protocol-specs/rollup-circuits/merge-rollup.md b/docs/docs/protocol-specs/rollup-circuits/merge-rollup.md
index b63ac550b3da..5d8ce56943f7 100644
--- a/docs/docs/protocol-specs/rollup-circuits/merge-rollup.md
+++ b/docs/docs/protocol-specs/rollup-circuits/merge-rollup.md
@@ -4,23 +4,16 @@ title: Merge Rollup
The Merge rollup circuit is our in-between circuit, it doesn't need to perform any state updates, but mainly check the consistency of its inputs.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph LR
A[MergeRollupInputs] --> C[MergeRollupCircuit] --> B[BaseOrMergeRollupPublicInputs]
-
```
## Overview
Below is a subset of the data structures figure from earlier for easy reference.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction TB
@@ -75,7 +68,6 @@ class MergeRollupInputs {
}
MergeRollupInputs *-- ChildRollupData: left
MergeRollupInputs *-- ChildRollupData: right
-
```
### Validity Conditions
diff --git a/docs/docs/protocol-specs/rollup-circuits/root-rollup.md b/docs/docs/protocol-specs/rollup-circuits/root-rollup.md
index f4185de2b892..0e09c4663ff9 100644
--- a/docs/docs/protocol-specs/rollup-circuits/root-rollup.md
+++ b/docs/docs/protocol-specs/rollup-circuits/root-rollup.md
@@ -4,13 +4,9 @@ title: Root Rollup
The root rollup circuit is our top circuit, it applies the state changes passed through its children and the cross-chain messages. Essentially, it is the last step that allows us to prove that the state transition function $\mathcal{T}(S, B) \mapsto S'$ was applied correctly for a state $S$ and a block $B$. Note, that the root rollup circuit's public inputs do not comprise the block entirely as it would be too costly to verify. Given a `ProvenBlock` and proof a node can derive the public inputs and validate the correctness of the state progression.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph LR
A[RootRollupInputs] --> C[RootRollupCircuit] --> B[RootRollupPublicInputs] --> D[ProvenBlock] --> E[Node]
-
```
For rollup purposes, the node we want to convince of the correctness is the [validating light node](../l1-smart-contracts/index.md) that we put on L1. We will cover it in more detail in the [cross-chain communication](../l1-smart-contracts/index.md) section.
@@ -21,10 +17,7 @@ This might practically happen through a series of "squisher" circuits that will
## Overview
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction TB
@@ -170,7 +163,6 @@ class RootRollupPublicInputs {
header: Header
}
RootRollupPublicInputs *--Header : header
-
```
### Validity Conditions
diff --git a/docs/docs/protocol-specs/rollup-circuits/tree-parity.md b/docs/docs/protocol-specs/rollup-circuits/tree-parity.md
index 6760e9877576..77ec759a851f 100644
--- a/docs/docs/protocol-specs/rollup-circuits/tree-parity.md
+++ b/docs/docs/protocol-specs/rollup-circuits/tree-parity.md
@@ -14,10 +14,7 @@ As earlier we are using a tree-like structure.
Instead of having a `base`, `merge` and `root` circuits, we will have only `base` and `root` parity circuits.
We only need these two, since what would have been the `merge` is doing the same as the `root` for this case.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
R((RootParity))
@@ -64,7 +61,6 @@ style I0 fill:#1976D2;
style I1 fill:#1976D2;
style I2 fill:#1976D2;
style I3 fill:#1976D2;
-
```
The output of the "combined" circuit will be the `converted_root` which is the root of the snark-friendly message tree.
@@ -72,10 +68,7 @@ And the `sha_root` which must match the root of the sha256 message tree from the
The circuit computes the two trees using the same inputs, and then we ensure that the elements of the trees match the inbox later in the [state transitioner](./../l1-smart-contracts/index.md#overview).
It proves parity of the leaves in the two trees.
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction LR
@@ -100,7 +93,6 @@ RootParityInput *-- ParityPublicInputs: public_inputs
class BaseParityInputs {
msgs: List~Fr[2]~
}
-
```
The logic of the circuits is quite simple - build both a SHA256 and a snark-friendly tree from the same inputs.
diff --git a/docs/docs/protocol-specs/state/archive.md b/docs/docs/protocol-specs/state/archive.md
index fd58b8206705..459cea3b924e 100644
--- a/docs/docs/protocol-specs/state/archive.md
+++ b/docs/docs/protocol-specs/state/archive.md
@@ -43,10 +43,7 @@ Therefore, we can probably remove the `contract_tree` and `ContractData` referen
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction TB
@@ -125,5 +122,4 @@ class ArchiveTree {
leaves: List~Header~
}
ArchiveTree *.. "m" Header : leaves
-
```
diff --git a/docs/docs/protocol-specs/state/index.md b/docs/docs/protocol-specs/state/index.md
index ac11c1fd9980..4dd342cfb806 100644
--- a/docs/docs/protocol-specs/state/index.md
+++ b/docs/docs/protocol-specs/state/index.md
@@ -83,10 +83,7 @@ To recall, the global state in Aztec is represented by a set of Merkle trees: th
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction TB
@@ -211,7 +208,6 @@ State *-- ArchiveTree : archive_tree
State *-- NoteHashTree : note_hash_tree
State *-- NullifierTree : nullifier_tree
State *-- PublicDataTree : public_data_tree
-
```
import DocCardList from '@theme/DocCardList';
diff --git a/docs/docs/protocol-specs/state/tree-implementations.md b/docs/docs/protocol-specs/state/tree-implementations.md
index b40a5557d65a..dfeded6c8242 100644
--- a/docs/docs/protocol-specs/state/tree-implementations.md
+++ b/docs/docs/protocol-specs/state/tree-implementations.md
@@ -20,7 +20,7 @@ Indexed Merkle trees, introduced [here](https://eprint.iacr.org/2021/1263.pdf),
With an Indexed Merkle tree, proving non-membership of a value `x` then requires a membership proof of the node with value lower than `x` and a next-highest value greater than `x`. The cost of this proof is proportional to the height of the tree, which can be set according to the expected number of elements to be stored in the tree. For comparison, a non-membership proof in a sparse tree requires a tree with height proportional to the size of the elements, so when working with 256-bit elements, 256 hashes are required for a proof.
-Refer to [this page](../../aztec/concepts/storage/trees/indexed_merkle_tree.mdx) for more details on how insertions, updates, and membership proofs are executed on an Indexed Merkle tree.
+Refer to [this page](../state/tree-implementations.md#indexed-merkle-trees) for more details on how insertions, updates, and membership proofs are executed on an Indexed Merkle tree.
diff --git a/docs/docs/protocol-specs/state/wonky-tree.md b/docs/docs/protocol-specs/state/wonky-tree.md
index fb7953f470d8..093e7334e5ee 100644
--- a/docs/docs/protocol-specs/state/wonky-tree.md
+++ b/docs/docs/protocol-specs/state/wonky-tree.md
@@ -4,10 +4,7 @@ A 'wonky' tree is an append-only unbalanced merkle tree, filled from left to rig
For example, using a balanced merkle tree to rollup 5 transactions requires padding of 3 empty transactions:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
R_c[Root]
@@ -62,10 +59,7 @@ Where each node marked with `*` indicates a circuit proving entirely empty infor
Our wonky tree implementation instead gives the below structure for 5 transactions:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
R_c[Root]
@@ -106,10 +100,7 @@ graph BT
Here, each circuit is proving useful transaction information with no wasted compute. We can construct a tree like this one for any number of transactions by greedy filling from left to right. Given the required 5 base circuits:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph
B0_c[Base 0]
B1_c[Base 1]
@@ -120,10 +111,7 @@ graph
...we theh pair these base circuits up to form merges:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
M0_c[Merge 0]
M1_c[Merge 1]
@@ -142,10 +130,7 @@ graph BT
Since we have an odd number of transactions, we cannot pair up the final base. Instead, we continue to pair the next layers until we reach a layer with an odd number of members. In this example, that's when we reach merge 2:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
M0_c[Merge 0]
M1_c[Merge 1]
@@ -168,10 +153,7 @@ graph BT
Once paired, the base layer has length 4, the next merge layer has 2, and the final merge layer has 1. After reaching a layer with odd length, the orchestrator can now pair base 4:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
R_c[Root]
@@ -230,10 +212,7 @@ Subtrees: [16, 8, 4, 2, 1] ->
An unrolled recursive algorithm is not the easiest thing to read. This diagram represents the 31 transactions rolled up in our wonky structure, where each `Merge ` is a 'subroot' above:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
graph BT
M2_c[Merge 2]
M3_c[Merge D
@@ -327,10 +306,7 @@ Here is a step-by-step example to construct the _`block_logs_data`_:
1. A rollup, _R01_, merges two transactions: _tx0_ containing _tx_logs_data_0_, and _tx1_ containing _tx_logs_data_1_:
- ```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+ ```mermaid
flowchart BT
tx0((tx0))
tx1((tx1))
@@ -345,10 +321,7 @@ import { Mermaid } from '@docusaurus/theme-mermaid';
2. Another rollup, _R23_, merges two transactions: _tx3_ containing _tx_logs_data_3_, and _tx2_ without any logs:
- ```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+ ```mermaid
flowchart BT
tx2((tx2))
tx3((tx3))
@@ -363,10 +336,7 @@ import { Mermaid } from '@docusaurus/theme-mermaid';
3. A rollup, _RA_, merges the two rollups _R01_ and _R23_:
- ```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+ ```mermaid
flowchart BT
tx0((tx0))
tx1((tx1))
@@ -389,10 +359,7 @@ import { Mermaid } from '@docusaurus/theme-mermaid';
4. A rollup, _RB_, merges the above rollup _RA_ and another rollup _R45_:
- ```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+ ```mermaid
flowchart BT
tx0((tx0))
tx1((tx1))
diff --git a/docs/docs/reference/index.md b/docs/docs/reference/index.md
deleted file mode 100644
index 2b725e63ad98..000000000000
--- a/docs/docs/reference/index.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: References
-sidebar_position: 0
----
-
-# References
-
-Welcome to the References section! In this section you will find reference material for developing on Aztec Protocol.
-
-This page lists popular references. Please see the sidebar for them all.
-
-
-## Popular
-
-### Smart contracts
-
-
Instance 0"] + Registry --> RollupContract1["Rollup Contract
Instance 1"] + Registry --> |Returns latest instance|RollupContractN["Rollup Contract
Instance n"] +``` +In practice, the Registry is an array of rollup instances that can only be inserted into by the Registryʼs owner - the Governance contract. + +```solidity +contract Registry is IRegistry, Ownable { + struct Instance { + address rollup; + uint96 blockNumber; + } + + Instance[] public instances; + + constructor(address _gov) Ownable(_gov) { + instances.push( + Instance({address: address(0), blockNumber: block.number}) + ); + } + + function addInstance(address _rollup) external onlyOwner { + instances.push( + Instance({address: _rollup, blockNumber: block.number}) + ); + } + + function getRollup() external view returns (address) { + return instances[instances.length - 1].rollup; + } + + function getInstancesLength() external view returns (uint256) { + return instances.length; + } +} +``` + +## Reward Distribution Contract + +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. + +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 + Issuer -->|1. Calls mint| HypotheticalAsset + Issuer -->|2. Transfer Hypothetical Asset| RewardDistribution + RollupContract -->|3. Calls claim| RewardDistribution +``` + +```solidity +contract RewardDistribution is Ownable { + uint256 public constant BLOCK_REWARD = xxx; + + IERC20 public immutable ASSET; + IRegistry public registry; + + // constructor etc + + function claim(address _to) external returns (uint256) { + address canonical = registry.getRollup(); + require(msg.sender == canonical); + ASSET.safeTransfer(_to, BLOCK_REWARD); + return BLOCK_REWARD; + } + + function updateRegistry(IRegistry _registry) external onlyOwner { + // ... + } +} +``` + +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 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. + +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 + +This is the only smart contract that is able to submit proposals to the Governance contract. + +The Proposals Contract will accept proposals only from sequencers of the current canonical instance, as indicated by the Registry. + +```solidity +contract Proposals is IProposals { + + // ... imports + + IGovernance public immutable GOVERNANCE; + IRegistry public immutable REGISTRY; + uint256 public immutable N; + uint256 public immutable M; + + constructor(IGovernance _governane, IRegistry _registry, uint256 _n, uint256 _m) { + // ... + + require(N > M / 2); + require(N <= M); + } + + function vote(address _proposal) external override(IProposals) returns (bool) { + require(_proposal.code.length > 0); + // ... + + Rollup instance = Rollup(REGISTRY.getRollup()); + address proposer = instance.getCurrentProposer(); + require(msg.sender == proposer); + } + // ... +} +``` +To vote to table a proposal, the current sequencer of the canonical rollup must deploy the contracts being proposed to upgrade / migrate to, to the L1. Then the current sequencer deploys the upgrade logic i.e. `_proposal`, then call `Proposals.vote(_proposal)`. + +The Proposals contract will then count votes specifying that same `_proposal`. For a proposal to be nominated for voting, it must garner at least N votes in a single round, where a round is defined as a M consecutive L2 slots. Round 1 is L2 slots 0 - M - 1, while Round 2 is L2 slots M - 2M - 1 and so on. + +Note that a sequencer’s ability to vote is not affected by the rollupʼs availability since voting happens on the L1. + +```mermaid +flowchart TD + Issuer[Issuer] -->|1. Calls mint| HypotheticalAsset[Hypothetical Asset] + Issuer -->|2. Transfer Hypothetical Asset| RewardDistribution[Reward Distribution] + RewardDistribution -->|3. Calls claim| RollupContract[RollupContract] +``` + +If the quorum has been reahed, anyone can call `pushProposal(uint256 _roundNumber)` on the Proposals contract to send the proposal to the Governance contract for voting. As a result, only one proposal can be nominated for voting at any given round. + +## 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 decides what is the canonical instance which gets block rewards. + +The Proposals contract tables proposals for voting, Holders who lock their Hypothetical Assets with the Governance contract may vote once for each Hypothetical Asset locked. They can vote either Yea or Nea. + +Once a proposal garners the minimum number of votes, and the Yay votes exceed Nay by at least the `quorum%` , the proposal can be executed by the Governance contract. + +```solidity +contract Governance is IGovernance { // ... imports + IERC20 public immutable ASSET; address public proposalsContract; // ... + constructor(IERC20 _asset, address _proposalsContract, ui nt256 _votingDelay, uint256 _votingDuration, uint256 _gracePeriod, uint256 _quorum, uin t256 _voteDifferential, uint256 _minimumVotes) { // ... + configuration = DataStructures.Configuration({ votingDelay: Timestamp.wrap(_votingDelay), // Min time between proposal creation and when voting starts votingDuration: Timestamp.wrap(_votingDuration), // Max duration of voting period + executionDelay: Timestamp.wrap(_executionDelay), // Min time between voting passing and proposal execution gracePeriod: Timestamp.wrap(_gracePeriod), // max time between proposal creation and proposal execution. + quorum: _quorum, // % of deposited ASSET that mus t participate in a vote (could be Yes or No) voteDifferential: _voteDifferential, // Yea must outweight Nea by this % to pass vote minimumVotes: _minimumVotes, // users with this much cummulative deposited ASSET must participate in the vote }) + } +// ... +function deposit(address _onBehalfOf, uint256 _amount) external override(IGovernance) { + // deposits are allowed on behalf of other addresses + users[_onBehalfOf].add(_amount); + // ... +} + +function initiateWithdraw(address _to, uint256 _amount) external override(IGovernance) returns (uint256) { + // ... + // No one can withdraw on behalf of someone else + users[msg.sender].sub(_amount); + // ... +} + +function propose(address _payload) external override(IGovernance) returns (bool) { + require(msg.sender == proposalsContract); + // ... +} + +function vote(uint256 _proposalId, uint256 _amount, bool _support) external override(IGovernance) returns (bool) {} + +function execute(uint256 _proposalId) external override(IGovernance) returns (bool) { + // execute proposal via `call()` +} +``` diff --git a/docs/docs/run_node/concepts/governance/_category_.json b/docs/docs/run_node/concepts/governance/_category_.json new file mode 100644 index 000000000000..69efe5a14964 --- /dev/null +++ b/docs/docs/run_node/concepts/governance/_category_.json @@ -0,0 +1,6 @@ +{ + "position": 1, + "collapsible": true, + "collapsed": true, + "label": "Governance" +} diff --git a/docs/docs/run_node/concepts/governance/governance.md b/docs/docs/run_node/concepts/governance/governance.md new file mode 100644 index 000000000000..7669574ddd49 --- /dev/null +++ b/docs/docs/run_node/concepts/governance/governance.md @@ -0,0 +1,17 @@ +--- +id: governance +sidebar_position: 3 +title: Governance Overview +--- + +import Image from "@theme/IdealImage"; + +This diagram outlines how governance works on Aztec: + + {
+ // Add quote to quote memory pool
+ this.epochProofQuotePool.addQuote(quote);
+
+ // Propagate quote via P2P
+ this.broadcastEpochProofQuote(quote);
+ }
+}
+```
+
+This is called by the Prover Node inside `ProverNode.sendEpochProofQuote()` after it detects an epoch has ended.
+
+## Prover Node
+
+As for the Prover Node, we add `QuoteProvider` and `BondManager` interfaces. Also an `EpochMonitor` which sits on the main start loop of the Prover Node. It fetches the most recent completed epochs and checks whether the proposer accepted an `EpochProofQuote`.
+
+If no quote has been accepted yet, the `EpochMonitor` will call on `BondManager` and `QuoteProvider` to provide a valid quote. If the claim detected belongs to the prover, the monitor will kick off a `handleCall()` to create proving jobs.
+
+```typescript
+interface BondManager {
+ ensureBond(amount: number): Promise;
+}
+interface QuoteProvider {
+ getQuote(epoch: number): Promise;
+}
+```
+
+When the prover node first starts up, it will call `BondManager.ensureBond` to ensure it has the minimum deposit amount `PROVER_MINIMUM_ESCROW_AMOUNT` deposited in the escrow contract. If it does not, it will top up to the target deposit amount `PROVER_TARGET_ESCROW_AMOUNT`.
+
+Both `PROVER_MINIMUM_ESCROW_AMOUNT` and `PROVER_TARGET_ESCROW_AMOUNT` are customizable environment variables.
+
+The `EpochMonitor` will then get the last completed, unproven epoch and will call the `QuoteProvider` to generate a quote if the epoch has not been claimed by any provers yet. The `QuoteProvider` will be provided with all the blocks in the unproven epoch so it could perform any custom logic to determine the quote parameters, i.e., `bondAmount`, `basisPointFee`, etc.
+
+Alternatively, the quote provider can issue an HTTP POST to a configurable `QUOTE_PROVIDER_URL` to get the quote. The request body is JSON-encoded and contains the following fields:
+
+- `epochNumber`: The epoch number to prove
+- `fromBlock`: The first block number of the epoch to prove
+- `endBlock`: The last block number (inclusive) of the epoch to prove
+- `txCount`: The total number of txs in the epoch
+- `totalFees`: The accumulated total fees across all txs in the epoch
+
+The response is also expected in JSON and to contain `basisPointFee` and `bondAmount` fields. Optionally, the request can include a `validUntilSlot` parameter, which specifies for how many slots the quote remains valid. For example, an `EpochProofQuote` with parameters `epochProofQuote#80` and `validUntilSlot#5` means that any of the first 5 proposers in epoch 101 can “claim” this quote.
+
+If no `QUOTE_PROVIDER_URL` is passed along to the Prover Node, then a `SimpleQuoteProvider` is used, which always returns the same `basisPointFee` and `bondAmount` as set in the `QUOTE_PROVIDER_BASIS_POINT_FEE` and `QUOTE_PROVIDER_BOND_AMOUNT` environment variables.
+
+:::warning
+If the `QuoteProvider` does not return a `bondAmount` or a `basisPointFee`, the Prover Node will not generate nor submit a quote to the proposer.
+:::
+
+Separately, the Prover Node needs a watcher on L1 to detect if its quote has been selected.
+
+To this end, the `L1Publisher` will be extended with a new method to retrieve proof claims.
+
+```typescript
+interface L1Publisher {
+ getProofClaim(): Promise;
+}
+```
+
+The Prover Node will call this method at least once per L2 slot to check for unclaimed accepted quotes if its quotes have been accepted. You can update the polling interval using the environment variable `PROVER_NODE_POLLING_INTERVAL_MS`.
+
+## 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
diff --git a/docs/docs/run_node/guides/_category_.json b/docs/docs/run_node/guides/_category_.json
new file mode 100644
index 000000000000..5dc689496822
--- /dev/null
+++ b/docs/docs/run_node/guides/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 2,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Guides"
+}
diff --git a/docs/docs/run_node/guides/connecting_to_node.md b/docs/docs/run_node/guides/connecting_to_node.md
new file mode 100644
index 000000000000..32ccbcb2bfe4
--- /dev/null
+++ b/docs/docs/run_node/guides/connecting_to_node.md
@@ -0,0 +1,5 @@
+---
+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
new file mode 100644
index 000000000000..4b45fbd9e474
--- /dev/null
+++ b/docs/docs/run_node/guides/node_reference.md
@@ -0,0 +1,5 @@
+---
+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
new file mode 100644
index 000000000000..293922e4c0b3
--- /dev/null
+++ b/docs/docs/run_node/guides/reacting_to_upgrades.md
@@ -0,0 +1,36 @@
+---
+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/_category_.json b/docs/docs/run_node/guides/run_nodes/_category_.json
new file mode 100644
index 000000000000..bab7be349b11
--- /dev/null
+++ b/docs/docs/run_node/guides/run_nodes/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 2,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Running nodes"
+}
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
new file mode 100644
index 000000000000..27e44517a3c2
--- /dev/null
+++ b/docs/docs/run_node/guides/run_nodes/how_to_run_prover.md
@@ -0,0 +1,8 @@
+---
+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
new file mode 100644
index 000000000000..8c1ea44feac5
--- /dev/null
+++ b/docs/docs/run_node/guides/run_nodes/how_to_run_prover_draft.md
@@ -0,0 +1,96 @@
+---
+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_HOST**: URL to an Ethereum node.
+- **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.
+- **PROVER_AGENT_CONCURRENCY**: Maximum concurrency for this given prover agent. Defaults to `1`.
+
+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
new file mode 100644
index 000000000000..ff82314a085b
--- /dev/null
+++ b/docs/docs/run_node/guides/run_nodes/how_to_run_sequencer_draft.md
@@ -0,0 +1,159 @@
+---
+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_HOST | URL to the Ethereum node your validator will connect to. 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_HOST| This is the URL to the L1 node 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 |
+| SEQ_MIN_SECONDS_BETWEEN_BLOCKS | If greater than zero, the sequencer will not propose a block until this much time has passed since the last L2 block was published to L1 |
+| SEQ_MAX_SECONDS_BETWEEN_BLOCKS | Sequencer will ignore the minTxPerBlock if this many seconds have passed since the last L2 block.|
+| 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_TCP_ANNOUNCE_ADDR | Format: `:`|
+|P2P_UDP_ANNOUNCE_ADDR |Format: `:`|
+| P2P_TCP_LISTEN_ADDR | Format: `:` or can use `0.0.0.0:` to listen on all interfaces|
+| 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. 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_MIN_PEERS | The min number of peers to connect to. |
+| 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.
\ No newline at end of file
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
new file mode 100644
index 000000000000..d87d530f9c1c
--- /dev/null
+++ b/docs/docs/run_node/guides/run_nodes/how_to_run_validator_sequencer.md
@@ -0,0 +1,10 @@
+---
+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
new file mode 100644
index 000000000000..9d4630ebc616
--- /dev/null
+++ b/docs/docs/run_node/guides/run_nodes/index.md
@@ -0,0 +1,26 @@
+---
+id: index
+sidebar_position: 0
+title: Run a Node, Sequencer, or Prover
+---
+
+## Running Aztec Nodes
+
+
Aztec Overview
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction LR
class ParentClass {
@@ -323,7 +320,6 @@ class D {
ParentClass *-- ChildClass: Composition.
A .. B: Perform a consistency check on values in these classes.
C ..> D: Copy the data from the inputs A to the outputs B\n(possibly with some modification along the way).
-
```
@@ -339,10 +335,7 @@ The diagram:
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
+```mermaid
classDiagram
direction TB
@@ -701,7 +694,7 @@ class PublicInputs {
}
ConstantData --* PublicInputs : constant_data
TransientAccumulatedData --* PublicInputs: transient_accumulated_data
-
+
```
diff --git a/docs/docs/protocol-specs/circuits/private-kernel-inner.mdx b/docs/docs/protocol-specs/circuits/private-kernel-inner.mdx
index 10546522b34b..78d97022a67e 100644
--- a/docs/docs/protocol-specs/circuits/private-kernel-inner.mdx
+++ b/docs/docs/protocol-specs/circuits/private-kernel-inner.mdx
@@ -130,10 +130,7 @@ NOTE TO ANYONE EDITING THIS DIAGRAM:
To save repeating yourself, you only need to edit the END of this diagram (demarcated clearly, further down the page - you'll see it). COPY-PASTE the beginning of this diagram (up to the demarcation) from ../private-kernel-initial.
-->
-```mdx
-import { Mermaid } from '@docusaurus/theme-mermaid';
-
-
-
-
-
-
-
- A detailed reference for storage types
-
-
-
-
-
-
-
- A detailed reference for working with portals and L1/L2 communication
-
-
-
-
-
-### Others
-
-Storage
-Portals
-
-
-
-
-
-
- Help debug your sandbox environment
-
-
-
-
-
-
-
- A full list of commands for working with the Aztec CLI
-
-
-
-
-
diff --git a/docs/docs/run_node/concepts/_category_.json b/docs/docs/run_node/concepts/_category_.json
new file mode 100644
index 000000000000..19d79cf9e982
--- /dev/null
+++ b/docs/docs/run_node/concepts/_category_.json
@@ -0,0 +1,6 @@
+{
+ "position": 1,
+ "collapsible": true,
+ "collapsed": true,
+ "label": "Decentralization Concepts"
+}
diff --git a/docs/docs/guides/developer_guides/running_nodes/_category_.json b/docs/docs/run_node/concepts/deployments/_category_.json
similarity index 51%
rename from docs/docs/guides/developer_guides/running_nodes/_category_.json
rename to docs/docs/run_node/concepts/deployments/_category_.json
index 88c8b42bc8f4..03142f5a9e87 100644
--- a/docs/docs/guides/developer_guides/running_nodes/_category_.json
+++ b/docs/docs/run_node/concepts/deployments/_category_.json
@@ -1,6 +1,6 @@
{
- "position": 5,
+ "position": 2,
"collapsible": true,
"collapsed": true,
- "label": "Aztec Protocol"
+ "label": "Deployments"
}
diff --git a/docs/docs/run_node/concepts/deployments/what_is_deployment.md b/docs/docs/run_node/concepts/deployments/what_is_deployment.md
new file mode 100644
index 000000000000..cd691a0036a4
--- /dev/null
+++ b/docs/docs/run_node/concepts/deployments/what_is_deployment.md
@@ -0,0 +1,244 @@
+---
+sidebar_position: 0
+title: What is a Deployment?
+---
+
+An Aztec deployment is a set of the following contracts:
+
+| Smart Contract | Immutability |
+|--------------------------------|--------------|
+| Hypothetical Asset | Immutable |
+| Issuer Contract | Immutable |
+| Registry Contract | Immutable |
+| Reward Distribution Contract | Mutable |
+| Proposals Contract | Mutable |
+| Governance Contract | Immutable |
+| Rollup Contract | Immutable |
+
+## Hypothetical Asset Contract
+
+Hypothetical Asset would live on Ethereum L1. It may have a minter which would be the only actor capable of calling the `mint` function on the Hypothetical Asset contract.
+
+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.
+- **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.
+
+## Issuer Contract
+
+This contract will be the sole minter of Hypothetical Asset. It will itself have an owner, which is the only actor capable of calling the `mint` function on the Hypothetical Asset ERC20 contract.
+
+The `mint` function will limit the amount of Hypothetical Assets that could be minted in a given time period. The reasoning behind this limit is that it makes supply expansions more predictable since "infinite mints" cannot be made.
+
+```mermaid
+flowchart LR
+ Issuer -->|Calls mint| HypotheticalAsset
+```
+
+```solidity
+contract Issuer is Ownable {
+ ERC20 immutable public ASSET; // Hypothetical Asset
+ uint256 immutable public RATE;
+ uint256 public timeOfLastMint;
+
+ constructor(ERC20 _asset, uint256 _rate, address _owner) Ownable(_owner) {
+ ASSET = _asset;
+ RATE = _rate;
+ timeOfLastMint = block.timestamp;
+ }
+
+ function mint(address _to, uint256 _amount) external onlyOwner {
+ uint256 maxMint = RATE * (block.timestamp - timeOfLastMint);
+ require(_amount <= maxMint, 'Insufficient mint available');
+
+ timeOfLastMint = block.timestamp;
+ ASSET.mint(_to, _amount);
+ }
+}
+```
+
+## 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.
+
+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.
+
+```mermaid
+flowchart LR
+ Registry --> RollupContract0["Rollup ContractCommon Sandbox Errors
-CLI reference
-Instance 0"] + Registry --> RollupContract1["Rollup Contract
Instance 1"] + Registry --> |Returns latest instance|RollupContractN["Rollup Contract
Instance n"] +``` +In practice, the Registry is an array of rollup instances that can only be inserted into by the Registryʼs owner - the Governance contract. + +```solidity +contract Registry is IRegistry, Ownable { + struct Instance { + address rollup; + uint96 blockNumber; + } + + Instance[] public instances; + + constructor(address _gov) Ownable(_gov) { + instances.push( + Instance({address: address(0), blockNumber: block.number}) + ); + } + + function addInstance(address _rollup) external onlyOwner { + instances.push( + Instance({address: _rollup, blockNumber: block.number}) + ); + } + + function getRollup() external view returns (address) { + return instances[instances.length - 1].rollup; + } + + function getInstancesLength() external view returns (uint256) { + return instances.length; + } +} +``` + +## Reward Distribution Contract + +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. + +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 + Issuer -->|1. Calls mint| HypotheticalAsset + Issuer -->|2. Transfer Hypothetical Asset| RewardDistribution + RollupContract -->|3. Calls claim| RewardDistribution +``` + +```solidity +contract RewardDistribution is Ownable { + uint256 public constant BLOCK_REWARD = xxx; + + IERC20 public immutable ASSET; + IRegistry public registry; + + // constructor etc + + function claim(address _to) external returns (uint256) { + address canonical = registry.getRollup(); + require(msg.sender == canonical); + ASSET.safeTransfer(_to, BLOCK_REWARD); + return BLOCK_REWARD; + } + + function updateRegistry(IRegistry _registry) external onlyOwner { + // ... + } +} +``` + +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 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. + +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 + +This is the only smart contract that is able to submit proposals to the Governance contract. + +The Proposals Contract will accept proposals only from sequencers of the current canonical instance, as indicated by the Registry. + +```solidity +contract Proposals is IProposals { + + // ... imports + + IGovernance public immutable GOVERNANCE; + IRegistry public immutable REGISTRY; + uint256 public immutable N; + uint256 public immutable M; + + constructor(IGovernance _governane, IRegistry _registry, uint256 _n, uint256 _m) { + // ... + + require(N > M / 2); + require(N <= M); + } + + function vote(address _proposal) external override(IProposals) returns (bool) { + require(_proposal.code.length > 0); + // ... + + Rollup instance = Rollup(REGISTRY.getRollup()); + address proposer = instance.getCurrentProposer(); + require(msg.sender == proposer); + } + // ... +} +``` +To vote to table a proposal, the current sequencer of the canonical rollup must deploy the contracts being proposed to upgrade / migrate to, to the L1. Then the current sequencer deploys the upgrade logic i.e. `_proposal`, then call `Proposals.vote(_proposal)`. + +The Proposals contract will then count votes specifying that same `_proposal`. For a proposal to be nominated for voting, it must garner at least N votes in a single round, where a round is defined as a M consecutive L2 slots. Round 1 is L2 slots 0 - M - 1, while Round 2 is L2 slots M - 2M - 1 and so on. + +Note that a sequencer’s ability to vote is not affected by the rollupʼs availability since voting happens on the L1. + +```mermaid +flowchart TD + Issuer[Issuer] -->|1. Calls mint| HypotheticalAsset[Hypothetical Asset] + Issuer -->|2. Transfer Hypothetical Asset| RewardDistribution[Reward Distribution] + RewardDistribution -->|3. Calls claim| RollupContract[RollupContract] +``` + +If the quorum has been reahed, anyone can call `pushProposal(uint256 _roundNumber)` on the Proposals contract to send the proposal to the Governance contract for voting. As a result, only one proposal can be nominated for voting at any given round. + +## 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 decides what is the canonical instance which gets block rewards. + +The Proposals contract tables proposals for voting, Holders who lock their Hypothetical Assets with the Governance contract may vote once for each Hypothetical Asset locked. They can vote either Yea or Nea. + +Once a proposal garners the minimum number of votes, and the Yay votes exceed Nay by at least the `quorum%` , the proposal can be executed by the Governance contract. + +```solidity +contract Governance is IGovernance { // ... imports + IERC20 public immutable ASSET; address public proposalsContract; // ... + constructor(IERC20 _asset, address _proposalsContract, ui nt256 _votingDelay, uint256 _votingDuration, uint256 _gracePeriod, uint256 _quorum, uin t256 _voteDifferential, uint256 _minimumVotes) { // ... + configuration = DataStructures.Configuration({ votingDelay: Timestamp.wrap(_votingDelay), // Min time between proposal creation and when voting starts votingDuration: Timestamp.wrap(_votingDuration), // Max duration of voting period + executionDelay: Timestamp.wrap(_executionDelay), // Min time between voting passing and proposal execution gracePeriod: Timestamp.wrap(_gracePeriod), // max time between proposal creation and proposal execution. + quorum: _quorum, // % of deposited ASSET that mus t participate in a vote (could be Yes or No) voteDifferential: _voteDifferential, // Yea must outweight Nea by this % to pass vote minimumVotes: _minimumVotes, // users with this much cummulative deposited ASSET must participate in the vote }) + } +// ... +function deposit(address _onBehalfOf, uint256 _amount) external override(IGovernance) { + // deposits are allowed on behalf of other addresses + users[_onBehalfOf].add(_amount); + // ... +} + +function initiateWithdraw(address _to, uint256 _amount) external override(IGovernance) returns (uint256) { + // ... + // No one can withdraw on behalf of someone else + users[msg.sender].sub(_amount); + // ... +} + +function propose(address _payload) external override(IGovernance) returns (bool) { + require(msg.sender == proposalsContract); + // ... +} + +function vote(uint256 _proposalId, uint256 _amount, bool _support) external override(IGovernance) returns (bool) {} + +function execute(uint256 _proposalId) external override(IGovernance) returns (bool) { + // execute proposal via `call()` +} +``` diff --git a/docs/docs/run_node/concepts/governance/_category_.json b/docs/docs/run_node/concepts/governance/_category_.json new file mode 100644 index 000000000000..69efe5a14964 --- /dev/null +++ b/docs/docs/run_node/concepts/governance/_category_.json @@ -0,0 +1,6 @@ +{ + "position": 1, + "collapsible": true, + "collapsed": true, + "label": "Governance" +} diff --git a/docs/docs/run_node/concepts/governance/governance.md b/docs/docs/run_node/concepts/governance/governance.md new file mode 100644 index 000000000000..7669574ddd49 --- /dev/null +++ b/docs/docs/run_node/concepts/governance/governance.md @@ -0,0 +1,17 @@ +--- +id: governance +sidebar_position: 3 +title: Governance Overview +--- + +import Image from "@theme/IdealImage"; + +This diagram outlines how governance works on Aztec: + +
+
+
+
+
+ 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.
+
+
+
+
+
+
+ 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/index.md b/docs/docs/run_node/index.md
new file mode 100644
index 000000000000..29fdc991272d
--- /dev/null
+++ b/docs/docs/run_node/index.md
@@ -0,0 +1,51 @@
+---
+id: index
+sidebar_position: 0
+title: Run a node
+---
+
+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.
+
+## Learn about governance on Aztec
+
+Run Aztec Validator Nodes
+Run Aztec Prover Nodes
+
+
+
+
+
+ An introduction to Aztec's governance model
+
+
+
+
+## Decentralization Components
+
+Governance
+
+
+
+
+
+ How sequencers propose and produce blocks
+
+
+
+
+## Run a node
+
+Sequencers
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js
index 20918552819f..7399dda10064 100644
--- a/docs/docusaurus.config.js
+++ b/docs/docusaurus.config.js
@@ -134,7 +134,7 @@ const config = {
entryPoints: ["../yarn-project/circuit-types/src/interfaces/pxe.ts"],
tsconfig: "../yarn-project/circuit-types/tsconfig.json",
entryPointStrategy: "expand",
- out: "reference/developer_references/aztecjs/pxe",
+ out: "developers/reference/aztecjs/pxe",
readme: "none",
sidebar: {
categoryLabel: "Private Execution Environment (PXE)",
@@ -152,7 +152,7 @@ const config = {
],
tsconfig: "../yarn-project/aztec.js/tsconfig.json",
entryPointStrategy: "resolve",
- out: "reference/developer_references/aztecjs/aztec-js",
+ out: "developers/reference/aztecjs/aztec-js",
readme: "none",
sidebar: {
categoryLabel: "Aztec.js",
@@ -173,7 +173,7 @@ const config = {
],
tsconfig: "../yarn-project/accounts/tsconfig.json",
entryPointStrategy: "resolve",
- out: "reference/developer_references/aztecjs/accounts",
+ out: "developers/reference/aztecjs/accounts",
readme: "none",
sidebar: {
categoryLabel: "Accounts",
@@ -208,19 +208,12 @@ const config = {
],
apiKey: "gpH8o2YnqsOEj2jgtIMTULbtHi1kZ2X3", // public search-only api key, safe to commit
},
- contextualSearch: true,
},
colorMode: {
defaultMode: "light",
disableSwitch: false,
respectPrefersColorScheme: false,
},
- // docs: {
- // sidebar: {
- // hideable: true,
- // autoCollapseCategories: false,
- // },
- // },
navbar: {
logo: {
alt: "Aztec Logo",
@@ -231,26 +224,32 @@ const config = {
items: [
{
type: "doc",
- docId: "index",
+ docId: "aztec/index",
position: "left",
label: "Learn",
},
+
{
type: "docSidebar",
- sidebarId: "guidesSidebar",
+ sidebarId: "buildSidebar",
position: "left",
- label: "Guides",
+ label: "Build",
},
{
type: "docSidebar",
- sidebarId: "referenceSidebar",
+ sidebarId: "nodesSidebar",
position: "left",
- label: "Reference",
+ label: "Run a node",
+ },
+ {
+ to: "/developers/getting_started",
+ label: "Install Sandbox",
+ position: "right",
},
{
type: "dropdown",
label: "Resources",
- position: "left",
+ position: "right",
items: [
{
type: "html",
@@ -353,7 +352,7 @@ const config = {
},
{
label: "Developer Getting Started Guide",
- to: "/guides/getting_started",
+ to: "/developers/getting_started",
},
{
label: "Aztec.nr",
diff --git a/docs/internal_notes/dev_docs/sandbox/components.md b/docs/internal_notes/dev_docs/sandbox/components.md
index fb8e6bfa1162..f9d407faf88d 100644
--- a/docs/internal_notes/dev_docs/sandbox/components.md
+++ b/docs/internal_notes/dev_docs/sandbox/components.md
@@ -137,7 +137,6 @@ Implementation notes for this milestone:
- Can be used as both the spending and decryption key for early development.
### Private Execution Environment (PXE)
-
Implements:
diff --git a/docs/netlify.toml b/docs/netlify.toml
index 3a0097de71b6..5dba9ffe4bba 100644
--- a/docs/netlify.toml
+++ b/docs/netlify.toml
@@ -1,22 +1,26 @@
[[redirects]]
from = "/guides/smart_contracts/writing_contracts/initializers"
- to = "/guides/developer_guides/smart_contracts/writing_contracts/initializers"
+ to = "/developers/guides/smart_contracts/writing_contracts/initializers"
[[redirects]]
from = "/reference/aztecjs/accounts"
- to = "/reference/developer_references/aztecjs/accounts"
+ to = "/developers/reference/aztecjs/accounts"
[[redirects]]
from = "/getting_started"
- to = "/guides/getting_started"
+ to = "/developers/getting_started"
[[redirects]]
- from = "/tutorials/simple_dapp/*"
- to = "/tutorials/codealong/simple_dapp"
+ from = "/developers/getting_started/main"
+ to = "/developers/getting_started"
+
+[[redirects]]
+ from = "guides/getting_started"
+ to = "/developers/getting_started"
[[redirects]]
- from = "/tutorials/simple_dapp"
- to = "/tutorials/codealong/simple_dapp"
+ from = "/tutorials/simple_dapp/*"
+ to = "developers/tutorials/codealong/js_tutorials/simple_dapp"
[[redirects]]
from = "/tutorials/contract_tutorials//token_bridge/typescript_glue_code"
@@ -64,7 +68,7 @@
[[redirects]]
from = "/developers/sandbox/*"
- to = "/guides/getting_started"
+ to = "/developers/getting_started"
[[redirects]]
from = "/developers/contracts/*"
@@ -72,7 +76,7 @@
[[redirects]]
from = "/dev_docs/*"
- to = "/guides/getting_started"
+ to = "/developers/getting_started"
[[redirects]]
from = "/aztec/cryptography/cryptography-roadmap"
@@ -136,16 +140,60 @@
[[redirects]]
from = "/reference/sandbox_reference/sandbox-reference"
- to = "/guides/getting_started"
+ to = "/developers/getting_started"
[[redirects]]
from = "/reference/sandbox_reference"
- to = "/guides/getting_started"
+ to = "/developers/getting_started"
+
+[[redirects]]
+ from = "/guides/getting_started/*"
+ to = "/developers/getting_started/*"
+
+[[redirects]]
+ from = "/guides/developer_guides/getting_started/quickstart"
+ to = "/developers/getting_started"
+
+[[redirects]]
+ from = "/aztec/concepts_overview"
+ to = "/aztec"
+
+[[redirects]]
+ from = "/aztec/concepts/accounts/authwit"
+ to = "/aztec/concepts/advanced/authwit"
+
+[[redirects]]
+ from = "/aztec/concepts/storage/storage_slots"
+ to = "/aztec/concepts/advanced/storage/storage_slots"
+
+[[redirects]]
+ from = "/aztec/concepts/storage/trees/*"
+ to = "/aztec/concepts/advanced/storage/indexed_merkle_tree"
+
+[[redirects]]
+ from = "/aztec/concepts/storage/partial_notes"
+ to = "/aztec/concepts/advanced/storage/partial_notes"
+
+[[redirects]]
+ from = "/aztec/concepts/circuits/*"
+ to = "/aztec/concepts/advanced/circuits"
+
+[[redirects]]
+ from = "/tutorials/*"
+ to = "/developers/tutorials/*"
+
+[[redirects]]
+ from = "/guides/*"
+ to = "/developers/guides/*"
+
+[[redirects]]
+ from = "/reference/*"
+ to = "/developers/reference/*"
[[redirects]]
- from = "/guides/getting_started/quickstart"
- to = "/guides/getting_started"
+ from = "/guides/privacy_considerations"
+ to = "/developers/reference/considerations/privacy_considerations"
[[redirects]]
-from = "/guides/developer_guides/getting_started/quickstart"
-to = "/guides/developer_guides/getting_started"
\ No newline at end of file
+ from = "/reference/developer_references/limitations"
+ to = "/developers/reference/considerations/limitations"
\ No newline at end of file
diff --git a/docs/package.json b/docs/package.json
index 0e9563dbfcec..98bd39e0a2fa 100644
--- a/docs/package.json
+++ b/docs/package.json
@@ -73,4 +73,4 @@
]
},
"packageManager": "yarn@4.5.2"
-}
+}
\ No newline at end of file
diff --git a/docs/scripts/clean.sh b/docs/scripts/clean.sh
index 8d27b2091b40..ce1fe639f84d 100755
--- a/docs/scripts/clean.sh
+++ b/docs/scripts/clean.sh
@@ -1,5 +1,5 @@
#!/usr/bin/env bash
rm -rf 'processed-docs' 'processed-docs-cache'
-rm -rf 'docs/reference/developer_references/aztecjs' 'docs/reference/developer_references/smart_contract_reference/aztec-nr'
+rm -rf 'docs/developers/reference/aztecjs' 'docs/developers/reference/smart_contract_reference/aztec-nr'
docusaurus clear
diff --git a/docs/scripts/move_processed.sh b/docs/scripts/move_processed.sh
index b841f2e5eb16..23d40065bedb 100755
--- a/docs/scripts/move_processed.sh
+++ b/docs/scripts/move_processed.sh
@@ -1,4 +1,4 @@
#!/usr/bin/env bash
-echo "label: \"AztecJS\"" > ./docs/reference/developer_references/aztecjs/_category_.yml
-mv ./docs/reference/developer_references/aztecjs ./processed-docs/reference/developer_references/aztecjs
-mv ./docs/reference/developer_references/smart_contract_reference/aztec-nr ./processed-docs/reference/developer_references/smart_contract_reference/aztec-nr
+echo "label: \"AztecJS\"" > ./docs/developers/reference/aztecjs/_category_.yml
+mv ./docs/developers/reference/aztecjs ./processed-docs/developers/reference/aztecjs
+mv ./docs/developers/reference/smart_contract_reference/aztec-nr ./processed-docs/developers/reference/smart_contract_reference/aztec-nr
diff --git a/docs/sidebars.js b/docs/sidebars.js
index ae40d1e6a513..7079d2566654 100644
--- a/docs/sidebars.js
+++ b/docs/sidebars.js
@@ -6,36 +6,16 @@ const path = require("path");
/** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */
export default {
sidebar: [
- {
- type: "html",
- value: '',
- className: "sidebar-title",
- },
{
type: "doc",
- id: "aztec/concepts_overview",
- label: "Concepts Overview",
+ id: "aztec/index",
+ label: "Aztec Overview",
},
{
type: "category",
label: "Concepts",
items: [{ type: "autogenerated", dirName: "aztec/concepts" }],
},
- {
- type: "html",
- value: '',
- className: "sidebar-title",
- },
- {
- type: "doc",
- id: "aztec/network_overview",
- label: "Network Overview",
- },
- {
- type: "category",
- label: "Network Infrastructure",
- items: [{ type: "autogenerated", dirName: "aztec/network" }],
- },
{
type: "html",
value: '',
@@ -62,15 +42,19 @@ export default {
{
type: "doc",
label: "Building in Public",
- id: "aztec",
+ id: "building_in_public",
+ },
+ {
+ type: "doc",
+ id: "aztec_connect_sunset",
},
],
- guidesSidebar: [
+ buildSidebar: [
{
type: "doc",
- id: "guides/index",
- label: "Guides and Tutorials",
+ id: "developers/index",
+ label: "Build",
},
{
type: "html",
@@ -80,7 +64,12 @@ export default {
{
type: "doc",
label: "Quickstart",
- id: "guides/getting_started"
+ id: "developers/getting_started"
+ },
+ {
+ type: "link",
+ label: "Aztec Starter GitHub repo",
+ href: "https://github.com/AztecProtocol/aztec-starter",
},
{
type: "html",
@@ -93,16 +82,20 @@ export default {
},
{
type: "autogenerated",
- dirName: "tutorials/codealong",
+ dirName: "developers/tutorials/codealong",
+ },
+ {
+ type: "html",
+ value: '',
},
{
type: "html",
- value: '',
+ value: '',
className: "sidebar-title",
},
{
type: "autogenerated",
- dirName: "tutorials/examples",
+ dirName: "developers/guides"
},
{
type: "html",
@@ -110,65 +103,59 @@ export default {
},
{
type: "html",
- value: '',
+ value: '',
className: "sidebar-title",
},
{
type: "autogenerated",
- dirName: "guides/developer_guides"
+ dirName: "developers/reference",
},
{
type: "html",
value: '',
},
- ],
-
- referenceSidebar: [
{
type: "doc",
- label: "References",
- id: "reference/index",
+ id: "migration_notes",
},
+ ],
+
+ roadmapSidebar: [
{
- type: "html",
- value: '',
- className: "sidebar-title",
+ type: "autogenerated",
+ dirName: "aztec/roadmap",
},
+ ],
+
+ nodesSidebar: [
+
{
- type: "autogenerated",
- dirName: "reference/developer_references",
+ type: "doc",
+ id: "run_node/index",
},
{
type: "html",
- value: '',
+ value: '',
className: "sidebar-title",
},
{
- type: "doc",
- id: "migration_notes",
- },
- {
- type: "doc",
- label: "Privacy Considerations",
- id: "guides/privacy_considerations"
+ type: "autogenerated",
+ dirName: "run_node/concepts",
},
{
type: "html",
value: '',
},
{
- type: "doc",
- id: "aztec_connect_sunset",
+ type: "html",
+ value: '',
+ className: "sidebar-title",
},
- ],
-
- roadmapSidebar: [
{
type: "autogenerated",
- dirName: "aztec/roadmap",
+ dirName: "run_node/guides",
},
],
-
...(process.env.SHOW_PROTOCOL_SPECS ? {
protocolSpecSidebar: [
"protocol-specs/intro",
diff --git a/docs/src/components/Disclaimers/_wip_disclaimer.mdx b/docs/src/components/Disclaimers/_wip_disclaimer.mdx
index 61f31593ea50..131eec88d592 100644
--- a/docs/src/components/Disclaimers/_wip_disclaimer.mdx
+++ b/docs/src/components/Disclaimers/_wip_disclaimer.mdx
@@ -5,7 +5,7 @@
:::caution Disclaimer
We are building Aztec as transparently as we can. The documents published here are living documents. The protocol, sandbox, language, and tools are all subject to change over time.
-Please see [here](/reference/developer_references/limitations) for details of known Aztec protocol and Aztec Sandbox limitations.
+Please see [here](/developers/reference/considerations/limitations) for details of known Aztec protocol and Aztec Sandbox limitations.
If you would like to help us build Aztec:
diff --git a/docs/src/preprocess/generate_aztecnr_reference.js b/docs/src/preprocess/generate_aztecnr_reference.js
index 7d0a3396a42a..3512ec15c366 100644
--- a/docs/src/preprocess/generate_aztecnr_reference.js
+++ b/docs/src/preprocess/generate_aztecnr_reference.js
@@ -323,7 +323,7 @@ function processFiles(baseDir, outputBaseDir) {
let baseDir = path.resolve(__dirname, "../../../noir-projects/aztec-nr");
let outputBaseDir = path.resolve(
__dirname,
- "../../docs/reference/developer_references/smart_contract_reference/aztec-nr"
+ "../../docs/developers/reference/smart_contract_reference/aztec-nr"
);
console.log(outputBaseDir);
processFiles(baseDir, outputBaseDir);
diff --git a/docs/static/img/governance.png b/docs/static/img/governance.png
new file mode 100644
index 000000000000..991dee3115c4
Binary files /dev/null and b/docs/static/img/governance.png differ
diff --git a/docs/typesense.config.json b/docs/typesense.config.json
index f20205e727c0..7dccc1f3dc63 100644
--- a/docs/typesense.config.json
+++ b/docs/typesense.config.json
@@ -1,47 +1,47 @@
{
- "index_name": "aztec-docs",
- "start_urls": [
- "https://docs.aztec.network/"
- ],
- "sitemap_urls": [
- "https://docs.aztec.network/sitemap.xml"
- ],
- "sitemap_alternate_links": true,
- "selectors": {
- "lvl0": {
- "selector": "(//ul[contains(@class,'menu__list')]//a[contains(@class, 'menu__link menu__link--sublist menu__link--active')]/text() | //nav[contains(@class, 'navbar')]//a[contains(@class, 'navbar__link--active')]/text())[last()]",
- "type": "xpath",
- "global": true,
- "default_value": "Documentation"
- },
- "lvl1": "header h1",
- "lvl2": "header h2",
- "lvl3": "header h3",
- "lvl4": "header h4",
- "lvl5": "header h5",
- "lvl6": "header h6",
- "text": "article p, article li, article td:last-child"
- },
- "strip_chars": " .,;:#",
- "custom_settings": {
- "separatorsToIndex": "_",
- "attributesForFaceting": [
- "language",
- "version",
- "type",
- "docusaurus_tag"
- ],
- "attributesToRetrieve": [
- "hierarchy",
- "content",
- "anchor",
- "url",
- "url_without_anchor",
- "type"
- ]
+ "index_name": "aztec-docs",
+ "start_urls": [
+ "https://docs.aztec.network/"
+ ],
+ "sitemap_urls": [
+ "https://docs.aztec.network/sitemap.xml"
+ ],
+ "sitemap_alternate_links": true,
+ "selectors": {
+ "lvl0": {
+ "selector": "(//ul[contains(@class,'menu__list')]//a[contains(@class, 'menu__link menu__link--sublist menu__link--active')]/text() | //nav[contains(@class, 'navbar')]//a[contains(@class, 'navbar__link--active')]/text())[last()]",
+ "type": "xpath",
+ "global": true,
+ "default_value": "Documentation"
},
- "conversation_id": [
- "833762294"
+ "lvl1": "header h1",
+ "lvl2": "header h2",
+ "lvl3": "header h3",
+ "lvl4": "header h4",
+ "lvl5": "header h5",
+ "lvl6": "header h6",
+ "text": "article p, article li, article td:last-child"
+ },
+ "strip_chars": " .,;:#",
+ "custom_settings": {
+ "separatorsToIndex": "_",
+ "attributesForFaceting": [
+ "language",
+ "version",
+ "type",
+ "docusaurus_tag"
],
- "nb_hits": 46250
- }
\ No newline at end of file
+ "attributesToRetrieve": [
+ "hierarchy",
+ "content",
+ "anchor",
+ "url",
+ "url_without_anchor",
+ "type"
+ ]
+ },
+ "conversation_id": [
+ "833762294"
+ ],
+ "nb_hits": 46250
+}
\ No newline at end of file
diff --git a/yarn-project/accounts/src/defaults/index.ts b/yarn-project/accounts/src/defaults/index.ts
index d5b399a1dd26..237e118c3ff5 100644
--- a/yarn-project/accounts/src/defaults/index.ts
+++ b/yarn-project/accounts/src/defaults/index.ts
@@ -1,7 +1,7 @@
/**
* The `@aztec/accounts/defaults` export provides the base class {@link DefaultAccountContract} for implementing account contracts that use the default entrypoint payload module.
*
- * Read more in {@link https://docs.aztec.network/developers/wallets/writing_an_account_contract | Writing an account contract}.
+ * Read more in {@link https://docs.aztec.network/developers/tutorials/codealong/contract_tutorials/write_accounts_contract | Writing an account contract}.
*
* @packageDocumentation
*/
diff --git a/yarn-project/aztec.js/README.md b/yarn-project/aztec.js/README.md
index 8fdc97fa5219..ff0540e71d83 100644
--- a/yarn-project/aztec.js/README.md
+++ b/yarn-project/aztec.js/README.md
@@ -1,6 +1,6 @@
# Aztec.js
-Aztec.js is a library that provides APIs for managing accounts and interacting with contracts on the Aztec network. It communicates with the [Private eXecution Environment (PXE)](https://docs.aztec.network/reference/aztecjs/pxe) through a `PXE` implementation, allowing developers to easily register new accounts, deploy contracts, view functions, and send transactions.
+Aztec.js is a library that provides APIs for managing accounts and interacting with contracts on the Aztec network. It communicates with the [Private eXecution Environment (PXE)](https://docs.aztec.network/developers/reference/aztecjs/pxe) through a `PXE` implementation, allowing developers to easily register new accounts, deploy contracts, view functions, and send transactions.
## Installing
diff --git a/yarn-project/aztec.js/src/contract/index.ts b/yarn-project/aztec.js/src/contract/index.ts
index b69395de86e2..265886aea9cc 100644
--- a/yarn-project/aztec.js/src/contract/index.ts
+++ b/yarn-project/aztec.js/src/contract/index.ts
@@ -1,7 +1,7 @@
/**
* The `contract` module provides utilities for deploying and interacting with contracts, based on a
* `Wallet` instance and a compiled artifact. Refer to the {@link account} module for how to obtain a valid
- * `Wallet` instance, and to the {@link https://docs.aztec.network/developers/contracts/compiling | Compiling contracts}
+ * `Wallet` instance, and to the {@link https://docs.aztec.network/developers/guides/smart_contracts/how_to_compile_contract | Compiling contracts}
* section of the documentation for how to generate an artifact out of your Noir source code.
*
* The {@link Contract} class is the main class in this module, and provides static methods for deploying
@@ -30,7 +30,7 @@
* has synchronized its changes.
*
* @remarks If you are using typescript, consider using the
- * {@link https://docs.aztec.network/developers/contracts/compiling#typescript-interfaces | autogenerated type-safe interfaces}
+ * {@link https://docs.aztec.network/developers/guides/smart_contracts/how_to_compile_contract#typescript-interfaces | autogenerated type-safe interfaces}
* for interacting with your contracts.
*
* @packageDocumentation
diff --git a/yarn-project/cli/src/cmds/misc/update.ts b/yarn-project/cli/src/cmds/misc/update.ts
index fa8265e425cd..34c3d3eed50a 100644
--- a/yarn-project/cli/src/cmds/misc/update.ts
+++ b/yarn-project/cli/src/cmds/misc/update.ts
@@ -10,7 +10,7 @@ import { updateAztecNr } from './update/noir.js';
import { getNewestVersion, updateAztecDeps, updateLockfile } from './update/npm.js';
const AZTECJS_PACKAGE = '@aztec/aztec.js';
-const UPDATE_DOCS_URL = 'https://docs.aztec.network/developers/updating';
+const UPDATE_DOCS_URL = 'https://docs.aztec.network/developers/guides/local_env/versions-updating';
export async function updateProject(
projectPath: string,
diff --git a/yarn-project/entrypoints/src/index.ts b/yarn-project/entrypoints/src/index.ts
index 75ba38e75d6f..fb1c0fedaba8 100644
--- a/yarn-project/entrypoints/src/index.ts
+++ b/yarn-project/entrypoints/src/index.ts
@@ -1,7 +1,7 @@
/**
* The `@aztec/accounts/defaults` export provides the base class {@link DefaultAccountContract} for implementing account contracts that use the default entrypoint payload module.
*
- * Read more in {@link https://docs.aztec.network/tutorials/write_accounts_contract | Writing an account contract}.
+ * Read more in {@link https://docs.aztec.network/developers/tutorials/codealong/contract_tutorials/write_accounts_contract | Writing an account contract}.
*
* @packageDocumentation
*/
diff --git a/yarn-project/pxe/src/pxe_service/pxe_service.ts b/yarn-project/pxe/src/pxe_service/pxe_service.ts
index 3094bb24242a..43942bf99fb8 100644
--- a/yarn-project/pxe/src/pxe_service/pxe_service.ts
+++ b/yarn-project/pxe/src/pxe_service/pxe_service.ts
@@ -657,7 +657,7 @@ export class PXEService implements PXE {
const contract = await this.db.getContract(to);
if (!contract) {
throw new Error(
- `Unknown contract ${to}: add it to PXE Service by calling server.addContracts(...).\nSee docs for context: https://docs.aztec.network/reference/common_errors/aztecnr-errors#unknown-contract-0x0-add-it-to-pxe-by-calling-serveraddcontracts`,
+ `Unknown contract ${to}: add it to PXE Service by calling server.addContracts(...).\nSee docs for context: https://docs.aztec.network/developers/reference/debugging/aztecnr-errors#unknown-contract-0x0-add-it-to-pxe-by-calling-serveraddcontracts`,
);
}