diff --git a/docs/docs/aztec/concepts/accounts/keys.md b/docs/docs/aztec/concepts/accounts/keys.md index 7df96c9c13f..168ff03c07c 100644 --- a/docs/docs/aztec/concepts/accounts/keys.md +++ b/docs/docs/aztec/concepts/accounts/keys.md @@ -109,7 +109,7 @@ In the following section we describe a few ways how an account contract could be #### Using a private note -Storing the signing public key in a private note makes it accessible from the entrypoint function, which is required to be a private function, and allows for rotating the key when needed. However, keep in mind that reading a private note requires nullifying it to ensure it is up-to-date, so each transaction you send will destroy and recreate the public key. This has the side effect of enforcing a strict ordering across all transactions, since each transaction will refer the instantiation of the private note from the previous one. +Storing the signing public key in a private note makes it accessible from the entrypoint function, which is required to be a private function, and allows for rotating the key when needed. However, keep in mind that reading a private note requires nullifying it to ensure it is up-to-date, so each transaction you send will destroy and recreate the public key. This has the side effect of enforcing a strict ordering across all transactions, since each transaction will refer to the instantiation of the private note from the previous one. #### Using an immutable private note @@ -122,7 +122,7 @@ A compromise between the two solutions above is to use shared state. This would #### Reusing some of the in-protocol keys It is possible to use some of the key pairs defined in protocol (e.g. incoming viewing keys) as the signing key. -Since this key is part of the address preimage (more on this on the privacy master key section), it can be validated against the account contract address rather than having to store it. +Since this key is part of the address preimage (more on this in the privacy master key section), it can be validated against the account contract address rather than having to store it. However, this approach is not recommended since it reduces the security of the user's account. #### Using a separate keystore diff --git a/docs/docs/aztec/concepts/circuits/index.md b/docs/docs/aztec/concepts/circuits/index.md index 606d7ca54a4..69b2e70499c 100644 --- a/docs/docs/aztec/concepts/circuits/index.md +++ b/docs/docs/aztec/concepts/circuits/index.md @@ -17,7 +17,7 @@ In Aztec, circuits come from two sources: 1. Core protocol circuits 2. User-written circuits (written as Aztec.nr Contracts and deployed to the network) -This page focusses on the core protocol circuits. These circuits check that the rules of the protocol are being adhered to. +This page focuses on the core protocol circuits. These circuits check that the rules of the protocol are being adhered to. When a function in an Ethereum smart contract is executed, the EVM performs checks to ensure that Ethereum's transaction rules are being adhered-to correctly. Stuff like: diff --git a/docs/docs/aztec/concepts/pxe/acir_simulator.md b/docs/docs/aztec/concepts/pxe/acir_simulator.md index 020dbdb812a..385e95c070b 100644 --- a/docs/docs/aztec/concepts/pxe/acir_simulator.md +++ b/docs/docs/aztec/concepts/pxe/acir_simulator.md @@ -28,7 +28,7 @@ Public functions can call other public functions as well as private functions. P ### Unconstrained Functions -Unconstrained functions are used to extract useful data for users, such as the user balance. They are not proved, and are simulated client-side. +Unconstrained functions are used to extract useful data for users, such as the user balance. They are not proven, and are simulated client-side. They are run with the assistance of a DB oracle that provides any private data requested by the function. diff --git a/docs/docs/aztec/glossary/call_types.md b/docs/docs/aztec/glossary/call_types.md index efdbd2bd26b..0bd73fcfd41 100644 --- a/docs/docs/aztec/glossary/call_types.md +++ b/docs/docs/aztec/glossary/call_types.md @@ -112,7 +112,7 @@ Since the public call is made asynchronously, any return values or side effects #include_code enqueue_public /noir-projects/noir-contracts/contracts/lending_contract/src/main.nr rust -It is also possible to create public functions that can _only_ be invoked by privately enqueueing a call from the same contract, which can very useful to update public state after private execution (e.g. update a token's supply after privately minting). This is achieved by annotating functions with `#[internal]`. +It is also possible to create public functions that can _only_ be invoked by privately enqueueing a call from the same contract, which can be very useful to update public state after private execution (e.g. update a token's supply after privately minting). This is achieved by annotating functions with `#[internal]`. A common pattern is to enqueue public calls to check some validity condition on public state, e.g. that a deadline has not expired or that some public value is set.