From fb654ffc3cfc5d84ec489583a8f5900e28a8123c Mon Sep 17 00:00:00 2001 From: josh crites Date: Fri, 25 Oct 2024 14:45:57 -0400 Subject: [PATCH 1/7] update authwit --- docs/docs/aztec/concepts/accounts/authwit.md | 11 ++++++++++- .../smart_contracts/writing_contracts/authwit.md | 4 ++-- 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/docs/docs/aztec/concepts/accounts/authwit.md b/docs/docs/aztec/concepts/accounts/authwit.md index e24d5a2057c..a0d1cbe32c1 100644 --- a/docs/docs/aztec/concepts/accounts/authwit.md +++ b/docs/docs/aztec/concepts/accounts/authwit.md @@ -59,9 +59,10 @@ Adopting ERC20 for Aztec is not as simple as it might seem because of private st If you recall from the [Hybrid State model](../state_model/index.md), private state is generally only known by its owner and those they have shared it with. Because it relies on secrets, private state might be "owned" by a contract, but it needs someone with knowledge of these secrets to actually spend it. You might see where this is going. -If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](./keys.md). +If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](./keys.md). While this might sound limiting in what we can actually do, the main use of approvals have been for simplifying contract interactions that the user is doing. In the case of private transactions, this is executed on the user device, so it is not a blocker that the user need to tell the executor a secret - the user is the executor! + ### So what can we do? A few more things we need to remember about private execution: @@ -194,6 +195,14 @@ The main difference is that we are not setting up an allowance, but allowing the Also, most uses of the approvals are for contracts where the following interactions are called by the user themselves, so it is not a big issue that they are not as easily "transferrable" as the `permit`s. +:::note + +Authwits only work for a single user to authorize actions on contracts that their account is calling. You cannot authorize other users to take actions on your behalf. + +::: + +In order for another user to be able to take actions on your behalf, they would need access to your nullifier secret key so that they could nullify notes for you, but they should not have access to your nullifier secret key. + ### Other use-cases We don't need to limit ourselves to the `transfer` function, we can use the same scheme for any function that requires authentication. For example, for authenticating to burn or shield assets or to vote in a governance contract or perform an operation on a lending protocol. diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md index 71c085f3ca6..a6c0edb89fd 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md +++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/authwit.md @@ -14,7 +14,7 @@ For a guide on using authwit in Aztec.js, [read this](../../js_apps/authwit.md). ## Introduction -Authentication Witness is a scheme for authentication actions on Aztec, so users can allow third-parties (eg protocols or other users) to execute an action on their behalf. +Authentication Witness (authwit) is a scheme for authentication actions on Aztec, so users can allow third-parties (eg other contracts) to execute an action on their behalf. Authwits can only authorize actions for contracts that your account is calling, they cannot be used to permit other users to take actions on your behalf. How it works logically is explained in the [concepts](../../../../aztec/concepts/accounts/authwit.md) but we will do a short recap here. @@ -175,7 +175,7 @@ In the snippet below, this is done as a separate contract call, but can also be We have cases where we need a non-wallet contract to approve an action to be executed by another contract. One of the cases could be when making more complex defi where funds are passed along. When doing so, we need the intermediate contracts to support approving of actions on their behalf. -This is fairly straight forward to do using the `auth` library which includes logic for updating values in the public auth registry. Namely, you can prepare the `message_hash` using `compute_authwit_message_hash_from_call` and then simply feed it into the `set_authorized` function (both are in `auth` library) to update the value. +This is fairly straight forward to do using the `auth` library which includes logic for updating values in the public auth registry. Namely, you can prepare the `message_hash` using `compute_authwit_message_hash_from_call` and then simply feed it into the `set_authorized` function (both are in `auth` library) to update the value. When another contract later is consuming the authwit using `assert_current_call_valid_authwit_public` it will be calling the registry, and spend that authwit. From c2a81d57e3487b89b9897dbbf60e7b84fdf68a7f Mon Sep 17 00:00:00 2001 From: josh crites Date: Mon, 28 Oct 2024 10:43:41 -0400 Subject: [PATCH 2/7] update broken link --- noir-projects/aztec-nr/README.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/noir-projects/aztec-nr/README.md b/noir-projects/aztec-nr/README.md index 3a944619c61..3d803766dd5 100644 --- a/noir-projects/aztec-nr/README.md +++ b/noir-projects/aztec-nr/README.md @@ -15,12 +15,12 @@

