diff --git a/docs/docs/aztec/concepts/accounts/authwit.md b/docs/docs/aztec/concepts/accounts/authwit.md index 79cb828ccb3..307c07a0edb 100644 --- a/docs/docs/aztec/concepts/accounts/authwit.md +++ b/docs/docs/aztec/concepts/accounts/authwit.md @@ -5,6 +5,8 @@ importance: 1 keywords: [authwit, authentication witness, accounts] --- +import Image from "@theme/IdealImage"; + Authentication Witness is a scheme for authenticating actions on Aztec, so users can allow third-parties (eg protocols or other users) to execute an action on their behalf. ## Background @@ -13,15 +15,7 @@ When building DeFi or other smart contracts, it is often desired to interact wit In the EVM world, this is often accomplished by having the user `approve` the protocol to transfer funds from their account, and then calling a `deposit` function on it afterwards. -```mermaid -sequenceDiagram - actor Alice - Alice->>Token: approve(Defi, 1000); - Alice->>Defi: deposit(Token, 1000); - activate Defi - Defi->>Token: transferFrom(Alice, Defi, 1000); - deactivate Defi -``` + This flow makes it rather simple for the application developer to implement the deposit function, but does not come without its downsides. @@ -36,16 +30,7 @@ This can lead to a series of issues though, eg: To avoid this, many protocols implement the `permit` flow, which uses a meta-transaction to let the user sign the approval off-chain, and pass it as an input to the `deposit` function, that way the user only has to send one transaction to make the deposit. -```mermaid -sequenceDiagram - actor Alice - Alice->>Alice: sign permit(Defi, 1000); - Alice->>Defi: deposit(Token, 1000, signature); - activate Defi - Defi->>Token: permit(Alice, Defi, 1000, signature); - Defi->>Token: transferFrom(Alice, Defi, 1000); - deactivate Defi -``` + This is a great improvement to infinite approvals, but still has its own sets of issues. For example, if the user is using a smart-contract wallet (such as Argent or Gnosis Safe), they will not be able to sign the permit message since the usual signature validation does not work well with contracts. [EIP-1271](https://eips.ethereum.org/EIPS/eip-1271) was proposed to give contracts a way to emulate this, but it is not widely adopted. @@ -57,7 +42,7 @@ All of these issues have been discussed in the community for a while, and there Adopting ERC20 for Aztec is not as simple as it might seem because of private state. -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 you recall from the [Hybrid State model](../storage/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). @@ -105,32 +90,7 @@ This can be read as "defi is allowed to call token transfer function with the ar With this out of the way, let's look at how this would work in the graph below. The exact contents of the witness will differ between implementations as mentioned before, but for the sake of simplicity you can think of it as a signature, which the account contract can then use to validate if it really should allow the action. -```mermaid -sequenceDiagram - actor Alice - participant AC as Alice Account - participant Token - Alice->>AC: Defi.deposit(Token, 1000); - activate AC - AC->>Defi: deposit(Token, 1000); - activate Defi - Defi->>Token: transfer(Alice, Defi, 1000); - activate Token - Token->>AC: Check if Defi may call transfer(Alice, Defi, 1000); - AC-->>Alice: Please give me AuthWit for DeFi
calling transfer(Alice, Defi, 1000); - activate Alice - Alice-->>Alice: Produces Authentication witness - Alice-->>AC: AuthWit for transfer(Alice, Defi, 1000); - AC->>Token: AuthWit validity - deactivate Alice - Token->>Token: throw if invalid AuthWit - Token->>Token: transfer(Alice, Defi, 1000); - Token->>Defi: success - deactivate Token - Defi->>Defi: deposit(Token, 1000); - deactivate Defi - deactivate AC -``` + :::info Static call for AuthWit checks The call to the account contract for checking authentication should be a static call, meaning that it cannot change state or make calls that change state. If this call is not static, it could be used to re-enter the flow and change the state of the contract. @@ -144,36 +104,7 @@ The above flow could be re-entered at token transfer. It is mainly for show to i As noted earlier, we could use the ERC20 standard for public. But this seems like a waste when we have the ability to try righting some wrongs. Instead, we can expand our AuthWit scheme to also work in public. This is actually quite simple, instead of asking an oracle (which we can't do as easily because not private execution) we can just store the AuthWit in a shared registry, and look it up when we need it. While this needs the storage to be updated ahead of time (can be same tx), we can quite easily do so by batching the AuthWit updates with the interaction - a benefit of Account Contracts. A shared registry is used such that execution from the sequencers point of view will be more straight forward and predictable. Furthermore, since we have the authorization data directly in public state, if they are both set and unset (authorized and then used) in the same transaction, there will be no state effect after the transaction for the authorization which saves gas ⛽. -```mermaid -sequenceDiagram - actor Alice - participant AC as Alice Account - participant AR as Auth Registry - participant Token - participant Defi - rect rgb(191, 223, 255) - note right of Alice: Alice sends a batch - Alice->>AC: Authorize Defi to call transfer(Alice, Defi, 1000); - activate AC - Alice->>AC: Defi.deposit(Token, 1000); - end - AC->>AR: Authorize Defi to call transfer(Alice, Defi, 1000); - AR->>AR: add authorize to true - AC->>Defi: deposit(Token, 1000); - activate Defi - Defi->>Token: transfer(Alice, Defi, 1000); - activate Token - Token->>AR: Check if Defi may call transfer(Alice, Defi, 1000); - AR->>AR: set authorize to false - AR->>Token: AuthWit validity - Token->>Token: throw if invalid AuthWit - Token->>Token: transfer(Alice, Defi, 1000); - Token->>Defi: success - deactivate Token - Defi->>Defi: deposit(Token, 1000); - deactivate Defi - deactivate AC -``` + ### Replays diff --git a/docs/docs/aztec/concepts/pxe/index.md b/docs/docs/aztec/concepts/pxe/index.md index 6e54b1ed354..5f7dedf1b28 100644 --- a/docs/docs/aztec/concepts/pxe/index.md +++ b/docs/docs/aztec/concepts/pxe/index.md @@ -6,32 +6,13 @@ keywords: [pxe, private execution environment] importance: 1 --- +import Image from "@theme/IdealImage"; + The Private Execution Environment (or PXE, pronounced 'pixie') is a client-side library for the execution of private operations. It is a TypeScript library and can be run within Node, such as when you run the sandbox. In the future it could be run inside wallet software or a browser. The PXE generates proofs of private function execution, and sends these proofs along with public function requests to the sequencer. Private inputs never leave the client-side PXE. -```mermaid -graph TD; - - subgraph client[Client] - subgraph pxe [PXE] - acirSim[ACIR Simulator] - db[Database] - keyStore[KeyStore] - end - end - - subgraph server[Application Server] - subgraph pxeService [PXE Service] - acctMgmt[Account Management] - contractTxInteract[Contract & Transaction Interactions] - noteMgmt[Note Management] - end - end - - pxe -->|interfaces| server - -``` + ## PXE Service diff --git a/docs/docs/aztec/concepts/state_model/public_vm.md b/docs/docs/aztec/concepts/state_model/public_vm.md deleted file mode 100644 index d5c26f1d33d..00000000000 --- a/docs/docs/aztec/concepts/state_model/public_vm.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Public VM ---- - -Refer to the [protocol specs section](../../../protocol-specs/public-vm/index.md) for the latest information about the Aztec Public VM. diff --git a/docs/docs/aztec/concepts/storage/index.md b/docs/docs/aztec/concepts/storage/index.md index 9b3987f901f..3e115ed8b44 100644 --- a/docs/docs/aztec/concepts/storage/index.md +++ b/docs/docs/aztec/concepts/storage/index.md @@ -10,56 +10,3 @@ In Aztec, private data and public data are stored in two trees; a public data tr These trees have in common that they store state for _all_ accounts on the Aztec network directly as leaves. This is different from Ethereum, where a state trie contains smaller tries that hold the individual accounts' storage. It also means that we need to be careful about how we allocate storage to ensure that they don't collide! We say that storage should be _siloed_ to its contract. The exact way of siloing differs a little for public and private storage. Which we will see in the following sections. - -## Public State Slots - -As mentioned in [State Model](../state_model/index.md), Aztec public state behaves similarly to public state on Ethereum from the point of view of the developer. Behind the scenes however, the storage is managed differently. As mentioned, public state has just one large sparse tree in Aztec - so we silo slots of public data by hashing it together with its contract address. - -The mental model is that we have a key-value store, where the siloed slot is the key, and the value is the data stored in that slot. You can think of the `real_storage_slot` identifying its position in the tree, and the `logical_storage_slot` identifying the position in the contract storage. - -```rust -real_storage_slot = H(contract_address, logical_storage_slot) -``` - -The siloing is performed by the [Kernel circuits](../circuits/index.md). - -For structs and arrays, we are logically using a similar storage slot computation to ethereum, e.g., as a struct with 3 fields would be stored in 3 consecutive slots. However, because the "actual" storage slot is computed as a hash of the contract address and the logical storage slot, the actual storage slot is not consecutive. - -## Private State Slots - Slots aren't real - -Private storage is a different beast. As you might remember from [Hybrid State Model](../state_model/index.md), private state is stored in encrypted logs and the corresponding private state commitments in append-only tree where each leaf is a commitment. Being append-only, means that leaves are never updated or deleted; instead a nullifier is emitted to signify that some note is no longer valid. A major reason we used this tree, is that lookups at a specific storage slot would leak information in the context of private state. If you could look up a specific address balance just by looking at the storage slot, even if encrypted you would be able to see it changing! That is not good privacy. - -Following this, the storage slot as we know it doesn't really exist. The leaves of the note hashes tree are just commitments to content (think of it as a hash of its content). - -Nevertheless, the concept of a storage slot is very useful when writing applications, since it allows us to reason about distinct and disjoint pieces of data. For example we can say that the balance of an account is stored in a specific slot and that the balance of another account is stored in another slot with the total supply stored in some third slot. By making sure that these slots are disjoint, we can be sure that the balances are not mixed up and that someone cannot use the total supply as their balance. - -### But how? - -If we include the storage slot, as part of the note whose commitment is stored in the note hashes tree, we can _logically link_ all the notes that make up the storage slot. For the case of a balance, we can say that the balance is the sum of all the notes that have the same storage slot - in the same way that your physical \$ balance might be the sum of all the notes in your wallet. - -Similarly to how we siloed the public storage slots, we can silo our private storage by hashing the logical storage slot together with the note content. - -```rust -note_hash = H(logical_storage_slot, note_content_hash); -``` - -This siloing (there will be more) is done in the application circuit, since it is not necessary for security of the network (but only the application). -:::info -The private variable wrappers `PrivateSet` and `PrivateMutable` in Aztec.nr include the `logical_storage_slot` in the commitments they compute, to make it easier for developers to write contracts without having to think about how to correctly handle storage slots. -::: - -When reading the values for these notes, the application circuit can then constrain the values to only read notes with a specific logical storage slot. - -To ensure that one contract cannot insert storage that other contracts would believe is theirs, we do a second siloing by hashing the `commitment` with the contract address. - -```rust -siloed_note_hash = H(contract_address, note_hash); -``` - -By doing this address-siloing at the kernel circuit we _force_ the inserted commitments to include and not lie about the `contract_address`. - -:::info -To ensure that nullifiers don't collide across contracts we also force this contract siloing at the kernel level. -::: - -For an example of this see [developer documentation on storage](../../../reference/developer_references/smart_contract_reference/storage/index.md). diff --git a/docs/docs/aztec/concepts/state_model/index.md b/docs/docs/aztec/concepts/storage/state_model/index.md similarity index 98% rename from docs/docs/aztec/concepts/state_model/index.md rename to docs/docs/aztec/concepts/storage/state_model/index.md index 37a0455456f..9aa78d92d3f 100644 --- a/docs/docs/aztec/concepts/state_model/index.md +++ b/docs/docs/aztec/concepts/storage/state_model/index.md @@ -35,4 +35,4 @@ This is achieved with two main features: ## Further reading -Read more about how to leverage the Aztec state model in Aztec contracts [here](../storage/index.md). +Read more about how to leverage the Aztec state model in Aztec contracts [here](../../storage/index.md). diff --git a/docs/docs/aztec/concepts/storage/state_model/public_vm.md b/docs/docs/aztec/concepts/storage/state_model/public_vm.md new file mode 100644 index 00000000000..528ee5f8d46 --- /dev/null +++ b/docs/docs/aztec/concepts/storage/state_model/public_vm.md @@ -0,0 +1,5 @@ +--- +title: Public VM +--- + +Refer to the [protocol specs section](../../../../protocol-specs/public-vm/index.md) for the latest information about the Aztec Public VM. diff --git a/docs/docs/aztec/concepts/storage/storage_slots.md b/docs/docs/aztec/concepts/storage/storage_slots.md new file mode 100644 index 00000000000..d3121c645d9 --- /dev/null +++ b/docs/docs/aztec/concepts/storage/storage_slots.md @@ -0,0 +1,55 @@ + +# Storage Slots + +## Public State Slots + +As mentioned in [State Model](../storage/state_model/index.md), Aztec public state behaves similarly to public state on Ethereum from the point of view of the developer. Behind the scenes however, the storage is managed differently. As mentioned, public state has just one large sparse tree in Aztec - so we silo slots of public data by hashing it together with its contract address. + +The mental model is that we have a key-value store, where the siloed slot is the key, and the value is the data stored in that slot. You can think of the `real_storage_slot` identifying its position in the tree, and the `logical_storage_slot` identifying the position in the contract storage. + +```rust +real_storage_slot = H(contract_address, logical_storage_slot) +``` + +The siloing is performed by the [Kernel circuits](../circuits/index.md). + +For structs and arrays, we are logically using a similar storage slot computation to ethereum, e.g., as a struct with 3 fields would be stored in 3 consecutive slots. However, because the "actual" storage slot is computed as a hash of the contract address and the logical storage slot, the actual storage slot is not consecutive. + +## Private State Slots + +Private storage is a different beast. As you might remember from [Hybrid State Model](../storage/state_model/index.md), private state is stored in encrypted logs and the corresponding private state commitments in append-only tree, called the note hash tree where each leaf is a commitment. Append-only means that leaves are never updated or deleted; instead a nullifier is emitted to signify that some note is no longer valid. A major reason we used this tree, is that updates at a specific storage slot would leak information in the context of private state, even if the value is encrypted. That is not good privacy. + +Following this, the storage slot as we know it doesn't really exist. The leaves of the note hashes tree are just commitments to content (think of it as a hash of its content). + +Nevertheless, the concept of a storage slot is very useful when writing applications, since it allows us to reason about distinct and disjoint pieces of data. For example we can say that the balance of an account is stored in a specific slot and that the balance of another account is stored in another slot with the total supply stored in some third slot. By making sure that these slots are disjoint, we can be sure that the balances are not mixed up and that someone cannot use the total supply as their balance. + +### Implementation + +If we include the storage slot, as part of the note whose commitment is stored in the note hashes tree, we can _logically link_ all the notes that make up the storage slot. For the case of a balance, we can say that the balance is the sum of all the notes that have the same storage slot - in the same way that your physical wallet balance is the sum of all the physical notes in your wallet. + +Similarly to how we siloed the public storage slots, we can silo our private storage by hashing the logical storage slot together with the note content. + +```rust +note_hash = H(logical_storage_slot, note_content_hash); +``` + +Note hash siloing is done in the application circuit, since it is not necessary for security of the network (but only the application). +:::info +The private variable wrappers `PrivateSet` and `PrivateMutable` in Aztec.nr include the `logical_storage_slot` in the commitments they compute, to make it easier for developers to write contracts without having to think about how to correctly handle storage slots. +::: + +When reading the values for these notes, the application circuit can then constrain the values to only read notes with a specific logical storage slot. + +To ensure that contracts can only modify their own logical storage, we do a second siloing by hashing the `commitment` with the contract address. + +```rust +siloed_note_hash = H(contract_address, note_hash); +``` + +By doing this address-siloing at the kernel circuit we _force_ the inserted commitments to include and not lie about the `contract_address`. + +:::info +To ensure that nullifiers don't collide across contracts we also force this contract siloing at the kernel level. +::: + +For an example of this see [developer documentation on storage](../../../reference/developer_references/smart_contract_reference/storage/index.md). diff --git a/docs/docs/aztec/overview.md b/docs/docs/aztec/concepts_overview.md similarity index 53% rename from docs/docs/aztec/overview.md rename to docs/docs/aztec/concepts_overview.md index 32a353fa80e..aeb4dccc53d 100644 --- a/docs/docs/aztec/overview.md +++ b/docs/docs/aztec/concepts_overview.md @@ -1,17 +1,20 @@ --- -title: What is Aztec? +title: Concepts Overview sidebar_position: 0 -id: overview tags: [protocol] --- import Image from "@theme/IdealImage"; -This page outlines Aztec's fundamental technical concepts. +This page outlines Aztec's fundamental technical concepts. It is recommended to read this before diving into building on Aztec. -## Aztec Overview +## What is Aztec? - +Aztec is a privacy-first Layer 2 on Ethereum. It supports smart contracts with both private & public state and private & public execution. + +## High level view + + 1. A user interacts with Aztec through Aztec.js (like web3js or ethersjs) 2. Private functions are executed in the PXE, which is client-side @@ -20,50 +23,71 @@ This page outlines Aztec's fundamental technical concepts. 5. The Public VM rolls up the private & public transaction rollups 6. These rollups are submitted to Ethereum +## Private and public execution + +Private functions and public functions are executed in different environments. + +### Private Execution Environment (PXE) + +Private functions are executed first on the user's device in the Private Execution Environment (PXE, pronounced 'pixie'). It is a client-side library for the execution of private operations. It holds keys, notes, and generates proofs. It is included in aztec.js, a TypeScript library, and can be run within Node or the browser. + +### Aztec VM + +Public functions are executed by the Aztec Virtual Machine (AVM), which is conceptually similar to the Ethereum Virtual Machine (EVM). To learn more about how it works and its instruction set, go to the [protocol specs](../protocol-specs/public-vm/intro.md). + The PXE is unaware of the Public VM. And the Public VM is unaware of the PXE. They are completely separate execution environments. This means: - The PXE and the Public VM cannot directly communicate with each other - Private transactions in the PXE are executed first, followed by public transactions -### Private and public state +## Private and public state -Private state works with UTXOs, or what we call notes. To keep things private, everything is stored in an [append-only UTXO tree](./concepts/storage/trees/index.md), and a nullifier is created when notes are invalidated. Nullifiers are then stored in their own [nullifier tree](./concepts/storage/trees/index.md). +Private state works with UTXOs, which are chunks of data that we call notes. To keep things private, notes are stored in an [append-only UTXO tree](./concepts/storage/trees/index.md), and a nullifier is created when notes are invalidated (aka deleted). Nullifiers are stored in their own [nullifier tree](./concepts/storage/trees/index.md). Public state works similarly to other chains like Ethereum, behaving like a public ledger. Public data is stored in a [public data tree](./concepts/storage/trees/index.md#public-state-tree). -Aztec [smart contract](./smart_contracts_overview.md) developers should keep in mind that different types are used when manipulating private or public state. Working with private state is creating commitments and nullifiers to state, whereas working with public state is directly updating state. +![Public vs private state](../../static/img/public-and-private-state-diagram.png) -## Accounts +Aztec [smart contract](./smart_contracts_overview.md) developers should keep in mind that different data types are used when manipulating private or public state. Working with private state is creating commitments and nullifiers to state, whereas working with public state is directly updating state. -Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for transaction signing, nonce management, and fee payments. +## Accounts and keys -Developers can write their own account contract to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed. +### Account abstraction -Learn more about account contracts [here](./concepts/accounts/index.md). +Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for authorizing transactions, nonce management, and fee payments. -## Smart contracts +Developers can write their own account contract to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed. -Developers can write [smart contracts](./smart_contracts_overview.md) that manipulate both public and private state. They are written in a framework on top of Noir, the zero-knowledge domain-specific language developed specifically for Aztec. Outside of Aztec, Noir is used for writing circuits that can be verified on EVM chains. +Learn more about account contracts [here](./concepts/accounts/index.md). -Noir has its own doc site that you can find [here](https://noir-lang.org). +### Key pairs -## Communication with Ethereum +Each account in Aztec is backed by 3 key pairs: -Aztec allows private communications with Ethereum - ie no-one knows where the transaction is coming from, just that it is coming from somewhere on Aztec. +- A **nullifier key pair** used for note nullifier computation +- A **incoming viewing key pair** used to encrypt a note for the recipient +- A **outgoing viewing key pair** used to encrypt a note for the sender -This is achieved through portals - these are smart contracts deployed on an EVM that are related to the Ethereum smart contract you want to interact with. +As Aztec has native account abstraction, accounts do not automatically have a signing key pair to authenticate transactions. This is up to the account contract developer to implement. -Learn more about portals [here](../protocol-specs/l1-smart-contracts/index.md). +## Noir -## Circuits +Noir is a zero-knowledge domain specific language used for writing smart contracts for the Aztec network. It is also possible to write circuits with Noir that can be verified on or offchain. For more in-depth docs into the features of Noir, go to the [Noir documentation](https://noir-lang.org/). -Aztec operates on three types of circuits: +## What's next? -- [Private kernel circuits](../aztec/concepts/circuits/kernels/private_kernel.md), which are executed by the user on their own device and prove correct execution of a function -- [Public kernel circuits](../aztec/concepts/circuits/kernels/public_kernel.md), which are executed by the [sequencer](./network/sequencer/index.md) and ensure the stack trace of transactions adheres to function execution rules -- [Rollup circuits](../aztec/concepts/circuits/index.md), which bundle all of the Aztec transactions into a proof that can be efficiently verified on Ethereum +### Start coding -## What's next? +
+ + +

Developer Getting Started Guide

+ + + Follow the getting started guide to start developing with the Aztec Sandbox + + +
### Dive deeper into how Aztec works @@ -82,7 +106,7 @@ Explore the Concepts for a deeper understanding into the components that make up -

Circuits

+

Protocol Circuits

 Central to Aztec's operations are circuits in the core protocol and the developer-written Aztec.nr contracts @@ -98,7 +122,7 @@ Explore the Concepts for a deeper understanding into the components that make up - +

State model

 @@ -126,16 +150,3 @@ Explore the Concepts for a deeper understanding into the components that make up - -### Start coding - -
- - -

Developer Getting Started Guide

- - - Follow the getting started guide to start developing with the Aztec Sandbox - - -
\ No newline at end of file diff --git a/docs/docs/aztec/smart_contracts/contract_creation.md b/docs/docs/aztec/smart_contracts/contract_creation.md index b648178e14e..02858dca070 100644 --- a/docs/docs/aztec/smart_contracts/contract_creation.md +++ b/docs/docs/aztec/smart_contracts/contract_creation.md @@ -7,4 +7,4 @@ The latest information about contract deployment has moved to the protocol speci ## Further reading -To see how to deploy a contract in practice, check out the [dapp development tutorial](../../tutorials/codealong/simple_dapp/index.md). +To see how to deploy a contract in practice, check out the [dapp development tutorial](../../tutorials/codealong/js_tutorials/simple_dapp/index.md). diff --git a/docs/docs/guides/developer_guides/js_apps/test.md b/docs/docs/guides/developer_guides/js_apps/test.md index a290623a51c..383358fa8c2 100644 --- a/docs/docs/guides/developer_guides/js_apps/test.md +++ b/docs/docs/guides/developer_guides/js_apps/test.md @@ -8,7 +8,7 @@ In this guide we will cover how to interact with your Aztec.nr smart contracts i ## Prerequisites - A compiled contract with TS interface (read [how to compile](../smart_contracts/how_to_compile_contract.md)) -- Your sandbox running (read [getting started](../getting_started.md)) +- Your sandbox running (read [getting started](../../getting_started.md)) ## Create TS file and install libraries @@ -107,7 +107,7 @@ To query storage directly, you'll need to know the slot you want to access. This #### Querying private state -Private state in the Aztec is represented via sets of [private notes](../../../aztec/concepts/state_model/index.md#private-state). We can query the Private Execution Environment (PXE) for all notes encrypted for a given user in a contract slot. For example, this gets all notes encrypted for the `owner` user that are stored on the token contract address and on the slot that was calculated earlier. To calculate the actual balance, it extracts the `value` of each note, which is the first element, and sums them up. +Private state in the Aztec is represented via sets of [private notes](../../../aztec/concepts/storage/state_model/index.md#private-state). We can query the Private Execution Environment (PXE) for all notes encrypted for a given user in a contract slot. For example, this gets all notes encrypted for the `owner` user that are stored on the token contract address and on the slot that was calculated earlier. To calculate the actual balance, it extracts the `value` of each note, which is the first element, and sums them up. #include_code private-storage /yarn-project/end-to-end/src/guides/dapp_testing.test.ts typescript diff --git a/docs/docs/guides/developer_guides/local_env/creating_schnorr_accounts.md b/docs/docs/guides/developer_guides/local_env/creating_schnorr_accounts.md index e8668294c95..b45b653b7f9 100644 --- a/docs/docs/guides/developer_guides/local_env/creating_schnorr_accounts.md +++ b/docs/docs/guides/developer_guides/local_env/creating_schnorr_accounts.md @@ -18,7 +18,7 @@ An in-depth explainer about accounts on aztec can be found [here](../../../aztec ## Pre-requisites -Have a running Sandbox and a repository that interacts with it as explained [in the quickstart](../getting_started.md). +Have a running Sandbox and a repository that interacts with it as explained [in the quickstart](../../getting_started.md). Let's assume you have a file `src/index.ts` from the example used in the Sandbox page. diff --git a/docs/docs/guides/developer_guides/local_env/run_more_than_one_pxe_sandbox.md b/docs/docs/guides/developer_guides/local_env/run_more_than_one_pxe_sandbox.md index ad575e6baf6..d937f6f5f13 100644 --- a/docs/docs/guides/developer_guides/local_env/run_more_than_one_pxe_sandbox.md +++ b/docs/docs/guides/developer_guides/local_env/run_more_than_one_pxe_sandbox.md @@ -23,7 +23,7 @@ This removes any other arguments, allowing you to ensure an isolated environment In another terminal, run: ```bash -aztec start --port 8081 --pxe nodeUrl=http://host.docker.internal:8080/ +aztec start --port 8081 --pxe --pxe.nodeUrl=http://host.docker.internal:8080/ ``` 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`. diff --git a/docs/docs/guides/developer_guides/smart_contracts/how_to_compile_contract.md b/docs/docs/guides/developer_guides/smart_contracts/how_to_compile_contract.md index 1c68a23fda7..056290ad93b 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/how_to_compile_contract.md +++ b/docs/docs/guides/developer_guides/smart_contracts/how_to_compile_contract.md @@ -444,7 +444,7 @@ export class TokenContract extends ContractBase { } ``` -Read more about interacting with contracts using `aztec.js` [by following this tutorial](../../../tutorials/codealong/aztecjs-getting-started). +Read more about interacting with contracts using `aztec.js` [by following this tutorial](../../../tutorials/codealong/js_tutorials/aztecjs-getting-started.md). ### Aztec.nr interfaces diff --git a/docs/docs/guides/developer_guides/smart_contracts/how_to_deploy_contract.md b/docs/docs/guides/developer_guides/smart_contracts/how_to_deploy_contract.md index 7df9f76b1a8..634be0fa19d 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/how_to_deploy_contract.md +++ b/docs/docs/guides/developer_guides/smart_contracts/how_to_deploy_contract.md @@ -12,7 +12,7 @@ Once you have [compiled](./how_to_compile_contract.md) your contracts you can pr - `aztec-nargo` installed (go to [Sandbox section](../../../reference/developer_references/sandbox_reference/sandbox-reference.md) for installation instructions) - contract artifacts ready (go to [How to Compile Contract](./how_to_compile_contract.md) for instructions on how to compile contracts) -- Aztec Sandbox running (go to [Getting Started](../getting_started.md) for instructions on how to install and run the sandbox) +- Aztec Sandbox running (go to [Getting Started](../../getting_started.md) for instructions on how to install and run the sandbox) ## Deploy diff --git a/docs/docs/guides/developer_guides/smart_contracts/testing_contracts/testing.md b/docs/docs/guides/developer_guides/smart_contracts/testing_contracts/testing.md index 86d470de664..56673255958 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/testing_contracts/testing.md +++ b/docs/docs/guides/developer_guides/smart_contracts/testing_contracts/testing.md @@ -38,7 +38,7 @@ So to summarize: ### Running TXE -If you have [the sandbox](../../getting_started.md) installed, you can run TXE tests using: +If you have [the sandbox](../../../getting_started.md) installed, you can run TXE tests using: `aztec test` diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/call_functions.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/call_functions.md index fcca446ddad..2df88f48025 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/call_functions.md +++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/call_functions.md @@ -5,15 +5,13 @@ tags: [functions, contracts] --- - - A contract is a collection of persistent state variables and functions which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called. -### Contract +### Defining a contract A contract may be declared and given a name using the `contract` keyword (see snippet below). By convention, contracts are named in `PascalCase`. @@ -32,4 +30,53 @@ contract MyContract { There is no [`main()` (GitHub link)](https://noir-lang.org/docs/getting_started/project_breakdown/#mainnr) function within a Noir `contract` scope. More than one function can be an entrypoint. ::: -To understand how to call a function from another contract, follow the [crowdfunding tutorial](../../../../tutorials/codealong/contract_tutorials/crowdfunding_contract.md). +### Add as a dependency in Nargo.toml + +Import the contract that you want to call into your `Nargo.toml` under `dependencies` like this: + +``` +token = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="noir-projects/noir-contracts/contracts/token_contract" } +``` + +### Import into your contract + +At the top of your contract, import the contract you want to call like this: + +``` +use token::Token; +``` + +### Call the function + +To call the function, you need to + +- Specify the address of the contract with `Contract::at(contract_address)` +- Call the function name with `.function_name()` +- Pass the parameters into the function call, like `.function_name(param1,param2)` +- Specify the type of call you want to make and pass a mut reference to the context, like `.call(&mut context)` + +#### Private calls + +To call a private function, you can just use `call()` like this: + +#include_code call_function noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr rust + +#### Public -> Public calls + +To call a public function from a public function, it is the same as above. You can just use `call()` like this: + +#include_code public_to_public_call noir-projects/noir-contracts/contracts/lending_contract/src/main.nr rust + +#### Private -> Public calls + +To call a public function from private, you will need to enqueue it like this: + +#include_code enqueue_public /noir-projects/noir-contracts/contracts/lending_contract/src/main.nr rust + +Public functions are always executed after private execution. To learn why, read the [concepts overview](../../../../aztec/concepts_overview.md). + +#### Other call types + +There are other call types, for example to ensure no state changes are made. You can learn more about them in the [call types glossary](../../../../aztec/glossary/call_types.md). + + diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/index.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/index.md index b002d3dd13f..aacd44df9d8 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/index.md +++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/common_patterns/index.md @@ -108,7 +108,7 @@ Hence, it's necessary to add a "randomness" field to your note to prevent such a ### L1 -- L2 interactions -Refer to [Token Portal codealong tutorial on bridging tokens between L1 and L2](../../../../../tutorials/codealong/contract_tutorials/advanced/token_bridge/index.md) and/or [Uniswap smart contract example that shows how to swap on L1 using funds on L2](../../../../../tutorials/examples/uniswap/index.md). Both examples show how to: +Refer to [Token Portal codealong tutorial on bridging tokens between L1 and L2](../../../../../tutorials/codealong/contract_tutorials/token_bridge/index.md) and/or [Uniswap smart contract example that shows how to swap on L1 using funds on L2](../../../../../tutorials/examples/uniswap/index.md). Both examples show how to: 1. L1 -> L2 message flow 2. L2 -> L1 message flow diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/notes/index.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/notes/index.md index b40f4be495e..ec9f829577b 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/notes/index.md +++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/notes/index.md @@ -4,4 +4,4 @@ sidebar_position: 6 tags: [contracts, notes] --- -Notes are the fundamental data structure in Aztec when working with private state. In this section there are guides about how to work with `AddressNote`, `ValueNote`, and custom notes in Aztec.nr. You can learn more about notes in the [concepts section](../../../../../aztec/concepts/state_model/index.md#private-state). \ No newline at end of file +Notes are the fundamental data structure in Aztec when working with private state. In this section there are guides about how to work with `AddressNote`, `ValueNote`, and custom notes in Aztec.nr. You can learn more about notes in the [concepts section](../../../../../aztec/concepts/storage/state_model/index.md#private-state). \ No newline at end of file diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md index d08078b0aec..439bf5f9377 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md +++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md @@ -5,7 +5,7 @@ tags: [contracts, portals] Is this your first time hearing the word `Portal`? You might want to check out the [protocol specs](../../../../../protocol-specs/l1-smart-contracts/index.md). -Follow the [token bridge tutorial](../../../../../tutorials/codealong/contract_tutorials/advanced/token_bridge/index.md) for hands-on experience writing and deploying a Portal contract. +Follow the [token bridge tutorial](../../../../../tutorials/codealong/contract_tutorials/token_bridge/index.md) for hands-on experience writing and deploying a Portal contract. ## Passing data to the rollup @@ -43,7 +43,7 @@ Note that while the `secret` and the `content` are both hashed, they are actuall ### Token bridge example -Computing the `content` must currently be done manually, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example (codealong tutorial)](../../../../../tutorials/codealong/contract_tutorials/advanced/token_bridge/index.md). +Computing the `content` must currently be done manually, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example (codealong tutorial)](../../../../../tutorials/codealong/contract_tutorials/token_bridge/index.md). #include_code claim_public /noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr rust diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/storage/notes.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/storage/notes.md index bea6aa7461b..b4f737c7857 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/storage/notes.md +++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/storage/notes.md @@ -83,9 +83,9 @@ To update a value, its previous note hash(es) are nullified. The new note value Some optional background resources on notes can be found here: -- [High level network architecture](../../../../../aztec/overview.md), specifically the Private Execution Environment +- [High level network architecture](../../../../../aztec/concepts_overview.md), specifically the Private Execution Environment - [Transaction lifecycle (simple diagram)](../../../../../aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle) -- [Public and Private state](../../../../../aztec/concepts/state_model/index.md) +- [Public and Private state](../../../../../aztec/concepts/storage/state_model/index.md) Notes touch several core components of the protocol, but we will focus on a the essentials first. diff --git a/docs/docs/guides/developer_guides/getting_started.md b/docs/docs/guides/getting_started.md similarity index 98% rename from docs/docs/guides/developer_guides/getting_started.md rename to docs/docs/guides/getting_started.md index cceabca3bfd..1e1eafa8750 100644 --- a/docs/docs/guides/developer_guides/getting_started.md +++ b/docs/docs/guides/getting_started.md @@ -225,8 +225,6 @@ Simulation result: 25n Now you have a development network running, so you're ready to start coding your first app with Aztec.nr and Aztec.js! -If you want to start coding, head over to the Tutorials & Examples section and write & deploy your first smart contract. -
@@ -237,3 +235,5 @@ If you want to start coding, head over to the Tutorials & Examples section and w
+ +If you'd rather clone a repo, check out the [Aztec Starter](https://github.com/AztecProtocol/aztec-starter). diff --git a/docs/docs/guides/index.md b/docs/docs/guides/index.md index 174895e4a37..cb047909a87 100644 --- a/docs/docs/guides/index.md +++ b/docs/docs/guides/index.md @@ -1,17 +1,20 @@ --- id: index sidebar_position: 0 -title: Guides +title: Guides and Tutorials --- -# Popular Guides +# Guides and Tutorials -Guides are step-by-step how-tos to achieve a specific goal. On this page you can find the most popular ones. You can also explore them all by checking out the sidebar. +In this section you will find: + +- A list of tutorials in order of increasing complexity, allowing you to write contracts and build applications on Aztec +- How-to guides for accomplishing quick, specific goals ## Getting Started
- +

Getting Started

 @@ -21,94 +24,24 @@ Guides are step-by-step how-tos to achieve a specific goal. On this page you can
-## Building smart contracts +## Building applications
- - -

Compile a contract

- - - Learn how to compile a smart contract and generate TypeScript bindings - - - - - -

Deploy a contract

- - - Deploy a contract to a local Aztec sandbox - - - - + -

Testing Contracts

+

Contract Tutorials

 - Write tests for your contracts and run them in the TXE + Go from zero to hero by following these tutorials in order, starting with a counter contract - + -

Communicate with L1

+

Full stack app on Aztec

 - How to use portals to communicate with L1 from your contract - - -
- -
- View all smart contract guides -
- -## JavaScript - -
- - -

Send a transaction

- - - Use Aztec.JS to send a transaction by calling a function on a smart contract - - - - - -

Testing

- - - Write end-to-end tests in Javascript using Aztec.JS - - -
- -
- View all JavaScript guides -
- -## Local environment - -
- - -

Update your environment

- - - Update all aspects of your Aztec environment, including the sandbox, aztec-nargo, Aztec.nr packages, and Aztec.js packages - - - - - -

Run more than one PXE

- - - Test that your contracts can work with multiple interactions by running a second PXE + Learn how everything works together by building an app in JavaScript that connects to a contract
@@ -132,8 +65,4 @@ Guides are step-by-step how-tos to achieve a specific goal. On this page you can Participate in the Aztec protocol as a prover node, proving the rollup integrity that is pivotal to the protocol. Runs on hardware fit for data centers. - - -
- View all local environment guides
\ No newline at end of file diff --git a/docs/docs/index.mdx b/docs/docs/index.mdx index b38e104d38e..938bf165d38 100644 --- a/docs/docs/index.mdx +++ b/docs/docs/index.mdx @@ -7,29 +7,43 @@ sidebar_position: 0 # Aztec Documentation -## Aztec is a Privacy-First L2 on Ethereum +## What is Aztec? + +### Aztec is a Privacy-First L2 on Ethereum On Ethereum today, everything is publicly visible, by everyone. In the real world, people enjoy privacy. Aztec brings privacy to Ethereum. -## Get started +- private functions, executed and proved on a user's device +- public functions, executed in the Aztec Virtual Machine +- private state, stored as UTXOs that only the owner can decrypt +- public state, stored in a public merkle tree +- composability between private/public execution and private/public state +- public and private messaging with Ethereum + +To learn more about how Aztec achieves these things, check out the [Aztec concepts overview](/aztec/concepts_overview). -
- +## Start coding + +
+ -

