refactor: rename all the occurrences of Aztec RPC (#2552)

Fixes #2451

.circleci/config.yml

@@ -520,7 +520,7 @@ jobs:
           name: "Build"
           command: build end-to-end
 
-  e2e-2-rpc-servers:
+  e2e-2-pxes:
     machine:
       image: ubuntu-2204:2023.07.2
     resource_class: large
@@ -529,7 +529,7 @@ jobs:
       - *setup_env
       - run:
           name: "Test"
-          command: cond_run_script end-to-end ./scripts/run_tests_local e2e_2_rpc_servers.test.ts
+          command: cond_run_script end-to-end ./scripts/run_tests_local e2e_2_pxes.test.ts
 
   e2e-multiple-accounts-1-enc-key:
     machine:
@@ -826,7 +826,7 @@ jobs:
       - *setup_env
       - run:
           name: "Test"
-          command: cond_run_script end-to-end ./scripts/run_tests_local aztec_rpc_sandbox.test.ts ./scripts/docker-compose-e2e-sandbox.yml
+          command: cond_run_script end-to-end ./scripts/run_tests_local pxe_sandbox.test.ts ./scripts/docker-compose-e2e-sandbox.yml
 
   cli-docs-sandbox:
     machine:
@@ -1186,7 +1186,7 @@ workflows:
             - canary
           <<: *defaults
 
-      - e2e-2-rpc-servers: *e2e_test
+      - e2e-2-pxes: *e2e_test
       - e2e-deploy-contract: *e2e_test
       - e2e-lending-contract: *e2e_test
       - e2e-token-contract: *e2e_test
@@ -1223,7 +1223,7 @@ workflows:
 
       - e2e-end:
           requires:
-            - e2e-2-rpc-servers
+            - e2e-2-pxes
             - e2e-deploy-contract
             - e2e-lending-contract
             - e2e-token-contract

README.md

@@ -11,7 +11,7 @@ All the packages that make up [Aztec](https://docs.aztec.network).
 
 - [Aztec.nr](./yarn-project/aztec-nr/): A [Noir](https://noir-lang.org) framework for smart contracts on Aztec.
 - [Aztec Sandbox](./yarn-project/aztec-sandbox/): A package for setting up a local dev net, including a local Ethereum network, deployed rollup contracts and Aztec execution environment.
-- [Aztec.js](./yarn-project/aztec.js/): A tool for interacting with the Aztec network. It communicates via the [Aztec RPC Server](./yarn-project/pxe/).
+- [Aztec.js](./yarn-project/aztec.js/): A tool for interacting with the Aztec network. It communicates via the [Private Execution Environment (PXE)](./yarn-project/pxe/).
 - [Aztec Boxes](./yarn-project/boxes/): A minimal framework for building full stack applications for Aztec (using React).
 - [Example contracts](./yarn-project/noir-contracts/): Example contracts for the Aztec network, written in Noir.
 - [End to end tests](./yarn-project/end-to-end/): Integration tests writted in Typescript--a good reference for how to use the packages for specific tasks.

docs/docs/about_aztec/roadmap/features_initial_ldt.md

@@ -64,7 +64,7 @@ A typescript wrapper for making RPC calls to an Aztec Sandbox node. See the sour
 
 A bundle of packages which emulate the actions of all eventual Aztec network participants. The goal is for developer experience to be akin to Ganache / Anvil.
 
-- Aztec RPC Client
+- PXE client
   - Simulate and/or execute private functions locally.
 - Aztec Public Node
   - Broadcasts a user's txs to the tx pool.

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

@@ -74,7 +74,7 @@ An application in Aztec.nr can access the encryption public key for a given addr
 #include_code encrypted /yarn-project/aztec-nr/value-note/src/utils.nr rust
 
 :::info
-In order to be able to provide the public encryption key for a given address, that public key needs to have been registered in advance. At the moment, there is no broadcasting mechanism for public keys, which means that you will need to manually register all addresses you intend to send encrypted notes to. You can do this via the `registerRecipient` method of the Aztec RPC server, callable either via aztec.js or the CLI. Note that any accounts you own that have been added to the RPC server are automatically registered.
+In order to be able to provide the public encryption key for a given address, that public key needs to have been registered in advance. At the moment, there is no broadcasting mechanism for public keys, which means that you will need to manually register all addresses you intend to send encrypted notes to. You can do this via the `registerRecipient` method of the Private Execution Environment (PXE), callable either via aztec.js or the CLI. Note that any accounts you own that have been added to the RPC server are automatically registered.
 :::
 
 ### Nullifier secrets

docs/docs/dev_docs/cli/main.md

@@ -36,7 +36,7 @@ Once installed it is invoked via:
 
 ## I have the Sandbox running, now what?
 
-Lets first establish that we are able to communicate with the Sandbox. Most commands will require the url to the Sandbox, which defaults in the CLI to `http://localhost:8080`. You can override this as an option with each command or by setting `AZTEC_RPC_HOST` environment variable.
+Lets first establish that we are able to communicate with the Sandbox. Most commands will require the url to the Sandbox, which defaults in the CLI to `http://localhost:8080`. You can override this as an option with each command or by setting `PXE_HOST` environment variable.
 
 To test communication with the Sandbox, let's run the command:
 
@@ -124,7 +124,7 @@ The `call` command calls a read-only method on a contract, one that will not gen
 - `--contract-abi` - The abi of the contract we are calling.
 - `--contract-address` - The address of the deployed contract
 
-As you can see from the result, this address has a balance of 1000000, as expected. When using the Sandbox, you are able to query the balance of any account that has been created in the system, even the accounts created by default. You may wonder why this is, as you haven't provided the private keys for these accounts. The Sandbox contains a component known as the AztecRPCServer. When an account is created, this component stores the provided encryption private key and is able to read the account's private state meaning that the Sandbox can report the balance of any of it's accounts. More information about the account model can be found [here](../../concepts/foundation/accounts/main.md).
+As you can see from the result, this address has a balance of 1000000, as expected. When using the Sandbox, you are able to query the balance of any account that has been created in the system, even the accounts created by default. You may wonder why this is, as you haven't provided the private keys for these accounts. The Sandbox contains a component known as the Private Execution Environment (PXE). When an account is created, this component stores the provided encryption private key and is able to read the account's private state meaning that the Sandbox can report the balance of any of it's accounts. More information about the account model can be found [here](../../concepts/foundation/accounts/main.md).
 
 ## Sending a Transaction
 

docs/docs/dev_docs/contracts/common_errors.md

@@ -15,34 +15,34 @@ Simulation error: Assertion failed: Balance too low 'sum == amount'
 To address the error. find the line in the contract that is throwing the error and investigate why the condition is not met.
 
 ### Unknown Contract Error
-This error occurs when you are trying to interact with a smart contract via an Aztec RPC Server that does not have the necessary information to execute a transaction.
+This error occurs when you are trying to interact with a smart contract via an Private Execution Environment (PXE) that does not have the necessary information to execute a transaction.
 
 This is what the error typically looks like:
 ```
-Unknown contract 0x1d206be10b873b78b875259e1a8c39e2212e2f181d2fd0b0407446487deba522: add it to Aztec RPC server by calling server.addContracts(...)
+Unknown contract 0x1d206be10b873b78b875259e1a8c39e2212e2f181d2fd0b0407446487deba522: add it to PXE by calling server.addContracts(...)
 ```
 
-To execute a transaction, the Aztec RPC Server needs to know the complete address of a contract, portal address (if portal is used) and contract artifacts.
+To execute a transaction, the PXE needs to know the complete address of a contract, portal address (if portal is used) and contract artifacts.
 
-To address the error, add the contract to the Aztec RPC Server by calling `server.addContracts(...)`.
+To address the error, add the contract to the PXE by calling `server.addContracts(...)`.
 
 ### Unknown Complete Address Error
-This error occurs when your contract is trying to get a public key via the `get_public_key` oracle call, but the Aztec RPC Server does not have the Complete Address (Complete Address contains the public key).
+This error occurs when your contract is trying to get a public key via the `get_public_key` oracle call, but the PXE does not have the Complete Address (Complete Address contains the public key).
 
 This is what the error typically looks like:
 ```
-Simulation error: Unknown complete address for address 0x0d179a5f9bd4505f7dfb8ca37d64e0bd0cd31b5cb018e252fd647bdf88959b95. Add the information to Aztec RPC server by calling server.registerRecipient(...) or server.registerAccount(...)
+Simulation error: Unknown complete address for address 0x0d179a5f9bd4505f7dfb8ca37d64e0bd0cd31b5cb018e252fd647bdf88959b95. Add the information to PXE by calling pxe.registerRecipient(...) or pxe.registerAccount(...)
 ```
 
 Your contract typically needs a public key when it wants to send a note to a recipient because the public key is used to encrypt notes.
 
 :::info
-Manually adding the recipient to the Aztec RPC Server should not be required in case the recipient contract has already been deployed and the Aztec RPC Server is fully synced.
+Manually adding the recipient to the PXE should not be required in case the recipient contract has already been deployed and the PXE is fully synced.
 This is because this information is submitted on-chain when the recipient contract is deployed.
 :::
 
 ### Unknown account
-This error occurs when your contract is trying to get a secret via the `get_secret` oracle call, but the Aztec RPC Server does not have the secret for the public key.
+This error occurs when your contract is trying to get a secret via the `get_secret` oracle call, but the PXE does not have the secret for the public key.
 
 This is what the error typically looks like:
 ```

docs/docs/dev_docs/contracts/compiling.md

@@ -54,7 +54,7 @@ export class PrivateTokenContract extends ContractBase {
   public static async at(address: AztecAddress, wallet: Wallet) { ... }
 
   /** Creates a tx to deploy a new instance of this contract. */
-  public static deploy(rpc: AztecRPC, initial_supply: FieldLike, owner: FieldLike) { ... }
+  public static deploy(pxe: PXE, initial_supply: FieldLike, owner: FieldLike) { ... }
 
   /** Type-safe wrappers for the public methods exposed by the contract. */
   public methods!: {

docs/docs/dev_docs/contracts/deploying.md

@@ -41,7 +41,7 @@ Now you can import it to easily deploy and interact with the contract.
 ```ts
 import { ExampleContract } from './Example.js';
 
-const tx = ExampleContract.deploy(aztecRpc).send();
+const tx = ExampleContract.deploy(pxe).send();
 await tx.wait({ interval: 0.5 });
 const receipt = await tx.getReceipt();
 const exampleContract = await ExampleContract.at(receipt.contractAddress!, myWallet);
@@ -58,7 +58,7 @@ There are several optional arguments that can be passed:
 
 The command also takes the following optional arguments:
 - `-args <constructorArgs...>` (default: `[]`): Arguments to pass to the contract constructor.
-- `--rpc-url <string>` (default: `http://localhost:8080`): URL of the Aztec node to connect to.
+- `--rpc-url <string>` (default: `http://localhost:8080`): URL of the PXE to connect to.
 - `--public-key <string>` (default: `undefined`): Optional encryption public key for this contract.
 Set this only if this contract is expected to receive private notes (in such a case the public key is used during the note encryption).
 - `--salt <string>` (default: random value): Hexadecimal string used when computing the contract address of the contract being deployed.
@@ -69,7 +69,7 @@ Set it, if you need a deterministic contract address (same functionality as Ethe
 <TabItem value="js" label="Aztec.js">
 
 The `deploy(...)` method is generated automatically with the typescript class representing your contract.
-Its arguments are `AztecRPC` client and contract constructor arguments.
+Its arguments are `PXE` client and contract constructor arguments.
 
 Additionally the `.send()` method can have a few optional arguments too, which are specified in an optional object:
 - `portalContract?: EthAddress`: The L1 portal address to link the contract to. See the section on [Portals to learn more about them](./portals/main.md).
@@ -78,7 +78,7 @@ By default is set to a random value.
 Set it, if you need a deterministic contract address (same functionality as Ethereum's `CREATE2` opcode).
 
 ```ts
-const tx = ExampleContract.deploy(aztecRpc).send({ 
+const tx = ExampleContract.deploy(pxe).send({ 
     portalContract: EthAddress.from("0x1234..."),
     contractAddressSalt: new Fr(3n),
 });
@@ -91,7 +91,7 @@ const tx = ExampleContract.deploy(aztecRpc).send({
 To give you a more complete example we will deploy the `PrivateToken` contract whose artifacts are included in the `@aztec/noir-contracts` package.
 
 The contract has `initial_supply` and `owner` as constructor arguments.
-Because the contract sends a note to the owner specified inside the constructor, we need their public key to encrypt the note with. For this, we first need to register the owner as a recipient inside the Aztec RPC with the following command:
+Because the contract sends a note to the owner specified inside the constructor, we need their public key to encrypt the note with. For this, we first need to register the owner as a recipient inside the PXE with the following command:
 
 <Tabs groupId="deployment-methods">
 <TabItem value="cli" label="Aztec CLI">
@@ -109,18 +109,18 @@ const publicKey = Point.fromString("0x26e193aef4f83c70651485b5526c6d01a36d763223
 const partialAddress = Fr.fromString("0x200e9a6c2d2e8352012e51c6637659713d336405c29386c7c4ac56779ab54fa7");
 
 const completeAddress = CompleteAddress.create(aztecAddress, publicKey, partialKey); 
-await aztecRpc.registerRecipient(completeAddress);
+await pxe.registerRecipient(completeAddress);
 ```
 
 
 </TabItem>
 </Tabs>
 
-When you create a new account, it gets automatically registered. It can be verified by calling `aztec-cli get-accounts` OR in aztec.js by using `await aztecRpc.getRegisteredAccounts()`
+When you create a new account, it gets automatically registered. It can be verified by calling `aztec-cli get-accounts` OR in aztec.js by using `await pxe.getRegisteredAccounts()`
 
 > **NOTE 1**: If we didn't register owner as a recipient we could not encrypt a note for the owner and the contract deployment would fail because constructor execution would fail (we need owner's public key to encrypt a note).
 
-> **NOTE 2**: If a note recipient is one of the accounts inside the Aztec RPC, we don't need to register it as a recipient because we already have the public key available.
+> **NOTE 2**: If a note recipient is one of the accounts inside the PXE, we don't need to register it as a recipient because we already have the public key available.
 
 Once the recipient is registered we can deploy the contract:
 

docs/docs/dev_docs/contracts/syntax/events.md

@@ -15,7 +15,7 @@ Unlike on Ethereum, there are 2 types of events supported by Aztec: encrypted an
 ## Encrypted Events
 
 Encrypted events can only be emitted by private functions and are encrypted using a public key of a recipient.
-For this reason it is necessary to register a recipient in the Aztec RPC Server before encrypting the events for them.
+For this reason it is necessary to register a recipient in the Private Execution Environment (PXE) before encrypting the events for them.
 Recipients can be registered using the Aztec CLI or Aztec.js:
 
 import Tabs from '@theme/Tabs';
@@ -47,18 +47,18 @@ const completeAddress = CompleteAddress.create(
   publicKey,
   partialKey
 );
-await aztecRpc.registerRecipient(completeAddress);
+await pxe.registerRecipient(completeAddress);
 ```
 
 </TabItem>
 </Tabs>
 
 :::info
-If a note recipient is one of the accounts inside the Aztec RPC Server, we don't need to register it as a recipient because we already have the public key available. You can register a recipient as shown [here](../deploying#deploying-private-token-contract)
+If a note recipient is one of the accounts inside the PXE, we don't need to register it as a recipient because we already have the public key available. You can register a recipient as shown [here](../deploying#deploying-private-token-contract)
 
 At this point the Sandbox only enables the emitting of encrypted note preimages through encrypted events.
 In the future we will allow emitting arbitrary information.
-(If you currently emit arbitrary information, Aztec RPC Server will fail to decrypt, process and store this data, so it will not be queryable).
+(If you currently emit arbitrary information, PXE will fail to decrypt, process and store this data, so it will not be queryable).
 :::
 
 To emit encrypted logs first import the `emit_encrypted_log` utility function which wraps an [oracle](./functions.md#oracle-functions):
@@ -71,19 +71,19 @@ Then you can call the function:
 
 ### Processing Encrypted Events
 
-One of the functions of the Aztec RPC Server is constantly loading encrypted logs from the `AztecNode` and decrypting them.
-When new encrypted logs are obtained, the Aztec RPC Server will try to decrypt them using the private encryption key of all the accounts registered inside Aztec RPC Server.
-If the decryption is successful, the Aztec RPC Server will store the decrypted note inside a database.
+One of the functions of the PXE is constantly loading encrypted logs from the `AztecNode` and decrypting them.
+When new encrypted logs are obtained, the PXE will try to decrypt them using the private encryption key of all the accounts registered inside PXE.
+If the decryption is successful, the PXE will store the decrypted note inside a database.
 If the decryption fails, the specific log will be discarded.
 
-For the Aztec RPC Server to successfully process the decrypted note we need to compute the note's 'note hash' and 'nullifier'.
-Aztec.nr enables smart contract developers to design custom notes, meaning developers can also customize how a note's note hash and nullifier should be computed. Because of this customizability, and because there will be a potentially-unlimited number of smart contracts deployed to Aztec, an Aztec RPC Server needs to be 'taught' how to compute the custom note hashes and nullifiers for a particular contract. Therefore, developers will need to implement a `compute_note_hash_and_nullifier` function inside their contracts.
+For the PXE to successfully process the decrypted note we need to compute the note's 'note hash' and 'nullifier'.
+Aztec.nr enables smart contract developers to design custom notes, meaning developers can also customize how a note's note hash and nullifier should be computed. Because of this customizability, and because there will be a potentially-unlimited number of smart contracts deployed to Aztec, an PXE needs to be 'taught' how to compute the custom note hashes and nullifiers for a particular contract. Therefore, developers will need to implement a `compute_note_hash_and_nullifier` function inside their contracts.
 
 :::danger
 If your function has private state variables, you **MUST** include a `compute_note_hash_and_nullifier` function to allow the RPC to process encrypted events.
 :::
 
-Every time a new note is successfully decrypted, the Aztec RPC Server will expect the existence of a `compute_note_hash_and_nullifier` function, which must teach it how to correctly process the new note.
+Every time a new note is successfully decrypted, the PXE will expect the existence of a `compute_note_hash_and_nullifier` function, which must teach it how to correctly process the new note.
 
 #include_code compute_note_hash_and_nullifier /yarn-project/noir-contracts/src/contracts/token_contract/src/main.nr rust