-
Notifications
You must be signed in to change notification settings - Fork 56
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.
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
[Docs]: Update Asset
and State
sections
#1030
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks. I left some comments. I am not sure, if I would use a white background for the pictures, that looks weird in DarkMode.
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com>
…n/miden-base into phklive-docs-update-assets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thank you. I left some comments inline.
|
||
Faucets can create assets and immediately distribute them by producing notes. However, assets can also stay in the faucet after creation to be sent later, e.g., in a bundle. That way, one can mint a million NFTs locally in a single transaction and then send them out as needed in separate transactions in the future. | ||
Faucets can issue either fungible or non-fungible assets as defined at account creation. The faucet's code specifies the asset minting conditions: i.e., how, when, and by whom these assets can be minted. Once minted, they can be transferred to other accounts using notes. | ||
|
||
![Architecture core concepts](../img/architecture/asset/asset-issuance.png) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this picture could be improved:
- It feels disproportionally big (I think we can reduce the size of text and shapes quite a bit).
- I would probably not introduce new colors - e.g., in Miden VM docs arrows also use back color.
- I would maybe add some simple comments to make it easier to understand what's what.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Perhaps the arrows from the faucet to the note should be labelled "issues", as in, "the faucet issues notes" and the arrows from the notes to the accounts should be labelled "transferred", as in, "the notes are transferred to the accounts"?
|
||
### Storage | ||
|
||
[Accounts](accounts.md) and [notes](notes.md) contain asset vaults that are used to store assets. Accounts can keep unlimited assets in a sparse Merkle tree called `account vault`. Notes can store up to `255` distinct assets. | ||
[Accounts](accounts.md) and [notes](notes.md) have vaults used to store assets. | ||
|
||
![Architecture core concepts](../img/architecture/asset/asset-storage.png) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to the above comment, I think this graphic can be improved.
|
||
### Issuance | ||
## What is an asset? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find having lots of small sections a bit distracting - though, maybe that's just in Github rendering and it it would look better in mdBook rendering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
When I run the serve-doc-site.sh
script as-is with mkdocs --strict
I'm getting a few errors regarding broken links. Looks like this isn't part of CI but it probably should be to catch such errors?
|
||
Faucets can create assets and immediately distribute them by producing notes. However, assets can also stay in the faucet after creation to be sent later, e.g., in a bundle. That way, one can mint a million NFTs locally in a single transaction and then send them out as needed in separate transactions in the future. | ||
Faucets can issue either fungible or non-fungible assets as defined at account creation. The faucet's code specifies the asset minting conditions: i.e., how, when, and by whom these assets can be minted. Once minted, they can be transferred to other accounts using notes. | ||
|
||
![Architecture core concepts](../img/architecture/asset/asset-issuance.png) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Perhaps the arrows from the faucet to the note should be labelled "issues", as in, "the faucet issues notes" and the arrows from the notes to the accounts should be labelled "transferred", as in, "the notes are transferred to the accounts"?
* Updated docs state * Update docs/architecture/state.md Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com> * Update docs/architecture/state.md Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com> * Update docs/architecture/state.md Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com> * Update docs/architecture/state.md Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com> * Update docs/architecture/state.md Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com> * Rewording * Singular for titles * Update docs/architecture/state.md Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com> * Rewording for nullifiers * Update docs/architecture/state.md Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com> * Update docs/architecture/state.md Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com> * Second wave of updates * Updated notes section * Standardize writing accross modified docs --------- Co-authored-by: Dominik Schmid <35031754+Dominik1999@users.noreply.github.com> Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>
Asset
sectionAsset
and State
sections
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some smaller comments. Once resolved we can merge
docs/architecture/state.md
Outdated
Nullifiers are stored in a sparse Merkle tree, which maps [note nullifiers](notes.md#note-nullifier-to-ensure-private-consumption) to block numbers at which the nullifiers are inserted into the chain (or to `0` for nullifiers which haven't been recorded yet). Nullifiers provide information on whether a specific note has been consumed. The database allows proving that a given nullifier is not in the database. | ||
Each [note](notes.md) has an associated nullifier which enables the tracking of whether it's associated note has been consumed or not, preventing double-spending. | ||
|
||
To prove that a note has not been consumed, the operator must provide a Merkle path to the corresponding node and show that the node’s value is 0. Since nullifiers are 32 bytes each, the Sparse Merkle Tree height must be sufficient to represent all possible nullifiers. Operators must maintain the entire nullifier set to compute the new tree root after inserting new nullifiers. For each nullifier we also record the block in which it was created. This way "unconsumed" nullifiers have block 0, but all consumed nullifiers have a non-zero block. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To prove that a note has not been consumed, the operator must provide a Merkle path to the corresponding node and show that the node’s value is 0.
It should be Note, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But why does the operator need to do that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here note is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will merge it like that and change it if needed.
My understanding is that the node must respond to the user with a merkle proof to the nullifier with a node value of 0, proving that the note has not been consummed.
If the node value is something else (e.g. the block in which the note has been consume) it means that the note has been consummed.
Hence this check is needed before a user consumes a note to make sure he consumes a note that has not yet been consummed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But here is node, no? to the corresponding node
…n/miden-base into phklive-docs-update-assets
In this PR I propose to update the
Asset
section of the Miden documentation:Additional questions:
Miden asset model
is?