refactor: renaming abi as artifact (#2756)

Fixes #2101

Note: In some places it made sense to use the ABI term because it really
referred to what ABI means in the Ethereum world (function name, args,
return types and no bytecode and verification key). Given this I renamed
`FunctionAbiHeader` as `FunctionAbi` and what was `FunctionAbi` is now
`FunctionArtifact`.

docs/docs/about_aztec/roadmap/features_initial_ldt.md

@@ -52,7 +52,7 @@ A typescript wrapper for making RPC calls to an Aztec Sandbox node. See the sour
 
 - 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 Aztec.nr contract's JSON ABI.
+- Construct `Contract` instances from a Aztec.nr contract's JSON artifact.
 - Deploy new contracts to the Aztec Sandbox.
 - Construct tx requests, passing arguments to a function of a contract.
 - Sign tx requests.

docs/docs/concepts/advanced/contract_creation.md

@@ -40,7 +40,7 @@ Each contract's function data is stored in a Merkle tree, where each leaf contai
 
 ### How are function signatures defined?
 
-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).
+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 artifact, TBD).
 
 ## Contract Representation in Aztec
 
@@ -284,7 +284,7 @@ The set of functions of a contract is represented as a mini Merkle tree of verif
 - Distributing L2 contract data
 - Linking to an L1 Portal Contract
 
-These topics are reflected in the layout of the contract deployment ABI:
+These topics are reflected in the layout of the contract deployment artifact:
 
 ```js
 publicInputs = {

docs/docs/dev_docs/cli/main.md

@@ -52,7 +52,7 @@ We have shipped a number of example contracts in the `@aztec/noir-contracts` npm
 
 You can see all of our example contracts in the monorepo [here](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/noir-contracts/src/contracts).
 
-In the following sections there will be commands that require contracts as options. You can either specify the full directory path to the contract abi, or you can use the name of one of these examples as the option value. This will become clearer later on.
+In the following sections there will be commands that require contracts as options. You can either specify the full directory path to the contract artifact, or you can use the name of one of these examples as the option value. This will become clearer later on.
 
 ## Creating Accounts
 
@@ -101,7 +101,7 @@ export CONTRACT_ADDRESS=<Your new contract address>
 If you use a different address in the constructor above, you will get an error when running the deployment. This is because you need to register an account in the sandbox before it can receive private notes. When you create a new account, it gets automatically registered. Alternatively, you can register an account you do not own along with its public key using the `register-recipient` command.
 :::
 
-This command takes 1 mandatory positional argument which is the path to the contract ABI file in a JSON format (e.g. `contracts/target/PrivateToken.json`).
+This command takes 1 mandatory positional argument which is the path to the contract artifact file in a JSON format (e.g. `contracts/target/PrivateToken.json`).
 Alternatively you can pass the name of an example contract as exported by `@aztec/noir-contracts` (run `aztec-cli example-contracts` to see the full list of contracts available).
 
 The command takes a few optional arguments while the most important one is:
@@ -121,7 +121,7 @@ When we deployed the token contract, an initial supply of tokens was minted to t
 The `call` command calls a read-only method on a contract, one that will not generate a transaction to be sent to the network. The arguments here are:
 
 - `--args` - The address for which we want to retrieve the balance.
-- `--contract-abi` - The abi of the contract we are calling.
+- `--contract-artifact` - The artifact 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 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).
@@ -135,7 +135,7 @@ We can now send a transaction to the network. We will transfer funds from the ow
 We called the `transfer` function of the contract and provided these arguments:
 
 - `--args` - The list of arguments to the function call.
-- `--contract-abi` - The abi of the contract to call.
+- `--contract-artifact` - The artifact of the contract to call.
 - `--contract-address` - The deployed address of the contract to call.
 - `--private-key` - The private key of the sender
 

docs/docs/dev_docs/contracts/compiling.md

@@ -28,11 +28,11 @@ Then run the `compile` command with the path to your [contract project folder](.
 aztec-cli compile ./path/to/my_aztec_contract_project
 ```
 
