chore(yellow_paper): fixes to my work on public private messages #3507

rahul-kothari · 2023-12-01T13:01:48Z

PR #3491 got accidentally merged without reviews. So here we are!

LHerskind

Got some things we need to discuss around msg_sender == 0 otherwise minor things.

LHerskind · 2023-12-01T17:26:47Z

yellow-paper/docs/calls/public_private_messaging.md

@@ -10,33 +10,51 @@ sidebar_position: 5
 This is a draft. These requirements need to be considered by the wider team, and might change significantly before a mainnet release.
 :::

-Private functions work by providing evidence of correct execution generated locally through kernel proofs. Public functions, on the other hand, are able to utilize the latest state to manage updates and perform alterations. As such, public state and private state are in different trees. In a private function you cannot reference or modify public state and vice versa. 
-
+Public state and private state exist in different trees. In a private function you cannot reference or modify public state and vice versa. 


WDYM with vice versa here? Later on your are explicitly mentioning how you can modify private state from public functions 👀

LHerskind · 2023-12-01T17:27:23Z

yellow-paper/docs/calls/public_private_messaging.md

 Yet, it should be possible for:
 1. private functions to call private or public functions
 2. public functions to call private or public functions

-For private execution, the user executed methods locally and presents evidence of correct execution as part of their transaction in the form of a kernel proof (generated locally on user device ahead of time). This way, the builder doesn't need to have knowledge of everything happening in the transaction, only the results. However, public functions are executed at the "tip" of the chain (i.e. make use of the latest updates), they can only be done by a builder who is aware of all the changes. Therefore a public function can't be executed locally by the user in the same way a private function is, as it would lead to race conditions, if the user doesn't keep track of the latest updates of the chain. If we were to build this public proof on the latest state, we would encounter problems. How can two different users build proofs at the same time, given that they will be executed one after the other by the sequencer? The simple answer is that they cannot, as race conditions would arise where one of the proofs would be invalidated by the other due to a change in the state root (which would nullify Merkle paths).
+Private functions are executed locally by the user and work by providing evidence of correct execution generated locally through kernel proofs. This way, the builder doesn't need to have knowledge of everything happening in the transaction, only the results. Public functions, on the other hand, are able to utilize the latest state to manage updates and perform alterations, as they are executed by the sequencer. 


It is a little funky when you are switching between calling it sequencer and builder.

LHerskind · 2023-12-01T17:29:08Z

yellow-paper/docs/calls/public_private_messaging.md


 This enables private functions to enqueue calls to public functions. But vice-versa is not true. Since private functions execute first, it cannot "wait" on the results of any of their calls to public functions. Stated differently, any calls made across domains are unilateral in nature. 

 The figure below shows the order of function calls on the left-hand side, while the right-hand side shows how the functions will be executed. Notably, the second private function call is independent of the output of the public function and merely occurs after its execution.

