diff --git a/docs/docs/aztec/concepts/accounts/index.md b/docs/docs/aztec/concepts/accounts/index.md index 3d502a96390..027427f9bf3 100644 --- a/docs/docs/aztec/concepts/accounts/index.md +++ b/docs/docs/aztec/concepts/accounts/index.md @@ -72,7 +72,7 @@ def entryPoint(payload): enqueueCall(to, data, value, gasLimit); ``` -Read more about how to write an account contract [here](../../../tutorials/write_accounts_contract.md). +Read more about how to write an account contract [here](../../../tutorials/contract_tutorials/write_accounts_contract.md). ### Account contracts and wallets diff --git a/docs/docs/aztec/concepts/accounts/keys.md b/docs/docs/aztec/concepts/accounts/keys.md index 457f0e4a510..5d6a6135267 100644 --- a/docs/docs/aztec/concepts/accounts/keys.md +++ b/docs/docs/aztec/concepts/accounts/keys.md @@ -116,7 +116,7 @@ This is a snippet of our Schnorr Account contract implementation, which uses Sch #include_code entrypoint /noir-projects/noir-contracts/contracts/schnorr_account_contract/src/main.nr rust -Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](../../../tutorials/write_accounts_contract.md) for a full example of how to manage authentication. +Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](../../../tutorials/contract_tutorials/write_accounts_contract.md) for a full example of how to manage authentication. Furthermore, and since signatures are fully abstracted, how the key is stored in the contract is abstracted as well and left to the developer of the account contract. In the following section we describe a few ways how an account contract could be architected to store signing keys. diff --git a/docs/docs/aztec/concepts/wallets/index.md b/docs/docs/aztec/concepts/wallets/index.md index 4d834b86691..7c47de34b7e 100644 --- a/docs/docs/aztec/concepts/wallets/index.md +++ b/docs/docs/aztec/concepts/wallets/index.md @@ -6,7 +6,7 @@ tags: [accounts] In this page we will cover the main responsibilities of a wallet in the Aztec network. -Refer to [writing an account contract](../../../tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account. +Refer to [writing an account contract](../../../tutorials/contract_tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account. Go to [wallet architecture](./architecture.md) for an overview of its architecture and a reference on the interface a wallet must implement. @@ -20,7 +20,7 @@ In addition to these usual responsibilities, wallets in Aztec also need to track The first step for any wallet is to let the user set up their [accounts](../accounts/index.md). An account in Aztec is represented on-chain by its corresponding account contract that the user must deploy to begin interacting with the network. This account contract dictates how transactions are authenticated and executed. -A wallet must support at least one specific [account contract implementation](../../../tutorials/write_accounts_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts). +A wallet must support at least one specific [account contract implementation](../../../tutorials/contract_tutorials/write_accounts_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts). Note that users must be able to receive funds in Aztec before deploying their account. A wallet should let a user generate a [deterministic complete address](../accounts/keys.md#complete-address) without having to interact with the network, so they can share it with others to receive funds. This requires that the wallet pins a specific contract implementation, its initialization arguments, a deployment salt, and a privacy key. These values yield a deterministic address, so when the account contract is actually deployed, it is available at the precalculated address. Once the account contract is deployed, the user can start sending transactions using it as the transaction origin. diff --git a/docs/docs/getting_started/codespaces.md b/docs/docs/getting_started/codespaces.md index 5d57ac291e2..bc6d494e7e9 100644 --- a/docs/docs/getting_started/codespaces.md +++ b/docs/docs/getting_started/codespaces.md @@ -4,11 +4,11 @@ sidebar_position: 0 draft: true --- -All machines are different, and you may not want to run the sandbox locally (for example when using Windows). We thought about you exactly ❤️ +If you do not want to run the sandbox locally, or if your machine is unsupported (eg Windows), it is possible to run it within a GitHub Codespace. -[Codespaces](https://github.com/features/codespaces) are a quick way to develop: they provision a remote machine with all tooling you need for Aztec in just a few minutes. We're big fans, so we prepared some prebuilt images to make it easier and faster. +[GitHub Codespaces](https://github.com/features/codespaces) are a quick way to develop: they provision a remote machine with all tooling you need for Aztec in just a few minutes. You can use some prebuilt images to make it easier and faster. -Just choose a boilerplate and click "create new codespace": +Choose a boilerplate and click "create new codespace": [![One-Click React Starter](/img/codespaces_badges/react_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Freact%2Fdevcontainer.json) [![One-Click HTML/TS Starter](/img/codespaces_badges/vanilla_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Fvanilla%2Fdevcontainer.json) [![One-Click Token Starter](/img/codespaces_badges/token_cta_badge.svg)](https://codespaces.new/AztecProtocol/aztec-packages?devcontainer_path=.devcontainer%2Ftoken%2Fdevcontainer.json) diff --git a/docs/docs/guides/local_env/creating_schnorr_accounts.md b/docs/docs/guides/local_env/creating_schnorr_accounts.md index 73f7e432b01..92c145af408 100644 --- a/docs/docs/guides/local_env/creating_schnorr_accounts.md +++ b/docs/docs/guides/local_env/creating_schnorr_accounts.md @@ -1,8 +1,11 @@ --- title: Creating Schnorr Accounts sidebar_position: 1 +draft: true --- + + ## Introduction This section shows how to create schnorr account wallets on the Aztec Sandbox. 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 500a0c314e6..0bf2c4f12f3 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 @@ -3,6 +3,14 @@ title: Running Multiple PXEs in the Sandbox sidebar_position: 2 --- +:::warning + +Unfortunately, this is currently not working due to a bug when attempting to run an `aztec` command with the sandbox running. This will be fixed in a future version. + +::: + +-- + When you run the sandbox, the Aztec node and PXE have their own http server. This makes it possible to run two PXEs on your local machine, which can be useful for testing that notes are accurately stored and remaining private in their respective PXEs. We are working on a better solution for this so expect an update soon, but currently you can follow this guide. @@ -12,20 +20,20 @@ We are working on a better solution for this so expect an update soon, but curre Rather than use the usual command, run: ```bash -cd ~/.aztec && docker-compose up +cd ~/.aztec && docker-compose -f ./docker-compose.sandbox.yml up ``` -This removes any other arguments, allowing you to ensure an isolated environment for the sandbox so it doesn't interfere with another PXE. +This removes any other arguments, allowing you to ensure an isolated environment for the sandbox so it doesn't interfere with another PXE. By default, the sandbox will run on port `8080`. ## Run PXE mode in another terminal In another terminal, run: ```bash -aztec start --pxe nodeUrl=http://localhost:8080/ +aztec start --port 8081 --pxe nodeUrl=http://host.docker.internal:8080/ ``` -This command uses the default ports, so they might need to be changed depending on yuor configuration. +This command uses the default ports, so they might need to be changed depending on yuor configuration. It will run the PXE on port `8081`. You should see something like this: diff --git a/docs/docs/guides/local_env/versions-updating.md b/docs/docs/guides/local_env/versions-updating.md index 708cc2b2c81..b310225bc25 100644 --- a/docs/docs/guides/local_env/versions-updating.md +++ b/docs/docs/guides/local_env/versions-updating.md @@ -3,9 +3,19 @@ title: Updating the Sandbox sidebar_position: 0 --- +- Current version: `#include_aztec_version` +- Update with `aztec-up` + +On this page you will find + +- [Understanding versions](#versions) +- [How to automatically update Aztec sandbox and aztec-nargo](#updating) +- [How to update Aztec.nr packages](#updating-aztecnr-packages) +- [How to update Aztec.js packages](#updating-aztecjs-packages) + ## Versions -Aztec tools (sandbox, nargo), dependencies (aztec-nr), and sample contracts are constantly being improved. +Aztec tools (sandbox, nargo), dependencies (Aztec.nr), and sample contracts are constantly being improved. When developing and referring to example .nr files/snippets, it is helpful to verify the versions of different components (below), and if required keep them in lock-step by [updating](#updating). ### Checking tool versions @@ -14,8 +24,6 @@ When developing and referring to example .nr files/snippets, it is helpful to ve The `aztec-nargo` versions follow `nargo` versions, which is different to the Aztec tool versions. ::: -The latest version of the Aztec tooling is currently `#include_aztec_version` , updating roughly every week. - ### Dependency versions Dependency versions in a contract's `Nargo.toml` file correspond to the `aztec-packages` repository tag `aztec-packages` (filter tags by `aztec`...) @@ -23,15 +31,11 @@ Dependency versions in a contract's `Nargo.toml` file correspond to the `aztec-p If you get an error like: `Cannot read file ~/nargo/github.com/AztecProtocol/aztec-packages/...` Check the `git=` github url, tag, and directory. -:::note -The folder structure changed at **0.24.0** from `yarn-project/aztec-nr` to `noir-projects/aztec-nr`. More details [here](../../migration_notes.md#aztecnr-aztec-nr-contracts-location-change-in-nargotoml) -::: - ### Example contract versions -Example contracts serve as a helpful reference between versions of the aztec-nr framework since they are strictly maintained with each release. +Example contracts serve as a helpful reference between versions of the Aztec.nr framework since they are strictly maintained with each release. -Code referenced in the documentation is sourced from contracts within [this directory](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts). +Code referenced in the documentation is sourced from contracts within [this directory (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts). As in the previous section, the location of the noir contracts moved at version `0.24.0`, from `yarn-project/noir-contracts` before, to `noir-projects/noir-contracts`. @@ -80,7 +84,7 @@ To set `VERSION` for a particular git tag, eg for [aztec-package-v**0.35.0**](ht VERSION=0.35.0 aztec-up ``` -2. Update aztec-nr and individual @aztec dependencies: +2. Update Aztec.nr and individual @aztec dependencies: Inside your project run: diff --git a/docs/docs/guides/smart_contracts/writing_contracts/authwit.md b/docs/docs/guides/smart_contracts/writing_contracts/authwit.md index b3a1e968923..ea5d8f1dae3 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/authwit.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/authwit.md @@ -85,7 +85,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/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. @@ -140,7 +140,7 @@ Then you will be able to import it into your contracts as follows. Based on the diagram earlier on this page let's take a look at how we can implement the `transfer` function such that it checks if the tokens are to be transferred `from` the caller or needs to be authenticated with an authentication witness. -#include_code transfer /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust +#include_code transfer_from /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust The first thing we see in the snippet above, is that if `from` is not the call we are calling the `assert_current_call_valid_authwit` function from [earlier](#private-functions). If the call is not throwing, we are all good and can continue with the transfer. 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 f649f4f8d8e..f67aad33653 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,13 @@ sidebar_position: 2 --- -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. + + +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 @@ -25,16 +31,4 @@ contract MyContract { There is no [`main()`](https://noir-lang.org/docs/getting_started/project_breakdown/#mainnr) function within a Noir `contract` scope. More than one function can be an entrypoint. ::: -### Directory structure - -Here's a common layout for a basic Aztec.nr Contract project: - -```title="layout of an aztec contract project" -─── my_aztec_contract_project - ├── src - │ ├── main.nr <-- your contract - └── Nargo.toml <-- package and dependency management -``` - -- 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). +To understand how to call a function from another contract, follow the [crowdfunding tutorial](../../../tutorials/contract_tutorials/crowdfunding_contract.md). \ No newline at end of file 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 00c036fe1dc..ab2a84333f0 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 @@ -51,11 +51,6 @@ If the decryption fails, the specific log will be discarded. For the PXE to successfully process the decrypted note we need to compute the note's 'note hash' and 'nullifier'. Aztec.nr enables smart contract developers to design custom notes, meaning developers can also customize how a note's note hash and nullifier should be computed. Because of this customizability, and because there will be a potentially-unlimited number of smart contracts deployed to Aztec, an PXE needs to be 'taught' how to compute the custom note hashes and nullifiers for a particular contract. This is done by a function called `compute_note_hash_and_optionally_a_nullifier`, which is automatically injected into every contract when compiled. -## Encrypted Events - -To emit generic event information as an encrypted log, call the context method `encrypt_and_emit_note`. Currently, only arrays of -fields are supported, and the PXE will fail to decrypt, process and store this data, so it will not be queryable automatically. - ## Unencrypted Events Unencrypted events are events which can be read by anyone. 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 90eded5ba29..c0805aecab8 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,13 +3,15 @@ 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 the 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). +This page is a quick introductory guide to creating historical proofs proofs from the archive tree. -# History library +For a reference, go [here](https://docs.aztec.network/reference/smart_contract_reference/aztec-nr/aztec/history/contract_inclusion). -The history library allows you to prove any of the following at a given block height before the current height: +## Inclusion and non-inclusion proofs + +Inclusion and non-inclusion proofs refer to proving the inclusion (or absence) of a specific piece of information within a specific Aztec block with a block header. You can prove any of the following at a given block height before the current height: - Note inclusion - Nullifier inclusion @@ -30,25 +32,13 @@ 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). - -## 1. Import the `history` library from `aztec` - -```rust -aztec::{ - #include_code imports noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr raw -} -``` - -This imports all functions from the `history` library. You should only import the functions you will use in your contract. - -## 2. Create a note to prove inclusion of +## Create a note to prove inclusion of In general you will likely have the note you want to prove inclusion of. But if you are just experimenting you can create a note with a function like below: #include_code create_note noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust -## 3. Get the note from the PXE +## Get the note from the PXE Retrieve the note from the user's PXE. @@ -56,46 +46,38 @@ Retrieve the note from the user's PXE. In this example, the user's notes are stored in a map called `private_values`. We retrieve this map, then select 1 note from it with the value of `1`. -## 4. Prove that a note was included in a specified block +## Prove that a note was included in a specified block -To prove that a note existed in a specified block, call `prove_note_inclusion_at` as shown in this example: +To prove that a note existed in a specified block, call `prove_note_inclusion` on the `header` as shown in this example: #include_code prove_note_inclusion noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust -This function takes in 3 arguments: - -1. The note (`maybe_note.unwrap_unchecked()`). Here, `unwrap_unchecked()` returns the inner value without asserting `self.is_some()` -2. The block number -3. Private context +Here, if `block_number` exists as an argument, it will prove inclusion in that block. Else, it will use the current block. -This will only prove the note existed at the specific block number, not whether or not the note has been nullified. You can prove that a note existed and had not been nullified in a specified block by using `prove_note_validity_at` which takes the same arguments: +This will only prove the note existed at the specific block number, not whether or not the note has been nullified. You can prove that a note existed and had not been nullified in a specified block by using `prove_note_validity` on the block header which takes the following arguments: #include_code prove_note_validity noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust -## 5. Create a nullifier to prove inclusion of +## Create a nullifier to prove inclusion of You can easily nullify a note like so: #include_code nullify_note noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust -This function gets a note from the PXE like we did in [step 3](#3-get-the-note-from-the-pxe) and nullifies it with `remove()`. +This function gets a note from the PXE and nullifies it with `remove()`. You can then compute this nullifier with `note.compute_nullifier(&mut context)`. -## 6. Prove that a nullifier was included in a specified block +## Prove that a nullifier was included in a specified block -Call `prove_nullifier_inclusion_at` like so: +Call `prove_nullifier_inclusion` on a block header like so: #include_code prove_nullifier_inclusion noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust -This takes three arguments: - -1. The nullifier -2. Block number -3. Private context +It takes the nullifier as an argument. -You can also prove that a nullifier was not included in a specified block by using `prove_nullifier_not_included_at` which takes the same arguments. +You can also prove that a note was not nullified in a specified block by using `prove_note_not_nullified` which takes the note and a reference to the private context. ## 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 historical proofs, check out the [reference](https://docs.aztec.network/reference/smart_contract_reference/aztec-nr/aztec/history/contract_inclusion) \ No newline at end of file diff --git a/docs/docs/guides/smart_contracts/writing_contracts/initializers.md b/docs/docs/guides/smart_contracts/writing_contracts/initializers.md index 80f7d3de38d..38f6b390fe8 100644 --- a/docs/docs/guides/smart_contracts/writing_contracts/initializers.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/initializers.md @@ -3,14 +3,25 @@ title: Defining Initializer Functions sidebar_position: 1 --- -This page explains how to write an initializer function. +This page explains how to write an initializer function, also known as a constructor. Initializers are regular functions that set an "initialized" flag (a nullifier) for the contract. A contract can only be initialized once, and contract functions can only be called after the contract has been initialized, much like a constructor. However, if a contract defines no initializers, it can be called at any time. Additionally, you can define as many initializer functions in a contract as you want, both private and public. -## Annotate with `#[aztec(private)]` and `#[aztec(initializer)]` +## Annotate with `#[aztec(initializer)]` Define your initializer like so: +```rust +#[aztec(initializer)] +fn constructor(){ + // function logic here +} +``` + +## Choose whether your initializer is public or private + +Aztec supports both public and private initializers. Use the appropriate macro, for example for a private initializer: + ```rust #[aztec(private)] #[aztec(initializer)] @@ -25,6 +36,14 @@ Initializers are commonly used to set an admin, such as this example: #include_code constructor /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust -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). +Here, the initializer is writing to storage. It can also call another function. Learn more about calling functions from functions [here](./call_functions.md). + +## Multiple initializers + +You can set multiple functions as an initializer function simply by annotating each of them with `#[aztec(initializer)]`. You can then decide which one to call when you are deploying the contract. + +Calling any one of the functions annotated with `#[aztec(initializer)]` will mark the contract as initialized. + +See [this page of the protocol specs](../../../protocol-specs/contract-deployment/instances.md#initialization) for more info about what marking a function as initialized means. To see an initializer in action, check out the [Counter Contract Tutorial](../../../tutorials/contract_tutorials/counter_contract.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 1c323b609f2..8a1594d05e2 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 @@ -47,7 +47,7 @@ Computing the `content` must currently be done manually, as we are still adding #include_code claim_public /noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr rust :::info -The `content_hash` is a sha256 truncated to a field element (~ 254 bits). In Aztec-nr, you can use our `sha256_to_field()` to do a sha256 hash which fits in one field element +The `content_hash` is a sha256 truncated to a field element (~ 254 bits). In Aztec.nr, you can use our `sha256_to_field()` to do a sha256 hash which fits in one field element ::: ### Token portal hash library diff --git a/docs/docs/migration_notes.md b/docs/docs/migration_notes.md index 6ef3bacf6f0..685ba62b85c 100644 --- a/docs/docs/migration_notes.md +++ b/docs/docs/migration_notes.md @@ -1103,7 +1103,7 @@ Now: import { TokenContract } from "@aztec/noir-contracts.js/Token"; ``` -### [Aztec.nr] aztec-nr contracts location change in Nargo.toml +### [Aztec.nr] Aztec.nr contracts location change in Nargo.toml Aztec contracts are now moved outside of the `yarn-project` folder and into `noir-projects`, so you need to update your imports. diff --git a/docs/docs/protocol-specs/bytecode/index.md b/docs/docs/protocol-specs/bytecode/index.md index c94d9789fc5..c863019b947 100644 --- a/docs/docs/protocol-specs/bytecode/index.md +++ b/docs/docs/protocol-specs/bytecode/index.md @@ -83,7 +83,7 @@ The exact form of the artifact is not specified by the protocol, but it needs at | Field | Type | Description | |----------|----------|----------| | `name` | `string` | The name of the contract. | -| `compilerVersion` | `string` | Version of the compiler that generated the bytecode. This is a string to convey extra information like the version of aztec-nr used. | +| `compilerVersion` | `string` | Version of the compiler that generated the bytecode. This is a string to convey extra information like the version of Aztec.nr used. | | `functions` | [FunctionEntry[]](#function-entry) | The functions of the contract. | | `publicBytecode` | `string` | The AVM bytecode of the public functions, converted to base64. | | `events` | [EventAbi[]](#event-abi) | The events of the contract. | diff --git a/docs/docs/protocol-specs/calls/public-private-messaging.md b/docs/docs/protocol-specs/calls/public-private-messaging.md index c2e6e185e1c..e438f49d96e 100644 --- a/docs/docs/protocol-specs/calls/public-private-messaging.md +++ b/docs/docs/protocol-specs/calls/public-private-messaging.md @@ -63,7 +63,7 @@ When a private function calls a public function: ### Handling Privacy Leakage and `msg.sender` -The sequencer only sees the data in the [`transaction_object`](../transactions/tx-object.md), which shouldn't expose any private information. There are some [practical caveats](http://docs.aztec.network). +The sequencer only sees the data in the [`transaction_object`](../transactions/tx-object.md), which shouldn't expose any private information. There are some practical caveats. When making a private-to-public call, the `msg_sender` will become public. If this is the actual user, then it leaks privacy. If `msg_sender` is some application's contract address, this leaks which contract is calling the public method and therefore leaks which contract the user was interacting with in private land. diff --git a/docs/docs/reference/smart_contract_reference/history_lib_reference.md b/docs/docs/reference/smart_contract_reference/history_lib_reference.md deleted file mode 100644 index a717c3fb9e6..00000000000 --- a/docs/docs/reference/smart_contract_reference/history_lib_reference.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: History Reference -sidebar_position: 3 ---- - - - -## Note inclusion - -Note inclusion proves that a note existed (its hash was included in a note hash tree) in a block header. - -### prove_note_inclusion - -`prove_note_inclusion` takes 1 parameter: - -| Name | Type | Description | -| ---- | ---- | -------------------------------------- | -| note | Note | The note you are proving inclusion for | - -#### Example - -#include_code prove_note_inclusion noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust - -## Note validity - -This proves that a note exists and has not been nullified in a specific block header. - -### prove_note_validity - -`prove_note_validity` takes 2 parameters: - -| Name | Type | Description | -| ---------------- | -------------- | -------------------------------------- | -| note_with_header | Note | The note you are proving inclusion for | -| context | PrivateContext | Private context | - -#### Example - -#include_code prove_note_validity noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust - -## Nullifier inclusion - -This proves that a nullifier exists in a given block header (can be used to prove that a note had been nullified). - -### prove_nullifier_inclusion - -`prove_nullifier_inclusion` takes 1 parameter: - -| Name | Type | Description | -| --------- | ----- | ------------------------------------------- | -| nullifier | Field | The nullifier you are proving inclusion for | - -#### Example - -#include_code prove_nullifier_inclusion noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust - -### prove_note_is_nullified - -Instead of passing the nullifier, you can check that a note has been nullified by passing the note. - -#### Implementation - -#include_code prove_note_is_nullified noir-projects/aztec-nr/aztec/src/history/nullifier_inclusion.nr rust - -## Nullifier non inclusion - -This proves that a nullifier was not included in a certain block, given the block header (can be used to prove that a note had not yet been nullified in a given block). - -### prove_nullifier_non_inclusion - -`prove_nullifier_non_inclusion` takes 1 parameters: - -| Name | Type | Description | -| --------- | ----- | ------------------------------------------- | -| nullifier | Field | The nullifier you are proving inclusion for | - -#### Example - -#include_code prove_nullifier_non_inclusion noir-projects/aztec-nr/aztec/src/history/contract_inclusion.nr rust - -### prove_note_not_nullified - -Instead of passing the nullifier, you can check that a note has not been nullified by passing the note. - -#### Implementation - -#include_code prove_note_not_nullified noir-projects/aztec-nr/aztec/src/history/nullifier_non_inclusion.nr rust - -## Public storage historical reads - -These return the value stored in a public storage slot of a given contract at the end of the execution of a certain block (the latest one if using `public_storage_historical_read`). - -Note that it is never possible to read the _current_ value in a public storage slot in private since private execution is local and by definition always works on _historical_ state. - -### public_storage_historical_read - -`public_storage_historical_read` takes 2 parameters: - -| Name | Type | Description | -| ---------------- | ------------ | --------------------------------------- | -| storage_slot | Field | Storage slot | -| contract_address | AztecAddress | The contract that owns the storage slot | - -#### Example - -#include_code public_storage_historical_read noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust - -## Contract inclusion - -This proves that a contract exists in, ie had been deployed before or in, a certain block. - -### prove_contract_deployment - -`prove_contract_deployment` takes 1 parameter: - -| Name | Type | Description | -| ---------------- | ------------ | ------------------------------------------- | -| contract_address | AztecAddress | The contract address to prove deployment of | - -#### Example - -#include_code prove_contract_deployment noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust - -### prove_contract_non_deployment - -`prove_contract_non_deployment` takes 1 parameter: - -| Name | Type | Description | -| ---------------- | ------------ | ----------------------------------------------- | -| contract_address | AztecAddress | The contract address to prove non-deployment of | - -#### Example - -#include_code prove_contract_non_deployment noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust - -### prove_contract_initialization - -`prove_contract_initialization` takes 1 parameter: - -| Name | Type | Description | -| ---------------- | ------------ | ----------------------------------------------- | -| contract_address | AztecAddress | The contract address to prove initialization of | - -#### Example - -#include_code prove_contract_initialization noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust - -### prove_contract_non_initialization - -`prove_contract_non_initialization` takes 1 parameter: - -| Name | Type | Description | -| ---------------- | ------------ | --------------------------------------------------- | -| contract_address | AztecAddress | The contract address to prove non-initialization of | - -#### Example - -#include_code prove_contract_non_initialization noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr rust diff --git a/docs/docs/tutorials/aztecjs-getting-started.md b/docs/docs/tutorials/aztecjs-getting-started.md index 6f9d145da5e..ff99ce941f8 100644 --- a/docs/docs/tutorials/aztecjs-getting-started.md +++ b/docs/docs/tutorials/aztecjs-getting-started.md @@ -11,13 +11,13 @@ This guide assumes you have followed the [quickstart](../getting_started.md). ## Prerequisites -- A running [Aztec sandbox](../getting_started.md) +- A running Aztec sandbox ## Set up the project We will deploy a pre-compiled token contract, and send tokens privately, using the Sandbox. -We will create a `yarn` project called `token` (although `npm` works fine too). +We will create a `yarn` TypeScript project called `token` (although `npm` works fine too). 1. Initialize a yarn project @@ -33,13 +33,13 @@ yarn init -yp mkdir src ``` -3. Add necessary yarn packages (and optionally add typescript too) +3. Add necessary yarn packages ```sh yarn add @aztec/aztec.js @aztec/accounts @aztec/noir-contracts.js typescript @types/node ``` -4. [Optional] If creating a typescript file, add a `tsconfig.json` file into the project root, here is an example: +4. Add a `tsconfig.json` file into the project root and paste this: ```json { @@ -67,16 +67,9 @@ yarn add @aztec/aztec.js @aztec/accounts @aztec/noir-contracts.js typescript @ty } ``` -5. Update `package.json` - Add a `scripts` section to `package.json` and set `"type": "module"`: +5. Add this to your `package.json`: ```json -{ - "name": "token", - "version": "1.0.0", - "description": "My first token contract", - "main": "index.js", - "author": "1000x Dev", - "license": "MIT", "type": "module", "scripts": { "build": "yarn clean && tsc -b", @@ -84,14 +77,6 @@ yarn add @aztec/aztec.js @aztec/accounts @aztec/noir-contracts.js typescript @ty "clean": "rm -rf ./dest tsconfig.tsbuildinfo", "start": "yarn build && DEBUG='token' node ./dest/index.js" }, - "dependencies": { - "@aztec/accounts": "latest", - "@aztec/aztec.js": "latest", - "@aztec/noir-contracts.js": "latest", - "@types/node": "^20.6.3", - "typescript": "^5.2.2" - } -} ``` 6. Create an `index.ts` file in the `src` directory with the following sandbox connection setup: @@ -148,11 +133,9 @@ The sandbox is preloaded with multiple accounts so you don't have to sit and cre 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.md). - ## Deploy a contract -Now that we have our accounts loaded, let's move on to deploy our pre-compiled token smart contract. You can find the full code for the contract [here](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-contracts/contracts/token_contract/src). Add this to `index.ts` below the code you added earlier: +Now that we have our accounts loaded, let's move on to deploy our pre-compiled token smart contract. You can find the full code for the contract [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-contracts/contracts/token_contract/src). Add this to `index.ts` below the code you added earlier: #include_code Deployment /yarn-project/end-to-end/src/composed/e2e_sandbox_example.test.ts typescript @@ -353,8 +336,15 @@ 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.md). +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 [on the Concepts page here](../aztec/concepts/transactions.md). ## Next Steps -Write your first account contract on the [next page](./write_accounts_contract.md). +### Build a fullstack Aztec project + +Follow the dapp tutorial on the [next page](./simple_dapp/index.md). + +### Optional: Learn more about concepts mentioned here + +- [Authentication witness](../aztec/concepts/accounts/authwit.md) +- [Functions under the hood](../aztec/concepts/smart_contracts/functions/inner_workings.md) \ No newline at end of file diff --git a/docs/docs/tutorials/contract_tutorials/advanced/_category_.json b/docs/docs/tutorials/contract_tutorials/advanced/_category_.json index 81a03772f7d..5fe169c13f3 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/_category_.json +++ b/docs/docs/tutorials/contract_tutorials/advanced/_category_.json @@ -1,6 +1,6 @@ { "label": "Advanced", - "position": 5, + "position": 6, "collapsible": true, "collapsed": true } diff --git a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/0_setup.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/0_setup.md index 03307f46596..42a082ffdce 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/0_setup.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/0_setup.md @@ -19,8 +19,10 @@ We recommend going through this setup to fully understand where things live. - [docker](https://docs.docker.com/) - [Aztec sandbox](../../../../getting_started.md) - you should have this running before starting the tutorial +Start the sandbox + ```bash -/bin/sh -c "$(curl -fsSL 'https://sandbox.aztec.network')" +aztec start --sandbox ``` ## Create the root project and packages @@ -45,7 +47,7 @@ cd packages && mkdir aztec-contracts Inside `aztec-contracts` create a new contract project like this: ```bash -aztec-nargo new --contract token_bridge +cd aztec-contracts && aztec-nargo new --contract token_bridge ``` Your file structure should look something like this: diff --git a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/2_minting_on_aztec.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/2_minting_on_aztec.md index e5ee2372439..a9897a29979 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/2_minting_on_aztec.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/2_minting_on_aztec.md @@ -6,9 +6,14 @@ In this step we will start writing our Aztec.nr bridge smart contract and write ## Initial contract setup -In our `token-bridge` Aztec project in `aztec-contracts`, under `src` there is an example `main.nr` file. Paste this to define imports and initialize the constructor: +In our `token-bridge` Aztec project in `aztec-contracts`, under `src` there is an example `main.nr` file. Paste this to define imports: -#include_code token_bridge_imports /noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr rust +```rust +#include_code token_bridge_imports /noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr raw +} +``` + +Inside this block (before the last `}`), paste this to initialize the constructor: #include_code token_bridge_storage_and_constructor /noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr rust diff --git a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/3_withdrawing_to_l1.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/3_withdrawing_to_l1.md index 19e90a10f5d..6d66f2a1bef 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/3_withdrawing_to_l1.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/3_withdrawing_to_l1.md @@ -6,7 +6,7 @@ This is where we have tokens on Aztec and want to withdraw them back to L1 (i.e. ## Withdrawing publicly -Go back to your `main.nr` and paste this: +In your `main.nr` paste this: #include_code exit_to_l1_public /noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr rust @@ -69,7 +69,7 @@ Compile your Solidity contracts using hardhat. Run this in the `packages` direct ```bash cd l1-contracts -npx hardhat compile +yarn hardhat compile ``` And compile your Aztec.nr contracts like this: @@ -87,6 +87,6 @@ And generate the TypeScript interface for the contract and add it to the test di aztec codegen target -o ../../src/test/fixtures ``` -This will create a TS interface inside `fixtures` dir in our `src/test` folder! +This will create a TS interface inside `fixtures` dir in our `src/test` folder! In the next step we will write the TypeScript code to deploy our contracts and call on both L1 and L2 so we can see how everything works together. diff --git a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/4_typescript_glue_code.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/4_typescript_glue_code.md index d00987b585f..7d0a03592a7 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/4_typescript_glue_code.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/4_typescript_glue_code.md @@ -160,6 +160,17 @@ cd packages/src DEBUG='aztec:e2e_uniswap' yarn test ``` -### Error handling - Note - you might have a jest error at the end of each test saying "expected 1-2 arguments but got 3". In case case simply remove the "120_000" at the end of each test. We have already set the timeout at the top so this shouldn't be a problem. + +**Congratulations!** You have just written a set of contracts for Ethereum and Aztec that have private and public interactions with each other, and tested them with TypeScript. + +## Next Steps + +### Follow a more detailed Aztec.js tutorial + +Follow the tutorial on the [next page](../../../aztecjs-getting-started.md). + +### Optional: Learn more about concepts mentioned here + +- [Portals (protocol specs)](../../../../protocol-specs/l1-smart-contracts/index.md) +- [Functions under the hood (concepts)](../../../../aztec/concepts/smart_contracts/functions/inner_workings.md) \ No newline at end of file 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 a2259479589..f38ea62322b 100644 --- a/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md @@ -5,7 +5,7 @@ sidebar_position: 2 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 page in the protocol specs](../../../../protocol-specs/l1-smart-contracts/index.md). ## A refresher on Portals @@ -36,20 +36,18 @@ 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). - ## Building a Token Bridge with Portals The goal for this tutorial is to create functionality such that a token can be bridged to and from Aztec. We’ll be using L1 to refer to Ethereum and L2 to refer to Aztec. 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](../../token_contract.md)). +Let’s assume a token exists on Ethereum and Aztec (see a [the token tutorial](../../token_contract.md)). We will build: -- a `Token Portal` solidity contract on L1 that will be responsible for sending messages to the Inbox and consuming from the Outbox. -- a `Token Bridge` aztec-nr contract on L2 that can consume L1 to L2 messages to mint tokens on L2 and create L2 to L1 messages to withdraw tokens back to L1. +- a `Token Portal` Solidity contract on L1 that will be responsible for sending messages to the Inbox and consuming from the Outbox. +- a `Token Bridge` Aztec.nr contract on L2 that can consume L1 to L2 messages to mint tokens on L2 and create L2 to L1 messages to withdraw tokens back to L1. - Some TypeScript code that can call the methods on the contracts and communicate with the sandbox. Our contracts will be able to work with _both_ private and public state i.e. how to deposit tokens into Aztec privately and publicly and withdraw tokens privately and publicly. diff --git a/docs/docs/tutorials/contract_tutorials/counter_contract.md b/docs/docs/tutorials/contract_tutorials/counter_contract.md index 1e138b93286..887954c9cba 100644 --- a/docs/docs/tutorials/contract_tutorials/counter_contract.md +++ b/docs/docs/tutorials/contract_tutorials/counter_contract.md @@ -106,7 +106,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/index.md). +We have annotated this and other functions with `#[aztec(private)]` which are ABI macros so the compiler understands it will handle private inputs. ## Incrementing our counter @@ -151,3 +151,13 @@ aztec codegen -o src/artifacts target ``` You can now use the artifact and/or the TS class in your Aztec.js! + +## Next Steps + +### Write a slightly more complex Aztec contract + +Follow the private voting contract tutorial on the [next page](./private_voting_contract.md). + +### Optional: Learn more about concepts mentioned here + + - [Functions and annotations like `#[aztec(private)]`](../../aztec/concepts/smart_contracts/functions/index.md) \ No newline at end of file diff --git a/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md b/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md index 168be40d51c..9c5dcfd260f 100644 --- a/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md +++ b/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md @@ -75,8 +75,6 @@ Replace the example functions with an initializer that takes the required campai } ``` -More about initializers [here](../../guides/smart_contracts/writing_contracts/initializers.md). - #### Dependencies When you compile the contracts by running `aztec-nargo compile` in your project directory, you'll notice it cannot resolve `AztecAddress`. (Or hovering over in VSCode) @@ -99,8 +97,6 @@ A word about versions: - Choose the aztec packages version to match your aztec sandbox version - Check that your `compiler_version` in Nargo.toml is satisified by your aztec compiler - `aztec-nargo -V` -More about versions [here](../../guides/local_env/versions-updating.md). - Inside the Crowdfunding contract definition, use the dependency that defines the address type `AztecAddress` (same syntax as Rust) ```rust @@ -135,7 +131,7 @@ You can compile the code so far with `aztec-nargo compile`. #### Checking campaign duration against the timestamp -To check that the donation occurs before the campaign deadline, we must access the public `timestamp`. It is one of several [Public Global Variables](../../reference/smart_contract_reference/globals). +To check that the donation occurs before the campaign deadline, we must access the public `timestamp`. It is one of several public global variables. Declare an Aztec function that is public and internal @@ -151,7 +147,7 @@ Read the deadline from storage and assert that the `timestamp` from this context --- -Since donations are to be private, the donate function will have the user's private context which has these [Private Global Variables](../../reference/smart_contract_reference/globals.md). So from the private context there is a little extra to call the (public internal) `_check_deadline` function. +Since donations are to be private, the donate function will have the user's private context which has these private global variables. So from the private context there is a little extra to call the (public internal) `_check_deadline` function. ```rust #include_code call-check-deadline /noir-projects/noir-contracts/contracts/crowdfunding_contract/src/main.nr raw @@ -165,7 +161,7 @@ Now conclude adding all dependencies to the `Crowdfunding` contract: #include_code all-deps /noir-projects/noir-contracts/contracts/crowdfunding_contract/src/main.nr rust -Like before, you can find these and other `aztec::protocol_types` [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-protocol-circuits/crates/types/src). +Like before, you can find these and other `aztec::protocol_types` [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-protocol-circuits/crates/types/src). #### Interfacing with another contract @@ -180,7 +176,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/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). +The user must have authorised this action, 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 @@ -197,19 +193,34 @@ The remaining function to implement, `withdraw`, is reasonably straight-forward: 2. transfer tokens from the contract to the operator 3. reveal that an amount has been withdrawn to the operator -The last point is achieved by emitting an unencrypted event log, more [here](../../guides/smart_contracts/writing_contracts/how_to_emit_event.md#unencrypted-events). +The last point is achieved by emitting an unencrypted event log. Copy the last function into your Crowdfunding contract: #include_code operator-withdrawals /noir-projects/noir-contracts/contracts/crowdfunding_contract/src/main.nr rust -You should be able to compile successfully with `aztec-nargo compile`. +You should be able to compile successfully with `aztec-nargo compile`. -## Conclusion +**Congraulations,** you have just built a multi-contract project on Aztec! -For comparison, the full Crowdfunding contract can be found [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-contracts/contracts/crowdfunding_contract). +## Conclusion -### Next steps? +For comparison, the full Crowdfunding contract can be found [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-contracts/contracts/crowdfunding_contract). If a new token wishes to honour donors with free tokens based on donation amounts, this is possible via the donation_receipts (a `PrivateSet`). See [claim_contract](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-contracts/contracts/claim_contract). + +## Next steps + +### Build an accounts contract + +Follow the account contract tutorial on the [next page](./write_accounts_contract.md) and learn more about account abstraction. + +### Optional: Learn more about concepts mentioned here + + - [Initializer functions](../../guides/smart_contracts/writing_contracts/initializers.md) + - [Versions](https://docs.aztec.network/developers/versions-updating). + - [Private Global Variables](https://docs.aztec.network/developers/contracts/references/globals#private-global-variables) + - [Authorizing actions](../../aztec/concepts/accounts/index.md#authorizing-actions) + - [Unencrypted logs](https://docs.aztec.network/developers/contracts/writing_contracts/events/emit_event#unencrypted-events) + - [Common dependencies](https://docs.aztec.network/developers/contracts/resources/dependencies) diff --git a/docs/docs/tutorials/contract_tutorials/private_voting_contract.md b/docs/docs/tutorials/contract_tutorials/private_voting_contract.md index 2d6b4342f67..8eab842357a 100644 --- a/docs/docs/tutorials/contract_tutorials/private_voting_contract.md +++ b/docs/docs/tutorials/contract_tutorials/private_voting_contract.md @@ -67,11 +67,11 @@ Inside this, paste these imports: #include_code imports noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr rust -We are using various utils within the Aztec library: +We are using various utils within the Aztec `prelude` library: -- `PrivateContext` - exposes things such as the contract address, msg_sender, etc - `AztecAddress` - A type for storing an address on Aztec - `FunctionSelector` - Used for computing a selector to call a function +- `PrivateContext` - exposes things such as the contract address, msg_sender, etc - `Map` - A data storage type for storing candidates with the number of votes they have - `PublicMutable` - A type of storage, which holds a mutable public value. We'll store votes as PublicMutables - `SharedImmutable` - an immutable storage value that is accessible in private and public execution. @@ -112,9 +112,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. -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. +To do this, we make an oracle call to fetch the caller's secret key, hash it to create a nullifier, and push the nullifier to Aztec. 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. @@ -138,7 +138,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. ## Allowing an admin to end a voting period @@ -166,11 +166,17 @@ Use `aztec codegen` to generate the Typescript artifact for the contract: aztec codegen target --outdir src/artifacts ``` -Once it is compiled you can [deploy](../../guides/smart_contracts/how_to_deploy_contract.md) it to the sandbox. +**Congratulations, you have written and compiled a private voting smart contract!** Once it is compiled you can deploy it to the sandbox! ## 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: +### Learn how contracts can work together + +Follow the crowdfunding contracts tutorial on the [next page](./crowdfunding_contract.md). + +### Optional: Learn more about concepts mentioned here -- 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 -- Go to the [next tutorial](token_contract.md) and learn how to write a token contract + - [Unconstrained functions](../../aztec/concepts/pxe/acir_simulator.md#unconstrained-functions). + - [Oracles](../../aztec/concepts/smart_contracts/oracles/index.md) + - [Nullifier secrets](../../aztec/concepts/accounts/keys.md#nullifier-secrets). + - [How to deploy a contract to the sandbox](../../guides/smart_contracts/how_to_deploy_contract.md) \ No newline at end of file diff --git a/docs/docs/tutorials/contract_tutorials/token_contract.md b/docs/docs/tutorials/contract_tutorials/token_contract.md index a01271af73f..f3d58d4490f 100644 --- a/docs/docs/tutorials/contract_tutorials/token_contract.md +++ b/docs/docs/tutorials/contract_tutorials/token_contract.md @@ -1,6 +1,6 @@ --- -title: "Private token contract" -sidebar_position: 4 +title: "Private & Public token contract" +sidebar_position: 5 --- In this tutorial we will go through writing an L2 native token contract @@ -17,7 +17,7 @@ In this tutorial you will learn how to: - Handle different private note types - Pass data between private and public state -We are going to start with a blank project and fill in the token contract source code defined on Github [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-contracts/contracts/token_contract/src/main.nr), and explain what is being added as we go. +We are going to start with a blank project and fill in the token contract source code defined [here (GitHub Link)](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-contracts/contracts/token_contract/src/main.nr), and explain what is being added as we go. ## Requirements @@ -56,116 +56,11 @@ compressed_string = {git="https://github.com/AztecProtocol/aztec-packages/", tag We will be working within `main.nr` for the rest of the tutorial. -## Contract Interface +## How this will work -Remove everything from `main.nr` and paste this: +Before writing the functions, let's go through them to see how this contract will work: -```rust -contract Token { - #[aztec(public)] - #[aztec(initializer)] - fn constructor() {} - - #[aztec(public)] - fn set_admin(new_admin: AztecAddress) {} - - #[aztec(public)] - fn set_minter(minter: AztecAddress, approve: bool) {} - - #[aztec(public)] - fn mint_public(to: AztecAddress, amount: Field) -> Field {} - - #[aztec(public)] - fn mint_private(amount: Field, secret_hash: Field) -> Field {} - - #[aztec(public)] - fn shield(from: AztecAddress, amount: Field, secret_hash: Field, nonce: Field) -> Field {} - - #[aztec(public)] - fn transfer_public(from: AztecAddress, to: AztecAddress, amount: Field, nonce: Field) -> Field {} - - #[aztec(public)] - fn burn_public(from: AztecAddress, amount: Field, nonce: Field) -> Field {} - - // Private functions - - #[aztec(private)] - fn redeem_shield(to: AztecAddress, amount: Field, secret: Field) -> Field {} - - #[aztec(private)] - fn unshield(from: AztecAddress, to: AztecAddress, amount: Field, nonce: Field) -> Field {} - - #[aztec(private)] - fn transfer(from: AztecAddress, to: AztecAddress, amount: Field, nonce: Field) -> Field {} - - #[aztec(private)] - fn transfer_from(from: AztecAddress, to: AztecAddress, amount: Field, nonce: Field) {} - - #[aztec(private)] - fn cancel_authwit(inner_hash: Field) {} - - #[aztec(private)] - fn burn(from: AztecAddress, amount: Field, nonce: Field) -> Field {} - - // Internal functions - - #[aztec(internal)] - #[aztec(public)] - fn _increase_public_balance(to: AztecAddress, amount: Field) {} - - #[aztec(internal)] - #[aztec(public)] - fn _reduce_total_supply(amount: Field) {} - - // View functions - - #[aztec(public)] - #[aztec(view)] - fn public_get_name() -> pub FieldCompressedString {} - - #[aztec(private)] - #[aztec(view)] - fn private_get_name() -> pub FieldCompressedString {} - - #[aztec(public)] - #[aztec(view)] - fn public_get_symbol() -> pub FieldCompressedString {} - - #[aztec(public)] - #[aztec(view)] - fn public_get_decimals() -> pub u8 {} - - #[aztec(private)] - #[aztec(view)] - fn private_get_decimals() -> pub u8 {} - - #[aztec(public)] - #[aztec(view)] - fn admin() -> Field {} - - #[aztec(public)] - #[aztec(view)] - fn is_minter(minter: AztecAddress) -> bool {} - - #[aztec(public)] - #[aztec(view)] - fn total_supply() -> Field {} - - #[aztec(public)] - #[aztec(view)] - fn balance_of_public(owner: AztecAddress) -> Field {} - - // Unconstrained functions (read only) - - unconstrained fn balance_of_private(owner: AztecAddress) -> Field {} -} -``` - -This specifies the interface of the `Token` contract. Don't worry if you get some warnings - we haven't imported our types yet. - -Before we through the interface and implement each function, let's review the functions to get a sense of what the contract does. - -### Initializer interface +### Initializer There is one `initilizer` function in this contract, and it will be selected and executed once when the contract is deployed, similar to a constructor in Solidity. This is marked private, so the function logic will not be transparent. To execute public function logic in the constructor, this function will call `_initialize` (marked internal, more detail below). @@ -183,7 +78,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 and nullifiers, 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 @@ -227,13 +122,16 @@ Before we can implement the functions, we need set up the contract storage, and :::info Copy required files -We will be going over the code in `main.nr` [here](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts/token_contract/src). If you are following along and want to compile `main.nr` yourself, you need to add the other files in the directory as they contain imports that are used in `main.nr`. +We will be going over the code in `main.nr` [here (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts/token_contract/src). If you are following along and want to compile `main.nr` yourself, you need to add the other files in the directory as they contain imports that are used in `main.nr`. ::: -Just below the contract definition, add the following imports: +Paste these imports: -#include_code imports /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust +```rust +#include_code imports /noir-projects/noir-contracts/contracts/token_contract/src/main.nr raw +} +``` We are importing: @@ -242,8 +140,6 @@ 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/index.md). - ### Types files We are also importing types from a `types.nr` file, which imports types from the `types` folder. You can view them [here](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts/token_contract/src). @@ -252,7 +148,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). ## Contract Storage @@ -272,8 +168,6 @@ Reading through the storage variables: - `public_balances` is a mapping of Aztec addresses in public state and represents the publicly viewable balances of accounts. - `symbol`, `name`, and `decimals` are similar in meaning to ERC20 tokens on Ethereum. -You can read more about it [here](../../aztec/concepts/storage/index.md). - ## Functions Copy and paste the body of each function into the appropriate place in your project if you are following along. @@ -286,9 +180,7 @@ This function sets the creator of the contract (passed as `msg_sender` from the ### Public function implementations -Public functions are declared with the `#[aztec(public)]` macro above the function name like so: - -#include_code set_admin /noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust +Public functions are declared with the `#[aztec(public)]` macro above the function name. As described in the [execution contexts section above](#execution-contexts), public function logic and transaction information is transparent to the world. Public functions update public state, but can be used to prepare data to be used in a private context, as we will go over below (e.g. see the [shield](#shield) function). @@ -485,12 +377,17 @@ aztec codegen target -o src/artifacts ## Next Steps -### Testing - -Review [the end to end tests](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/end-to-end/src/e2e_token_contract/) for reference. - ### Token Bridge Contract 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. + +### Optional: Dive deeper into this contract and concepts mentioned here + +- Review [the end to end tests (Github link)](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn-project/end-to-end/src/e2e_token_contract/) for reference. +- [Commitments (Wikipedia link)](https://en.wikipedia.org/wiki/Commitment_scheme) +- [Nullifiers](../../aztec/concepts/storage/trees/index.md#nullifier-tree) +- [Contract Communication](../../aztec/concepts/smart_contracts/communication/index.md). +- [Contract Storage](../../aztec/concepts/storage/index.md) +- [Authwit](../../aztec/concepts/accounts/authwit.md) diff --git a/docs/docs/tutorials/write_accounts_contract.md b/docs/docs/tutorials/contract_tutorials/write_accounts_contract.md similarity index 78% rename from docs/docs/tutorials/write_accounts_contract.md rename to docs/docs/tutorials/contract_tutorials/write_accounts_contract.md index d2ed9a69883..82e32e53173 100644 --- a/docs/docs/tutorials/write_accounts_contract.md +++ b/docs/docs/tutorials/contract_tutorials/write_accounts_contract.md @@ -1,5 +1,6 @@ --- -title: Writing an Account Contract +title: Account Contract +sidebar_position: 4 tags: [accounts] --- @@ -14,15 +15,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/accounts/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 in the Aztec network. -It is highly recommended that you understand how an [account](../aztec/concepts/accounts/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/accounts/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 @@ -30,7 +31,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 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 @@ -50,7 +51,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). ### Nonce Abstraction @@ -84,7 +85,7 @@ 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#incoming-viewing-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#incoming-viewing-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 @@ -100,9 +101,16 @@ To make sure that we are actually validating the provided signature in our accou Lo and behold, we get `Error: Assertion failed: 'verification == true'` when running the snippet above, pointing to the line in our account contract where we verify the Schnorr signature. -## Resources +## Next Steps -Account contracts source code: +### Build a hybrid token tutorial -- [ECDSA signer account contract](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-contracts/contracts/ecdsa_account_contract/src/main.nr) -- [Schnorr signer account contract](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts/schnorr_account_contract) +Follow the token contract tutorial on the [next page](./token_contract.md) and learn more about hybrid state. + +### Optional: Learn more about concepts mentioned here + +- [ECDSA signer account contract (GitHub link)](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/noir-contracts/contracts/ecdsa_account_contract/src/main.nr) +- [Schnorr signer account contract (GitHub link)](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/noir-contracts/contracts/schnorr_account_contract) +- [Account abstraction](../../aztec/concepts/accounts/index.md#what-is-account-abstraction) +- [Authentication witness](../../aztec/concepts/accounts/authwit.md) +- [Fee abstraction](../../protocol-specs/gas-and-fees/tx-setup-and-teardown.md). \ No newline at end of file diff --git a/noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr b/noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr index e29a9754652..2726584e58a 100644 --- a/noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr +++ b/noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr @@ -1,9 +1,6 @@ contract EasyPrivateVoting { // docs:start:imports - use dep::aztec::prelude::{ - AztecAddress, FunctionSelector, NoteHeader, NoteInterface, NoteGetterOptions, PrivateContext, - Map, PublicMutable, SharedImmutable - }; + use dep::aztec::prelude::{AztecAddress, FunctionSelector, PrivateContext, Map, PublicMutable, SharedImmutable}; // docs:end:imports // docs:start:storage_struct #[aztec(storage)] diff --git a/noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr b/noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr index 436d286b99a..2c9e092e2da 100644 --- a/noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr +++ b/noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/main.nr @@ -8,9 +8,6 @@ contract InclusionProofs { use dep::aztec::protocol_types::{contract_class_id::ContractClassId, header::Header}; use dep::aztec::{note::note_getter_options::NoteStatus}; - // docs:start:imports - // Imports are not needed as inclusion / non_inclusion proofs are accessible on the header. - // docs:end:imports // docs:start:value_note_imports use dep::value_note::value_note::ValueNote; // docs:end:value_note_imports @@ -58,13 +55,14 @@ contract InclusionProofs { let note = private_values.get_notes(options).get(0); // docs:end:get_note_from_pxe + // docs:start:prove_note_inclusion // 2) Prove the note inclusion let header = if (use_block_number) { context.get_header_at(block_number) } else { context.get_header() }; - // docs:start:prove_note_inclusion + header.prove_note_inclusion(note); // docs:end:prove_note_inclusion }