[Docs]: Update State section
#1029
Conversation
phklive
added
the
no changelog
Co-authored-by: Dominik Schmid <[email protected]>
Co-authored-by: Dominik Schmid <[email protected]>
Co-authored-by: Dominik Schmid <[email protected]>
Co-authored-by: Dominik Schmid <[email protected]>
Co-authored-by: Dominik Schmid <[email protected]>
Co-authored-by: Dominik Schmid <[email protected]>
…/miden-base into phklive-docs-update-state
There was a problem hiding this comment.
Thank you! I left some comments inline, but also a few general comments as well:
- In some cases I think we've removed pretty important info which would be good to bring back.
- Would be good to get graphics to be a bit more proportionately sized (they appear too big).
More importantly though, I think we may need to combine this section with the "execution" section. Otherwise it may be difficult to get the comprehensive picture. Basically, we need to single section which explains how the Miden blockchain works. This would include what's in a block and how each block affects the state etc.
|
|
||
| Private notes greatly reduce storage requirements and thus result in lower fees. They add only $64$ bytes to the state ($32$ bytes when produced and $32$ bytes when consumed). | ||
|
|
||
| At high throughput (e.g., 1K TPS), the note database could grow by about 1TB/year. However, only unconsumed public notes and enough information to construct membership proofs must be stored explicitly. Private notes, as well as consumed public notes, can be discarded. This solves the issue of infinitely growing note databases. | ||
|
|
||
|  |
There was a problem hiding this comment.
This picture is outdated: we don't actually have a separate notes MMR. Instead, we have the blockchain MMR where every leaf is a block header. Then, each block header contains a commitment to the notes created in that block.
|
|
||
| However, the size of the note database does not grow indefinitely. Theoretically, at high tps, it grows very quickly: at $1$K TPS there are about $1$TB/year added to the database. But, only the unconsumed public notes, and enough info to construct membership proofs against them, need to be stored explicitly. Private notes, as well as public notes which have already been consumed, can be safely discarded. Such notes would still remain in the accumulator, but there is no need to store them explicitly as the append-only accumulator can be updated without knowing about all the items stored in it. This reduces actual storage requirements to a fraction of the database's nominal size. | ||
| ### Public shared state |
There was a problem hiding this comment.
I like the idea of this section but I think it should be a part of a bigger section the describes how different users work with the state. Specifically, we could come up with different types of state:
- Self-custodied state - state managed by a single user.
- Federated state - state managed by a small number of users (e.g., under 100).
- Network-managed state - state managed by the network itself (this would be the "public shared state").
- Hybrids between the above (this could be a really cool thing).
Would be good to describe how these work and what are the tradeoffs between them.
|
|
||
| 1. Membership witnesses (that a note exists in the database) against such an accumulator needs to be updated very infrequently. | ||
| 2. Old membership witnesses can be extended to a new accumulator value, but this extension does not need to be done by the original witness holder. | ||
|  |
There was a problem hiding this comment.
Isn't this diagram outdated? It states that nullifiers values are either 0/1 but they are the block number in which the note was consumed.
It also mentions the nullifier tree is a tiered sparse merkle tree, though right now it is just an SMT. Not sure right now if the plan is for it to be a tiered SMT in the future to support dropping older epochs.
|
|
||
| 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. | ||
|  |
There was a problem hiding this comment.
- The explanation of the diagram is duplicated: Once within the diagram itself and once below in the text. I think we should remove the explanation from the diagram. This way it can also be enlarged a little bit as some text (like the "tx" with numbers) is fairly small.
- I would also remove the extra heading "Handling shared state" in the diagram. Other diagrams don't have this.
- Can we write out "Acc" as "Account" and "Uni" as "Uniswap"?
- Can we align the "note x" text with the bubble surrounding it and capitalize it? Ideally so that note and number are on the same line. Some of them are underlined with red markers. Would be great to remove that.
Co-authored-by: Philipp Gackstatter <[email protected]>
Co-authored-by: Philipp Gackstatter <[email protected]>
|
I will merge the docs with the images as they are now, I am opening an issue to update all the images at once when we finish the contents part. @bobbinth @PhilippGackstatter Thank you for your thorough comments. |
In this PR I propose to update the
Statesection of the Miden documentation:Additional questions: