diff --git a/docs/.gitignore b/docs/.gitignore index 54162e3dbc6..07d9321798d 100644 --- a/docs/.gitignore +++ b/docs/.gitignore @@ -22,6 +22,5 @@ npm-debug.log* yarn-debug.log* yarn-error.log* -docs/reference/reference/smart_contract_reference/aztec-nr - -/src/preprocess/AztecnrReferenceAutogenStructure.json +docs/reference/aztecjs +docs/reference/smart_contract_reference/aztec-nr diff --git a/docs/docs/.gitignore b/docs/docs/.gitignore deleted file mode 100644 index 6fa7731468d..00000000000 --- a/docs/docs/.gitignore +++ /dev/null @@ -1 +0,0 @@ -/apis diff --git a/docs/docs/aztec/aztec/index.md b/docs/docs/aztec.md similarity index 94% rename from docs/docs/aztec/aztec/index.md rename to docs/docs/aztec.md index d679f1955e0..dec4840f9de 100644 --- a/docs/docs/aztec/aztec/index.md +++ b/docs/docs/aztec.md @@ -3,7 +3,7 @@ title: Aztec sidebar_position: 0 --- -import Disclaimer from "../../../src/components/Disclaimers/\_wip_disclaimer.mdx"; +import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx"; import ReactPlayer from "react-player/youtube"; Aztec is an L2 that brings programmable privacy to Ethereum. @@ -52,7 +52,7 @@ Contributors to Aztec uphold many of the values of the Ethereum community -- bui Noir is a domain specific programming language for writing zero-knowledge circuits. On Aztec a smart contract is a collection of circuits that developers write using Noir. -You can find more information and resources for learning about Noir smart contracts on [this page](/aztec/aztec/concepts/smart_contracts/index.md). +You can find more information and resources for learning about Noir smart contracts on [this page](/aztec/concepts/smart_contracts/index.md). ## Cryptography diff --git a/docs/docs/aztec/_category_.json b/docs/docs/aztec/_category_.json index 5313372a176..336394a563a 100644 --- a/docs/docs/aztec/_category_.json +++ b/docs/docs/aztec/_category_.json @@ -1,6 +1,6 @@ { + "label": "Aztec", "position": 0, "collapsible": true, - "collapsed": true, - "label": "Aztec" + "collapsed": true } diff --git a/docs/docs/aztec/aztec/_category_.json b/docs/docs/aztec/aztec/_category_.json deleted file mode 100644 index 336394a563a..00000000000 --- a/docs/docs/aztec/aztec/_category_.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "label": "Aztec", - "position": 0, - "collapsible": true, - "collapsed": true -} diff --git a/docs/docs/aztec/aztec/concepts/_category_.json b/docs/docs/aztec/concepts/_category_.json similarity index 100% rename from docs/docs/aztec/aztec/concepts/_category_.json rename to docs/docs/aztec/concepts/_category_.json diff --git a/docs/docs/aztec/aztec/concepts/accounts/authwit.md b/docs/docs/aztec/concepts/accounts/authwit.md similarity index 94% rename from docs/docs/aztec/aztec/concepts/accounts/authwit.md rename to docs/docs/aztec/concepts/accounts/authwit.md index 5b4388b5ef7..f4ad3ea825c 100644 --- a/docs/docs/aztec/aztec/concepts/accounts/authwit.md +++ b/docs/docs/aztec/concepts/accounts/authwit.md @@ -54,9 +54,9 @@ 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](/aztec/aztec/concepts/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](/aztec/concepts/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](/aztec/aztec/concepts/accounts/keys.md). +If we were to implement the `approve` with an allowance in private, you might know the allowance, but unless you also know about the individual notes that make up the user's balances, it would be of no use to you! It is private after all. To spend the user's funds you would need to know the decryption key, see [keys for more](/aztec/concepts/accounts/keys.md). While this might sound limiting in what we can actually do, the main use of approvals have been for simplifying contract interactions that the user is doing. In the case of private transactions, this is executed on the user device, so it is not a blocker that the user need to tell the executor a secret - the user is the executor! ### So what can we do? @@ -178,7 +178,7 @@ For the transfer, this could be done simply by appending a nonce to the argument action = H(defi, token, transfer_selector, H(alice_account, defi, 1000, nonce)); ``` -Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this which we will see in the [developer documentation](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md). +Beware that the account contract will be unable to emit the nullifier since it is checked with a static call, so the calling contract must do it. This is similar to nonces in ERC20 tokens today. We provide a small library that handles this which we will see in the [developer documentation](guides/smart_contracts/writing_contracts/common_patterns/authwit.md). ### Differences to approval @@ -192,4 +192,4 @@ We don't need to limit ourselves to the `transfer` function, we can use the same ### Next Steps -Check out the [developer documentation](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md) to see how to implement this in your own contracts. +Check out the [developer documentation](guides/smart_contracts/writing_contracts/common_patterns/authwit.md) to see how to implement this in your own contracts. diff --git a/docs/docs/aztec/aztec/concepts/accounts/index.md b/docs/docs/aztec/concepts/accounts/index.md similarity index 98% rename from docs/docs/aztec/aztec/concepts/accounts/index.md rename to docs/docs/aztec/concepts/accounts/index.md index e9add04a564..5d396c9fd92 100644 --- a/docs/docs/aztec/aztec/concepts/accounts/index.md +++ b/docs/docs/aztec/concepts/accounts/index.md @@ -71,7 +71,7 @@ def entryPoint(payload): enqueueCall(to, data, value, gasLimit); ``` -Read more about how to write an account contract [here](/tutorials/tutorials/write_accounts_contract.md). +Read more about how to write an account contract [here](/tutorials/write_accounts_contract.md). ### Account contracts and wallets @@ -134,7 +134,7 @@ These two patterns combined allow an account contract to answer whether an actio Aztec requires users to define [encryption and nullifying keys](./keys.md) that are needed for receiving and spending private notes. Unlike transaction signing, encryption and nullifying is enshrined at the protocol. This means that there is a single scheme used for encryption and nullifying. These keys are derived from a master public key. This master public key, in turn, is used when deterministically deriving the account's address. -A side effect of committing to a master public key as part of the address is that _this key cannot be rotated_. While an account contract implementation could include methods for rotating the signing key, this is unfortunately not possible for encryption and nullifying keys (note that rotating nullifying keys also creates other challenges such as preventing double spends). We are exploring usage of [`SharedMutable`](/reference/reference/smart_contract_reference/storage/shared_state.md#sharedmutable) to enable rotating these keys. +A side effect of committing to a master public key as part of the address is that _this key cannot be rotated_. While an account contract implementation could include methods for rotating the signing key, this is unfortunately not possible for encryption and nullifying keys (note that rotating nullifying keys also creates other challenges such as preventing double spends). We are exploring usage of [`SharedMutable`](/reference/smart_contract_reference/storage/shared_state.md#sharedmutable) to enable rotating these keys. NOTE: While we entertained the idea of abstracting note encryption, where account contracts would define an `encrypt` method that would use a user-defined scheme, there are two main reasons we decided against this. First is that this entailed that, in order to receive funds, a user had to first deploy their account contract, which is a major UX issue. Second, users could define malicious `encrypt` methods that failed in certain circumstances, breaking application flows that required them to receive a private note. While this issue already exists in Ethereum when transferring ETH (see the [king of the hill](https://coinsbench.com/27-king-ethernaut-da5021cd4aa6)), its impact is made worse in Aztec since any execution failure in a private function makes the entire transaction unprovable (ie it is not possible to catch errors in calls to other private functions), and furthermore because encryption is required for any private state (not just for transferring ETH). Nevertheless, both of these problems are solvable. Initialization can be worked around by embedding a commitment to the bytecode in the address and removing the need for actually deploying contracts before interacting with them, and the king of the hill issue can be mitigated by introducing a full private VM that allows catching reverts. As such, we may be able to abstract encryption in the future as well. diff --git a/docs/docs/aztec/aztec/concepts/accounts/keys.md b/docs/docs/aztec/concepts/accounts/keys.md similarity index 94% rename from docs/docs/aztec/aztec/concepts/accounts/keys.md rename to docs/docs/aztec/concepts/accounts/keys.md index a0cc247d1b4..dd9caace655 100644 --- a/docs/docs/aztec/aztec/concepts/accounts/keys.md +++ b/docs/docs/aztec/concepts/accounts/keys.md @@ -20,7 +20,7 @@ Instead it's up to the account contract developer to implement it. ::: ## Public keys retrieval -The keys can either be retrieved from a key registry contract or from the [Private eXecution Environment (PXE)](/aztec/aztec/concepts/pxe/index.md). +The keys can either be retrieved from a key registry contract or from the [Private eXecution Environment (PXE)](/aztec/concepts/pxe/index.md). :::note The key registry is a canonical contract used to store user public keys. @@ -40,7 +40,7 @@ Below are some ways how we could instantiate it after getting the information in #include_code instantiate-complete-address /yarn-project/circuits.js/src/structs/complete_address.test.ts rust -Then to register the recipient's [complete address](#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](/aztec/aztec/core_components.md#aztecjs): +Then to register the recipient's [complete address](#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](/aztec/core_components.md#aztecjs): #include_code register-recipient /yarn-project/aztec.js/src/wallet/create_recipient.ts rust @@ -116,7 +116,7 @@ This is a snippet of our Schnorr Account contract implementation, which uses Sch #include_code entrypoint /noir-projects/noir-contracts/contracts/schnorr_account_contract/src/main.nr rust -Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](/tutorials/tutorials/write_accounts_contract.md) for a full example of how to manage authentication. +Still, different accounts may use different signing schemes, may require multi-factor authentication, or _may not even use signing keys_ and instead rely on other authentication mechanisms. Read [how to write an account contract](/tutorials/write_accounts_contract.md) for a full example of how to manage authentication. Furthermore, and since signatures are fully abstracted, how the key is stored in the contract is abstracted as well and left to the developer of the account contract. In the following section we describe a few ways how an account contract could be architected to store signing keys. @@ -133,7 +133,7 @@ Similar to using a private note, but using an immutable private note removes the #### Using shared state -A compromise between the two solutions above is to use [shared state](/reference/reference/smart_contract_reference/storage/shared_state.md). This would not generate additional nullifiers and commitments for each transaction while allowing the user to rotate their key. However, this causes every transaction to now have a time-to-live determined by the frequency of the mutable shared state, as well as imposing restrictions on how fast keys can be rotated due to minimum delays. +A compromise between the two solutions above is to use [shared state](/reference/smart_contract_reference/storage/shared_state.md). This would not generate additional nullifiers and commitments for each transaction while allowing the user to rotate their key. However, this causes every transaction to now have a time-to-live determined by the frequency of the mutable shared state, as well as imposing restrictions on how fast keys can be rotated due to minimum delays. #### Reusing some of the in-protocol keys diff --git a/docs/docs/aztec/aztec/concepts/circuits/index.md b/docs/docs/aztec/concepts/circuits/index.md similarity index 92% rename from docs/docs/aztec/aztec/concepts/circuits/index.md rename to docs/docs/aztec/concepts/circuits/index.md index 108a6555a3c..e05e10c8937 100644 --- a/docs/docs/aztec/aztec/concepts/circuits/index.md +++ b/docs/docs/aztec/concepts/circuits/index.md @@ -52,7 +52,7 @@ In other words, since neither the EVM nor other rollups have rules for how to pr What kind of extra rules / checks does a rollup need, to enforce notions of private states and private functions? Stuff like: -- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [trees](/aztec/aztec/concepts/storage/trees/index.md)). +- "Perform state reads and writes using new tree structures which prevent tx linkability" (see [trees](/aztec/concepts/storage/trees/index.md)). - "Hide which function was just executed, by wrapping it in a zk-snark" - "Hide all functions which were executed as part of this tx's stack trace, by wrapping the whole tx in a zk-snark" @@ -62,12 +62,12 @@ So what kinds of core protocol circuits does Aztec have? ### Kernel Circuits -- [Private Kernel Circuit](/aztec/aztec/concepts/circuits/kernels/private_kernel) -- [Public Kernel Circuit](/aztec/aztec/concepts/circuits/kernels/public_kernel) +- [Private Kernel Circuit](/aztec/concepts/circuits/kernels/private_kernel) +- [Public Kernel Circuit](/aztec/concepts/circuits/kernels/public_kernel) ### Rollup Circuits -- [Rollup Circuits](/aztec/aztec/concepts/circuits/rollup_circuits) +- [Rollup Circuits](/aztec/concepts/circuits/rollup_circuits) #### Squisher Circuits diff --git a/docs/docs/aztec/aztec/concepts/circuits/kernels/private_kernel.md b/docs/docs/aztec/concepts/circuits/kernels/private_kernel.md similarity index 92% rename from docs/docs/aztec/aztec/concepts/circuits/kernels/private_kernel.md rename to docs/docs/aztec/concepts/circuits/kernels/private_kernel.md index 29850ae496c..3b9f66bc016 100644 --- a/docs/docs/aztec/aztec/concepts/circuits/kernels/private_kernel.md +++ b/docs/docs/aztec/concepts/circuits/kernels/private_kernel.md @@ -16,10 +16,10 @@ This circuit is executed by the user, on their own device. This is to ensure pri - public call stacks: hashes representing calls to other public functions; - events; - all data accumulated by all previous private kernel circuit recursions of this tx; -- Hides which private function has been executed, by performing a zero-knowledge proof of membership against the [contract tree](/aztec/aztec/concepts/storage/trees/index.md#contract-tree). +- Hides which private function has been executed, by performing a zero-knowledge proof of membership against the [contract tree](/aztec/concepts/storage/trees/index.md#contract-tree). - Ensures the entire stack trace of private functions (for a particular tx) adheres to function execution rules. - Verifies a previous 'Private Kernel Proof', recursively, when verifying transactions which are composed of many private function calls. -- Optionally can [deploy](/aztec/aztec/concepts/smart_contracts/contract_creation.md) a new private contract. +- Optionally can [deploy](/aztec/concepts/smart_contracts/contract_creation.md) a new private contract. > Note: **This is the only core protocol circuit which actually needs to be "zk" (zero-knowledge)!!!** That's because this is the only core protocol circuit which handles private data, and hence the only circuit for which proofs must not leak any information about witnesses! (The private data being handled includes: details of the Aztec.nr Contract function which has been executed; the address of the user who executed the function; the intelligible inputs and outputs of that function). > This is a really interesting point. Most so-called "zk-Rollups" do not make use of this "zero-knowledge" property. Their snarks are "snarks"; with no need for zero-knowledge, because they don't seek privacy; they only seek the 'succinct' computation-compression properties of snarks. Aztec's "zk-Rollup" actually makes use of "zero-knowledge" snarks. That's why we sometimes call it a "zk-zk-Rollup", or "_actual_ zk-Rollup". diff --git a/docs/docs/aztec/aztec/concepts/circuits/kernels/public_kernel.md b/docs/docs/aztec/concepts/circuits/kernels/public_kernel.md similarity index 80% rename from docs/docs/aztec/aztec/concepts/circuits/kernels/public_kernel.md rename to docs/docs/aztec/concepts/circuits/kernels/public_kernel.md index 90a331cab77..ba078f1cb81 100644 --- a/docs/docs/aztec/aztec/concepts/circuits/kernels/public_kernel.md +++ b/docs/docs/aztec/concepts/circuits/kernels/public_kernel.md @@ -2,7 +2,7 @@ title: Public Kernel Circuit --- -This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](/aztec/aztec/concepts/storage/trees/index.md#public-state-tree) at any time. A Sequencer might choose to delegate proof generation to the Prover pool. +This circuit is executed by a Sequencer, since only a Sequencer knows the current state of the [public data tree](/aztec/concepts/storage/trees/index.md#public-state-tree) at any time. A Sequencer might choose to delegate proof generation to the Prover pool. - Exposes (forwards) the following data to the next recursive circuit: - all data accumulated by all previous private kernel circuit recursions of this tx; diff --git a/docs/docs/aztec/aztec/concepts/circuits/rollup_circuits/index.md b/docs/docs/aztec/concepts/circuits/rollup_circuits/index.md similarity index 95% rename from docs/docs/aztec/aztec/concepts/circuits/rollup_circuits/index.md rename to docs/docs/aztec/concepts/circuits/rollup_circuits/index.md index cec6a6ce30c..7190f858400 100644 --- a/docs/docs/aztec/aztec/concepts/circuits/rollup_circuits/index.md +++ b/docs/docs/aztec/concepts/circuits/rollup_circuits/index.md @@ -23,7 +23,7 @@ For both transactions, it: - Performs public state read membership checks. - Updates the public data tree in line with the requested state transitions. -- Checks that the nullifiers haven't previously been inserted into the [indexed nullifier tree](/aztec/aztec/concepts/storage/trees/indexed_merkle_tree.mdx#primer-on-nullifier-trees). +- Checks that the nullifiers haven't previously been inserted into the [indexed nullifier tree](/aztec/concepts/storage/trees/indexed_merkle_tree.mdx#primer-on-nullifier-trees). - Batch-inserts new nullifiers into the nullifier tree. - Batch-inserts new note hashes into the note hash tree - Batch-inserts any new contract deployments into the contract tree. diff --git a/docs/docs/aztec/aztec/concepts/index.md b/docs/docs/aztec/concepts/index.md similarity index 59% rename from docs/docs/aztec/aztec/concepts/index.md rename to docs/docs/aztec/concepts/index.md index dd91d9b5243..88bbd6efa57 100644 --- a/docs/docs/aztec/aztec/concepts/index.md +++ b/docs/docs/aztec/concepts/index.md @@ -25,11 +25,11 @@ The PXE is unaware of the Public VM. And the Public VM is unaware of the PXE. Th ### 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](/aztec/aztec/concepts/storage/trees/index.md#note-hash-tree), and a nullifier is created when notes are invalidated. Nullifiers are then stored in their own [nullifier tree](/aztec/aztec/concepts/storage/trees/indexed_merkle_tree.mdx#primer-on-nullifier-trees). +Private state works with UTXOs, or what we call notes. To keep things private, everything is stored in an [append-only UTXO tree](/aztec/concepts/storage/trees/index.md#note-hash-tree), and a nullifier is created when notes are invalidated. Nullifiers are then stored in their own [nullifier tree](/aztec/concepts/storage/trees/indexed_merkle_tree.mdx#primer-on-nullifier-trees). -Public state works similarly to other chains like Ethereum, behaving like a public ledger. Public data is stored in a [public data tree](/aztec/aztec/concepts/storage/trees/index.md#public-state-tree). +Public state works similarly to other chains like Ethereum, behaving like a public ledger. Public data is stored in a [public data tree](/aztec/concepts/storage/trees/index.md#public-state-tree). -Aztec [smart contract](/aztec/aztec/concepts/smart_contracts/index.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. +Aztec [smart contract](/aztec/concepts/smart_contracts/index.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. ## Accounts @@ -37,11 +37,11 @@ Every account in Aztec is a smart contract (account abstraction). This allows im 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. -Learn more about account contracts [here](/aztec/aztec/concepts/index.md). +Learn more about account contracts [here](/aztec/concepts/index.md). ## Smart contracts -Developers can write [smart contracts](/aztec/aztec/concepts/smart_contracts/index.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. +Developers can write [smart contracts](/aztec/concepts/smart_contracts/index.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. Noir has its own doc site that you can find [here](https://noir-lang.org). @@ -52,14 +52,13 @@ Aztec allows private communications with Ethereum - ie no-one knows where the tr 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. Learn more about portals [here](/protocol-specs/l1-smart-contracts/index.md). - ## Circuits Aztec operates on three types of circuits: -- [Private kernel circuits](/aztec/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](./circuits/kernels/public_kernel.md), which are executed by the [sequencer](/aztec/aztec/concepts/nodes_clients/sequencer) and ensure the stack trace of transactions adheres to function execution rules -- [Rollup circuits](/aztec/aztec/concepts/circuits), which bundle all of the Aztec transactions into a proof that can be efficiently verified on Ethereum +- [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](./circuits/kernels/public_kernel.md), which are executed by the [sequencer](/aztec/concepts/nodes_clients/sequencer) and ensure the stack trace of transactions adheres to function execution rules +- [Rollup circuits](/aztec/concepts/circuits), which bundle all of the Aztec transactions into a proof that can be efficiently verified on Ethereum ## What's next? @@ -71,4 +70,4 @@ Explore the Concepts for a deeper understanding into the components that make up ### Start coding -Follow the [developer getting started guide](/getting_started/getting_started). +Follow the [developer getting started guide](/getting_started). diff --git a/docs/docs/aztec/aztec/concepts/nodes_clients/_category_.json b/docs/docs/aztec/concepts/nodes_clients/_category_.json similarity index 100% rename from docs/docs/aztec/aztec/concepts/nodes_clients/_category_.json rename to docs/docs/aztec/concepts/nodes_clients/_category_.json diff --git a/docs/docs/aztec/aztec/concepts/nodes_clients/sequencer/index.md b/docs/docs/aztec/concepts/nodes_clients/sequencer/index.md similarity index 97% rename from docs/docs/aztec/aztec/concepts/nodes_clients/sequencer/index.md rename to docs/docs/aztec/concepts/nodes_clients/sequencer/index.md index 35cded457bd..afaf726f022 100644 --- a/docs/docs/aztec/aztec/concepts/nodes_clients/sequencer/index.md +++ b/docs/docs/aztec/concepts/nodes_clients/sequencer/index.md @@ -40,4 +40,4 @@ You can view the current implementation on Github [here](https://github.com/Azte ## Further Reading -- [Sequencer Selection](/aztec/aztec/concepts/nodes_clients/sequencer/sequencer_selection.md) +- [Sequencer Selection](/aztec/concepts/nodes_clients/sequencer/sequencer_selection.md) diff --git a/docs/docs/aztec/aztec/concepts/nodes_clients/sequencer/sequencer_selection.md b/docs/docs/aztec/concepts/nodes_clients/sequencer/sequencer_selection.md similarity index 100% rename from docs/docs/aztec/aztec/concepts/nodes_clients/sequencer/sequencer_selection.md rename to docs/docs/aztec/concepts/nodes_clients/sequencer/sequencer_selection.md diff --git a/docs/docs/aztec/aztec/concepts/pxe/acir_simulator.md b/docs/docs/aztec/concepts/pxe/acir_simulator.md similarity index 88% rename from docs/docs/aztec/aztec/concepts/pxe/acir_simulator.md rename to docs/docs/aztec/concepts/pxe/acir_simulator.md index 9fc4039b9c3..5ee55027368 100644 --- a/docs/docs/aztec/aztec/concepts/pxe/acir_simulator.md +++ b/docs/docs/aztec/concepts/pxe/acir_simulator.md @@ -14,13 +14,13 @@ It simulates three types of functions: Private functions are simulated and proved client-side, and verified client-side in the private kernel circuit. -They are run with the assistance of a DB oracle that provides any private data requested by the function. You can read more about oracle functions in the smart contract section [here](/aztec/aztec/concepts/smart_contracts/oracles/index.md). +They are run with the assistance of a DB oracle that provides any private data requested by the function. You can read more about oracle functions in the smart contract section [here](/aztec/concepts/smart_contracts/oracles/index.md). Private functions can call other private functions and can request to call a public function. The public function execution will be performed by the sequencer asynchronously, so private functions don't have direct access to the return values of public functions. ### Public Functions -Public functions are simulated and proved on the [sequencer](/aztec/aztec/concepts/nodes_clients/sequencer) side, and verified by the [public kernel circuit](../circuits/kernels/public_kernel.md). +Public functions are simulated and proved on the [sequencer](/aztec/concepts/nodes_clients/sequencer) side, and verified by the [public kernel circuit](../circuits/kernels/public_kernel.md). They are run with the assistance of an oracle that provides any value read from the public state tree. diff --git a/docs/docs/aztec/aztec/concepts/pxe/index.md b/docs/docs/aztec/concepts/pxe/index.md similarity index 93% rename from docs/docs/aztec/aztec/concepts/pxe/index.md rename to docs/docs/aztec/concepts/pxe/index.md index 9ae9f319451..3185229b7b2 100644 --- a/docs/docs/aztec/aztec/concepts/pxe/index.md +++ b/docs/docs/aztec/concepts/pxe/index.md @@ -63,9 +63,9 @@ The keystore is a secure storage for private and public keys. ## Oracles -Oracles are pieces of data that are injected into a smart contract function from the client side. You can read more about why and how they work in the [functions section](/aztec/aztec/concepts/smart_contracts/oracles/index.md). +Oracles are pieces of data that are injected into a smart contract function from the client side. You can read more about why and how they work in the [functions section](/aztec/concepts/smart_contracts/oracles/index.md). ## For developers To learn how to develop on top of the PXE, refer to these guides: -* [Run more than one PXE on your local machine](/aztec/aztec/concepts/pxe/index.md) -* [Use in-built oracles including oracles for arbitrary data](guides/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md) +* [Run more than one PXE on your local machine](/aztec/concepts/pxe/index.md) +* [Use in-built oracles including oracles for arbitrary data](guides/smart_contracts/writing_contracts/how_to_pop_capsules.md) diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/communication/index.md b/docs/docs/aztec/concepts/smart_contracts/communication/index.md similarity index 78% rename from docs/docs/aztec/aztec/concepts/smart_contracts/communication/index.md rename to docs/docs/aztec/concepts/smart_contracts/communication/index.md index 4172cdea96d..2a6b7a8edf5 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/communication/index.md +++ b/docs/docs/aztec/concepts/smart_contracts/communication/index.md @@ -9,4 +9,4 @@ See [Private \<--\> Public execution](./public_private_calls.md) for information ## Cross-chain communication -Read the protocol specification about Cross-chain communication between Aztec and Ethereum [here](../../../../../protocol-specs/l1-smart-contracts/index.md). +Read the protocol specification about Cross-chain communication between Aztec and Ethereum [here](/protocol-specs/l1-smart-contracts/index.md). diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md b/docs/docs/aztec/concepts/smart_contracts/communication/public_private_calls.md similarity index 93% rename from docs/docs/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md rename to docs/docs/aztec/concepts/smart_contracts/communication/public_private_calls.md index 04e32af8c91..09f2449bec0 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md +++ b/docs/docs/aztec/concepts/smart_contracts/communication/public_private_calls.md @@ -4,7 +4,7 @@ title: Private <> Public Communication import Image from "@theme/IdealImage"; -import Disclaimer from "../../../../../../src/components/Disclaimers/\_wip_disclaimer.mdx"; +import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx"; @@ -84,6 +84,6 @@ Many applications rely on some form of access control to function well. USDC hav Access control like this cannot easily be enforced in the private domain, as reading is also nullifying (to ensure data is up to date). However, as it is possible to read historical public state, one can combine private and public functions to get the desired effect. -This concept is known as [shared state](/reference/reference/smart_contract_reference/storage/shared_state.md), and relies on using delays when changing public data so that it can also be read in private with currentness guarantees. Since values cannot be immediately modified but instead require delays to elapse, it is possible to privately prove that an application is using the current value _as long as the transaction gets included before some time in the future_, which would be the earliest the value could possibly change. +This concept is known as [shared state](/reference/smart_contract_reference/storage/shared_state.md), and relies on using delays when changing public data so that it can also be read in private with currentness guarantees. Since values cannot be immediately modified but instead require delays to elapse, it is possible to privately prove that an application is using the current value _as long as the transaction gets included before some time in the future_, which would be the earliest the value could possibly change. If the public state is only changed infrequently, and it is acceptable to have delays when doing so, then shared state is a good solution to this problem. diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/contract_creation.md b/docs/docs/aztec/concepts/smart_contracts/contract_creation.md similarity index 82% rename from docs/docs/aztec/aztec/concepts/smart_contracts/contract_creation.md rename to docs/docs/aztec/concepts/smart_contracts/contract_creation.md index f6944dbd053..1400657f8cd 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/contract_creation.md +++ b/docs/docs/aztec/concepts/smart_contracts/contract_creation.md @@ -6,4 +6,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/tutorials/simple_dapp). +To see how to deploy a contract in practice, check out the [dapp development tutorial](/tutorials/simple_dapp). diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/contract_structure.md b/docs/docs/aztec/concepts/smart_contracts/contract_structure.md similarity index 65% rename from docs/docs/aztec/aztec/concepts/smart_contracts/contract_structure.md rename to docs/docs/aztec/concepts/smart_contracts/contract_structure.md index f8e024d740d..ac8a21048a5 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/contract_structure.md +++ b/docs/docs/aztec/concepts/smart_contracts/contract_structure.md @@ -2,7 +2,7 @@ title: Structure of a contract --- -A contract is a collection of persistent [state variables](/aztec/aztec/concepts/storage/index.md), and [functions](/aztec/aztec/concepts/smart_contracts/functions) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called. +A contract is a collection of persistent [state variables](/aztec/concepts/storage/index.md), and [functions](/aztec/concepts/smart_contracts/functions) 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 @@ -35,4 +35,4 @@ Here's a common layout for a basic Aztec.nr Contract project: ``` - See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages). -- You can review the structure of a complete contract in the token contract tutorial [here](/tutorials/tutorials/contract_tutorials/token_contract.md). +- You can review the structure of a complete contract in the token contract tutorial [here](/tutorials/contract_tutorials/token_contract.md). diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/context.md b/docs/docs/aztec/concepts/smart_contracts/functions/context.md similarity index 94% rename from docs/docs/aztec/aztec/concepts/smart_contracts/functions/context.md rename to docs/docs/aztec/concepts/smart_contracts/functions/context.md index a2d44f40d80..5bd2f4526b3 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/context.md +++ b/docs/docs/aztec/concepts/smart_contracts/functions/context.md @@ -4,7 +4,7 @@ title: Understanding Function Context ## What is the context -The context is an object that is made available within every function in `Aztec.nr`. As mentioned in the [kernel circuit documentation](/aztec/aztec/concepts/circuits/kernels/private_kernel.md). At the beginning of a function's execution, the context contains all of the kernel information that application needs to execute. During the lifecycle of a transaction, the function will update the context with each of it's side effects (created notes, nullifiers etc.). At the end of a function's execution the mutated context is returned to the kernel to be checked for validity. +The context is an object that is made available within every function in `Aztec.nr`. As mentioned in the [kernel circuit documentation](/aztec/concepts/circuits/kernels/private_kernel.md). At the beginning of a function's execution, the context contains all of the kernel information that application needs to execute. During the lifecycle of a transaction, the function will update the context with each of it's side effects (created notes, nullifiers etc.). At the end of a function's execution the mutated context is returned to the kernel to be checked for validity. Behind the scenes, Aztec.nr will pass data the kernel needs to and from a circuit, this is abstracted away from the developer. In an developer's eyes; the context is a useful structure that allows access and mutate the state of the `Aztec` blockchain. @@ -18,7 +18,7 @@ On this page, you'll learn ## Two contexts, one API -The `Aztec` blockchain contains two environments [public and private](/aztec/aztec/concepts/state_model/index.md). +The `Aztec` blockchain contains two environments [public and private](/aztec/concepts/state_model/index.md). - Private, for private transactions taking place on user's devices. - Public, for public transactions taking place on the network's sequencers. diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/index.md b/docs/docs/aztec/concepts/smart_contracts/functions/index.md similarity index 72% rename from docs/docs/aztec/aztec/concepts/smart_contracts/functions/index.md rename to docs/docs/aztec/concepts/smart_contracts/functions/index.md index cb3021e0c71..0593873c757 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/index.md +++ b/docs/docs/aztec/concepts/smart_contracts/functions/index.md @@ -2,9 +2,9 @@ title: Defining Functions --- -Functions serve as the building blocks of smart contracts. Functions can be either **public**, ie they are publicly available for anyone to see and can directly interact with public state, or **private**, meaning they are executed completely client-side in the [PXE](/aztec/aztec/concepts/pxe/index.md). Read more about how private functions work [here](./inner_workings.md#private-functions). +Functions serve as the building blocks of smart contracts. Functions can be either **public**, ie they are publicly available for anyone to see and can directly interact with public state, or **private**, meaning they are executed completely client-side in the [PXE](/aztec/concepts/pxe/index.md). Read more about how private functions work [here](./inner_workings.md#private-functions). -For a more practical guide of using multiple types of functions, follow the [token tutorial](/tutorials/tutorials/contract_tutorials/token_contract.md). +For a more practical guide of using multiple types of functions, follow the [token tutorial](/tutorials/contract_tutorials/token_contract.md). Currently, any function is "mutable" in the sense that it might alter state. However, we also support support static calls, similarly to EVM. A static call is essentially a call that does not alter state (it keeps state static). @@ -22,7 +22,7 @@ Explore this section to learn: - [How function visibility works in Aztec](./visibility.md) - [Public, private, and unconstrained functions](./public_private_unconstrained.md), and how to write them -- How to write an [initializer function](/guides/guides/smart_contracts/writing_contracts/initializers.md) -- [Calling functions from within the same smart contract and from different contracts](/guides/guides/smart_contracts/writing_contracts/call_functions.md), including calling private functions from private functions, public from public, and even private from public -- [Oracles](/aztec/aztec/concepts/smart_contracts/oracles/index.md) and how Aztec smart contracts might use them +- How to write an [initializer function](/guides/smart_contracts/writing_contracts/initializers.md) +- [Calling functions from within the same smart contract and from different contracts](/guides/smart_contracts/writing_contracts/call_functions.md), including calling private functions from private functions, public from public, and even private from public +- [Oracles](/aztec/concepts/smart_contracts/oracles/index.md) and how Aztec smart contracts might use them - [How functions work under the hood](./inner_workings.md) diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/inner_workings.md b/docs/docs/aztec/concepts/smart_contracts/functions/inner_workings.md similarity index 74% rename from docs/docs/aztec/aztec/concepts/smart_contracts/functions/inner_workings.md rename to docs/docs/aztec/concepts/smart_contracts/functions/inner_workings.md index eb0a4b5599c..2e6f412ee1b 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/inner_workings.md +++ b/docs/docs/aztec/concepts/smart_contracts/functions/inner_workings.md @@ -10,7 +10,7 @@ To get a more practical understanding about functions, read [the rest of this se Aztec.nr uses an attribute system to annotate a function's type. Annotating a function with the `#[aztec(private)]` attribute tells the framework that this is a private function that will be executed on a users device. The compiler will create a circuit to define this function. -`#aztec(private)` is just syntactic sugar. At compile time, the Aztec.nr framework inserts code that allows the function to interact with the [kernel](/aztec/aztec/concepts/circuits/kernels/private_kernel.md). +`#aztec(private)` is just syntactic sugar. At compile time, the Aztec.nr framework inserts code that allows the function to interact with the [kernel](/aztec/concepts/circuits/kernels/private_kernel.md). To help illustrate how this interacts with the internals of Aztec and its kernel circuits, we can take an example private function, and explore what it looks like after Aztec.nr's macro expansion. @@ -24,12 +24,12 @@ To help illustrate how this interacts with the internals of Aztec and its kernel #### The expansion broken down? -Viewing the expanded Aztec contract uncovers a lot about how Aztec contracts interact with the [kernel](/aztec/aztec/concepts/circuits/kernels/private_kernel.md). To aid with developing intuition, we will break down each inserted line. +Viewing the expanded Aztec contract uncovers a lot about how Aztec contracts interact with the [kernel](/aztec/concepts/circuits/kernels/private_kernel.md). To aid with developing intuition, we will break down each inserted line. **Receiving context from the kernel.** #include_code context-example-inputs /noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr rust -Private function calls are able to interact with each other through orchestration from within the [kernel circuit](/aztec/aztec/concepts/circuits/kernels/private_kernel.md). The kernel circuit forwards information to each contract function (recall each contract function is a circuit). This information then becomes part of the private context. +Private function calls are able to interact with each other through orchestration from within the [kernel circuit](/aztec/concepts/circuits/kernels/private_kernel.md). The kernel circuit forwards information to each contract function (recall each contract function is a circuit). This information then becomes part of the private context. For example, within each private function we can access some global variables. To access them we can call on the `context`, e.g. `context.chain_id()`. The value of the chain ID comes from the values passed into the circuit from the kernel. The kernel checks that all of the values passed to each circuit in a function call are the same. @@ -54,7 +54,7 @@ Inside the kernel circuits, the inputs to functions are reduced to a single valu **Creating the function's context.** #include_code context-example-context /noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr rust -Each Aztec function has access to a [context](/aztec/aztec/concepts/smart_contracts/functions/context) object. This object, although labelled a global variable, is created locally on a users' device. It is initialized from the inputs provided by the kernel, and a hash of the function's inputs. +Each Aztec function has access to a [context](/aztec/concepts/smart_contracts/functions/context) object. This object, although labelled a global variable, is created locally on a users' device. It is initialized from the inputs provided by the kernel, and a hash of the function's inputs. #include_code context-example-context-return /noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr rust @@ -64,7 +64,7 @@ We achieve this by pushing return values to the execution context, which we then **Making the contract's storage available** #include_code storage-example-context /noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr rust -When a [`Storage` struct](/guides/guides/smart_contracts/writing_contracts/storage) is declared within a contract, the `storage` keyword is made available. As shown in the macro expansion above, this calls the init function on the storage struct with the current function's context. +When a [`Storage` struct](/guides/smart_contracts/writing_contracts/storage) is declared within a contract, the `storage` keyword is made available. As shown in the macro expansion above, this calls the init function on the storage struct with the current function's context. Any state variables declared in the `Storage` struct can now be accessed as normal struct members. @@ -75,14 +75,14 @@ This function takes the application context, and converts it into the `PrivateCi ## Unconstrained functions -Defining a function as `unconstrained` tells Aztec to simulate it completely client-side in the [ACIR simulator](/aztec/aztec/concepts/pxe/acir_simulator.md) without generating proofs. They are useful for extracting information from a user through an [oracle](../oracles). +Defining a function as `unconstrained` tells Aztec to simulate it completely client-side in the [ACIR simulator](/aztec/concepts/pxe/acir_simulator.md) without generating proofs. They are useful for extracting information from a user through an [oracle](../oracles). When an unconstrained function is called, it prompts the ACIR simulator to 1. generate the execution environment 2. execute the function within this environment -To generate the environment, the simulator gets the blockheader from the [PXE database](/aztec/aztec/concepts/pxe/index.md#database) and passes it along with the contract address to `ViewDataOracle`. This creates a context that simulates the state of the blockchain at a specific block, allowing the unconstrained function to access and interact with blockchain data as it would appear in that block, but without affecting the actual blockchain state. +To generate the environment, the simulator gets the blockheader from the [PXE database](/aztec/concepts/pxe/index.md#database) and passes it along with the contract address to `ViewDataOracle`. This creates a context that simulates the state of the blockchain at a specific block, allowing the unconstrained function to access and interact with blockchain data as it would appear in that block, but without affecting the actual blockchain state. Once the execution environment is created, `execute_unconstrained_function` is invoked: @@ -93,4 +93,4 @@ This: 1. Prepares the ACIR for execution 2. Converts `args` into a format suitable for the ACVM (Abstract Circuit Virtual Machine), creating an initial witness (witness = set of inputs required to compute the function). `args` might be an oracle to request a user's balance 3. Executes the function in the ACVM, which involves running the ACIR with the initial witness and the context. If requesting a user's balance, this would query the balance from the PXE database -4. Extracts the return values from the `partialWitness` and decodes them based on the artifact to get the final function output. The [artifact](/aztec/aztec/concepts/smart_contracts/contract_structure.md) is the compiled output of the contract, and has information like the function signature, parameter types, and return types +4. Extracts the return values from the `partialWitness` and decodes them based on the artifact to get the final function output. The [artifact](/aztec/concepts/smart_contracts/contract_structure.md) is the compiled output of the contract, and has information like the function signature, parameter types, and return types diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/public_private_unconstrained.md b/docs/docs/aztec/concepts/smart_contracts/functions/public_private_unconstrained.md similarity index 100% rename from docs/docs/aztec/aztec/concepts/smart_contracts/functions/public_private_unconstrained.md rename to docs/docs/aztec/concepts/smart_contracts/functions/public_private_unconstrained.md diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/visibility.md b/docs/docs/aztec/concepts/smart_contracts/functions/visibility.md similarity index 91% rename from docs/docs/aztec/aztec/concepts/smart_contracts/functions/visibility.md rename to docs/docs/aztec/concepts/smart_contracts/functions/visibility.md index 2db0a5a4805..ef5e9002ac3 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/functions/visibility.md +++ b/docs/docs/aztec/concepts/smart_contracts/functions/visibility.md @@ -4,7 +4,7 @@ title: Visibility In Aztec there are multiple different types of visibility that can be applied to functions. Namely we have `data visibility` and `function visibility`. This page explains these types of visibility. -For a practical guide of using multiple types of data and function visibility,follow the [token tutorial](/tutorials/tutorials/contract_tutorials/token_contract.md). +For a practical guide of using multiple types of data and function visibility,follow the [token tutorial](/tutorials/contract_tutorials/token_contract.md). ### Data Visibility @@ -19,7 +19,7 @@ By default, all functions are callable from other contracts, similarly to the So A good place to use `internal` is when you want a private function to be able to alter public state. As mentioned above, private functions cannot do this directly. They are able to call public functions and by making these internal we can ensure that this state manipulating function is only callable from our private function. :::danger -Note that non-internal functions could be used directly as an entry-point, which currently means that the `msg_sender` would be `0`, so for now, using address `0` as a burn address is not recommended. You can learn more about this in the [Accounts concept page](/aztec/aztec/concepts/index.md#entrypoint-restrictions). +Note that non-internal functions could be used directly as an entry-point, which currently means that the `msg_sender` would be `0`, so for now, using address `0` as a burn address is not recommended. You can learn more about this in the [Accounts concept page](/aztec/concepts/index.md#entrypoint-restrictions). ::: To understand how visibility works under the hood, check out the [Inner Workings page](./inner_workings.md). diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/index.md b/docs/docs/aztec/concepts/smart_contracts/index.md similarity index 94% rename from docs/docs/aztec/aztec/concepts/smart_contracts/index.md rename to docs/docs/aztec/concepts/smart_contracts/index.md index 2eea1b9e17f..6237dc5051a 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/index.md +++ b/docs/docs/aztec/concepts/smart_contracts/index.md @@ -24,4 +24,4 @@ There are no plans for EVM compatibility or to support Solidity in Aztec. The pr ## Further reading -Read more about writing Aztec contracts [here](/aztec/aztec/concepts/smart_contracts/index.md). +Read more about writing Aztec contracts [here](/aztec/concepts/smart_contracts/index.md). diff --git a/docs/docs/aztec/aztec/concepts/smart_contracts/oracles/index.md b/docs/docs/aztec/concepts/smart_contracts/oracles/index.md similarity index 94% rename from docs/docs/aztec/aztec/concepts/smart_contracts/oracles/index.md rename to docs/docs/aztec/concepts/smart_contracts/oracles/index.md index 9f0c252cb91..51760f0b59c 100644 --- a/docs/docs/aztec/aztec/concepts/smart_contracts/oracles/index.md +++ b/docs/docs/aztec/concepts/smart_contracts/oracles/index.md @@ -4,7 +4,7 @@ title: Oracle Functions This page goes over what oracles are in Aztec and how they work. -Looking for a hands-on guide? You can learn how to use oracles in a smart contract [here](/guides/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md). +Looking for a hands-on guide? You can learn how to use oracles in a smart contract [here](/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md). An oracle is something that allows us to get data from the outside world into our contracts. The most widely-known types of oracles in blockchain systems are probably Chainlink price feeds, which allow us to get the price of an asset in USD taking non-blockchain data into account. @@ -22,7 +22,7 @@ Oracles introduce **non-determinism** into a circuit, and thus are `unconstraine ## Inbuilt oracles -- [`debug_log`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/debug_log.nr) - Provides a couple of debug functions that can be used to log information to the console. Read more about debugging [here](/reference/reference/debugging.md#logging-in-aztecnr). +- [`debug_log`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/debug_log.nr) - Provides a couple of debug functions that can be used to log information to the console. Read more about debugging [here](/reference/debugging.md#logging-in-aztecnr). - [`auth_witness`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/authwit/src/auth_witness.nr) - Provides a way to fetch the authentication witness for a given address. This is useful when building account contracts to support approve-like functionality. - [`get_l1_to_l2_message`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/get_l1_to_l2_message.nr) - Useful for application that receive messages from L1 to be consumed on L2, such as token bridges or other cross-chain applications. - [`notes`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/aztec-nr/aztec/src/oracle/notes.nr) - Provides a lot of functions related to notes, such as fetches notes from storage etc, used behind the scenes for value notes and other pre-build note implementations. @@ -30,4 +30,4 @@ Oracles introduce **non-determinism** into a circuit, and thus are `unconstraine Find a full list [on GitHub](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/aztec-nr/aztec/src/oracle). -Please note that it is **not** possible to write a custom oracle for your dapp. Oracles are implemented in the PXE, so all users of your dapp would have to use a PXE service with your custom oracle included. If you want to inject some arbitrary data that does not have a dedicated oracle, you can use [popCapsule](/guides/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md). +Please note that it is **not** possible to write a custom oracle for your dapp. Oracles are implemented in the PXE, so all users of your dapp would have to use a PXE service with your custom oracle included. If you want to inject some arbitrary data that does not have a dedicated oracle, you can use [popCapsule](/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md). diff --git a/docs/docs/aztec/aztec/concepts/state_model/index.md b/docs/docs/aztec/concepts/state_model/index.md similarity index 97% rename from docs/docs/aztec/aztec/concepts/state_model/index.md rename to docs/docs/aztec/concepts/state_model/index.md index 593ca47e718..3a393f32076 100644 --- a/docs/docs/aztec/aztec/concepts/state_model/index.md +++ b/docs/docs/aztec/concepts/state_model/index.md @@ -44,4 +44,4 @@ This is achieved with two main features: ## Further reading -Read more about how to leverage the Aztec state model in Aztec contracts [here](/aztec/aztec/concepts/storage/index.md). +Read more about how to leverage the Aztec state model in Aztec contracts [here](/aztec/concepts/storage/index.md). diff --git a/docs/docs/aztec/aztec/concepts/state_model/public_vm.md b/docs/docs/aztec/concepts/state_model/public_vm.md similarity index 100% rename from docs/docs/aztec/aztec/concepts/state_model/public_vm.md rename to docs/docs/aztec/concepts/state_model/public_vm.md diff --git a/docs/docs/aztec/aztec/concepts/storage/index.md b/docs/docs/aztec/concepts/storage/index.md similarity index 77% rename from docs/docs/aztec/aztec/concepts/storage/index.md rename to docs/docs/aztec/concepts/storage/index.md index 7e121117ca5..643e24857e8 100644 --- a/docs/docs/aztec/aztec/concepts/storage/index.md +++ b/docs/docs/aztec/concepts/storage/index.md @@ -12,7 +12,7 @@ It also means that we need to be careful about how we allocate storage to ensure ## Public State Slots -As mentioned in [State Model](/aztec/aztec/concepts/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. +As mentioned in [State Model](/aztec/concepts/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. @@ -20,14 +20,14 @@ The mental model is that we have a key-value store, where the siloed slot is the real_storage_slot = H(contract_address, logical_storage_slot) ``` -The siloing is performed by the [Kernel circuits](/aztec/aztec/concepts/circuits). +The siloing is performed by the [Kernel circuits](/aztec/concepts/circuits). 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](/aztec/aztec/concepts/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. +Private storage is a different beast. As you might remember from [Hybrid State Model](/aztec/concepts/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). @@ -62,4 +62,4 @@ By doing this address-siloing at the kernel circuit we *force* the inserted comm 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 storage slots](/aztec/aztec/concepts/storage/index.md). +For an example of this see [developer documentation storage slots](/aztec/concepts/storage/index.md). diff --git a/docs/docs/aztec/aztec/concepts/storage/trees/index.md b/docs/docs/aztec/concepts/storage/trees/index.md similarity index 96% rename from docs/docs/aztec/aztec/concepts/storage/trees/index.md rename to docs/docs/aztec/concepts/storage/trees/index.md index 56a508aaa10..1def5386a27 100644 --- a/docs/docs/aztec/aztec/concepts/storage/trees/index.md +++ b/docs/docs/aztec/concepts/storage/trees/index.md @@ -130,7 +130,7 @@ nullifier = hash(note_hash, owner_secret_key); This has the property that it's inextricably linked to the Note it is nullifying, and it can only be derived by the owner of the `owner_public_key` contained within the Note. Ensuring that the secret key corresponds to the public key would be implemented in the Aztec contract. -A smart contract that generates this nullifier and submits it to the network will only be allowed to submit it once; a second submission will be rejected by the base [Rollup Circuit](/aztec/aztec/concepts/circuits) (which performs Merkle non-membership checks against the Nullifier Tree). This prevents a Note from being 'deleted' twice. +A smart contract that generates this nullifier and submits it to the network will only be allowed to submit it once; a second submission will be rejected by the base [Rollup Circuit](/aztec/concepts/circuits) (which performs Merkle non-membership checks against the Nullifier Tree). This prevents a Note from being 'deleted' twice. :::note @@ -169,7 +169,7 @@ This tree's data can only be read/written by the Sequencer, since only they can ## Contract Tree -The contract tree contains information about every function of every contract deployed to the Aztec network. This allows the [Kernel Circuits](/aztec/aztec/concepts/circuits) to validate that a function belongs to a specific contract. +The contract tree contains information about every function of every contract deployed to the Aztec network. This allows the [Kernel Circuits](/aztec/concepts/circuits) to validate that a function belongs to a specific contract. @@ -209,7 +209,7 @@ HistoricalAccessTree --- Header ``` -It can also be used to find information about notes, public state, and contracts that were included in a certain block using [inclusion and non-inclusion proofs](/guides/guides/smart_contracts/writing_contracts/how_to_prove_history.md). +It can also be used to find information about notes, public state, and contracts that were included in a certain block using [inclusion and non-inclusion proofs](/guides/smart_contracts/writing_contracts/how_to_prove_history.md). ## Trees of valid Kernel/Rollup circuit Verification Keys diff --git a/docs/docs/aztec/aztec/concepts/storage/trees/indexed_merkle_tree.mdx b/docs/docs/aztec/concepts/storage/trees/indexed_merkle_tree.mdx similarity index 100% rename from docs/docs/aztec/aztec/concepts/storage/trees/indexed_merkle_tree.mdx rename to docs/docs/aztec/concepts/storage/trees/indexed_merkle_tree.mdx diff --git a/docs/docs/aztec/aztec/concepts/transactions.md b/docs/docs/aztec/concepts/transactions.md similarity index 91% rename from docs/docs/aztec/aztec/concepts/transactions.md rename to docs/docs/aztec/concepts/transactions.md index fd2c0d2f468..898de71c4a8 100644 --- a/docs/docs/aztec/aztec/concepts/transactions.md +++ b/docs/docs/aztec/concepts/transactions.md @@ -30,9 +30,9 @@ _The transaction has not been broadcasted to the sequencer network yet. For now, _The transaction has still not been broadcasted to the sequencer network yet and continues to live solely within the context of the PXE._ -3. **The PXE proves correct execution** – At this point, the PXE proves correct execution (via zero-knowledge proofs) of the authorization and of the private transfer method. Once the proofs have been generated, the PXE sends the proofs and required inputs (inputs are new note commitments, stored in the [note hash tree](/aztec/aztec/concepts/storage/trees/index.md#note-hash-tree) and nullifiers stored in the [nullifiers tree](/aztec/aztec/concepts/storage/trees/index.md#nullifier-tree)) to the sequencer. Nullifiers are data that invalidate old commitments, ensuring that commitments can only be used once. +3. **The PXE proves correct execution** – At this point, the PXE proves correct execution (via zero-knowledge proofs) of the authorization and of the private transfer method. Once the proofs have been generated, the PXE sends the proofs and required inputs (inputs are new note commitments, stored in the [note hash tree](/aztec/concepts/storage/trees/index.md#note-hash-tree) and nullifiers stored in the [nullifiers tree](/aztec/concepts/storage/trees/index.md#nullifier-tree)) to the sequencer. Nullifiers are data that invalidate old commitments, ensuring that commitments can only be used once. -_The sequencer has received the transaction proof and can begin to process the transaction - verifying proofs and applying updates to the relevant [data trees](/aztec/aztec/concepts/storage/trees/index.md) - alongside other public and private transactions._ +_The sequencer has received the transaction proof and can begin to process the transaction - verifying proofs and applying updates to the relevant [data trees](/aztec/concepts/storage/trees/index.md) - alongside other public and private transactions._ 4. **The sequencer has the necessary information to act** – the randomly-selected sequencer (based on the Fernet sequencer selection protocol) validates the transaction proofs along with required inputs (e.g. the note commitments and nullifiers) for this private transfer. The sequencer also executes public functions and requests proofs of public execution from a prover network. The sequencer updates the corresponding data trees and does the same for other private transactions. When the sequencer receives proofs from the prover network, the proofs will be bundled into a final rollup proof. @@ -48,7 +48,7 @@ Transactions on Aztec start with a call from Aztec.js or the Aztec CLI, which cr See [this diagram](https://raw.githubusercontent.com/AztecProtocol/aztec-packages/2fa143e4d88b3089ebbe2a9e53645edf66157dc8/docs/static/img/sandbox_sending_a_tx.svg) for a more detailed overview of the transaction execution process. It highlights 3 different types of transaction execution: contract deployments, private transactions and public transactions. -See the page on [contract communication](/aztec/aztec/concepts/smart_contracts/communication/index.md) for more context on transaction execution. +See the page on [contract communication](/aztec/concepts/smart_contracts/communication/index.md) for more context on transaction execution. ### Enabling Transaction Semantics: The Aztec Kernel diff --git a/docs/docs/aztec/aztec/concepts/wallets/_category_.json b/docs/docs/aztec/concepts/wallets/_category_.json similarity index 100% rename from docs/docs/aztec/aztec/concepts/wallets/_category_.json rename to docs/docs/aztec/concepts/wallets/_category_.json diff --git a/docs/docs/aztec/aztec/concepts/wallets/architecture.md b/docs/docs/aztec/concepts/wallets/architecture.md similarity index 80% rename from docs/docs/aztec/aztec/concepts/wallets/architecture.md rename to docs/docs/aztec/concepts/wallets/architecture.md index f79dd176e4c..b62febe1947 100644 --- a/docs/docs/aztec/aztec/concepts/wallets/architecture.md +++ b/docs/docs/aztec/concepts/wallets/architecture.md @@ -10,7 +10,7 @@ Architecture-wise, a wallet is an instance of an **Private Execution Environment The PXE also communicates with an **Aztec Node** for retrieving public information or broadcasting transactions. Note that the PXE requires a local database for keeping private state, and is also expected to be continuously syncing new blocks for trial-decryption of user notes. -Additionally, a wallet must be able to handle one or more [account contract implementations](/aztec/aztec/concepts/index.md#account-contracts-and-wallets). When a user creates a new account, the account is represented on-chain by an account contract. The wallet is responsible for deploying and interacting with this contract. A wallet may support multiple flavours of accounts, such as an account that uses ECDSA signatures, or one that relies on WebAuthn, or one that requires multi-factor authentication. For a user, the choice of what account implementation to use is then determined by the wallet they interact with. +Additionally, a wallet must be able to handle one or more [account contract implementations](/aztec/concepts/index.md#account-contracts-and-wallets). When a user creates a new account, the account is represented on-chain by an account contract. The wallet is responsible for deploying and interacting with this contract. A wallet may support multiple flavours of accounts, such as an account that uses ECDSA signatures, or one that relies on WebAuthn, or one that requires multi-factor authentication. For a user, the choice of what account implementation to use is then determined by the wallet they interact with. In code, this translates to a wallet implementing an **AccountInterface** interface that defines [how to create an _execution request_ out of an array of _function calls_](./index.md#transaction-lifecycle) for the specific implementation of an account contract and [how to generate an _auth witness_](./index.md#authorizing-actions) for authorizing actions on behalf of the user. Think of this interface as the Javascript counterpart of an account contract, or the piece of code that knows how to format a transaction and authenticate an action based on the rules defined by the user's account contract implementation. diff --git a/docs/docs/aztec/aztec/concepts/wallets/index.md b/docs/docs/aztec/concepts/wallets/index.md similarity index 70% rename from docs/docs/aztec/aztec/concepts/wallets/index.md rename to docs/docs/aztec/concepts/wallets/index.md index 18540be83db..b47f11bab17 100644 --- a/docs/docs/aztec/aztec/concepts/wallets/index.md +++ b/docs/docs/aztec/concepts/wallets/index.md @@ -4,7 +4,7 @@ title: Wallets In this page we will cover the main responsibilities of a wallet in the Aztec network. -Refer to [_writing an account contract_](/tutorials/tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account. +Refer to [_writing an account contract_](/tutorials/write_accounts_contract.md) for a tutorial on how to write a contract to back a user's account. Go to [\_wallet architecture](./architecture.md) for an overview of its architecture and a reference on the interface a wallet must implement. @@ -16,17 +16,17 @@ In addition to these usual responsibilities, wallets in Aztec also need to track ## Account setup -The first step for any wallet is to let the user set up their [accounts](/aztec/aztec/concepts/index.md). An account in Aztec is represented on-chain by its corresponding account contract that the user must deploy to begin interacting with the network. This account contract dictates how transactions are authenticated and executed. +The first step for any wallet is to let the user set up their [accounts](/aztec/concepts/index.md). An account in Aztec is represented on-chain by its corresponding account contract that the user must deploy to begin interacting with the network. This account contract dictates how transactions are authenticated and executed. -A wallet must support at least one specific [account contract implementation](/tutorials/tutorials/write_accounts_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts). +A wallet must support at least one specific [account contract implementation](/tutorials/write_accounts_contract.md), which means being able to deploy such a contract, as well as interacting with it when sending transactions. Code-wise, this requires [implementing the `AccountContract` interface](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/aztec.js/src/account_contract/index.ts). -Note that users must be able to receive funds in Aztec before deploying their account. A wallet should let a user generate a [deterministic complete address](/aztec/aztec/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys) without having to interact with the network, so they can share it with others to receive funds. This requires that the wallet pins a specific contract implementation, its initialization arguments, a deployment salt, and a privacy key. These values yield a deterministic address, so when the account contract is actually deployed, it is available at the precalculated address. Once the account contract is deployed, the user can start sending transactions using it as the transaction origin. +Note that users must be able to receive funds in Aztec before deploying their account. A wallet should let a user generate a [deterministic complete address](/aztec/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys) without having to interact with the network, so they can share it with others to receive funds. This requires that the wallet pins a specific contract implementation, its initialization arguments, a deployment salt, and a privacy key. These values yield a deterministic address, so when the account contract is actually deployed, it is available at the precalculated address. Once the account contract is deployed, the user can start sending transactions using it as the transaction origin. ## Transaction lifecycle Every transaction in Aztec is broadcast to the network as a zero-knowledge proof of correct execution, in order to preserve privacy. This means that transaction proofs are generated on the wallet and not on a remote node. This is one of the biggest differences with regard to EVM chain wallets. -A wallet is responsible for **creating** an [_execution request_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/tx_execution_request.ts) out of one or more [_function calls_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/function_call.ts) requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet [turns that into an execution request](/aztec/aztec/concepts/index.md#execution-requests) with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/ecdsa_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key. +A wallet is responsible for **creating** an [_execution request_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/tx_execution_request.ts) out of one or more [_function calls_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/function_call.ts) requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet [turns that into an execution request](/aztec/concepts/index.md#execution-requests) with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/ecdsa_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key. Once the _execution request_ is created, the wallet is responsible for **simulating** and **proving** the execution of its private functions. The simulation yields an execution trace, which can be used to provide the user with a list of side effects of the private execution of the transaction. During this simulation, the wallet is responsible of providing data to the virtual machine, such as private notes, encryption keys, or nullifier secrets. This execution trace is fed into the prover, which returns a zero-knowledge proof that guarantees correct execution and hides all private information. The output of this process is a [_transaction_](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/types/src/tx/tx.ts) object. @@ -42,13 +42,13 @@ There are no proofs generated as of the Sandbox release. This will be included i ## Authorizing actions -Account contracts in Aztec expose an interface for other contracts to validate [whether an action is authorized by the account or not](/aztec/aztec/concepts/index.md#authorizing-actions). For example, an application contract may want to transfer tokens on behalf of a user, in which case the token contract will check with the account contract whether the application is authorized to do so. These actions may be carried out in private or in public functions, and in transactions originated by the user or by someone else. +Account contracts in Aztec expose an interface for other contracts to validate [whether an action is authorized by the account or not](/aztec/concepts/index.md#authorizing-actions). For example, an application contract may want to transfer tokens on behalf of a user, in which case the token contract will check with the account contract whether the application is authorized to do so. These actions may be carried out in private or in public functions, and in transactions originated by the user or by someone else. Wallets should manage these authorizations, prompting the user when they are requested by an application. Authorizations in private executions come in the form of _auth witnesses_, which are usually signatures over an identifier for an action. Applications can request the wallet to produce an auth witness via the `createAuthWit` call. In public functions, authorizations are pre-stored in the account contract storage, which is handled by a call to an internal function in the account contract implementation. ## Key management -As in EVM-based chains, wallets are expected to manage user keys, or provide an interface to hardware wallets or alternative key stores. Keep in mind that in Aztec each account requires [two sets of keys](/aztec/aztec/concepts/accounts/keys.md): privacy keys and authentication keys. Privacy keys are mandated by the protocol and used for encryption and nullification, whereas authentication keys are dependent on the account contract implementation rolled out by the wallet. Should the account contract support it, wallets must provide the user with the means to rotate or recover their authentication keys. +As in EVM-based chains, wallets are expected to manage user keys, or provide an interface to hardware wallets or alternative key stores. Keep in mind that in Aztec each account requires [two sets of keys](/aztec/concepts/accounts/keys.md): privacy keys and authentication keys. Privacy keys are mandated by the protocol and used for encryption and nullification, whereas authentication keys are dependent on the account contract implementation rolled out by the wallet. Should the account contract support it, wallets must provide the user with the means to rotate or recover their authentication keys. :::info Due to limitations in the current architecture, privacy keys need to be available in the wallet software itself and cannot be punted to an external keystore. This restriction may be lifted in a future release. @@ -56,7 +56,7 @@ Due to limitations in the current architecture, privacy keys need to be availabl ## Recipient encryption keys -Wallets are also expected to manage the public encryption keys of any recipients of local transactions. When creating an encrypted note for a recipient given their address, the wallet needs to provide their [complete address](/aztec/aztec/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys). Recipients broadcast their complete addresses when deploying their account contracts, and wallets collect this information and save it in a local registry for easy access when needed. +Wallets are also expected to manage the public encryption keys of any recipients of local transactions. When creating an encrypted note for a recipient given their address, the wallet needs to provide their [complete address](/aztec/concepts/accounts/keys.md#addresses-partial-addresses-and-public-keys). Recipients broadcast their complete addresses when deploying their account contracts, and wallets collect this information and save it in a local registry for easy access when needed. Note that, in order to interact with a recipient who has not yet deployed their account contract (and thus not broadcasted their complete address), it must also be possible to manually add an entry to a wallet's local registry of complete addresses. diff --git a/docs/docs/aztec/aztec/core_components.md b/docs/docs/aztec/core_components.md similarity index 73% rename from docs/docs/aztec/aztec/core_components.md rename to docs/docs/aztec/core_components.md index acaa0857820..b5619300187 100644 --- a/docs/docs/aztec/aztec/core_components.md +++ b/docs/docs/aztec/core_components.md @@ -35,13 +35,13 @@ An overview of the Aztec network architecture will help contextualize the concep ### Aztec.js -A user of the Aztec network will interact with the network through Aztec.js. Aztec.js is a library that provides APIs for managing accounts and interacting with smart contracts (including account contracts) on the Aztec network. It communicates with the [Private eXecution Environment (PXE)](/aztec/aztec/concepts/pxe) through a `PXE` implementation, allowing developers to easily register new accounts, deploy contracts, view functions, and send transactions. +A user of the Aztec network will interact with the network through Aztec.js. Aztec.js is a library that provides APIs for managing accounts and interacting with smart contracts (including account contracts) on the Aztec network. It communicates with the [Private eXecution Environment (PXE)](/aztec/concepts/pxe) through a `PXE` implementation, allowing developers to easily register new accounts, deploy contracts, view functions, and send transactions. ### Private Execution Environment -The PXE provides a secure environment for the execution of sensitive operations, ensuring private information and decrypted data are not accessible to unauthorized applications. It hides the details of the [state model](/aztec/aztec/concepts/state_model/index.md) from end users, but the state model is important for Aztec developers to understand as it has implications for [private/public execution](/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md) and [L1/L2 communication](../../protocol-specs/l1-smart-contracts/index.md). The PXE also includes the [ACIR Simulator](/aztec/aztec/concepts/pxe/acir_simulator.md) for private executions and the KeyStore for secure key management. +The PXE provides a secure environment for the execution of sensitive operations, ensuring private information and decrypted data are not accessible to unauthorized applications. It hides the details of the [state model](/aztec/concepts/state_model/index.md) from end users, but the state model is important for Aztec developers to understand as it has implications for [private/public execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md) and [L1/L2 communication](/protocol-specs/l1-smart-contracts/index.md). The PXE also includes the [ACIR Simulator](/aztec/concepts/pxe/acir_simulator.md) for private executions and the KeyStore for secure key management. -Procedurally, the PXE sends results of private function execution and requests for public function executions to the [sequencer](/aztec/aztec/concepts/nodes_clients/sequencer), which will update the state of the rollup. +Procedurally, the PXE sends results of private function execution and requests for public function executions to the [sequencer](/aztec/concepts/nodes_clients/sequencer), which will update the state of the rollup. ### Sequencer @@ -49,8 +49,8 @@ The sequencer aggregates transactions into a block, generates proofs of the stat ## Further Reading -- [The state model](/aztec/aztec/concepts/state_model) -- [Accounts](/aztec/aztec/concepts) -- [Aztec Smart Contracts](/aztec/aztec/concepts/smart_contracts) -- [Transactions](/aztec/aztec/concepts/transactions) -- [Communication between network components](/aztec/aztec/concepts/smart_contracts/communication) +- [The state model](/aztec/concepts/state_model) +- [Accounts](/aztec/concepts) +- [Aztec Smart Contracts](/aztec/concepts/smart_contracts) +- [Transactions](/aztec/concepts/transactions) +- [Communication between network components](/aztec/concepts/smart_contracts/communication) diff --git a/docs/docs/aztec/aztec/glossary/call_types.md b/docs/docs/aztec/glossary/call_types.md similarity index 99% rename from docs/docs/aztec/aztec/glossary/call_types.md rename to docs/docs/aztec/glossary/call_types.md index ba700ae846d..0ecb95dbd6c 100644 --- a/docs/docs/aztec/aztec/glossary/call_types.md +++ b/docs/docs/aztec/glossary/call_types.md @@ -121,7 +121,7 @@ A common pattern is to enqueue public calls to check some validity condition on #include_code deadline /noir-projects/noir-contracts/contracts/crowdfunding_contract/src/main.nr rust :::warning -Calling public functions privately leaks some privacy! The caller of the function and all arguments will be revelead, so exercise care when mixing the private and public domains. To learn about alternative ways to access public state privately, look into [Shared State](/reference/reference/smart_contract_reference/storage/shared_state.md). +Calling public functions privately leaks some privacy! The caller of the function and all arguments will be revelead, so exercise care when mixing the private and public domains. To learn about alternative ways to access public state privately, look into [Shared State](/reference/smart_contract_reference/storage/shared_state.md). ::: ### Public Execution diff --git a/docs/docs/aztec/aztec/glossary/index.md b/docs/docs/aztec/glossary/index.md similarity index 100% rename from docs/docs/aztec/aztec/glossary/index.md rename to docs/docs/aztec/glossary/index.md diff --git a/docs/docs/aztec/aztec/how_to_participate.md b/docs/docs/aztec/how_to_participate.md similarity index 100% rename from docs/docs/aztec/aztec/how_to_participate.md rename to docs/docs/aztec/how_to_participate.md diff --git a/docs/docs/aztec/aztec/limitations.md b/docs/docs/aztec/limitations.md similarity index 89% rename from docs/docs/aztec/aztec/limitations.md rename to docs/docs/aztec/limitations.md index 5ca4703a923..6c48a29e7e5 100644 --- a/docs/docs/aztec/aztec/limitations.md +++ b/docs/docs/aztec/limitations.md @@ -30,11 +30,11 @@ Help shape and define: - It is a testing environment, it is insecure, unaudited and does not generate any proofs, its only for testing purposes; - Constructors can not call nor alter public state - - The constructor is executed exclusively in private domain, WITHOUT the ability to call public functions or alter public state. This means to set initial storage values, you need to follow a pattern similar to [proxies in Ethereum](https://blog.openzeppelin.com/proxy-patterns), where you `initialize` the contract with values after it have been deployed, see [initializer functions](/guides/guides/smart_contracts/writing_contracts/initializers.md). + - The constructor is executed exclusively in private domain, WITHOUT the ability to call public functions or alter public state. This means to set initial storage values, you need to follow a pattern similar to [proxies in Ethereum](https://blog.openzeppelin.com/proxy-patterns), where you `initialize` the contract with values after it have been deployed, see [initializer functions](/guides/smart_contracts/writing_contracts/initializers.md). - Beware that what you think of as a `view` could alter state ATM! Notably the account could alter state or re-enter whenever the account contract's `is_valid` function is called. - `msg_sender` is currently leaking when doing private -> public calls - - The `msg_sender` will always be set, if you call a public function from the private world, the `msg_sender` will be set to the private caller's address. See [function context](/aztec/aztec/concepts/smart_contracts/functions/context). -- The initial `msg_sender` is 0, which can be problematic for some contracts, see [function visibility](/aztec/aztec/concepts/smart_contracts/functions/visibility.md). + - The `msg_sender` will always be set, if you call a public function from the private world, the `msg_sender` will be set to the private caller's address. See [function context](/aztec/concepts/smart_contracts/functions/context). +- The initial `msg_sender` is 0, which can be problematic for some contracts, see [function visibility](/aztec/concepts/smart_contracts/functions/visibility.md). - Unencrypted logs don't link to the contract that emitted it, so essentially just a `debug_log`` that you can match values against. - A note that is created and nullified in the same transaction will still emit an encrypted log. - A limited amount of new note hashes, nullifiers and calls that are supported by a transaction, see [circuit limitations](#circuit-limitations). @@ -53,7 +53,7 @@ That's right, the Sandbox doesn't actually generate or verify any zk-SNARKs yet! The main goal of the Sandbox is to enable developers to experiment with building apps, and hopefully to provide feedback. We want the developer experience to be as fast as possible, much like how Ethereum developers use Ganache or Anvil to get super-fast block times, instead of the slow-but-realistic 12-second block times that they'll encounter in production. A fast Sandbox enables fast testing, which enables developers to iterate quickly. -That's not to say a super-fast proving system isn't being worked on [as we speak](/aztec/aztec/roadmap/cryptography_roadmap.md). +That's not to say a super-fast proving system isn't being worked on [as we speak](/aztec/roadmap/cryptography_roadmap.md). #### What are the consequences? @@ -172,11 +172,11 @@ This will be patched in the near future, but unfortunately, app developers might ### New Privacy Standards are required -There are many [patterns](/reference/reference/privacy_considerations.md) which can leak privacy, even on Aztec. Standards haven't been developed yet, to encourage best practices when designing private smart contracts. +There are many [patterns](/reference/privacy_considerations.md) which can leak privacy, even on Aztec. Standards haven't been developed yet, to encourage best practices when designing private smart contracts. #### What are the consequences? -For example, until community standards are developed to reduce the uniqueness of ['Tx Fingerprints'](/reference/reference/privacy_considerations.md#function-fingerprints-and-tx-fingerprints) app developers might accidentally forfeit some function privacy. +For example, until community standards are developed to reduce the uniqueness of ['Tx Fingerprints'](/reference/privacy_considerations.md#function-fingerprints-and-tx-fingerprints) app developers might accidentally forfeit some function privacy. ## Circuit limitations @@ -192,7 +192,7 @@ Here are the current constants: #### What are the consequences? -When you write an Aztec.nr [function](/aztec/aztec/concepts/smart_contracts/functions), there will be upper bounds on the following: +When you write an Aztec.nr [function](/aztec/concepts/smart_contracts/functions), there will be upper bounds on the following: - The number of public state reads and writes; - The number of note reads and nullifications; @@ -208,13 +208,13 @@ Not only are there limits on a _per function_ basis, there are also limits on a **In particular, these _per-transaction_ limits will limit transaction call stack depths** in the Sandbox. That means if a function call results in a cascade of nested function calls, and each of those function calls outputs lots of state reads and writes, or logs (etc.), then all of that accumulated output data might exceed the per-transaction limits that we currently have. This would cause such transactions to fail. -There are plans to relax all of this rigidity, by providing many 'sizes' of [kernel circuit](/aztec/aztec/concepts/circuits), and introducing a 'bus' to ferry varying lengths of data between kernel iterations. But that'll all take some time. +There are plans to relax all of this rigidity, by providing many 'sizes' of [kernel circuit](/aztec/concepts/circuits), and introducing a 'bus' to ferry varying lengths of data between kernel iterations. But that'll all take some time. > **In the mean time**, if you encounter a per-transaction limit when testing, and you're feeling adventurous, you could 'hack' the Sandbox to increase the limits. See here (TODO: link) for a guide. **However**, the limits cannot be increased indefinitely. So although we do anticipate that we'll be able to increase them a little bit, don't go mad and provide yourself with 1 million state transitions per transaction. That would be as unrealistic as artificially increasing Ethereum gas limits to 1 trillion. ### Circuits Processing Order Differs from Execution Order -Each function call is represented by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](/aztec/aztec/concepts/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. In doing so, the processing order differs from the execution order. Firstly, the private kernel has to handle one function call in its entirety at a time because a zk proof cannot be verified partially. This property alone makes it impossible for the ordering of kernel circuit validation to match the order in which the functions of the transaction were executed. Secondly, the private kernel processes function calls in a stack-based order, i.e., after having processed a function call, it processes all direct child function calls in an order which is the reverse of the execution order. +Each function call is represented by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](/aztec/concepts/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. In doing so, the processing order differs from the execution order. Firstly, the private kernel has to handle one function call in its entirety at a time because a zk proof cannot be verified partially. This property alone makes it impossible for the ordering of kernel circuit validation to match the order in which the functions of the transaction were executed. Secondly, the private kernel processes function calls in a stack-based order, i.e., after having processed a function call, it processes all direct child function calls in an order which is the reverse of the execution order. Note that there is no plan to change this in the future. @@ -242,7 +242,7 @@ Transaction output elements such as notes in encrypted logs, note hashes (commit ### Chopped Transient Notes are still Emitted in Logs -A note which is created and nullified during the very same transaction is called transient. Such a note is chopped by the [private kernel circuit](/aztec/aztec/concepts/circuits/kernels/private_kernel.md) and is never stored in any persistent data tree. +A note which is created and nullified during the very same transaction is called transient. Such a note is chopped by the [private kernel circuit](/aztec/concepts/circuits/kernels/private_kernel.md) and is never stored in any persistent data tree. For the time being, such chopped notes are still emitted through encrypted logs (which is the communication channel to transmit notes). When a log containing a chopped note is processed, a warning will be logged about a decrypted note which does not exist in data tree. We [improved](https://github.com/AztecProtocol/aztec-packages/issues/1603) error logging to help identify such an occurrence. However, this might be a source of confusion. This issue is tracked in ticket [#1641](https://github.com/AztecProtocol/aztec-packages/issues/1641). diff --git a/docs/docs/aztec/aztec/roadmap/_category_.json b/docs/docs/aztec/roadmap/_category_.json similarity index 100% rename from docs/docs/aztec/aztec/roadmap/_category_.json rename to docs/docs/aztec/roadmap/_category_.json diff --git a/docs/docs/aztec/aztec/roadmap/cryptography_roadmap.md b/docs/docs/aztec/roadmap/cryptography_roadmap.md similarity index 100% rename from docs/docs/aztec/aztec/roadmap/cryptography_roadmap.md rename to docs/docs/aztec/roadmap/cryptography_roadmap.md diff --git a/docs/docs/aztec/aztec/roadmap/engineering_roadmap.md b/docs/docs/aztec/roadmap/engineering_roadmap.md similarity index 99% rename from docs/docs/aztec/aztec/roadmap/engineering_roadmap.md rename to docs/docs/aztec/roadmap/engineering_roadmap.md index 6f510af56e6..02be93a9875 100644 --- a/docs/docs/aztec/aztec/roadmap/engineering_roadmap.md +++ b/docs/docs/aztec/roadmap/engineering_roadmap.md @@ -124,7 +124,7 @@ CI takes up a significant amount of time. It gets its own section here, so we re ## Shared Mutable State -We _need_ a way to read mutable public data from a private function. We are moving away from the old Slow Updates Tree in favor of [Shared Mutable](/reference/reference/smart_contract_reference/storage/shared_state.md). +We _need_ a way to read mutable public data from a private function. We are moving away from the old Slow Updates Tree in favor of [Shared Mutable](/reference/smart_contract_reference/storage/shared_state.md). ## Contract classes and instances? diff --git a/docs/docs/aztec/aztec/roadmap/features_initial_ldt.md b/docs/docs/aztec/roadmap/features_initial_ldt.md similarity index 100% rename from docs/docs/aztec/aztec/roadmap/features_initial_ldt.md rename to docs/docs/aztec/roadmap/features_initial_ldt.md diff --git a/docs/docs/aztec/aztec/roadmap/index.md b/docs/docs/aztec/roadmap/index.md similarity index 100% rename from docs/docs/aztec/aztec/roadmap/index.md rename to docs/docs/aztec/roadmap/index.md diff --git a/docs/docs/getting_started/getting_started/index.md b/docs/docs/getting_started.md similarity index 89% rename from docs/docs/getting_started/getting_started/index.md rename to docs/docs/getting_started.md index 18c358b4cf2..163fa2588a5 100644 --- a/docs/docs/getting_started/getting_started/index.md +++ b/docs/docs/getting_started.md @@ -16,7 +16,7 @@ This creates a codespace with a prebuilt image containing one of the "Aztec Boxe The above method uses Aztec boxes to install the sandbox and clone the repo. You can use it too to get started on your own machine and use your own IDE. -You can also [install the sandbox manually](/reference/reference/sandbox_reference). +You can also [install the sandbox manually](/reference/sandbox_reference). ### Prerequisites @@ -37,8 +37,8 @@ You can run `npx create-aztec-app sandbox -h` to start, stop, update and output ## What's next? -To deploy a smart contract to your sandbox and interact with it using Aztec.js, go to the [next page](aztecjs-getting-started.md). +To deploy a smart contract to your sandbox and interact with it using Aztec.js, go to the [next page](getting_started/aztecjs-getting-started.md). -To skip this and write your first smart contract, go to the [Aztec.nr getting started page](aztecnr-getting-started.md). +To skip this and write your first smart contract, go to the [Aztec.nr getting started page](getting_started/aztecnr-getting-started.md). diff --git a/docs/docs/getting_started/_category_.json b/docs/docs/getting_started/_category_.json deleted file mode 100644 index 52193ac82d5..00000000000 --- a/docs/docs/getting_started/_category_.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "position": 1, - "collapsible": true, - "collapsed": true, - "label": "Getting Started" -} diff --git a/docs/docs/getting_started/getting_started/aztecjs-getting-started.md b/docs/docs/getting_started/aztecjs-getting-started.md similarity index 96% rename from docs/docs/getting_started/getting_started/aztecjs-getting-started.md rename to docs/docs/getting_started/aztecjs-getting-started.md index b292cce92fc..88cf9c2210f 100644 --- a/docs/docs/getting_started/getting_started/aztecjs-getting-started.md +++ b/docs/docs/getting_started/aztecjs-getting-started.md @@ -7,11 +7,11 @@ 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](./index.md). +This guide assumes you have followed the [quickstart](../getting_started.md). ## Prerequisites -- A running [Aztec sandbox](./index.md) +- A running [Aztec sandbox](../getting_started.md) ## Set up the project @@ -146,9 +146,9 @@ The sandbox is preloaded with multiple accounts so you don't have to sit and cre #include_code load_accounts /yarn-project/end-to-end/src/composed/e2e_sandbox_example.test.ts typescript -An explanation on accounts on Aztec can be found [here](/aztec/aztec/concepts/index.md). +An explanation on accounts on Aztec can be found [here](/aztec/concepts/index.md). -If you want more accounts, you can find instructions in the [Account creation section](/guides/guides/local_env/creating_schnorr_accounts). +If you want more accounts, you can find instructions in the [Account creation section](/guides/local_env/creating_schnorr_accounts). ## Deploy a contract @@ -256,7 +256,7 @@ Now lets transfer some funds from Alice to Bob by calling the `transfer` functio 1. The sender. 2. The recipient. 3. The quantity of tokens to be transferred. -4. The nonce for the [authentication witness](/aztec/aztec/concepts/index.md#authorizing-actions), or 0 if msg.sender equal sender. +4. The nonce for the [authentication witness](/aztec/concepts/index.md#authorizing-actions), or 0 if msg.sender equal sender. Here is the Typescript code to call the `transfer` function, add this to your `index.ts` at the bottom of the `main` function: @@ -353,7 +353,7 @@ Our complete output should now be something like: token Bob's balance 10543 +43ms ``` -That's it! We have successfully deployed a token contract to an instance of the Aztec network and mined private state-transitioning transactions. We have also queried the resulting state all via the interfaces provided by the contract. To see exactly what has happened here, you can learn about the transaction flow [here](/aztec/aztec/concepts/transactions). +That's it! We have successfully deployed a token contract to an instance of the Aztec network and mined private state-transitioning transactions. We have also queried the resulting state all via the interfaces provided by the contract. To see exactly what has happened here, you can learn about the transaction flow [here](/aztec/concepts/transactions). ## Next Steps diff --git a/docs/docs/getting_started/getting_started/aztecnr-getting-started.md b/docs/docs/getting_started/aztecnr-getting-started.md similarity index 95% rename from docs/docs/getting_started/getting_started/aztecnr-getting-started.md rename to docs/docs/getting_started/aztecnr-getting-started.md index 1e331c443f5..8e2abeff7b7 100644 --- a/docs/docs/getting_started/getting_started/aztecnr-getting-started.md +++ b/docs/docs/getting_started/aztecnr-getting-started.md @@ -5,11 +5,11 @@ sidebar_position: 2 In this guide, we will create our first Aztec.nr smart contract. We will build a simple private counter. This contract will get you started with the basic setup and syntax of Aztec.nr, but doesn't showcase the awesome stuff Aztec is capable of. -If you already have some experience with Noir and want to build a cooler contract that utilizes both private and public state, you might want to check out the [token contract tutorial instead](/tutorials/tutorials/contract_tutorials/token_contract.md). +If you already have some experience with Noir and want to build a cooler contract that utilizes both private and public state, you might want to check out the [token contract tutorial instead](/tutorials/contract_tutorials/token_contract.md). ## Prerequisites -- You have followed the [quickstart](./index.md) +- You have followed the [quickstart](../getting_started.md) - Running Aztec Sandbox ## Set up a project @@ -116,7 +116,7 @@ Let’s create a constructor method to run on deployment that assigns an initial This function accesses the counts from storage. Then it assigns the passed initial counter to the `owner`'s counter privately using `at().add()`. -We have annotated this and other functions with `#[aztec(private)]` which are ABI macros so the compiler understands it will handle private inputs. Learn more about functions and annotations [here](/aztec/aztec/concepts/smart_contracts/functions). +We have annotated this and other functions with `#[aztec(private)]` which are ABI macros so the compiler understands it will handle private inputs. Learn more about functions and annotations [here](/aztec/concepts/smart_contracts/functions). ## Incrementing our counter @@ -181,7 +181,7 @@ Update the `Noir: Nargo Path` field to point to your desired `aztec-nargo` execu The next recommmended steps are follow the tutorials in order. They will teach you more about contracts, Aztec.js, and how Aztec works in general. -To follow the series of tutorials, start with the private voting contract [here](/tutorials/tutorials/contract_tutorials/private_voting_contract.md). +To follow the series of tutorials, start with the private voting contract [here](/tutorials/contract_tutorials/private_voting_contract.md). -Alternatively, you can read about the high level architecture on the [Core Components page](/aztec/aztec/concepts/state_model/index.md) and [the lifecycle of a transaction](/aztec/aztec/concepts/transactions). +Alternatively, you can read about the high level architecture on the [Core Components page](/aztec/concepts/state_model/index.md) and [the lifecycle of a transaction](/aztec/concepts/transactions). diff --git a/docs/docs/getting_started/getting_started/_category_.json b/docs/docs/getting_started/getting_started/_category_.json deleted file mode 100644 index f2c55c6f9e1..00000000000 --- a/docs/docs/getting_started/getting_started/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Getting Started", - "position": 1 -} diff --git a/docs/docs/guides/_category_.json b/docs/docs/guides/_category_.json deleted file mode 100644 index 5dc68949682..00000000000 --- a/docs/docs/guides/_category_.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "position": 2, - "collapsible": true, - "collapsed": true, - "label": "Guides" -} diff --git a/docs/docs/guides/guides/_category_.json b/docs/docs/guides/guides/_category_.json deleted file mode 100644 index a8fa84718fc..00000000000 --- a/docs/docs/guides/guides/_category_.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "position": 0, - "collapsible": true, - "collapsed": true, - "label": "Guides" -} diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/portals/index.md b/docs/docs/guides/guides/smart_contracts/writing_contracts/portals/index.md deleted file mode 100644 index f861c47664a..00000000000 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/portals/index.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Portals ---- - -A portal is a point of contact between L1 and a contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2. - -As outlined in [Communication](../../../../../protocol-specs/l1-smart-contracts/index.md), an Aztec L2 contract does not have to be linked to a portal contract, but can specify an intended portal in storage. Note, that a portal doesn't actually need to be a contract, it could be any address on L1. diff --git a/docs/docs/guides/guides/js_apps/_category_.json b/docs/docs/guides/js_apps/_category_.json similarity index 100% rename from docs/docs/guides/guides/js_apps/_category_.json rename to docs/docs/guides/js_apps/_category_.json diff --git a/docs/docs/guides/guides/js_apps/call_view_function.md b/docs/docs/guides/js_apps/call_view_function.md similarity index 100% rename from docs/docs/guides/guides/js_apps/call_view_function.md rename to docs/docs/guides/js_apps/call_view_function.md diff --git a/docs/docs/guides/guides/js_apps/create_account.md b/docs/docs/guides/js_apps/create_account.md similarity index 100% rename from docs/docs/guides/guides/js_apps/create_account.md rename to docs/docs/guides/js_apps/create_account.md diff --git a/docs/docs/guides/guides/js_apps/deploy_contract.md b/docs/docs/guides/js_apps/deploy_contract.md similarity index 80% rename from docs/docs/guides/guides/js_apps/deploy_contract.md rename to docs/docs/guides/js_apps/deploy_contract.md index 90e4ddd9f83..1a511366185 100644 --- a/docs/docs/guides/guides/js_apps/deploy_contract.md +++ b/docs/docs/guides/js_apps/deploy_contract.md @@ -10,11 +10,11 @@ You should have a wallet to act as the deployer, and a contract artifact ready t You can learn how to create wallets from [this guide](./create_account.md). -You can read about contract artifacts [here](/aztec/aztec/concepts/smart_contracts/contract_structure.md). +You can read about contract artifacts [here](/aztec/concepts/smart_contracts/contract_structure.md). ## Import the contract artifact -In this guide we are using a Token contract artifact. This comes from the [token contract tutorial](/tutorials/tutorials/contract_tutorials/token_contract.md). +In this guide we are using a Token contract artifact. This comes from the [token contract tutorial](/tutorials/contract_tutorials/token_contract.md). #include_code import_token_contract yarn-project/end-to-end/src/composed/docs_examples.test.ts typescript diff --git a/docs/docs/guides/guides/js_apps/send_transaction.md b/docs/docs/guides/js_apps/send_transaction.md similarity index 100% rename from docs/docs/guides/guides/js_apps/send_transaction.md rename to docs/docs/guides/js_apps/send_transaction.md diff --git a/docs/docs/guides/guides/js_apps/test_contracts.md b/docs/docs/guides/js_apps/test_contracts.md similarity index 86% rename from docs/docs/guides/guides/js_apps/test_contracts.md rename to docs/docs/guides/js_apps/test_contracts.md index 14e5b8854b9..53a7272335a 100644 --- a/docs/docs/guides/guides/js_apps/test_contracts.md +++ b/docs/docs/guides/js_apps/test_contracts.md @@ -8,7 +8,7 @@ We will be using typescript to write our tests, and rely on the [`aztec.js`](htt ## A simple example -Let's start with a simple example for a test using the [Sandbox](/reference/reference/sandbox_reference/index.md). We will create two accounts and deploy a token contract in a setup step, and then issue a transfer from one user to another. +Let's start with a simple example for a test using the [Sandbox](/reference/sandbox_reference/index.md). We will create two accounts and deploy a token contract in a setup step, and then issue a transfer from one user to another. #include_code sandbox-example /yarn-project/end-to-end/src/guides/dapp_testing.test.ts typescript @@ -17,7 +17,7 @@ This test sets up the environment by creating a client to the Private Execution Once we have this setup, the test itself is simple. We check the balance of the `recipient` user to ensure it has no tokens, send and await a deployment transaction, and then check the balance again to ensure it was increased. Note that all numeric values are represented as [native bigints](https://developer.mozilla.org/en-US/docs/Web/JavaScript//reference/Global_Objects/BigInt) to avoid loss of precision. :::info -We are using the `Token` contract's typescript interface. Follow the [typescript interface section](/guides/guides/smart_contracts/how_to_compile_contract.md#typescript-interfaces) to get type-safe methods for deploying and interacting with the token contract. +We are using the `Token` contract's typescript interface. Follow the [typescript interface section](/guides/smart_contracts/how_to_compile_contract.md#typescript-interfaces) to get type-safe methods for deploying and interacting with the token contract. ::: To run the test, first make sure the Sandbox is running on port 8080, and then [run your tests using jest](https://jestjs.io/docs/getting-started#running-from-command-line). Your test should pass, and you should see the following output in the Sandbox logs, where each chunk corresponds to a transaction. Note how this test run has a total of four transactions: two for deploying the account contracts for the `owner` and `recipient`, another for deploying the token contract, and a last one for actually executing the transfer. @@ -92,7 +92,7 @@ If a note doesn't appear when you expect it to, check the visible notes returned If the note appears in the visible notes and it contains the expected values there is probably an issue with how you fetch the notes. Check that the note getter (or note viewer) parameters are set correctly. If the note doesn't appear, ensure that you have emitted the corresponding encrypted log (usually by passing in a `broadcast = true` param to the `create_note` function). You can also check the Sandbox logs to see if the `emitEncryptedLog` was emitted. Run `export DEBUG="aztec:\*" before spinning up sandbox to see all the logs. -For debugging and logging in Aztec contracts, see [this page](/reference/reference/debugging.md). +For debugging and logging in Aztec contracts, see [this page](/reference/debugging.md). ## Assertions @@ -142,13 +142,13 @@ WARN Error processing tx 06dc87c4d64462916ea58426ffcfaf20017880b353c9ec3e0f0ee5f We can check private or public state directly rather than going through view-only methods, as we did in the initial example by calling `token.methods.balance().simulate()`. Bear in mind that directly accessing contract storage will break any kind of encapsulation. -To query storage directly, you'll need to know the slot you want to access. This can be checked in the [contract's `Storage` definition](/aztec/aztec/concepts/storage/index.md) directly for most data types. However, when it comes to mapping types, as in most EVM languages, we'll need to calculate the slot for a given key. To do this, we'll use the [`CheatCodes`](/reference/reference/sandbox_reference/cheat_codes.md) utility class: +To query storage directly, you'll need to know the slot you want to access. This can be checked in the [contract's `Storage` definition](/aztec/concepts/storage/index.md) directly for most data types. However, when it comes to mapping types, as in most EVM languages, we'll need to calculate the slot for a given key. To do this, we'll use the [`CheatCodes`](/reference/sandbox_reference/cheat_codes.md) utility class: #include_code calc-slot /yarn-project/end-to-end/src/guides/dapp_testing.test.ts typescript #### Querying private state -Private state in the Aztec Network is represented via sets of [private notes](/aztec/aztec/concepts/state_model/index.md#private-state). In our token contract example, the balance of a user is represented as a set of unspent value notes, each with their own corresponding numeric value. +Private state in the Aztec Network is represented via sets of [private notes](/aztec/concepts/state_model/index.md#private-state). In our token contract example, the balance of a user is represented as a set of unspent value notes, each with their own corresponding numeric value. #include_code value-note-def noir-projects/aztec-nr/value-note/src/value_note.nr rust @@ -158,13 +158,13 @@ We can query the Private eXecution Environment (PXE) for all notes encrypted for #### Querying public state -[Public state](/aztec/aztec/concepts/state_model/index.md#public-state) behaves as a key-value store, much like in the EVM. This scenario is much more straightforward, in that we can directly query the target slot and get the result back as a buffer. Note that we use the [`TokenContract`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr) in this example, which defines a mapping of public balances on slot 6. +[Public state](/aztec/concepts/state_model/index.md#public-state) behaves as a key-value store, much like in the EVM. This scenario is much more straightforward, in that we can directly query the target slot and get the result back as a buffer. Note that we use the [`TokenContract`](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/token_contract/src/main.nr) in this example, which defines a mapping of public balances on slot 6. #include_code public-storage /yarn-project/end-to-end/src/guides/dapp_testing.test.ts typescript ### Logs -Last but not least, we can check the logs of [events](/guides/guides/smart_contracts/writing_contracts/how_to_emit_event) emitted by our contracts. Contracts in Aztec can emit both [encrypted](/guides/guides/smart_contracts/writing_contracts/how_to_emit_event.md#encrypted-events) and [unencrypted](/guides/guides/smart_contracts/writing_contracts/how_to_emit_event.md#unencrypted-events) events. +Last but not least, we can check the logs of [events](/guides/smart_contracts/writing_contracts/how_to_emit_event) emitted by our contracts. Contracts in Aztec can emit both [encrypted](/guides/smart_contracts/writing_contracts/how_to_emit_event.md#encrypted-events) and [unencrypted](/guides/smart_contracts/writing_contracts/how_to_emit_event.md#unencrypted-events) events. :::info At the time of this writing, only unencrypted events can be queried directly. Encrypted events are always assumed to be encrypted notes. @@ -178,7 +178,7 @@ We can query the PXE for the unencrypted logs emitted in the block where our tra ## Cheats -The [`CheatCodes`](/reference/reference/sandbox_reference/cheat_codes.md) class, which we used for [calculating the storage slot above](#state), also includes a set of cheat methods for modifying the chain state that can be handy for testing. +The [`CheatCodes`](/reference/sandbox_reference/cheat_codes.md) class, which we used for [calculating the storage slot above](#state), also includes a set of cheat methods for modifying the chain state that can be handy for testing. ### Set next block timestamp diff --git a/docs/docs/guides/guides/local_env/_category_.json b/docs/docs/guides/local_env/_category_.json similarity index 100% rename from docs/docs/guides/guides/local_env/_category_.json rename to docs/docs/guides/local_env/_category_.json diff --git a/docs/docs/guides/guides/local_env/creating_schnorr_accounts.md b/docs/docs/guides/local_env/creating_schnorr_accounts.md similarity index 93% rename from docs/docs/guides/guides/local_env/creating_schnorr_accounts.md rename to docs/docs/guides/local_env/creating_schnorr_accounts.md index 0649378a77a..51eb3e24a84 100644 --- a/docs/docs/guides/guides/local_env/creating_schnorr_accounts.md +++ b/docs/docs/guides/local_env/creating_schnorr_accounts.md @@ -7,14 +7,14 @@ sidebar_position: 1 This section shows how to create schnorr account wallets on the Aztec Sandbox. -An in-depth explaining about accounts on aztec can be found [here](/aztec/aztec/concepts/index.md). But creating an account on the Sandbox does 2 things: +An in-depth explaining about accounts on aztec can be found [here](/aztec/concepts/index.md). But creating an account on the Sandbox does 2 things: 1. Deploys an account contract -- representing you -- allowing you to perform actions on the network (deploy contracts, call functions etc). 2. Adds your encryption keys to the Private eXecution Environment (PXE) allowing it to decrypt and manage your private state. ## Pre-requisites -Have a running Sandbox and a repository that interacts with it as explained [here](/getting_started/getting_started). +Have a running Sandbox and a repository that interacts with it as explained [here](/getting_started). Let's assume you have a file `src/index.ts` from the example used in the Sandbox page. @@ -61,4 +61,4 @@ Once this has completed, the L2 block is retrieved and pulled down to the PXE so ## Next Steps -Check out our section on [Writing your own Account Contract](/tutorials/tutorials/write_accounts_contract.md) leveraging our account abstraction +Check out our section on [Writing your own Account Contract](/tutorials/write_accounts_contract.md) leveraging our account abstraction diff --git a/docs/docs/guides/guides/local_env/run_more_than_one_pxe_sandbox.md b/docs/docs/guides/local_env/run_more_than_one_pxe_sandbox.md similarity index 97% rename from docs/docs/guides/guides/local_env/run_more_than_one_pxe_sandbox.md rename to docs/docs/guides/local_env/run_more_than_one_pxe_sandbox.md index 398a0fd6112..9081163c703 100644 --- a/docs/docs/guides/guides/local_env/run_more_than_one_pxe_sandbox.md +++ b/docs/docs/guides/local_env/run_more_than_one_pxe_sandbox.md @@ -39,6 +39,6 @@ You should see something like this: Aztec Server listening on port 8080 ``` -You can learn more about custom commands in the [sandbox reference](/reference/reference/sandbox_reference/index.md). +You can learn more about custom commands in the [sandbox reference](/reference/sandbox_reference/index.md). diff --git a/docs/docs/guides/guides/local_env/versions-updating.md b/docs/docs/guides/local_env/versions-updating.md similarity index 98% rename from docs/docs/guides/guides/local_env/versions-updating.md rename to docs/docs/guides/local_env/versions-updating.md index 0a133ee1359..cb322f82c43 100644 --- a/docs/docs/guides/guides/local_env/versions-updating.md +++ b/docs/docs/guides/local_env/versions-updating.md @@ -81,7 +81,7 @@ cd your/aztec/project aztec-builder update . --contract src/contract1 --contract src/contract2 ``` -The sandbox must be running for the update command to work. Make sure it is [installed and running](/reference/reference/sandbox_reference/index.md). +The sandbox must be running for the update command to work. Make sure it is [installed and running](/reference/sandbox_reference/index.md). Follow [updating Aztec.nr packages](#updating-aztecnr-packages) and [updating JavaScript packages](#updating-aztecjs-packages) guides. diff --git a/docs/docs/guides/guides/smart_contracts/_category_.json b/docs/docs/guides/smart_contracts/_category_.json similarity index 100% rename from docs/docs/guides/guides/smart_contracts/_category_.json rename to docs/docs/guides/smart_contracts/_category_.json diff --git a/docs/docs/guides/guides/smart_contracts/how_to_compile_contract.md b/docs/docs/guides/smart_contracts/how_to_compile_contract.md similarity index 91% rename from docs/docs/guides/guides/smart_contracts/how_to_compile_contract.md rename to docs/docs/guides/smart_contracts/how_to_compile_contract.md index ddf8cc86833..944e2dea6ed 100644 --- a/docs/docs/guides/guides/smart_contracts/how_to_compile_contract.md +++ b/docs/docs/guides/smart_contracts/how_to_compile_contract.md @@ -3,9 +3,9 @@ title: How to Compile a Contract sidebar_position: 3 --- -import Disclaimer from "../../../../src/components/Disclaimers/\_wip_disclaimer.mdx"; +import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx"; -Once you have written a contract in Aztec.nr, you will need to compile it into an [artifact](/aztec/aztec/concepts/smart_contracts/contract_structure.md) in order to use it. +Once you have written a contract in Aztec.nr, you will need to compile it into an [artifact](/aztec/concepts/smart_contracts/contract_structure.md) in order to use it. In this guide we will cover how to do so, both using the `aztec-nargo` command and programmatically. @@ -21,7 +21,7 @@ Run the `aztec-nargo compile` command within your contract project folder (the o aztec-nargo compile ``` -This will output a JSON [artifact](/aztec/aztec/concepts/smart_contracts/contract_structure.md) for each contract in the project to a `target` folder containing the Noir ABI artifacts. +This will output a JSON [artifact](/aztec/concepts/smart_contracts/contract_structure.md) for each contract in the project to a `target` folder containing the Noir ABI artifacts. :::note This command looks for `Nargo.toml` files by ascending up the parent directories, and will compile the top-most Nargo.toml file it finds. @@ -222,11 +222,11 @@ export class TokenContract extends ContractBase { } ``` -Read more about interacting with contracts using `aztec.js` [here](/getting_started/getting_started/aztecjs-getting-started.md). +Read more about interacting with contracts using `aztec.js` [here](/getting_started/aztecjs-getting-started.md). ### Aztec.nr interfaces -An Aztec.nr contract can [call a function](/guides/guides/smart_contracts/writing_contracts/call_functions.md) in another contract via `context.call_private_function` or `context.call_public_function`. However, this requires manually assembling the function selector and manually serializing the arguments, which is not type-safe. +An Aztec.nr contract can [call a function](/guides/smart_contracts/writing_contracts/call_functions.md) in another contract via `context.call_private_function` or `context.call_public_function`. However, this requires manually assembling the function selector and manually serializing the arguments, which is not type-safe. To make this easier, the compiler automatically generates interface structs that expose a convenience method for each function listed in a given contract artifact. These structs are intended to be used from another contract project that calls into the current one. @@ -260,7 +260,7 @@ contract FPC { } ``` -Read more about how to use the Aztec.nr interfaces [here](/aztec/aztec/concepts/smart_contracts/functions). +Read more about how to use the Aztec.nr interfaces [here](/aztec/concepts/smart_contracts/functions). :::info At the moment, the compiler generates these interfaces from already compiled ABIs, and not from source code. This means that you should not import a generated interface from within the same project as its source contract, or you risk circular references. diff --git a/docs/docs/guides/guides/smart_contracts/how_to_deploy_contract.md b/docs/docs/guides/smart_contracts/how_to_deploy_contract.md similarity index 84% rename from docs/docs/guides/guides/smart_contracts/how_to_deploy_contract.md rename to docs/docs/guides/smart_contracts/how_to_deploy_contract.md index 5811c261265..f9c2f851814 100644 --- a/docs/docs/guides/guides/smart_contracts/how_to_deploy_contract.md +++ b/docs/docs/guides/smart_contracts/how_to_deploy_contract.md @@ -5,13 +5,13 @@ sidebar_position: 4 # Deploying contracts -Once you have [compiled](/guides/guides/smart_contracts/how_to_compile_contract) your contracts you can proceed to deploying them using aztec.js which is a Typescript client to interact with the sandbox. +Once you have [compiled](/guides/smart_contracts/how_to_compile_contract) your contracts you can proceed to deploying them using aztec.js which is a Typescript client to interact with the sandbox. ## Prerequisites -- `aztec-nargo` installed (go to [Sandbox and CLI section](/reference/reference/sandbox_reference) for installation instructions) -- contract artifacts ready (go to [How to Compile Contract](/guides/guides/smart_contracts/how_to_compile_contract) for instructions on how to compile contracts) -- Aztec Sandbox running (go to [Sandbox section](/getting_started/getting_started) for instructions on how to install and run the sandbox) +- `aztec-nargo` installed (go to [Sandbox and CLI section](/reference/sandbox_reference) for installation instructions) +- contract artifacts ready (go to [How to Compile Contract](/guides/smart_contracts/how_to_compile_contract) for instructions on how to compile contracts) +- Aztec Sandbox running (go to [Sandbox section](/getting_started) for instructions on how to install and run the sandbox) ## Deploy @@ -29,7 +29,7 @@ Generate the typescript class: aztec-builder ./aztec-nargo/output/target/path -o src/artifacts ``` -This would create a typescript file like `Example.ts` in `./src/artifacts`. Read more on the [compiling page](/guides/guides/smart_contracts/how_to_compile_contract). +This would create a typescript file like `Example.ts` in `./src/artifacts`. Read more on the [compiling page](/guides/smart_contracts/how_to_compile_contract). Now you can import it to easily deploy and interact with the contract. diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/_category_.json b/docs/docs/guides/smart_contracts/writing_contracts/_category_.json similarity index 100% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/_category_.json rename to docs/docs/guides/smart_contracts/writing_contracts/_category_.json diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/call_functions.md b/docs/docs/guides/smart_contracts/writing_contracts/call_functions.md similarity index 65% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/call_functions.md rename to docs/docs/guides/smart_contracts/writing_contracts/call_functions.md index dcf5c8d2dd4..c026447e3dd 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/call_functions.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/call_functions.md @@ -4,7 +4,7 @@ sidebar_position: 2 --- -A contract is a collection of persistent [state variables](/aztec/aztec/concepts/storage/index.md), and [functions](/aztec/aztec/concepts/smart_contracts/functions) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called. +A contract is a collection of persistent [state variables](/aztec/concepts/storage/index.md), and [functions](/aztec/concepts/smart_contracts/functions) which may manipulate these variables. Functions and state variables within a contract's scope are said to belong to that contract. A contract can only access and modify its own state. If a contract wishes to access or modify another contract's state, it must make a call to an external function of the other contract. For anything to happen on the Aztec network, an external function of a contract needs to be called. ### Contract @@ -37,4 +37,4 @@ Here's a common layout for a basic Aztec.nr Contract project: ``` - See the vanilla Noir docs for [more info on packages](https://noir-lang.org/docs/noir/modules_packages_crates/crates_and_packages). -- You can review the structure of a complete contract in the token contract tutorial [here](/tutorials/tutorials/contract_tutorials/token_contract.md). +- You can review the structure of a complete contract in the token contract tutorial [here](/tutorials/contract_tutorials/token_contract.md). diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/common_patterns/_category_.json b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/_category_.json similarity index 100% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/common_patterns/_category_.json rename to docs/docs/guides/smart_contracts/writing_contracts/common_patterns/_category_.json diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/authwit.md similarity index 96% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md rename to docs/docs/guides/smart_contracts/writing_contracts/common_patterns/authwit.md index 6840366384b..9a31c6de1a5 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/authwit.md @@ -5,13 +5,13 @@ description: Developer Documentation to use Authentication Witness for authentic ## Prerequisite reading -- [Authwit](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md) +- [Authwit](guides/smart_contracts/writing_contracts/common_patterns/authwit.md) ## Introduction Authentication Witness is a scheme for authentication actions on Aztec, so users can allow third-parties (eg protocols or other users) to execute an action on their behalf. -How it works logically is explained in the [concepts](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md) but we will do a short recap here. +How it works logically is explained in the [concepts](guides/smart_contracts/writing_contracts/common_patterns/authwit.md) but we will do a short recap here. An authentication witness is defined for a specific action, such as allowing a Defi protocol to transfer funds on behalf of the user. An action is here something that could be explained as `A is allowed to perform X operation on behalf of B` and we define it as a hash computed as such: @@ -82,7 +82,7 @@ Both return the value `0xabf64ad4` (`IS_VALID` selector) for a successful authen As part of [Aztec.nr](https://aztec.nr), we are providing a library that can be used to implement authentication witness for your contracts. -This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](/tutorials/tutorials/write_accounts_contract.md). +This library also provides a basis for account implementations such that these can more easily implement authentication witness. For more on the wallets, see [writing an account contract](/tutorials/write_accounts_contract.md). For our purposes here (not building a wallet), the most important part of the library is the `auth` utility which exposes a couple of helper methods for computing the action hash, retrieving witnesses, validating them and emitting the nullifier. @@ -163,7 +163,7 @@ With private functions covered, how can we use this in a public function? Well, Authenticating an action in the public domain is quite similar to the private domain, with the difference that we are executing a function on the account contract to add the witness, if you recall, this is because we don't have access to the oracle in the public domain. -In the snippet below, this is done as a separate contract call, but can also be done as part of a batch as mentioned in the [Accounts concepts](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md#what-about-public). +In the snippet below, this is done as a separate contract call, but can also be done as part of a batch as mentioned in the [Accounts concepts](guides/smart_contracts/writing_contracts/common_patterns/authwit.md#what-about-public). #include_code authwit_public_transfer_example /yarn-project/end-to-end/src/e2e_token_contract/transfer_public.test.ts typescript diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/common_patterns/index.md b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/index.md similarity index 93% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/common_patterns/index.md rename to docs/docs/guides/smart_contracts/writing_contracts/common_patterns/index.md index a09038acc4c..70490891197 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/common_patterns/index.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/common_patterns/index.md @@ -40,7 +40,7 @@ Note - you could also create a note and send it to the user. The problem is ther You can't read public storage in private domain. But nevertheless reading public storage is desirable. There are two ways to achieve the desired effect: -1. For public values that change infrequently, you can use [shared state](/reference/reference/smart_contract_reference/storage/shared_state.md). +1. For public values that change infrequently, you can use [shared state](/reference/smart_contract_reference/storage/shared_state.md). 1. You pass the data as a parameter to your private method and later assert in public that the data is correct. E.g.: @@ -82,13 +82,13 @@ Let's say you have some storage in public and want to move them into the private So you have to create a custom note in the public domain that is not encrypted by some owner - we call such notes a "TransparentNote" since it is created in public, anyone can see the amount and the note is not encrypted by some owner. -This pattern is discussed in detail in [writing a token contract section in the shield() method](/tutorials/tutorials/contract_tutorials/token_contract.md#redeem_shield). +This pattern is discussed in detail in [writing a token contract section in the shield() method](/tutorials/contract_tutorials/token_contract.md#redeem_shield). ### Discovering my notes -When you send someone a note, the note hash gets added to the [note hash tree](/aztec/aztec/concepts/storage/trees/index.md#note-hash-tree). To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes: +When you send someone a note, the note hash gets added to the [note hash tree](/aztec/concepts/storage/trees/index.md#note-hash-tree). To spend the note, the receiver needs to get the note itself (the note hash preimage). There are two ways you can get a hold of your notes: -1. When sending someone a note, use `emit_encrypted_log` (the function encrypts the log in such a way that only a recipient can decrypt it). PXE then tries to decrypt all the encrypted logs, and stores the successfully decrypted one. [More info here](/guides/guides/smart_contracts/writing_contracts/how_to_emit_event) +1. When sending someone a note, use `emit_encrypted_log` (the function encrypts the log in such a way that only a recipient can decrypt it). PXE then tries to decrypt all the encrypted logs, and stores the successfully decrypted one. [More info here](/guides/smart_contracts/writing_contracts/how_to_emit_event) 2. Manually using `pxe.addNote()` - If you choose to not emit logs to save gas or when creating a note in the public domain and want to consume it in private domain (`emit_encrypted_log` shouldn't be called in the public domain because everything is public), like in the previous section where we created a TransparentNote in public. #include_code pxe_add_note yarn-project/end-to-end/src/e2e_cheat_codes.test.ts typescript @@ -115,7 +115,7 @@ Hence, it's necessary to add a "randomness" field to your note to prevent such a ### L1 -- L2 interactions -Refer to [Token Portal tutorial on bridging tokens between L1 and L2](/tutorials/tutorials/contract_tutorials/advanced/token_bridge). This example shows how to: +Refer to [Token Portal tutorial on bridging tokens between L1 and L2](/tutorials/contract_tutorials/advanced/token_bridge). This example shows how to: 1. L1 -> L2 message flow 2. L2 -> L1 message flow @@ -151,6 +151,6 @@ PS: when calling from private to public, `msg_sender` is the contract address wh In the [Prevent the same user flow from happening twice using nullifier](#prevent-the-same-user-flow-from-happening-twice-using-nullifiers), we recommended using nullifiers. But what you put in the nullifier is also as important. -E.g. for a voting contract, if your nullifier simply emits just the `user_address`, then privacy can easily be leaked as nullifiers are deterministic (have no randomness), especially if there are few users of the contract. So you need some kind of randomness. You can add the user's secret key into the nullifier to add randomness. We call this "nullifier secrets" as explained [here](/aztec/aztec/concepts/accounts/keys.md#nullifier-secrets). E.g.: +E.g. for a voting contract, if your nullifier simply emits just the `user_address`, then privacy can easily be leaked as nullifiers are deterministic (have no randomness), especially if there are few users of the contract. So you need some kind of randomness. You can add the user's secret key into the nullifier to add randomness. We call this "nullifier secrets" as explained [here](/aztec/concepts/accounts/keys.md#nullifier-secrets). E.g.: #include_code nullifier /noir-projects/aztec-nr/value-note/src/value_note.nr rust diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/how_to_emit_event.md b/docs/docs/guides/smart_contracts/writing_contracts/how_to_emit_event.md similarity index 92% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/how_to_emit_event.md rename to docs/docs/guides/smart_contracts/writing_contracts/how_to_emit_event.md index 913497e3249..bd8f362bc8c 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/how_to_emit_event.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/how_to_emit_event.md @@ -25,7 +25,7 @@ Bellow are some ways how we could instantiate it after getting the information i #include_code instantiate-complete-address /yarn-project/circuits.js/src/structs/complete_address.test.ts rust -Then to register the recipient's [complete address](/aztec/aztec/concepts/accounts/keys.md#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](/aztec/aztec/core_components.md#aztecjs): +Then to register the recipient's [complete address](/aztec/concepts/accounts/keys.md#complete-address) in PXE we would call `registerRecipient` PXE endpoint using [Aztec.js](/aztec/core_components.md#aztecjs): #include_code register-recipient /yarn-project/aztec.js/src/wallet/create_recipient.ts rust @@ -60,7 +60,7 @@ They can be emitted by both public and private functions. :::danger - Emitting unencrypted events from private function is a significant privacy leak and it should be considered by the developer whether it is acceptable. -- Unencrypted events are currently **NOT** linked to the contract emitting them, so it is practically a [`debug_log`](/aztec/aztec/concepts/smart_contracts/oracles/index.md#a-few-useful-inbuilt-oracles). +- Unencrypted events are currently **NOT** linked to the contract emitting them, so it is practically a [`debug_log`](/aztec/concepts/smart_contracts/oracles/index.md#a-few-useful-inbuilt-oracles). ::: diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md b/docs/docs/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md similarity index 100% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md rename to docs/docs/guides/smart_contracts/writing_contracts/how_to_pop_capsules.md diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/how_to_prove_history.md b/docs/docs/guides/smart_contracts/writing_contracts/how_to_prove_history.md similarity index 91% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/how_to_prove_history.md rename to docs/docs/guides/smart_contracts/writing_contracts/how_to_prove_history.md index 0cd59d451f1..c6fbd2c2e16 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/how_to_prove_history.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/how_to_prove_history.md @@ -3,9 +3,9 @@ title: Using the Archive Tree sidebar_position: 4 --- -The Aztec Protocol uses an append-only Merkle tree to store hashes of the headers of all previous blocks in the chain as its leaves. This is known as an archive tree. You can learn more about how it works in the [concepts section](/aztec/aztec/concepts/storage/trees/index.md#archive-tree). +The Aztec Protocol uses an append-only Merkle tree to store hashes of the headers of all previous blocks in the chain as its leaves. This is known as an archive tree. You can learn more about how it works in the [concepts section](/aztec/concepts/storage/trees/index.md#archive-tree). -View the History lib reference [here](/reference/reference/smart_contract_reference/history_lib_reference.md). +View the History lib reference [here](/reference/smart_contract_reference/history_lib_reference.md). # History library @@ -30,7 +30,7 @@ Using this library, you can check that specific notes or nullifiers were part of - Prove a note was included in a specified block - Create a nullifier and prove it was not included in a specified block -For a more extensive reference, go to [the reference page](/reference/reference/smart_contract_reference/history_lib_reference.md). +For a more extensive reference, go to [the reference page](/reference/smart_contract_reference/history_lib_reference.md). ## 1. Import the `history` library from `aztec` @@ -98,4 +98,4 @@ You can also prove that a nullifier was not included in a specified block by usi ## Prove contract inclusion, public value inclusion, and use current state in lookups -To see what else you can do with the `history` library, check out the [reference](/reference/reference/smart_contract_reference/history_lib_reference.md). +To see what else you can do with the `history` library, check out the [reference](/reference/smart_contract_reference/history_lib_reference.md). diff --git a/docs/docs/guides/smart_contracts/writing_contracts/index.md b/docs/docs/guides/smart_contracts/writing_contracts/index.md new file mode 100644 index 00000000000..2c857ff0af3 --- /dev/null +++ b/docs/docs/guides/smart_contracts/writing_contracts/index.md @@ -0,0 +1,7 @@ +--- +title: Portals +--- + +A portal is a point of contact between L1 and a contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2. + +As outlined in [Communication](/protocol-specs/l1-smart-contracts/index.md), an Aztec L2 contract does not have to be linked to a portal contract, but can specify an intended portal in storage. Note, that a portal doesn't actually need to be a contract, it could be any address on L1. diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/initializers.md b/docs/docs/guides/smart_contracts/writing_contracts/initializers.md similarity index 94% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/initializers.md rename to docs/docs/guides/smart_contracts/writing_contracts/initializers.md index 7c15e051fd1..3c0194132e2 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/initializers.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/initializers.md @@ -27,4 +27,4 @@ Initializers are commonly used to set an admin, such as this example: Here, the initializer is calling a public function. It can also call a private function. Learn more about calling functions from functions [here](./call_functions.md). -To see constructors in action, check out the [Aztec.nr getting started guide](/getting_started/getting_started/aztecnr-getting-started.md). +To see constructors in action, check out the [Aztec.nr getting started guide](/getting_started/aztecnr-getting-started.md). diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/portals/_category_.json b/docs/docs/guides/smart_contracts/writing_contracts/portals/_category_.json similarity index 100% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/portals/_category_.json rename to docs/docs/guides/smart_contracts/writing_contracts/portals/_category_.json diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md b/docs/docs/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md similarity index 97% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md rename to docs/docs/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md index 31ef4735f7c..027b1740b82 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md @@ -2,9 +2,9 @@ title: Communicating with L1 --- -Is this your first time hearing the word `Portal`? Check out the [concepts section](../../../../../protocol-specs/l1-smart-contracts/index.md). +Is this your first time hearing the word `Portal`? Check out the [concepts section](../../../../protocol-specs/l1-smart-contracts/index.md). -Follow the [token bridge tutorial](/tutorials/tutorials/contract_tutorials/advanced/token_bridge) for hands-on experience writing and deploying a Portal contract. +Follow the [token bridge tutorial](/tutorials/contract_tutorials/advanced/token_bridge) for hands-on experience writing and deploying a Portal contract. ## Passing data to the rollup @@ -42,7 +42,7 @@ Note that while the `secret` and the `content` are both hashed, they are actuall ### Token bridge example -Computing the `content` must currently be done manually, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example](../../../../../tutorials/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md#consume-the-l1-message). +Computing the `content` must currently be done manually, as we are still adding a number of bytes utilities. A good example exists within the [Token bridge example](/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md#consume-the-l1-message). #include_code claim_public /noir-projects/noir-contracts/contracts/token_bridge_contract/src/main.nr rust diff --git a/docs/docs/guides/smart_contracts/writing_contracts/portals/index.md b/docs/docs/guides/smart_contracts/writing_contracts/portals/index.md new file mode 100644 index 00000000000..ddf0bfeb784 --- /dev/null +++ b/docs/docs/guides/smart_contracts/writing_contracts/portals/index.md @@ -0,0 +1,5 @@ +--- +title: Portals +--- + +A portal is a point of contact between L1 and a contract on Aztec. For applications such as token bridges, this is the point where the tokens are held on L1 while used in L2. Note, that a portal doesn't actually need to be a contract, it could be any address on L1. diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/storage/_category_.json b/docs/docs/guides/smart_contracts/writing_contracts/storage/_category_.json similarity index 100% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/storage/_category_.json rename to docs/docs/guides/smart_contracts/writing_contracts/storage/_category_.json diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/storage/index.md b/docs/docs/guides/smart_contracts/writing_contracts/storage/index.md similarity index 75% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/storage/index.md rename to docs/docs/guides/smart_contracts/writing_contracts/storage/index.md index f6cc58cac40..7198612356d 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/storage/index.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/storage/index.md @@ -4,9 +4,9 @@ title: Defining Storage On this page, you will learn how to define storage in your smart contract. -To learn more about how storage works in Aztec, read [the concepts](/guides/guides/smart_contracts/writing_contracts/storage/storage_slots). +To learn more about how storage works in Aztec, read [the concepts](/guides/smart_contracts/writing_contracts/storage/storage_slots). -[See the storage reference](/aztec/aztec/concepts/storage/index.md). +[See the storage reference](/aztec/concepts/storage/index.md). ```rust #[aztec(storage)] diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/storage/notes.md b/docs/docs/guides/smart_contracts/writing_contracts/storage/notes.md similarity index 92% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/storage/notes.md rename to docs/docs/guides/smart_contracts/writing_contracts/storage/notes.md index da2a8e82fe6..41f93939383 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/storage/notes.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/storage/notes.md @@ -19,7 +19,7 @@ This page will focus on how private variables are implemented with Notes and sto #### Side-note about execution Under the hood, the Aztec protocol handles some important details around public and private function calls. Calls between them are asynchronous due to different execution contexts (local execution vs. node execution). -A detailed explanation of the transaction lifecycle can be found [here](/aztec/aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle). +A detailed explanation of the transaction lifecycle can be found [here](/aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle). ## Private state variables in Aztec State variables in an Aztec contract are defined inside a struct specifically named `Storage`, and must satisfy the [Note Interface](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/aztec-nr/aztec/src/note/note_interface.nr) and contain a [Note header](https://github.com/AztecProtocol/aztec-packages/tree/#include_aztec_version/noir-projects/aztec-nr/aztec/src/note/note_header.nr). @@ -29,7 +29,7 @@ The Note header struct contains the contract address which the value is effectiv A couple of things to unpack here: #### Storage "slot" -Storage slots are more literal for public storage, a place where a value is stored. For private storage, a storage slot is logical (more [here](/aztec/aztec/concepts/storage/index.md#private-state-slots---slots-arent-real)). +Storage slots are more literal for public storage, a place where a value is stored. For private storage, a storage slot is logical (more [here](/aztec/concepts/storage/index.md#private-state-slots---slots-arent-real)). #### Silos The address of the contract is included in a Note's data to ensure that different contracts don't arrive at the same hash with an identical variable. This is handled in the protocol's execution. @@ -69,9 +69,9 @@ To update a value, its previous note hash(es) are nullified. The new note value ## Supplementary components Some optional background resources on notes can be found here: -- [High level network architecture](/aztec/aztec/core_components.md#high-level-network-architecture), specifically the Private Execution Environment -- [Transaction lifecycle (simple diagram)](/aztec/aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle) -- [Public and Private state](/aztec/aztec/concepts/state_model) +- [High level network architecture](/aztec/core_components.md#high-level-network-architecture), specifically the Private Execution Environment +- [Transaction lifecycle (simple diagram)](/aztec/concepts/transactions.md#simple-example-of-the-private-transaction-lifecycle) +- [Public and Private state](/aztec/concepts/state_model) Notes touch several core components of the protocol, but we will focus on a the essentials first. @@ -126,10 +126,10 @@ Notice how the `add` function shows the simplicity of appending a new note to al ----- ### Apply -Try the [Token tutorial](/tutorials/tutorials/contract_tutorials/token_contract.md) to see what notes can achieve. In this section you will also find other tutorials using notes in different ways. +Try the [Token tutorial](/tutorials/contract_tutorials/token_contract.md) to see what notes can achieve. In this section you will also find other tutorials using notes in different ways. ### Further reading -- [Storage Trees](/aztec/aztec/concepts/storage/trees) +- [Storage Trees](/aztec/concepts/storage/trees) - [Proof of prior notes](../how_to_prove_history.md) - public/private reading of public/private proof of state (public or private) If you're curious about any of the following related topics, search the documentation for... diff --git a/docs/docs/guides/guides/smart_contracts/writing_contracts/storage/storage_slots.md b/docs/docs/guides/smart_contracts/writing_contracts/storage/storage_slots.md similarity index 89% rename from docs/docs/guides/guides/smart_contracts/writing_contracts/storage/storage_slots.md rename to docs/docs/guides/smart_contracts/writing_contracts/storage/storage_slots.md index ef53ad1b77d..32881114bd5 100644 --- a/docs/docs/guides/guides/smart_contracts/writing_contracts/storage/storage_slots.md +++ b/docs/docs/guides/smart_contracts/writing_contracts/storage/storage_slots.md @@ -2,7 +2,7 @@ title: Storage slots --- -From the description of storage slots [in the Concepts](/guides/guides/smart_contracts/writing_contracts/storage/storage_slots) you will get an idea around the logic of storage slots. In this section we will go into more detail and walk through an entire example of how storage slots are computed for private state to improve our storage slot intuition. Recall, that storage slots in the private domain is just a logical construct, and are not "actually" used for lookups, but rather just as a value to constrain against. +From the description of storage slots [in the Concepts](/guides/smart_contracts/writing_contracts/storage/storage_slots) you will get an idea around the logic of storage slots. In this section we will go into more detail and walk through an entire example of how storage slots are computed for private state to improve our storage slot intuition. Recall, that storage slots in the private domain is just a logical construct, and are not "actually" used for lookups, but rather just as a value to constrain against. For the case of the example, we will look at what is inserted into the note hashes tree when adding a note in the Token contract. Specifically, we are looking at the last part of the `transfer` function: diff --git a/docs/docs/index.mdx b/docs/docs/index.mdx index 1957686f36e..db92b85619e 100644 --- a/docs/docs/index.mdx +++ b/docs/docs/index.mdx @@ -36,11 +36,11 @@ Aztec is: ### Learn 📚 -Start on the [Technical Overview page](/aztec/aztec/core_components) to read about how Aztec works. +Start on the [Technical Overview page](/aztec/core_components) to read about how Aztec works. ### Build 🧑‍💻 -Go to the [Getting Started section](/getting_started/getting_started) of the developer docs to get your hands dirty and start developing on Aztec. +Go to the [Getting Started section](/getting_started) of the developer docs to get your hands dirty and start developing on Aztec. #### Go deeper 🔬 @@ -48,4 +48,4 @@ Check out the [Awesome Aztec repo](https://github.com/AztecProtocol/awesome-azte Clone the [Aztec Starter repo](https://github.com/AztecProtocol/aztec-starter) to get a minimal project set up with Sandbox (local developer network), a simple contract and a test suite. -Jump into one of the [tutorials](/tutorials/tutorials/contract_tutorials/private_voting_contract.md) to learn how to build more complex applications on Aztec. +Jump into one of the [tutorials](/tutorials/contract_tutorials/private_voting_contract.md) to learn how to build more complex applications on Aztec. diff --git a/docs/docs/protocol-specs/cryptography/hashing/hashing.md b/docs/docs/protocol-specs/cryptography/hashing/hashing.md index 80a3bed1129..f1773cb63fd 100644 --- a/docs/docs/protocol-specs/cryptography/hashing/hashing.md +++ b/docs/docs/protocol-specs/cryptography/hashing/hashing.md @@ -14,7 +14,7 @@ To minimize the potential for collisions between distinct hashing contexts, all In the case of using Poseidon2 for hashing (which is the case for most hashing in the Aztec protocol), the string is converted from a big-endian byte representation into a `Field` element, and passed as a first argument into the hash. In the case of using non-algebraic hash functions (such as sha256), the string is converted from a big-endian byte representation into bits, and passed as the first bits into the hash. These details are conveyed more clearly as pseudocode in the relevant sections of the spec. -For some hashes there is further domain-separation. For example, [Merkle tree hashing](/aztec/aztec/concepts/storage/trees/index.md#layers) of the tree. +For some hashes there is further domain-separation. For example, [Merkle tree hashing](/aztec/concepts/storage/trees/index.md#layers) of the tree. ### Pseudo-randomness @@ -24,6 +24,6 @@ Pseudo-randomness is required in cases such as: - Fiat-Shamir challenge generation. - Expanding a random seed to generate additional randomness. - - See the derivation of [master secret keys](/aztec/aztec/concepts/accounts/keys.md#master-keys). + - See the derivation of [master secret keys](/aztec/concepts/accounts/keys.md#master-keys). - Deriving a nullifier, and siloing a nullifier. - - See [deriving a nullifier](/aztec/aztec/concepts/accounts/keys.md#deriving-a-nullifier-within-an-app-contract). + - See [deriving a nullifier](/aztec/concepts/accounts/keys.md#deriving-a-nullifier-within-an-app-contract). diff --git a/docs/docs/protocol-specs/state/tree-implementations.md b/docs/docs/protocol-specs/state/tree-implementations.md index 03f3657e95d..ec15a26fe1b 100644 --- a/docs/docs/protocol-specs/state/tree-implementations.md +++ b/docs/docs/protocol-specs/state/tree-implementations.md @@ -14,7 +14,7 @@ Indexed Merkle trees, introduced [here](https://eprint.iacr.org/2021/1263.pdf), With an Indexed Merkle tree, proving non-membership of a value `x` then requires a membership proof of the node with value lower than `x` and a next-highest value greater than `x`. The cost of this proof is proportional to the height of the tree, which can be set according to the expected number of elements to be stored in the tree. For comparison, a non-membership proof in a sparse tree requires a tree with height proportional to the size of the elements, so when working with 256-bit elements, 256 hashes are required for a proof. -Refer to [this page](/aztec/aztec/concepts/storage/trees/indexed_merkle_tree) for more details on how insertions, updates, and membership proofs are executed on an Indexed Merkle tree. +Refer to [this page](/aztec/concepts/storage/trees/indexed_merkle_tree) for more details on how insertions, updates, and membership proofs are executed on an Indexed Merkle tree. diff --git a/docs/docs/reference/reference/common_errors/_category_.json b/docs/docs/reference/common_errors/_category_.json similarity index 100% rename from docs/docs/reference/reference/common_errors/_category_.json rename to docs/docs/reference/common_errors/_category_.json diff --git a/docs/docs/reference/reference/common_errors/aztecnr-errors.md b/docs/docs/reference/common_errors/aztecnr-errors.md similarity index 92% rename from docs/docs/reference/reference/common_errors/aztecnr-errors.md rename to docs/docs/reference/common_errors/aztecnr-errors.md index dc0a9bf6510..71028ba9429 100644 --- a/docs/docs/reference/reference/common_errors/aztecnr-errors.md +++ b/docs/docs/reference/common_errors/aztecnr-errors.md @@ -12,11 +12,11 @@ All smart contracts written in Aztec.nr need the `aztec` dependency. In your `Na aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="noir-projects/aztec-nr/aztec" } ``` -You can learn more about dependencies and their paths [here](/reference/reference/smart_contract_reference/dependencies.md). +You can learn more about dependencies and their paths [here](/reference/smart_contract_reference/dependencies.md). #### `backend has encountered an error` -This is likely due to a version mismatch or bad install of barretenberg. Try [reinstalling nargo](guides/guides/local_env/versions-updating.md#updating) or uninstalling barretenberg: +This is likely due to a version mismatch or bad install of barretenberg. Try [reinstalling nargo](guides/local_env/versions-updating.md#updating) or uninstalling barretenberg: ```bash nargo backend uninstall acvm-backend-barretenberg @@ -26,7 +26,7 @@ It will then reinstall when you compile. #### `Oracle callback {} not found` & `Oracle callback pedersenHash not found` -This can occasionally happen when there are breaking releases. Make sure that your dependencies in `Nargo.toml` are [updated to the latest release](/reference/reference/smart_contract_reference/dependencies.md). +This can occasionally happen when there are breaking releases. Make sure that your dependencies in `Nargo.toml` are [updated to the latest release](/reference/smart_contract_reference/dependencies.md). #### `error: Failed constraint: 'Public state writes only supported in public functions` @@ -47,7 +47,7 @@ This error occurs when you are trying to interact with a smart contract via an P To execute a transaction, the PXE needs to know the complete address of a contract and contract artifacts. -To address the error, add the contract to the PXE by calling [`pxe.addContracts(...)`](/aztec/aztec/concepts/pxe/index.md#addcontracts). +To address the error, add the contract to the PXE by calling [`pxe.addContracts(...)`](/aztec/concepts/pxe/index.md#addcontracts). #### `Simulation error: No public key registered for address 0x0. Register it by calling pxe.registerRecipient(...) or pxe.registerAccount(...)` diff --git a/docs/docs/reference/reference/common_errors/sandbox-errors.md b/docs/docs/reference/common_errors/sandbox-errors.md similarity index 89% rename from docs/docs/reference/reference/common_errors/sandbox-errors.md rename to docs/docs/reference/common_errors/sandbox-errors.md index 873b5de2db2..3ab918c7ac9 100644 --- a/docs/docs/reference/reference/common_errors/sandbox-errors.md +++ b/docs/docs/reference/common_errors/sandbox-errors.md @@ -2,7 +2,7 @@ title: Aztec Sandbox Errors --- -import Disclaimer from '../../../../src/components/Disclaimers/\_wip_disclaimer.mdx'; +import Disclaimer from '@site/src/components/Disclaimers/\_wip_disclaimer.mdx'; @@ -14,7 +14,7 @@ This section contains a list of errors you may encounter when using Aztec Sandbo ### Kernel Circuits -We have several versions of public and private kernels as explained in [our circuits section](/aztec/aztec/concepts/circuits). Certain things are only possible in certain versions of the circuits. So always ensure that the right version is being used for proof generation. For example, there is a specific version of the public kernel that only works if the previous kernel iteration was a private kernel. Similarly there is one that only works if the previous kernel was public. +We have several versions of public and private kernels as explained in [our circuits section](/aztec/concepts/circuits). Certain things are only possible in certain versions of the circuits. So always ensure that the right version is being used for proof generation. For example, there is a specific version of the public kernel that only works if the previous kernel iteration was a private kernel. Similarly there is one that only works if the previous kernel was public. Remember that for each function call (i.e. each item in the call stack), there is a new kernel iteration that gets run. @@ -87,7 +87,7 @@ Calling a private Aztec.nr function in a public kernel is not allowed. #### 3005 - PUBLIC_KERNEL\_\_NON_EMPTY_PRIVATE_CALL_STACK -Public functions are executed after all the private functions are (see [private-public execution](/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md)). As such, private call stack must be empty when executing in the public kernel. +Public functions are executed after all the private functions are (see [private-public execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md)). As such, private call stack must be empty when executing in the public kernel. #### 3011 - PUBLIC_KERNEL\_\_CALCULATED_PRIVATE_CALL_HASH_AND_PROVIDED_PRIVATE_CALL_HASH_MISMATCH @@ -131,7 +131,7 @@ For static calls, no new note hashes or nullifiers can be added to the state. ### Rollup circuit errors -These are errors that occur when kernel proofs (transaction proofs) are sent to the rollup circuits to create an L2 block. See [rollup circuits](/aztec/aztec/concepts/circuits) for more information. +These are errors that occur when kernel proofs (transaction proofs) are sent to the rollup circuits to create an L2 block. See [rollup circuits](/aztec/concepts/circuits) for more information. #### 4007 - BASE\_\_INVALID_CHAIN_ID @@ -141,7 +141,7 @@ The L1 chain ID you used in your proof generation (for your private transaction) Same as [section 4007](#4007---base__invalid_chain_id) except the `version` refers to the version of the Aztec L2 instance. -Some scary bugs like `4003 - BASE__INVALID_NULLIFIER_SUBTREE` and `4004 - BASE__INVALID_NULLIFIER_RANGE` which are to do malformed nullifier trees (see [Indexed Merkle Trees](/aztec/aztec/concepts/storage/trees/indexed_merkle_tree)) etc may seem unrelated at a glance, but at a closer look may be because of some bug in an application's Aztec.nr code. Same is true for certain instances of `7008 - MEMBERSHIP_CHECK_FAILED`. +Some scary bugs like `4003 - BASE__INVALID_NULLIFIER_SUBTREE` and `4004 - BASE__INVALID_NULLIFIER_RANGE` which are to do malformed nullifier trees (see [Indexed Merkle Trees](/aztec/concepts/storage/trees/indexed_merkle_tree)) etc may seem unrelated at a glance, but at a closer look may be because of some bug in an application's Aztec.nr code. Same is true for certain instances of `7008 - MEMBERSHIP_CHECK_FAILED`. ### Generic circuit errors @@ -172,7 +172,7 @@ Users may create a proof against a historical state in Aztec. The rollup circuit - using invalid historical L1 to L2 message data tree state - inserting a subtree into the greater tree - we make a smaller merkle tree of all the new note hashes/nullifiers etc that were created in a transaction or in a rollup and add it to the bigger state tree. Before inserting, we do a merkle membership check to ensure that the index to insert at is indeed an empty subtree (otherwise we would be overwriting state). This can happen when `next_available_leaf_index` in the state tree's snapshot is wrong (it is fetched by the sequencer from the archiver). The error message should reveal which tree is causing this issue - - nullifier tree related errors - The nullifier tree uses an [Indexed Merkle Tree](/aztec/aztec/concepts/storage/trees/indexed_merkle_tree). It requires additional data from the archiver to know which is the nullifier in the tree that is just below the current nullifier before it can perform batch insertion. If the low nullifier is wrong, or the nullifier is in incorrect range, you may receive this error. + - nullifier tree related errors - The nullifier tree uses an [Indexed Merkle Tree](/aztec/concepts/storage/trees/indexed_merkle_tree). It requires additional data from the archiver to know which is the nullifier in the tree that is just below the current nullifier before it can perform batch insertion. If the low nullifier is wrong, or the nullifier is in incorrect range, you may receive this error. --- @@ -190,7 +190,7 @@ Users may create a proof against a historical state in Aztec. The rollup circuit - "\$\{treeName\} tree next available leaf index mismatch" - validating a tree's root is not enough. It also checks that the `next_available_leaf_index` is as expected. This is the next index we can insert new values into. Note that for the public data tree, this test is skipped since as it is a sparse tree unlike the others. -- "Public call stack size exceeded" - In Aztec, the sequencer executes all enqueued public functions in a transaction (to prevent race conditions - see [private-public execution](/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md)). This error says there are too many public functions requested. +- "Public call stack size exceeded" - In Aztec, the sequencer executes all enqueued public functions in a transaction (to prevent race conditions - see [private-public execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md)). This error says there are too many public functions requested. - "Array size exceeds target length" - happens if you add more items than allowed by the constants set due to our circuit limitations (eg sending too many L2 to L1 messages or creating a function that exceeds the call stack length or returns more values than what Aztec.nr functions allow) diff --git a/docs/docs/reference/reference/debugging.md b/docs/docs/reference/debugging.md similarity index 100% rename from docs/docs/reference/reference/debugging.md rename to docs/docs/reference/debugging.md diff --git a/docs/docs/reference/reference/privacy_considerations.md b/docs/docs/reference/privacy_considerations.md similarity index 98% rename from docs/docs/reference/reference/privacy_considerations.md rename to docs/docs/reference/privacy_considerations.md index 0b0af36def6..7198d90df1d 100644 --- a/docs/docs/reference/reference/privacy_considerations.md +++ b/docs/docs/reference/privacy_considerations.md @@ -52,7 +52,7 @@ Any time a private function makes a call to a public function, information is le ### Crossing the public -> private boundary -If a public function sends a message to be consumed by a private function, the act of consuming that message might be leaked if not following recommended patterns. See [here](/reference/reference/smart_contract_reference/portals/inbox.md) for more details. +If a public function sends a message to be consumed by a private function, the act of consuming that message might be leaked if not following recommended patterns. See [here](/reference/smart_contract_reference/portals/inbox.md) for more details. ### Timing of transactions diff --git a/docs/docs/reference/reference/_category_.json b/docs/docs/reference/reference/_category_.json deleted file mode 100644 index 31e9f9521da..00000000000 --- a/docs/docs/reference/reference/_category_.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "label": "Reference", - "position": 4, - "collapsible": true, - "collapsed": true -} diff --git a/docs/docs/reference/reference/sandbox_reference/_category_.json b/docs/docs/reference/sandbox_reference/_category_.json similarity index 100% rename from docs/docs/reference/reference/sandbox_reference/_category_.json rename to docs/docs/reference/sandbox_reference/_category_.json diff --git a/docs/docs/reference/reference/sandbox_reference/cheat_codes.md b/docs/docs/reference/sandbox_reference/cheat_codes.md similarity index 99% rename from docs/docs/reference/reference/sandbox_reference/cheat_codes.md rename to docs/docs/reference/sandbox_reference/cheat_codes.md index 2817c900f27..493690c7466 100644 --- a/docs/docs/reference/reference/sandbox_reference/cheat_codes.md +++ b/docs/docs/reference/sandbox_reference/cheat_codes.md @@ -1,7 +1,7 @@ --- title: Cheat Codes --- -import Disclaimer from "../../../../src/components/Disclaimers/\_wip_disclaimer.mdx"; +import Disclaimer from "@site/src/components/Disclaimers/\_wip_disclaimer.mdx"; ## Introduction diff --git a/docs/docs/reference/reference/sandbox_reference/index.md b/docs/docs/reference/sandbox_reference/index.md similarity index 93% rename from docs/docs/reference/reference/sandbox_reference/index.md rename to docs/docs/reference/sandbox_reference/index.md index 68e12b66849..c0a12814740 100644 --- a/docs/docs/reference/reference/sandbox_reference/index.md +++ b/docs/docs/reference/sandbox_reference/index.md @@ -10,7 +10,7 @@ Aztec's Layer 2 network is a fully programmable combined private/public ZK rollu - Aztec Node - Aggregates all of the 'backend' services necessary for the building and publishing of rollups. This package is currently in development and much of the functionality is mocked. - [Private Execution Environment (PXE)](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/pxe) - Normally residing with the end client, this decrypts and stores a client's private state, executes simulations and submits transactions to the Aztec Node. -- [Aztec.js](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/aztec.js) - Aztec's client library for interacting with the PXE (think Ethers.js). See the getting started guide [here](/getting_started/getting_started/aztecjs-getting-started.md). +- [Aztec.js](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/aztec.js) - Aztec's client library for interacting with the PXE (think Ethers.js). See the getting started guide [here](/getting_started/aztecjs-getting-started.md). All of this is included in the Sandbox, with the exception of Aztec.js which you can use to interact with it. @@ -34,4 +34,4 @@ The current sandbox does not generate or verify proofs, but provides a working e ## Command line tools -Aztec-nargo and aztec-builder are command-line tool allowing you to compile smart contracts. See the [compiling contracts](/guides/guides/smart_contracts/how_to_compile_contract) page for more information. +Aztec-nargo and aztec-builder are command-line tool allowing you to compile smart contracts. See the [compiling contracts](/guides/smart_contracts/how_to_compile_contract) page for more information. diff --git a/docs/docs/reference/reference/sandbox_reference/sandbox-reference.md b/docs/docs/reference/sandbox_reference/sandbox-reference.md similarity index 82% rename from docs/docs/reference/reference/sandbox_reference/sandbox-reference.md rename to docs/docs/reference/sandbox_reference/sandbox-reference.md index 52c31cd9d3a..c02d4a7988c 100644 --- a/docs/docs/reference/reference/sandbox_reference/sandbox-reference.md +++ b/docs/docs/reference/sandbox_reference/sandbox-reference.md @@ -4,13 +4,65 @@ title: Sandbox Reference :::tip -For a quick start, follow the [guide](/getting_started/getting_started) to install the sandbox. +For a quick start, follow the [guide](/getting_started.md) to install the sandbox. ::: ## Manual Install -You can manually install the sandbox via the underlying script used in the [Aztec Boxes](getting_started/getting_started/index.md#run-the-npx-script). + +You can manually install the sandbox via the underlying script used in the [Aztec Boxes](/getting_started.md#run-the-npx-script). + +### Prerequisites + +- Node.js >= v18 (recommend installing with [nvm](https://github.com/nvm-sh/nvm)) +- Docker (visit [this page of the Docker docs](https://docs.docker.com/get-docker/) on how to install it) + +### Install the sandbox + +To install the latest Sandbox version, run: + +```bash +bash -i <(curl -s install.aztec.network) +``` + +This will install the following tools: + +- **aztec** - launches various infrastructure subsystems (sequencer, prover, pxe, etc). +- **aztec-nargo** - aztec's build of nargo, the noir compiler toolchain. +- **aztec-sandbox** - a wrapper around docker-compose that launches services needed for sandbox testing. +- **aztec-up** - a tool to upgrade the aztec toolchain to the latest, or specific versions. +- **aztec-builder** - A useful tool for projects to generate ABIs and update their dependencies. + +Once these have been installed, to start the sandbox, run: + +```bash +aztec-sandbox +``` + +### Have fun! + +**Congratulations, you have just installed and run the Aztec Sandbox!** + +```bash + /\ | | + / \ ___| |_ ___ ___ + / /\ \ |_ / __/ _ \/ __| + / ____ \ / /| || __/ (__ + /_/___ \_\/___|\__\___|\___| + +``` + +In the terminal, you will see some logs: +1. Sandbox version +2. Contract addresses of rollup contracts +3. PXE (private execution environment) setup logs +4. Initial accounts that are shipped with the sandbox and can be used in tests + + +## Manual Install + +You can manually install the sandbox via the underlying script used in the [Aztec Boxes](getting_started.md#run-the-npx-script). ### Prerequisites @@ -67,7 +119,7 @@ If you wish to run components of the Aztec network stack separately, you can use aztec start --node [nodeOptions] --pxe [pxeOptions] --archiver [archiverOptions] --sequencer [sequencerOptions] --prover [proverOptions] ----p2p-bootstrap [p2pOptions] ``` -Starting the aztec node alongside a PXE, sequencer or archiver, will attach the components to the node.Eg if you want to run a PXE separately to a node, you can [read this guide](/aztec/aztec/concepts/pxe/index.md)/ +Starting the aztec node alongside a PXE, sequencer or archiver, will attach the components to the node.Eg if you want to run a PXE separately to a node, you can [read this guide](/aztec/concepts/pxe/index.md)/ ## Environment Variables @@ -165,7 +217,7 @@ To help with testing, the sandbox is shipped with a set of cheatcodes. Cheatcodes allow you to change the time of the Aztec block, load certain state or more easily manipulate Ethereum instead of having to write dedicated RPC calls to anvil or hardhat. -You can find the cheat code reference [here](/reference/reference/sandbox_reference/cheat_codes.md). +You can find the cheat code reference [here](/reference/sandbox_reference/cheat_codes.md). ## Contracts diff --git a/docs/docs/reference/reference/smart_contract_reference/_category_.json b/docs/docs/reference/smart_contract_reference/_category_.json similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/_category_.json rename to docs/docs/reference/smart_contract_reference/_category_.json diff --git a/docs/docs/reference/reference/smart_contract_reference/dependencies.md b/docs/docs/reference/smart_contract_reference/dependencies.md similarity index 92% rename from docs/docs/reference/reference/smart_contract_reference/dependencies.md rename to docs/docs/reference/smart_contract_reference/dependencies.md index 6b8f9510cab..39ca07ee85c 100644 --- a/docs/docs/reference/reference/smart_contract_reference/dependencies.md +++ b/docs/docs/reference/smart_contract_reference/dependencies.md @@ -19,7 +19,7 @@ This is the core Aztec library that is required for every Aztec.nr smart contrac authwit = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="noir-projects/aztec-nr/authwit"} ``` -This allows you to use authentication witnesses in your contract. Find more about its usage [here](guides/guides/smart_contracts/writing_contracts/common_patterns/authwit.md). +This allows you to use authentication witnesses in your contract. Find more about its usage [here](guides/smart_contracts/writing_contracts/common_patterns/authwit.md). ## Address note @@ -51,4 +51,4 @@ This library contains types that are used in the Aztec protocol. Find it on [Git value_note = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="noir-projects/aztec-nr/value-note" } ``` -This is a library for a note that stores one arbitrary value. You can see an example of how it might be used in the [token contract tutorial](/tutorials/tutorials/contract_tutorials/token_contract.md). +This is a library for a note that stores one arbitrary value. You can see an example of how it might be used in the [token contract tutorial](/tutorials/contract_tutorials/token_contract.md). diff --git a/docs/docs/reference/reference/smart_contract_reference/globals.md b/docs/docs/reference/smart_contract_reference/globals.md similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/globals.md rename to docs/docs/reference/smart_contract_reference/globals.md diff --git a/docs/docs/reference/reference/smart_contract_reference/history_lib_reference.md b/docs/docs/reference/smart_contract_reference/history_lib_reference.md similarity index 98% rename from docs/docs/reference/reference/smart_contract_reference/history_lib_reference.md rename to docs/docs/reference/smart_contract_reference/history_lib_reference.md index 86563bb7074..64f41b03086 100644 --- a/docs/docs/reference/reference/smart_contract_reference/history_lib_reference.md +++ b/docs/docs/reference/smart_contract_reference/history_lib_reference.md @@ -21,7 +21,7 @@ Note inclusion proves that a note existed (its hash was included in a note hash ## prove_note_commitment_inclusion -A **commitment**, also referred to as a **note hash** is a public acknowledgment of the existence of a note without revealing the content of the note. You can learn more about how to compress a note to a note hash [here](/aztec/aztec/concepts/storage/trees/index.md#example-note). +A **commitment**, also referred to as a **note hash** is a public acknowledgment of the existence of a note without revealing the content of the note. You can learn more about how to compress a note to a note hash [here](/aztec/concepts/storage/trees/index.md#example-note). `prove_note_commitment_inclusion` takes 2 parameters: diff --git a/docs/docs/reference/reference/smart_contract_reference/index.md b/docs/docs/reference/smart_contract_reference/index.md similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/index.md rename to docs/docs/reference/smart_contract_reference/index.md diff --git a/docs/docs/reference/reference/smart_contract_reference/portals/_category_.json b/docs/docs/reference/smart_contract_reference/portals/_category_.json similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/portals/_category_.json rename to docs/docs/reference/smart_contract_reference/portals/_category_.json diff --git a/docs/docs/reference/reference/smart_contract_reference/portals/data_structures.md b/docs/docs/reference/smart_contract_reference/portals/data_structures.md similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/portals/data_structures.md rename to docs/docs/reference/smart_contract_reference/portals/data_structures.md diff --git a/docs/docs/reference/reference/smart_contract_reference/portals/inbox.md b/docs/docs/reference/smart_contract_reference/portals/inbox.md similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/portals/inbox.md rename to docs/docs/reference/smart_contract_reference/portals/inbox.md diff --git a/docs/docs/reference/reference/smart_contract_reference/portals/outbox.md b/docs/docs/reference/smart_contract_reference/portals/outbox.md similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/portals/outbox.md rename to docs/docs/reference/smart_contract_reference/portals/outbox.md diff --git a/docs/docs/reference/reference/smart_contract_reference/portals/registry.md b/docs/docs/reference/smart_contract_reference/portals/registry.md similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/portals/registry.md rename to docs/docs/reference/smart_contract_reference/portals/registry.md diff --git a/docs/docs/reference/reference/smart_contract_reference/storage/_category_.json b/docs/docs/reference/smart_contract_reference/storage/_category_.json similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/storage/_category_.json rename to docs/docs/reference/smart_contract_reference/storage/_category_.json diff --git a/docs/docs/reference/reference/smart_contract_reference/storage/index.md b/docs/docs/reference/smart_contract_reference/storage/index.md similarity index 81% rename from docs/docs/reference/reference/smart_contract_reference/storage/index.md rename to docs/docs/reference/smart_contract_reference/storage/index.md index 267b71f8b08..8e8cfb0472d 100644 --- a/docs/docs/reference/reference/smart_contract_reference/storage/index.md +++ b/docs/docs/reference/smart_contract_reference/storage/index.md @@ -4,8 +4,8 @@ title: Storage Smart contracts rely on storage, acting as the persistent memory on the blockchain. In Aztec, because of its hybrid, privacy-first architecture, the management of this storage is more complex than other blockchains like Ethereum. -To learn how to define a storage struct, read [this guide](/guides/guides/smart_contracts/writing_contracts/storage). -To learn more about storage slots, read [this explainer](/guides/guides/smart_contracts/writing_contracts/storage/storage_slots). +To learn how to define a storage struct, read [this guide](/guides/smart_contracts/writing_contracts/storage). +To learn more about storage slots, read [this explainer](/guides/smart_contracts/writing_contracts/storage/storage_slots). You control this storage in Aztec using a struct annotated with `#[aztec(storage)]`. This struct serves as the housing unit for all your smart contract's state variables - the data it needs to keep track of and maintain. @@ -26,7 +26,7 @@ On this and the following pages in this section, you’ll learn: Public state variables can be read by anyone, while private state variables can only be read by their owner (or people whom the owner has shared the decrypted data or note viewing key with). -Public state follows the Ethereum style account model, where each contract has its own key-value datastore. Private state follows a UTXO model, where note contents (/aztec/aztec/concepts/state_model/index.md) and [private/public execution](/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md)) for more background. +Public state follows the Ethereum style account model, where each contract has its own key-value datastore. Private state follows a UTXO model, where note contents (/aztec/aztec/concepts/state_model/index.md) and [private/public execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md)) for more background. ## Storage struct @@ -46,7 +46,7 @@ A `map` is a state variable that "maps" a key to a value. It can be used with pr In Aztec.nr, keys are always `Field`s, or types that can be serialized as Fields, and values can be any type - even other maps. `Field`s are finite field elements, but you can think of them as integers. ::: -It includes a [`Context`](/aztec/aztec/concepts/smart_contracts/functions/context) to specify the private or public domain, a `storage_slot` to specify where in storage the map is stored, and a `start_var_constructor` which tells the map how it should operate on the underlying type. This includes how to serialize and deserialize the type, as well as how commitments and nullifiers are computed for the type if it's private. +It includes a [`Context`](/aztec/concepts/smart_contracts/functions/context) to specify the private or public domain, a `storage_slot` to specify where in storage the map is stored, and a `start_var_constructor` which tells the map how it should operate on the underlying type. This includes how to serialize and deserialize the type, as well as how commitments and nullifiers are computed for the type if it's private. You can view the implementation in the Aztec.nr library [here](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/aztec-nr). @@ -54,7 +54,7 @@ You can have multiple `map`s in your contract that each have a different underly ### `new` -When declaring the storage for a map, we use the `Map::new()` constructor. As seen below, this takes the `storage_slot` and the `start_var_constructor` along with the [`Context`](/aztec/aztec/concepts/smart_contracts/functions/context). +When declaring the storage for a map, we use the `Map::new()` constructor. As seen below, this takes the `storage_slot` and the `start_var_constructor` along with the [`Context`](/aztec/concepts/smart_contracts/functions/context). We will see examples of map constructors for public and private variables in later sections. @@ -94,6 +94,6 @@ require(minters[msg.sender], "caller is not minter"); ## Concepts mentioned -- [State Model](/aztec/aztec/concepts/state_model/index.md) -- [Public-private execution](/aztec/aztec/concepts/smart_contracts/communication/public_private_calls.md) -- [Function Contexts](/aztec/aztec/concepts/smart_contracts/functions/context) +- [State Model](/aztec/concepts/state_model/index.md) +- [Public-private execution](/aztec/concepts/smart_contracts/communication/public_private_calls.md) +- [Function Contexts](/aztec/concepts/smart_contracts/functions/context) diff --git a/docs/docs/reference/reference/smart_contract_reference/storage/private_state.md b/docs/docs/reference/smart_contract_reference/storage/private_state.md similarity index 96% rename from docs/docs/reference/reference/smart_contract_reference/storage/private_state.md rename to docs/docs/reference/smart_contract_reference/storage/private_state.md index f1c3619899d..bed799ff641 100644 --- a/docs/docs/reference/reference/smart_contract_reference/storage/private_state.md +++ b/docs/docs/reference/smart_contract_reference/storage/private_state.md @@ -4,15 +4,15 @@ title: Private State On this page we will look at how to manage private state in Aztec contracts. We will look at how to declare private state, how to read and write to it, and how to use it in your contracts. -For a higher level overview of the state model in Aztec, see the [hybrid state model](/aztec/aztec/concepts/state_model/index.md) page. +For a higher level overview of the state model in Aztec, see the [hybrid state model](/aztec/concepts/state_model/index.md) page. ## Overview In contrast to public state, private state is persistent state that is **not** visible to the whole world. Depending on the logic of the smart contract, a private state variable's current value will only be known to one entity, or a closed group of entities. -The value of a private state variable can either be shared via an [encrypted log](/guides/guides/smart_contracts/writing_contracts/how_to_emit_event#encrypted-events), or offchain via web2, or completely offline: it's up to the app developer. +The value of a private state variable can either be shared via an [encrypted log](/guides/smart_contracts/writing_contracts/how_to_emit_event#encrypted-events), or offchain via web2, or completely offline: it's up to the app developer. -Aztec private state follows a [utxo](https://en.wikipedia.org/wiki/Unspent_transaction_output)-based model. That is, a private state's current value is represented as one or many [notes](/aztec/aztec/concepts/storage/trees/index.md). +Aztec private state follows a [utxo](https://en.wikipedia.org/wiki/Unspent_transaction_output)-based model. That is, a private state's current value is represented as one or many [notes](/aztec/concepts/storage/trees/index.md). To greatly simplify the experience of writing private state, Aztec.nr provides three different types of private state variable: @@ -184,7 +184,7 @@ Functionally similar to `get_note`, but executed unconstrained and can be used b You can view the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/state_vars/set.nr). -And can be added to the `Storage` struct as follows. Here adding a set for a custom note, the TransparentNote (useful for [public -> private communication](/guides/guides/smart_contracts/writing_contracts/call_functions.md). +And can be added to the `Storage` struct as follows. Here adding a set for a custom note, the TransparentNote (useful for [public -> private communication](/guides/smart_contracts/writing_contracts/call_functions.md). #include_code storage-set-declaration /noir-projects/noir-contracts/contracts/docs_example_contract/src/main.nr rust @@ -200,13 +200,13 @@ We can initialize the set as follows: Allows us to modify the storage by inserting a note into the `PrivateSet`. -A hash of the note will be generated, and inserted into the note hash tree, allowing us to later use in contract interactions. Recall that the content of the note should be shared with the owner to allow them to use it, as mentioned this can be done via an [encrypted log](/guides/guides/smart_contracts/writing_contracts/how_to_emit_event#encrypted-events), or offchain via web2, or completely offline. +A hash of the note will be generated, and inserted into the note hash tree, allowing us to later use in contract interactions. Recall that the content of the note should be shared with the owner to allow them to use it, as mentioned this can be done via an [encrypted log](/guides/smart_contracts/writing_contracts/how_to_emit_event#encrypted-events), or offchain via web2, or completely offline. #include_code insert /noir-projects/aztec-nr/easy-private-state/src/easy_private_uint.nr rust ### `insert_from_public` -The `insert_from_public` allow public function to insert notes into private storage. This is very useful when we want to support private function calls that have been initiated in public, such as shielding in the [example token contract](/tutorials/tutorials/contract_tutorials/token_contract.md#shield). +The `insert_from_public` allow public function to insert notes into private storage. This is very useful when we want to support private function calls that have been initiated in public, such as shielding in the [example token contract](/tutorials/contract_tutorials/token_contract.md#shield). The usage is similar to using the `insert` method with the difference that this one is called in public functions. @@ -248,7 +248,7 @@ This function requires a `NoteViewerOptions`. The `NoteViewerOptions` is essenti ## `NoteGetterOptions` -`NoteGetterOptions` encapsulates a set of configurable options for filtering and retrieving a selection of notes from a [data oracle](/aztec/aztec/concepts/smart_contracts/oracles/index.md). Developers can design instances of `NoteGetterOptions`, to determine how notes should be filtered and returned to the functions of their smart contracts. +`NoteGetterOptions` encapsulates a set of configurable options for filtering and retrieving a selection of notes from a [data oracle](/aztec/concepts/smart_contracts/oracles/index.md). Developers can design instances of `NoteGetterOptions`, to determine how notes should be filtered and returned to the functions of their smart contracts. You can view the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/note/note_getter_options.nr). diff --git a/docs/docs/reference/reference/smart_contract_reference/storage/public_state.md b/docs/docs/reference/smart_contract_reference/storage/public_state.md similarity index 89% rename from docs/docs/reference/reference/smart_contract_reference/storage/public_state.md rename to docs/docs/reference/smart_contract_reference/storage/public_state.md index 3b04b61747a..f30e256659d 100644 --- a/docs/docs/reference/reference/smart_contract_reference/storage/public_state.md +++ b/docs/docs/reference/smart_contract_reference/storage/public_state.md @@ -4,7 +4,7 @@ title: Public State On this page we will look at how to manage public state in Aztec contracts. We will look at how to declare public state, how to read and write to it, and how to use it in your contracts. -For a higher level overview of the state model in Aztec, see the [state model](/aztec/aztec/concepts/state_model/index.md) page. +For a higher level overview of the state model in Aztec, see the [state model](/aztec/concepts/state_model/index.md) page. ## `PublicMutable` @@ -13,7 +13,7 @@ The `PublicMutable` (formerly known as `PublicState`) struct is generic over the #include_code serialize /noir-projects/noir-protocol-circuits/crates/types/src/traits.nr rust #include_code deserialize /noir-projects/noir-protocol-circuits/crates/types/src/traits.nr rust -The struct contains a `storage_slot` which, similar to Ethereum, is used to figure out _where_ in storage the variable is located. Notice that while we don't have the exact same [state model](/aztec/aztec/concepts/state_model/index.md) as EVM chains it will look similar from the contract developers point of view. +The struct contains a `storage_slot` which, similar to Ethereum, is used to figure out _where_ in storage the variable is located. Notice that while we don't have the exact same [state model](/aztec/concepts/state_model/index.md) as EVM chains it will look similar from the contract developers point of view. You can find the details of `PublicMutable` in the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/state_vars/public_mutable.nr). @@ -25,7 +25,7 @@ An example using a larger struct can be found in the [lending example](https://g ### `new` -When declaring the storage for `T` as a persistent public storage variable, we use the `PublicMutable::new()` constructor. As seen below, this takes the `storage_slot` and the `serialization_methods` as arguments along with the [`Context`](/aztec/aztec/concepts/smart_contracts/functions/context), which in this case is used to share interface with other structures. You can view the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/state_vars/public_mutable.nr). +When declaring the storage for `T` as a persistent public storage variable, we use the `PublicMutable::new()` constructor. As seen below, this takes the `storage_slot` and the `serialization_methods` as arguments along with the [`Context`](/aztec/concepts/smart_contracts/functions/context), which in this case is used to share interface with other structures. You can view the implementation [here](https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/noir-projects/aztec-nr/aztec/src/state_vars/public_mutable.nr). #### Single value example diff --git a/docs/docs/reference/reference/smart_contract_reference/storage/shared_state.md b/docs/docs/reference/smart_contract_reference/storage/shared_state.md similarity index 100% rename from docs/docs/reference/reference/smart_contract_reference/storage/shared_state.md rename to docs/docs/reference/smart_contract_reference/storage/shared_state.md diff --git a/docs/docs/tutorials/_category_.json b/docs/docs/tutorials/_category_.json index 1285823106e..02c7361fd8a 100644 --- a/docs/docs/tutorials/_category_.json +++ b/docs/docs/tutorials/_category_.json @@ -1,6 +1,6 @@ { "label": "Tutorials", - "position": 2, + "position": 1, "collapsible": true, "collapsed": true } diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/_category_.json b/docs/docs/tutorials/contract_tutorials/_category_.json similarity index 100% rename from docs/docs/tutorials/tutorials/contract_tutorials/_category_.json rename to docs/docs/tutorials/contract_tutorials/_category_.json diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/_category_.json b/docs/docs/tutorials/contract_tutorials/advanced/_category_.json similarity index 100% rename from docs/docs/tutorials/tutorials/contract_tutorials/advanced/_category_.json rename to docs/docs/tutorials/contract_tutorials/advanced/_category_.json diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/_category_.json b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/_category_.json similarity index 100% rename from docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/_category_.json rename to docs/docs/tutorials/contract_tutorials/advanced/token_bridge/_category_.json diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec.md similarity index 100% rename from docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec.md rename to docs/docs/tutorials/contract_tutorials/advanced/token_bridge/depositing_to_aztec.md diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/index.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md similarity index 97% rename from docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/index.md rename to docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md index 7d3880595a2..3331911f850 100644 --- a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/index.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/index.md @@ -43,7 +43,7 @@ The goal for this tutorial is to create functionality such that a token can be b This is just a reference implementation for educational purposes only. It has not been through an in-depth security audit. -Let’s assume a token exists on Ethereum and Aztec (see a [guide on writing a token contract on Aztec here](/tutorials/tutorials/contract_tutorials/token_contract)). +Let’s assume a token exists on Ethereum and Aztec (see a [guide on writing a token contract on Aztec here](/tutorials/contract_tutorials/token_contract)). We will build: diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md similarity index 98% rename from docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md rename to docs/docs/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md index 0aef8d37fef..f3b6aadd52d 100644 --- a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/minting_on_aztec.md @@ -47,6 +47,6 @@ If the content hashes were constructed similarly for `mint_private` and `mint_pu While we mint the tokens on L2, we _still don’t actually mint them to a certain address_. Instead we continue to pass the `secret_hash_for_redeeming_minted_notes` like we did on L1. This means that a user could reveal their secret for L2 message consumption for anyone to mint tokens on L2 but they can redeem these notes at a later time. **This enables a paradigm where an app can manage user’s secrets for L2 message consumption on their behalf**. **The app or any external party can also mint tokens on the user’s behalf should they be comfortable with leaking the secret for L2 Message consumption.** This doesn’t leak any new information to the app because their smart contract on L1 knew that a user wanted to move some amount of tokens to L2. The app still doesn’t know which address on L2 the user wants these notes to be in, but they can mint tokens nevertheless on their behalf. -To mint tokens privately, `claim_private` calls an internal function `_call_mint_on_token()` which then calls [token.mint_private()](/tutorials/tutorials/contract_tutorials/token_contract.md#redeem_shield). +To mint tokens privately, `claim_private` calls an internal function `_call_mint_on_token()` which then calls [token.mint_private()](/tutorials/contract_tutorials/token_contract.md#redeem_shield). In the next step we will see how we can cancel a message. diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/setup.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/setup.md similarity index 99% rename from docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/setup.md rename to docs/docs/tutorials/contract_tutorials/advanced/token_bridge/setup.md index 1c214be6efb..78fe396dc07 100644 --- a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/setup.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/setup.md @@ -18,7 +18,7 @@ We recommend going through this setup to fully understand where things live. - [node v18+](https://github.com/tj/n) - [docker](https://docs.docker.com/) - [Aztec sandbox](https://docs.aztec.network/developers/getting_started/sandbox) - you should have this running before starting the tutorial -- [Aztec CLI](/getting_started/getting_started) +- [Aztec CLI](/getting_started) ```bash /bin/sh -c "$(curl -fsSL 'https://sandbox.aztec.network')" diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code.md similarity index 100% rename from docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code.md rename to docs/docs/tutorials/contract_tutorials/advanced/token_bridge/typescript_glue_code.md diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md similarity index 91% rename from docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md rename to docs/docs/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md index bf4034a6ca9..3c5c8b4008e 100644 --- a/docs/docs/tutorials/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md +++ b/docs/docs/tutorials/contract_tutorials/advanced/token_bridge/withdrawing_to_l1.md @@ -17,9 +17,9 @@ For this to work we import the `get_withdraw_content_hash` helper function from The `exit_to_l1_public` function enables anyone to withdraw their L2 tokens back to L1 publicly. This is done by burning tokens on L2 and then creating an L2->L1 message. 1. Like with our deposit function, we need to create the L2 to L1 message. The content is the _amount_ to burn, the recipient address, and who can execute the withdraw on the L1 portal on behalf of the user. It can be `0x0` for anyone, or a specified address. -2. `context.message_portal()` passes this content to the [kernel circuit](/aztec/aztec/concepts/circuits/kernels/public_kernel.md) which creates the proof for the transaction. The kernel circuit then adds the sender (the L2 address of the bridge + version of aztec) and the recipient (the portal to the L2 address + the chain ID of L1) under the hood, to create the message which gets added as part of the transaction data published by the sequencer and is stored in the outbox for consumption. +2. `context.message_portal()` passes this content to the [kernel circuit](/aztec/concepts/circuits/kernels/public_kernel.md) which creates the proof for the transaction. The kernel circuit then adds the sender (the L2 address of the bridge + version of aztec) and the recipient (the portal to the L2 address + the chain ID of L1) under the hood, to create the message which gets added as part of the transaction data published by the sequencer and is stored in the outbox for consumption. 3. The `context.message_portal()` takes the recipient and content as input, and will insert a message into the outbox. We set the recipient to be the portal address read from storage of the contract. -4. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](/tutorials/tutorials/contract_tutorials/token_contract.md#authorizing-token-spends). +4. Finally, you also burn the tokens on L2! Note that it burning is done at the end to follow the check effects interaction pattern. Note that the caller has to first approve the bridge contract to burn tokens on its behalf. Refer to [burn_public function on the token contract](/tutorials/contract_tutorials/token_contract.md#authorizing-token-spends). - We burn the tokens from the `msg_sender()`. Otherwise, a malicious user could burn someone else’s tokens and mint tokens on L1 to themselves. One could add another approval flow on the bridge but that might make it complex for other applications to call the bridge. ## Withdrawing Privately diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/crowdfunding_contract.md b/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md similarity index 96% rename from docs/docs/tutorials/tutorials/contract_tutorials/crowdfunding_contract.md rename to docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md index 1e7edbaff58..7147853ac5b 100644 --- a/docs/docs/tutorials/tutorials/contract_tutorials/crowdfunding_contract.md +++ b/docs/docs/tutorials/contract_tutorials/crowdfunding_contract.md @@ -76,7 +76,7 @@ Replace the example functions with an initializer that takes the required campai } ``` -More about initializers [here](/guides/guides/smart_contracts/writing_contracts/initializers.md). +More about initializers [here](/guides/smart_contracts/writing_contracts/initializers.md). #### Dependencies @@ -184,7 +184,7 @@ token = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_ With the dependency already `use`d at the start of the contract, the token contract can be called to make the transfer from msg sender to this contract. :::note -The user must have authorised this action (concept [here](/aztec/aztec/concepts/accounts#authorizing-actions)), example use of `createAuthWit` in 'full donor flow' test [here](../../../../../yarn-project/end-to-end/src/e2e_crowdfunding_and_claim.test.ts). +The user must have authorised this action (concept [here](/aztec/concepts/accounts#authorizing-actions)), example use of `createAuthWit` in 'full donor flow' test [here](../../../../yarn-project/end-to-end/src/e2e_crowdfunding_and_claim.test.ts). ::: #### Creating and storing a private receipt note diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/private_voting_contract.md b/docs/docs/tutorials/contract_tutorials/private_voting_contract.md similarity index 82% rename from docs/docs/tutorials/tutorials/contract_tutorials/private_voting_contract.md rename to docs/docs/tutorials/contract_tutorials/private_voting_contract.md index 10a211912d7..5815d037c26 100644 --- a/docs/docs/tutorials/tutorials/contract_tutorials/private_voting_contract.md +++ b/docs/docs/tutorials/contract_tutorials/private_voting_contract.md @@ -21,7 +21,7 @@ To keep things simple, we won't create ballots or allow for delegate voting. ## Prerequisites -- You have followed the [quickstart](/getting_started/getting_started) to install `aztec-nargo` and `aztec-sandbox`. +- You have followed the [quickstart](/getting_started) to install `aztec-nargo` and `aztec-sandbox`. - Running Aztec Sandbox ## Set up a project @@ -110,9 +110,9 @@ Create a private function called `cast_vote`: #include_code cast_vote noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr rust -In this function, we do not create a nullifier with the address directly. This would leak privacy as it would be easy to reverse-engineer. We must add some randomness or some form of secret, like [nullifier secrets](/aztec/aztec/concepts/accounts/keys.md#nullifier-secrets). +In this function, we do not create a nullifier with the address directly. This would leak privacy as it would be easy to reverse-engineer. We must add some randomness or some form of secret, like [nullifier secrets](/aztec/concepts/accounts/keys.md#nullifier-secrets). -To do this, we make an [oracle call](/aztec/aztec/concepts/smart_contracts/oracles/index.md) to fetch the caller's secret key, hash it to create a nullifier, and push the nullifier to Aztec. The `secret.high` and `secret.low` values here refer to how we divide a large [Grumpkin scalar](https://github.com/AztecProtocol/aztec-packages/blob/7fb35874eae3f2cad5cb922282a619206573592c/noir/noir_stdlib/src/grumpkin_scalar.nr) value into its higher and lower parts. This allows for faster cryptographic computations so our hash can still be secure but is calculated faster. +To do this, we make an [oracle call](/aztec/concepts/smart_contracts/oracles/index.md) to fetch the caller's secret key, hash it to create a nullifier, and push the nullifier to Aztec. The `secret.high` and `secret.low` values here refer to how we divide a large [Grumpkin scalar](https://github.com/AztecProtocol/aztec-packages/blob/7fb35874eae3f2cad5cb922282a619206573592c/noir/noir_stdlib/src/grumpkin_scalar.nr) value into its higher and lower parts. This allows for faster cryptographic computations so our hash can still be secure but is calculated faster. After pushing the nullifier, we update the `tally` to reflect this vote. As we know from before, a private function cannot update public state directly, so we are calling a public function. @@ -132,7 +132,7 @@ We will create a function that anyone can call that will return the number of vo #include_code get_vote noir-projects/noir-contracts/contracts/easy_private_voting_contract/src/main.nr rust -We set it as `unconstrained` and do not annotate it because it is only reading from state. You can read more about unconstrained functions [here](/aztec/aztec/concepts/pxe/acir_simulator.md#unconstrained-functions). +We set it as `unconstrained` and do not annotate it because it is only reading from state. You can read more about unconstrained functions [here](/aztec/concepts/pxe/acir_simulator.md#unconstrained-functions). ## Allowing an admin to end a voting period @@ -154,18 +154,18 @@ aztec-nargo compile This will create a new directory called `target` and a JSON artifact inside it. -Once it is compiled you can [deploy](/reference/reference/sandbox_reference/index.md). +Once it is compiled you can [deploy](/reference/sandbox_reference/index.md). ```bash aztec-builder target -o src/artifacts ``` -Once it is compiled you can [deploy](/guides/guides/smart_contracts/how_to_deploy_contract.md) it to the sandbox. This is out of scope for this tutorial but you can learn how to do this in the [Aztec.js getting-started guide](/getting_started/getting_started/aztecjs-getting-started.md). +Once it is compiled you can [deploy](/guides/smart_contracts/how_to_deploy_contract.md) it to the sandbox. This is out of scope for this tutorial but you can learn how to do this in the [Aztec.js getting-started guide](/getting_started/aztecjs-getting-started.md). ## Next steps Now you have learned the foundations of Aztec smart contracts, you can start to play around with some more advanced features. Some ideas: - Add some more features into this contract, like the admin can distribute votes, people can delegate their votes, or voteIds can have more data like names, descriptions, etc -- Create a frontend for this contract using [Aztec.js](/getting_started/getting_started/aztecjs-getting-started.md). -- Go to the [next tutorial](/tutorials/tutorials/contract_tutorials/token_contract.md) and learn how to write a token contract +- Create a frontend for this contract using [Aztec.js](/getting_started/aztecjs-getting-started.md). +- Go to the [next tutorial](/tutorials/contract_tutorials/token_contract.md) and learn how to write a token contract diff --git a/docs/docs/tutorials/tutorials/contract_tutorials/token_contract.md b/docs/docs/tutorials/contract_tutorials/token_contract.md similarity index 96% rename from docs/docs/tutorials/tutorials/contract_tutorials/token_contract.md rename to docs/docs/tutorials/contract_tutorials/token_contract.md index 18b32e3db9d..cac8dc0a4d1 100644 --- a/docs/docs/tutorials/tutorials/contract_tutorials/token_contract.md +++ b/docs/docs/tutorials/contract_tutorials/token_contract.md @@ -21,7 +21,7 @@ We are going to start with a blank project and fill in the token contract source ## Requirements -You will need to have `aztec-nargo` installed in order to compile Aztec.nr contracts. See the [sandbox reference](/reference/reference/sandbox_reference/index.md) for installation instructions. +You will need to have `aztec-nargo` installed in order to compile Aztec.nr contracts. See the [sandbox reference](/reference/sandbox_reference/index.md) for installation instructions. You should also install the [Noir Language Support extension](https://marketplace.visualstudio.com/items?itemName=noir-lang.vscode-noir) for VS Code. @@ -151,7 +151,7 @@ These are functions that have transparent logic, will execute in a publicly veri ### Private functions -These are functions that have private logic and will be executed on user devices to maintain privacy. The only data that is submitted to the network is a proof of correct execution, new data [commitments](https://en.wikipedia.org/wiki/Commitment_scheme) and [nullifiers](/aztec/aztec/concepts/storage/trees/index.md#nullifier-tree), so users will not reveal which contract they are interacting with or which function they are executing. The only information that will be revealed publicly is that someone executed a private transaction on Aztec. +These are functions that have private logic and will be executed on user devices to maintain privacy. The only data that is submitted to the network is a proof of correct execution, new data [commitments](https://en.wikipedia.org/wiki/Commitment_scheme) and [nullifiers](/aztec/concepts/storage/trees/index.md#nullifier-tree), so users will not reveal which contract they are interacting with or which function they are executing. The only information that will be revealed publicly is that someone executed a private transaction on Aztec. - `redeem_shield` enables accounts to claim tokens that have been made private via `mint_private` or `shield` by providing the secret - `unshield` enables an account to send tokens from their private balance to any other account's public balance @@ -209,7 +209,7 @@ We are importing: - `compute_secret_hash` that will help with the shielding and unshielding, allowing someone to claim a token from private to public - Types for storing note types -For more detail on execution contexts, see [Contract Communication](/aztec/aztec/concepts/smart_contracts/communication). +For more detail on execution contexts, see [Contract Communication](/aztec/concepts/smart_contracts/communication). ### Types files @@ -219,7 +219,7 @@ The main thing to note from this types folder is the `TransparentNote` definitio ### Note on private state -Private state in Aztec is all [UTXOs](/aztec/aztec/concepts/storage/index.md) to learn more about public and private state in Aztec. +Private state in Aztec is all [UTXOs](/aztec/concepts/storage/index.md) to learn more about public and private state in Aztec. ## Contract Storage @@ -238,7 +238,7 @@ Reading through the storage variables: - `pending_shields` is a `PrivateSet` of `TransparentNote`s stored in private state. What is stored publicly is a set of commitments to `TransparentNote`s. - `public_balances` is a mapping of Aztec addresses in public state and represents the publicly viewable balances of accounts. -You can read more about it [here](/aztec/aztec/concepts/storage/index.md). +You can read more about it [here](/aztec/concepts/storage/index.md). ## Functions @@ -423,7 +423,7 @@ A getter function for checking the public balance of the provided Aztec account. ## Compiling -Now that the contract is complete, you can compile it with `aztec-nargo`. See the [Sandbox reference page](/reference/reference/sandbox_reference/index.md) for instructions on setting it up. +Now that the contract is complete, you can compile it with `aztec-nargo`. See the [Sandbox reference page](/reference/sandbox_reference/index.md) for instructions on setting it up. Run the following command in the directory where your `Nargo.toml` file is located: @@ -447,6 +447,6 @@ https://github.com/AztecProtocol/aztec-packages/blob/#include_aztec_version/yarn ### Token Bridge Contract -The [token bridge tutorial](/tutorials/tutorials/contract_tutorials/advanced/token_bridge) is a great follow up to this one. +The [token bridge tutorial](/tutorials/contract_tutorials/advanced/token_bridge) 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/tutorials/simple_dapp/contract_deployment.md b/docs/docs/tutorials/simple_dapp/contract_deployment.md similarity index 94% rename from docs/docs/tutorials/tutorials/simple_dapp/contract_deployment.md rename to docs/docs/tutorials/simple_dapp/contract_deployment.md index b3e157f88d7..a6981fbd58d 100644 --- a/docs/docs/tutorials/tutorials/simple_dapp/contract_deployment.md +++ b/docs/docs/tutorials/simple_dapp/contract_deployment.md @@ -3,7 +3,7 @@ To add contracts to your application, we'll start by creating a new `aztec-nargo` project. We'll then compile the contracts, and write a simple script to deploy them to our Sandbox. :::info -Follow the instructions [here](/reference/reference/sandbox_reference/index.md) to install `aztec-nargo` if you haven't done so already. +Follow the instructions [here](/reference/sandbox_reference/index.md) to install `aztec-nargo` if you haven't done so already. ::: ## Initialize Aztec project @@ -34,7 +34,7 @@ The `Token` contract also requires some helper files. You can view the files [he ## Compile your contract -We'll now use `aztec-nargo` to [compile](/reference/reference/sandbox_reference/index.md#installation). +We'll now use `aztec-nargo` to [compile](/reference/sandbox_reference/index.md#installation). Now run the following from your contract folder (containing Nargo.toml): diff --git a/docs/docs/tutorials/tutorials/simple_dapp/contract_interaction.md b/docs/docs/tutorials/simple_dapp/contract_interaction.md similarity index 91% rename from docs/docs/tutorials/tutorials/simple_dapp/contract_interaction.md rename to docs/docs/tutorials/simple_dapp/contract_interaction.md index 253801457e0..c263b64ddf6 100644 --- a/docs/docs/tutorials/tutorials/simple_dapp/contract_interaction.md +++ b/docs/docs/tutorials/simple_dapp/contract_interaction.md @@ -9,7 +9,7 @@ Let's start by showing our user's private balance for the token across their acc #include_code balance_of_private noir-projects/noir-contracts/contracts/token_contract/src/main.nr rust :::info -Note that this function will only return a valid response for accounts registered in the Private eXecution Environment (PXE), since it requires access to the [user's private state](/aztec/aztec/concepts/wallets/index.md#private-state). In other words, you cannot query the private balance of another user for the token contract. +Note that this function will only return a valid response for accounts registered in the Private eXecution Environment (PXE), since it requires access to the [user's private state](/aztec/concepts/wallets/index.md#private-state). In other words, you cannot query the private balance of another user for the token contract. ::: To do this, let's first initialize a new `Contract` instance using `aztec.js` that represents our deployed token contracts. Create a new `src/contracts.mjs` file with the imports for our artifacts and other dependencies: @@ -93,12 +93,12 @@ At the time of this writing, there are no events emitted when new private notes ## Working with public state -While [private and public state](/aztec/aztec/concepts/state_model/index.md) are fundamentally different, the API for working with private and public functions and state from `aztec.js` is equivalent. To query the balance in public tokens for our user accounts, we can just call the `balance_of_public` view function in the contract: +While [private and public state](/aztec/concepts/state_model/index.md) are fundamentally different, the API for working with private and public functions and state from `aztec.js` is equivalent. To query the balance in public tokens for our user accounts, we can just call the `balance_of_public` view function in the contract: #include_code showPublicBalances yarn-project/end-to-end/src/sample-dapp/index.mjs javascript :::info -Since this we are working with pubic balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](/aztec/aztec/concepts/accounts/keys.md#encryption-keys). +Since this we are working with pubic balances, we can now query the balance for any address, not just those registered in our local PXE. We can also send funds to addresses for which we don't know their [public encryption key](/aztec/concepts/accounts/keys.md#encryption-keys). ::: Here, since the token contract does not mint any initial funds upon deployment, the balances for all of our user's accounts will be zero. diff --git a/docs/docs/tutorials/tutorials/simple_dapp/index.md b/docs/docs/tutorials/simple_dapp/index.md similarity index 87% rename from docs/docs/tutorials/tutorials/simple_dapp/index.md rename to docs/docs/tutorials/simple_dapp/index.md index 7254d2e242d..34a7c6dd6be 100644 --- a/docs/docs/tutorials/tutorials/simple_dapp/index.md +++ b/docs/docs/tutorials/simple_dapp/index.md @@ -4,7 +4,7 @@ title: Dapp Tutorial In this tutorial we'll go through the steps for building a simple application that interacts with the Aztec Sandbox. We'll be building a console application using Javascript and NodeJS, but you may reuse the same concepts here for a web-based app. All Aztec libraries are written in Typescript and fully typed, so you can use Typescript instead of Javascript to make the most out of its type checker. -This tutorial will focus on environment setup, including creating accounts and deployments, as well as interacting with your contracts. It will not cover [how to write contracts in Noir](/aztec/aztec/concepts/smart_contracts/index.md). +This tutorial will focus on environment setup, including creating accounts and deployments, as well as interacting with your contracts. It will not cover [how to write contracts in Noir](/aztec/concepts/smart_contracts/index.md). The full code for this tutorial is [available on the `aztec-packages` repository](https://github.com/AztecProtocol/aztec-packages/blob/master/yarn-project/end-to-end/src/sample-dapp). @@ -12,8 +12,8 @@ The full code for this tutorial is [available on the `aztec-packages` repository - Linux or OSX environment - [NodeJS](https://nodejs.org/) 18 or higher -- [Aztec Sandbox](/getting_started/getting_started) -- [Aztec CLI](/reference/reference/sandbox_reference) +- [Aztec Sandbox](/getting_started) +- [Aztec CLI](/reference/sandbox_reference) ## Prerequisites diff --git a/docs/docs/tutorials/tutorials/simple_dapp/project_setup.md b/docs/docs/tutorials/simple_dapp/project_setup.md similarity index 100% rename from docs/docs/tutorials/tutorials/simple_dapp/project_setup.md rename to docs/docs/tutorials/simple_dapp/project_setup.md diff --git a/docs/docs/tutorials/tutorials/simple_dapp/pxe_service.md b/docs/docs/tutorials/simple_dapp/pxe_service.md similarity index 92% rename from docs/docs/tutorials/tutorials/simple_dapp/pxe_service.md rename to docs/docs/tutorials/simple_dapp/pxe_service.md index 8832d8e9c7d..f4f3c51c158 100644 --- a/docs/docs/tutorials/tutorials/simple_dapp/pxe_service.md +++ b/docs/docs/tutorials/simple_dapp/pxe_service.md @@ -4,7 +4,7 @@ PXE is a component of the Aztec Protocol that provides a private execution envir As an app developer, the [PXE](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/pxe) interface provides you with access to the user's accounts and their private state, as well as a connection to the network for accessing public global state. -During the Sandbox phase, this role is fulfilled by the [Aztec Sandbox](/reference/reference/sandbox_reference/index.md), which runs a local PXE and an Aztec Node, both connected to a local Ethereum development node like Anvil. +During the Sandbox phase, this role is fulfilled by the [Aztec Sandbox](/reference/sandbox_reference/index.md), which runs a local PXE and an Aztec Node, both connected to a local Ethereum development node like Anvil. The Sandbox also includes a set of pre-initialized accounts that you can use from your app. In this section, we'll connect to the Sandbox from our project. diff --git a/docs/docs/tutorials/tutorials/simple_dapp/testing.md b/docs/docs/tutorials/simple_dapp/testing.md similarity index 79% rename from docs/docs/tutorials/tutorials/simple_dapp/testing.md rename to docs/docs/tutorials/simple_dapp/testing.md index c9907bd0dd0..1160977b085 100644 --- a/docs/docs/tutorials/tutorials/simple_dapp/testing.md +++ b/docs/docs/tutorials/simple_dapp/testing.md @@ -4,7 +4,7 @@ title: Testing To wrap up this tutorial, we'll set up a simple automated test for our dapp contracts. We will be using [jest](https://jestjs.io/), but any nodejs test runner works fine. -Here we'll only test the happy path for a `transfer` on our private token contract, but in a real application you should be testing both happy and unhappy paths, as well as both your contracts and application logic. Refer to the full [testing guide](/tutorials/tutorials/simple_dapp/testing.md) for more info on testing and assertions. +Here we'll only test the happy path for a `transfer` on our private token contract, but in a real application you should be testing both happy and unhappy paths, as well as both your contracts and application logic. ## Dependencies @@ -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/reference/sandbox_reference/index.md#installation). +We'll need to [install and run the Sandbox](/reference/sandbox_reference/index.md#installation). ## Test setup @@ -46,7 +46,7 @@ Let's set up our test suite. We'll make sure the Sandbox is running, create two #include_code setup yarn-project/end-to-end/src/sample-dapp/index.test.mjs javascript :::tip -Instead of creating new accounts in our test suite, we can use the ones already initialized by the Sandbox upon startup. This can provide a speed boost to your tests setup. However, bear in mind that you may accidentally introduce an interdependency across test suites by reusing the same accounts. Read more [here](/tutorials/tutorials/simple_dapp/testing.md#using-sandbox-initial-accounts). +Instead of creating new accounts in our test suite, we can use the ones already initialized by the Sandbox upon startup. This can provide a speed boost to your tests setup. However, bear in mind that you may accidentally introduce an interdependency across test suites by reusing the same accounts. ::: ## Writing our test @@ -55,7 +55,7 @@ Now that we have a working test environment, we can write our first test for exe #include_code test yarn-project/end-to-end/src/sample-dapp/index.test.mjs javascript -In this example, we assert that the `recipient`'s balance is increased by the amount transferred. We could also test that the `owner`'s funds are decremented by the same amount, or that a transaction that attempts to send more funds than those available would fail. Check out the [testing guide](/tutorials/tutorials/simple_dapp/testing.md) for more ideas. +In this example, we assert that the `recipient`'s balance is increased by the amount transferred. We could also test that the `owner`'s funds are decremented by the same amount, or that a transaction that attempts to send more funds than those available would fail. ## Running our tests @@ -67,4 +67,4 @@ yarn node --experimental-vm-modules $(yarn bin jest) --testRegex '.*\.test\.mjs$ ## Next steps -Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](/aztec/aztec/concepts/smart_contracts/index.md) or read about the [fundamental concepts behind Aztec Network](/aztec/aztec/core_components). +Now that you have finished the tutorial, you can learn more about [writing contracts with Noir](/aztec/concepts/smart_contracts/index.md) or read about the [fundamental concepts behind Aztec Network](/aztec/core_components). diff --git a/docs/docs/tutorials/tutorials/_category_.json b/docs/docs/tutorials/tutorials/_category_.json deleted file mode 100644 index 02c7361fd8a..00000000000 --- a/docs/docs/tutorials/tutorials/_category_.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "label": "Tutorials", - "position": 1, - "collapsible": true, - "collapsed": true -} diff --git a/docs/docs/tutorials/tutorials/write_accounts_contract.md b/docs/docs/tutorials/write_accounts_contract.md similarity index 83% rename from docs/docs/tutorials/tutorials/write_accounts_contract.md rename to docs/docs/tutorials/write_accounts_contract.md index bee114a9c58..fca19b89b0d 100644 --- a/docs/docs/tutorials/tutorials/write_accounts_contract.md +++ b/docs/docs/tutorials/write_accounts_contract.md @@ -13,15 +13,15 @@ You will learn: - Typescript glue code to format and authenticate transactions - Deploying and testing the account contract -Writing your own account contract allows you to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed (including key rotation and recovery). In other words, writing an account contract lets you make the most out of [account abstraction](/aztec/aztec/concepts/index.md#what-is-account-abstraction) in the Aztec network. +Writing your own account contract allows you to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed (including key rotation and recovery). In other words, writing an account contract lets you make the most out of [account abstraction](/aztec/concepts/index.md#what-is-account-abstraction) in the Aztec network. -It is highly recommended that you understand how an [account](/aztec/aztec/concepts/index.md) is defined in Aztec, as well as the differences between privacy and authentication [keys](/aztec/aztec/concepts/accounts/keys.md). You will also need to know how to write a contract in Noir, as well as some basic [Typescript](https://www.typescriptlang.org/). +It is highly recommended that you understand how an [account](/aztec/concepts/index.md) is defined in Aztec, as well as the differences between privacy and authentication [keys](/aztec/concepts/accounts/keys.md). You will also need to know how to write a contract in Noir, as well as some basic [Typescript](https://www.typescriptlang.org/). For this tutorial, we will write an account contract that uses Schnorr signatures for authenticating transaction requests. Every time a transaction payload is passed to this account contract's `entrypoint` function, the account contract requires a valid Schnorr signature, whose signed message matches the transaction payload, and whose signer matches the account contract owner's public key. If the signature fails, the transaction will fail. -For the sake of simplicity, we will hardcode the signing public key into the contract, but you could store it [in a private note](/aztec/aztec/concepts/accounts/keys.md#using-a-private-note), [in an immutable note](/aztec/aztec/concepts/accounts/keys.md#using-an-immutable-private-note), or [on a separate keystore](/aztec/aztec/concepts/accounts/keys.md#using-a-separate-keystore), to mention a few examples. +For the sake of simplicity, we will hardcode the signing public key into the contract, but you could store it [in a private note](/aztec/concepts/accounts/keys.md#using-a-private-note), [in an immutable note](/aztec/concepts/accounts/keys.md#using-an-immutable-private-note), or [on a separate keystore](/aztec/concepts/accounts/keys.md#using-a-separate-keystore), to mention a few examples. ## Contract @@ -29,7 +29,7 @@ Let's start with the account contract itself in Aztec.nr. Create a new Aztec.nr #include_code contract noir-projects/noir-contracts/contracts/schnorr_hardcoded_account_contract/src/main.nr rust -The important part of this contract is the `entrypoint` function, which will be the first function executed in any transaction originated from this account. This function has two main responsibilities: authenticating the transaction and executing calls. It receives a `payload` with the list of function calls to execute, and requests a corresponding [authentication witness](/aztec/aztec/concepts/accounts/authwit.md) from an oracle to validate it. Authentication witnesses are used for authorizing actions for an account, whether it is just checking a signature, like in this case, or granting authorization for another account to act on an accounts behalf (e.g. token approvals). You will find this logic implemented in the `AccountActions` module, which use the `AppPayload` and `FeePayload` structs: +The important part of this contract is the `entrypoint` function, which will be the first function executed in any transaction originated from this account. This function has two main responsibilities: authenticating the transaction and executing calls. It receives a `payload` with the list of function calls to execute, and requests a corresponding [authentication witness](/aztec/concepts/accounts/authwit.md) from an oracle to validate it. Authentication witnesses are used for authorizing actions for an account, whether it is just checking a signature, like in this case, or granting authorization for another account to act on an accounts behalf (e.g. token approvals). You will find this logic implemented in the `AccountActions` module, which use the `AppPayload` and `FeePayload` structs: #include_code entrypoint noir-projects/aztec-nr/authwit/src/account.nr rust @@ -83,11 +83,11 @@ More signing schemes are available in case you want to experiment with other typ Let's try creating a new account backed by our account contract, and interact with a simple token contract to test it works. -To create and deploy the account, we will use the `AccountManager` class, which takes an instance of an Private Execution Environment (PXE), a [privacy private key](/aztec/aztec/concepts/accounts/keys.md#privacy-keys), and an instance of our `AccountContract` class: +To create and deploy the account, we will use the `AccountManager` class, which takes an instance of an Private Execution Environment (PXE), a [privacy private key](/aztec/concepts/accounts/keys.md#privacy-keys), and an instance of our `AccountContract` class: #include_code account-contract-deploy yarn-project/end-to-end/src/guides/writing_an_account_contract.test.ts typescript -Note that we get a [`Wallet` instance](/aztec/aztec/concepts/index.md#account-contracts-and-wallets) out of the account, which we can use for initializing the token contract class after deployment, so any transactions sent to it are sent from our wallet. We can then send a transaction to it and check its effects: +Note that we get a [`Wallet` instance](/aztec/concepts/index.md#account-contracts-and-wallets) out of the account, which we can use for initializing the token contract class after deployment, so any transactions sent to it are sent from our wallet. We can then send a transaction to it and check its effects: #include_code account-contract-works yarn-project/end-to-end/src/guides/writing_an_account_contract.test.ts typescript diff --git a/docs/docs/aztec/index.mdx b/docs/docs/vision.mdx similarity index 96% rename from docs/docs/aztec/index.mdx rename to docs/docs/vision.mdx index 5381c307ecb..498522810f5 100644 --- a/docs/docs/aztec/index.mdx +++ b/docs/docs/vision.mdx @@ -3,7 +3,7 @@ title: Vision sidebar_position: 1 --- -import Disclaimer from "../../src/components/Disclaimers/_wip_disclaimer.mdx"; +import Disclaimer from "@site/src/components/Disclaimers/_wip_disclaimer.mdx"; ## The world's encrypted ledger diff --git a/docs/docusaurus.config.js b/docs/docusaurus.config.js index 5b5b5fe9190..16c6fbacd7c 100644 --- a/docs/docusaurus.config.js +++ b/docs/docusaurus.config.js @@ -126,33 +126,40 @@ const config = { [ "docusaurus-plugin-typedoc", { - id: "apis/pxe", + id: "aztecjs/pxe", entryPoints: ["../yarn-project/circuit-types/src/interfaces/pxe.ts"], tsconfig: "../yarn-project/circuit-types/tsconfig.json", entryPointStrategy: "expand", - out: "apis/pxe", + out: "reference/aztecjs/pxe", + readme: "none", + sidebar: { + categoryLabel: "Private Execution Environment (PXE)", + }, disableSources: true, - frontmatter: { sidebar_label: "Private Execution Environment (PXE)" }, }, ], [ "docusaurus-plugin-typedoc", { - id: "apis/aztec-js", + id: "aztecjs/aztec-js", entryPoints: [ "../yarn-project/aztec.js/src/contract/index.ts", "../yarn-project/aztec.js/src/account/index.ts", ], tsconfig: "../yarn-project/aztec.js/tsconfig.json", entryPointStrategy: "resolve", - out: "apis/aztec-js", + out: "reference/aztecjs/aztec-js", + readme: "none", + sidebar: { + categoryLabel: "Aztec.js", + }, disableSources: true, }, ], [ "docusaurus-plugin-typedoc", { - id: "apis/accounts", + id: "aztecjs/accounts", entryPoints: [ "../yarn-project/accounts/src/defaults/index.ts", "../yarn-project/accounts/src/ecdsa/index.ts", @@ -162,7 +169,11 @@ const config = { ], tsconfig: "../yarn-project/accounts/tsconfig.json", entryPointStrategy: "resolve", - out: "apis/accounts", + out: "reference/aztecjs/accounts", + readme: "none", + sidebar: { + categoryLabel: "Accounts", + }, disableSources: true, }, ], @@ -231,7 +242,7 @@ const config = { }, { label: "Developer Quickstart", - to: "/getting_started/getting_started", + to: "/getting_started", }, { label: "Aztec.nr", diff --git a/docs/package.json b/docs/package.json index 390cff4d4a5..ce1043aaaef 100644 --- a/docs/package.json +++ b/docs/package.json @@ -8,14 +8,11 @@ "dev:local": "ENV=dev yarn docs", "build": "./scripts/build.sh", "swizzle": "docusaurus swizzle", - "clear": "rm -rf 'processed-docs' 'processed-docs-cache' docs/apis && docusaurus clear && rm 'src/preprocess/AztecnrReferenceAutogenStructure.json' && rm -rf 'docs/developers/references/aztec-nr'", + "clean": "./scripts/clean.sh", "serve": "docusaurus serve", "preprocess": "yarn node -r dotenv/config ./src/preprocess/index.js && node src/preprocess/generate_aztecnr_reference.js", "preprocess:dev": "nodemon --config nodemon.json ./src/preprocess/index.js && nodemon --config nodemon.json src/preprocess/generate_aztecnr_reference.js ", - "typedoc": "rm -rf docs/apis && docusaurus generate-typedoc && cp -a docs/apis processed-docs/", - "typedoc:dev": "nodemon -w ../yarn-project -e '*.js,*.ts,*.nr,*.md' --exec \"rm -rf docs/apis && yarn docusaurus generate-typedoc && cp -a docs/apis processed-docs/\"", - "write-translations": "docusaurus write-translations", - "write-heading-ids": "docusaurus write-heading-ids" + "typedoc": "docusaurus generate-typedoc" }, "dependencies": { "@docusaurus/core": "^3.0.1", diff --git a/docs/scripts/build.sh b/docs/scripts/build.sh index ead793d4968..d884bcdf3d5 100755 --- a/docs/scripts/build.sh +++ b/docs/scripts/build.sh @@ -45,10 +45,16 @@ if [ -n "$NETLIFY" ]; then yarn fi +# Clean +echo Cleaning... +yarn clean + # Now build the docsite echo Building docsite... -echo "Generating Aztec.nr reference docs..." -node ./src/preprocess/generate_aztecnr_reference.js -echo "Generated Aztec.nr reference docs" +echo "Processing..." +yarn preprocess +yarn typedoc +sh scripts/move_processed.sh -yarn preprocess && yarn typedoc && yarn docusaurus build +echo "Building..." +yarn docusaurus build diff --git a/docs/scripts/clean.sh b/docs/scripts/clean.sh new file mode 100755 index 00000000000..da22dfd276e --- /dev/null +++ b/docs/scripts/clean.sh @@ -0,0 +1,5 @@ +#!/usr/bin/env bash +rm -rf 'processed-docs' 'processed-docs-cache' +rm -rf docs/reference/aztecjs 'docs/reference/smart_contract_reference/aztec-nr' + +docusaurus clear diff --git a/docs/scripts/move_processed.sh b/docs/scripts/move_processed.sh new file mode 100755 index 00000000000..8a29b13a16e --- /dev/null +++ b/docs/scripts/move_processed.sh @@ -0,0 +1,4 @@ +#!/usr/bin/env bash +echo "label: \"AztecJS\"" > ./docs/reference/aztecjs/_category_.yml +mv ./docs/reference/aztecjs ./processed-docs/reference/aztecjs +mv ./docs/reference/smart_contract_reference/aztec-nr ./processed-docs/reference/smart_contract_reference/aztec-nr diff --git a/docs/sidebars.js b/docs/sidebars.js index e8adcdc8704..1b84e84f303 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -1,82 +1,45 @@ -/** - * Creating a sidebar enables you to: - - create an ordered group of docs - - render a sidebar for each doc of that group - - provide next/previous navigation - - The sidebars can be generated from the filesystem, or explicitly defined here. - - Create as many sidebars as you want. - */ - // @ts-check const fs = require("fs"); const path = require("path"); -// Load the structured documentation paths -const docsStructurePath = path.join( - __dirname, - "/src/preprocess/AztecnrReferenceAutogenStructure.json" -); -const docsStructure = JSON.parse(fs.readFileSync(docsStructurePath, "utf8")); - -// Function to recursively build sidebar items from the structured documentation -function buildSidebarItemsFromStructure(structure, basePath = "") { - const items = []; - for (const key in structure) { - if (key === "_docs") { - // Base case: add the docs - structure[key].forEach((doc) => { - items.push(`${basePath}/${doc}`); - }); - } else { - // Recursive case: process a subdirectory - const subItems = buildSidebarItemsFromStructure( - structure[key], - `${basePath}/${key}` - ); - items.push({ - type: "category", - label: key.charAt(0).toUpperCase() + key.slice(1), // Capitalize the label - items: subItems, - }); - } - } - return items; -} - -// Build sidebar for AztecNR documentation -const aztecNRSidebar = buildSidebarItemsFromStructure( - docsStructure.AztecNR, - "developers/contracts/references/aztec-nr" -); /** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ export default { sidebar: [ { - type: "autogenerated", - dirName: "aztec", + type: "category", + label: "Aztec", + link: { type: "doc", id: "aztec" }, + items: [{ type: "autogenerated", dirName: "aztec" }], + }, + { + type: "doc", + id: "vision", }, { type: "html", value: '', }, { - type: "autogenerated", - dirName: "getting_started", + type: "category", + label: "Getting Started", + link: { type: "doc", id: "getting_started" }, + items: [{ type: "autogenerated", dirName: "getting_started" }], }, { - type: "autogenerated", - dirName: "tutorials", + type: "category", + label: "Tutorials", + items: [{ type: "autogenerated", dirName: "tutorials" }], }, { - type: "autogenerated", - dirName: "guides", + type: "category", + label: "Guides", + items: [{ type: "autogenerated", dirName: "guides" }], }, { - type: "autogenerated", - dirName: "reference", + type: "category", + label: "Reference", + items: [{ type: "autogenerated", dirName: "reference" }], }, { type: "html", diff --git a/docs/src/components/Disclaimers/_wip_disclaimer.mdx b/docs/src/components/Disclaimers/_wip_disclaimer.mdx index 8d1d33f4405..597f226dc5f 100644 --- a/docs/src/components/Disclaimers/_wip_disclaimer.mdx +++ b/docs/src/components/Disclaimers/_wip_disclaimer.mdx @@ -5,7 +5,7 @@ :::caution Disclaimer We are building Aztec as transparently as we can. The documents published here are living documents. The protocol, sandbox, language, and tools are all subject to change over time. -Please see [here](/aztec/aztec/limitations) for details of known Aztec protocol and Aztec Sandbox limitations. +Please see [here](/aztec/limitations) for details of known Aztec protocol and Aztec Sandbox limitations. If you would like to help us build Aztec: diff --git a/docs/src/preprocess/generate_aztecnr_reference.js b/docs/src/preprocess/generate_aztecnr_reference.js index c2a54ec731b..b0902590663 100644 --- a/docs/src/preprocess/generate_aztecnr_reference.js +++ b/docs/src/preprocess/generate_aztecnr_reference.js @@ -317,36 +317,13 @@ function processFiles(baseDir, outputBaseDir) { fs.mkdirSync(path.dirname(outputFilePath), { recursive: true }); fs.writeFileSync(outputFilePath, markdown); - - // Adjusted to populate docStructure for JSON - const docPathForJson = adjustedPath.replace(/\\/g, "/").replace(".md", ""); - const parts = docPathForJson.split("/"); - let current = docStructure; - - for (let i = 0; i < parts.length - 1; i++) { - current[parts[i]] = current[parts[i]] || {}; - current = current[parts[i]]; - } - - current._docs = current._docs || []; - current._docs.push(parts[parts.length - 1]); }); - - // Write structured documentation paths to JSON - const outputPath = path.join( - __dirname, - "AztecnrReferenceAutogenStructure.json" - ); - fs.writeFileSync( - outputPath, - JSON.stringify({ AztecNR: docStructure }, null, 2) - ); } let baseDir = path.resolve(__dirname, "../../../noir-projects/aztec-nr"); let outputBaseDir = path.resolve( __dirname, - "../../docs/reference/reference/smart_contract_reference/aztec-nr" + "../../docs/reference/smart_contract_reference/aztec-nr" ); console.log(outputBaseDir); processFiles(baseDir, outputBaseDir);