rm a3 references

docs/aztec/components.md

@@ -4,11 +4,9 @@ title: Components
 
 <!-- TODO: Mike to edit. This is a copy of milestone1-1, which actually contained a comprehensive explanation of components (if we remove the json rpc command suggestions) -->
 
-:::caution
-We are building Aztec 3 as transparently as we can. The documents published here are merely an entry point to understanding. These documents are largely complete, but unpolished.
+import Disclaimer from './common/\_disclaimer.mdx';
 
-If you would like to help us build Aztec 3, consider reviewing our [GitHub](https://github.com/AztecProtocol) to contribute code and joining our [forum](https://discourse.aztec.network/) to participate in discussions.
-:::
+<Disclaimer/>
 
 You can track the development of these components in the [aztec3-packages repo](https://github.com/AztecProtocol/aztec3-packages/tree/master).
 
@@ -110,7 +108,7 @@ aztec.js should always be stateless. It offers the ability to interact with stat
 
 The analogous AC component would be the AztecSdk (wraps the CoreSdk which is more analogous to the private client).
 
-- Allows a user to create an Aztec3 keypair. Call `create_account` on Wallet.
+- Allows a user to create an Aztec keypair. Call `create_account` on Wallet.
 - Create a `Contract` instance (similar to web3.js), given a path to a Noir Contract ABI.
 - Construct `tx_request` by calling e.g. `contract.get_deployment_request(constructor_args)`.
 - Call wallet `sign_tx_request(tx_request)` to get signature.

docs/aztec/cryptography/cryptography-roadmap.md

@@ -19,7 +19,7 @@ title: Cryptography Roadmap
 
 ## Goblin projects
 
-- Goblin is a deferred verification framework thats allow for an order-of-magnitude increase in the complexity of computations that Aztec 3 users can execute with full privacy. This corresponds to a 10x increase in the expressivity of Noir programs that can be run in practice without melting anybody's favorite phone or laptop.
+- Goblin is a deferred verification framework thats allow for an order-of-magnitude increase in the complexity of computations that Aztec users can execute with full privacy. This corresponds to a 10x increase in the expressivity of Noir programs that can be run in practice without melting anybody's favorite phone or laptop.
 
 Read more here. https://hackmd.io/@aztec-network/B19AA8812
 

docs/aztec/differences-to-aztec-connect.md

@@ -1,14 +1,14 @@
-## Heuristics that differ from Aztec Connect
+## Heuristics that differ from 'Aztec Connect' (a.k.a. 'Connect')
 
 **A contract cannot manipulate another contract's state**
 
-In A.C. we had multiple circuits that could each create/destroy a unified set of value notes. This was acceptable because all A.C. circuits had a single author (us!).
+In Connect, we had multiple circuits that could each create/destroy a unified set of value notes. This was acceptable because all Connect circuits had a single author (us!).
 
-In A3 our architecture must process arbitrary circuits written by potentially dishonest actors. Contract state must therefore be siloed at the architecture level similar to Ethereum. Fortunately, this does not require splitting up the anonymity set.
+In Aztec our architecture must process arbitrary circuits written by potentially dishonest actors. Contract state must therefore be siloed at the architecture level similar to Ethereum. Fortunately, this does not require splitting up the anonymity set.
 
 **Anonymity set must be shared across all contracts**
 
-In A.C. observers knew when different note types were being created (value note, account note etc). This cannot be the case in A3 as we want to provide strong privacy gaurantees to all private contracts even if they have few transactions interacting with their contract.
+In Connect observers knew when different note types were being created (value note, account note etc). This cannot be the case in Aztec, as we want to provide strong privacy gaurantees to all private contracts even if they have few transactions interacting with their contract.
 
 **Support for call semantics**
 

docs/aztec/how-it-works/l1-l2-messaging.md

@@ -16,13 +16,13 @@ The goal is to setup a minimal-complexity mechanism, that will allow a base-laye
 
 This document will contain communication abstractions that we use to support interaction between _private_ functions, _public_ functions and Layer 1 portal contracts.
 
-Fundamental restrictions for Aztec 3:
+Fundamental restrictions for Aztec:
 
 - L1 and L2 have very different execution environments, stuff that is cheap on L1 is most often expensive on L2 and vice versa. As an example, `keccak256` is cheap on L1, but very expensive on L2.
 - L1 and L2 have causal ordering, simply meaning that we cannot execute something on L1 that depends on something happening on L2 and vice versa.
 - _Private_ function calls are fully "prepared" and proven by the user, which provides the kernel proof along with commitments and nullifiers to the sequencer.
 - _Public_ functions altering public state (updatable storage) must be executed at the current "head" of the chain, which only the sequencer can ensure, so these must be executed separately to the _private_ functions.
-- _Private_ and _public_ functions within A3 are therefore ordered such that first _private_ functions are executed, and then _public_. For a more detailed description of why, see above.
+- _Private_ and _public_ functions within Aztec are therefore ordered such that first _private_ functions are executed, and then _public_. For a more detailed description of why, see above.
 - There is an **explicit 1:1 link** from a L2 contract to an L1 contract, and only the messages between a pair is allowed. See Portal for more information.
 - Messages are consumables, and can only be consumed by the recipient. See [Message Boxes](#message-boxes) for more information.
 
@@ -40,7 +40,7 @@ Because everything is unilateral and async, the application developer have to ex
 
 ### Portal
 
-A "portal" refers to the part of an application residing on L1, which is associated with a particular L2 address (the confidential part of the application). The link between them is established explicitly to reduce access control complexity. On public chains, access control information such as a whitelist in a mapping or similar data structure can simply be placed in public storage. However, this is not feasible for contracts in A3. Recall that public storage can only be accessed (up to date) by public functions which are called AFTER the private functions. This implies that access control values in public storage only work for public functions. One possible workaround is to store them in private data, but this is not always practical for generic token bridges and other similar use cases where the values must be publicly known to ensure that the system remains operational. Instead, we chose to use a hard link between the portal and the L2 address.
+A "portal" refers to the part of an application residing on L1, which is associated with a particular L2 address (the confidential part of the application). The link between them is established explicitly to reduce access control complexity. On public chains, access control information such as a whitelist in a mapping or similar data structure can simply be placed in public storage. However, this is not feasible for contracts in Aztec. Recall that public storage can only be accessed (up to date) by public functions which are called AFTER the private functions. This implies that access control values in public storage only work for public functions. One possible workaround is to store them in private data, but this is not always practical for generic token bridges and other similar use cases where the values must be publicly known to ensure that the system remains operational. Instead, we chose to use a hard link between the portal and the L2 address.
 
 :::info
 Note, that we at no point require the "portal" to be a contract, it could be an EOA on L1.

docs/aztec/how-it-works/private-public-execution.mdx

@@ -4,9 +4,9 @@ title: Private <--> Public execution
 
 import Image from "@theme/IdealImage";
 
-import Disclaimer from "../common/_disclaimer.mdx";
+import Disclaimer from "../common/\_disclaimer.mdx";
 
-<Disclaimer />
+<Disclaimer/>
 
 # Intra-L2 Communication
 
@@ -31,7 +31,7 @@ On the left-hand side of the diagram below, we see the fully public world where
 
 <Image img={require("/img/com-abs-1.png")} />
 
-Given that A3 will comprise both private and public functions, it is imperative that we determine the optimal ordering for these functions. From a logical standpoint, it is reasonable to execute the private functions first as they are executed on a state $S_i$, where $i \le n$, with $S_n$ representing the current state where the public functions always operate on the current state $S_n$. Prioritizing the private functions would also afford us the added convenience of enabling them to invoke the public functions, which is particularly advantageous when implementing a peer-to-pool architecture such as that employed by Uniswap.
+Given that Aztec will comprise both private and public functions, it is imperative that we determine the optimal ordering for these functions. From a logical standpoint, it is reasonable to execute the private functions first as they are executed on a state $S_i$, where $i \le n$, with $S_n$ representing the current state where the public functions always operate on the current state $S_n$. Prioritizing the private functions would also afford us the added convenience of enabling them to invoke the public functions, which is particularly advantageous when implementing a peer-to-pool architecture such as that employed by Uniswap.
 
 Transactions that involve both private and public functions will follow a specific order of execution, wherein the private functions will be executed first, followed by the public functions, and then moving on to the next transaction.
 
@@ -51,7 +51,7 @@ To summarise:
 
 - _Private_ function calls are fully "prepared" and proven by the user, which provides the kernel proof along with new commitments and nullifiers to the sequencer.
 - _Public_ functions altering public state (updatable storage) must be executed at the current "head" of the chain, which only the sequencer can ensure, so these must be executed separately to the _private_ functions.
-- _Private_ and _public_ functions within an A3 transaction are therefore ordered such that first _private_ functions are executed, and then _public_.
+- _Private_ and _public_ functions within an Aztec transaction are therefore ordered such that first _private_ functions are executed, and then _public_.
 
 A more comprehensive overview of the interplay between private and public functions and their ability to manipulate data is presented below. It is worth noting that all data reads performed by private functions are historical in nature, and that private functions are not capable of modifying public storage. Conversely, public functions have the capacity to manipulate private storage (e.g., inserting new commitments, potentially as part of transferring funds from the public domain to the secret domain).
 

docs/aztec/how-it-works/private-smart-contracts.md

@@ -12,7 +12,7 @@ A "smart contract" is defined as a set of public and private functions written a
 
 The end goal is a language that is intuitive to use for developers with no cryptographic knowledge and empowers developers to easily write programable private smart contracts.
 
-There are no plans for EVM compatibility or to support Solidity in Aztec 3. The privacy-first nature of Aztec 3 is fundamentally incompatible with the EVM architecture and Solidity's semantics. In addition, the heavy use of client-side proof construction makes this impractical.
+There are no plans for EVM compatibility or to support Solidity in Aztec. The privacy-first nature of Aztec is fundamentally incompatible with the EVM architecture and Solidity's semantics. In addition, the heavy use of client-side proof construction makes this impractical.
 
 ## Enabling Transaction Semantics: The Aztec Kernel
 

docs/aztec/milestones/features-initial-ldt.md

@@ -10,7 +10,7 @@ The Aztec Sandbox Node is intended to provide developers with a lightweight & fa
 
 Devs should be able to quickly spin up local, emulated instances of an Ethereum blockchain and an Aztec encrypted rollup, and start deploying confidential contracts and submitting confidential txs.
 
-Here's a summary of the features we intend to support with the first release of the A3 sandbox (local developer testnet, LDT).
+Here's a summary of the features we intend to support with the first release of the Aztec Sandbox.
 
 ## Noir Contracts
 

docs/aztec/milestones/milestone1-1.md

@@ -52,7 +52,7 @@ There will be no proofs generated in early milestones. Functions that would norm
 
 ## Thinking About State
 
-The lowest level system state is represented by one or more streams of data. In AC this was the calldata and the off-chain data. A3 will likely have it's state also represented as more than one stream of data. For this milestone we could just adopt a similar separation of data, although longer term some state might make it's way into [danksharding](https://ethereum.org/en/roadmap/danksharding/) blobs, and maybe some state won't go to the ethereum network at all.
+The lowest level system state is represented by one or more streams of data. In AC this was the calldata and the off-chain data. Aztec will likely have it's state also represented as more than one stream of data. For this milestone we could just adopt a similar separation of data, although longer term some state might make it's way into [danksharding](https://ethereum.org/en/roadmap/danksharding/) blobs, and maybe some state won't go to the ethereum network at all.
 
 Regardless, there should be a separation of concern between the stream of data, and how/where it's stored. Data should be stored unprocessed, in an implementation of a simple key-value store interface. So e.g. there maybe a component that when pointed at the rollup contract, stores the calldata for each rollup in a key-value implementation that just saves it to a file named by rollup number.
 
@@ -279,7 +279,7 @@ aztec.js should always be stateless. It offers the ability to interact with stat
 
 The analogous AC component would be the AztecSdk (wraps the CoreSdk which is more analogous to the private client).
 
-- Allows a user to create an Aztec3 keypair. Call `create_account` on Wallet.
+- Allows a user to create an Aztec keypair. Call `create_account` on Wallet.
 - Create a `Contract` instance (similar to web3.js), given a path to a Noir Contract ABI.
 - Construct `tx_request` by calling e.g. `contract.get_deployment_request(constructor_args)`.
 - Call wallet `sign_tx_request(tx_request)` to get signature.

docs/aztec/milestones/milestones.md

@@ -10,7 +10,7 @@ The milestones are written as sets of user stories to make it clear what functio
 
 ## Development Strategy
 
-The goal is that all software components of Aztec3 can be developed as independent modules (e.g. private client, public client, simulators, data sources/sinks, circuit architecture, RPC, cryptography).
+The goal is that all software components of Aztec can be developed as independent modules (e.g. private client, public client, simulators, data sources/sinks, circuit architecture, RPC, cryptography).
 
 When modules need to communicate across module boundaries, they do so via clearly defined APIs.
 

docs/aztec/overview.mdx

@@ -3,9 +3,9 @@ title: Overview
 ---
 
 import ReactPlayer from "react-player/youtube";
-import Disclaimer from "./common/_disclaimer.mdx";
+import Disclaimer from "./common/\_disclaimer.mdx";
 
-<Disclaimer />
+<Disclaimer/>
 
 The next version of our rollup, Aztec, is a privacy-preserving, programmable extension to Ethereum. It is a layer 2 zk-rollup on Ethereum that enables programable privacy via composable smart contracts.
 
@@ -36,7 +36,7 @@ Watch Zac, CEO of Aztec, describe our approach to building a privacy preserving
 
 ### Private-public Composability
 
-You can watch Mike, Aztec 3 PM, talk about public-private composablity in Aztec 3 at Devcon here.
+You can watch Mike, Aztec PM, talk about public-private composablity in Aztec at Devcon here.
 
 <ReactPlayer
   controls
@@ -47,7 +47,7 @@ You can watch Mike, Aztec 3 PM, talk about public-private composablity in Aztec
 
 ## How Aztec is being built
 
-Aztec is being built and launched as a credibly neutral, decentralized network. The protocol is being developed as open source software by Aztec (the company) and our community. Together we are designing, building and auditing much of the software that will be run by network stakeholders such as infrastructure providers in order to create the Aztec network.
+Aztec is being built and launched as a credibly neutral, decentralized network. The protocol is being developed as open source software by Aztec (the company) and our community. Together we are designing, building and auditing much of the software that will be run by network stakeholders such as infrastructure providers in order to create Aztec.
 
 Contributors to Aztec uphold many of the values of the Ethereum community -- building in public, a rigorous commitment to open source and a goal to build a permission-less, censorship resistance system.
 

docs/aztec/protocol/contract-creation.md

@@ -12,7 +12,7 @@ import Disclaimer from '../common/\_disclaimer.mdx';
 
 Answer:
 
-- How are contracts represented in Aztec3?
+- How are contracts represented in Aztec?
 - How does a transaction deploy a contract?
 - How do we validate contract bytecode
 
@@ -42,9 +42,9 @@ Each contract's function data is stored in a Merkle tree, where each leaf contai
 
 We can take a leaf from Ethereum and make them the first 4 bytes of a hash of the function definition (defined according to the contract ABI, TBD).
 
-## Contract Representation in Aztec3
+## Contract Representation in Aztec
 
-Aztec3 contains a contract Merkle tree that stores all contract data (the contract tree).
+Aztec contains a contract Merkle tree that stores all contract data (the contract tree).
 
 Each leaf represents a contract, and contains a hash of the following:
 
@@ -69,7 +69,7 @@ L2 contracts can only call L1 contracts via its designated portal contract.
 
 L2 contracts can only be called _from_ L1 via calls from the portal contract.
 
-The goal is to simplify the domain knowledge required for A3 devs - all comms that go across the L2-L1 boundary must go via an L2 contract's respective portal contract.
+The goal is to simplify the domain knowledge required for Aztec devs - all comms that go across the L2-L1 boundary must go via an L2 contract's respective portal contract.
 
 Portal contracts also act as custodians for tokens while they are bridged into their respective L2 contract.
 
@@ -166,7 +166,7 @@ In order to link a `contractAddress`, with with a leafIndex in the `contractTree
 
 The `contractAddress` is stored within the contract's leaf of the `contractTree`, so that the private kernel circuit may validate contract address <--> vk relationships.
 
-> Aside: It would have been neat for a contract's address to be the leaf index of its mini Merkle tree (i.e. the root of the `vkTree`) in the`contractTree`. However, the leaf index is only known at the time the rollup provider runs the 'contract deployment kernel snark', whereas we need the contract address to be known earlier, at the time the deployer generates the private constructor proof. Without a contract address, the private constructor would not be able to: call other functions (and pass them a valid callContext); or [silo](https://github.com/AztecProtocol/aztec3-circuits/blob/master/specs/src/architecture/contracts/states-and-storage.md#preventing-private-state-collisions) newly created commitments.
+> Aside: It would have been neat for a contract's address to be the leaf index of its mini Merkle tree (i.e. the root of the `vkTree`) in the`contractTree`. However, the leaf index is only known at the time the rollup provider runs the 'contract deployment kernel snark', whereas we need the contract address to be known earlier, at the time the deployer generates the private constructor proof. Without a contract address, the private constructor would not be able to: call other functions (and pass them a valid callContext); or silo newly-created commitments.
 
 ## Deployment overview