chore(docs): rename to aztec.nr

docs/docs/about_aztec/roadmap/features_initial_ldt.md

@@ -8,7 +8,7 @@ Devs should be able to quickly spin up local, emulated instances of an Ethereum
 
 Here's a summary of the features we intend to support with the first release of the Aztec Sandbox.
 
-## Noir Contracts
+## Aztec.nr Contracts
 
 - Noir `contract` scopes.
   - Declare a `contract`, containing a collection of state variables and functions.
@@ -21,22 +21,22 @@ Here's a summary of the features we intend to support with the first release of
 - public functions
   - May read and modify public state.
 - `constructor` functions, for initialising contract state.
-- `import` other Noir contracts, so their functions may be called.
+- `import` other Aztec.nr contracts, so their functions may be called.
 - Nested function calls, for contract composability
   - private functions can call private functions of other contracts, and receive return values.
   - private functions can call public functions any contract.
   - public functions can call private functions of any contract.
   - public functions can call public functions of other contracts, and receive return values.
   - private functions can be called recursively.
   - public functions can be called recursively.
-- Send messages from Noir contracts to Ethereum L1, for consumption by L1 smart contracts.
+- Send messages from Aztec.nr contracts to Ethereum L1, for consumption by L1 smart contracts.
   - Useful, for example, if writing an app to withdraw funds from L2 to L1.
 - Consume messages which have been sent by:
   - L1 functions.
     - Useful, for example, if writing an app to deposit funds from L1 to L2.
   - public L2 functions.
-- Emit `event` data from a Noir Contract.
-  - Allows applications to subscribe to events which have been emitted by a Noir contract's functions, for example.
+- Emit `event` data from a Aztec.nr Contract.
+  - Allows applications to subscribe to events which have been emitted by a Aztec.nr contract's functions, for example.
 - Write `unconstrained` functions.
   - These allow developers to write `pure` and `view` functions, which can perform calculations and retrieve state. E.g. for fetching contract-specific information, which may then be consumed by a dapp, without having to generate a zero-knowledge proof or interact with the 'network'.
 
@@ -46,13 +46,13 @@ A typescript wrapper for making RPC calls to an Aztec LDT node.
 
 - Similar in purpose to `web3.js`/`ethers.js`/`viem`, but for interacting with Aztec Network nodes. The RPC interface for an Aztec node is necessarily different from that of an Ethereum node, because it deals with encrypted transactions and state variables.
 - A library for public/private key management.
-- Construct `Contract` instances from a Noir contract's JSON ABI.
+- Construct `Contract` instances from a Aztec.nr contract's JSON ABI.
 - Deploy new contracts to the Aztec LDT.
 - Construct tx requests, passing arguments to a function of a contract.
 - Sign tx requests.
 - Send txs to the LDT node, for simulating.
 - Send txs to the LDT node, to be sent to the LDT network.
-- Call `unconstrained` functions of a Noir contract, to perform `pure` calculations or retrieve state.
+- Call `unconstrained` functions of a Aztec.nr contract, to perform `pure` calculations or retrieve state.
 
 ## Aztec Local Developer Testnet Node
 

docs/docs/concepts/advanced/circuits/kernels/private_kernel.md

@@ -6,7 +6,7 @@ This circuit is executed by the user, on their own device. This is to ensure pri
 
 - Verifies a user's signature.
 - Hides the user's address.
-- Verifies an app's proof - i.e. a proof which has been output after the execution of some function in a Noir Contract.
+- Verifies an app's proof - i.e. a proof which has been output after the execution of some function in an Aztec.nr Contract.
 - Performs private state reads and writes.
 - Exposes (forwards) the following data to the next recursive circuit:
   - new note hashes;
@@ -21,5 +21,5 @@ This circuit is executed by the user, on their own device. This is to ensure pri
 - Verifies a previous 'Private Kernel Proof', recursively, when verifying transactions which are composed of many private function calls.
 - Optionally can [deploy](../../contract_creation) a new private contract.
 
-> Note: **This is the only core protocol circuit which actually needs to be "zk" (zero knowledge)!!!** That's because this is the only core protocol circuit which handles private data, and hence the only circuit for which proofs must not leak any information about witnesses! (The private data being handled includes: details of the Noir Contract function which has been executed; the address of the user who executed the function; the intelligible inputs and outputs of that function).
+> Note: **This is the only core protocol circuit which actually needs to be "zk" (zero knowledge)!!!** That's because this is the only core protocol circuit which handles private data, and hence the only circuit for which proofs must not leak any information about witnesses! (The private data being handled includes: details of the Aztec.nr Contract function which has been executed; the address of the user who executed the function; the intelligible inputs and outputs of that function).
 > This is a really interesting point. Most so-called "zk-Rollups" do not make use of this "zero knowledge" property. Their snarks are "snarks"; with no need for zero-knowledge, because they don't seek privacy; they only seek the 'succinct' computation-compression properties of snarks. Aztec's "zk-Rollup" actually makes use of "zero knowledge" snarks. That's why we sometimes call it a "zk-zk-Rollup", or "_actual_ zk-Rollup".

