diff --git a/docs/docs/developers/contracts/references/slow_updates_tree.md b/docs/docs/developers/contracts/references/slow_updates_tree.md deleted file mode 100644 index a179c54a93d..00000000000 --- a/docs/docs/developers/contracts/references/slow_updates_tree.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: Slow Updates Tree ---- - -## Struct `SlowMap` - -### Overview - -The `SlowMap` struct is used to interact with a slow updates tree deployed via the SlowTree smart contract. - -### Fields - -| Name | Type | Description | -| ------- | ------- | ------------------------------------ | -| address | `Field` | The address of the SlowTree contract | - -## Functions - -### at - -Returns an instance of `SlowMap` at the specified address. - -**Parameters** - -| Name | Type | Description | -| --------- | -------------- | --------------------------- | -| `address` | `AztecAddress` | The address of the SlowTree | - -**Return** - -| Name | Type | Description | -| ---- | --------- | ---------------------- | -| - | `SlowMap` | The `SlowMap` instance | - -**Example** - -#include_code slowmap_at noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -### initialize - -Initializes the `SlowMap`. - -**Parameters** - -| Name | Type | Description | -| --------- | --------------- | --------------------- | -| `context` | `PublicContext` | The execution context | - -**Return** - -| Name | Type | Description | -| ---- | ---- | ----------- | -| - | - | - | - -**Example** - -#include_code slowmap_initialize noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -### read_at_pub - -Reads a value at a specified index from a public function. - -**Parameters** - -| Name | Type | Description | -| --------- | --------------- | --------------------- | -| `context` | `PublicContext` | The execution context | -| `index` | `Field` | The index to read at | - -**Return** - -| Name | Type | Description | -| -------- | ------- | -------------------- | -| `result` | `Field` | The value at `index` | - -**Example** - -#include_code read_at_pub noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -### read_at - -Reads a value at a specified index from a private function. - -**Parameters** - -| Name | Type | Description | -| --------- | ---------------- | --------------------- | -| `context` | `PrivateContext` | The execution context | -| `index` | `Field` | The index to read at | - -**Return** - -| Name | Type | Description | -| -------- | ------- | -------------------- | -| `result` | `Field` | The value at `index` | - -**Example** - -#include_code slowmap_read_at noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -### update_at_private - -Updates a value at a specified index from a private function. Does not return anything. - -**Parameters** - -| Name | Type | Description | -| ----------- | ---------------- | --------------------- | -| `context` | `PrivateContext` | The execution context | -| `index` | `Field` | The index to update | -| `new_value` | `Field` | The new value | - -**Example** - -#include_code get_and_update_private noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -## Updating from public - -This is not a method in the interface as it can be done using regular Aztec.nr public storage update syntax. - -**Example** - -#include_code write_slow_update_public noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust diff --git a/docs/docs/developers/contracts/references/storage/main.md b/docs/docs/developers/contracts/references/storage/main.md index aef6fe7cbf3..439784739f4 100644 --- a/docs/docs/developers/contracts/references/storage/main.md +++ b/docs/docs/developers/contracts/references/storage/main.md @@ -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 (pre-images) are only known by the sender and those able to decrypt them - see ([state model](../../../../learn/concepts/hybrid_state/main.md) and [private/public execution](../../../../learn/concepts/communication/public_private_calls/main.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 (pre-images) are only known by the sender and those able to decrypt them - see ([state model](../../../../learn/concepts/hybrid_state/main.md) and [private/public execution](../../../../learn/concepts/communication/public_private_calls.md)) for more background. ## Storage struct @@ -94,5 +94,5 @@ require(minters[msg.sender], "caller is not minter"); ## Concepts mentioned - [State Model](../../../../learn/concepts/hybrid_state/main.md) -- [Public-private execution](../../../../learn/concepts/communication/public_private_calls/main.md) +- [Public-private execution](../../../../learn/concepts/communication/public_private_calls.md) - [Function Contexts](../../writing_contracts/functions/context.md) diff --git a/docs/docs/developers/contracts/resources/common_patterns/main.md b/docs/docs/developers/contracts/resources/common_patterns/main.md index 39763df867d..66c3b9b9138 100644 --- a/docs/docs/developers/contracts/resources/common_patterns/main.md +++ b/docs/docs/developers/contracts/resources/common_patterns/main.md @@ -38,11 +38,12 @@ Note - you could also create a note and send it to the user. The problem is ther ### Reading public storage in private -You can't read public storage in private domain. But nevertheless reading public storage is desirable. There are two ways: +You can't read public storage in private domain. But nevertheless reading public storage is desirable. This is the naive way: -1. For public storage that changes infrequently, use the slow updates tree! Learn more about it [here](../../../../learn/concepts/communication/public_private_calls/slow_updates_tree.md). + -2. You pass the data as a parameter to your private method and later assert in public that the data is correct. E.g.: +- You pass the data as a parameter to your private method and later assert in public that the data is correct. E.g.: ```rust struct Storage { diff --git a/docs/docs/developers/contracts/writing_contracts/historical_data/archive_tree/how_to_prove_history.md b/docs/docs/developers/contracts/writing_contracts/historical_data/archive_tree/how_to_prove_history.md index 8b604ca6863..e0068c9e9df 100644 --- a/docs/docs/developers/contracts/writing_contracts/historical_data/archive_tree/how_to_prove_history.md +++ b/docs/docs/developers/contracts/writing_contracts/historical_data/archive_tree/how_to_prove_history.md @@ -1,5 +1,5 @@ --- -title: How to use the Arhive Tree +title: How to use the 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](../../../../../learn/concepts/storage/trees/main.md#archive-tree). diff --git a/docs/docs/developers/contracts/writing_contracts/historical_data/slow_updates_tree/implement_slow_updates.md b/docs/docs/developers/contracts/writing_contracts/historical_data/slow_updates_tree/implement_slow_updates.md deleted file mode 100644 index 6de1c8abae6..00000000000 --- a/docs/docs/developers/contracts/writing_contracts/historical_data/slow_updates_tree/implement_slow_updates.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: How to implement a Slow Updates Tree ---- - -To learn more about the Slow Updates Tree, go [here](./main.md) - -On this page you will learn how to implement a slow updates tree into your contract, and an example of a token blacklisting contract that uses the slow updates tree. - -# How to implement a slow updates tree - -1. Store the SlowTree address in private storage as a FieldNote - -#include_code constructor noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -2. Store the SlowTree address in public storage and initialize an instance of SlowMap using this address - -#include_code write_slow_update_public noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -3. Now you can read and update from private functions: - -#include_code get_and_update_private noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -4. Or from public functions: - -#include_code get_public noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -View the [reference](../../../references/slow_updates_tree.md) for more information. - -## Exploring an example integration through a **`TokenBlacklist`** Smart Contract - -The `TokenBlacklist` contract is a token contract that does not allow blacklisted accounts to perform mints or transfers. In this section we will go through how this is achieved through the slow updates tree. - -You can find the full code for the TokenBlacklist smart contract [here](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-contracts/contracts/token_blacklist_contract). - -### Importing SlowMap - -The contract first imports the **`SlowMap`** interface: - -#include_code interface noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -This interface allows the contract to interact with its attached SlowTree. It abstracts these functions so they do not have to be implemented in the TokenBlacklist contract. - -### Constructor and initialization - -The contract's constructor takes the address of the slow updates contract: - -#include_code constructor noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -This initialization sets up the connection between the **`TokenBlacklist`** contract and a previously deployed SlowTree, allowing it to use the interface to directly interact with the SlowTree. - -### Private transfer function utilizing the slow updates tree - -In the private transfer function, the contract uses the interface to check if a user is blacklisted: - -#include_code transfer_private noir-projects/noir-contracts/contracts/token_blacklist_contract/src/main.nr rust - -Here, the contract reads the roles of the sender and recipient from the SlowTree using the **`read_at`** function in the interface. It checks if either party is blacklisted, and if so, the transaction does not go ahead. diff --git a/docs/docs/developers/contracts/writing_contracts/historical_data/slow_updates_tree/main.md b/docs/docs/developers/contracts/writing_contracts/historical_data/slow_updates_tree/main.md deleted file mode 100644 index 4edc82d0537..00000000000 --- a/docs/docs/developers/contracts/writing_contracts/historical_data/slow_updates_tree/main.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Slow Updates Tree ---- - -Slow Updates Tree is a data structure that allows for historical public data to be accessed in both private and public domains. Read the high level overview in the [Communication section](../../../../../learn/concepts/communication/public_private_calls/slow_updates_tree.md). This page explains the components involved. - -If you want to integrate it in your contract, follow this [guide](../slow_updates_tree/implement_slow_updates.md). - -The slow updates tree works by having a current tree and a pending tree, and replacing the current tree with the pending tree after an epoch has passed. Public functions can read directly from the current tree, and private functions can perform a membership proof that values are part of a commitment to the current state of the tree. - -# Components involved in implementing a slow updates tree - -There are generally 4 main components involved to make it easier to use a slow updates tree, with 3 already implemented by Aztec. This makes it easier to interact with a slow updates tree through a simple interface. These four components are: - -## Main smart contract - -This is the primary smart contract that will use the slow updates tree. In the example we use a [token with blacklisting features](./implement_slow_updates.md#exploring-an-example-integration-through-a-tokenblacklist-smart-contract). - -## SlowTree.nr contract - -This is a smart contract developed by Aztec that establishes and manages a slow updates tree structure. It allows developers to access and interact with the tree, such as reading and updating data. - -You can find it [here](https://github.com/AztecProtocol/aztec-packages/tree/master/noir-projects/noir-contracts/contracts/slow_tree_contract). - -## SlowMap type - -This is a type in the Aztec.nr library that is utilized by the SlowTree contract. It defines the underlying data structure for the slow updates tree, and handles storing both the current and pending values for each data entry. - -You can find it [here](https://github.com/AztecProtocol/aztec-nr/blob/master/slow-updates-tree/src/slow_map.nr). - -The diagram below describes how these components work together. It does not contain all the functionality. - -```mermaid -graph TD - MSC[Main Smart Contract] --> INT[Interface] - STC --> SMT - - INT_RAP[read_at_pub] <--> STC_RAP[read_at_public] - INT_RA[read_at] <--> STC_RA[read_at] - INT_UAP[update_at_public] <--> STC_UAP[update_at_public] - INT_UA[update_at_private] <--> STC_UA[update_at_private] - - STC_RA <--> VMP[verify_membership_proof] - STC_UA <--> CR[compute_roots] - - subgraph INT[Interface] - INT_RAP - INT_UAP - INT_RA - INT_UA - end - - subgraph STC[SlowTree.nr] - STC_RAP - STC_UAP - STC_RA - STC_UA - end - - subgraph SMT[SlowMap Type] - Change{Epoch Over} -->|True| Current{Current} - Change -->|False| Pending{Pending} - Current --> Current1[Current Commitment 1] - Current --> CurrentM[Current Commitment M] - CurrentM --> Value1[Current Value 1] - CurrentM --> Value2[Current Value 2] - CurrentM --> ValueN[Current Value N] - Pending --> PendingM[Pending Commitment 1] - PendingM --> PValue1[Pending Value 1] - PendingM --> PValue2[Pending Value 2] - PendingM --> PValueN[Pending Value N] - end - - style INT fill:#fff,stroke:#333,stroke-width:1px - style STC fill:#fff,stroke:#333,stroke-width:1px - style SMT fill:#fff,stroke:#333,stroke-width:1px -``` diff --git a/docs/docs/developers/debugging/sandbox-errors.md b/docs/docs/developers/debugging/sandbox-errors.md index a67ecc3c0c8..212e3d80b6d 100644 --- a/docs/docs/developers/debugging/sandbox-errors.md +++ b/docs/docs/developers/debugging/sandbox-errors.md @@ -86,7 +86,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](../../learn/concepts/communication/public_private_calls/main.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](../../learn/concepts/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 @@ -189,7 +189,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](../../learn/concepts/communication/public_private_calls/main.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](../../learn/concepts/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/learn/about_aztec/technical_overview.md b/docs/docs/learn/about_aztec/technical_overview.md index 7192e34d316..eed3e31f36e 100644 --- a/docs/docs/learn/about_aztec/technical_overview.md +++ b/docs/docs/learn/about_aztec/technical_overview.md @@ -40,7 +40,7 @@ A user of the Aztec network will interact with the network through Aztec.js. Azt ### 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](../concepts/hybrid_state/main.md) from end users, but the state model is important for Aztec developers to understand as it has implications for [private/public execution](../concepts/communication/public_private_calls/main.md) and [L1/L2 communication](../concepts/communication/cross_chain_calls.md). The PXE also includes the [ACIR Simulator](../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](../concepts/hybrid_state/main.md) from end users, but the state model is important for Aztec developers to understand as it has implications for [private/public execution](../concepts/communication/public_private_calls.md) and [L1/L2 communication](../concepts/communication/cross_chain_calls.md). The PXE also includes the [ACIR Simulator](../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](../concepts/nodes_clients/sequencer/main.md), which will update the state of the rollup. diff --git a/docs/docs/learn/concepts/accounts/keys.md b/docs/docs/learn/concepts/accounts/keys.md index ed91e7928fe..5864abdc028 100644 --- a/docs/docs/learn/concepts/accounts/keys.md +++ b/docs/docs/learn/concepts/accounts/keys.md @@ -27,9 +27,15 @@ Storing the signing public key in a private note makes it accessible from the en Similar to using a private note, but using an immutable private note removes the need to nullify the note on every read. This generates less nullifiers and commitments per transaction, and does not enforce an order across transactions. However, it does not allow the user to rotate their key should they lose it. + ### Reusing the privacy master key diff --git a/docs/docs/learn/concepts/accounts/main.md b/docs/docs/learn/concepts/accounts/main.md index 6e75172f0bd..deac366c16c 100644 --- a/docs/docs/learn/concepts/accounts/main.md +++ b/docs/docs/learn/concepts/accounts/main.md @@ -129,7 +129,11 @@ 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 the [slow updates tree](../communication/public_private_calls/slow_updates_tree.md) 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). + + 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/learn/concepts/communication/main.md b/docs/docs/learn/concepts/communication/main.md index 99588c9bc7c..a893fe7484d 100644 --- a/docs/docs/learn/concepts/communication/main.md +++ b/docs/docs/learn/concepts/communication/main.md @@ -4,6 +4,6 @@ title: Contract Communication This section will walk over communication types that behaves differently than normal function calls. -Namely, if functions are in different domains, private vs. public, their execution behaves a little differently to what you might expect! See [Private <--> Public execution](./public_private_calls/main.md). +Namely, if functions are in different domains, private vs. public, their execution behaves a little differently to what you might expect! See [Private <--> Public execution](./public_private_calls.md). Likewise, executing a function on a different domain than its origin needs a bit extra thought. See [L1 <--> L2 communication](./cross_chain_calls.md). diff --git a/docs/docs/learn/concepts/communication/public_private_calls/main.md b/docs/docs/learn/concepts/communication/public_private_calls.md similarity index 81% rename from docs/docs/learn/concepts/communication/public_private_calls/main.md rename to docs/docs/learn/concepts/communication/public_private_calls.md index eca7d2ccb54..2bd3d02e037 100644 --- a/docs/docs/learn/concepts/communication/public_private_calls/main.md +++ b/docs/docs/learn/concepts/communication/public_private_calls.md @@ -1,10 +1,10 @@ --- -title: Private - Public execution +title: Private <> Public Communication --- import Image from "@theme/IdealImage"; -import Disclaimer from "../../../../misc/common/\_disclaimer.mdx"; +import Disclaimer from "../../../misc/common/\_disclaimer.mdx"; @@ -78,32 +78,10 @@ Theoretically the builder has all the state trees after the public function has From the above, we should have a decent idea about what private and public functions can do inside the L2, and how they might interact. + diff --git a/docs/docs/learn/concepts/communication/public_private_calls/slow_updates_tree.md b/docs/docs/learn/concepts/communication/public_private_calls/slow_updates_tree.md deleted file mode 100644 index 1e0d44ae666..00000000000 --- a/docs/docs/learn/concepts/communication/public_private_calls/slow_updates_tree.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Privately access Historical Public Data ---- - -In Aztec, private and public execution environments are completely separate and operate with distinct state management. It is not possible for private functions to reliably access the most recent public data public state - only sequencers can do that. You'll want to [read the previous section](./main.md) to understand this before reading this page. - -But, what about historical public data (or public data that changes infrequently)? Through a **slow updates tree**, private functions can access historical public state. Please note that we are still experimenting with this feature. - -On this page you will learn: - -1. Why a slow updates tree exists & use cases -2. How it works -3. How it can be used to access historical public data -4. Limitations - -## The need for a slow updates tree - -This structure was created specifically to privately & publicly access historical public data. It should be used to store public data that doesn't change often. - -- Access historical public data from a private function -- Access historical public data from a public function -- Update public data (that does not need updated often) from public and private functions - -This data structure is ideal for these use cases: - -- Address Registry: Enabling contracts to interact with other contracts more easily requires address storage accessible in both public and private executions. This can be particularly helpful in things such as proxy contracts. -- Access Control: Managing privileges in contracts, such as a token contract owner’s ability to mint new tokens, is streamlined when control information is shared between public and private executions. This might include things like blacklists and whitelists. - -## How it works - -We developed the Slow Updates Tree to help balance public and private execution in a blockchain context. Earlier systems typically used either fully public or entirely private state trees. - -The Slow Updates Tree is a dual-tree structure - a current tree and a pending tree. Any updates are added to the pending tree, which then becomes the current tree at the end of an epoch. The pending tree is replicated from the current tree, and the cycle begins again. - -```mermaid -graph TD; - Change{Epoch Over} -->|True| Current{Current} - Change -->|False| Pending{Pending} - Current --> Current1[Current Commitment 1] - Current --> CurrentM[Current Commitment 2] - CurrentM --> Value1[Current Value 1] - CurrentM --> Value2[Current Value 2] - CurrentM --> ValueN[Current Value n] - Pending --> PendingM[Pending Note Hash 1] - PendingM --> PValue1[Pending Value 1] - PendingM --> PValue2[Pending Value 2] - PendingM --> PValueN[Pending Value n] -``` - -This way, we can ensure that the values are stable throughout the epoch, and that the membership proofs are not invalidated by changes in other contracts more than once every epoch. - -## Reads and Writes - -### Accessing Data - -*From public state:* Accessed directly from the state -*From private state:* Performs a membership proof for the values in the tree, ensuring that they are part of the commitment. - -### Updating Data - -Updates are made to the pending tree. Then at the end of each epoch, the updates in the pending tree are committed and it becomes the current tree. - -## Limitations - -### Delayed State Finality - -Updates in the Slow Updates Tree are only finalized at the end of an epoch. - -Developers are used to instant state updates, so the Slow Updates Tree might take some getting used to. But we believe this won't take long! - -## Dive into the code - -For a code walkthrough of how a token blacklist contract can use a slow updates tree, read [this](../../../../developers/contracts/writing_contracts/historical_data/slow_updates_tree/implement_slow_updates.md). \ No newline at end of file diff --git a/docs/docs/misc/roadmap/engineering_roadmap.md b/docs/docs/misc/roadmap/engineering_roadmap.md index 2e232a2c023..51e49405774 100644 --- a/docs/docs/misc/roadmap/engineering_roadmap.md +++ b/docs/docs/misc/roadmap/engineering_roadmap.md @@ -19,7 +19,7 @@ The engineering roadmap is long. There are no timings assigned here. In a loose ## Standardization efforts - Recommended Aztec smart contract coding patterns -- Access Control (whitelists/blacklists) - probably needs the Slow Updates tree (or something similar). +- Access Control (whitelists/blacklists) - probably needs the Shared Mutable. - Basic _example_ private tokens - Including recursive calls to 'get_notes'. - Compliant private tokens @@ -117,11 +117,10 @@ CI takes up a significant amount of time. It gets its own section here, so we re - Do a RFC from the external community - Implement -## Slow Updates tree? +## Shared Mutable State -We _need_ a way to read mutable public data from a private function. - -Note: we just published the [Slow Updates Tree](../../learn/concepts/communication/public_private_calls/slow_updates_tree.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. + ## Contract classes and instances? diff --git a/docs/netlify.toml b/docs/netlify.toml index 4a2b63e0e92..736bb7fbec2 100644 --- a/docs/netlify.toml +++ b/docs/netlify.toml @@ -154,6 +154,10 @@ from="/concepts/foundation/communication/public_private_calls" to="/learn/concepts/communication/public_private_calls/main" +[[redirects]] + from="/learn/concepts/communication/public_private_calls/main" + to="/learn/concepts/communication/public_private_calls" + [[redirects]] from = "/aztec/how-it-works/l1-l2-messaging" to = "/learn/concepts/communication/cross_chain_calls" diff --git a/docs/sidebars.js b/docs/sidebars.js index f4725933719..c10514ddbe9 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -138,18 +138,12 @@ const sidebars = { { label: "Communication", type: "category", + link: { + type: "doc", + id: "learn/concepts/communication/main", + }, items: [ - { - label: "Public <> Private Communication", - type: "category", - link: { - type: "doc", - id: "learn/concepts/communication/public_private_calls/main", - }, - items: [ - "learn/concepts/communication/public_private_calls/slow_updates_tree", - ], - }, + "learn/concepts/communication/public_private_calls", "learn/concepts/communication/cross_chain_calls", ], }, @@ -406,29 +400,7 @@ const sidebars = { label: "Historical Data", type: "category", items: [ - { - label: "Historical Blockchain Data (Archive Tree)", - type: "category", - link: { - type: "doc", - id: "developers/contracts/writing_contracts/historical_data/slow_updates_tree/main", - }, - items: [ - "developers/contracts/writing_contracts/historical_data/archive_tree/how_to_prove_history", - ], - }, - ], - }, - { - label: - "Access public data from private state (Slow Updates Tree)", - type: "category", - link: { - type: "doc", - id: "developers/contracts/writing_contracts/historical_data/slow_updates_tree/main", - }, - items: [ - "developers/contracts/writing_contracts/historical_data/slow_updates_tree/implement_slow_updates", + "developers/contracts/writing_contracts/historical_data/archive_tree/how_to_prove_history", ], }, ], @@ -482,7 +454,6 @@ const sidebars = { items: aztecNRSidebar, }, "developers/contracts/references/history_lib_reference", - "developers/contracts/references/slow_updates_tree", ], }, {