From 67065d5f48e1ac32b7fb0542ccff4be29f3b55a6 Mon Sep 17 00:00:00 2001 From: jeanmon Date: Thu, 7 Sep 2023 06:46:10 +0000 Subject: [PATCH 1/6] 1652 - document limitations on ordering and logs of chopped notes --- docs/docs/dev_docs/limitations/main.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/docs/dev_docs/limitations/main.md b/docs/docs/dev_docs/limitations/main.md index a8e64411d00..ae7be4c1690 100644 --- a/docs/docs/dev_docs/limitations/main.md +++ b/docs/docs/dev_docs/limitations/main.md @@ -217,6 +217,18 @@ There are [plans](../../about_aztec/roadmap/engineering_roadmap.md#proper-circui > **In the mean time**, if you encounter a per-transaction limit when testing, and you're feeling adventurous, you could 'hack' the Sandbox to increase the limits. See here (TODO: link) for a guide. **However**, the limits cannot be increased indefinitely. So although we do anticipate that we'll be able to increase them a little bit, don't go mad and provide yourself with 1 million state transitions per transaction. That would be as unrealistic as artificially increasing Ethereum gas limits to 1 trillion. +### Circuits Processing Order Differ from Execution + +Each function call is representing by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. By doing so, the processing order differ from the execution order. + +#### What are the consequences? +Transaction output elements such as notes in encrypted logs, note hashes (commitments), nullifiers might be ordered differently than the one exepected by the execution. + +### Chopped Transient Notes are still Emitted in Logs +A note which is created and nullified during the very same transaction is called transient. Such a note is chopped by the [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) and is never stored in any persistent data tree. + +At the time being, such chopped notes are still emitted as part of encrypted logs which is the communication channel to transmit notes. When a log containing a chopped note is processed a warning will be logged about a decrypted note which does not exist in data tree. We [improved](https://github.com/AztecProtocol/aztec-packages/issues/1603) error logging to help identify such an occurence. However, this might be the source of confusion. +This is issue is tracked in ticket [#1641](https://github.com/AztecProtocol/aztec-packages/issues/1641). ## There's more From 9ab3163cac890571d667d350bea76c518aec841a Mon Sep 17 00:00:00 2001 From: jeanmon Date: Thu, 7 Sep 2023 11:30:38 +0000 Subject: [PATCH 2/6] 1652 - adding an example for kernel processing order --- docs/docs/dev_docs/limitations/main.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/docs/docs/dev_docs/limitations/main.md b/docs/docs/dev_docs/limitations/main.md index ae7be4c1690..e2068c3cb76 100644 --- a/docs/docs/dev_docs/limitations/main.md +++ b/docs/docs/dev_docs/limitations/main.md @@ -219,7 +219,21 @@ There are [plans](../../about_aztec/roadmap/engineering_roadmap.md#proper-circui ### Circuits Processing Order Differ from Execution -Each function call is representing by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. By doing so, the processing order differ from the execution order. +Each function call is representing by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. By doing so, the processing order differ from the execution order. Firstly, the private kernel has to handle one function call in its entirety at a time because a zk proof cannot be verified partially. This property alone makes it impossible to follow an execution process. Secondly, the private kernel is processing function calls in a stack-based order, i.e., after having processed a function call, it processes all direct children function call in an order which is the reverse than execution. + +### Example +Let us assume that the main function named f_1 is calling in order f_2, f_3 (which calls f_5 folllowed by f_6), and f_4. + +Call Dependency: +> f_1 ---> f_2, f_3, f_4 \ + f_3 ---> f_5, f_6 + +Execution Order: +> f_1, f_2, f_3, f_5, f_6, f_4 + + +Private Kernel Processing Order: +> f_1, f_4, f_3, f_6, f_5, f_2 #### What are the consequences? Transaction output elements such as notes in encrypted logs, note hashes (commitments), nullifiers might be ordered differently than the one exepected by the execution. From f60990132823b2db0a53a6930261f81174f4cfa6 Mon Sep 17 00:00:00 2001 From: Jean M <132435771+jeanmon@users.noreply.github.com> Date: Thu, 7 Sep 2023 16:09:51 +0200 Subject: [PATCH 3/6] Update docs/docs/dev_docs/limitations/main.md Co-authored-by: Michael Connor --- docs/docs/dev_docs/limitations/main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/dev_docs/limitations/main.md b/docs/docs/dev_docs/limitations/main.md index e2068c3cb76..b6c43c78b01 100644 --- a/docs/docs/dev_docs/limitations/main.md +++ b/docs/docs/dev_docs/limitations/main.md @@ -217,7 +217,7 @@ There are [plans](../../about_aztec/roadmap/engineering_roadmap.md#proper-circui > **In the mean time**, if you encounter a per-transaction limit when testing, and you're feeling adventurous, you could 'hack' the Sandbox to increase the limits. See here (TODO: link) for a guide. **However**, the limits cannot be increased indefinitely. So although we do anticipate that we'll be able to increase them a little bit, don't go mad and provide yourself with 1 million state transitions per transaction. That would be as unrealistic as artificially increasing Ethereum gas limits to 1 trillion. -### Circuits Processing Order Differ from Execution +### Circuits Processing Order Differs from Execution Order Each function call is representing by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. By doing so, the processing order differ from the execution order. Firstly, the private kernel has to handle one function call in its entirety at a time because a zk proof cannot be verified partially. This property alone makes it impossible to follow an execution process. Secondly, the private kernel is processing function calls in a stack-based order, i.e., after having processed a function call, it processes all direct children function call in an order which is the reverse than execution. From b065550058de9ab528db1362b206537d4e6aa312 Mon Sep 17 00:00:00 2001 From: Jean M <132435771+jeanmon@users.noreply.github.com> Date: Thu, 7 Sep 2023 16:10:09 +0200 Subject: [PATCH 4/6] Update docs/docs/dev_docs/limitations/main.md Co-authored-by: Michael Connor --- docs/docs/dev_docs/limitations/main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/dev_docs/limitations/main.md b/docs/docs/dev_docs/limitations/main.md index b6c43c78b01..3c9de813f1a 100644 --- a/docs/docs/dev_docs/limitations/main.md +++ b/docs/docs/dev_docs/limitations/main.md @@ -219,7 +219,7 @@ There are [plans](../../about_aztec/roadmap/engineering_roadmap.md#proper-circui ### Circuits Processing Order Differs from Execution Order -Each function call is representing by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. By doing so, the processing order differ from the execution order. Firstly, the private kernel has to handle one function call in its entirety at a time because a zk proof cannot be verified partially. This property alone makes it impossible to follow an execution process. Secondly, the private kernel is processing function calls in a stack-based order, i.e., after having processed a function call, it processes all direct children function call in an order which is the reverse than execution. +Each function call is represented by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. In doing so, the processing order differs from the execution order. Firstly, the private kernel has to handle one function call in its entirety at a time because a zk proof cannot be verified partially. This property alone makes it impossible for the ordering of kernel circuit validation to match the order in which the functions of the transaction were executed. Secondly, the private kernel processes function calls in a stack-based order, i.e., after having processed a function call, it processes all direct child function calls in an order which is the reverse of the execution order. ### Example Let us assume that the main function named f_1 is calling in order f_2, f_3 (which calls f_5 folllowed by f_6), and f_4. From 83ef7a1cae2c0691bef02bc02940152038b1ef0a Mon Sep 17 00:00:00 2001 From: Jean M <132435771+jeanmon@users.noreply.github.com> Date: Thu, 7 Sep 2023 16:10:24 +0200 Subject: [PATCH 5/6] Update docs/docs/dev_docs/limitations/main.md Co-authored-by: Michael Connor --- docs/docs/dev_docs/limitations/main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/dev_docs/limitations/main.md b/docs/docs/dev_docs/limitations/main.md index 3c9de813f1a..4d966246e9e 100644 --- a/docs/docs/dev_docs/limitations/main.md +++ b/docs/docs/dev_docs/limitations/main.md @@ -241,7 +241,7 @@ Transaction output elements such as notes in encrypted logs, note hashes (commit ### Chopped Transient Notes are still Emitted in Logs A note which is created and nullified during the very same transaction is called transient. Such a note is chopped by the [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) and is never stored in any persistent data tree. -At the time being, such chopped notes are still emitted as part of encrypted logs which is the communication channel to transmit notes. When a log containing a chopped note is processed a warning will be logged about a decrypted note which does not exist in data tree. We [improved](https://github.com/AztecProtocol/aztec-packages/issues/1603) error logging to help identify such an occurence. However, this might be the source of confusion. +For the time being, such chopped notes are still emitted through encrypted logs (which is the communication channel to transmit notes). When a log containing a chopped note is processed, a warning will be logged about a decrypted note which does not exist in data tree. We [improved](https://github.com/AztecProtocol/aztec-packages/issues/1603) error logging to help identify such an occurence. However, this might be a source of confusion. This is issue is tracked in ticket [#1641](https://github.com/AztecProtocol/aztec-packages/issues/1641). ## There's more From ca01f380f917dfcda78fea79e4c23a1b723f29d3 Mon Sep 17 00:00:00 2001 From: jeanmon Date: Thu, 7 Sep 2023 14:27:10 +0000 Subject: [PATCH 6/6] 1652 - Addressing feedback and use latex for functions --- docs/docs/dev_docs/limitations/main.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/docs/docs/dev_docs/limitations/main.md b/docs/docs/dev_docs/limitations/main.md index 4d966246e9e..b1b68edad2c 100644 --- a/docs/docs/dev_docs/limitations/main.md +++ b/docs/docs/dev_docs/limitations/main.md @@ -221,19 +221,22 @@ There are [plans](../../about_aztec/roadmap/engineering_roadmap.md#proper-circui Each function call is represented by a circuit with a dedicated zero-knowledge proof of its execution. The [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) is in charge of stitching all these proofs together to produce a zero-knowledge proof that the whole execution of all function calls within a transaction is correct. In doing so, the processing order differs from the execution order. Firstly, the private kernel has to handle one function call in its entirety at a time because a zk proof cannot be verified partially. This property alone makes it impossible for the ordering of kernel circuit validation to match the order in which the functions of the transaction were executed. Secondly, the private kernel processes function calls in a stack-based order, i.e., after having processed a function call, it processes all direct child function calls in an order which is the reverse of the execution order. +Note that there is no plan to change this in the future. + ### Example -Let us assume that the main function named f_1 is calling in order f_2, f_3 (which calls f_5 folllowed by f_6), and f_4. +Let us assume that the main function named $f_1$ is calling in order $f_2$, $f_3$ (which calls $f_5$ folllowed by $f_6$), and $f_4$. Call Dependency: -> f_1 ---> f_2, f_3, f_4 \ - f_3 ---> f_5, f_6 +> $f_1 \longrightarrow f_2$, $f_3$, $f_4$ + +> $f_3 \longrightarrow f_5$, $f_6$ Execution Order: -> f_1, f_2, f_3, f_5, f_6, f_4 +> $f_1$, $f_2$, $f_3$, $f_5$, $f_6$, $f_4$ Private Kernel Processing Order: -> f_1, f_4, f_3, f_6, f_5, f_2 +> $f_1$, $f_4$, $f_3$, $f_6$, $f_5$, $f_2$ #### What are the consequences? Transaction output elements such as notes in encrypted logs, note hashes (commitments), nullifiers might be ordered differently than the one exepected by the execution. @@ -242,7 +245,7 @@ Transaction output elements such as notes in encrypted logs, note hashes (commit A note which is created and nullified during the very same transaction is called transient. Such a note is chopped by the [private kernel circuit](../../concepts/advanced/circuits/kernels/private_kernel.md) and is never stored in any persistent data tree. For the time being, such chopped notes are still emitted through encrypted logs (which is the communication channel to transmit notes). When a log containing a chopped note is processed, a warning will be logged about a decrypted note which does not exist in data tree. We [improved](https://github.com/AztecProtocol/aztec-packages/issues/1603) error logging to help identify such an occurence. However, this might be a source of confusion. -This is issue is tracked in ticket [#1641](https://github.com/AztecProtocol/aztec-packages/issues/1641). +This issue is tracked in ticket [#1641](https://github.com/AztecProtocol/aztec-packages/issues/1641). ## There's more