docs/docs/concepts/advanced/circuits/main.md

@@ -7,7 +7,7 @@ title: Circuits
 In Aztec, circuits come from two sources:
 
 1. Core protocol circuits
-2. User-written circuits (written as Noir Contracts and deployed to the network)
+2. User-written circuits (written as Aztec.nr Contracts and deployed to the network)
 
 This page focusses on the core protocol circuits. These circuits check that the rules of the protocol are being adhered to.
 

docs/docs/concepts/advanced/data_structures/trees.md

@@ -25,19 +25,19 @@ So, if an app needs to edit a private state variable (which will be represented
 
 ### Example Note
 
-An example blob of data might be defined in a Noir Contract as:
+An example blob of data might be defined in an Aztec.nr Contract as:
 
 ```rust
 struct MyNote {
-    storage_slot: Field, // determined by the Noir Contract
+    storage_slot: Field, // determined by the Aztec.nr Contract
     value: Field,
     owner_public_key: Point, // The owner of this private state
                              // (and the person who may edit it).
     randomness: Field,
 }
 ```
 
-The note might be committed-to, within a function of the Noir Contract as:
+The note might be committed-to, within a function of the Aztec.nr Contract as:
 
 ```rust
 note_hash: Field = pedersen::compress(

docs/docs/concepts/foundation/accounts/keys.md

@@ -69,7 +69,7 @@ The privacy master key is used to derive encryption keys. Encryption keys, as th
 
 In a future version, encryption keys will be differentiated between incoming and outgoing. When sending a note to another user, the sender will use the recipient's incoming encryption key for encrypting the data for them, and will optionally use their own outgoing encryption key for encrypting any data about the destination of that note. This is useful for reconstructing transaction history from on-chain data. For example, during a token transfer, the token contract may dictate that the sender encrypts the note with value with the recipient's incoming key, but also records the transfer with its own outgoing key for bookkeeping purposes.
 
-An application in Noir can access the encryption public key for a given address using the oracle call `get_public_key`, which you can then use for calls such as `emit_encrypted_log`:
+An application in Aztec.nr can access the encryption public key for a given address using the oracle call `get_public_key`, which you can then use for calls such as `emit_encrypted_log`:
 
 #include_code encrypted /yarn-project/noir-libs/value-note/src/utils.nr rust
 
@@ -81,7 +81,7 @@ In order to be able to provide the public encryption key for a given address, th
 
 In addition to deriving encryption keys, the privacy master key is used for deriving nullifier secrets. Whenever a private note is consumed, a nullifier deterministically derived from it is emitted. This mechanisms prevents double-spends, since nullifiers are checked by the protocol to be unique. Now, in order to preserve privacy, a third party should not be able to link a note commitment to its nullifier - this link is enforced by the note implementation. Therefore, calculating the nullifier for a note requires a secret from its owner.
 
-An application in Noir can request a nullifier from the current user for computing the nullifier of a note via the `get_secret_key` oracle call:
+An application in Aztec.nr can request a nullifier from the current user for computing the nullifier of a note via the `get_secret_key` oracle call:
 
 #include_code nullifier /yarn-project/noir-libs/value-note/src/value_note.nr rust
 

docs/docs/concepts/foundation/state_model.md

@@ -10,7 +10,7 @@ import Disclaimer from '../../misc/common/\_disclaimer.mdx';
 
 ## Private State
 
-Private state must be treated differently from public state and this must be expressed in the semantics of the Noir language.
+Private state must be treated differently from public state and this must be expressed in the semantics of Aztec.nr.
 
 Private state is encrypted and therefore is "owned" by a user or a set of users (via shared secrets) that are able to decrypt the state.
 
@@ -22,12 +22,12 @@ Modification of state variables can be emulated by nullifying the a state record
 
 ### Abstracting UTXO's from App's / Users
 
-The goal of Noir's contract syntax is abstract the UTXO model away from an app user / developer, contract developers are the only actor who should have to think about UTXO's.
+The goal of the Aztec.nr smart contract library is to abstract the UTXO model away from an app user / developer, contract developers are the only actor who should have to think about UTXO's.
 
 This is achieved with two main features:
 
 1. Users sign over transactions, not over specific UTXO's
-2. Noir contracts support developer defined `unconstrained` getter functions to help dApp's make sense of UTXO's. e.g `getBalance()`. These functions can be called outside of a transaction context to read private state.
+2. Aztec.nr contracts support developer defined `unconstrained` getter functions to help dApp's make sense of UTXO's. e.g `getBalance()`. These functions can be called outside of a transaction context to read private state.
 
 
 ### The lifecycle of a note

docs/docs/dev_docs/contracts/common_errors.md

@@ -2,7 +2,7 @@
 
 List common errors.
 
-There are two kinds of errors: errors in a noir contract, and errors spat out by an Aztec Sandbox node!
+There are two kinds of errors: errors in an Aztec.nr contract, and errors spat out by an Aztec Sandbox node!
 
 Maybe even auto-generate error docs, based on error codes in our codebase.
 

docs/docs/dev_docs/contracts/compiling.md

@@ -1,10 +1,10 @@
 # Compiling contracts
 
-Once you have written a [contract](../contracts/main.md) in Noir, you will need to compile it into an [artifact](./abi.md) in order to use it.
+Once you have written a [contract](../contracts/main.md) in Aztec.nr, you will need to compile it into an [artifact](./abi.md) in order to use it.
 
 In this guide we will cover how to do so, both using the CLI and programmatically.
 
-We'll also cover how to generate a helper [TypeScript interface](#typescript-interfaces) and a [Noir interface](#noir-interfaces) for easily interacting with your contract from your typescript app and from other noir contracts, respectively.
+We'll also cover how to generate a helper [TypeScript interface](#typescript-interfaces) and an [Aztec.nr interface](#noir-interfaces) for easily interacting with your contract from your typescript app and from other Aztec.nr contracts, respectively.
 
 ## Prerequisites
 
@@ -70,13 +70,13 @@ export class PrivateTokenContract extends ContractBase {
 
 Read more about interacting with contracts using `aztec.js` [here](../dapps/main.md).
 
-### Noir interfaces
+### Aztec.nr interfaces
 
-A Noir contract can [call a function](./functions.md) in another contract via `context.call_private_function` or `context.call_public_function`. However, this requires manually assembling the function selector and manually serialising the arguments, which is not type-safe.
+An Aztec.nr contract can [call a function](./functions.md) in another contract via `context.call_private_function` or `context.call_public_function`. However, this requires manually assembling the function selector and manually serialising the arguments, which is not type-safe.
 
 To make this easier, the compiler can generate contract interface structs that expose a convenience method for each function listed in a given contract ABI. These structs are intended to be used from another contract project that calls into the current one. For each contract, two interface structs are generated: one to be used from private functions with a `PrivateContext`, and one to be used from open functions with a `PublicContext`.
 
-To generate them, include a `--interface` option in the compile command with a path to the target folder for the generated Noir interface files:
+To generate them, include a `--interface` option in the compile command with a path to the target folder for the generated Aztec.nr interface files:
 
 ```
 aztec-cli compile --interface ./path/to/another_aztec_contract_project/src ./path/to/my_aztec_contract_project
@@ -116,7 +116,7 @@ impl PrivateTokenPrivateContextInterface {
 }
 ```
 
-Read more about how to use the Noir interfaces [here](./functions.md#contract-interface).
+Read more about how to use the Aztec.nr interfaces [here](./functions.md#contract-interface).
 
 :::info
 At the moment, the compiler generates these interfaces from already compiled ABIs, and not from source code. This means that you should not import a generated interface from within the same project as its source contract, or you risk circular references.
@@ -131,9 +131,9 @@ npm install @aztec/noir-compiler
 `
 
 The compiler exposes the following functions:
-- `compileUsingNargo`: Compiles a Noir project in the target folder using the `nargo` binary available on the shell `PATH` and returns the generated ABIs.
+- `compileUsingNargo`: Compiles an Aztec.nr project in the target folder using the `nargo` binary available on the shell `PATH` and returns the generated ABIs.
 - `generateTypescriptContractInterface`: Generates a typescript class for the given contract ABI.
-- `generateNoirContractInterface`: Generates a Noir interface struct for the given contract ABI.
+- `generateNoirContractInterface`: Generates a Aztec.nr interface struct for the given contract ABI.
 
 ## Next steps
 

docs/docs/dev_docs/contracts/contract.md

@@ -18,7 +18,7 @@ contract MyContract {
 ```
 
 
-> A note for vanilla Noir devs: There is no [`main()`](https://noir-lang.org/getting_started/breakdown/#mainnr) function within a Noir Contract scope. This is because more than one function of a contract may be called and proven as external (as opposed to inlined by the compiler).
+> A note for vanilla Noir devs: There is no [`main()`](https://noir-lang.org/getting_started/breakdown/#mainnr) function within a Noir `contract` scope. This is because more than one function of a contract may be called and proven as external (as opposed to inlined by the compiler).
 
 ## Structure of a contract
 

docs/docs/dev_docs/contracts/layout.md

@@ -1,7 +1,7 @@
 # Layout
 ## Directory structure
 
-Here's a common layout for a basic Noir Contract project:
+Here's a common layout for a basic Aztec.nr Contract project:
 
 ``` title="layout of an aztec contract project"
 ─── my_aztec_contract_project

docs/docs/dev_docs/contracts/main.md

@@ -2,7 +2,7 @@
 
 ## What is Aztec.nr?
 
-**Aztec.nr** is a library for writing Aztec smart contracts.
+**Aztec.nr** is a framework for writing Aztec smart contracts.
 
 ## Nomenclature
 
@@ -12,17 +12,17 @@ A **smart contract** is just a collection of persistent state variables, and a c
 
 An **Aztec smart contract** is a smart contract with **private** state variables and **private** functions.
 
-**Aztec.nr** is a library for writing Aztec smart contracts, written in Noir.
+**Aztec.nr** is a framework for writing Aztec smart contracts, written in Noir.
 
 # Getting started
 
 ## Install Noir
 
-To write a Noir Contract, you need to write Noir, and to write Noir, you need to [install Nargo](https://noir-lang.org/getting_started/nargo_installation).
+To write an Aztec.nr contract, you need to write Noir, and to write Noir, you need to [install Nargo](https://noir-lang.org/getting_started/nargo_installation).
 
 ## Install Noir tooling
 
-There are a number of tools to make writing Noir Contracts more pleasant. See [here](https://github.com/noir-lang/awesome-noir#get-coding).
+There are a number of tools to make writing Aztec.nr contracts more pleasant. See [here](https://github.com/noir-lang/awesome-noir#get-coding).
 
 ## Quick start
 
@@ -31,7 +31,7 @@ Starter kit
 :::
 
 
-## Example Noir Contract
+## Example Aztec.nr Contract
 
 In keeping with the origins of blockchain, here's an example of a simple private token contract. Everyone's balances are private.
 

docs/docs/dev_docs/contracts/storage.md

@@ -1,6 +1,6 @@
 # Storage
 
-> A common convention in Noir Contracts is to declare the state variables for your Noir Contract in a `storage.nr` file inside your project (see [directory structure](./layout.md#directory-structure)). This is just a convention, though: your contract would still work if you declare storage in the `main.nr` file.
+> A common convention when writing Aztec.nr contracts is to declare the state variables for your contract in a `storage.nr` file inside your project (see [directory structure](./layout.md#directory-structure)). This is just a convention, though: your contract would still work if you declare storage in the `main.nr` file.
 
 State variables must be declared inside a struct. (This enables us to declare types composed of nested generics in Noir - see [types](./types.md)).
 

docs/docs/dev_docs/contracts/types.md

@@ -1,2 +1,2 @@
 See Noir docs for Noir types.
-See [state_variables](./state_variables.md) for Noir Contract state variable types.
+See [state_variables](./state_variables.md) for Aztec.nr state variable types.

docs/docs/dev_docs/contracts/workflow.md

@@ -1,4 +1,4 @@
-# Noir contract workflow
+# Aztec.nr smart contract workflow
 
  ## Write
 

docs/docs/dev_docs/dapps/main.md

@@ -21,7 +21,7 @@ Explain how to write a dapp using [`aztec.js`](https://github.com/AztecProtocol/
     - Use the e2e tests as inspiration.
       - Instantiate a contract
       - Deploy a contract
-      - How to generate a nice typescript interface for a Noir Contract's functions (we have a little `.ts` program in `noir-contracts` to generate a types file at the moment... how would a user do this?)
+      - How to generate a nice typescript interface for an Aztec.nr contract's functions (we have a little `.ts` program in `noir-contracts` to generate a types file at the moment... how would a user do this?)
       - Call 'view' functions
       - Simulate functions (simulate the result, without sending to the 'network')
       - Execute functions (send them to the 'network')

docs/docs/dev_docs/getting_started/sandbox.md

@@ -6,7 +6,7 @@ import Image from "@theme/IdealImage";
 
 ## Introduction
 
-The Aztec Sandbox aims to provide a local development system against which you can build and test Noir contracts in a fast, safe, and free environment.
+The Aztec Sandbox aims to provide a local development system against which you can build and test Aztec.nr contracts in a fast, safe, and free environment.
 
 Here we will walkthrough the process of retrieving the Sandbox, installing the client libraries and using it to deploy and use a fully private token contract on the Aztec network.