- # Aztec.nr `Aztec-nr` is a [Noir](https://noir-lang.org) framework for smart contracts on [Aztec](aztec.network). ### Directory Structure + ``` . ├── aztec // The core of the aztec framework @@ -47,24 +47,26 @@ easy_private_state = { git = "https://github.com/AztecProtocol/aztec-nr", tag = value_note = { git = "https://github.com/AztecProtocol/aztec-nr", tag = "master" , directory = "value-note" } ``` - ## Prerequisites + To use `Aztec.nr` you must have [Noir](https://noir-lang.org/) installed. Noir is a general purpose programming language for creating zero-knowledge-proofs. `Aztec.nr` supercharges the Noir language with Aztec Smart Contract capabilities. ### Quick Installation -The fastest way to install is with [noirup](https://noir-lang.org/docs/getting_started/installation/#installing-noirup). + +The fastest way to install is with [noirup](https://noir-lang.org/docs/getting_started/quick_start). To use `Aztec-nr` the `aztec` version of `Noir` is required (Note; this version is temporarily required if you would like to use `#[aztec()]` macros). Once noirup is installed, you can run the following: + ```bash noirup -v NARGO_VERSION_COMPATIBLE_WITH_YOUR_SANDBOX ``` Replace `NARGO_VERSION_COMPATIBLE_WITH_YOUR_SANDBOX` with the version from the output of `aztec-cli get-node-info`: + ```bash aztec-cli get-node-info ``` For more installation options, please view [Noir's getting started.](https://noir-lang.org/docs/getting_started/installation/other_install_methods) - From 0ca35a1f90e55f1bded06a977e53592352e12f6f Mon Sep 17 00:00:00 2001 From: josh crites Date: Mon, 28 Oct 2024 17:10:04 -0400 Subject: [PATCH 3/7] note on simulations --- docs/docs/aztec/concepts/accounts/index.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/docs/docs/aztec/concepts/accounts/index.md b/docs/docs/aztec/concepts/accounts/index.md index 7315c99e0c4..7a62067db29 100644 --- a/docs/docs/aztec/concepts/accounts/index.md +++ b/docs/docs/aztec/concepts/accounts/index.md @@ -107,10 +107,11 @@ Notice that the Signerless wallet doesn't invoke an entrypoint function of an ac :::info Entrypoints for the following cases: + - if no contract entrypoint is used `msg_sender` is set to `Field.max`. - in a private to public entrypoint, `msg_sender` is the contract making the private to public call - when calling the entrypoint on an account contract, `msg_sender` is set to the account contract address -::: + ::: ### Account initialization @@ -127,13 +128,21 @@ Users will need to pay transaction fees in order to deploy their account contrac Account contracts are also expected, though not required by the protocol, to implement a set of methods for authorizing actions on behalf of the user. During a transaction, a contract may call into the account contract and request the user authorization for a given action, identified by a hash. This pattern is used, for instance, for transferring tokens from an account that is not the caller. When executing a private function, this authorization is checked by requesting an _auth witness_ from the execution oracle, which is usually a signed message. -The PXE is responsible for storing these auth witnesses and returning them to the requesting account contract. +The user's Private eXecution Environment (PXE) is responsible for storing these auth witnesses and returning them to the requesting account contract. Auth witnesses can belong to the current user executing the local transaction, or to another user who shared it out-of-band. However, during a public function execution, it is not possible to retrieve a value from the local oracle. To support authorizations in public functions, account contracts should save in contract storage what actions have been pre-authorized by their owner. These two patterns combined allow an account contract to answer whether an action `is_valid` for a given user both in private and public contexts. +You can read more about authorizing actions with authorization witnesses on [this page](./authwit.md). + +:::warn + +Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that "read" functions may have unintended side-effects and degraded UX. For example, a user will need to authorize an action, even if it is only a "read" operation from a contract. Reading contract state will require a signature or will require 2FA authorization in the case of 2FA account. + +::: + ### Encryption and nullifying keys Aztec requires users to define [encryption and nullifying keys](./keys.md) that are needed for receiving and spending private notes. Unlike transaction signing, encryption and nullifying is enshrined at the protocol. This means that there is a single scheme used for encryption and nullifying. These keys are derived from a master public key. This master public key, in turn, is used when deterministically deriving the account's address. From b5c70fb0b50f8f8d230b33aa21fbdd308f57bfec Mon Sep 17 00:00:00 2001 From: josh crites Date: Wed, 30 Oct 2024 10:21:04 -0400 Subject: [PATCH 4/7] update bb install script --- .../cpp/src/barretenberg/bb/readme.md | 78 ++++++------------- 1 file changed, 24 insertions(+), 54 deletions(-) diff --git a/barretenberg/cpp/src/barretenberg/bb/readme.md b/barretenberg/cpp/src/barretenberg/bb/readme.md index eb1ff22b2c8..721e54b7695 100644 --- a/barretenberg/cpp/src/barretenberg/bb/readme.md +++ b/barretenberg/cpp/src/barretenberg/bb/readme.md @@ -9,39 +9,7 @@ This binary will take as input ACIR and witness values described in the IR to cr ### Installation -1. Install `bbup` the installation script by running this in your terminal: - - ```bash - curl -L https://raw.githubusercontent.com/AztecProtocol/aztec-packages/master/barretenberg/cpp/installation/install | bash - ``` - -2. Reload your terminal shell environment: - - macOS: - ```bash - source ~/.zshrc - ``` - - Linux: - ```bash - source ~/.bashrc - ``` - -3. Install the version of `bb` compatible with your Noir version; with **Noir v0.34.0** for example: - - ```bash - bbup -v 0.55.0 - ``` - - Check the version compatibility section below for how to identify matching versions. - -4. Check if the installation was successful: - - ```bash - bb --version - ``` - -If installation was successful, the command would print the version of `bb` installed. +Follow the installation instructions described [here](../../../../../barretenberg/bbup/README.md#installation). ### Usage prerequisites @@ -52,6 +20,7 @@ Certain `bb` commands will expect the tool `jq` to already be installed. If `jq TODO: https://github.com/AztecProtocol/aztec-packages/issues/7511 For quick reference: + - Noir v0.34.0 <> BB v0.55.0 - Noir v0.33.0 <> BB v0.47.1 - Noir v0.32.0 <> BB v0.46.1 @@ -78,23 +47,23 @@ Documented with Noir v0.33.0 <> BB v0.47.1: 2. Prove the valid execution of your Noir program running: - ```bash - bb prove_ultra_honk -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof - ``` + ```bash + bb prove_ultra_honk -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof + ``` 3. Compute the verification key for your Noir program running: - ```bash - bb write_vk_ultra_honk -b ./target/hello_world.json -o ./target/vk - ``` + ```bash + bb write_vk_ultra_honk -b ./target/hello_world.json -o ./target/vk + ``` 4. Verify your proof running: - ```bash - bb verify_ultra_honk -k ./target/vk -p ./target/proof - ``` + ```bash + bb verify_ultra_honk -k ./target/vk -p ./target/proof + ``` - If successful, the verification will complete in silence; if unsuccessful, the command will trigger logging of the corresponding error. + If successful, the verification will complete in silence; if unsuccessful, the command will trigger logging of the corresponding error. Refer to all available `bb` commands linked above for full list of functionality. @@ -106,24 +75,24 @@ Barretenberg UltraHonk comes with the capability to verify proofs in Solidity, i 2. Prove the valid execution of your Noir program running: - ```bash - bb prove_ultra_keccak_honk -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof - ``` + ```bash + bb prove_ultra_keccak_honk -b ./target/hello_world.json -w ./target/witness-name.gz -o ./target/proof + ``` - > **Note:** `prove_ultra_keccak_honk` is used to generate UltraHonk proofs with Keccak hashes, as it is what the Solidity verifier is designed to be compatible with given the better gas efficiency when verifying on-chain; `prove_ultra_honk` in comparison generates proofs with Poseidon hashes, more efficient in recursions but not on-chain verifications. + > **Note:** `prove_ultra_keccak_honk` is used to generate UltraHonk proofs with Keccak hashes, as it is what the Solidity verifier is designed to be compatible with given the better gas efficiency when verifying on-chain; `prove_ultra_honk` in comparison generates proofs with Poseidon hashes, more efficient in recursions but not on-chain verifications. 3. Compute the verification key for your Noir program running: - ```bash - bb write_vk_ultra_honk -b ./target/hello_world.json -o ./target/vk - ``` + ```bash + bb write_vk_ultra_honk -b ./target/hello_world.json -o ./target/vk + ``` 4. Generate Solidity verifier - **WARNING:** Contract incomplete, do not use in production! + **WARNING:** Contract incomplete, do not use in production! - ```bash - bb contract_ultra_honk -k ./target/vk -c $CRS_PATH -b ./target/hello_world.json -o ./target/Verifier.sol - ``` + ```bash + bb contract_ultra_honk -k ./target/vk -c $CRS_PATH -b ./target/hello_world.json -o ./target/Verifier.sol + ``` #### Usage with MegaHonk @@ -132,6 +101,7 @@ Use `bb _mega_honk`. Refer to all available `bb` commands linked above for full list of functionality. Note that MegaHonk: + - Generates insecure recursion circuits when Goblin recursive verifiers are not present - Will not have a Solidity verifier, as the proving system is intended for use with apps deploying on Aztec only From 79b4db721d9cb5718c57c148672745a9531fda5f Mon Sep 17 00:00:00 2001 From: josh crites Date: Wed, 30 Oct 2024 14:59:14 -0400 Subject: [PATCH 5/7] note on simulating simulations --- docs/docs/aztec/concepts/accounts/index.md | 6 +++--- .../codealong/contract_tutorials/write_accounts_contract.md | 6 ++++++ 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/docs/docs/aztec/concepts/accounts/index.md b/docs/docs/aztec/concepts/accounts/index.md index 7a62067db29..1d318d0d9b1 100644 --- a/docs/docs/aztec/concepts/accounts/index.md +++ b/docs/docs/aztec/concepts/accounts/index.md @@ -133,13 +133,13 @@ Auth witnesses can belong to the current user executing the local transaction, o However, during a public function execution, it is not possible to retrieve a value from the local oracle. To support authorizations in public functions, account contracts should save in contract storage what actions have been pre-authorized by their owner. -These two patterns combined allow an account contract to answer whether an action `is_valid` for a given user both in private and public contexts. +These two patterns combined allow an account contract to answer whether an action `is_valid_impl` for a given user both in private and public contexts. You can read more about authorizing actions with authorization witnesses on [this page](./authwit.md). -:::warn +:::info -Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that "read" functions may have unintended side-effects and degraded UX. For example, a user will need to authorize an action, even if it is only a "read" operation from a contract. Reading contract state will require a signature or will require 2FA authorization in the case of 2FA account. +Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. For example, a user will need to authorize an action, even if it is only a simulated operation from a contract. Simulating a `transfer_from` call will require a signature in a Schnorr account or will require 2FA authorization in the case of 2FA account. ::: diff --git a/docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md b/docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md index 89e0d382293..64216816703 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md @@ -49,6 +49,12 @@ The `AccountActions` module provides default implementations for most of the acc For our account contract, we will take the hash of the action to authorize, request the corresponding auth witness from the oracle, and validate it against our hardcoded public key. If the signature is correct, we authorize the action. +:::info + +Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. For example, a user will need to authorize an action, even if it is only a simulated operation from a contract. Simulating a `transfer_from` call will require a signature in a Schnorr account or will require 2FA authorization in the case of 2FA account. + +::: + ### 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 Fee Juice to use another asset to pay for fees, provided they can find a relayer willing to accept the asset as payment (or do it for free). From 852c5f1e3b337e4460fc67cc86cd721938b51972 Mon Sep 17 00:00:00 2001 From: josh crites Date: Wed, 30 Oct 2024 15:54:11 -0400 Subject: [PATCH 6/7] update build manifest link --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c26aa2f49fe..83a2d819572 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,7 @@ To build Typescript code, make sure to have [`nvm`](https://github.com/nvm-sh/nv This repository uses CircleCI for continuous integration. Build steps are managed using [`build-system`](https://github.com/AztecProtocol/build-system). Small packages are built and tested as part of a docker build operation, while larger ones and end-to-end tests spin up a large AWS spot instance. Each successful build step creates a new docker image that gets tagged with the package name and commit. -All packages need to be included in the [build manifest](`build_manifest.json`), which declares what paths belong to each package, as well as dependencies between packages. When the CI runs, if none of the rebuild patterns or dependencies were changed, then the build step is skipped and the last successful image is re-tagged with the current commit. Read more on the [`build-system`](https://github.com/AztecProtocol/build-system) repository README. +All packages need to be included in the [build manifest](build_manifest.yml), which declares what paths belong to each package, as well as dependencies between packages. When the CI runs, if none of the rebuild patterns or dependencies were changed, then the build step is skipped and the last successful image is re-tagged with the current commit. Read more on the [`build-system`](https://github.com/AztecProtocol/build-system) repository README. It is faster to debug CI failures within a persistent ssh session compared to pushing and waiting. You can create a session with "Rerun step with SSH" on CircleCI which will generate an ssh command for debugging on a worker. Run that command locally and then do From ea6d0910a8d08e36e8b695882f66c8fc4eb4cb1d Mon Sep 17 00:00:00 2001 From: josh crites Date: Mon, 4 Nov 2024 15:21:00 -0500 Subject: [PATCH 7/7] refine sim sim --- docs/docs/aztec/concepts/accounts/index.md | 2 +- .../codealong/contract_tutorials/write_accounts_contract.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/docs/aztec/concepts/accounts/index.md b/docs/docs/aztec/concepts/accounts/index.md index 1d318d0d9b1..3a6d56567b7 100644 --- a/docs/docs/aztec/concepts/accounts/index.md +++ b/docs/docs/aztec/concepts/accounts/index.md @@ -139,7 +139,7 @@ You can read more about authorizing actions with authorization witnesses on [thi :::info -Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. For example, a user will need to authorize an action, even if it is only a simulated operation from a contract. Simulating a `transfer_from` call will require a signature in a Schnorr account or will require 2FA authorization in the case of 2FA account. +Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. Without simulating simulations, the PXE can't anticipate what authwits a transaction may need, so developers will need to manually request these authwits from users. In the future, transactions requiring authwits will be smart enough to ask the user for the correct authwits automatically. ::: diff --git a/docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md b/docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md index 64216816703..064365bb3dd 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/write_accounts_contract.md @@ -51,7 +51,7 @@ For our account contract, we will take the hash of the action to authorize, requ :::info -Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. For example, a user will need to authorize an action, even if it is only a simulated operation from a contract. Simulating a `transfer_from` call will require a signature in a Schnorr account or will require 2FA authorization in the case of 2FA account. +Transaction simulations in the PXE are not currently simulated, this is future work described [here](https://github.com/AztecProtocol/aztec-packages/issues/9133). This means that any transaction simulations that call into a function requiring an authwit will require the user to provide an authwit. Without simulating simulations, the PXE can't anticipate what authwits a transaction may need, so developers will need to manually request these authwits from users. In the future, transactions requiring authwits will be smart enough to ask the user for the correct authwits automatically. :::