Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Merged
merged 2 commits into from
Dec 6, 2023
Merged

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

merged 2 commits into from
Dec 6, 2023

Conversation

rahul-kothari
Copy link
Contributor

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

LHerskind
LHerskind requested changes Dec 1, 2023
View reviewed changes
Copy link
Contributor

@LHerskind LHerskind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

yellow-paper/docs/calls/public_private_messaging.md Outdated
@@ -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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

yellow-paper/docs/calls/public_private_messaging.md Outdated
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧜‍♂️

yellow-paper/docs/calls/public_private_messaging.md Outdated

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for the in a chunk.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
LHerskind approved these changes Dec 5, 2023
View reviewed changes
Copy link
Contributor

@LHerskind LHerskind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@rahul-kothari rahul-kothari merged commit 33a4f63 into master Dec 6, 2023
84 checks passed
@rahul-kothari rahul-kothari deleted the rk/yp_pub_pvt_msg_fix branch December 6, 2023 14:04
@AztecBot AztecBot mentioned this pull request Dec 6, 2023
Merged
rahul-kothari pushed a commit that referenced this pull request Dec 6, 2023
@AztecBot
chore(master): Release 0.16.6 (#3600)
58be3a0 
🤖 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).
AztecBot added a commit to AztecProtocol/barretenberg that referenced this pull request Dec 7, 2023
@AztecBot
chore(master): Release 0.16.6 (#3600)
cf7ca16 
🤖 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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@LHerskind LHerskind LHerskind approved these changes

@benesjan benesjan benesjan approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@rahul-kothari @benesjan @LHerskind