-This will output a JSON [artifact](./artifacts.md) for each contract in the project to a `target` folder containing their ABI, which you can use for deploying or interacting with your contracts.
+This will output a JSON [artifact](./artifacts.md) for each contract in the project to a `target` folder containing their artifact, which you can use for deploying or interacting with your contracts.
 
 ### Typescript Interfaces
 
-You can use the compiler to autogenerate type-safe typescript classes for each of your contracts. These classes define type-safe methods for deploying and interacting with your contract based on their ABI.
+You can use the compiler to autogenerate type-safe typescript classes for each of your contracts. These classes define type-safe methods for deploying and interacting with your contract based on their artifact.
 
 To generate them, include a `--typescript` option in the compile command with a path to the target folder for the typescript files:
 
@@ -77,7 +77,7 @@ Read more about interacting with contracts using `aztec.js` [here](../getting_st
 
 An Aztec.nr contract can [call a function](./syntax/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 make this easier, the compiler can generate contract interface structs that expose a convenience method for each function listed in a given contract artifact. 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 Aztec.nr interface files:
 
@@ -140,8 +140,8 @@ You can also programmatically access the compiler via the `@aztec/noir-compiler`
 The compiler exposes the following functions:
 
 - `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 Aztec.nr interface struct for the given contract ABI.
+- `generateTypescriptContractInterface`: Generates a typescript class for the given contract artifact.
+- `generateNoirContractInterface`: Generates a Aztec.nr interface struct for the given contract artifact.
 
 ## Next steps
 

docs/docs/dev_docs/contracts/deploying.md

@@ -19,7 +19,7 @@ import TabItem from '@theme/TabItem';
 <TabItem value="cli" label="Aztec CLI">
 
 ```bash
-aztec-cli deploy /path/to/contract/abi.json
+aztec-cli deploy /path/to/contract/artifact.json
 ```
 
 </TabItem>
@@ -31,7 +31,7 @@ Pre-requisite - Generate type-safe typescript classes for your contract when com
 import { readFileSync, writeFileSync } from 'fs';
 import { compileUsingNargo, generateTypescriptContractInterface} from '@aztec/noir-compiler';
 
-const compiled: ContractAbi[] = await compileUsingNargo(projectPathToContractFolder);
+const compiled: ContractArtifact[] = await compileUsingNargo(projectPathToContractFolder);
 const abiImportPath = "../target/Example.json";
 writeFileSync(tsInterfaceDestFilePath, generateTypescriptContractInterface(compiled[0], abiImportPath));
 ```
@@ -54,7 +54,7 @@ There are several optional arguments that can be passed:
 <Tabs groupId="deployment-methods">
 <TabItem value="cli" label="Aztec CLI">
 
-`aztec-cli deploy` takes 1 mandatory argument which is the path to the contract ABI file in a JSON format (e.g. `contracts/target/PrivateToken.json`). Alternatively you can pass the name of an example contract as exported by `@aztec/noir-contracts` (run `aztec-cli example-contracts` to see the full list of contracts available).
+`aztec-cli deploy` takes 1 mandatory argument which is the path to the contract artifact file in a JSON format (e.g. `contracts/target/PrivateToken.json`). Alternatively you can pass the name of an example contract as exported by `@aztec/noir-contracts` (run `aztec-cli example-contracts` to see the full list of contracts available).
 
 The command also takes the following optional arguments:
 - `-args <constructorArgs...>` (default: `[]`): Arguments to pass to the contract constructor.
@@ -128,7 +128,7 @@ Once the recipient is registered we can deploy the contract:
 <TabItem value="cli" label="Aztec CLI">
 
 ```bash
-aztec-cli deploy PrivateTokenContractAbi --args 1000 0x147392a39e593189902458f4303bc6e0a39128c5a1c1612f76527a162d36d529
+aztec-cli deploy PrivateTokenContractArtifact --args 1000 0x147392a39e593189902458f4303bc6e0a39128c5a1c1612f76527a162d36d529
 ```
 
 </TabItem>
@@ -154,7 +154,7 @@ If we pass the salt as an argument:
 <TabItem value="cli" label="Aztec CLI">
 
 ```bash
-aztec-cli deploy PrivateTokenContractAbi --args 1000 0x147392a39e593189902458f4303bc6e0a39128c5a1c1612f76527a162d36d529 --salt 0x123
+aztec-cli deploy PrivateTokenContractArtifact --args 1000 0x147392a39e593189902458f4303bc6e0a39128c5a1c1612f76527a162d36d529 --salt 0x123
 ```
 
 </TabItem>

docs/docs/dev_docs/tutorials/writing_dapp/contract_deployment.md

@@ -64,7 +64,7 @@ Create a new file `src/deploy.mjs`:
 // src/deploy.mjs
 import { writeFileSync } from 'fs';
 import { Contract, ContractDeployer, createPXEClient, getSandboxAccountsWallets } from '@aztec/aztec.js';
-import TokenContractAbi from "../contracts/token/target/Token.json" assert { type: "json" };
+import TokenContractArtifact from "../contracts/token/target/Token.json" assert { type: "json" };
 
 #include_code dapp-deploy yarn-project/end-to-end/src/sample-dapp/deploy.mjs raw
 

docs/docs/dev_docs/tutorials/writing_dapp/contract_interaction.md

@@ -18,7 +18,7 @@ To do this, let's first initialize a new `Contract` instance using `aztec.js` th
 // src/contracts.mjs
 import { Contract } from "@aztec/aztec.js";
 import { readFileSync } from "fs";
-import TokenContractAbi from "../contracts/token/target/Token.json" assert { type: "json" };
+import TokenContractArtifact from "../contracts/token/target/Token.json" assert { type: "json" };
 ```
 
 And then add the following code for initialising the `Contract` instances:

docs/docs/dev_docs/tutorials/writing_dapp/testing.md

@@ -27,7 +27,7 @@ Create a new file `src/index.test.mjs` with the imports we'll be using and an em
 ```js
 import { createSandbox } from "@aztec/aztec-sandbox";
 import { Contract, createAccount } from "@aztec/aztec.js";
-import TokenContractAbi from "../contracts/token/target/Token.json" assert { type: "json" };
+import TokenContractArtifact from "../contracts/token/target/Token.json" assert { type: "json" };
 
 describe("token", () => {});
 ```

docs/internal_notes/dev_docs/sandbox/components.md

@@ -89,9 +89,9 @@ Responsibilities:
 These tasks are lower priority than providing a handcrafted ABI.
 
 - The ability for a dev to enclose a collection of Aztec.nr functions in a 'contract scope'.
-- The ability to create an Aztec.nr contract abi from the above.
+- The ability to create an Aztec.nr contract artifact from the above.
 
-Design an Aztec.nr Contract ABI, similar to a Solidity ABI which is output by Solc (see [here](https://docs.soliditylang.org/en/v0.8.13/abi-spec.html#json)). It might include for each function:
+Design an Aztec.nr contract artifact, similar to a Solidity ABI which is output by Solc (see [here](https://docs.soliditylang.org/en/v0.8.13/abi-spec.html#json)). It might include for each function:
 
 - ACIR opcodes (akin to Solidity bytecode).
 - Function name and parameter names & types.
@@ -113,7 +113,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 Aztec keypair. Call `create_account` on Wallet.
-- Create a `Contract` instance (similar to web3.js), given a path to an Aztec.nr Contract ABI.
+- Create a `Contract` instance (similar to web3.js), given a path to an Aztec.nr contract artifact.
 - Construct `tx_request` by calling e.g. `contract.get_deployment_request(constructor_args)`.
 - Call wallet `sign_tx_request(tx_request)` to get signature.
 - Call `simulate_tx(signed_tx_request)` on the Private Client. In future this would help compute gas, for now we won't actually return gas (it's hard). Returns success or failure, so client knows if it should proceed, and computed kernel circuit public outputs.