diff --git a/docs/docs/dev_docs/contracts/syntax/events.md b/docs/docs/dev_docs/contracts/syntax/events.md index f09a4aa66d47..c50526530f06 100644 --- a/docs/docs/dev_docs/contracts/syntax/events.md +++ b/docs/docs/dev_docs/contracts/syntax/events.md @@ -54,7 +54,7 @@ await aztecRpc.registerRecipient(completeAddress); :::info -If a note recipient is one of the accounts inside the Aztec RPC Server, we don't need to register it as a recipient because we already have the public key available. +If a note recipient is one of the accounts inside the Aztec RPC Server, we don't need to register it as a recipient because we already have the public key available. You can register a recipient as shown [here](../deploying#deploying-private-token-contract) At this point the Sandbox only enables the emitting of encrypted note preimages through encrypted events. In the future we will allow emitting arbitrary information. @@ -71,7 +71,7 @@ Then you can call the function: ### Processing Encrypted Events -One function of Aztec RPC Server is constantly loading encrypted logs from an AztecNode and decrypting them. +One of the functions of the Aztec RPC Server is constantly loading encrypted logs from the `AztecNode` and decrypting them. When new encrypted logs are obtained, the Aztec RPC Server will try to decrypt them using the private encryption key of all the accounts registered inside Aztec RPC Server. If the decryption is successful, the Aztec RPC Server will store the decrypted note inside a database. If the decryption fails, the specific log will be discarded. @@ -126,11 +126,11 @@ aztec-cli get-logs --from 5 --limit 1 All event data is pushed to Ethereum as calldata by the sequencer and for this reason the cost of emitting an event is non-trivial. -:::info -The cost of submitting calldata to Ethereum is currently 4 gas per byte. In the Sandbox, an encrypted note has a fixed overhead of 4 field elements (to broadcast an ephemeral public key, a contract address, and a storage slot); plus a variable number of field elements depending on the type of note being emitted. +In the Sandbox, an encrypted note has a fixed overhead of 4 field elements (to broadcast an ephemeral public key, a contract address, and a storage slot); plus a variable number of field elements depending on the type of note being emitted. A `ValueNote`, for example, currently uses 3 fields elements (plus the fixed overhead of 4). That's roughly `7 * 32 = 224` bytes of information. +#include_code value-note-def /yarn-project/aztec-nr/value-note/src/value_note.nr + - There are plans to compress encrypted note data further. -- There are plans to adopt EIP-4844 blobs to reduce the cost of data submission further. -::: \ No newline at end of file +- There are plans to adopt EIP-4844 blobs to reduce the cost of data submission further. \ No newline at end of file diff --git a/docs/docs/dev_docs/limitations/main.md b/docs/docs/dev_docs/limitations/main.md index 4a5200c2de14..3b8ae640cc3f 100644 --- a/docs/docs/dev_docs/limitations/main.md +++ b/docs/docs/dev_docs/limitations/main.md @@ -31,7 +31,8 @@ Help shape and define: - 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 [constructor](../contracts/syntax/functions.md#constructor). - No static nor delegate calls (see [mutability](../contracts/syntax/functions.md#mutability)). - - There are unused values in the call-context. 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. + - These values are unused in the call-context. + - 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 leaked 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](../contracts/syntax/context.mdx). - The initial `msg_sender` is 0, which can be problematic for some contracts, see [function visibility](../contracts/syntax/functions.md#function-visibility).