From 34088a83d7c5781d0471d3a5fa80d9468289b598 Mon Sep 17 00:00:00 2001 From: signorecello Date: Mon, 20 May 2024 15:26:28 +0000 Subject: [PATCH] modifying the rest of the links, they should be all relative now --- .../aztecjs-getting-started.md | 8 ++++---- .../aztecnr-getting-started.md | 8 ++++---- docs/docs/guides/js_apps/deploy_contract.md | 4 ++-- docs/docs/guides/js_apps/test_contracts.md | 16 ++++++++-------- .../local_env/creating_schnorr_accounts.md | 6 +++--- .../run_more_than_one_pxe_sandbox.md | 2 +- .../guides/local_env/versions-updating.md | 4 ++-- .../how_to_compile_contract.md | 10 +++++----- .../smart_contracts/how_to_deploy_contract.md | 10 +++++----- .../writing_contracts/call_functions.md | 4 ++-- .../common_patterns/authwit.md | 2 +- .../common_patterns/index.md | 12 ++++++------ .../writing_contracts/how_to_emit_event.md | 4 ++-- .../writing_contracts/how_to_prove_history.md | 8 ++++---- .../writing_contracts/index.md | 2 +- .../writing_contracts/initializers.md | 2 +- .../portals/communicate_with_portal.md | 6 +++--- .../portals/deploy_with_portal.md | 2 +- .../writing_contracts/portals/index.md | 2 +- .../writing_contracts/storage/index.md | 4 ++-- .../writing_contracts/storage/notes.md | 14 +++++++------- .../storage/storage_slots.md | 2 +- .../cryptography/hashing/hashing.md | 6 +++--- .../state/tree-implementations.md | 2 +- .../reference/common_errors/aztecnr-errors.md | 6 +++--- .../reference/common_errors/sandbox-errors.md | 12 ++++++------ docs/docs/reference/privacy_considerations.md | 2 +- .../docs/reference/sandbox_reference/index.md | 4 ++-- .../sandbox_reference/sandbox-reference.md | 8 ++++---- .../smart_contract_reference/dependencies.md | 2 +- .../history_lib_reference.md | 2 +- .../smart_contract_reference/storage/index.md | 16 ++++++++-------- .../storage/private_state.md | 14 +++++++------- .../storage/public_state.md | 6 +++--- .../advanced/token_bridge/index.md | 6 +++--- .../advanced/token_bridge/minting_on_aztec.md | 2 +- .../advanced/token_bridge/setup.md | 2 +- .../token_bridge/withdrawing_to_l1.md | 4 ++-- .../crowdfunding_contract.md | 4 ++-- .../private_voting_contract.md | 16 ++++++++-------- .../contract_tutorials/token_contract.md | 14 +++++++------- .../simple_dapp/contract_deployment.md | 4 ++-- .../simple_dapp/contract_interaction.md | 6 +++--- docs/docs/tutorials/simple_dapp/index.md | 6 +++--- .../docs/tutorials/simple_dapp/pxe_service.md | 2 +- docs/docs/tutorials/simple_dapp/testing.md | 4 ++-- .../docs/tutorials/write_accounts_contract.md | 14 +++++++------- docs/scripts/rewrite_paths.js | 19 ++++++++++++++----- 48 files changed, 162 insertions(+), 153 deletions(-) diff --git a/docs/docs/getting_started/aztecjs-getting-started.md b/docs/docs/getting_started/aztecjs-getting-started.md index 88cf9c2210f6..7d435faae956 100644 --- a/docs/docs/getting_started/aztecjs-getting-started.md +++ b/docs/docs/getting_started/aztecjs-getting-started.md @@ -146,9 +146,9 @@ The sandbox is preloaded with multiple accounts so you don't have to sit and cre #include_code load_accounts /yarn-project/end-to-end/src/composed/e2e_sandbox_example.test.ts typescript -An explanation on accounts on Aztec can be found [here](/aztec/concepts/index.md). +An explanation on accounts on Aztec can be found [here](../aztec/concepts/index.md). -If you want more accounts, you can find instructions in the [Account creation section](/guides/local_env/creating_schnorr_accounts). +If you want more accounts, you can find instructions in the [Account creation section](../guides/local_env/creating_schnorr_accounts.md). ## Deploy a contract @@ -256,7 +256,7 @@ Now lets transfer some funds from Alice to Bob by calling the `transfer` functio 1. The sender. 2. The recipient. 3. The quantity of tokens to be transferred. -4. The nonce for the [authentication witness](/aztec/concepts/index.md#authorizing-actions), or 0 if msg.sender equal sender. +4. The nonce for the [authentication witness](../aztec/concepts/index.md#authorizing-actions), or 0 if msg.sender equal sender. Here is the Typescript code to call the `transfer` function, add this to your `index.ts` at the bottom of the `main` function: @@ -353,7 +353,7 @@ Our complete output should now be something like: token Bob's balance 10543 +43ms ``` -That's it! We have successfully deployed a token contract to an instance of the Aztec network and mined private state-transitioning transactions. We have also queried the resulting state all via the interfaces provided by the contract. To see exactly what has happened here, you can learn about the transaction flow [here](/aztec/concepts/transactions). +That's it! We have successfully deployed a token contract to an instance of the Aztec network and mined private state-transitioning transactions. We have also queried the resulting state all via the interfaces provided by the contract. To see exactly what has happened here, you can learn about the transaction flow [here](../aztec/concepts/transactions.md). ## Next Steps diff --git a/docs/docs/getting_started/aztecnr-getting-started.md b/docs/docs/getting_started/aztecnr-getting-started.md index 8e2abeff7b7b..787bb689cb0d 100644 --- a/docs/docs/getting_started/aztecnr-getting-started.md +++ b/docs/docs/getting_started/aztecnr-getting-started.md @@ -5,7 +5,7 @@ sidebar_position: 2 In this guide, we will create our first Aztec.nr smart contract. We will build a simple private counter. This contract will get you started with the basic setup and syntax of Aztec.nr, but doesn't showcase the awesome stuff Aztec is capable of. -If you already have some experience with Noir and want to build a cooler contract that utilizes both private and public state, you might want to check out the [token contract tutorial instead](/tutorials/contract_tutorials/token_contract.md). +If you already have some experience with Noir and want to build a cooler contract that utilizes both private and public state, you might want to check out the [token contract tutorial instead](../tutorials/contract_tutorials/token_contract.md). ## Prerequisites @@ -116,7 +116,7 @@ Let’s create a constructor method to run on deployment that assigns an initial This function accesses the counts from storage. Then it assigns the passed initial counter to the `owner`'s counter privately using `at().add()`. -We have annotated this and other functions with `#[aztec(private)]` which are ABI macros so the compiler understands it will handle private inputs. Learn more about functions and annotations [here](/aztec/concepts/smart_contracts/functions). +We have annotated this and other functions with `#[aztec(private)]` which are ABI macros so the compiler understands it will handle private inputs. Learn more about functions and annotations [here](../aztec/concepts/smart_contracts/functions/index.md). ## Incrementing our counter @@ -181,7 +181,7 @@ Update the `Noir: Nargo Path` field to point to your desired `aztec-nargo` execu The next recommmended steps are follow the tutorials in order. They will teach you more about contracts, Aztec.js, and how Aztec works in general. -To follow the series of tutorials, start with the private voting contract [here](/tutorials/contract_tutorials/private_voting_contract.md). +To follow the series of tutorials, start with the private voting contract [here](../tutorials/contract_tutorials/private_voting_contract.md). -Alternatively, you can read about the high level architecture on the [Core Components page](/aztec/concepts/state_model/index.md) and [the lifecycle of a transaction](/aztec/concepts/transactions). +Alternatively, you can read about the high level architecture on the [Core Components page](../aztec/concepts/state_model/index.md) and [the lifecycle of a transaction](../aztec/concepts/transactions.md). diff --git a/docs/docs/guides/js_apps/deploy_contract.md b/docs/docs/guides/js_apps/deploy_contract.md index 1a5113661854..51ddd83c74eb 100644 --- a/docs/docs/guides/js_apps/deploy_contract.md +++ b/docs/docs/guides/js_apps/deploy_contract.md @@ -10,11 +10,11 @@ You should have a wallet to act as the deployer, and a contract artifact ready t You can learn how to create wallets from [this guide](./create_account.md). -You can read about contract artifacts [here](/aztec/concepts/smart_contracts/contract_structure.md). +You can read about contract artifacts [here](../../aztec/concepts/smart_contracts/contract_structure.md). ## Import the contract artifact -In this guide we are using a Token contract artifact. This comes from the [token contract tutorial](/tutorials/contract_tutorials/token_contract.md). +In this guide we are using a Token contract artifact. This comes from the [token contract tutorial](../../tutorials/contract_tutorials/token_contract.md). #include_code import_token_contract yarn-project/end-to-end/src/composed/docs_examples.test.ts typescript diff --git a/docs/docs/guides/js_apps/test_contracts.md b/docs/docs/guides/js_apps/test_contracts.md index 53a7272335ab..1ad2358fd908 100644 --- a/docs/docs/guides/js_apps/test_contracts.md +++ b/docs/docs/guides/js_apps/test_contracts.md @@ -8,7 +8,7 @@ We will be using typescript to write our tests, and rely on the [`aztec.js`](htt ## A simple example -Let's start with a simple example for a test using the [Sandbox](/reference/sandbox_reference/index.md). We will create two accounts and deploy a token contract in a setup step, and then issue a transfer from one user to another. +Let's start with a simple example for a test using the [Sandbox](../../reference/sandbox_reference/index.md). We will create two accounts and deploy a token contract in a setup step, and then issue a transfer from one user to another. #include_code sandbox-example /yarn-project/end-to-end/src/guides/dapp_testing.test.ts typescript @@ -17,7 +17,7 @@ This test sets up the environment by creating a client to the Private Execution Once we have this setup, the test itself is simple. We check the balance of the `recipient` user to ensure it has no tokens, send and await a deployment transaction, and then check the balance again to ensure it was increased. Note that all numeric values are represented as [native bigints](https://developer.mozilla.org/en-US/docs/Web/JavaScript//reference/Global_Objects/BigInt) to avoid loss of precision. :::info -We are using the `Token` contract's typescript interface. Follow the [typescript interface section](/guides/smart_contracts/how_to_compile_contract.md#typescript-interfaces) to get type-safe methods for deploying and interacting with the token contract. +We are using the `Token` contract's typescript interface. Follow the [typescript interface section](../smart_contracts/how_to_compile_contract.md#typescript-interfaces) to get type-safe methods for deploying and interacting with the token contract. ::: To run the test, first make sure the Sandbox is running on port 8080, and then [run your tests using jest](https://jestjs.io/docs/getting-started#running-from-command-line). Your test should pass, and you should see the following output in the Sandbox logs, where each chunk corresponds to a transaction. Note how this test run has a total of four transactions: two for deploying the account contracts for the `owner` and `recipient`, another for deploying the token contract, and a last one for actually executing the transfer. @@ -92,7 +92,7 @@ If a note doesn't appear when you expect it to, check the visible notes returned If the note appears in the visible notes and it contains the expected values there is probably an issue with how you fetch the notes. Check that the note getter (or note viewer) parameters are set correctly. If the note doesn't appear, ensure that you have emitted the corresponding encrypted log (usually by passing in a `broadcast = true` param to the `create_note` function). You can also check the Sandbox logs to see if the `emitEncryptedLog` was emitted. Run `export DEBUG="aztec:\*" before spinning up sandbox to see all the logs. -For debugging and logging in Aztec contracts, see [this page](/reference/debugging.md). +For debugging and logging in Aztec contracts, see [this page](../../reference/debugging.md). ## Assertions @@ -142,13 +142,13 @@ WARN Error processing tx 06dc87c4d64462916ea58426ffcfaf20017880b353c9ec3e0f0ee5f We can check private or public state directly rather than going through view-only methods, as we did in the initial example by calling `token.methods.balance().simulate()`. Bear in mind that directly accessing contract storage will break any kind of encapsulation. -To query storage directly, you'll need to know the slot you want to access. This can be checked in the [contract's `Storage` definition](/aztec/concepts/storage/index.md) directly for most data types. However, when it comes to mapping types, as in most EVM languages, we'll need to calculate the slot for a given key. To do this, we'll use the [`CheatCodes`](/reference/sandbox_reference/cheat_codes.md) utility class: +To query storage directly, you'll need to know the slot you want to access. This can be checked in the [contract's `Storage` definition](../../aztec/concepts/storage/index.md) directly for most data types. However, when it comes to mapping types, as in most EVM languages, we'll need to calculate the slot for a given key. To do this, we'll use the [`CheatCodes`](../../reference/sandbox_reference/cheat_codes.md) utility class: #include_code calc-slot /yarn-project/end-to-end/src/guides/dapp_testing.test.ts typescript #### Querying private state -Private state in the Aztec Network is represented via sets of [private notes](/aztec/concepts/state_model/index.md#private-state). In our token contract example, the balance of a user is represented as a set of unspent value notes, each with their own corresponding numeric value. +Private state in the Aztec Network is represented via sets of [private notes](../../aztec/concepts/state_model/index.md#private-state). In our token contract example, the balance of a user is represented as a set of unspent value notes, each with their own corresponding numeric value. #include_code value-note-def noir-projects/aztec-nr/value-note/src/value_note.nr rust @@ -158,13 +158,13 @@ We can query the Private eXecution Environment (PXE) for all notes encrypted for #### Querying public state -[Public state](/aztec/concepts/state_model/index.md#public-state) behaves as a key-value store, much like in the EVM. This scenario is much more straightforward, in that we can directly query the target slot and get the result back as a buffer. Note that we use the [`TokenContract`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr) in this example, which defines a mapping of public balances on slot 6. +[Public state](../../aztec/concepts/state_model/index.md#public-state) behaves as a key-value store, much like in the EVM. This scenario is much more straightforward, in that we can directly query the target slot and get the result back as a buffer. Note that we use the [`TokenContract`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr) in this example, which defines a mapping of public balances on slot 6. #include_code public-storage /yarn-project/end-to-end/src/guides/dapp_testing.test.ts typescript ### Logs -Last but not least, we can check the logs of [events](/guides/smart_contracts/writing_contracts/how_to_emit_event) emitted by our contracts. Contracts in Aztec can emit both [encrypted](/guides/smart_contracts/writing_contracts/how_to_emit_event.md#encrypted-events) and [unencrypted](/guides/smart_contracts/writing_contracts/how_to_emit_event.md#unencrypted-events) events. +Last but not least, we can check the logs of [events](../smart_contracts/writing_contracts/how_to_emit_event.md) emitted by our contracts. Contracts in Aztec can emit both [encrypted](../smart_contracts/writing_contracts/how_to_emit_event.md#encrypted-events) and [unencrypted](../smart_contracts/writing_contracts/how_to_emit_event.md#unencrypted-events) events. :::info At the time of this writing, only unencrypted events can be queried directly. Encrypted events are always assumed to be encrypted notes. @@ -178,7 +178,7 @@ We can query the PXE for the unencrypted logs emitted in the block where our tra ## Cheats -The [`CheatCodes`](/reference/sandbox_reference/cheat_codes.md) class, which we used for [calculating the storage slot above](#state), also includes a set of cheat methods for modifying the chain state that can be handy for testing. +The [`CheatCodes`](../../reference/sandbox_reference/cheat_codes.md) class, which we used for [calculating the storage slot above](#state), also includes a set of cheat methods for modifying the chain state that can be handy for testing. ### Set next block timestamp diff --git a/docs/docs/guides/local_env/creating_schnorr_accounts.md b/docs/docs/guides/local_env/creating_schnorr_accounts.md index 51eb3e24a845..954dff409fa5 100644 --- a/docs/docs/guides/local_env/creating_schnorr_accounts.md +++ b/docs/docs/guides/local_env/creating_schnorr_accounts.md @@ -7,14 +7,14 @@ sidebar_position: 1 This section shows how to create schnorr account wallets on the Aztec Sandbox. -An in-depth explaining about accounts on aztec can be found [here](/aztec/concepts/index.md). But creating an account on the Sandbox does 2 things: +An in-depth explaining about accounts on aztec can be found [here](../../aztec/concepts/index.md). But creating an account on the Sandbox does 2 things: 1. Deploys an account contract -- representing you -- allowing you to perform actions on the network (deploy contracts, call functions etc). 2. Adds your encryption keys to the Private eXecution Environment (PXE) allowing it to decrypt and manage your private state. ## Pre-requisites -Have a running Sandbox and a repository that interacts with it as explained [here](/getting_started). +Have a running Sandbox and a repository that interacts with it as explained [here](../../getting_started.md). Let's assume you have a file `src/index.ts` from the example used in the Sandbox page. @@ -61,4 +61,4 @@ Once this has completed, the L2 block is retrieved and pulled down to the PXE so ## Next Steps -Check out our section on [Writing your own Account Contract](/tutorials/write_accounts_contract.md) leveraging our account abstraction +Check out our section on [Writing your own Account Contract](../../tutorials/write_accounts_contract.md) leveraging our account abstraction diff --git a/docs/docs/guides/local_env/run_more_than_one_pxe_sandbox.md b/docs/docs/guides/local_env/run_more_than_one_pxe_sandbox.md index 9081163c7031..40bf431c7e4b 100644 --- a/docs/docs/guides/local_env/run_more_than_one_pxe_sandbox.md +++ b/docs/docs/guides/local_env/run_more_than_one_pxe_sandbox.md @@ -39,6 +39,6 @@ You should see something like this: Aztec Server listening on port 8080 ``` -You can learn more about custom commands in the [sandbox reference](/reference/sandbox_reference/index.md). +You can learn more about custom commands in the [sandbox reference](../../reference/sandbox_reference/index.md). diff --git a/docs/docs/guides/local_env/versions-updating.md b/docs/docs/guides/local_env/versions-updating.md index cb322f82c43b..580c9a3782a3 100644 --- a/docs/docs/guides/local_env/versions-updating.md +++ b/docs/docs/guides/local_env/versions-updating.md @@ -81,11 +81,11 @@ cd your/aztec/project aztec-builder update . --contract src/contract1 --contract src/contract2 ``` -The sandbox must be running for the update command to work. Make sure it is [installed and running](/reference/sandbox_reference/index.md). +The sandbox must be running for the update command to work. Make sure it is [installed and running](../../reference/sandbox_reference/index.md). Follow [updating Aztec.nr packages](#updating-aztecnr-packages) and [updating JavaScript packages](#updating-aztecjs-packages) guides. -3. Refer to [Migration Notes](/migration_notes.md) on any breaking changes that might affect your dapp +3. Refer to [Migration Notes](../../migration_notes.md) on any breaking changes that might affect your dapp --- diff --git a/docs/docs/guides/smart_contracts/how_to_compile_contract.md b/docs/docs/guides/smart_contracts/how_to_compile_contract.md index 944e2dea6ed2..9206dfa69821 100644 --- a/docs/docs/guides/smart_contracts/how_to_compile_contract.md +++ b/docs/docs/guides/smart_contracts/how_to_compile_contract.md @@ -5,7 +5,7 @@ sidebar_position: 3 import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx"; -Once you have written a contract in Aztec.nr, you will need to compile it into an [artifact](/aztec/concepts/smart_contracts/contract_structure.md) in order to use it. +Once you have written a contract in Aztec.nr, you will need to compile it into an [artifact](../../aztec/concepts/smart_contracts/contract_structure.md) in order to use it. In this guide we will cover how to do so, both using the `aztec-nargo` command and programmatically. @@ -21,7 +21,7 @@ Run the `aztec-nargo compile` command within your contract project folder (the o aztec-nargo compile ``` -This will output a JSON [artifact](/aztec/concepts/smart_contracts/contract_structure.md) for each contract in the project to a `target` folder containing the Noir ABI artifacts. +This will output a JSON [artifact](../../aztec/concepts/smart_contracts/contract_structure.md) for each contract in the project to a `target` folder containing the Noir ABI artifacts. :::note This command looks for `Nargo.toml` files by ascending up the parent directories, and will compile the top-most Nargo.toml file it finds. @@ -222,11 +222,11 @@ export class TokenContract extends ContractBase { } ``` -Read more about interacting with contracts using `aztec.js` [here](/getting_started/aztecjs-getting-started.md). +Read more about interacting with contracts using `aztec.js` [here](../../getting_started/aztecjs-getting-started.md). ### Aztec.nr interfaces -An Aztec.nr contract can [call a function](/guides/smart_contracts/writing_contracts/call_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 serializing the arguments, which is not type-safe. +An Aztec.nr contract can [call a function](writing_contracts/call_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 serializing the arguments, which is not type-safe. To make this easier, the compiler automatically generates 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. @@ -260,7 +260,7 @@ contract FPC { } ``` -Read more about how to use the Aztec.nr interfaces [here](/aztec/concepts/smart_contracts/functions). +Read more about how to use the Aztec.nr interfaces [here](../../aztec/concepts/smart_contracts/functions/index.md). :::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. diff --git a/docs/docs/guides/smart_contracts/how_to_deploy_contract.md b/docs/docs/guides/smart_contracts/how_to_deploy_contract.md index f9c2f851814d..bb4ca2a74fd1 100644 --- a/docs/docs/guides/smart_contracts/how_to_deploy_contract.md +++ b/docs/docs/guides/smart_contracts/how_to_deploy_contract.md @@ -5,13 +5,13 @@ sidebar_position: 4 # Deploying contracts -Once you have [compiled](/guides/smart_contracts/how_to_compile_contract) your contracts you can proceed to deploying them using aztec.js which is a Typescript client to interact with the sandbox. +Once you have [compiled](how_to_compile_contract.md) your contracts you can proceed to deploying them using aztec.js which is a Typescript client to interact with the sandbox. ## Prerequisites -- `aztec-nargo` installed (go to [Sandbox and CLI section](/reference/sandbox_reference) for installation instructions) -- contract artifacts ready (go to [How to Compile Contract](/guides/smart_contracts/how_to_compile_contract) for instructions on how to compile contracts) -- Aztec Sandbox running (go to [Sandbox section](/getting_started) for instructions on how to install and run the sandbox) +- `aztec-nargo` installed (go to [Sandbox and CLI section](../../reference/sandbox_reference/index.md) for installation instructions) +- contract artifacts ready (go to [How to Compile Contract](how_to_compile_contract.md) for instructions on how to compile contracts) +- Aztec Sandbox running (go to [Sandbox section](../../getting_started.md) for instructions on how to install and run the sandbox) ## Deploy @@ -29,7 +29,7 @@ Generate the typescript class: aztec-builder ./aztec-nargo/output/target/path -o src/artifacts ``` -This would create a typescript file like `Example.ts` in `./src/artifacts`. Read more on the [compiling page](/guides/smart_contracts/how_to_compile_contract). +This would create a typescript file like `Example.ts` in `./src/artifacts`. Read more on the [compiling page](how_to_compile_contract.md). Now you can import it to easily deploy and interact with the contract. diff --git a/docs/docs/guides/smart_contracts/writing_contracts/call_functions.md b/docs/docs/guides/smart_contracts/writing_contracts/call_functions.md index c026447e3dd8..f649f4f8d8eb 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/call_functions.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/call_functions.md @@ -4,7 +4,7 @@ sidebar_position: 2 --- -A contract is a collection of persistent [state variables](/aztec/concepts/storage/index.md), and [functions](/aztec/concepts/smart_contracts/functions) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called. +A contract is a collection of persistent [state variables](../../../aztec/concepts/storage/index.md), and [functions](../../../aztec/concepts/smart_contracts/functions/index.md) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called. ### Contract @@ -37,4 +37,4 @@ Here's a common layout for a basic Aztec.nr Contract project: ``` - See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages). -- You can review the structure of a complete contract in the token contract tutorial [here](/tutorials/contract_tutorials/token_contract.md). +- You can review the structure of a complete contract in the token contract tutorial [here](../../../tutorials/contract_tutorials/token_contract.md). diff --git a/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/authwit.md b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/authwit.md index 9a31c6de1a57..fc3af290b511 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/authwit.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/authwit.md @@ -82,7 +82,7 @@ Both return the value `0xabf64ad4` (`IS_VALID` selector) for a successful authen As part of [Aztec.nr](https://aztec.nr), we are providing a library that can be used to implement authentication witness for your contracts. -This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](/tutorials/write_accounts_contract.md). +This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](../../../../tutorials/write_accounts_contract.md). For our purposes here (not building a wallet), the most important part of the library is the `auth` utility which exposes a couple of helper methods for computing the action hash, retrieving witnesses, validating them and emitting the nullifier. diff --git a/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/index.md b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/index.md index 704908911974..450dd0773d69 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/index.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/index.md @@ -40,7 +40,7 @@ Note - you could also create a note and send it to the user. The problem is ther You can't read public storage in private domain. But nevertheless reading public storage is desirable. There are two ways to achieve the desired effect: -1. For public values that change infrequently, you can use [shared state](/reference/smart_contract_reference/storage/shared_state.md). +1. For public values that change infrequently, you can use [shared state](../../../../reference/smart_contract_reference/storage/shared_state.md). 1. You pass the data as a parameter to your private method and later assert in public that the data is correct. E.g.: @@ -82,13 +82,13 @@ Let's say you have some storage in public and want to move them into the private So you have to create a custom note in the public domain that is not encrypted by some owner - we call such notes a "TransparentNote" since it is created in public, anyone can see the amount and the note is not encrypted by some owner. -This pattern is discussed in detail in [writing a token contract section in the shield() method](/tutorials/contract_tutorials/token_contract.md#redeem_shield). +This pattern is discussed in detail in [writing a token contract section in the shield() method](../../../../tutorials/contract_tutorials/token_contract.md#redeem_shield). ### Discovering my notes -When you send someone a note, the note hash gets added to the [note hash tree](/aztec/concepts/storage/trees/index.md#note-hash-tree). To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes: +When you send someone a note, the note hash gets added to the [note hash tree](../../../../aztec/concepts/storage/trees/index.md#note-hash-tree). To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes: -1. When sending someone a note, use `emit_encrypted_log` (the function encrypts the log in such a way that only a recipient can decrypt it). PXE then tries to decrypt all the encrypted logs, and stores the successfully decrypted one. [More info here](/guides/smart_contracts/writing_contracts/how_to_emit_event) +1. When sending someone a note, use `emit_encrypted_log` (the function encrypts the log in such a way that only a recipient can decrypt it). PXE then tries to decrypt all the encrypted logs, and stores the successfully decrypted one. [More info here](../how_to_emit_event.md) 2. Manually using `pxe.addNote()` - If you choose to not emit logs to save gas or when creating a note in the public domain and want to consume it in private domain (`emit_encrypted_log` shouldn't be called in the public domain because everything is public), like in the previous section where we created a TransparentNote in public. #include_code pxe_add_note yarn-project/end-to-end/src/e2e_cheat_codes.test.ts typescript @@ -115,7 +115,7 @@ Hence, it's necessary to add a "randomness" field to your note to prevent such a ### L1 -- L2 interactions -Refer to [Token Portal tutorial on bridging tokens between L1 and L2](/tutorials/contract_tutorials/advanced/token_bridge). This example shows how to: +Refer to [Token Portal tutorial on bridging tokens between L1 and L2](../../../../tutorials/contract_tutorials/advanced/token_bridge/index.md). This example shows how to: 1. L1 -> L2 message flow 2. L2 -> L1 message flow @@ -151,6 +151,6 @@ PS: when calling from private to public, `msg_sender` is the contract address wh In the [Prevent the same user flow from happening twice using nullifier](#prevent-the-same-user-flow-from-happening-twice-using-nullifiers), we recommended using nullifiers. But what you put in the nullifier is also as important. -E.g. for a voting contract, if your nullifier simply emits just the `user_address`, then privacy can easily be leaked as nullifiers are deterministic (have no randomness), especially if there are few users of the contract. So you need some kind of randomness. You can add the user's secret key into the nullifier to add randomness. We call this "nullifier secrets" as explained [here](/aztec/concepts/accounts/keys.md#nullifier-secrets). E.g.: +E.g. for a voting contract, if your nullifier simply emits just the `user_address`, then privacy can easily be leaked as nullifiers are deterministic (have no randomness), especially if there are few users of the contract. So you need some kind of randomness. You can add the user's secret key into the nullifier to add randomness. We call this "nullifier secrets" as explained [here](../../../../aztec/concepts/accounts/keys.md#nullifier-secrets). E.g.: #include_code nullifier /noir-projects/aztec-nr/value-note/src/value_note.nr rust diff --git a/docs/docs/guides/smart_contracts/writing_contracts/how_to_emit_event.md b/docs/docs/guides/smart_contracts/writing_contracts/how_to_emit_event.md index bd8f362bc8c5..a5aeab71ab3d 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/how_to_emit_event.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/how_to_emit_event.md @@ -25,7 +25,7 @@ Bellow are some ways how we could instantiate it after getting the information i #include_code instantiate-complete-address /yarn-project/circuits.js/src/structs/complete_address.test.ts rust -Then to register the recipient's [complete address](/aztec/concepts/accounts/keys.md#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](/aztec/core_components.md#aztecjs): +Then to register the recipient's [complete address](../../../aztec/concepts/accounts/keys.md#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](../../../aztec/core_components.md#aztecjs): #include_code register-recipient /yarn-project/aztec.js/src/wallet/create_recipient.ts rust @@ -60,7 +60,7 @@ They can be emitted by both public and private functions. :::danger - Emitting unencrypted events from private function is a significant privacy leak and it should be considered by the developer whether it is acceptable. -- Unencrypted events are currently **NOT** linked to the contract emitting them, so it is practically a [`debug_log`](/aztec/concepts/smart_contracts/oracles/index.md#a-few-useful-inbuilt-oracles). +- Unencrypted events are currently **NOT** linked to the contract emitting them, so it is practically a [`debug_log`](../../../aztec/concepts/smart_contracts/oracles/index.md#a-few-useful-inbuilt-oracles). ::: diff --git a/docs/docs/guides/smart_contracts/writing_contracts/how_to_prove_history.md b/docs/docs/guides/smart_contracts/writing_contracts/how_to_prove_history.md index c6fbd2c2e162..a40a7a9cbe55 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/how_to_prove_history.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/how_to_prove_history.md @@ -3,9 +3,9 @@ title: Using the Archive Tree sidebar_position: 4 --- -The Aztec Protocol uses an append-only Merkle tree to store hashes of the headers of all previous blocks in the chain as its leaves. This is known as an archive tree. You can learn more about how it works in the [concepts section](/aztec/concepts/storage/trees/index.md#archive-tree). +The Aztec Protocol uses an append-only Merkle tree to store hashes of the headers of all previous blocks in the chain as its leaves. This is known as an archive tree. You can learn more about how it works in the [concepts section](../../../aztec/concepts/storage/trees/index.md#archive-tree). -View the History lib reference [here](/reference/smart_contract_reference/history_lib_reference.md). +View the History lib reference [here](../../../reference/smart_contract_reference/history_lib_reference.md). # History library @@ -30,7 +30,7 @@ Using this library, you can check that specific notes or nullifiers were part of - Prove a note was included in a specified block - Create a nullifier and prove it was not included in a specified block -For a more extensive reference, go to [the reference page](/reference/smart_contract_reference/history_lib_reference.md). +For a more extensive reference, go to [the reference page](../../../reference/smart_contract_reference/history_lib_reference.md). ## 1. Import the `history` library from `aztec` @@ -98,4 +98,4 @@ You can also prove that a nullifier was not included in a specified block by usi ## Prove contract inclusion, public value inclusion, and use current state in lookups -To see what else you can do with the `history` library, check out the [reference](/reference/smart_contract_reference/history_lib_reference.md). +To see what else you can do with the `history` library, check out the [reference](../../../reference/smart_contract_reference/history_lib_reference.md). diff --git a/docs/docs/guides/smart_contracts/writing_contracts/index.md b/docs/docs/guides/smart_contracts/writing_contracts/index.md index 2c857ff0af33..4271c4e0441a 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/index.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/index.md @@ -4,4 +4,4 @@ title: Portals A portal is a point of contact between L1 and a contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2. -As outlined in [Communication](/protocol-specs/l1-smart-contracts/index.md), an Aztec L2 contract does not have to be linked to a portal contract, but can specify an intended portal in storage. Note, that a portal doesn't actually need to be a contract, it could be any address on L1. +As outlined in [Communication](../../../protocol-specs/l1-smart-contracts/index.md), an Aztec L2 contract does not have to be linked to a portal contract, but can specify an intended portal in storage. Note, that a portal doesn't actually need to be a contract, it could be any address on L1. diff --git a/docs/docs/guides/smart_contracts/writing_contracts/initializers.md b/docs/docs/guides/smart_contracts/writing_contracts/initializers.md index 3c0194132e2f..7428af87fbf3 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/initializers.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/initializers.md @@ -27,4 +27,4 @@ Initializers are commonly used to set an admin, such as this example: Here, the initializer is calling a public function. It can also call a private function. Learn more about calling functions from functions [here](./call_functions.md). -To see constructors in action, check out the [Aztec.nr getting started guide](/getting_started/aztecnr-getting-started.md). +To see constructors in action, check out the [Aztec.nr getting started guide](../../../getting_started/aztecnr-getting-started.md). diff --git a/docs/docs/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md b/docs/docs/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md index a62981bc9153..7e75a04c9980 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md @@ -2,9 +2,9 @@ title: Communicating with L1 --- -Is this your first time hearing the word `Portal`? Check out the [concepts section](/aztec/concepts/smart_contracts/communication/cross_chain_calls). +Is this your first time hearing the word `Portal`? Check out the [concepts section](../../../../aztec/concepts/smart_contracts/communication/cross_chain_calls.md). -Follow the [token bridge tutorial](/tutorials/contract_tutorials/advanced/token_bridge) for hands-on experience writing and deploying a Portal contract. +Follow the [token bridge tutorial](../../../../tutorials/contract_tutorials/advanced/token_bridge/index.md) for hands-on experience writing and deploying a Portal contract. ## Passing data to the rollup @@ -42,7 +42,7 @@ Note that while the `secret` and the `content` are both hashed, they are actuall ### Token bridge example -Computing the `content` must currently be done manually, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example](/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md#consume-the-l1-message). +Computing the `content` must currently be done manually, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example](../../../../tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md#consume-the-l1-message). #include_code claim_public /noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr rust diff --git a/docs/docs/guides/smart_contracts/writing_contracts/portals/deploy_with_portal.md b/docs/docs/guides/smart_contracts/writing_contracts/portals/deploy_with_portal.md index cd963a809cc1..2b5694f76ba1 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/portals/deploy_with_portal.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/portals/deploy_with_portal.md @@ -9,4 +9,4 @@ title: How to deploy a contract with a Portal ``` - Initialize l1 with l2 address for access control. -Follow the [token bridge tutorial](/tutorials/contract_tutorials/advanced/token_bridge) for hands-on experience writing and deploying a Portal contract. +Follow the [token bridge tutorial](../../../../tutorials/contract_tutorials/advanced/token_bridge/index.md) for hands-on experience writing and deploying a Portal contract. diff --git a/docs/docs/guides/smart_contracts/writing_contracts/portals/index.md b/docs/docs/guides/smart_contracts/writing_contracts/portals/index.md index 7d8bddc747bb..ee850ae8ff18 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/portals/index.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/portals/index.md @@ -4,4 +4,4 @@ title: Portals A portal is a point of contact between L1 and a contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2. -As outlined in [Communication](/aztec/concepts/smart_contracts/communication/cross_chain_calls), an Aztec L2 contract is linked to _ONE_ L1 address at time of deployment (specified by the developer). This L1 address is the only address that can send messages to that specific L2 contract, and the only address that can receive messages sent from the L2 contract to L1. Note, that a portal doesn't actually need to be a contract, it could be any address on L1. +As outlined in [Communication](../../../../aztec/concepts/smart_contracts/communication/cross_chain_calls.md), an Aztec L2 contract is linked to _ONE_ L1 address at time of deployment (specified by the developer). This L1 address is the only address that can send messages to that specific L2 contract, and the only address that can receive messages sent from the L2 contract to L1. Note, that a portal doesn't actually need to be a contract, it could be any address on L1. diff --git a/docs/docs/guides/smart_contracts/writing_contracts/storage/index.md b/docs/docs/guides/smart_contracts/writing_contracts/storage/index.md index 7198612356df..2576fb45f459 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/storage/index.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/storage/index.md @@ -4,9 +4,9 @@ title: Defining Storage On this page, you will learn how to define storage in your smart contract. -To learn more about how storage works in Aztec, read [the concepts](/guides/smart_contracts/writing_contracts/storage/storage_slots). +To learn more about how storage works in Aztec, read [the concepts](storage_slots.md). -[See the storage reference](/aztec/concepts/storage/index.md). +[See the storage reference](../../../../aztec/concepts/storage/index.md). ```rust #[aztec(storage)] diff --git a/docs/docs/guides/smart_contracts/writing_contracts/storage/notes.md b/docs/docs/guides/smart_contracts/writing_contracts/storage/notes.md index 41f939393834..b6dbfc3eb4b7 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/storage/notes.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/storage/notes.md @@ -19,7 +19,7 @@ This page will focus on how private variables are implemented with Notes and sto #### Side-note about execution Under the hood, the Aztec protocol handles some important details around public and private function calls. Calls between them are asynchronous due to different execution contexts (local execution vs. node execution). -A detailed explanation of the transaction lifecycle can be found [here](/aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle). +A detailed explanation of the transaction lifecycle can be found [here](../../../../aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle). ## Private state variables in Aztec State variables in an Aztec contract are defined inside a struct specifically named `Storage`, and must satisfy the [Note Interface](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/aztec-nr/aztec/src/note/note_interface.nr) and contain a [Note header](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/aztec-nr/aztec/src/note/note_header.nr). @@ -29,7 +29,7 @@ The Note header struct contains the contract address which the value is effectiv A couple of things to unpack here: #### Storage "slot" -Storage slots are more literal for public storage, a place where a value is stored. For private storage, a storage slot is logical (more [here](/aztec/concepts/storage/index.md#private-state-slots---slots-arent-real)). +Storage slots are more literal for public storage, a place where a value is stored. For private storage, a storage slot is logical (more [here](../../../../aztec/concepts/storage/index.md#private-state-slots---slots-arent-real)). #### Silos The address of the contract is included in a Note's data to ensure that different contracts don't arrive at the same hash with an identical variable. This is handled in the protocol's execution. @@ -69,9 +69,9 @@ To update a value, its previous note hash(es) are nullified. The new note value ## Supplementary components Some optional background resources on notes can be found here: -- [High level network architecture](/aztec/core_components.md#high-level-network-architecture), specifically the Private Execution Environment -- [Transaction lifecycle (simple diagram)](/aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle) -- [Public and Private state](/aztec/concepts/state_model) +- [High level network architecture](../../../../aztec/core_components.md#high-level-network-architecture), specifically the Private Execution Environment +- [Transaction lifecycle (simple diagram)](../../../../aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle) +- [Public and Private state](../../../../aztec/concepts/state_model/index.md) Notes touch several core components of the protocol, but we will focus on a the essentials first. @@ -126,10 +126,10 @@ Notice how the `add` function shows the simplicity of appending a new note to al ----- ### Apply -Try the [Token tutorial](/tutorials/contract_tutorials/token_contract.md) to see what notes can achieve. In this section you will also find other tutorials using notes in different ways. +Try the [Token tutorial](../../../../tutorials/contract_tutorials/token_contract.md) to see what notes can achieve. In this section you will also find other tutorials using notes in different ways. ### Further reading -- [Storage Trees](/aztec/concepts/storage/trees) +- [Storage Trees](../../../../aztec/concepts/storage/trees/index.md) - [Proof of prior notes](../how_to_prove_history.md) - public/private reading of public/private proof of state (public or private) If you're curious about any of the following related topics, search the documentation for... diff --git a/docs/docs/guides/smart_contracts/writing_contracts/storage/storage_slots.md b/docs/docs/guides/smart_contracts/writing_contracts/storage/storage_slots.md index 32881114bd5d..478fdf408901 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/storage/storage_slots.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/storage/storage_slots.md @@ -2,7 +2,7 @@ title: Storage slots --- -From the description of storage slots [in the Concepts](/guides/smart_contracts/writing_contracts/storage/storage_slots) you will get an idea around the logic of storage slots. In this section we will go into more detail and walk through an entire example of how storage slots are computed for private state to improve our storage slot intuition. Recall, that storage slots in the private domain is just a logical construct, and are not "actually" used for lookups, but rather just as a value to constrain against. +From the description of storage slots [in the Concepts](storage_slots.md) you will get an idea around the logic of storage slots. In this section we will go into more detail and walk through an entire example of how storage slots are computed for private state to improve our storage slot intuition. Recall, that storage slots in the private domain is just a logical construct, and are not "actually" used for lookups, but rather just as a value to constrain against. For the case of the example, we will look at what is inserted into the note hashes tree when adding a note in the Token contract. Specifically, we are looking at the last part of the `transfer` function: diff --git a/docs/docs/protocol-specs/cryptography/hashing/hashing.md b/docs/docs/protocol-specs/cryptography/hashing/hashing.md index f1773cb63fdb..6f83f0b8f98e 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](../../../aztec/concepts/storage/trees/index.md#layers) of the tree. ### Pseudo-randomness @@ -24,6 +24,6 @@ Pseudo-randomness is required in cases such as: - Fiat-Shamir challenge generation. - Expanding a random seed to generate additional randomness. - - See the derivation of [master secret keys](/aztec/concepts/accounts/keys.md#master-keys). + - See the derivation of [master secret keys](../../../aztec/concepts/accounts/keys.md#master-keys). - Deriving a nullifier, and siloing a nullifier. - - See [deriving a nullifier](/aztec/concepts/accounts/keys.md#deriving-a-nullifier-within-an-app-contract). + - See [deriving a nullifier](../../../aztec/concepts/accounts/keys.md#deriving-a-nullifier-within-an-app-contract). diff --git a/docs/docs/protocol-specs/state/tree-implementations.md b/docs/docs/protocol-specs/state/tree-implementations.md index ec15a26fe1b6..cf0f9cf8ccf7 100644 --- a/docs/docs/protocol-specs/state/tree-implementations.md +++ b/docs/docs/protocol-specs/state/tree-implementations.md @@ -14,7 +14,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) for more details on how insertions, updates, and membership proofs are executed on an Indexed Merkle tree. +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. diff --git a/docs/docs/reference/common_errors/aztecnr-errors.md b/docs/docs/reference/common_errors/aztecnr-errors.md index 71028ba94298..093e0c0ffd7e 100644 --- a/docs/docs/reference/common_errors/aztecnr-errors.md +++ b/docs/docs/reference/common_errors/aztecnr-errors.md @@ -12,7 +12,7 @@ All smart contracts written in Aztec.nr need the `aztec` dependency. In your `Na aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="noir-projects/aztec-nr/aztec" } ``` -You can learn more about dependencies and their paths [here](/reference/smart_contract_reference/dependencies.md). +You can learn more about dependencies and their paths [here](../smart_contract_reference/dependencies.md). #### `backend has encountered an error` @@ -26,7 +26,7 @@ It will then reinstall when you compile. #### `Oracle callback {} not found` & `Oracle callback pedersenHash not found` -This can occasionally happen when there are breaking releases. Make sure that your dependencies in `Nargo.toml` are [updated to the latest release](/reference/smart_contract_reference/dependencies.md). +This can occasionally happen when there are breaking releases. Make sure that your dependencies in `Nargo.toml` are [updated to the latest release](../smart_contract_reference/dependencies.md). #### `error: Failed constraint: 'Public state writes only supported in public functions` @@ -47,7 +47,7 @@ This error occurs when you are trying to interact with a smart contract via an P To execute a transaction, the PXE needs to know the complete address of a contract and contract artifacts. -To address the error, add the contract to the PXE by calling [`pxe.addContracts(...)`](/aztec/concepts/pxe/index.md#addcontracts). +To address the error, add the contract to the PXE by calling [`pxe.addContracts(...)`](../../aztec/concepts/pxe/index.md#addcontracts). #### `Simulation error: No public key registered for address 0x0. Register it by calling pxe.registerRecipient(...) or pxe.registerAccount(...)` diff --git a/docs/docs/reference/common_errors/sandbox-errors.md b/docs/docs/reference/common_errors/sandbox-errors.md index 3ab918c7ac9f..c345ecf05a99 100644 --- a/docs/docs/reference/common_errors/sandbox-errors.md +++ b/docs/docs/reference/common_errors/sandbox-errors.md @@ -14,7 +14,7 @@ This section contains a list of errors you may encounter when using Aztec Sandbo ### Kernel Circuits -We have several versions of public and private kernels as explained in [our circuits section](/aztec/concepts/circuits). Certain things are only possible in certain versions of the circuits. So always ensure that the right version is being used for proof generation. For example, there is a specific version of the public kernel that only works if the previous kernel iteration was a private kernel. Similarly there is one that only works if the previous kernel was public. +We have several versions of public and private kernels as explained in [our circuits section](../../aztec/concepts/circuits/index.md). Certain things are only possible in certain versions of the circuits. So always ensure that the right version is being used for proof generation. For example, there is a specific version of the public kernel that only works if the previous kernel iteration was a private kernel. Similarly there is one that only works if the previous kernel was public. Remember that for each function call (i.e. each item in the call stack), there is a new kernel iteration that gets run. @@ -87,7 +87,7 @@ Calling a private Aztec.nr function in a public kernel is not allowed. #### 3005 - PUBLIC_KERNEL\_\_NON_EMPTY_PRIVATE_CALL_STACK -Public functions are executed after all the private functions are (see [private-public execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md)). As such, private call stack must be empty when executing in the public kernel. +Public functions are executed after all the private functions are (see [private-public execution](../../aztec/concepts/smart_contracts/communication/public_private_calls.md)). As such, private call stack must be empty when executing in the public kernel. #### 3011 - PUBLIC_KERNEL\_\_CALCULATED_PRIVATE_CALL_HASH_AND_PROVIDED_PRIVATE_CALL_HASH_MISMATCH @@ -131,7 +131,7 @@ For static calls, no new note hashes or nullifiers can be added to the state. ### Rollup circuit errors -These are errors that occur when kernel proofs (transaction proofs) are sent to the rollup circuits to create an L2 block. See [rollup circuits](/aztec/concepts/circuits) for more information. +These are errors that occur when kernel proofs (transaction proofs) are sent to the rollup circuits to create an L2 block. See [rollup circuits](../../aztec/concepts/circuits/index.md) for more information. #### 4007 - BASE\_\_INVALID_CHAIN_ID @@ -141,7 +141,7 @@ The L1 chain ID you used in your proof generation (for your private transaction) Same as [section 4007](#4007---base__invalid_chain_id) except the `version` refers to the version of the Aztec L2 instance. -Some scary bugs like `4003 - BASE__INVALID_NULLIFIER_SUBTREE` and `4004 - BASE__INVALID_NULLIFIER_RANGE` which are to do malformed nullifier trees (see [Indexed Merkle Trees](/aztec/concepts/storage/trees/indexed_merkle_tree)) etc may seem unrelated at a glance, but at a closer look may be because of some bug in an application's Aztec.nr code. Same is true for certain instances of `7008 - MEMBERSHIP_CHECK_FAILED`. +Some scary bugs like `4003 - BASE__INVALID_NULLIFIER_SUBTREE` and `4004 - BASE__INVALID_NULLIFIER_RANGE` which are to do malformed nullifier trees (see [Indexed Merkle Trees](../../aztec/concepts/storage/trees/indexed_merkle_tree.mdx)) etc may seem unrelated at a glance, but at a closer look may be because of some bug in an application's Aztec.nr code. Same is true for certain instances of `7008 - MEMBERSHIP_CHECK_FAILED`. ### Generic circuit errors @@ -172,7 +172,7 @@ Users may create a proof against a historical state in Aztec. The rollup circuit - using invalid historical L1 to L2 message data tree state - inserting a subtree into the greater tree - we make a smaller merkle tree of all the new note hashes/nullifiers etc that were created in a transaction or in a rollup and add it to the bigger state tree. Before inserting, we do a merkle membership check to ensure that the index to insert at is indeed an empty subtree (otherwise we would be overwriting state). This can happen when `next_available_leaf_index` in the state tree's snapshot is wrong (it is fetched by the sequencer from the archiver). The error message should reveal which tree is causing this issue - - nullifier tree related errors - The nullifier tree uses an [Indexed Merkle Tree](/aztec/concepts/storage/trees/indexed_merkle_tree). It requires additional data from the archiver to know which is the nullifier in the tree that is just below the current nullifier before it can perform batch insertion. If the low nullifier is wrong, or the nullifier is in incorrect range, you may receive this error. + - nullifier tree related errors - The nullifier tree uses an [Indexed Merkle Tree](../../aztec/concepts/storage/trees/indexed_merkle_tree.mdx). It requires additional data from the archiver to know which is the nullifier in the tree that is just below the current nullifier before it can perform batch insertion. If the low nullifier is wrong, or the nullifier is in incorrect range, you may receive this error. --- @@ -190,7 +190,7 @@ Users may create a proof against a historical state in Aztec. The rollup circuit - "\$\{treeName\} tree next available leaf index mismatch" - validating a tree's root is not enough. It also checks that the `next_available_leaf_index` is as expected. This is the next index we can insert new values into. Note that for the public data tree, this test is skipped since as it is a sparse tree unlike the others. -- "Public call stack size exceeded" - In Aztec, the sequencer executes all enqueued public functions in a transaction (to prevent race conditions - see [private-public execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md)). This error says there are too many public functions requested. +- "Public call stack size exceeded" - In Aztec, the sequencer executes all enqueued public functions in a transaction (to prevent race conditions - see [private-public execution](../../aztec/concepts/smart_contracts/communication/public_private_calls.md)). This error says there are too many public functions requested. - "Array size exceeds target length" - happens if you add more items than allowed by the constants set due to our circuit limitations (eg sending too many L2 to L1 messages or creating a function that exceeds the call stack length or returns more values than what Aztec.nr functions allow) diff --git a/docs/docs/reference/privacy_considerations.md b/docs/docs/reference/privacy_considerations.md index 7198d90df1d6..d8b053ac169e 100644 --- a/docs/docs/reference/privacy_considerations.md +++ b/docs/docs/reference/privacy_considerations.md @@ -52,7 +52,7 @@ Any time a private function makes a call to a public function, information is le ### Crossing the public -> private boundary -If a public function sends a message to be consumed by a private function, the act of consuming that message might be leaked if not following recommended patterns. See [here](/reference/smart_contract_reference/portals/inbox.md) for more details. +If a public function sends a message to be consumed by a private function, the act of consuming that message might be leaked if not following recommended patterns. See [here](smart_contract_reference/portals/inbox.md) for more details. ### Timing of transactions diff --git a/docs/docs/reference/sandbox_reference/index.md b/docs/docs/reference/sandbox_reference/index.md index c0a128147408..3be2d0448e3f 100644 --- a/docs/docs/reference/sandbox_reference/index.md +++ b/docs/docs/reference/sandbox_reference/index.md @@ -10,7 +10,7 @@ Aztec's Layer 2 network is a fully programmable combined private/public ZK rollu - Aztec Node - Aggregates all of the 'backend' services necessary for the building and publishing of rollups. This package is currently in development and much of the functionality is mocked. - [Private Execution Environment (PXE)](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/pxe) - Normally residing with the end client, this decrypts and stores a client's private state, executes simulations and submits transactions to the Aztec Node. -- [Aztec.js](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/aztec.js) - Aztec's client library for interacting with the PXE (think Ethers.js). See the getting started guide [here](/getting_started/aztecjs-getting-started.md). +- [Aztec.js](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/aztec.js) - Aztec's client library for interacting with the PXE (think Ethers.js). See the getting started guide [here](../../getting_started/aztecjs-getting-started.md). All of this is included in the Sandbox, with the exception of Aztec.js which you can use to interact with it. @@ -34,4 +34,4 @@ The current sandbox does not generate or verify proofs, but provides a working e ## Command line tools -Aztec-nargo and aztec-builder are command-line tool allowing you to compile smart contracts. See the [compiling contracts](/guides/smart_contracts/how_to_compile_contract) page for more information. +Aztec-nargo and aztec-builder are command-line tool allowing you to compile smart contracts. See the [compiling contracts](../../guides/smart_contracts/how_to_compile_contract.md) page for more information. diff --git a/docs/docs/reference/sandbox_reference/sandbox-reference.md b/docs/docs/reference/sandbox_reference/sandbox-reference.md index c02d4a7988c1..5d017dbdc90f 100644 --- a/docs/docs/reference/sandbox_reference/sandbox-reference.md +++ b/docs/docs/reference/sandbox_reference/sandbox-reference.md @@ -4,14 +4,14 @@ title: Sandbox Reference :::tip -For a quick start, follow the [guide](/getting_started.md) to install the sandbox. +For a quick start, follow the [guide](../../getting_started.md) to install the sandbox. ::: ## Manual Install -You can manually install the sandbox via the underlying script used in the [Aztec Boxes](/getting_started.md#run-the-npx-script). +You can manually install the sandbox via the underlying script used in the [Aztec Boxes](../../getting_started.md#run-the-npx-script). ### Prerequisites @@ -119,7 +119,7 @@ If you wish to run components of the Aztec network stack separately, you can use aztec start --node [nodeOptions] --pxe [pxeOptions] --archiver [archiverOptions] --sequencer [sequencerOptions] --prover [proverOptions] ----p2p-bootstrap [p2pOptions] ``` -Starting the aztec node alongside a PXE, sequencer or archiver, will attach the components to the node.Eg if you want to run a PXE separately to a node, you can [read this guide](/aztec/concepts/pxe/index.md)/ +Starting the aztec node alongside a PXE, sequencer or archiver, will attach the components to the node.Eg if you want to run a PXE separately to a node, you can [read this guide](../../aztec/concepts/pxe/index.md)/ ## Environment Variables @@ -217,7 +217,7 @@ To help with testing, the sandbox is shipped with a set of cheatcodes. Cheatcodes allow you to change the time of the Aztec block, load certain state or more easily manipulate Ethereum instead of having to write dedicated RPC calls to anvil or hardhat. -You can find the cheat code reference [here](/reference/sandbox_reference/cheat_codes.md). +You can find the cheat code reference [here](cheat_codes.md). ## Contracts diff --git a/docs/docs/reference/smart_contract_reference/dependencies.md b/docs/docs/reference/smart_contract_reference/dependencies.md index 39ca07ee85c9..fdcd2b82f35b 100644 --- a/docs/docs/reference/smart_contract_reference/dependencies.md +++ b/docs/docs/reference/smart_contract_reference/dependencies.md @@ -51,4 +51,4 @@ This library contains types that are used in the Aztec protocol. Find it on [Git value_note = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="noir-projects/aztec-nr/value-note" } ``` -This is a library for a note that stores one arbitrary value. You can see an example of how it might be used in the [token contract tutorial](/tutorials/contract_tutorials/token_contract.md). +This is a library for a note that stores one arbitrary value. You can see an example of how it might be used in the [token contract tutorial](../../tutorials/contract_tutorials/token_contract.md). diff --git a/docs/docs/reference/smart_contract_reference/history_lib_reference.md b/docs/docs/reference/smart_contract_reference/history_lib_reference.md index 64f41b03086b..9971a6ef7756 100644 --- a/docs/docs/reference/smart_contract_reference/history_lib_reference.md +++ b/docs/docs/reference/smart_contract_reference/history_lib_reference.md @@ -21,7 +21,7 @@ Note inclusion proves that a note existed (its hash was included in a note hash ## prove_note_commitment_inclusion -A **commitment**, also referred to as a **note hash** is a public acknowledgment of the existence of a note without revealing the content of the note. You can learn more about how to compress a note to a note hash [here](/aztec/concepts/storage/trees/index.md#example-note). +A **commitment**, also referred to as a **note hash** is a public acknowledgment of the existence of a note without revealing the content of the note. You can learn more about how to compress a note to a note hash [here](../../aztec/concepts/storage/trees/index.md#example-note). `prove_note_commitment_inclusion` takes 2 parameters: diff --git a/docs/docs/reference/smart_contract_reference/storage/index.md b/docs/docs/reference/smart_contract_reference/storage/index.md index 8e8cfb0472d5..be392ad8b631 100644 --- a/docs/docs/reference/smart_contract_reference/storage/index.md +++ b/docs/docs/reference/smart_contract_reference/storage/index.md @@ -4,8 +4,8 @@ title: Storage Smart contracts rely on storage, acting as the persistent memory on the blockchain. In Aztec, because of its hybrid, privacy-first architecture, the management of this storage is more complex than other blockchains like Ethereum. -To learn how to define a storage struct, read [this guide](/guides/smart_contracts/writing_contracts/storage). -To learn more about storage slots, read [this explainer](/guides/smart_contracts/writing_contracts/storage/storage_slots). +To learn how to define a storage struct, read [this guide](../../../guides/smart_contracts/writing_contracts/storage/index.md). +To learn more about storage slots, read [this explainer](../../../guides/smart_contracts/writing_contracts/storage/storage_slots.md). You control this storage in Aztec using a struct annotated with `#[aztec(storage)]`. This struct serves as the housing unit for all your smart contract's state variables - the data it needs to keep track of and maintain. @@ -26,7 +26,7 @@ On this and the following pages in this section, you’ll learn: Public state variables can be read by anyone, while private state variables can only be read by their owner (or people whom the owner has shared the decrypted data or note viewing key with). -Public state follows the Ethereum style account model, where each contract has its own key-value datastore. Private state follows a UTXO model, where note contents (/aztec/aztec/concepts/state_model/index.md) and [private/public execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md)) for more background. +Public state follows the Ethereum style account model, where each contract has its own key-value datastore. Private state follows a UTXO model, where note contents (/aztec/aztec/concepts/state_model/index.md) and [private/public execution](../../../aztec/concepts/smart_contracts/communication/public_private_calls.md)) for more background. ## Storage struct @@ -46,7 +46,7 @@ A `map` is a state variable that "maps" a key to a value. It can be used with pr In Aztec.nr, keys are always `Field`s, or types that can be serialized as Fields, and values can be any type - even other maps. `Field`s are finite field elements, but you can think of them as integers. ::: -It includes a [`Context`](/aztec/concepts/smart_contracts/functions/context) to specify the private or public domain, a `storage_slot` to specify where in storage the map is stored, and a `start_var_constructor` which tells the map how it should operate on the underlying type. This includes how to serialize and deserialize the type, as well as how commitments and nullifiers are computed for the type if it's private. +It includes a [`Context`](../../../aztec/concepts/smart_contracts/functions/context.md) to specify the private or public domain, a `storage_slot` to specify where in storage the map is stored, and a `start_var_constructor` which tells the map how it should operate on the underlying type. This includes how to serialize and deserialize the type, as well as how commitments and nullifiers are computed for the type if it's private. You can view the implementation in the Aztec.nr library [here](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/aztec-nr). @@ -54,7 +54,7 @@ You can have multiple `map`s in your contract that each have a different underly ### `new` -When declaring the storage for a map, we use the `Map::new()` constructor. As seen below, this takes the `storage_slot` and the `start_var_constructor` along with the [`Context`](/aztec/concepts/smart_contracts/functions/context). +When declaring the storage for a map, we use the `Map::new()` constructor. As seen below, this takes the `storage_slot` and the `start_var_constructor` along with the [`Context`](../../../aztec/concepts/smart_contracts/functions/context.md). We will see examples of map constructors for public and private variables in later sections. @@ -94,6 +94,6 @@ require(minters[msg.sender], "caller is not minter"); ## Concepts mentioned -- [State Model](/aztec/concepts/state_model/index.md) -- [Public-private execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md) -- [Function Contexts](/aztec/concepts/smart_contracts/functions/context) +- [State Model](../../../aztec/concepts/state_model/index.md) +- [Public-private execution](../../../aztec/concepts/smart_contracts/communication/public_private_calls.md) +- [Function Contexts](../../../aztec/concepts/smart_contracts/functions/context.md) diff --git a/docs/docs/reference/smart_contract_reference/storage/private_state.md b/docs/docs/reference/smart_contract_reference/storage/private_state.md index bed799ff6412..f2987c0a96a2 100644 --- a/docs/docs/reference/smart_contract_reference/storage/private_state.md +++ b/docs/docs/reference/smart_contract_reference/storage/private_state.md @@ -4,15 +4,15 @@ title: Private State On this page we will look at how to manage private state in Aztec contracts. We will look at how to declare private state, how to read and write to it, and how to use it in your contracts. -For a higher level overview of the state model in Aztec, see the [hybrid state model](/aztec/concepts/state_model/index.md) page. +For a higher level overview of the state model in Aztec, see the [hybrid state model](../../../aztec/concepts/state_model/index.md) page. ## Overview In contrast to public state, private state is persistent state that is **not** visible to the whole world. Depending on the logic of the smart contract, a private state variable's current value will only be known to one entity, or a closed group of entities. -The value of a private state variable can either be shared via an [encrypted log](/guides/smart_contracts/writing_contracts/how_to_emit_event#encrypted-events), or offchain via web2, or completely offline: it's up to the app developer. +The value of a private state variable can either be shared via an [encrypted log](../../../guides/smart_contracts/writing_contracts/how_to_emit_event.md#encrypted-events), or offchain via web2, or completely offline: it's up to the app developer. -Aztec private state follows a [utxo](https://en.wikipedia.org/wiki/Unspent_transaction_output)-based model. That is, a private state's current value is represented as one or many [notes](/aztec/concepts/storage/trees/index.md). +Aztec private state follows a [utxo](https://en.wikipedia.org/wiki/Unspent_transaction_output)-based model. That is, a private state's current value is represented as one or many [notes](../../../aztec/concepts/storage/trees/index.md). To greatly simplify the experience of writing private state, Aztec.nr provides three different types of private state variable: @@ -184,7 +184,7 @@ Functionally similar to `get_note`, but executed unconstrained and can be used b You can view the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/state_vars/set.nr). -And can be added to the `Storage` struct as follows. Here adding a set for a custom note, the TransparentNote (useful for [public -> private communication](/guides/smart_contracts/writing_contracts/call_functions.md). +And can be added to the `Storage` struct as follows. Here adding a set for a custom note, the TransparentNote (useful for [public -> private communication](../../../guides/smart_contracts/writing_contracts/call_functions.md). #include_code storage-set-declaration /noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr rust @@ -200,13 +200,13 @@ We can initialize the set as follows: Allows us to modify the storage by inserting a note into the `PrivateSet`. -A hash of the note will be generated, and inserted into the note hash tree, allowing us to later use in contract interactions. Recall that the content of the note should be shared with the owner to allow them to use it, as mentioned this can be done via an [encrypted log](/guides/smart_contracts/writing_contracts/how_to_emit_event#encrypted-events), or offchain via web2, or completely offline. +A hash of the note will be generated, and inserted into the note hash tree, allowing us to later use in contract interactions. Recall that the content of the note should be shared with the owner to allow them to use it, as mentioned this can be done via an [encrypted log](../../../guides/smart_contracts/writing_contracts/how_to_emit_event.md#encrypted-events), or offchain via web2, or completely offline. #include_code insert /noir-projects/aztec-nr/easy-private-state/src/easy_private_uint.nr rust ### `insert_from_public` -The `insert_from_public` allow public function to insert notes into private storage. This is very useful when we want to support private function calls that have been initiated in public, such as shielding in the [example token contract](/tutorials/contract_tutorials/token_contract.md#shield). +The `insert_from_public` allow public function to insert notes into private storage. This is very useful when we want to support private function calls that have been initiated in public, such as shielding in the [example token contract](../../../tutorials/contract_tutorials/token_contract.md#shield). The usage is similar to using the `insert` method with the difference that this one is called in public functions. @@ -248,7 +248,7 @@ This function requires a `NoteViewerOptions`. The `NoteViewerOptions` is essenti ## `NoteGetterOptions` -`NoteGetterOptions` encapsulates a set of configurable options for filtering and retrieving a selection of notes from a [data oracle](/aztec/concepts/smart_contracts/oracles/index.md). Developers can design instances of `NoteGetterOptions`, to determine how notes should be filtered and returned to the functions of their smart contracts. +`NoteGetterOptions` encapsulates a set of configurable options for filtering and retrieving a selection of notes from a [data oracle](../../../aztec/concepts/smart_contracts/oracles/index.md). Developers can design instances of `NoteGetterOptions`, to determine how notes should be filtered and returned to the functions of their smart contracts. You can view the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/note/note_getter_options.nr). diff --git a/docs/docs/reference/smart_contract_reference/storage/public_state.md b/docs/docs/reference/smart_contract_reference/storage/public_state.md index f30e256659d6..69b5a960fb8b 100644 --- a/docs/docs/reference/smart_contract_reference/storage/public_state.md +++ b/docs/docs/reference/smart_contract_reference/storage/public_state.md @@ -4,7 +4,7 @@ title: Public State On this page we will look at how to manage public state in Aztec contracts. We will look at how to declare public state, how to read and write to it, and how to use it in your contracts. -For a higher level overview of the state model in Aztec, see the [state model](/aztec/concepts/state_model/index.md) page. +For a higher level overview of the state model in Aztec, see the [state model](../../../aztec/concepts/state_model/index.md) page. ## `PublicMutable` @@ -13,7 +13,7 @@ The `PublicMutable` (formerly known as `PublicState`) struct is generic over the #include_code serialize /noir-projects/noir-protocol-circuits/crates/types/src/traits.nr rust #include_code deserialize /noir-projects/noir-protocol-circuits/crates/types/src/traits.nr rust -The struct contains a `storage_slot` which, similar to Ethereum, is used to figure out _where_ in storage the variable is located. Notice that while we don't have the exact same [state model](/aztec/concepts/state_model/index.md) as EVM chains it will look similar from the contract developers point of view. +The struct contains a `storage_slot` which, similar to Ethereum, is used to figure out _where_ in storage the variable is located. Notice that while we don't have the exact same [state model](../../../aztec/concepts/state_model/index.md) as EVM chains it will look similar from the contract developers point of view. You can find the details of `PublicMutable` in the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/state_vars/public_mutable.nr). @@ -25,7 +25,7 @@ An example using a larger struct can be found in the [lending example](https://g ### `new` -When declaring the storage for `T` as a persistent public storage variable, we use the `PublicMutable::new()` constructor. As seen below, this takes the `storage_slot` and the `serialization_methods` as arguments along with the [`Context`](/aztec/concepts/smart_contracts/functions/context), which in this case is used to share interface with other structures. You can view the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/state_vars/public_mutable.nr). +When declaring the storage for `T` as a persistent public storage variable, we use the `PublicMutable::new()` constructor. As seen below, this takes the `storage_slot` and the `serialization_methods` as arguments along with the [`Context`](../../../aztec/concepts/smart_contracts/functions/context.md), which in this case is used to share interface with other structures. You can view the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/state_vars/public_mutable.nr). #### Single value example diff --git a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md index 3331911f850f..ae0de9a64474 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md @@ -4,7 +4,7 @@ title: Token Bridge import Image from "@theme/IdealImage"; -In this tutorial, we will learn how to build the entire flow of a cross-chain token using portals. If this is your first time hearing the word portal, you’ll want to read [this](/protocol-specs/l1-smart-contracts/index.md). +In this tutorial, we will learn how to build the entire flow of a cross-chain token using portals. If this is your first time hearing the word portal, you’ll want to read [this](../../../../protocol-specs/l1-smart-contracts/index.md). ## A refresher on Portals @@ -35,7 +35,7 @@ Aztec has the following core smart contracts on L1 that we need to know about: - `Outbox.sol` - a mailbox to the rollup for L2 to L1 messages (e.g. withdrawing tokens). Aztec contracts emit these messages and the sequencer adds these to the outbox. Portals then consume these messages. - `Registry.sol` - just like L1, we assume there will be various versions of Aztec (due to upgrades, forks etc). In such a case messages must not be replayable in other Aztec “domains”. A portal must decide which version/ID of Aztec the message is for. The registry stores the rollup, inbox and outbox address for each version of Aztec deployments, so the portal can find out the address of the mailbox it wants to talk to -For more information, read [cross-chain calls](/protocol-specs/l1-smart-contracts/index.md). +For more information, read [cross-chain calls](../../../../protocol-specs/l1-smart-contracts/index.md). ## Building a Token Bridge with Portals @@ -43,7 +43,7 @@ The goal for this tutorial is to create functionality such that a token can be b This is just a reference implementation for educational purposes only. It has not been through an in-depth security audit. -Let’s assume a token exists on Ethereum and Aztec (see a [guide on writing a token contract on Aztec here](/tutorials/contract_tutorials/token_contract)). +Let’s assume a token exists on Ethereum and Aztec (see a [guide on writing a token contract on Aztec here](../../token_contract.md)). We will build: diff --git a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md index f3b6aadd52d2..e5ee2372439a 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md @@ -47,6 +47,6 @@ If the content hashes were constructed similarly for `mint_private` and `mint_pu While we mint the tokens on L2, we _still don’t actually mint them to a certain address_. Instead we continue to pass the `secret_hash_for_redeeming_minted_notes` like we did on L1. This means that a user could reveal their secret for L2 message consumption for anyone to mint tokens on L2 but they can redeem these notes at a later time. **This enables a paradigm where an app can manage user’s secrets for L2 message consumption on their behalf**. **The app or any external party can also mint tokens on the user’s behalf should they be comfortable with leaking the secret for L2 Message consumption.** This doesn’t leak any new information to the app because their smart contract on L1 knew that a user wanted to move some amount of tokens to L2. The app still doesn’t know which address on L2 the user wants these notes to be in, but they can mint tokens nevertheless on their behalf. -To mint tokens privately, `claim_private` calls an internal function `_call_mint_on_token()` which then calls [token.mint_private()](/tutorials/contract_tutorials/token_contract.md#redeem_shield). +To mint tokens privately, `claim_private` calls an internal function `_call_mint_on_token()` which then calls [token.mint_private()](../../token_contract.md#redeem_shield). In the next step we will see how we can cancel a message. diff --git a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/setup.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/setup.md index 78fe396dc07a..c449545491af 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/setup.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/setup.md @@ -18,7 +18,7 @@ We recommend going through this setup to fully understand where things live. - [node v18+](https://github.com/tj/n) - [docker](https://docs.docker.com/) - [Aztec sandbox](https://docs.aztec.network/developers/getting_started/sandbox) - you should have this running before starting the tutorial -- [Aztec CLI](/getting_started) +- [Aztec CLI](../../../../getting_started.md) ```bash /bin/sh -c "$(curl -fsSL 'https://sandbox.aztec.network')" diff --git a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md index 3c5c8b4008e5..a8a71c3cf0ef 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md @@ -17,9 +17,9 @@ For this to work we import the `get_withdraw_content_hash` helper function from The `exit_to_l1_public` function enables anyone to withdraw their L2 tokens back to L1 publicly. This is done by burning tokens on L2 and then creating an L2->L1 message. 1. Like with our deposit function, we need to create the L2 to L1 message. The content is the _amount_ to burn, the recipient address, and who can execute the withdraw on the L1 portal on behalf of the user. It can be `0x0` for anyone, or a specified address. -2. `context.message_portal()` passes this content to the [kernel circuit](/aztec/concepts/circuits/kernels/public_kernel.md) which creates the proof for the transaction. The kernel circuit then adds the sender (the L2 address of the bridge + version of aztec) and the recipient (the portal to the L2 address + the chain ID of L1) under the hood, to create the message which gets added as part of the transaction data published by the sequencer and is stored in the outbox for consumption. +2. `context.message_portal()` passes this content to the [kernel circuit](../../../../aztec/concepts/circuits/kernels/public_kernel.md) which creates the proof for the transaction. The kernel circuit then adds the sender (the L2 address of the bridge + version of aztec) and the recipient (the portal to the L2 address + the chain ID of L1) under the hood, to create the message which gets added as part of the transaction data published by the sequencer and is stored in the outbox for consumption. 3. The `context.message_portal()` takes the recipient and content as input, and will insert a message into the outbox. We set the recipient to be the portal address read from storage of the contract. -4. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](/tutorials/contract_tutorials/token_contract.md#authorizing-token-spends). +4. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](../../token_contract.md#authorizing-token-spends). - We burn the tokens from the `msg_sender()`. Otherwise, a malicious user could burn someone else’s tokens and mint tokens on L1 to themselves. One could add another approval flow on the bridge but that might make it complex for other applications to call the bridge. ## Withdrawing Privately diff --git a/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md b/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md index 7147853ac5b2..0280a5a214dd 100644 --- a/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md +++ b/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md @@ -76,7 +76,7 @@ Replace the example functions with an initializer that takes the required campai } ``` -More about initializers [here](/guides/smart_contracts/writing_contracts/initializers.md). +More about initializers [here](../../guides/smart_contracts/writing_contracts/initializers.md). #### Dependencies @@ -184,7 +184,7 @@ token = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_ With the dependency already `use`d at the start of the contract, the token contract can be called to make the transfer from msg sender to this contract. :::note -The user must have authorised this action (concept [here](/aztec/concepts/accounts#authorizing-actions)), example use of `createAuthWit` in 'full donor flow' test [here](../../../../yarn-project/end-to-end/src/e2e_crowdfunding_and_claim.test.ts). +The user must have authorised this action (concept [here](../../aztec/concepts/accounts/index.md#authorizing-actions)), example use of `createAuthWit` in 'full donor flow' test [here](../../../../yarn-project/end-to-end/src/e2e_crowdfunding_and_claim.test.ts). ::: #### Creating and storing a private receipt note diff --git a/docs/docs/tutorials/contract_tutorials/private_voting_contract.md b/docs/docs/tutorials/contract_tutorials/private_voting_contract.md index 5815d037c267..0a489da0ae40 100644 --- a/docs/docs/tutorials/contract_tutorials/private_voting_contract.md +++ b/docs/docs/tutorials/contract_tutorials/private_voting_contract.md @@ -21,7 +21,7 @@ To keep things simple, we won't create ballots or allow for delegate voting. ## Prerequisites -- You have followed the [quickstart](/getting_started) to install `aztec-nargo` and `aztec-sandbox`. +- You have followed the [quickstart](../../getting_started.md) to install `aztec-nargo` and `aztec-sandbox`. - Running Aztec Sandbox ## Set up a project @@ -110,9 +110,9 @@ Create a private function called `cast_vote`: #include_code cast_vote noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr rust -In this function, we do not create a nullifier with the address directly. This would leak privacy as it would be easy to reverse-engineer. We must add some randomness or some form of secret, like [nullifier secrets](/aztec/concepts/accounts/keys.md#nullifier-secrets). +In this function, we do not create a nullifier with the address directly. This would leak privacy as it would be easy to reverse-engineer. We must add some randomness or some form of secret, like [nullifier secrets](../../aztec/concepts/accounts/keys.md#nullifier-secrets). -To do this, we make an [oracle call](/aztec/concepts/smart_contracts/oracles/index.md) to fetch the caller's secret key, hash it to create a nullifier, and push the nullifier to Aztec. The `secret.high` and `secret.low` values here refer to how we divide a large [Grumpkin scalar](https://github.com/AztecProtocol/aztec-packages/blob/7fb35874eae3f2cad5cb922282a619206573592c/noir/noir_stdlib/src/grumpkin_scalar.nr) value into its higher and lower parts. This allows for faster cryptographic computations so our hash can still be secure but is calculated faster. +To do this, we make an [oracle call](../../aztec/concepts/smart_contracts/oracles/index.md) to fetch the caller's secret key, hash it to create a nullifier, and push the nullifier to Aztec. The `secret.high` and `secret.low` values here refer to how we divide a large [Grumpkin scalar](https://github.com/AztecProtocol/aztec-packages/blob/7fb35874eae3f2cad5cb922282a619206573592c/noir/noir_stdlib/src/grumpkin_scalar.nr) value into its higher and lower parts. This allows for faster cryptographic computations so our hash can still be secure but is calculated faster. After pushing the nullifier, we update the `tally` to reflect this vote. As we know from before, a private function cannot update public state directly, so we are calling a public function. @@ -132,7 +132,7 @@ We will create a function that anyone can call that will return the number of vo #include_code get_vote noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr rust -We set it as `unconstrained` and do not annotate it because it is only reading from state. You can read more about unconstrained functions [here](/aztec/concepts/pxe/acir_simulator.md#unconstrained-functions). +We set it as `unconstrained` and do not annotate it because it is only reading from state. You can read more about unconstrained functions [here](../../aztec/concepts/pxe/acir_simulator.md#unconstrained-functions). ## Allowing an admin to end a voting period @@ -154,18 +154,18 @@ aztec-nargo compile This will create a new directory called `target` and a JSON artifact inside it. -Once it is compiled you can [deploy](/reference/sandbox_reference/index.md). +Once it is compiled you can [deploy](../../reference/sandbox_reference/index.md). ```bash aztec-builder target -o src/artifacts ``` -Once it is compiled you can [deploy](/guides/smart_contracts/how_to_deploy_contract.md) it to the sandbox. This is out of scope for this tutorial but you can learn how to do this in the [Aztec.js getting-started guide](/getting_started/aztecjs-getting-started.md). +Once it is compiled you can [deploy](../../guides/smart_contracts/how_to_deploy_contract.md) it to the sandbox. This is out of scope for this tutorial but you can learn how to do this in the [Aztec.js getting-started guide](../../getting_started/aztecjs-getting-started.md). ## Next steps Now you have learned the foundations of Aztec smart contracts, you can start to play around with some more advanced features. Some ideas: - Add some more features into this contract, like the admin can distribute votes, people can delegate their votes, or voteIds can have more data like names, descriptions, etc -- Create a frontend for this contract using [Aztec.js](/getting_started/aztecjs-getting-started.md). -- Go to the [next tutorial](/tutorials/contract_tutorials/token_contract.md) and learn how to write a token contract +- Create a frontend for this contract using [Aztec.js](../../getting_started/aztecjs-getting-started.md). +- Go to the [next tutorial](token_contract.md) and learn how to write a token contract diff --git a/docs/docs/tutorials/contract_tutorials/token_contract.md b/docs/docs/tutorials/contract_tutorials/token_contract.md index cac8dc0a4d1b..839d0dcffb9a 100644 --- a/docs/docs/tutorials/contract_tutorials/token_contract.md +++ b/docs/docs/tutorials/contract_tutorials/token_contract.md @@ -21,7 +21,7 @@ We are going to start with a blank project and fill in the token contract source ## Requirements -You will need to have `aztec-nargo` installed in order to compile Aztec.nr contracts. See the [sandbox reference](/reference/sandbox_reference/index.md) for installation instructions. +You will need to have `aztec-nargo` installed in order to compile Aztec.nr contracts. See the [sandbox reference](../../reference/sandbox_reference/index.md) for installation instructions. You should also install the [Noir Language Support extension](https://marketplace.visualstudio.com/items?itemName=noir-lang.vscode-noir) for VS Code. @@ -151,7 +151,7 @@ These are functions that have transparent logic, will execute in a publicly veri ### Private functions -These are functions that have private logic and will be executed on user devices to maintain privacy. The only data that is submitted to the network is a proof of correct execution, new data [commitments](https://en.wikipedia.org/wiki/Commitment_scheme) and [nullifiers](/aztec/concepts/storage/trees/index.md#nullifier-tree), so users will not reveal which contract they are interacting with or which function they are executing. The only information that will be revealed publicly is that someone executed a private transaction on Aztec. +These are functions that have private logic and will be executed on user devices to maintain privacy. The only data that is submitted to the network is a proof of correct execution, new data [commitments](https://en.wikipedia.org/wiki/Commitment_scheme) and [nullifiers](../../aztec/concepts/storage/trees/index.md#nullifier-tree), so users will not reveal which contract they are interacting with or which function they are executing. The only information that will be revealed publicly is that someone executed a private transaction on Aztec. - `redeem_shield` enables accounts to claim tokens that have been made private via `mint_private` or `shield` by providing the secret - `unshield` enables an account to send tokens from their private balance to any other account's public balance @@ -209,7 +209,7 @@ We are importing: - `compute_secret_hash` that will help with the shielding and unshielding, allowing someone to claim a token from private to public - Types for storing note types -For more detail on execution contexts, see [Contract Communication](/aztec/concepts/smart_contracts/communication). +For more detail on execution contexts, see [Contract Communication](../../aztec/concepts/smart_contracts/communication/index.md). ### Types files @@ -219,7 +219,7 @@ The main thing to note from this types folder is the `TransparentNote` definitio ### Note on private state -Private state in Aztec is all [UTXOs](/aztec/concepts/storage/index.md) to learn more about public and private state in Aztec. +Private state in Aztec is all [UTXOs](../../aztec/concepts/storage/index.md) to learn more about public and private state in Aztec. ## Contract Storage @@ -238,7 +238,7 @@ Reading through the storage variables: - `pending_shields` is a `PrivateSet` of `TransparentNote`s stored in private state. What is stored publicly is a set of commitments to `TransparentNote`s. - `public_balances` is a mapping of Aztec addresses in public state and represents the publicly viewable balances of accounts. -You can read more about it [here](/aztec/concepts/storage/index.md). +You can read more about it [here](../../aztec/concepts/storage/index.md). ## Functions @@ -423,7 +423,7 @@ A getter function for checking the public balance of the provided Aztec account. ## Compiling -Now that the contract is complete, you can compile it with `aztec-nargo`. See the [Sandbox reference page](/reference/sandbox_reference/index.md) for instructions on setting it up. +Now that the contract is complete, you can compile it with `aztec-nargo`. See the [Sandbox reference page](../../reference/sandbox_reference/index.md) for instructions on setting it up. Run the following command in the directory where your `Nargo.toml` file is located: @@ -447,6 +447,6 @@ https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn ### Token Bridge Contract -The [token bridge tutorial](/tutorials/contract_tutorials/advanced/token_bridge) is a great follow up to this one. +The [token bridge tutorial](advanced/token_bridge/index.md) is a great follow up to this one. It builds on the Token contract described here and goes into more detail about Aztec contract composability and Ethereum (L1) and Aztec (L2) cross-chain messaging. diff --git a/docs/docs/tutorials/simple_dapp/contract_deployment.md b/docs/docs/tutorials/simple_dapp/contract_deployment.md index a6981fbd58d6..6d39e55d9021 100644 --- a/docs/docs/tutorials/simple_dapp/contract_deployment.md +++ b/docs/docs/tutorials/simple_dapp/contract_deployment.md @@ -3,7 +3,7 @@ To add contracts to your application, we'll start by creating a new `aztec-nargo` project. We'll then compile the contracts, and write a simple script to deploy them to our Sandbox. :::info -Follow the instructions [here](/reference/sandbox_reference/index.md) to install `aztec-nargo` if you haven't done so already. +Follow the instructions [here](../../reference/sandbox_reference/index.md) to install `aztec-nargo` if you haven't done so already. ::: ## Initialize Aztec project @@ -34,7 +34,7 @@ The `Token` contract also requires some helper files. You can view the files [he ## Compile your contract -We'll now use `aztec-nargo` to [compile](/reference/sandbox_reference/index.md#installation). +We'll now use `aztec-nargo` to [compile](../../reference/sandbox_reference/index.md#installation). Now run the following from your contract folder (containing Nargo.toml): diff --git a/docs/docs/tutorials/simple_dapp/contract_interaction.md b/docs/docs/tutorials/simple_dapp/contract_interaction.md index c263b64ddf63..29f8bcdb8597 100644 --- a/docs/docs/tutorials/simple_dapp/contract_interaction.md +++ b/docs/docs/tutorials/simple_dapp/contract_interaction.md @@ -9,7 +9,7 @@ Let's start by showing our user's private balance for the token across their acc #include_code balance_of_private noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust :::info -Note that this function will only return a valid response for accounts registered in the Private eXecution Environment (PXE), since it requires access to the [user's private state](/aztec/concepts/wallets/index.md#private-state). In other words, you cannot query the private balance of another user for the token contract. +Note that this function will only return a valid response for accounts registered in the Private eXecution Environment (PXE), since it requires access to the [user's private state](../../aztec/concepts/wallets/index.md#private-state). In other words, you cannot query the private balance of another user for the token contract. ::: To do this, let's first initialize a new `Contract` instance using `aztec.js` that represents our deployed token contracts. Create a new `src/contracts.mjs` file with the imports for our artifacts and other dependencies: @@ -93,12 +93,12 @@ At the time of this writing, there are no events emitted when new private notes ## Working with public state -While [private and public state](/aztec/concepts/state_model/index.md) are fundamentally different, the API for working with private and public functions and state from `aztec.js` is equivalent. To query the balance in public tokens for our user accounts, we can just call the `balance_of_public` view function in the contract: +While [private and public state](../../aztec/concepts/state_model/index.md) are fundamentally different, the API for working with private and public functions and state from `aztec.js` is equivalent. To query the balance in public tokens for our user accounts, we can just call the `balance_of_public` view function in the contract: #include_code showPublicBalances yarn-project/end-to-end/src/sample-dapp/index.mjs javascript :::info -Since this we are working with pubic balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](/aztec/concepts/accounts/keys.md#encryption-keys). +Since this we are working with pubic balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](../../aztec/concepts/accounts/keys.md#encryption-keys). ::: Here, since the token contract does not mint any initial funds upon deployment, the balances for all of our user's accounts will be zero. diff --git a/docs/docs/tutorials/simple_dapp/index.md b/docs/docs/tutorials/simple_dapp/index.md index 34a7c6dd6bed..bb4f1021c88d 100644 --- a/docs/docs/tutorials/simple_dapp/index.md +++ b/docs/docs/tutorials/simple_dapp/index.md @@ -4,7 +4,7 @@ title: Dapp Tutorial In this tutorial we'll go through the steps for building a simple application that interacts with the Aztec Sandbox. We'll be building a console application using Javascript and NodeJS, but you may reuse the same concepts here for a web-based app. All Aztec libraries are written in Typescript and fully typed, so you can use Typescript instead of Javascript to make the most out of its type checker. -This tutorial will focus on environment setup, including creating accounts and deployments, as well as interacting with your contracts. It will not cover [how to write contracts in Noir](/aztec/concepts/smart_contracts/index.md). +This tutorial will focus on environment setup, including creating accounts and deployments, as well as interacting with your contracts. It will not cover [how to write contracts in Noir](../../aztec/concepts/smart_contracts/index.md). The full code for this tutorial is [available on the `aztec-packages` repository](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/end-to-end/src/sample-dapp). @@ -12,8 +12,8 @@ The full code for this tutorial is [available on the `aztec-packages` repository - Linux or OSX environment - [NodeJS](https://nodejs.org/) 18 or higher -- [Aztec Sandbox](/getting_started) -- [Aztec CLI](/reference/sandbox_reference) +- [Aztec Sandbox](../../getting_started.md) +- [Aztec CLI](../../reference/sandbox_reference/index.md) ## Prerequisites diff --git a/docs/docs/tutorials/simple_dapp/pxe_service.md b/docs/docs/tutorials/simple_dapp/pxe_service.md index f4f3c51c1583..ca6b995ab3a4 100644 --- a/docs/docs/tutorials/simple_dapp/pxe_service.md +++ b/docs/docs/tutorials/simple_dapp/pxe_service.md @@ -4,7 +4,7 @@ PXE is a component of the Aztec Protocol that provides a private execution envir As an app developer, the [PXE](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/pxe) interface provides you with access to the user's accounts and their private state, as well as a connection to the network for accessing public global state. -During the Sandbox phase, this role is fulfilled by the [Aztec Sandbox](/reference/sandbox_reference/index.md), which runs a local PXE and an Aztec Node, both connected to a local Ethereum development node like Anvil. +During the Sandbox phase, this role is fulfilled by the [Aztec Sandbox](../../reference/sandbox_reference/index.md), which runs a local PXE and an Aztec Node, both connected to a local Ethereum development node like Anvil. The Sandbox also includes a set of pre-initialized accounts that you can use from your app. In this section, we'll connect to the Sandbox from our project. diff --git a/docs/docs/tutorials/simple_dapp/testing.md b/docs/docs/tutorials/simple_dapp/testing.md index 1160977b085f..4261eb8a75b6 100644 --- a/docs/docs/tutorials/simple_dapp/testing.md +++ b/docs/docs/tutorials/simple_dapp/testing.md @@ -14,7 +14,7 @@ Start by installing our test runner, in this case jest: yarn add -D jest ``` -We'll need to [install and run the Sandbox](/reference/sandbox_reference/index.md#installation). +We'll need to [install and run the Sandbox](../../reference/sandbox_reference/index.md#installation). ## Test setup @@ -67,4 +67,4 @@ yarn node --experimental-vm-modules $(yarn bin jest) --testRegex '.*\.test\.mjs$ ## Next steps -Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](/aztec/concepts/smart_contracts/index.md) or read about the [fundamental concepts behind Aztec Network](/aztec/core_components). +Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](../../aztec/concepts/smart_contracts/index.md) or read about the [fundamental concepts behind Aztec Network](../../aztec/core_components.md). diff --git a/docs/docs/tutorials/write_accounts_contract.md b/docs/docs/tutorials/write_accounts_contract.md index fca19b89b0dc..25a10503b373 100644 --- a/docs/docs/tutorials/write_accounts_contract.md +++ b/docs/docs/tutorials/write_accounts_contract.md @@ -13,15 +13,15 @@ You will learn: - Typescript glue code to format and authenticate transactions - Deploying and testing the account contract -Writing your own account contract allows you to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed (including key rotation and recovery). In other words, writing an account contract lets you make the most out of [account abstraction](/aztec/concepts/index.md#what-is-account-abstraction) in the Aztec network. +Writing your own account contract allows you to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed (including key rotation and recovery). In other words, writing an account contract lets you make the most out of [account abstraction](../aztec/concepts/index.md#what-is-account-abstraction) in the Aztec network. -It is highly recommended that you understand how an [account](/aztec/concepts/index.md) is defined in Aztec, as well as the differences between privacy and authentication [keys](/aztec/concepts/accounts/keys.md). You will also need to know how to write a contract in Noir, as well as some basic [Typescript](https://www.typescriptlang.org/). +It is highly recommended that you understand how an [account](../aztec/concepts/index.md) is defined in Aztec, as well as the differences between privacy and authentication [keys](../aztec/concepts/accounts/keys.md). You will also need to know how to write a contract in Noir, as well as some basic [Typescript](https://www.typescriptlang.org/). For this tutorial, we will write an account contract that uses Schnorr signatures for authenticating transaction requests. Every time a transaction payload is passed to this account contract's `entrypoint` function, the account contract requires a valid Schnorr signature, whose signed message matches the transaction payload, and whose signer matches the account contract owner's public key. If the signature fails, the transaction will fail. -For the sake of simplicity, we will hardcode the signing public key into the contract, but you could store it [in a private note](/aztec/concepts/accounts/keys.md#using-a-private-note), [in an immutable note](/aztec/concepts/accounts/keys.md#using-an-immutable-private-note), or [on a separate keystore](/aztec/concepts/accounts/keys.md#using-a-separate-keystore), to mention a few examples. +For the sake of simplicity, we will hardcode the signing public key into the contract, but you could store it [in a private note](../aztec/concepts/accounts/keys.md#using-a-private-note), [in an immutable note](../aztec/concepts/accounts/keys.md#using-an-immutable-private-note), or [on a separate keystore](../aztec/concepts/accounts/keys.md#using-a-separate-keystore), to mention a few examples. ## Contract @@ -29,7 +29,7 @@ Let's start with the account contract itself in Aztec.nr. Create a new Aztec.nr #include_code contract noir-projects/noir-contracts/contracts/schnorr_hardcoded_account_contract/src/main.nr rust -The important part of this contract is the `entrypoint` function, which will be the first function executed in any transaction originated from this account. This function has two main responsibilities: authenticating the transaction and executing calls. It receives a `payload` with the list of function calls to execute, and requests a corresponding [authentication witness](/aztec/concepts/accounts/authwit.md) from an oracle to validate it. Authentication witnesses are used for authorizing actions for an account, whether it is just checking a signature, like in this case, or granting authorization for another account to act on an accounts behalf (e.g. token approvals). You will find this logic implemented in the `AccountActions` module, which use the `AppPayload` and `FeePayload` structs: +The important part of this contract is the `entrypoint` function, which will be the first function executed in any transaction originated from this account. This function has two main responsibilities: authenticating the transaction and executing calls. It receives a `payload` with the list of function calls to execute, and requests a corresponding [authentication witness](../aztec/concepts/accounts/authwit.md) from an oracle to validate it. Authentication witnesses are used for authorizing actions for an account, whether it is just checking a signature, like in this case, or granting authorization for another account to act on an accounts behalf (e.g. token approvals). You will find this logic implemented in the `AccountActions` module, which use the `AppPayload` and `FeePayload` structs: #include_code entrypoint noir-projects/aztec-nr/authwit/src/account.nr rust @@ -49,7 +49,7 @@ For our account contract, we will take the hash of the action to authorize, requ ### Fee Abstraction -The `FeePayload`, being distinct from the `AppPayload`, allows for fee abstraction, meaning the account paying the fee for the transaction can be different than the account that is initiating the transaction. This is also useful for maintaining privacy, as fee payments on the network must be public. For example, Alice could pay a relayer transaction fees in private, and the relayer could pay the transaction fee in public. This also allows for accounts without a fee paying asset to use a non-fee paying asset to pay for fees, provided they can find a relayer willing to accept a non-fee paying asset as payment (or do it for free). You can read more about that works in the protocol specification on fees [here](/protocol-specs/gas-and-fees/tx-setup-and-teardown.md). +The `FeePayload`, being distinct from the `AppPayload`, allows for fee abstraction, meaning the account paying the fee for the transaction can be different than the account that is initiating the transaction. This is also useful for maintaining privacy, as fee payments on the network must be public. For example, Alice could pay a relayer transaction fees in private, and the relayer could pay the transaction fee in public. This also allows for accounts without a fee paying asset to use a non-fee paying asset to pay for fees, provided they can find a relayer willing to accept a non-fee paying asset as payment (or do it for free). You can read more about that works in the protocol specification on fees [here](../protocol-specs/gas-and-fees/tx-setup-and-teardown.md). ### Nonce Abstraction @@ -83,11 +83,11 @@ More signing schemes are available in case you want to experiment with other typ Let's try creating a new account backed by our account contract, and interact with a simple token contract to test it works. -To create and deploy the account, we will use the `AccountManager` class, which takes an instance of an Private Execution Environment (PXE), a [privacy private key](/aztec/concepts/accounts/keys.md#privacy-keys), and an instance of our `AccountContract` class: +To create and deploy the account, we will use the `AccountManager` class, which takes an instance of an Private Execution Environment (PXE), a [privacy private key](../aztec/concepts/accounts/keys.md#privacy-keys), and an instance of our `AccountContract` class: #include_code account-contract-deploy yarn-project/end-to-end/src/guides/writing_an_account_contract.test.ts typescript -Note that we get a [`Wallet` instance](/aztec/concepts/index.md#account-contracts-and-wallets) out of the account, which we can use for initializing the token contract class after deployment, so any transactions sent to it are sent from our wallet. We can then send a transaction to it and check its effects: +Note that we get a [`Wallet` instance](../aztec/concepts/index.md#account-contracts-and-wallets) out of the account, which we can use for initializing the token contract class after deployment, so any transactions sent to it are sent from our wallet. We can then send a transaction to it and check its effects: #include_code account-contract-works yarn-project/end-to-end/src/guides/writing_an_account_contract.test.ts typescript diff --git a/docs/scripts/rewrite_paths.js b/docs/scripts/rewrite_paths.js index c1990b246206..155f2604c2a4 100644 --- a/docs/scripts/rewrite_paths.js +++ b/docs/scripts/rewrite_paths.js @@ -10,27 +10,36 @@ function rewrite(markdown, fp) { // Get the absolute path of the file const filePath = path.resolve(fp); const fileDir = path.dirname(filePath); - const fileDirRelative = path.relative("docs", fileDir); console.log("------"); - console.log("FILE: ", fileDirRelative); + console.log("FILE: ", fileDir); // Go through each link in the markdown file for (let l of absolutePaths) { + if (l.startsWith("](/img")) break; const originalLink = l.slice(2); // Remove the initial "]( /" const linkPath = path.resolve(path.join("docs", originalLink)); // Resolve to the docs directory console.log("Link: ", originalLink); // Calculate the relative path from fileDir to linkPath - const relativePath = path.relative(fileDir, linkPath); + let relativePath = path.relative(fileDir, linkPath); + if ( + !fs.existsSync(linkPath + ".md") && + !fs.existsSync(linkPath + ".mdx") && + fs.statSync(linkPath).isDirectory() + ) { + relativePath += "/index.md"; + } else { + relativePath += ".md"; + } console.log("Transformed link: ", relativePath); // Replace the absolute path with the relative path in the markdown markdown = markdown.replace(`(${originalLink}`, `(${relativePath}`); - // fs.writeFileSync(fp, markdown); + fs.writeFileSync(fp, markdown); } console.log("\n"); } @@ -54,4 +63,4 @@ async function iterate(dir) { } } -iterate("docs/aztec"); +iterate("docs/protocol-specs");