diff --git a/docs/docs/dev_docs/contracts/common_errors.md b/docs/docs/dev_docs/contracts/common_errors.md deleted file mode 100644 index 8bf3ea8021fa..000000000000 --- a/docs/docs/dev_docs/contracts/common_errors.md +++ /dev/null @@ -1,53 +0,0 @@ -# Common Errors - -There are two kinds of errors: errors in an Aztec.nr contract, and errors spat out by an Aztec Sandbox node! -This section will provide an overview of the errors you might encounter, and how to fix them. - -### Assertion Error - -This error is thrown when a condition is not met. - -This is what the error typically looks like: -``` -Simulation error: Assertion failed: Balance too low 'sum == amount' -``` - -To address the error. find the line in the contract that is throwing the error and investigate why the condition is not met. - -### Unknown Contract Error -This error occurs when you are trying to interact with a smart contract via an Private Execution Environment (PXE) that does not have the necessary information to execute a transaction. - -This is what the error typically looks like: -``` -Unknown contract 0x1d206be10b873b78b875259e1a8c39e2212e2f181d2fd0b0407446487deba522: add it to PXE by calling server.addContracts(...) -``` - -To execute a transaction, the PXE needs to know the complete address of a contract, portal address (if portal is used) and contract artifacts. - -To address the error, add the contract to the PXE by calling `server.addContracts(...)`. - -### No Public Key Registered Error -This error occurs when your contract is trying to get a public key via the `get_public_key` oracle call, but the PXE does not have the Complete Address (Complete Address contains the public key). - -This is what the error typically looks like: -``` -Simulation error: No public key registered for address 0x0d179a5f9bd4505f7dfb8ca37d64e0bd0cd31b5cb018e252fd647bdf88959b95. Register it by calling pxe.registerRecipient(...) or pxe.registerAccount(...) -``` - -Your contract typically needs a note recipient's public key when it wants to send a note to because the public key is used to encrypt notes. - -:::info -Manually adding the recipient to the PXE should not be required in case the recipient contract has already been deployed and the PXE is fully synced. -This is because this information is submitted on-chain when the recipient contract is deployed. -::: - -### Unknown account -This error occurs when your contract is trying to get a secret via the `get_secret` oracle call, but the PXE does not have the secret for the public key. - -This is what the error typically looks like: -``` -Could not process note because of "Error: Unknown account.". Skipping note... -``` - -This error might occur when you register an account only as a recipient and not as an account. -To address the error, register the account by calling `server.registerAccount(...)`. \ No newline at end of file diff --git a/docs/docs/dev_docs/contracts/resources/dependencies.md b/docs/docs/dev_docs/contracts/resources/dependencies.md new file mode 100644 index 000000000000..35f60ee3c679 --- /dev/null +++ b/docs/docs/dev_docs/contracts/resources/dependencies.md @@ -0,0 +1,59 @@ +--- +title: Dependencies +--- + +On this page you will find information about Aztec.nr dependencies and up-to-date paths for use in your `Nargo.toml`. + +## Aztec + +```toml +aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="yarn-project/aztec-nr/aztec" } +``` + +This is the core Aztec library that is required for every Aztec.nr smart contract. + +## Authwit + +```toml +authwit = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="yarn-project/aztec-nr/authwit"} +``` + +This allows you to use authentication witnesses in your contract. Find more about its usage [here](../resources/common_patterns/authwit.md). + +## Address note + +```toml +address_note = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="yarn-project/aztec-nr/address-note" } +``` + +## Assets + +```toml +assets = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="yarn-project/aztec-nr/assets" } +``` + +This is a library for utilizing notes that hold addresses. Find it on [GitHub](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/aztec-nr/address-note/src). + +## Easy private state + +```toml +easy_private_state = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="yarn-project/aztec-nr/easy-private-state" } +``` + +This is an abstraction library for using private variables like [`EasyPrivateUint`](https://github.com/AztecProtocol/aztec-packages/blob/6c20b45993ee9cbd319ab8351e2722e0c912f427/yarn-project/aztec-nr/easy-private-state/src/easy_private_state.nr#L17). + +## Safe math + +```toml +safe_math = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="yarn-project/aztec-nr/safe-math" } +``` + +This is a library for safe arithmetic, similar to OpenZeppelin's safe math library. Find it on [GitHub](https://github.com/AztecProtocol/aztec-packages/tree/master/yarn-project/aztec-nr/safe-math). + +## Value note + +```toml +value_note = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="yarn-project/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/writing_token_contract.md). diff --git a/docs/docs/dev_docs/debugging/aztecnr-errors.md b/docs/docs/dev_docs/debugging/aztecnr-errors.md new file mode 100644 index 000000000000..879aa27676f2 --- /dev/null +++ b/docs/docs/dev_docs/debugging/aztecnr-errors.md @@ -0,0 +1,78 @@ +--- +title: Aztec.nr Errors +--- + +This section contains some errors that you may encounter when writing and compiling contracts in Aztec.nr. If you run into an error that is not listed here, please [create an issue](https://github.com/AztecProtocol/aztec-packages/issues/new). + +#### `Aztec dependency not found. Please add aztec as a dependency in your Nargo.toml` + +All smart contracts written in Aztec.nr need the `aztec` dependency. In your `Nargo.toml` under `[dependencies]`, add this: + +```toml +aztec = { git="https://github.com/AztecProtocol/aztec-packages/", tag="#include_aztec_version", directory="yarn-project/aztec-nr/aztec" } +``` + +You can learn more about dependencies and their paths [here](../contracts/resources/dependencies.md). + +#### `compute_note_hash_and_nullifier function not found. Define it in your contract` + +Any smart contract that utilizes private varibles must include a [`compute_note_hash_and_nullifier`](https://github.com/AztecProtocol/aztec-packages/blob/6c20b45993ee9cbd319ab8351e2722e0c912f427/yarn-project/aztec-nr/aztec/src/note/utils.nr#L69) function to allow the PXE to process encrypted events. + +This is an example of this function in the token contract: + +#include_code compute_note_hash_and_nullifier yarn-project/noir-contracts/src/contracts/token_contract/src/main.nr rust + +This error may also show if the `compute_note_hash_and_nullifier` function is not correct or sits outside of the contract. + +#### `backend has encountered an error` + +This is likely due to a version mismatch or bad install of barretenberg. Try [reinstalling nargo](../cli/updating.md) or uninstalling barretenberg: + +```bash +nargo backend uninstall acvm-backend-barretenberg +``` + +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](../contracts/resources/dependencies.md). + +#### `error: Failed constraint: 'Public state writes only supported in public functions` + +Reading and writing to public state from private functions is currently not supported. +This is because public values may change before the private function execution is posted on-chain. + +This may change in future versions. + +#### `Simulation error: Assertion failed:...` + +This is an assertion error that is thrown when a condition is not met. + +To address the error. find the line in the contract that is throwing the error and investigate why the condition is not met. + +#### `Unknown contract 0x0: add it to PXE by calling server.addContracts(...)` + +This error occurs when you are trying to interact with a smart contract via an Private Execution Environment (PXE) that does not have the necessary information to execute a transaction. + +To execute a transaction, the PXE needs to know the complete address of a contract, portal address (if portal is used) and contract artifacts. + +To address the error, add the contract to the PXE by calling [`pxe.addContracts(...)`](../../apis/pxe/interfaces/PXE#addcontracts). + +`Simulation error: No public key registered for address 0x0. Register it by calling pxe.registerRecipient(...) or pxe.registerAccount(...)` + +This error occurs when your contract is trying to get a public key via the `get_public_key` oracle call, but the PXE does not have the Complete Address (Complete Address contains the public key). + +Your contract typically needs a note recipient's public key when it wants to send a note to because the public key is used to encrypt notes. + +:::info +Manually adding the recipient to the PXE should not be required in case the recipient contract has already been deployed and the PXE is fully synced. +This is because this information is submitted on-chain when the recipient contract is deployed. +::: + +#### `Could not process note because of "Error: Unknown account.". Skipping note...` + +This error occurs when your contract is trying to get a secret via the `get_secret` oracle call, but the PXE does not have the secret for the public key. + +This error might occur when you register an account only as a recipient and not as an account. +To address the error, register the account by calling `server.registerAccount(...)`. diff --git a/docs/docs/dev_docs/debugging/main.md b/docs/docs/dev_docs/debugging/main.md new file mode 100644 index 000000000000..40702df6895c --- /dev/null +++ b/docs/docs/dev_docs/debugging/main.md @@ -0,0 +1,9 @@ +--- +title: Debugging +--- + +import DocCardList from '@theme/DocCardList'; + +On this section you can learn how to debug your Aztec.nr smart contracts and common errors that you may run into. + + diff --git a/docs/docs/dev_docs/sandbox_errors/main.md b/docs/docs/dev_docs/debugging/sandbox-errors.md similarity index 66% rename from docs/docs/dev_docs/sandbox_errors/main.md rename to docs/docs/dev_docs/debugging/sandbox-errors.md index a231daa0e727..c1a8e18d26d8 100644 --- a/docs/docs/dev_docs/sandbox_errors/main.md +++ b/docs/docs/dev_docs/debugging/sandbox-errors.md @@ -8,160 +8,195 @@ import Disclaimer from '../../misc/common/\_disclaimer.mdx'; This section contains a list of errors you may encounter when using Aztec Sandbox and an explanation of each of them. ## Circuit Errors + **To prevent bloating this doc, here is a list of some of the common errors. Feel free to have a look at [circuit_errors.hpp](https://github.com/AztecProtocol/aztec-packages/blob/master/circuits/cpp/src/aztec3/utils/circuit_errors.hpp) for a list of all possible circuit errors.** ### Kernel Circuits -We have several versions of public and private kernels as explained in [our circuits section](../../concepts/advanced/circuits/main.md). 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. +We have several versions of public and private kernels as explained in [our circuits section](../../concepts/advanced/circuits/kernels/main.md). 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. + +#### 2002 - PRIVATE_KERNEL\_\_INVALID_CONTRACT_ADDRESS -#### 2002 - PRIVATE_KERNEL__INVALID_CONTRACT_ADDRESS -Cannot call contract at address(0x0) privately. +Cannot call contract at address(0x0) privately. This error may also happen when you deploy a new contract and the contract data hash is inconsistent to the expected contract address. -#### 2005 - PRIVATE_KERNEL__NEW_COMMITMENTS_PROHIBITED_IN_STATIC_CALL +#### 2005 - PRIVATE_KERNEL\_\_NEW_COMMITMENTS_PROHIBITED_IN_STATIC_CALL + For static calls, new commitments aren't allowed -#### 2006 - PRIVATE_KERNEL__NEW_NULLIFIERS_PROHIBITED_IN_STATIC_CALL +#### 2006 - PRIVATE_KERNEL\_\_NEW_NULLIFIERS_PROHIBITED_IN_STATIC_CALL + For static calls, new nullifiers aren't allowed -#### 2009 - PRIVATE_KERNEL__NON_PRIVATE_FUNCTION_EXECUTED_WITH_PRIVATE_KERNEL +#### 2009 - PRIVATE_KERNEL\_\_NON_PRIVATE_FUNCTION_EXECUTED_WITH_PRIVATE_KERNEL + You cannot execute a public Aztec.nr function in the private kernel -#### 2011 - PRIVATE_KERNEL__UNSUPPORTED_OP +#### 2011 - PRIVATE_KERNEL\_\_UNSUPPORTED_OP + You are trying to do something that is currently unsupported in the private kernel. If this is a blocker feel free to open up an issue on our monorepo [aztec3-packages](https://github.com/AztecProtocol/aztec3-packages/tree/master) or reach out to us on discord Note that certain operations are unsupported on certain versions of the private kernel. Eg static calls are allowed for all but the initial iteration of the private kernel (which initializes the kernel for subsequent function calls). -#### 2012 - PRIVATE_KERNEL__CONTRACT_ADDRESS_MISMATCH +#### 2012 - PRIVATE_KERNEL\_\_CONTRACT_ADDRESS_MISMATCH + For the initial iteration of the private kernel, only the expected Aztec.nr contract should be the entrypoint. Static and delegate calls are not allowed in the initial iteration. -#### 2013 - PRIVATE_KERNEL__NON_PRIVATE_KERNEL_VERIFIED_WITH_PRIVATE_KERNEL +#### 2013 - PRIVATE_KERNEL\_\_NON_PRIVATE_KERNEL_VERIFIED_WITH_PRIVATE_KERNEL + The previous kernel iteration within the private kernel must also be private -#### 2014 - PRIVATE_KERNEL__CONSTRUCTOR_EXECUTED_IN_RECURSION +#### 2014 - PRIVATE_KERNEL\_\_CONSTRUCTOR_EXECUTED_IN_RECURSION + A constructor must be executed as the first tx in the recursion i.e. a constructor call must be the first item in the call stack i.e. it can be executed in the first kernel iteration but not in subsequent ones. This also means you can't have a contract deploy another contract yet on Aztec. -#### 2017 - PRIVATE_KERNEL__USER_INTENT_MISMATCH_BETWEEN_TX_REQUEST_AND_CALL_STACK_ITEM +#### 2017 - PRIVATE_KERNEL\_\_USER_INTENT_MISMATCH_BETWEEN_TX_REQUEST_AND_CALL_STACK_ITEM + Confirms that the TxRequest (user's intent) matches the private call being executed. This error may happen when: -* origin address of tx_request doesn't match call_stack_item's contract_address -* tx_request.function_data doesn't match call_stack_item.function_data -* Aztec.nr function args passed to tx_request doesn't match args in the call_stack_item -#### 2018 - PRIVATE_KERNEL__READ_REQUEST_NOTE_HASH_TREE_ROOT_MISMATCH -Given a read request and provided witness, we check that the merkle root obtained from the witness' sibling path and it's leaf is similar to the historic state root we want to read against. This is a sanity check to ensure we are reading from the right state. -For a non transient read, we fetch the merkle root from the membership witnesses and the leaf index +- origin address of tx_request doesn't match call_stack_item's contract_address +- tx_request.function_data doesn't match call_stack_item.function_data +- Aztec.nr function args passed to tx_request doesn't match args in the call_stack_item + +#### 2018 - PRIVATE_KERNEL\_\_READ_REQUEST_NOTE_HASH_TREE_ROOT_MISMATCH + +Given a read request and provided witness, we check that the merkle root obtained from the witness' sibling path and it's leaf is similar to the historic state root we want to read against. This is a sanity check to ensure we are reading from the right state. +For a non transient read, we fetch the merkle root from the membership witnesses and the leaf index + +#### 2019 - PRIVATE_KERNEL\_\_TRANSIENT_READ_REQUEST_NO_MATCH -#### 2019 - PRIVATE_KERNEL__TRANSIENT_READ_REQUEST_NO_MATCH A pending commitment is the one that is not yet added to note hash tree. A transient read is when we try to "read" a pending commitment. This error happens when you try to read a pending commitment that doesn't exist. -#### 2021 - PRIVATE_KERNEL__UNRESOLVED_NON_TRANSIENT_READ_REQUEST +#### 2021 - PRIVATE_KERNEL\_\_UNRESOLVED_NON_TRANSIENT_READ_REQUEST + For a transient read request we skip merkle membership checks since pending commitments aren't inserted into the note hash tree yet. But for non transient reads, we do a merkle membership check. Redas are done at the kernel circuit. So this checks that there are no already unresolved reads from a previous kernel iteration (other than non transient ones). -#### 3001 - PUBLIC_KERNEL__UNSUPPORTED_OP +#### 3001 - PUBLIC_KERNEL\_\_UNSUPPORTED_OP + You are trying to do something that is currently unsupported in the public kernel. If this is a blocker feel free to open up an issue on our monorepo [aztec3-packages](https://github.com/AztecProtocol/aztec3-packages/tree/master) or reach out to us on discord -#### 3002 - PUBLIC_KERNEL__PRIVATE_FUNCTION_NOT_ALLOWED -Calling a private Aztec.nr function in a public kernel is not allowed. +#### 3002 - PUBLIC_KERNEL\_\_PRIVATE_FUNCTION_NOT_ALLOWED + +Calling a private Aztec.nr function in a public kernel is not allowed. + +#### 3005 - PUBLIC_KERNEL\_\_NON_EMPTY_PRIVATE_CALL_STACK -#### 3005 - PUBLIC_KERNEL__NON_EMPTY_PRIVATE_CALL_STACK Public functions are executed after all the private functions are (see [private-public execution](../../concepts/foundation/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 +#### 3011 - PUBLIC_KERNEL\_\_CALCULATED_PRIVATE_CALL_HASH_AND_PROVIDED_PRIVATE_CALL_HASH_MISMATCH + When the hash stored at the top most of the call stack is different to the call stack item expected by the public kernel's inputs. -#### 3012 - PUBLIC_KERNEL__PUBLIC_CALL_STACK_MISMATCH +#### 3012 - PUBLIC_KERNEL\_\_PUBLIC_CALL_STACK_MISMATCH + Similar to above, except here we actually have the preimages to the call stack and hash to ensure they match. -#### 3013 - PUBLIC_KERNEL__CONTRACT_DEPLOYMENT_NOT_ALLOWED +#### 3013 - PUBLIC_KERNEL\_\_CONTRACT_DEPLOYMENT_NOT_ALLOWED + Public kernel doesn't allow contract deployments -#### 3014 - PUBLIC_KERNEL__CONSTRUCTOR_NOT_ALLOWED +#### 3014 - PUBLIC_KERNEL\_\_CONSTRUCTOR_NOT_ALLOWED + Aztec doesn't support public constructors. -#### 3015 - PUBLIC_KERNEL__CONTRACT_ADDRESS_INVALID +#### 3015 - PUBLIC_KERNEL\_\_CONTRACT_ADDRESS_INVALID + Calling `address(0x0)` publicly is not permitted. -#### 3016 - PUBLIC_KERNEL__FUNCTION_SIGNATURE_INVALID -Cannot call a contract with no function (i.e. function signature of 0) publicly. +#### 3016 - PUBLIC_KERNEL\_\_FUNCTION_SIGNATURE_INVALID + +Cannot call a contract with no function (i.e. function signature of 0) publicly. -#### 3022 - PUBLIC_KERNEL__PUBLIC_CALL_STACK_CONTRACT_STORAGE_UPDATES_PROHIBITED_FOR_STATIC_CALL -For static calls, no contract storage change requests are allowed. +#### 3022 - PUBLIC_KERNEL\_\_PUBLIC_CALL_STACK_CONTRACT_STORAGE_UPDATES_PROHIBITED_FOR_STATIC_CALL + +For static calls, no contract storage change requests are allowed. + +#### 3024 - PUBLIC_KERNEL\_\_CALL_CONTEXT_CONTRACT_STORAGE_UPDATE_REQUESTS_PROHIBITED_FOR_STATIC_CALL -#### 3024 - PUBLIC_KERNEL__CALL_CONTEXT_CONTRACT_STORAGE_UPDATE_REQUESTS_PROHIBITED_FOR_STATIC_CALL Same as [3022](#3022---public_kernel__public_call_stack_contract_storage_updates_prohibited_for_static_call), no contract changes are allowed for static calls. -#### 3026 - PUBLIC_KERNEL__NEW_COMMITMENTS_PROHIBITED_IN_STATIC_CALL +#### 3026 - PUBLIC_KERNEL\_\_NEW_COMMITMENTS_PROHIBITED_IN_STATIC_CALL + For static calls, no new commitments or nullifiers can be added to the state. -#### 3027 - PUBLIC_KERNEL__NEW_NULLIFIERS_PROHIBITED_IN_STATIC_CALL +#### 3027 - PUBLIC_KERNEL\_\_NEW_NULLIFIERS_PROHIBITED_IN_STATIC_CALL + For static calls, no new commitments 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](../../concepts/advanced/circuits/rollup_circuits/main.md) for more information. -#### 4007 - BASE__INVALID_CHAIN_ID -The L1 chain ID you used in your proof generation (for your private transaction) is different to what the rollup circuits expected. Double check against the global variables passed to noir and the config set in [Aztec's rollup contract](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/Rollup.sol) which are [read in by sequencer](https://github.com/AztecProtocol/aztec3-packages/blob/master/yarn-project/sequencer-client/src/global_variable_builder/global_builder.ts#L32) and subsequently passed in as inputs to the base rollup. When the sequencer submits the block to the rollup contracts, this is again sanity checked so ensure this is the same everywhere. +#### 4007 - BASE\_\_INVALID_CHAIN_ID + +The L1 chain ID you used in your proof generation (for your private transaction) is different to what the rollup circuits expected. Double check against the global variables passed to noir and the config set in [Aztec's rollup contract](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/Rollup.sol) which are [read in by sequencer](https://github.com/AztecProtocol/aztec3-packages/blob/master/yarn-project/sequencer-client/src/global_variable_builder/global_builder.ts#L32) and subsequently passed in as inputs to the base rollup. When the sequencer submits the block to the rollup contracts, this is again sanity checked so ensure this is the same everywhere. + +#### 4008 - BASE\_\_INVALID_VERSION -#### 4008 - BASE__INVALID_VERSION 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](../../concepts/advanced/data_structures/indexed_merkle_tree.md)) 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 #### 7009 - ARRAY_OVERFLOW + Circuits work by having a fixed size array. As such, we have limits on how many UTXOs can be created (aka "commitments") or destroyed/nullified (aka "nullifiers") in a transaction. Similarly we have limits on many reads or writes you can do, how many contracts you can create in a transaction. This error typically says that you have reached the current limits of what you can do in a transaction. Some examples when you may hit this error are: -* too many new commitments in one tx -* too many new nullifiers in one tx - - Note: Nullifiers may be created even outside the context of your Aztec.nr code. Eg, when creating a contract, we add a nullifier for its address to prevent same address from ever occurring. Similarly, we add a nullifier for your transaction hash too. -* too many private function calls in one tx (i.e. call stack size exceeded) -* too many public function calls in one tx (i.e. call stack size exceeded) -* too many new L2 to L1 messages in one tx -* too many contracts created in one tx -* too many public data update requests in one tx -* too many public data reads in one tx -* too many transient read requests in one tx -* too many transient read request membership witnesses in one tx +- too many new commitments in one tx +- too many new nullifiers in one tx + - Note: Nullifiers may be created even outside the context of your Aztec.nr code. Eg, when creating a contract, we add a nullifier for its address to prevent same address from ever occurring. Similarly, we add a nullifier for your transaction hash too. +- too many private function calls in one tx (i.e. call stack size exceeded) +- too many public function calls in one tx (i.e. call stack size exceeded) +- too many new L2 to L1 messages in one tx +- too many contracts created in one tx +- too many public data update requests in one tx +- too many public data reads in one tx +- too many transient read requests in one tx +- too many transient read request membership witnesses in one tx You can have a look at our current constants/limitations in [constants.hpp](https://github.com/AztecProtocol/aztec-packages/blob/master/circuits/cpp/src/aztec3/constants.hpp) #### 7008 - MEMBERSHIP_CHECK_FAILED + Users may create a proof against a historic state in Aztec. The rollup circuits performs a merkle membership check to ensure this state existed at some point. If the historic state doesn't exist, you get this error. Some examples when you may hit this error are: -* using invalid historic note hash tree state (aka historic commitments tree) -* using invalid historic contracts data tree state -* using invalid historic L1 to L2 message data tree state -* inserting a subtree into the greater tree - - we make a smaller merkle tree of all the new commitments/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](../../concepts/advanced/data_structures/indexed_merkle_tree.md). 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. +- using invalid historic note hash tree state (aka historic commitments tree) +- using invalid historic contracts data tree state +- using invalid historic L1 to L2 message data tree state +- inserting a subtree into the greater tree + - we make a smaller merkle tree of all the new commitments/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](../../concepts/advanced/data_structures/indexed_merkle_tree.md). 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. --- ## Archiver Errors -* "L1 to L2 Message with key ${messageKey.toString()} not found in the confirmed messages store" - happens when the L1 to L2 message doesn't exist or is "pending", when the user has sent a message on L1 via the Inbox contract but it has yet to be included in an L2 block by the sequencer - user has to wait for sequencer to pick it up and the archiver to sync the respective L2 block. You can get the sequencer to pick it up by doing an arbitary transaction on L2 (eg send DAI to yourself). This would give the sequencer a transaction to process and as a side effect it would look for any pending messages it should include. -* "Unable to remove message: L1 to L2 Message with key ${messageKeyBigInt} not found in store" - happens when trying to confirm a non-existent pending message or cancelling such a message. Perhaps the sequencer has already confirmed the message? +- "L1 to L2 Message with key ${messageKey.toString()} not found in the confirmed messages store" - happens when the L1 to L2 message doesn't exist or is "pending", when the user has sent a message on L1 via the Inbox contract but it has yet to be included in an L2 block by the sequencer - user has to wait for sequencer to pick it up and the archiver to sync the respective L2 block. You can get the sequencer to pick it up by doing an arbitary transaction on L2 (eg send DAI to yourself). This would give the sequencer a transaction to process and as a side effect it would look for any pending messages it should include. + +- "Unable to remove message: L1 to L2 Message with key ${messageKeyBigInt} not found in store" - happens when trying to confirm a non-existent pending message or cancelling such a message. Perhaps the sequencer has already confirmed the message? -* "Block number mismatch: expected ${l2BlockNum} but got ${block.number}" - The archiver keeps track of the next expected L2 block number. It throws this error if it got a different one when trying to sync with the rollup contract's events on L1. +- "Block number mismatch: expected ${l2BlockNum} but got ${block.number}" - The archiver keeps track of the next expected L2 block number. It throws this error if it got a different one when trying to sync with the rollup contract's events on L1. ## Sequencer Errors -* "Calldata hash mismatch" - the sequencer assembles a block and sends it to the rollup circuits for proof generation. Along with the proof, the circuits return the hash of the calldata that must be sent to the Rollup contract on L1. Before doing so, the sequencer sanity checks that this hash is equivalent to the calldata hash of the block that it submitted. This could be a bug in our code e.g. if we are ordering things differently in circuits and in our transaction/block (e.g. incorrect ordering of encrypted logs or queued public calls). Easiest way to debug this is by printing the calldata of the block both on the TS (in l2Block.getCalldataHash()) and C++ side (in the base rollup) -* "${treeName} tree root mismatch" - like with calldata mismatch, it validates that the root of the tree matches the output of the circuit simulation. The tree name could be Public data tree, Note Hash Tree, Contract tree, Nullifier tree or the L1ToL2Message tree, +- "Calldata hash mismatch" - the sequencer assembles a block and sends it to the rollup circuits for proof generation. Along with the proof, the circuits return the hash of the calldata that must be sent to the Rollup contract on L1. Before doing so, the sequencer sanity checks that this hash is equivalent to the calldata hash of the block that it submitted. This could be a bug in our code e.g. if we are ordering things differently in circuits and in our transaction/block (e.g. incorrect ordering of encrypted logs or queued public calls). Easiest way to debug this is by printing the calldata of the block both on the TS (in l2Block.getCalldataHash()) and C++ side (in the base rollup) -* "${treeName} tree next available leaf index mismatch" - validating a tree's root is not enough. It also checks that the `next_avaliable_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. +- "${treeName} tree root mismatch" - like with calldata mismatch, it validates that the root of the tree matches the output of the circuit simulation. The tree name could be Public data tree, Note Hash Tree, Contract tree, Nullifier tree or the L1ToL2Message tree, -* "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](../../concepts/foundation/communication/public_private_calls.md)). This error says there are too many public functions requested. +- "${treeName} tree next available leaf index mismatch" - validating a tree's root is not enough. It also checks that the `next_avaliable_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. -* "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) +- "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](../../concepts/foundation/communication/public_private_calls.md)). This error says there are too many public functions requested. -* "Failed to publish block" - Happens when sequencer tries to submit its L2 block + proof to the rollup contract. Use the CLI to find any solidity error and then refer the [Contract errors section](#l1-aztec-contract-errors). +- "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) + +- "Failed to publish block" - Happens when sequencer tries to submit its L2 block + proof to the rollup contract. Use the CLI to find any solidity error and then refer the [Contract errors section](#l1-aztec-contract-errors). ## L1 Aztec Contract Errors -Aztec's L1 contracts use custom errors in solidity. While it saves gas, it has a side effect of making it harder to decode when things go wrong. If you get an error when submitting an L2Block into our rollup contract or when interacting with our Inbox/Outbox contracts, you can use the [Errors.sol library](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/libraries/Errors.sol) to match the hex encoded error to the error name. + +Aztec's L1 contracts use custom errors in solidity. While it saves gas, it has a side effect of making it harder to decode when things go wrong. If you get an error when submitting an L2Block into our rollup contract or when interacting with our Inbox/Outbox contracts, you can use the [Errors.sol library](https://github.com/AztecProtocol/aztec-packages/blob/master/l1-contracts/src/core/libraries/Errors.sol) to match the hex encoded error to the error name. diff --git a/docs/netlify.toml b/docs/netlify.toml index 8e2de855e81d..579c31121605 100644 --- a/docs/netlify.toml +++ b/docs/netlify.toml @@ -182,6 +182,15 @@ from = "/dev_docs/getting_started/updating" to = "/dev_docs/cli/updating" +[[redirects]] + from = "/dev_docs/sandbox_errors/main" + to = "dev_docs/debugging/sandbox-errors" + +[[redirects]] + from = "/dev_docs/contracts/common_errors" + to = "dev_docs/debugging/aztecnr-errors" + + [[redirects]] from = "/misc/aztec-connect-sunset" to = "misc/aztec_connect_sunset" diff --git a/docs/sidebars.js b/docs/sidebars.js index 629d59622e91..0a05d8b34605 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -338,11 +338,11 @@ const sidebars = { "dev_docs/contracts/portals/outbox", ], }, - "dev_docs/contracts/common_errors", { label: "Resources", type: "category", items: [ + "dev_docs/contracts/resources/dependencies", //"dev_docs/contracts/resources/style_guide", { label: "Common Patterns", @@ -384,7 +384,18 @@ const sidebars = { type: "doc", id: "dev_docs/aztecjs/main", }, - + { + label: "Debugging", + type: "category", + link: { + type: "doc", + id: "dev_docs/debugging/main", + }, + items: [ + "dev_docs/debugging/aztecnr-errors", + "dev_docs/debugging/sandbox-errors", + ], + }, { label: "Updating", type: "doc",