diff --git a/aztec-up/README.md b/aztec-up/README.md index 630d0e0fc5c..4a8ebf22fa2 100644 --- a/aztec-up/README.md +++ b/aztec-up/README.md @@ -14,6 +14,7 @@ a users `PATH` variable in their shell startup script so they can be found. - `aztec-nargo` - A build of `nargo` from `noir` that is guaranteed to be version aligned. Provides compiler, lsp and more. - `aztec-sandbox` - A wrapper around docker-compose that launches services needed for sandbox testing. - `aztec-up` - A tool to upgrade the aztec toolchain to the latest, or specific versions. +- `aztec-builder` - A useful tool for projects to generate ABIs and update their dependencies. After installed, you can use `aztec-up` to upgrade or install specific versions. diff --git a/docs/docs/developers/contracts/resources/common_patterns/authwit.md b/docs/docs/developers/contracts/resources/common_patterns/authwit.md index 334eba3e240..f1649d731ef 100644 --- a/docs/docs/developers/contracts/resources/common_patterns/authwit.md +++ b/docs/docs/developers/contracts/resources/common_patterns/authwit.md @@ -82,7 +82,7 @@ Both return the value `0xabf64ad4` (`IS_VALID` selector) for a successful authen As part of [Aztec.nr](https://aztec.nr), we are providing a library that can be used to implement authentication witness for your contracts. -This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](../../writing_contracts/accounts/write_accounts_contract.md). +This library also provides a basis for account implementations such that these can more easily implement authentication witness. For our purposes here (not building a wallet), the most important part of the library is the `auth` utility which exposes a couple of helper methods for computing the action hash, retrieving witnesses, validating them and emitting the nullifier. diff --git a/docs/docs/developers/contracts/resources/common_patterns/main.md b/docs/docs/developers/contracts/resources/common_patterns/main.md index 312eed8552e..aca95c3f5d9 100644 --- a/docs/docs/developers/contracts/resources/common_patterns/main.md +++ b/docs/docs/developers/contracts/resources/common_patterns/main.md @@ -115,7 +115,7 @@ Hence, it's necessary to add a "randomness" field to your note to prevent such a ### L1 -- L2 interactions -Refer to [Token Portal tutorial on bridging tokens between L1 and L2](../../../tutorials/token_portal/main.md) and/or [Uniswap tutorial that shows how to swap on L1 using funds on L2](../../../tutorials/uniswap/main.md). Both examples show how to: +Refer to [Token Portal tutorial on bridging tokens between L1 and L2](../../../tutorials/token_portal/main.md). This example shows how to: 1. L1 -> L2 message flow 2. L2 -> L1 message flow @@ -129,7 +129,7 @@ To send a note to someone, they need to have a key which we can encrypt the note There are several patterns here: 1. Give the contract a key and share it amongst all participants. This leaks privacy, as anyone can see all the notes in the contract. -2. `Unshield` funds into the contract - this is used in the [Uniswap tutorial where a user sends private funds into a Uniswap Portal contract which eventually withdraws to L1 to swap on L1 Uniswap](../../../tutorials/uniswap/swap_privately.md). This works like ethereum - to achieve contract composability, you move funds into the public domain. This way the contract doesn't even need keys. +2. `Unshield` funds into the contract. This works like ethereum - to achieve contract composability, you move funds into the public domain. This way the contract doesn't even need keys. There are several other designs we are discussing through [in this discourse post](https://discourse.aztec.network/t/how-to-handle-private-escrows-between-two-parties/2440) but they need some changes in the protocol or in our demo contract. If you are interested in this discussion, please participate in the discourse post! diff --git a/docs/docs/developers/contracts/writing_contracts/accounts/write_accounts_contract.md b/docs/docs/developers/contracts/writing_contracts/accounts/write_accounts_contract.md index be77b51e6e7..252b752cc84 100644 --- a/docs/docs/developers/contracts/writing_contracts/accounts/write_accounts_contract.md +++ b/docs/docs/developers/contracts/writing_contracts/accounts/write_accounts_contract.md @@ -1,5 +1,6 @@ --- title: How to write an accounts contract +draft: true --- This tutorial will take you through the process of writing your own account contract in Aztec.nr, along with the Typescript glue code required for using it within a wallet. diff --git a/docs/docs/developers/getting_started/aztecjs-getting-started.md b/docs/docs/developers/getting_started/aztecjs-getting-started.md index acb8916c0a5..e6f4caba71d 100644 --- a/docs/docs/developers/getting_started/aztecjs-getting-started.md +++ b/docs/docs/developers/getting_started/aztecjs-getting-started.md @@ -16,10 +16,6 @@ This guide assumes you have followed the [quickstart](./quickstart.md). We will deploy a pre-compiled token contract, and send tokens privately, using the Sandbox. -:::info -Find the full code [here](https://github.com/AztecProtocol/dev-rel/tree/main/tutorials/sandbox-tutorial/token) -::: - We will create a `yarn` project called `token` (although `npm` works fine too). 1. Initialize a yarn project diff --git a/docs/docs/developers/getting_started/aztecnr-getting-started.md b/docs/docs/developers/getting_started/aztecnr-getting-started.md index 4996532e4e9..ae19d03da86 100644 --- a/docs/docs/developers/getting_started/aztecnr-getting-started.md +++ b/docs/docs/developers/getting_started/aztecnr-getting-started.md @@ -26,7 +26,14 @@ cd aztec-private-counter mkdir contracts ``` -Inside contracts create the following file structure: +Inside `contracts` create a new project called `counter`: + +```bash +cd contracts +aztec-nargo new --contract counter +``` + +Your structure should look like this: ```tree . @@ -40,14 +47,14 @@ Inside contracts create the following file structure: The file `main.nr` will soon turn into our smart contract! -Add the following content to `Nargo.toml`: +Add the following dependencies to `Nargo.toml`: ```toml [package] name = "counter" type = "contract" authors = [""] -compiler_version = ">=0.18.0" +compiler_version = ">=0.28.0" [dependencies] aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="noir-projects/aztec-nr/aztec" } @@ -144,10 +151,12 @@ aztec-nargo compile This will compile the smart contract and create a `target` folder with a `.json` artifact inside. -After compiling, you can generate a typescript class. In the same directory, run this: +After compiling, you can generate a typescript class using `aztec-builder`'s `codegen` command. (See `aztec-builder help codegen` for syntax). + +In the same directory, run this: ```bash -aztec-builder target -o src/artifacts +aztec-builder codegen -o src/artifacts target ``` You can now use the artifact and/or the TS class in your Aztec.js! If you skipped the Aztec.js getting-started guide, you can follow it [here](aztecjs-getting-started.md). This will teach you about deploying and calling contracts in Aztec.js. diff --git a/docs/docs/developers/getting_started/quickstart.md b/docs/docs/developers/getting_started/quickstart.md index dfc66cc4d57..a05f8abc675 100644 --- a/docs/docs/developers/getting_started/quickstart.md +++ b/docs/docs/developers/getting_started/quickstart.md @@ -51,6 +51,8 @@ This will install the following: - **aztec-nargo** - aztec's build of nargo, the noir compiler toolchain. - **aztec-sandbox** - a wrapper around docker-compose that launches services needed for sandbox testing. - **aztec-up** - a tool to upgrade the aztec toolchain to the latest, or specific versions. +- **aztec-builder** - A useful tool for projects to generate ABIs and update their dependencies. + Once these have been installed, to start the sandbox, run: diff --git a/docs/docs/developers/sandbox/references/sandbox-reference.md b/docs/docs/developers/sandbox/references/sandbox-reference.md index ecf4e04c61e..673ed6c4020 100644 --- a/docs/docs/developers/sandbox/references/sandbox-reference.md +++ b/docs/docs/developers/sandbox/references/sandbox-reference.md @@ -20,6 +20,7 @@ This will install the following: - **aztec-nargo** - aztec's build of nargo, the noir compiler toolchain. - **aztec-sandbox** - a wrapper around docker-compose that launches services needed for sandbox testing. - **aztec-up** - a tool to upgrade the aztec toolchain to the latest, or specific versions. +- **aztec-builder** - A useful tool for projects to generate ABIs and update their dependencies. Once these have been installed, to start the sandbox, run: diff --git a/docs/docs/developers/tutorials/main.md b/docs/docs/developers/tutorials/main.md index 69dc1513793..f5ef0a11082 100644 --- a/docs/docs/developers/tutorials/main.md +++ b/docs/docs/developers/tutorials/main.md @@ -4,7 +4,7 @@ title: Tutorials This section will guide you through all aspects of Aztec. You'll be building Aztec.nr contracts, writing tests with Aztec.js, and exploring more aspects of the sandbox on the way. -It is recommended to follow them in order, beginning with the [private voting contract](writing_private_voting_contract.md) through to the [uniswap contract with e2e test](./uniswap/main.md). +It is recommended to follow them in order, beginning with the [private voting contract](writing_private_voting_contract.md). Here's an overview of what you'll learn in each: @@ -37,11 +37,3 @@ Here's an overview of what you'll learn in each: - More details into what the Sandbox is capable of [Check it out](./token_portal/main.md). - -## Swap on L1 Uniswap from L2 with Portals - -- A more complex example of cross-chain communication - -Note - this builds on the code previously written in the Token Bridge tutorial. - -[Check it out](./uniswap/main.md). diff --git a/docs/docs/developers/tutorials/token_portal/setup.md b/docs/docs/developers/tutorials/token_portal/setup.md index d4c44d37496..455625c8722 100644 --- a/docs/docs/developers/tutorials/token_portal/setup.md +++ b/docs/docs/developers/tutorials/token_portal/setup.md @@ -13,8 +13,6 @@ In this step, we’re going to We recommend going through this setup to fully understand where things live. -However if you’d rather skip this part, our dev-rels repo contains the starter code here. - ## Prerequisites - [node v18+](https://github.com/tj/n) @@ -35,7 +33,7 @@ mkdir aztec-token-bridge cd aztec-token-bridge && mkdir packages ``` -We will hold our projects inside of `packages` to follow the design of the project in the [repo](https://github.com/AztecProtocol/dev-rel/tree/main/tutorials/token-bridge-e2e). +We will hold our projects inside of `packages` to follow the design of other projects. ## Create a noir project diff --git a/docs/docs/developers/tutorials/uniswap/execute_private_swap_on_l1.md b/docs/docs/developers/tutorials/uniswap/execute_private_swap_on_l1.md index 834e1c18039..17541af1d73 100644 --- a/docs/docs/developers/tutorials/uniswap/execute_private_swap_on_l1.md +++ b/docs/docs/developers/tutorials/uniswap/execute_private_swap_on_l1.md @@ -1,5 +1,6 @@ --- title: Executing Private Swap on L1 +draft: true --- To execute the swaps on L1, go back to the `UniswapPortal.sol` we [created earlier](./l1_portal.md) in `l1-contracts`. diff --git a/docs/docs/developers/tutorials/uniswap/execute_public_swap_on_l1.md b/docs/docs/developers/tutorials/uniswap/execute_public_swap_on_l1.md index 9b92eb92c65..10738cd41d9 100644 --- a/docs/docs/developers/tutorials/uniswap/execute_public_swap_on_l1.md +++ b/docs/docs/developers/tutorials/uniswap/execute_public_swap_on_l1.md @@ -1,5 +1,6 @@ --- title: Solidity Code to Execute Swap on L1 +draft: true --- To execute the swaps on L1, go back to the `UniswapPortal.sol` we [created earlier](./l1_portal.md) in `l1-contracts`. diff --git a/docs/docs/developers/tutorials/uniswap/l1_portal.md b/docs/docs/developers/tutorials/uniswap/l1_portal.md index d628755da83..cf400478ee7 100644 --- a/docs/docs/developers/tutorials/uniswap/l1_portal.md +++ b/docs/docs/developers/tutorials/uniswap/l1_portal.md @@ -1,5 +1,6 @@ --- title: Uniswap Portal on L1 +draft: true --- In this step we will set up our Solidity portal contract. diff --git a/docs/docs/developers/tutorials/uniswap/l2_contract_setup.md b/docs/docs/developers/tutorials/uniswap/l2_contract_setup.md index 71284fafe79..49ef7681ddc 100644 --- a/docs/docs/developers/tutorials/uniswap/l2_contract_setup.md +++ b/docs/docs/developers/tutorials/uniswap/l2_contract_setup.md @@ -1,5 +1,6 @@ --- title: L2 Contract Setup +draft: true --- As we mentioned in [the overview](./main.md), the Uniswap L2 contract will receive funds from the user and then burn funds on L2 to withdraw. To do this it calls `TokenBridge.exit_to_l1_public()` which burns funds on the Uniswap contract. The bridge needs approval from the Uniswap contract to burn its funds. diff --git a/docs/docs/developers/tutorials/uniswap/main.md b/docs/docs/developers/tutorials/uniswap/main.md index d265f44c316..3950437b399 100644 --- a/docs/docs/developers/tutorials/uniswap/main.md +++ b/docs/docs/developers/tutorials/uniswap/main.md @@ -1,5 +1,6 @@ --- title: Build an Aztec Connect-style Uniswap +draft: true --- import Image from "@theme/IdealImage"; diff --git a/docs/docs/developers/tutorials/uniswap/redeeming_swapped_assets_on_l2.md b/docs/docs/developers/tutorials/uniswap/redeeming_swapped_assets_on_l2.md index befecf8b226..b284f2cb811 100644 --- a/docs/docs/developers/tutorials/uniswap/redeeming_swapped_assets_on_l2.md +++ b/docs/docs/developers/tutorials/uniswap/redeeming_swapped_assets_on_l2.md @@ -1,5 +1,6 @@ --- title: Redeeming Swapped Assets on L2 +draft: true --- So you emitted a message to withdraw input tokens to L1 and a message to swap. Then you or someone on your behalf can swap on L1 and emit a message to deposit swapped assets to L2, diff --git a/docs/docs/developers/tutorials/uniswap/setup.md b/docs/docs/developers/tutorials/uniswap/setup.md index ba86ecb73be..498d5482195 100644 --- a/docs/docs/developers/tutorials/uniswap/setup.md +++ b/docs/docs/developers/tutorials/uniswap/setup.md @@ -1,10 +1,15 @@ --- title: Setup & Installation +draft: true --- This tutorial builds on top of the project created in the previous tutorial. It can exist on its own, but for our sake it is much easier to utilize the existing L1 contracts that we already have in place. +:::warning +Note: This document does not appear in the sidebar. +Also note that the code linked in the dev-rel repo is not as up to date as the aztec-packages monorepo. If you don’t have this, you can find the code for it [in our dev-rels repo](https://github.com/AztecProtocol/dev-rel/tree/main/tutorials/token-bridge-e2e). +:::warning # Uniswap contract diff --git a/docs/docs/developers/tutorials/uniswap/swap_privately.md b/docs/docs/developers/tutorials/uniswap/swap_privately.md index 1e964019416..76e199a088c 100644 --- a/docs/docs/developers/tutorials/uniswap/swap_privately.md +++ b/docs/docs/developers/tutorials/uniswap/swap_privately.md @@ -1,5 +1,6 @@ --- title: Swapping Privately +draft: true --- In the `uniswap/src/main.nr` contract we created [previously](./l2_contract_setup.md) in `aztec-contracts/uniswap`, paste these functions: diff --git a/docs/docs/developers/tutorials/uniswap/swap_publicly.md b/docs/docs/developers/tutorials/uniswap/swap_publicly.md index ef2916a9ed0..c87c68ff824 100644 --- a/docs/docs/developers/tutorials/uniswap/swap_publicly.md +++ b/docs/docs/developers/tutorials/uniswap/swap_publicly.md @@ -1,5 +1,6 @@ --- title: Swapping Publicly +draft: true --- In this step we will create the flow for allowing a user to swap their tokens publicly on L1. It will have the functionality of letting anyone call this method on behalf of the user, assuming they have appropriate approvals. This means that an operator can pay gas fees on behalf of the user! diff --git a/docs/docs/developers/tutorials/uniswap/typescript_glue_code.md b/docs/docs/developers/tutorials/uniswap/typescript_glue_code.md index 01db9de4285..946eb8ee98d 100644 --- a/docs/docs/developers/tutorials/uniswap/typescript_glue_code.md +++ b/docs/docs/developers/tutorials/uniswap/typescript_glue_code.md @@ -1,5 +1,6 @@ --- title: Deploy & Call Contracts with Typescript +draft: true --- In this step, we We will now write a Typescript to interact with the sandbox and see our Solidity and Aztec.nr contracts in action. diff --git a/docs/docs/developers/tutorials/writing_token_contract.md b/docs/docs/developers/tutorials/writing_token_contract.md index cc555428c13..bd777d67940 100644 --- a/docs/docs/developers/tutorials/writing_token_contract.md +++ b/docs/docs/developers/tutorials/writing_token_contract.md @@ -444,6 +444,6 @@ https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn ### Token Bridge Contract -The [token bridge tutorial](https://github.com/AztecProtocol/dev-rel/tree/main/tutorials/token-bridge) is a great follow up to this one. +The [token bridge tutorial](./token_portal/main) is a great follow up to this one. It builds on the Token contract described here and goes into more detail about Aztec contract composability and Ethereum (L1) and Aztec (L2) cross-chain messaging. diff --git a/docs/docs/developers/wallets/architecture.md b/docs/docs/developers/wallets/architecture.md index bd9d6beeb6d..a02f42cf2e3 100644 --- a/docs/docs/developers/wallets/architecture.md +++ b/docs/docs/developers/wallets/architecture.md @@ -6,8 +6,6 @@ This page talks about the architecture of a wallet in Aztec. To get an overview about wallets in Aztec, [go here](./main.md). -To learn how to write an accounts contract, [go here](../contracts/writing_contracts/accounts/write_accounts_contract.md). - To create a schnorr account in the sandbox, [go here](./creating_schnorr_accounts.md). Wallets expose to dapps an interface that allows them to act on behalf of the user, such as querying private state or sending transactions. Bear mind that, as in Ethereum, wallets should require user confirmation whenever carrying out a potentially sensitive action requested by a dapp. @@ -28,8 +26,6 @@ The account interface is used for creating an _execution request_ out of one or #include_code account-interface yarn-project/aztec.js/src/account/interface.ts typescript -Refer to the page on [writing an account contract](../contracts/writing_contracts/accounts/write_accounts_contract.md) for an example on how to implement this interface. - ## PXE interface A wallet exposes the PXE interface to dapps by running an PXE instance. The PXE requires a keystore and a database implementation for storing keys, private state, and recipient encryption public keys. diff --git a/docs/docs/developers/wallets/creating_schnorr_accounts.md b/docs/docs/developers/wallets/creating_schnorr_accounts.md index a2b4cefd98f..0da79ddbce2 100644 --- a/docs/docs/developers/wallets/creating_schnorr_accounts.md +++ b/docs/docs/developers/wallets/creating_schnorr_accounts.md @@ -57,7 +57,3 @@ If you were looking at your terminal that is running the Sandbox you should have This is because the Sandbox will have simulated the deployment of both contracts, executed the private kernel circuit for each account deployment and later on submitted the 2 transactions to the pool. The sequencer will have picked them up and inserted them into an L2 block and executed the recursive rollup circuits before publishing the L2 block on L1 (in our case Anvil). Once this has completed, the L2 block is retrieved and pulled down to the PXE so that any new account state can be decrypted. - -## Next Steps - -Check out our section on [Writing your own Account Contract](../contracts/writing_contracts/accounts/write_accounts_contract.md) leveraging our account abstraction diff --git a/docs/docs/developers/wallets/main.md b/docs/docs/developers/wallets/main.md index a35ce8a7f8f..0a072867478 100644 --- a/docs/docs/developers/wallets/main.md +++ b/docs/docs/developers/wallets/main.md @@ -4,8 +4,6 @@ title: Wallets In this page we will cover the main responsibilities of a wallet in the Aztec network. -Refer to [_writing an account contract_](../contracts/writing_contracts/accounts/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. Wallets are the applications through which users manage their accounts. Users rely on wallets to browse through their accounts, monitor their balances, and create new accounts. Wallets also store seed phrases and private keys, or interact with external keystores such as hardware wallets. @@ -18,7 +16,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](../../learn/concepts/accounts/main.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](../contracts/writing_contracts/accounts/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, 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](../../learn/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys) 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/learn/concepts/accounts/keys.md b/docs/docs/learn/concepts/accounts/keys.md index 1cf42aa3755..570ef9fb0d9 100644 --- a/docs/docs/learn/concepts/accounts/keys.md +++ b/docs/docs/learn/concepts/accounts/keys.md @@ -15,7 +15,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](../../../developers/contracts/writing_contracts/accounts/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. 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. Here are a few ideas on how to store them, each with their pros and cons. diff --git a/docs/docs/learn/concepts/accounts/main.md b/docs/docs/learn/concepts/accounts/main.md index 55746cc1524..34d5f1e67cb 100644 --- a/docs/docs/learn/concepts/accounts/main.md +++ b/docs/docs/learn/concepts/accounts/main.md @@ -70,8 +70,6 @@ def entryPoint(payload): enqueueCall(to, data, value, gasLimit); ``` -Read more about how to write an account contract [here](../../../developers/contracts/writing_contracts/accounts/write_accounts_contract.md). - ### Account contracts and wallets Account contracts are tightly coupled to the wallet software that users use to interact with the protocol. Dapps submit to the wallet software one or more function calls to be executed (eg "call swap in X contract"), and the wallet encodes and authenticates the request as a valid payload for the user's account contract. The account contract then validates the request encoded and authenticated by the wallet, and executes the function calls requested by the dapp.