Tutorials

+

Developer Getting Started Guide

 - Start writing Aztec contracts with our tutorials. + Follow the getting started guide to start developing with the Aztec Sandbox +
- +## Learn how Aztec works + +
+ -

References

+

Aztec Overview

 - Review reference materials for building on Aztec. + Learn the core concepts that make up the Aztec Protocol - -
+
\ No newline at end of file diff --git a/docs/docs/protocol-specs/public-vm/gen/_instruction-set.mdx b/docs/docs/protocol-specs/public-vm/gen/_instruction-set.mdx index 4d081801c4d..126d9e239ad 100644 --- a/docs/docs/protocol-specs/public-vm/gen/_instruction-set.mdx +++ b/docs/docs/protocol-specs/public-vm/gen/_instruction-set.mdx @@ -1054,6 +1054,7 @@ context.machineState.pc = loc`} - **Details**: Target location is an immediate value (a constant in the bytecode). - **Bit-size**: 48 +[![](/img/protocol-specs/public-vm/bit-formats/INTERNALCALL.png)](/img/protocol-specs/public-vm/bit-formats/INTERNALCALL.png) ### `INTERNALRETURN` Return from an internal call. Pop from the internal call stack and jump to the popped location. diff --git a/docs/docs/reference/developer_references/sandbox_reference/sandbox-reference.md b/docs/docs/reference/developer_references/sandbox_reference/sandbox-reference.md index 82435874756..873fc3edbff 100644 --- a/docs/docs/reference/developer_references/sandbox_reference/sandbox-reference.md +++ b/docs/docs/reference/developer_references/sandbox_reference/sandbox-reference.md @@ -6,7 +6,7 @@ sidebar_position: 0 :::tip -For a quick start, follow the [guide](../../../guides/developer_guides/getting_started) to install the sandbox. +For a quick start, follow the [guide](../../../guides/getting_started) to install the sandbox. ::: diff --git a/docs/docs/reference/developer_references/smart_contract_reference/storage/index.md b/docs/docs/reference/developer_references/smart_contract_reference/storage/index.md index f85fd6f3a82..d5c3bccd90e 100644 --- a/docs/docs/reference/developer_references/smart_contract_reference/storage/index.md +++ b/docs/docs/reference/developer_references/smart_contract_reference/storage/index.md @@ -101,6 +101,6 @@ require(minters[msg.sender], "caller is not minter"); ## Concepts mentioned -- [State Model](../../../../aztec/concepts/state_model/index.md) +- [State Model](../../../../aztec/concepts/storage/state_model/index.md) - [Public-private execution](../../../../aztec/smart_contracts/functions/public_private_calls.md) - [Function Contexts](../../../../aztec/smart_contracts/functions/context.md) diff --git a/docs/docs/reference/developer_references/smart_contract_reference/storage/private_state.md b/docs/docs/reference/developer_references/smart_contract_reference/storage/private_state.md index a2f84a70456..ec24ad687b8 100644 --- a/docs/docs/reference/developer_references/smart_contract_reference/storage/private_state.md +++ b/docs/docs/reference/developer_references/smart_contract_reference/storage/private_state.md @@ -4,7 +4,7 @@ title: Private State On this page we will look at how to manage private state in Aztec contracts. We will look at how to declare private state, how to read and write to it, and how to use it in your contracts. -For a higher level overview of the state model in Aztec, see the [hybrid state model](../../../../aztec/concepts/state_model/index.md) page. +For a higher level overview of the state model in Aztec, see the [hybrid state model](../../../../aztec/concepts/storage/state_model/index.md) page. ## Overview diff --git a/docs/docs/reference/developer_references/smart_contract_reference/storage/public_state.md b/docs/docs/reference/developer_references/smart_contract_reference/storage/public_state.md index 1c2c46cded4..d49aebd81e2 100644 --- a/docs/docs/reference/developer_references/smart_contract_reference/storage/public_state.md +++ b/docs/docs/reference/developer_references/smart_contract_reference/storage/public_state.md @@ -4,7 +4,7 @@ title: Public State On this page we will look at how to manage public state in Aztec contracts. We will look at how to declare public state, how to read and write to it, and how to use it in your contracts. -For a higher level overview of the state model in Aztec, see the [state model](../../../../aztec/concepts/state_model/index.md) concepts page. +For a higher level overview of the state model in Aztec, see the [state model](../../../../aztec/concepts/storage/state_model/index.md) concepts page. ## `PublicMutable` diff --git a/docs/docs/tutorials/codealong/contract_tutorials/advanced/_category_.json b/docs/docs/tutorials/codealong/contract_tutorials/advanced/_category_.json deleted file mode 100644 index 5fe169c13f3..00000000000 --- a/docs/docs/tutorials/codealong/contract_tutorials/advanced/_category_.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "label": "Advanced", - "position": 6, - "collapsible": true, - "collapsed": true -} diff --git a/docs/docs/tutorials/codealong/contract_tutorials/counter_contract.md b/docs/docs/tutorials/codealong/contract_tutorials/counter_contract.md index 22dc4e4e5b3..0ab8bc479b5 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/counter_contract.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/counter_contract.md @@ -7,7 +7,7 @@ In this guide, we will create our first Aztec.nr smart contract. We will build a ## Prerequisites -- You have followed the [quickstart](../../../guides/developer_guides/getting_started.md) +- You have followed the [quickstart](../../../guides/getting_started.md) - Running Aztec Sandbox - Installed [Noir LSP](../../../guides/developer_guides/local_env/installing_noir_lsp.md) (optional) diff --git a/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md b/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md index 397ac584839..1f11c0735e0 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/crowdfunding_contract.md @@ -26,7 +26,7 @@ Along the way you will: ### Install tools -Please ensure that you already have [Installed the Sandbox](../../../guides/developer_guides/getting_started) +Please ensure that you already have [Installed the Sandbox](../../../guides/getting_started) ### Create an Aztec project diff --git a/docs/docs/tutorials/codealong/contract_tutorials/private_voting_contract.md b/docs/docs/tutorials/codealong/contract_tutorials/private_voting_contract.md index 7f3aba4aa76..2c7f0d81f86 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/private_voting_contract.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/private_voting_contract.md @@ -21,7 +21,7 @@ To keep things simple, we won't create ballots or allow for delegate voting. ## Prerequisites -- You have followed the [quickstart](../../../guides/developer_guides/getting_started) to install `aztec-nargo` and `aztec`. +- You have followed the [quickstart](../../../guides/getting_started) to install `aztec-nargo` and `aztec`. - Running Aztec Sandbox ## Set up a project diff --git a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/0_setup.md b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/0_setup.md similarity index 98% rename from docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/0_setup.md rename to docs/docs/tutorials/codealong/contract_tutorials/token_bridge/0_setup.md index 200c4347b48..4ec44d065e7 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/0_setup.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/0_setup.md @@ -17,7 +17,7 @@ We recommend going through this setup to fully understand where things live. - [node v18+ (GitHub link)](https://github.com/tj/n) - [docker](https://docs.docker.com/) -- [Aztec sandbox](../../../../../guides/developer_guides/getting_started) - you should have this running before starting the tutorial +- [Aztec sandbox](../../../../../guides/getting_started) - you should have this running before starting the tutorial Start the sandbox diff --git a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/1_depositing_to_aztec.md b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/1_depositing_to_aztec.md similarity index 100% rename from docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/1_depositing_to_aztec.md rename to docs/docs/tutorials/codealong/contract_tutorials/token_bridge/1_depositing_to_aztec.md diff --git a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/2_minting_on_aztec.md b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/2_minting_on_aztec.md similarity index 100% rename from docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/2_minting_on_aztec.md rename to docs/docs/tutorials/codealong/contract_tutorials/token_bridge/2_minting_on_aztec.md diff --git a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/3_withdrawing_to_l1.md b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/3_withdrawing_to_l1.md similarity index 98% rename from docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/3_withdrawing_to_l1.md rename to docs/docs/tutorials/codealong/contract_tutorials/token_bridge/3_withdrawing_to_l1.md index a0c1b508212..ae28246bde3 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/3_withdrawing_to_l1.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/3_withdrawing_to_l1.md @@ -19,7 +19,7 @@ The `exit_to_l1_public` function enables anyone to withdraw their L2 tokens back 1. Like with our deposit function, we need to create the L2 to L1 message. The content is the _amount_ to burn, the recipient address, and who can execute the withdraw on the L1 portal on behalf of the user. It can be `0x0` for anyone, or a specified address. 2. `context.message_portal()` passes this content to the kernel circuit which creates the proof for the transaction. The kernel circuit then adds the sender (the L2 address of the bridge + version of aztec) and the recipient (the portal to the L2 address + the chain ID of L1) under the hood, to create the message which gets added as part of the transaction data published by the sequencer and is stored in the outbox for consumption. 3. The `context.message_portal()` takes the recipient and content as input, and will insert a message into the outbox. We set the recipient to be the portal address read from storage of the contract. -4. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](../../token_contract.md#authorizing-token-spends). +4. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](../token_contract.md#burn_public). - We burn the tokens from the `msg_sender()`. Otherwise, a malicious user could burn someone else’s tokens and mint tokens on L1 to themselves. One could add another approval flow on the bridge but that might make it complex for other applications to call the bridge. ## Withdrawing Privately diff --git a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/4_typescript_glue_code.md b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/4_typescript_glue_code.md similarity index 95% rename from docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/4_typescript_glue_code.md rename to docs/docs/tutorials/codealong/contract_tutorials/token_bridge/4_typescript_glue_code.md index 0600dbf1059..5754ce1f0f8 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/4_typescript_glue_code.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/4_typescript_glue_code.md @@ -167,9 +167,9 @@ Note - you might have a jest error at the end of each test saying "expected 1-2 ### Follow a more detailed Aztec.js tutorial -Follow the tutorial [here](../../../aztecjs-getting-started). +Follow the tutorial [here](../../js_tutorials/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/smart_contracts/functions/function_transforms.md) +- [Portals (protocol specs)](../../../../protocol-specs/l1-smart-contracts/index.md#portals) +- [Functions under the hood (concepts)](../../../../aztec/smart_contracts/functions/function_transforms.md) diff --git a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/index.md b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/index.md similarity index 97% rename from docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/index.md rename to docs/docs/tutorials/codealong/contract_tutorials/token_bridge/index.md index 8b3873c5a91..72a0c7061df 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/advanced/token_bridge/index.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/token_bridge/index.md @@ -1,11 +1,11 @@ --- title: Token Bridge -sidebar_position: 2 +sidebar_position: 6 --- 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 page in the protocol specs](../../../../../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 @@ -42,7 +42,7 @@ The goal for this tutorial is to create functionality such that a token can be b This is just a reference implementation for educational purposes only. It has not been through an in-depth security audit. -Let’s assume a token exists on Ethereum and Aztec (see a [the token tutorial](../../token_contract.md)). +Let’s assume a token exists on Ethereum and Aztec (see a [the token tutorial](../token_contract.md)). We will build: diff --git a/docs/docs/tutorials/codealong/contract_tutorials/token_contract.md b/docs/docs/tutorials/codealong/contract_tutorials/token_contract.md index e650379aee4..9b93a6e0e72 100644 --- a/docs/docs/tutorials/codealong/contract_tutorials/token_contract.md +++ b/docs/docs/tutorials/codealong/contract_tutorials/token_contract.md @@ -422,7 +422,7 @@ aztec codegen target -o src/artifacts ### Token Bridge Contract -The [token bridge tutorial](./advanced/token_bridge/index.md) is a great follow up to this one. +The [token bridge tutorial](.//token_bridge/index.md) is a great follow up to this one. It builds on the Token contract described here and goes into more detail about Aztec contract composability and Ethereum (L1) and Aztec (L2) cross-chain messaging. diff --git a/docs/docs/tutorials/codealong/js_tutorials/_category_.json b/docs/docs/tutorials/codealong/js_tutorials/_category_.json new file mode 100644 index 00000000000..79b35ed8528 --- /dev/null +++ b/docs/docs/tutorials/codealong/js_tutorials/_category_.json @@ -0,0 +1,6 @@ +{ + "label": "Dapp Tutorials", + "position": 1, + "collapsible": true, + "collapsed": true +} \ No newline at end of file diff --git a/docs/docs/tutorials/codealong/aztecjs-getting-started.md b/docs/docs/tutorials/codealong/js_tutorials/aztecjs-getting-started.md similarity index 94% rename from docs/docs/tutorials/codealong/aztecjs-getting-started.md rename to docs/docs/tutorials/codealong/js_tutorials/aztecjs-getting-started.md index d4eeae0b976..987348e2173 100644 --- a/docs/docs/tutorials/codealong/aztecjs-getting-started.md +++ b/docs/docs/tutorials/codealong/js_tutorials/aztecjs-getting-started.md @@ -1,13 +1,13 @@ --- title: Transferring Tokens with Aztec.js -sidebar_position: 1 +sidebar_position: 0 --- import Image from "@theme/IdealImage"; In this guide, we will retrieving the Sandbox and deploy a pre-written contract to it using Aztec.js. -This guide assumes you have followed the [quickstart](../../guides/developer_guides/getting_started). +This guide assumes you have followed the [quickstart](../../../guides/getting_started.md). ## Prerequisites @@ -134,7 +134,7 @@ The sandbox is preloaded with multiple accounts so you don't have to sit and cre #include_code load_accounts /yarn-project/end-to-end/src/composed/e2e_sandbox_example.test.ts typescript -An explanation on accounts on Aztec can be found [here](../../aztec/concepts/accounts/index.md). +An explanation on accounts on Aztec can be found [here](../../../aztec/concepts/accounts/index.md). ## Deploy a contract @@ -295,7 +295,7 @@ This function takes: 2. A recipient 3. An amount of tokens to mint -This function starts as private to set up the creation of a [partial note](../../aztec/concepts/storage/partial_notes.md). The private function calls a public function that checks that the minter is authorized to mint new tokens an increments the public total supply. The recipient of the tokens remains private, but the minter and the amount of tokens minted are public. +This function starts as private to set up the creation of a [partial note](../../../aztec/concepts/storage/partial_notes.md). The private function calls a public function that checks that the minter is authorized to mint new tokens an increments the public total supply. The recipient of the tokens remains private, but the minter and the amount of tokens minted are public. Let's now use these functions to mint some tokens to Bob's account using Typescript, add this to `index.ts`: @@ -339,7 +339,7 @@ Our complete output should now be something like: token Bob's balance 10543 +43ms ``` -That's it! We have successfully deployed a token contract to an instance of the Aztec network and mined private state-transitioning transactions. We have also queried the resulting state all via the interfaces provided by the contract. To see exactly what has happened here, you can learn about the transaction flow [on the Concepts page 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 @@ -349,5 +349,5 @@ Follow the [dapp tutorial](./simple_dapp/index.md). ### Optional: Learn more about concepts mentioned here -- [Authentication witness](../../aztec/concepts/accounts/authwit.md) -- [Functions under the hood](../../aztec/smart_contracts/functions/function_transforms.md) +- [Authentication witness](../../../aztec/concepts/accounts/authwit.md) +- [Functions under the hood](../../../aztec/smart_contracts/functions/function_transforms.md) diff --git a/docs/docs/tutorials/codealong/simple_dapp/0_project_setup.md b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/0_project_setup.md similarity index 100% rename from docs/docs/tutorials/codealong/simple_dapp/0_project_setup.md rename to docs/docs/tutorials/codealong/js_tutorials/simple_dapp/0_project_setup.md diff --git a/docs/docs/tutorials/codealong/simple_dapp/1_pxe_service.md b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/1_pxe_service.md similarity index 86% rename from docs/docs/tutorials/codealong/simple_dapp/1_pxe_service.md rename to docs/docs/tutorials/codealong/js_tutorials/simple_dapp/1_pxe_service.md index ba30343f577..727b94d079b 100644 --- a/docs/docs/tutorials/codealong/simple_dapp/1_pxe_service.md +++ b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/1_pxe_service.md @@ -4,7 +4,8 @@ PXE is a component of the Aztec Protocol that provides a private execution envir As an app developer, the PXE interface provides you with access to the user's accounts and their private state, as well as a connection to the network for accessing public global state. -The [Aztec Sandbox](../../../reference/developer_references/sandbox_reference/index.md) runs a local PXE and an Aztec Node, both connected to a local Ethereum development node like Anvil. +The [Aztec Sandbox](.././../../../reference/developer_references/sandbox_reference/sandbox-reference.md) runs a local PXE and an Aztec Node, both connected to a local Ethereum development node like Anvil. + The Sandbox also includes a set of pre-initialized accounts that you can use from your app. In this section, we'll connect to the Sandbox from our project. @@ -20,7 +21,7 @@ Let's create our first file `src/index.mjs` with the following contents: #include_code all yarn-project/end-to-end/src/sample-dapp/connect.mjs javascript -Make sure the [Sandbox is running](../../../guides/developer_guides/getting_started.md) and run the example +Make sure the [Sandbox is running](../../../../guides/getting_started.md) and run the example ```bash node src/index.mjs diff --git a/docs/docs/tutorials/codealong/simple_dapp/2_contract_deployment.md b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/2_contract_deployment.md similarity index 93% rename from docs/docs/tutorials/codealong/simple_dapp/2_contract_deployment.md rename to docs/docs/tutorials/codealong/js_tutorials/simple_dapp/2_contract_deployment.md index 392aacce391..324e3d59d0c 100644 --- a/docs/docs/tutorials/codealong/simple_dapp/2_contract_deployment.md +++ b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/2_contract_deployment.md @@ -3,7 +3,7 @@ To add contracts to your application, we'll start by creating a new `aztec-nargo` project. We'll then compile the contracts, and write a simple script to deploy them to our Sandbox. :::info -Follow the instructions [here](../../../reference/developer_references/sandbox_reference/index.md) to install `aztec-nargo` if you haven't done so already. +Follow the instructions [here](../../../../guides/getting_started.md) to install `aztec-nargo` if you haven't done so already. ::: ## Initialize Aztec project @@ -73,7 +73,7 @@ Here, we are using the `Contract` class with the compiled artifact to send a new Note that the token's `constructor()` method expects an `owner` address to set as the contract `admin`. We are using the first account from the Sandbox for this. :::info -If you are using the generated typescript classes, you can drop the generic `ContractDeployer` in favor of using the `deploy` method of the generated class, which will automatically load the artifact for you and type-check the constructor arguments. See the [How to deploy a contract](../../../guides/developer_guides/smart_contracts/how_to_deploy_contract.md) page for more info. +If you are using the generated typescript classes, you can drop the generic `ContractDeployer` in favor of using the `deploy` method of the generated class, which will automatically load the artifact for you and type-check the constructor arguments. See the [How to deploy a contract](../../../../guides/developer_guides/smart_contracts/how_to_deploy_contract.md) page for more info. ::: Run the snippet above as `node src/deploy.mjs`, and you should see the following output, along with a new `addresses.json` file in your project root: diff --git a/docs/docs/tutorials/codealong/simple_dapp/3_contract_interaction.md b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/3_contract_interaction.md similarity index 91% rename from docs/docs/tutorials/codealong/simple_dapp/3_contract_interaction.md rename to docs/docs/tutorials/codealong/js_tutorials/simple_dapp/3_contract_interaction.md index 769e53d6e00..72583b361af 100644 --- a/docs/docs/tutorials/codealong/simple_dapp/3_contract_interaction.md +++ b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/3_contract_interaction.md @@ -11,7 +11,7 @@ Let's start by showing our user's private balance for the token across their acc #include_code balance_of_private noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust :::info -Note that this function will only return a valid response for accounts registered in the Private eXecution Environment (PXE), since it requires access to the [user's private state](../../../aztec/concepts/wallets/index.md#private-state). In other words, you cannot query the private balance of another user for the token contract. +Note that this function will only return a valid response for accounts registered in the Private eXecution Environment (PXE), since it requires access to the [user's private state](../../../../aztec/concepts/wallets/index.md#private-state). In other words, you cannot query the private balance of another user for the token contract. ::: To do this, let's first initialize a new `Contract` instance using `aztec.js` that represents our deployed token contracts. Create a new `src/contracts.mjs` file with the imports for our artifacts and other dependencies: @@ -99,12 +99,12 @@ At the time of this writing, there are no events emitted when new private notes ## Working with public state -While [private and public state](../../../aztec/concepts/state_model/index.md) are fundamentally different, the API for working with private and public functions and state from `aztec.js` is equivalent. To query the balance in public tokens for our user accounts, we can just call the `balance_of_public` view function in the contract: +While [private and public state](../../../../aztec/concepts/storage/state_model/index.md) are fundamentally different, the API for working with private and public functions and state from `aztec.js` is equivalent. To query the balance in public tokens for our user accounts, we can just call the `balance_of_public` view function in the contract: #include_code showPublicBalances yarn-project/end-to-end/src/sample-dapp/index.mjs javascript :::info -Since this we are working with public balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](../../../aztec/concepts/accounts/keys.md#encryption-keys). +Since this we are working with public balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](../../../../aztec/concepts/accounts/keys.md#encryption-keys). ::: Here, since the token contract does not mint any initial funds upon deployment, the balances for all of our user's accounts will be zero. diff --git a/docs/docs/tutorials/codealong/simple_dapp/4_testing.md b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/4_testing.md similarity index 87% rename from docs/docs/tutorials/codealong/simple_dapp/4_testing.md rename to docs/docs/tutorials/codealong/js_tutorials/simple_dapp/4_testing.md index f7b03eda1c9..d162345d448 100644 --- a/docs/docs/tutorials/codealong/simple_dapp/4_testing.md +++ b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/4_testing.md @@ -14,7 +14,7 @@ Start by installing our test runner, in this case jest: yarn add -D jest ``` -We'll need to [install and run the Sandbox](../../../reference/developer_references/sandbox_reference/sandbox-reference.md). +We'll need to [install and run the Sandbox](../../../../guides/getting_started.md). ## Test setup @@ -69,4 +69,6 @@ yarn node --experimental-vm-modules $(yarn bin jest) --testRegex '.*\.test\.mjs$ ## Next steps -Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](../../../aztec/smart_contracts_overview.md) or read about the [fundamental concepts behind Aztec Network](../../../aztec/overview.md). +Have you written a contract from scratch? If not, follow a tutorial for [writing contracts with Noir](../../contract_tutorials/counter_contract.md) + +Or read about the [fundamental concepts behind Aztec Network](../../../../aztec/concepts_overview.md) and dive deeper into how things work. diff --git a/docs/docs/tutorials/codealong/simple_dapp/index.md b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/index.md similarity index 88% rename from docs/docs/tutorials/codealong/simple_dapp/index.md rename to docs/docs/tutorials/codealong/js_tutorials/simple_dapp/index.md index 26b04daebdc..5457d22e4c5 100644 --- a/docs/docs/tutorials/codealong/simple_dapp/index.md +++ b/docs/docs/tutorials/codealong/js_tutorials/simple_dapp/index.md @@ -1,10 +1,10 @@ --- -title: Dapp Tutorial +title: Node.js app that interacts with contracts --- In this tutorial we'll go through the steps for building a simple application that interacts with the Aztec Sandbox. We'll be building a console application using Javascript and NodeJS, but you may reuse the same concepts here for a web-based app. All Aztec libraries are written in Typescript and fully typed, so you can use Typescript instead of Javascript to make the most out of its type checker. -This tutorial will focus on environment setup, including creating accounts and deployments, as well as interacting with your contracts. It will not cover [how to write contracts in Noir](../../../aztec/smart_contracts_overview.md). +This tutorial will focus on environment setup, including creating accounts and deployments, as well as interacting with your contracts. It will not cover [how to write contracts in Noir](../../../../aztec/smart_contracts_overview.md). The full code for this tutorial is [available on the `aztec-packages` repository](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/end-to-end/src/sample-dapp). @@ -12,7 +12,7 @@ The full code for this tutorial is [available on the `aztec-packages` repository - Linux or OSX environment - [NodeJS](https://nodejs.org/) 18 or higher -- [Aztec Sandbox](../../../guides/developer_guides/getting_started) +- [Aztec Sandbox](../../../guides/getting_started) ## Prerequisites diff --git a/docs/docs/tutorials/examples/uniswap/index.md b/docs/docs/tutorials/examples/uniswap/index.md index c4fc55b539f..d31c03b0418 100644 --- a/docs/docs/tutorials/examples/uniswap/index.md +++ b/docs/docs/tutorials/examples/uniswap/index.md @@ -15,7 +15,7 @@ The flow will be: 2. We create an L2 → L1 message to swap on L1 3. On L1, the user gets their input tokens, consumes the swap message, and executes the swap 4. The user deposits the “output” tokens to the output token portal so it can be deposited into L2 -5. We will assume that token portals and token bridges for the input and output tokens must exist. These are what we built in the [token bridge tutorial](../../codealong/contract_tutorials/advanced/token_bridge/index.md). +5. We will assume that token portals and token bridges for the input and output tokens must exist. These are what we built in the [token bridge tutorial](../../codealong/contract_tutorials/token_bridge/index.md). The execution of swap on L1 should be designed such that any 3rd party can execute the swap on behalf of the user. This helps maintain user privacy by not requiring links between L1 and L2 activity. @@ -27,5 +27,5 @@ This reference will cover: This diagram describes the private flow. -This code works alongside a token portal that you can learn to build [in this codealong tutorial](../../codealong/contract_tutorials/advanced/token_bridge/index.md). +This code works alongside a token portal that you can learn to build [in this codealong tutorial](../../codealong/contract_tutorials/token_bridge/index.md). diff --git a/docs/docs/tutorials/examples/uniswap/l1_contract.md b/docs/docs/tutorials/examples/uniswap/l1_contract.md index 6eb246a7c18..c9b16928ed1 100644 --- a/docs/docs/tutorials/examples/uniswap/l1_contract.md +++ b/docs/docs/tutorials/examples/uniswap/l1_contract.md @@ -3,7 +3,7 @@ title: L1 contracts (EVM) sidebar_position: 2 --- -This page goes over the code in the L1 contract for Uniswap, which works alongside a [token portal (codealong tutorial)](../../codealong/contract_tutorials/advanced/token_bridge/index.md). +This page goes over the code in the L1 contract for Uniswap, which works alongside a [token portal (codealong tutorial)](../../codealong/contract_tutorials/token_bridge/index.md). ## Setup diff --git a/docs/docs/tutorials/examples/uniswap/l2_contract.md b/docs/docs/tutorials/examples/uniswap/l2_contract.md index 9d428e6332b..a3ce0e6de53 100644 --- a/docs/docs/tutorials/examples/uniswap/l2_contract.md +++ b/docs/docs/tutorials/examples/uniswap/l2_contract.md @@ -3,7 +3,7 @@ title: L2 Contracts (Aztec) sidebar_position: 1 --- -This page goes over the code in the L2 contract for Uniswap, which works alongside a [token bridge (codealong tutorial)](../../codealong/contract_tutorials/advanced/token_bridge/index.md). +This page goes over the code in the L2 contract for Uniswap, which works alongside a [token bridge (codealong tutorial)](../../codealong/contract_tutorials/token_bridge/index.md). ## Main.nr @@ -20,7 +20,7 @@ We just need to store the portal address for the token that we want to swap. 2. We fetch the underlying aztec token that needs to be swapped. 3. We transfer the user’s funds to the Uniswap contract. Like with Ethereum, the user must have provided approval to the Uniswap contract to do so. The user must provide the nonce they used in the approval for transfer, so that Uniswap can send it to the token contract, to prove it has appropriate approval. 4. Funds are added to the Uniswap contract. -5. Uniswap must exit the input tokens to L1. For this it has to approve the bridge to burn its tokens on its behalf and then actually exit the funds. We call the [`exit_to_l1_public()` method on the token bridge](../../codealong/contract_tutorials/advanced/token_bridge/index.md). We use the public flow for exiting since we are operating on public state. +5. Uniswap must exit the input tokens to L1. For this it has to approve the bridge to burn its tokens on its behalf and then actually exit the funds. We call the [`exit_to_l1_public()` method on the token bridge](../../codealong/contract_tutorials/token_bridge/index.md). We use the public flow for exiting since we are operating on public state. 6. It is not enough for us to simply emit a message to withdraw the funds. We also need to emit a message to display our swap intention. If we do not do this, there is nothing stopping a third party from calling the Uniswap portal with their own parameters and consuming our message. So the Uniswap portal (on L1) needs to know: diff --git a/docs/docs/tutorials/index.md b/docs/docs/tutorials/index.md deleted file mode 100644 index c6e9362c344..00000000000 --- a/docs/docs/tutorials/index.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -id: index -sidebar_position: 0 -title: Tutorials and Examples ---- - -# Code-Along Tutorials and Examples - -In this section, you will find two things: code-along tutorials and code examples of Aztec applications. - -Tutorials will teach you how to build a full application or smart contract locally. Examples are not intended for you to replicate locally as they have more complex setups, but can be useful for exploring what you can do with Aztec. - -This page includes the most popular tutorials in order of increasing complexity. Explore the sidebar for more! - -## Code-Along Tutorials - -### Beginner: Write your first smart contract - -
- - -

