Skip to content

Commit a935ca3

Browse files
authored
docs(yellow-paper): circuits (AztecProtocol#3782)
Please provide a paragraph or two giving a summary of the change, including relevant motivation and context. # Checklist: Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge. - [ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag. - [ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code. - [ ] Every change is related to the PR description. - [ ] I have [linked](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) this pull request to relevant issues (if any exist).
1 parent 30243c1 commit a935ca3

10 files changed

+1332
-1070
lines changed
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,136 @@
1+
# High Level Topology
2+
3+
:::info Disclaimer
4+
This is a draft. These requirements need to be considered by the wider team, and might change significantly before a mainnet release.
5+
:::
6+
7+
## Overview
8+
9+
A transaction begins with a call to a private function, which may invoke nested calls to other private and public functions. The entire set of private function calls is executed in a secure environment, and their proofs are validated and aggregated by private kernel circuits. Meanwhile, any public function calls triggered from private functions will be enqueued. The proofs for these calls, along with those from the nested public function calls, are generated and processed through public kernel circuits in any entity possessing the correct contexts.
10+
11+
Once all functions in a transaction are executed, the accumulated data is outputted from a tail circuit. These values are then inserted or updated to the trees within the base rollup circuit. The merge rollup circuit facilitates the merging of two rollup proofs. Repeating this merging process enables the inclusion of more transactions in a block. Finally, the root rollup circuit produces the final proof, which is subsequently submitted and validated onchain.
12+
13+
To illustrate, consider a transaction involving the following functions, where circles depict private functions, and squares denote public functions:
14+
15+
```mermaid
16+
flowchart LR
17+
f0([f0]) --> f1([f1])
18+
f0 --> f2([f2])
19+
f0 --> f3([f3])
20+
f1 -.-> F0
21+
F0 --> F1
22+
F0 --> F2
23+
F2 --> F3
24+
f3 --> f4([f4])
25+
f3 -.-> F4
26+
f3 --> f5([f5])
27+
```
28+
29+
This transaction contains 6 private functions (f0 to f5) and 5 public functions (F0 to F4), with `f0` being the entrypoint. The entire transaction is processed as follows:
30+
31+
```mermaid
32+
flowchart TB
33+
subgraph Transaction A
34+
subgraph Private Functions
35+
f0([f0])
36+
f1([f1])
37+
f2([f2])
38+
f3([f3])
39+
f4([f4])
40+
f5([f5])
41+
end
42+
subgraph Public Functions
43+
F0
44+
F1
45+
F2
46+
F3
47+
F4
48+
end
49+
end
50+
subgraph Transaction C
51+
init2(...)
52+
tail2(Tail Private Kernel)
53+
init2 -.-> tail2
54+
end
55+
subgraph Transaction B
56+
init1(...)
57+
tail1(Tail Private Kernel)
58+
init1 -.-> tail1
59+
end
60+
subgraph Public Kernel
61+
INIT0(Initial Public Kernel)
62+
INNER0(Inner Public Kernel)
63+
INNER1(Inner Public Kernel)
64+
INNER2(Inner Public Kernel)
65+
INNER3(Inner Public Kernel)
66+
TAIL0(Tail Public Kernel)
67+
INIT0 --> INNER0
68+
INNER0 --> INNER1
69+
INNER1 --> INNER2
70+
INNER2 --> INNER3
71+
INNER3 --> TAIL0
72+
end
73+
subgraph Private Kernel
74+
init0(Initial Private Kernel)
75+
inner0(Inner Private Kernel)
76+
inner1(Inner Private Kernel)
77+
inner2(Inner Private Kernel)
78+
reset0(Reset Private Kernel)
79+
inner3(Inner Private Kernel)
80+
inner4(Inner Private Kernel)
81+
reset1(Reset Private Kernel)
82+
tail0(Tail Private Kernel)
83+
init0 --> inner0
84+
inner0 --> inner1
85+
inner1 --> inner2
86+
inner2 --> reset0
87+
reset0 --> inner3
88+
inner3 --> inner4
89+
inner4 --> reset1
90+
reset1 --> tail0
91+
end
92+
f0 --> init0
93+
f1 --> inner0
94+
f2 --> inner1
95+
f3 --> inner2
96+
f4 --> inner3
97+
f5 --> inner4
98+
F0 --> INIT0
99+
F1 --> INNER0
100+
F2 --> INNER1
101+
F3 --> INNER2
102+
F4 --> INNER3
103+
subgraph Rollup
104+
BR0(Base Rollup)
105+
BR1(Base Rollup)
106+
BR2(Base Rollup)
107+
BR3(Base Rollup)
108+
MR0(Merge Rollup)
109+
MR1(Merge Rollup)
110+
MR2(Merge Rollup)
111+
MR3(Merge Rollup)
112+
ROOT(Root Rollup)
113+
end
114+
tail0 --> INIT0
115+
TAIL0 --> BR0
116+
tail1 --> BR1
117+
tail2 --> BR2
118+
BR0 --> MR0
119+
BR1 --> MR0
120+
BR2 --> MR1
121+
BR3 --> MR1
122+
MR0 --> MR2
123+
MR1 --> MR2
124+
MR2 --> ROOT
125+
MR3 --> ROOT
126+
```
127+
128+
A few things to note:
129+
130+
- A transaction always starts with an [initial private kernel circuit](./private-kernel-initial.md).
131+
- An [inner private kernel circuit](./private-kernel-inner.md) won't be required if there is only one private function in a transaction.
132+
- A [reset private kernel circuit](./private-kernel-reset.md) can be executed between two private kernel circuits to "reset" transient data. The reset process can be repeated as needed.
133+
- Public functions are "enqueued" when invoked from a private function. Public kernel circuits will be executed after the completion of all private kernel iterations.
134+
- A [base rollup circuit](../rollup-circuits/base_rollup.md) can accept either a [tail public kernel circuit](./public-kernel-tail.md), or a [tail private kernel circuit](./private-kernel-tail.md) in cases where no public functions are present in the transaction.
135+
- A [merge rollup circuit](../rollup-circuits/merge_rollup.md) can merge two base rollup circuits or two merge rollup circuits.
136+
- The final step is the execution of the [root rollup circuit](../rollup-circuits/root_rollup.md), which combines two base rollup circuits or two merge rollup circuits.

yellow-paper/docs/circuits/private-function.md

+65-24
Original file line numberDiff line numberDiff line change
@@ -6,9 +6,9 @@ This is a draft. These requirements need to be considered by the wider team, and
66

77
## Requirements
88

9-
A private function circuit is a custom circuit tailored to the needs of a specific application. This circuit should be designed to handle private data processing while generating public inputs that safeguard the application and account's intentions without compromising sensitive information.
9+
Private function circuits represent smart contract functions that modify the Aztec private state trees. They serve as untrusted, third-party code that is executed as part of evaluating an Aztec transaction.
1010

11-
The logic of this circuit is flexible, yet its public inputs must adhere to a specific format.
11+
The logic of each private function circuit is tailored to the needs of a particular application or scenario, yet its public inputs must adhere to a specific format. This circuit should be designed to handle private data processing while generating public inputs that safeguard the application and account's intentions without compromising sensitive information.
1212

1313
## Private Inputs
1414

@@ -18,28 +18,69 @@ The private inputs of a private function circuit are customizable.
1818

1919
The public inputs of a private function circuit will be incorporated into the private inputs of a private kernel circuit. Private kernel circuits leverage these public inputs, coupled with proof data and verification key from a private function circuit, to prove the correct execution of a private function.
2020

21-
It must adhere to the following format:
22-
23-
| Field | Type | Description |
24-
| ---------------------------------- | -------------------------- | ---------------------------------------------------------------------- |
25-
| _call_context_ | _CallContext_ | Context of the call corresponding to this function execution. |
26-
| _args_hash_ | _field_ | Hash of the function arguments. |
27-
| _return_values_ | [_field_; C] | Return values of this function call. |
28-
| _read_requests_ | [_ReadRequest_; C] | Requests to read a note in the note hash tree. |
29-
| _note_hash_contexts_ | [_NoteHashContext_; C] | New note hashes created in this function call. |
30-
| _nullifier_contexts_ | [_NullifierContext_; C] | New nullifiers created in this function call. |
31-
| _l2_to_l1_msg_contexts_ | [_L2L1MessageContext; C] | New L2 to L1 messages created in this function call. |
32-
| _new_contract_contexts_ | [_ContractDataContext_; C] | Data of contracts deployed in this function call. |
33-
| _encrypted_logs_hash_ | [_field_; N] | Hash of the encrypted logs emitted in this function call. |
34-
| _unencrypted_logs_hash_ | [_field_; N] | Hash of the unencrypted logs emitted in this function call. |
35-
| _encrypted_log_preimages_length_ | [_field_; N] | Length of the encrypted log preimages emitted in this function call. |
36-
| _unencrypted_log_preimages_length_ | [_field_; N] | Length of the unencrypted log preimages emitted in this function call. |
37-
| _private_call_stack_hashes_ | [_field_; C] | Hashes of the private function calls initiated by this function. |
38-
| _public_call_stack_hashes_ | [_field_; C] | Hashes of the public function calls initiated by this function. |
39-
| _block_header_ | _BlockHeader_ | Information about the trees used for the transaction. |
40-
| _chain_id_ | _field_ | Chain ID of the transaction. |
41-
| _version_ | _field_ | Version of the transaction. |
21+
The following format defines the ABI that is used by the private kernel circuit when processing private function public inputs:
22+
23+
| Field | Type | Description |
24+
| ---------------------------------- | ------------------------------------ | ---------------------------------------------------------------------- |
25+
| _call_context_ | _[CallContext](#callcontext)_ | Context of the call corresponding to this function execution. |
26+
| _args_hash_ | _field_ | Hash of the function arguments. |
27+
| _return_values_ | [_field_; _C_] | Return values of this function call. |
28+
| _read_requests_ | [_[ReadRequest](#readrequest)_; _C_] | Requests to read notes in the note hash tree. |
29+
| _note_hashes_ | [_[NoteHash](#notehash)_; _C_] | New note hashes created in this function call. |
30+
| _nullifiers_ | [_[Nullifier](#nullifier)_; _C_] | New nullifiers created in this function call. |
31+
| _l2_to_l1_messages_ | [_field_; _C_] | New L2 to L1 messages created in this function call. |
32+
| _encrypted_logs_hash_ | _field_ | Hash of the encrypted logs emitted in this function call. |
33+
| _unencrypted_logs_hash_ | _field_ | Hash of the unencrypted logs emitted in this function call. |
34+
| _encrypted_log_preimages_length_ | _field_ | Length of the encrypted log preimages emitted in this function call. |
35+
| _unencrypted_log_preimages_length_ | _field_ | Length of the unencrypted log preimages emitted in this function call. |
36+
| _private_call_stack_item_hashes_ | [_field_; _C_] | Hashes of the private function calls initiated by this function. |
37+
| _public_call_stack_item_hashes_ | [_field_; _C_] | Hashes of the public function calls initiated by this function. |
38+
| _block_header_ | _[BlockHeader](#blockheader)_ | Information about the trees used for the transaction. |
39+
| _chain_id_ | _field_ | Chain ID of the transaction. |
40+
| _version_ | _field_ | Version of the transaction. |
4241

4342
> The above **C**s represent constants defined by the protocol. Each **C** might have a different value from the others.
4443
45-
> The above **N**s represent the number of _field_ of a hash. Its value depends on the hash function chosen by the protocol.
44+
## Types
45+
46+
#### _CallContext_
47+
48+
| Field | Type | Description |
49+
| -------------------------- | -------------- | ----------------------------------------------------------------------- |
50+
| _msg_sender_ | _AztecAddress_ | Address of the caller contract. |
51+
| _storage_contract_address_ | _AztecAddress_ | Address of the contract against which all state changes will be stored. |
52+
| _portal_contract_address_ | _AztecAddress_ | Address of the portal contract to the storage contract. |
53+
| _is_delegate_call_ | _bool_ | A flag indicating whether the call is a delegate call. |
54+
| _is_static_call_ | _bool_ | A flag indicating whether the call is a static call. |
55+
56+
#### _ReadRequest_
57+
58+
| Field | Type | Description |
59+
| ----------- | ------- | -------------------------------------- |
60+
| _note_hash_ | _field_ | Hash of the note to be read. |
61+
| _counter_ | _field_ | Counter at which the request was made. |
62+
63+
#### _NoteHash_
64+
65+
| Field | Type | Description |
66+
| --------- | ------- | ------------------------------------------- |
67+
| _value_ | _field_ | Hash of the note. |
68+
| _counter_ | _field_ | Counter at which the note hash was created. |
69+
70+
#### _Nullifier_
71+
72+
| Field | Type | Description |
73+
| --------- | ------- | ------------------------------------------- |
74+
| _value_ | _field_ | Value of the nullifier. |
75+
| _counter_ | _field_ | Counter at which the nullifier was created. |
76+
77+
#### _BlockHeader_
78+
79+
| Field | Type | Description |
80+
| ----------------------------- | ------- | ----------------------------------------------------------------------------------------------- |
81+
| _note_hash_tree_root_ | _field_ | Root of the note hash tree. |
82+
| _nullifier_tree_root_ | _field_ | Root of the nullifier tree. |
83+
| _l1_to_l2_messages_tree_root_ | _field_ | Root of the l1-to-l2 messages tree. |
84+
| _public_data_tree_root_ | _field_ | Root of the public data tree. |
85+
| _archive_tree_root_ | _field_ | Root of the state roots tree archived at the block prior to when the transaction was assembled. |
86+
| _global_variables_hash_ | _field_ | Hash of the previous global variables. |

0 commit comments

Comments
 (0)