draft: state vars #8
Conversation
❌ Deploy Preview for aztec-docs-2 failed. Why did it fail? →
|
|
|
||
| ### Storage Slots | ||
|
|
||
| each state variable gets assigned a different_storage slot_, a numerical value. Their meaning depends on the kind of state variable: for public state variables they are related to slots in the public data tree, and for private state variables they are metadata that gets included in the note hash. The purpose of slots is the same for both domains however: they keep the values of different state values _separate_ so that they do not interfere with one another. |
There was a problem hiding this comment.
wdym by meaning here?
There was a problem hiding this comment.
Meaning was probably the wrong word - the meaning is the same. It's how we use the storage slot that changes (make it be an SLOAD param or put it in note metadata).
|
|
||
| understanding these primitives and how they can be used is key to understanding how private state works. | ||
|
|
||
| (table comparing private set and private mutable? not sure what the columns would be) |
There was a problem hiding this comment.
will we also have
private set
Private Mutable
Why is there no private immutable? should we add that this doesn't exist and why?
There was a problem hiding this comment.
We do have it. It was just not on the list so I forgot to put it.
|
|
||
| ### Notes and Nullifiers | ||
|
|
||
| Just as public state is stored in a single public data tree (equivalent to the key-value store that is contract storage on the EVM), private state is stored in two separate trees that have different properties: the note hash tree and the nullifier tree |
There was a problem hiding this comment.
love love love this sentance
|
|
||
| they also have some metadata, including a storage slot to avoid collisions with other notes (link above), a 'randomness' value that helps hide the content, and an owner who can nullify the note (more on this later). | ||
|
|
||
| the note content plus metadata are all hashed together, and it is this hash that gets stored onchain in the note hash tree. the underlying note content (the note hash preimage) is not stored anywhere, and so third parties cannot access it and it remains private. the rightful owner will however be able to use the note in the future by producing the hidden content and showing that its hash is stored onchain as part of a zero-knowledge proof - this is typically referred to as 'reading a note'. |
There was a problem hiding this comment.
forget third parties... who's the second party lol... the nodes dont see this info either
There was a problem hiding this comment.
The immediate next sentence begins with 'the rightful owner'. This may be you, but it could also be someone else you're creating the note for, in which case you need to tell them. The immediate next section opens with this.
|
|
||
| - creation: an account executing a private contract function creates a new note according to contract logic, e.g. transferring tokens to a recipient. note values (e.g. the token amount) and metadata are set, and the note hash computed and inserted as one of the effects of the transaction (link to protocol docs - tx effects). | ||
|
|
||
| - encryption: the content of the note is encrypted with a key only the sender and intended recipient know - no other account can decrypt this message. |
There was a problem hiding this comment.
wait how is the key shared with the receiver im confused
There was a problem hiding this comment.
We do ECDH between the recipient's public key and an ephemeral private key which we then discard. The ephemeral public key is shown in plantext in the log (it's just a random value). This is why quantum computers hit us bad - one would be able to find the private key and decrypt the message. Alas those don't exist yet.
I'd have this sentence link to the page on messages where we explain message encryption and layout in detail.
This is not complete - some of the explanations took a bit longer than anticipated as I started to figure out where to draw the line between these docs and the API ref. I think what's here so far does a good balance of showing useful information without drowning the reader in detail - which is what the API ref will do.