Simple counter contract

- - - Follow this tutorial to build, compile and deploy your first Aztec smart contract - a simple private counter - - -
- - -### Intermediate: Write increasingly more complex contracts - -It is recommended to follow these in order. - -
- - -

Simple private voting contract

- - - Build a contract with hybrid state and calling public functions from private - - - - - -

Crowdfunding contract

- - - A more complex contract that interacts with other contracts - - - - - -

Token contract with hybrid state

- - - A very complex contract for a token that can move across public & private state and be transferred to others - - - - - -

Accounts contract

- - - A simple accounts contract that will teach you about account abstraction in Aztec - - -
- -
- View all smart contract tutorials -
- -## Examples - -
- - -

Interacting with L1 Uniswap from L2 Aztec

- - - An example app inspired by Aztec Connect that allows users to swap publicly & privately on L1 Uniswap from Aztec - - - - - - - - -

Card game contract ↗️

- - - A set of contracts that allow players to take turns playing cards - - -
diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js index 678e9cce230..3c480ffaba6 100644 --- a/docs/docusaurus.config.js +++ b/docs/docusaurus.config.js @@ -223,9 +223,9 @@ const config = { items: [ { type: "doc", - docId: "aztec/overview", + docId: "index", position: "left", - label: "Concepts", + label: "Learn", }, { type: "docSidebar", @@ -233,17 +233,11 @@ const config = { position: "left", label: "Guides", }, - { - type: "docSidebar", - sidebarId: "tutorialsSidebar", - position: "left", - label: "Examples", - }, { type: "docSidebar", sidebarId: "referenceSidebar", position: "left", - label: "References", + label: "Reference", }, { type: "dropdown", @@ -255,6 +249,13 @@ const config = { value: 'GitHub', className: "dropdown-subtitle", }, + { + to: "https://github.com/AztecProtocol/aztec-starter", + label: "Aztec Starter repo", + target: "_blank", + rel: "noopener noreferrer", + className: "github-item", + }, { to: "https://github.com/AztecProtocol/aztec-packages", label: "Aztec Monorepo", @@ -343,7 +344,7 @@ const config = { }, { label: "Developer Getting Started Guide", - to: "/guides/developer_guides/getting_started", + to: "/guides/getting_started", }, { label: "Aztec.nr", diff --git a/docs/netlify.toml b/docs/netlify.toml index bf5475fff6b..3a0097de71b 100644 --- a/docs/netlify.toml +++ b/docs/netlify.toml @@ -8,7 +8,7 @@ [[redirects]] from = "/getting_started" - to = "/guides/developer_guides/getting_started" + to = "/guides/getting_started" [[redirects]] from = "/tutorials/simple_dapp/*" @@ -19,28 +19,28 @@ to = "/tutorials/codealong/simple_dapp" [[redirects]] - from = "/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code" - to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/typescript_glue_code" + from = "/tutorials/contract_tutorials//token_bridge/typescript_glue_code" + to = "/tutorials/codealong/contract_tutorials/token_bridge/typescript_glue_code" [[redirects]] - from = "/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1" - to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/withdrawing_to_l1" + from = "/tutorials/contract_tutorials//token_bridge/withdrawing_to_l1" + to = "/tutorials/codealong/contract_tutorials/token_bridge/withdrawing_to_l1" [[redirects]] - from = "/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec" - to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/minting_on_aztec" + from = "/tutorials/contract_tutorials//token_bridge/minting_on_aztec" + to = "/tutorials/codealong/contract_tutorials/token_bridge/minting_on_aztec" [[redirects]] - from = "/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec" - to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/depositing_to_aztec" + from = "/tutorials/contract_tutorials//token_bridge/depositing_to_aztec" + to = "/tutorials/codealong/contract_tutorials/token_bridge/depositing_to_aztec" [[redirects]] - from = "/tutorials/contract_tutorials/advanced/token_bridge" - to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge" + from = "/tutorials/contract_tutorials//token_bridge" + to = "/tutorials/codealong/contract_tutorials/token_bridge" [[redirects]] - from = "/tutorials/contract_tutorials/advanced/token_bridge/setup" - to = "/tutorials/codealong/contract_tutorials/advanced/token_bridge/setup" + from = "/tutorials/contract_tutorials//token_bridge/setup" + to = "/tutorials/codealong/contract_tutorials/token_bridge/setup" [[redirects]] from = "/tutorials/contract_tutorials/crowdfunding_contract" @@ -64,7 +64,7 @@ [[redirects]] from = "/developers/sandbox/*" - to = "/guides/developer_guides/getting_started" + to = "/guides/getting_started" [[redirects]] from = "/developers/contracts/*" @@ -72,7 +72,7 @@ [[redirects]] from = "/dev_docs/*" - to = "/guides/developer_guides/getting_started" + to = "/guides/getting_started" [[redirects]] from = "/aztec/cryptography/cryptography-roadmap" @@ -136,12 +136,16 @@ [[redirects]] from = "/reference/sandbox_reference/sandbox-reference" - to = "/guides/developer_guides/getting_started" + to = "/guides/getting_started" [[redirects]] from = "/reference/sandbox_reference" - to = "/guides/developer_guides/getting_started" + to = "/guides/getting_started" [[redirects]] - from = "/guides/developer_guides/getting_started/quickstart" - to = "/guides/developer_guides/getting_started" \ No newline at end of file + from = "/guides/getting_started/quickstart" + to = "/guides/getting_started" + +[[redirects]] +from = "/guides/developer_guides/getting_started/quickstart" +to = "/guides/developer_guides/getting_started" \ No newline at end of file diff --git a/docs/sidebars.js b/docs/sidebars.js index f8a9c10e42b..673ca9602fa 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -8,13 +8,13 @@ export default { sidebar: [ { type: "html", - value: 'Aztec Protocol', + value: 'Concepts', className: "sidebar-title", }, { type: "doc", - id: "aztec/overview", - label: "What is Aztec?", + id: "aztec/concepts_overview", + label: "Concepts Overview", }, { type: "category", @@ -68,54 +68,60 @@ export default { guidesSidebar: [ { - type: "doc", - label: "Popular Guides", - id: "guides/index", + type: "doc", + id: "guides/index", + label: "Guides and Tutorials", }, { type: "html", - value: 'Developer Guides', + value: 'Getting Started', className: "sidebar-title", }, { - type: "autogenerated", - dirName: "guides/developer_guides", + type: "doc", + label: "Quickstart", + id: "guides/getting_started" }, { type: "html", value: '', }, { - type: "doc", - label: "Privacy Considerations", - id: "guides/privacy_considerations", + type: "html", + value: 'Code-along Tutorials', + className: "sidebar-title", }, - ], - tutorialsSidebar: [ { - type: "doc", - label: "Tutorials and Examples", - id: "tutorials/index", + type: "autogenerated", + dirName: "tutorials/codealong", }, { type: "html", - value: 'Code-along Tutorials', + value: 'Advanced Examples', className: "sidebar-title", }, { type: "autogenerated", - dirName: "tutorials/codealong", + dirName: "tutorials/examples", + }, + { + type: "html", + value: '', }, { type: "html", - value: 'Examples', + value: 'How-to Guides', className: "sidebar-title", }, { type: "autogenerated", - dirName: "tutorials/examples", + dirName: "guides/developer_guides" }, - ], + { + type: "html", + value: '', + }, + ], referenceSidebar: [ { @@ -132,10 +138,20 @@ export default { type: "autogenerated", dirName: "reference/developer_references", }, + { + type: "html", + value: 'Considerations', + className: "sidebar-title", + }, { type: "doc", id: "migration_notes", }, + { + type: "doc", + label: "Privacy Considerations", + id: "guides/privacy_considerations" + }, { type: "html", value: '', @@ -144,7 +160,7 @@ export default { type: "doc", id: "aztec_connect_sunset", }, - ], + ], roadmapSidebar: [ { diff --git a/docs/static/img/authwit.png b/docs/static/img/authwit.png new file mode 100644 index 00000000000..bf941e6b4e0 Binary files /dev/null and b/docs/static/img/authwit.png differ diff --git a/docs/static/img/authwit2.png b/docs/static/img/authwit2.png new file mode 100644 index 00000000000..80cbf1ad8ee Binary files /dev/null and b/docs/static/img/authwit2.png differ diff --git a/docs/static/img/authwit3.png b/docs/static/img/authwit3.png new file mode 100644 index 00000000000..d6b375565c0 Binary files /dev/null and b/docs/static/img/authwit3.png differ diff --git a/docs/static/img/authwit4.png b/docs/static/img/authwit4.png new file mode 100644 index 00000000000..2cb6f4d14a0 Binary files /dev/null and b/docs/static/img/authwit4.png differ diff --git a/docs/static/img/aztec-high-level.png b/docs/static/img/aztec-high-level.png new file mode 100644 index 00000000000..cb4813f3257 Binary files /dev/null and b/docs/static/img/aztec-high-level.png differ diff --git a/docs/static/img/aztec_high_level_network_architecture.png b/docs/static/img/aztec_high_level_network_architecture.png deleted file mode 100644 index db7401112ff..00000000000 Binary files a/docs/static/img/aztec_high_level_network_architecture.png and /dev/null differ diff --git a/docs/static/img/aztec_high_level_network_architecture.svg b/docs/static/img/aztec_high_level_network_architecture.svg deleted file mode 100644 index 12998f66e10..00000000000 --- a/docs/static/img/aztec_high_level_network_architecture.svg +++ /dev/null @@ -1,21 +0,0 @@ - - - - - - - - Aztec NetworkPrivate Execution Environment (PXE)UserAztec.jsACIR SimulatorAztec NodeSequencerEthereumRollup ContractProver NetworkProverProverProverProverDatabasePrivate Kernel CircuitPrivate Execution (Client-side)Public Execution (Network-side) \ No newline at end of file diff --git a/docs/static/img/context/sender_context_change.png b/docs/static/img/context/sender_context_change.png index 5f36f91c488..e0ec94fa1ee 100644 Binary files a/docs/static/img/context/sender_context_change.png and b/docs/static/img/context/sender_context_change.png differ diff --git a/docs/static/img/how-does-aztec-work.webp b/docs/static/img/how-does-aztec-work.webp deleted file mode 100644 index 011378fee2d..00000000000 Binary files a/docs/static/img/how-does-aztec-work.webp and /dev/null differ diff --git a/docs/static/img/public-and-private-state-diagram.png b/docs/static/img/public-and-private-state-diagram.png new file mode 100644 index 00000000000..cb1f6ef5349 Binary files /dev/null and b/docs/static/img/public-and-private-state-diagram.png differ diff --git a/docs/static/img/pxe.png b/docs/static/img/pxe.png new file mode 100644 index 00000000000..2d34ebae78f Binary files /dev/null and b/docs/static/img/pxe.png differ diff --git a/docs/static/img/transaction-lifecycle.png b/docs/static/img/transaction-lifecycle.png index c92950d71d2..96852449fcc 100644 Binary files a/docs/static/img/transaction-lifecycle.png and b/docs/static/img/transaction-lifecycle.png differ diff --git a/noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr b/noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr index 4aa3759433a..219e8c8dd55 100644 --- a/noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr +++ b/noir-projects/noir-contracts/contracts/escrow_contract/src/main.nr @@ -43,7 +43,8 @@ contract Escrow { let note = storage.owner.get_note(); assert(note.address == sender); - + // docs:start:call_function Token::at(token).transfer(recipient, amount).call(&mut context); + // docs:end:call_function } } diff --git a/noir-projects/noir-contracts/contracts/lending_contract/src/main.nr b/noir-projects/noir-contracts/contracts/lending_contract/src/main.nr index b5781af3b20..d9d965cea05 100644 --- a/noir-projects/noir-contracts/contracts/lending_contract/src/main.nr +++ b/noir-projects/noir-contracts/contracts/lending_contract/src/main.nr @@ -128,9 +128,11 @@ contract Lending { on_behalf_of: Field, collateral_asset: AztecAddress, ) { + // docs:start:public_to_public_call let _ = Token::at(collateral_asset) .transfer_in_public(context.msg_sender(), context.this_address(), amount, nonce) .call(&mut context); + // docs:end:public_to_public_call let _ = Lending::at(context.this_address()) ._deposit(AztecAddress::from_field(on_behalf_of), amount, collateral_asset) .call(&mut context);