-![Public - Private Ordering](./images/calls/pvt_pub_ordering.png)
+Tx call order be:
+```mermaid


🧜‍♂️

LHerskind · 2023-12-01T17:38:21Z

yellow-paper/docs/calls/public_private_messaging.md

+
+## Private to Public Messaging
+When a private function calls a public function:
+1. Public function args get hashed together in a chunk


No need for the in a chunk.

LHerskind · 2023-12-01T17:43:17Z

yellow-paper/docs/calls/public_private_messaging.md


-Specifically, when the call stack is passed to the kernel circuit, the kernel should assert the `msg_sender` is 0 and hash appropriately. `msg_sender` could be the contract address too instead of `0`, but it leaks which contract is calling the public method and therefore leaks which contract the user was interacting with in private land.
+Therefore, when the call stack is passed to the kernel circuit, the kernel should assert the `msg_sender` is 0 and hash appropriately. 


Calling @iAmMichaelConnor here as he might have other thoughts with all his keys.

Separately, setting msg_sender to 0 might be a really bad idea if people will be writing applications like they do in Ethereum. Many contracts use 0 as burn address, or end up having 0 as the admin if they burn the admin keys.

If that happens here, you could make a private -> public call to those functions and then you got msg_sender == 0, so better transfer all those burned funds or mint some more.

LHerskind

LGTM

🤖 I have created a release *beep* *boop* --- <details><summary>aztec-packages: 0.16.6</summary> ## [0.16.6](aztec-packages-v0.16.5...aztec-packages-v0.16.6) (2023-12-06) ### Bug Fixes * **pxe:** Initialise aztecjs on pxe startup ([#3601](#3601)) ([ceb2ed2](ceb2ed2)) * Remove api_prefix local ([#3599](#3599)) ([0d8dd8d](0d8dd8d)) ### Miscellaneous * **yellow_paper:** Fixes to my work on public private messages ([#3507](#3507)) ([33a4f63](33a4f63)) </details> <details><summary>barretenberg.js: 0.16.6</summary> ## [0.16.6](barretenberg.js-v0.16.5...barretenberg.js-v0.16.6) (2023-12-06) ### Miscellaneous * **barretenberg.js:** Synchronize aztec-packages versions </details> <details><summary>barretenberg: 0.16.6</summary> ## [0.16.6](barretenberg-v0.16.5...barretenberg-v0.16.6) (2023-12-06) ### Miscellaneous * **barretenberg:** Synchronize aztec-packages versions </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).

🤖 I have created a release *beep* *boop* --- <details><summary>aztec-packages: 0.16.6</summary> ## [0.16.6](AztecProtocol/aztec-packages@aztec-packages-v0.16.5...aztec-packages-v0.16.6) (2023-12-06) ### Bug Fixes * **pxe:** Initialise aztecjs on pxe startup ([#3601](AztecProtocol/aztec-packages#3601)) ([ceb2ed2](AztecProtocol/aztec-packages@ceb2ed2)) * Remove api_prefix local ([#3599](AztecProtocol/aztec-packages#3599)) ([0d8dd8d](AztecProtocol/aztec-packages@0d8dd8d)) ### Miscellaneous * **yellow_paper:** Fixes to my work on public private messages ([#3507](AztecProtocol/aztec-packages#3507)) ([33a4f63](AztecProtocol/aztec-packages@33a4f63)) </details> <details><summary>barretenberg.js: 0.16.6</summary> ## [0.16.6](AztecProtocol/aztec-packages@barretenberg.js-v0.16.5...barretenberg.js-v0.16.6) (2023-12-06) ### Miscellaneous * **barretenberg.js:** Synchronize aztec-packages versions </details> <details><summary>barretenberg: 0.16.6</summary> ## [0.16.6](AztecProtocol/aztec-packages@barretenberg-v0.16.5...barretenberg-v0.16.6) (2023-12-06) ### Miscellaneous * **barretenberg:** Synchronize aztec-packages versions </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).

rahul-kothari requested review from benesjan and LHerskind December 1, 2023 13:01

benesjan approved these changes Dec 1, 2023

View reviewed changes

LHerskind requested changes Dec 1, 2023

View reviewed changes

rahul-kothari added 2 commits December 4, 2023 14:23

fixes to my public private messages pr

1d3fa49

updates per pr comments

a72d7b7

rahul-kothari force-pushed the rk/yp_pub_pvt_msg_fix branch from 84f9d37 to a72d7b7 Compare December 4, 2023 14:24

rahul-kothari requested a review from LHerskind December 4, 2023 21:46

LHerskind approved these changes Dec 5, 2023

View reviewed changes

rahul-kothari merged commit 33a4f63 into master Dec 6, 2023
84 checks passed

rahul-kothari deleted the rk/yp_pub_pvt_msg_fix branch December 6, 2023 14:04

AztecBot mentioned this pull request Dec 6, 2023

chore(master): Release 0.16.6 #3600

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(yellow_paper): fixes to my work on public private messages #3507

chore(yellow_paper): fixes to my work on public private messages #3507

rahul-kothari commented Dec 1, 2023

LHerskind left a comment

LHerskind Dec 1, 2023

LHerskind Dec 1, 2023

LHerskind Dec 1, 2023

LHerskind Dec 1, 2023

LHerskind Dec 1, 2023

LHerskind left a comment


		Specifically, when the call stack is passed to the kernel circuit, the kernel should assert the `msg_sender` is 0 and hash appropriately. `msg_sender` could be the contract address too instead of `0`, but it leaks which contract is calling the public method and therefore leaks which contract the user was interacting with in private land.
		Therefore, when the call stack is passed to the kernel circuit, the kernel should assert the `msg_sender` is 0 and hash appropriately.

chore(yellow_paper): fixes to my work on public private messages #3507

chore(yellow_paper): fixes to my work on public private messages #3507

Conversation

rahul-kothari commented Dec 1, 2023

LHerskind left a comment

Choose a reason for hiding this comment

LHerskind Dec 1, 2023

Choose a reason for hiding this comment

LHerskind Dec 1, 2023

Choose a reason for hiding this comment

LHerskind Dec 1, 2023

Choose a reason for hiding this comment

LHerskind Dec 1, 2023

Choose a reason for hiding this comment

LHerskind Dec 1, 2023

Choose a reason for hiding this comment

LHerskind left a comment

Choose a reason for hiding this comment