From eb04041eb2ebc342e23ddac7037ca835269424de Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 11:44:02 +0200 Subject: [PATCH 01/11] typos field_docs.md --- barretenberg/cpp/src/barretenberg/ecc/fields/field_docs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/barretenberg/cpp/src/barretenberg/ecc/fields/field_docs.md b/barretenberg/cpp/src/barretenberg/ecc/fields/field_docs.md index 912804f408e..1c52ca64813 100644 --- a/barretenberg/cpp/src/barretenberg/ecc/fields/field_docs.md +++ b/barretenberg/cpp/src/barretenberg/ecc/fields/field_docs.md @@ -11,7 +11,7 @@ We use Montgomery reduction to speed up field multiplication. For an original el The goal of using Montgomery form is to avoid heavy division modulo \f$p\f$. To compute a representative of element $$c = a⋅b\ mod\ p$$ we compute $$c⋅R = (a⋅R)⋅(b⋅R) / R\ mod\ p$$, but we use an efficient division trick to avoid straight modular division. Let's look into the standard 4⋅64 case: 1. First, we compute the value $$c_r=c⋅R⋅R = aR⋅bR$$ in integers and get a value with 8 64-bit limbs 2. Then we take the lowest limb of \f$c_r\f$ (\f$c_r[0]\f$) and multiply it by a special value $$r_{inv} = -1 ⋅ p^{-1}\ mod\ 2^{64}$$ As a result we get $$k = r_{inv}⋅ c_r[0]\ mod\ 2^{64}$$ -3. Next we update \f$c_r\f$ in integers by adding a value \f$k⋅p\f$: $$c_r += k⋅p$$ You might notice that the value of \f$c_r\ mod\ p\f$ hasn't changed, since we've added a multiple of the modulus. A the same time, if we look at the expression modulo \f$2^{64}\f$: $$c_r + k⋅p = c_r + c_r⋅r_{inv}⋅p = c_r + c_r⋅ (-1)⋅p^{-1}⋅p = c_r - c_r = 0\ mod\ 2^{64}$$ The result is equivalent modulo \f$p\f$, but we zeroed out the lowest limb +3. Next we update \f$c_r\f$ in integers by adding a value \f$k⋅p\f$: $$c_r += k⋅p$$ You might notice that the value of \f$c_r\ mod\ p\f$ hasn't changed, since we've added a multiple of the modulus. At the same time, if we look at the expression modulo \f$2^{64}\f$: $$c_r + k⋅p = c_r + c_r⋅r_{inv}⋅p = c_r + c_r⋅ (-1)⋅p^{-1}⋅p = c_r - c_r = 0\ mod\ 2^{64}$$ The result is equivalent modulo \f$p\f$, but we zeroed out the lowest limb 4. We perform the same operation for \f$c_r[1]\f$, but instead of adding \f$k⋅p\f$, we add \f$2^{64}⋅k⋅p\f$. In the implementation, instead of adding \f$k⋅ p\f$ to limbs of \f$c_r\f$ starting with zero, we just start with limb 1. This ensures that \f$c_r[1]=0\f$. We then perform the same operation for 2 more limbs. 5. At this stage we are left with a version of \f$c_r\f$ where the first 4 limbs of the total 8 limbs are zero. So if we treat the 4 high limbs as a separate integer \f$c_{r.high}\f$, $$c_r = c_{r.high}⋅2^{256}=c_{r.high}⋅R\ mod\ p \Rightarrow c_{r.high} = c\cdot R\ mod\ p$$ and we can get the evaluation simply by taking the 4 high limbs of \f$c_r\f$. 6. The previous step has reduced the intermediate value of \f$cR\f$ to range \f$[0,2p)\f$, so we must check if it is more than \f$p\f$ and subtract the modulus once if it overflows. From a26c9bd5c881a11463d64924bbb5bde4d44c7b47 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 11:45:48 +0200 Subject: [PATCH 02/11] typos pippenger.md --- barretenberg/cpp/src/barretenberg/ecc/pippenger.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/barretenberg/cpp/src/barretenberg/ecc/pippenger.md b/barretenberg/cpp/src/barretenberg/ecc/pippenger.md index a7463663216..9756ace72e9 100644 --- a/barretenberg/cpp/src/barretenberg/ecc/pippenger.md +++ b/barretenberg/cpp/src/barretenberg/ecc/pippenger.md @@ -24,7 +24,7 @@ For example, let's say that our bit slice is 6 bits. The first round will take t So, for example, if the most significant 6 bits of a scalar are `011001` (25), we add the scalar's point into the 25th bucket. -At the end of each round, we then 'concatenate' all of the buckets into a sum. Let's represent each bucket accumulator in an array `A[num_buckets]`. The concatenation phase will compute `A[0] + 2A[1] + 3A[2] + 4A[3] + 5A[4] + ... = Sum`. +At the end of each round, we then 'concatenate' all the buckets into a sum. Let's represent each bucket accumulator in an array `A[num_buckets]`. The concatenation phase will compute `A[0] + 2A[1] + 3A[2] + 4A[3] + 5A[4] + ... = Sum`. Finally, we add each `Sum` point into an overall accumulator. For example, for a set of 254 bit scalars, if we evaluate the most 6 significant bits of each scalar and accumulate the resulting point into `Sum`, we actually need `(2^{248}).Sum` to accommodate for the bit shift. From 89497627be0411151edacb0ec79a914f8c6759e8 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 11:48:18 +0200 Subject: [PATCH 03/11] typos keys.md --- docs/docs/aztec/concepts/accounts/keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/aztec/concepts/accounts/keys.md b/docs/docs/aztec/concepts/accounts/keys.md index cf731a5813c..87572444485 100644 --- a/docs/docs/aztec/concepts/accounts/keys.md +++ b/docs/docs/aztec/concepts/accounts/keys.md @@ -111,7 +111,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 the instantiation of the private note from the previous one. #### Using an immutable private note From e22be89cc5ed6861a2c735608f2ecc559e2977d1 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 11:49:46 +0200 Subject: [PATCH 04/11] typos communicate_with_portal.md --- .../writing_contracts/portals/communicate_with_portal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md index d08078b0aec..944016dfff3 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md +++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md @@ -156,7 +156,7 @@ Error handling for cross chain messages is handled by the application contract a Designating a caller grants the ability to specify who should be able to call a function that consumes a message. This is useful for ordering of batched messages. -When performing multiple cross-chain calls in one action it is important to consider the order of the calls. Say for example, that you want to perform a uniswap trade on L1. You would withdraw funds from the rollup, swap them on L1, and then deposit the swapped funds back into the rollup. This is a straightforward process, but it requires that the calls are done in the correct order (e.g. if the swap is called before the funds are withdrawn, the swap will fail). +When performing multiple cross-chain calls in one action it is important to consider the order of the calls. Say for example, that you want to perform an uniswap trade on L1. You would withdraw funds from the rollup, swap them on L1, and then deposit the swapped funds back into the rollup. This is a straightforward process, but it requires that the calls are done in the correct order (e.g. if the swap is called before the funds are withdrawn, the swap will fail). The message boxes (Inbox and Outbox) will only allow the recipient portal to consume the message, and we can use this to ensure that the calls are done in the correct order. Say that we include a designated "caller" in the messages, and that the portal contract checks that the caller matches the designated caller or designated as `address(0)` (if anyone can call). When the messages are to be consumed on L1, it can compute the message as seen below: From 4a47f12fa374239b66a958dd28c90ebafe378010 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 11:50:39 +0200 Subject: [PATCH 05/11] typos precompiles.md --- docs/docs/protocol-specs/addresses-and-keys/precompiles.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/protocol-specs/addresses-and-keys/precompiles.md b/docs/docs/protocol-specs/addresses-and-keys/precompiles.md index 07348290ea1..720e2c13d4d 100644 --- a/docs/docs/protocol-specs/addresses-and-keys/precompiles.md +++ b/docs/docs/protocol-specs/addresses-and-keys/precompiles.md @@ -8,7 +8,7 @@ Precompiled contracts, which borrow their name from Ethereum's, are contracts no Note that, unlike user-defined contracts, the address of a precompiled [contract instance](../contract-deployment/instances.md) and the [identifier of its class](../contract-deployment/classes.md#class-identifier) both have no known preimage. -The rationale for precompiled contracts is to provide a set of vetted primitives for [note encryption](../private-message-delivery/private-msg-delivery.md#encryption-and-decryption) and [tagging](../private-message-delivery/private-msg-delivery.md#note-tagging) that applications can use safely. These primitives are guaranteed to be always-satisfiable when called with valid arguments. This allows account contracts to choose their preferred method of encryption and tagging from any primitive in this set, and application contracts to call into them without the risk of calling into a untrusted code, which could potentially halt the execution flow via an unsatisfiable constraint. Furthermore, by exposing these primitives in a reserved set of well-known addresses, applications can be forward-compatible and incorporate new encryption and tagging methods as accounts opt into them. +The rationale for precompiled contracts is to provide a set of vetted primitives for [note encryption](../private-message-delivery/private-msg-delivery.md#encryption-and-decryption) and [tagging](../private-message-delivery/private-msg-delivery.md#note-tagging) that applications can use safely. These primitives are guaranteed to be always-satisfiable when called with valid arguments. This allows account contracts to choose their preferred method of encryption and tagging from any primitive in this set, and application contracts to call into them without the risk of calling into an untrusted code, which could potentially halt the execution flow via an unsatisfiable constraint. Furthermore, by exposing these primitives in a reserved set of well-known addresses, applications can be forward-compatible and incorporate new encryption and tagging methods as accounts opt into them. ## Constants From 7c2605408905c906f8ba62e9cf3cf2baed26d493 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 11:52:39 +0200 Subject: [PATCH 06/11] typos public-private-messaging.md --- docs/docs/protocol-specs/calls/public-private-messaging.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/protocol-specs/calls/public-private-messaging.md b/docs/docs/protocol-specs/calls/public-private-messaging.md index e438f49d96e..3dc4ab83e5e 100644 --- a/docs/docs/protocol-specs/calls/public-private-messaging.md +++ b/docs/docs/protocol-specs/calls/public-private-messaging.md @@ -15,7 +15,7 @@ Private functions are executed locally by the user, so that the user can ensure Given this natural flow from private-land to public-land, private functions can enqueue calls to public functions. But the opposite direction is not true. We'll see [below](#public-to-private-messaging) that public functions cannot "call" private functions, but rather they must pass messages. -Since private functions execute first, they cannot 'wait' on the results of any of their calls to public functions. +Since private functions execute first, they cannot 'wait' on the results of their calls to public functions. By way of example, suppose a function makes a call to a public function, and then to a private function. The public function will not be executed immediately, but will instead be enqueued for the sequencer to execute later. From ba024d79646e792abcc12adbd1139499a39a3fed Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 11:54:49 +0200 Subject: [PATCH 07/11] typos p2p-network.md --- docs/docs/protocol-specs/decentralization/p2p-network.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/protocol-specs/decentralization/p2p-network.md b/docs/docs/protocol-specs/decentralization/p2p-network.md index 62c1bbe4c7f..971955e125c 100644 --- a/docs/docs/protocol-specs/decentralization/p2p-network.md +++ b/docs/docs/protocol-specs/decentralization/p2p-network.md @@ -61,7 +61,7 @@ When new participants join the network for the first time, they will need to loc Whilst the DiscV5 specification is still under development, the protocol is currently in use by Ethereum's consensus layer with 100,000s of participants. Nodes maintain a DHT routing table of Ethereum Node Records (ENRs), periodically flushing nodes that are no longer responsive and searching for new nodes by requesting records from their neighbours. -Neighbours in this sense are not necessarily in geographical proximity. Node distance is defined as the bitwise XOR of the nodes 32 bit IDs. +Neighbours in this sense are not necessarily in geographical proximity. Node distance is defined as the bitwise XOR of the nodes 32-bit IDs. ``` distance(Id1, Id2) = Id1 XOR Id2 From e6b19a7c92495dc2a7a4dde1376804db19e1e93b Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 11:56:14 +0200 Subject: [PATCH 08/11] typos intro.md --- docs/docs/protocol-specs/intro.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/docs/protocol-specs/intro.md b/docs/docs/protocol-specs/intro.md index 275b370ed15..58966b25c73 100644 --- a/docs/docs/protocol-specs/intro.md +++ b/docs/docs/protocol-specs/intro.md @@ -22,7 +22,7 @@ Some of the info we need to populate this document might have already been writt ## Diagrams -To increase the probability of diagrams being up to date we encourage you to write them in `mermaid`. Mermaid is a markdown-like language for generating diagrams and is supported by Docusaurus, so it will be rendered automatically for you. +To increase the probability of diagrams being up-to-date we encourage you to write them in `mermaid`. Mermaid is a markdown-like language for generating diagrams and is supported by Docusaurus, so it will be rendered automatically for you. You simply create a codeblock specifying the language as `mermaid` and write your diagram in the codeblock. For example: ````txt @@ -87,7 +87,7 @@ classDiagram If mermaid doesn't cover your case, please add both the rendered image and the source code to the documentation. Most of the tools for diagramming can export a non-rendered representation that can then be updated by other people. Please name it such that it is clear what tool was used. -This should allow us to keep the diagrams up to date, by allowing others to update them. +This should allow us to keep the diagrams up-to-date, by allowing others to update them. ## For each protocol feature From a0deadd016a95bf9837e93d8f91552a30f3b8368 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 12:01:22 +0200 Subject: [PATCH 09/11] typos alu.md --- docs/docs/protocol-specs/public-vm/alu.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/protocol-specs/public-vm/alu.md b/docs/docs/protocol-specs/public-vm/alu.md index bf30043974c..70a902406ad 100644 --- a/docs/docs/protocol-specs/public-vm/alu.md +++ b/docs/docs/protocol-specs/public-vm/alu.md @@ -4,7 +4,7 @@ The algebraic logic unit performs operations analogous to an arithmetic unit in This component of the VM circuit evaluates both base-2 arithmetic operations and prime-field operation. It takes its input/output from the intermediate registers in the state controller. -The following block diagram maps out an draft of the internal components of the "ALU" +The following block diagram maps out a draft of the internal components of the "ALU" ![](/img/protocol-specs/public-vm/alu.png) From eed4d2c50bdc23a0bbb2faf90b601eceae43b922 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 12:02:19 +0200 Subject: [PATCH 10/11] typos aztecnr-errors.md --- .../developer_references/common_errors/aztecnr-errors.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/reference/developer_references/common_errors/aztecnr-errors.md b/docs/docs/reference/developer_references/common_errors/aztecnr-errors.md index e76d9206355..2a2b3f3d381 100644 --- a/docs/docs/reference/developer_references/common_errors/aztecnr-errors.md +++ b/docs/docs/reference/developer_references/common_errors/aztecnr-errors.md @@ -72,4 +72,4 @@ To address the error, register the account by calling `server.registerAccount(.. You may encounter this error when trying to send a transaction that is using an invalid contract. The contract may compile without errors and you only encounter this when sending the transaction. -This error may arise when function parameters are not properly formatted, when trying to "double-spend" a note, or it may indicate that there is a bug deeper in the stack (e.g. a bug in the Aztec.nr library or deeper). If you hit this error, double check your contract implementation, but also consider [opening an issue (GitHub link)](https://github.com/AztecProtocol/aztec-packages/issues/new). +This error may arise when function parameters are not properly formatted, when trying to "double-spend" a note, or it may indicate that there is a bug deeper in the stack (e.g. a bug in the Aztec.nr library or deeper). If you hit this error, double-check your contract implementation, but also consider [opening an issue (GitHub link)](https://github.com/AztecProtocol/aztec-packages/issues/new). From 772e9e4ccdd0dcc43d4621a3849c225feb7b8ae3 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sun, 24 Nov 2024 12:07:27 +0200 Subject: [PATCH 11/11] Update communicate_with_portal.md --- .../writing_contracts/portals/communicate_with_portal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md index 944016dfff3..d08078b0aec 100644 --- a/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md +++ b/docs/docs/guides/developer_guides/smart_contracts/writing_contracts/portals/communicate_with_portal.md @@ -156,7 +156,7 @@ Error handling for cross chain messages is handled by the application contract a Designating a caller grants the ability to specify who should be able to call a function that consumes a message. This is useful for ordering of batched messages. -When performing multiple cross-chain calls in one action it is important to consider the order of the calls. Say for example, that you want to perform an uniswap trade on L1. You would withdraw funds from the rollup, swap them on L1, and then deposit the swapped funds back into the rollup. This is a straightforward process, but it requires that the calls are done in the correct order (e.g. if the swap is called before the funds are withdrawn, the swap will fail). +When performing multiple cross-chain calls in one action it is important to consider the order of the calls. Say for example, that you want to perform a uniswap trade on L1. You would withdraw funds from the rollup, swap them on L1, and then deposit the swapped funds back into the rollup. This is a straightforward process, but it requires that the calls are done in the correct order (e.g. if the swap is called before the funds are withdrawn, the swap will fail). The message boxes (Inbox and Outbox) will only allow the recipient portal to consume the message, and we can use this to ensure that the calls are done in the correct order. Say that we include a designated "caller" in the messages, and that the portal contract checks that the caller matches the designated caller or designated as `address(0)` (if anyone can call). When the messages are to be consumed on L1, it can compute the message as seen below: