Comments (10)
To confirm, am I correct in thinking that the created note vault hash is a sequential hash of the associated assets?
Yes, this is correct.
Is there a reason why this isn't computed at the time of note creation and is instead deferred to the epilogue?
My thinking was that we may allow modifying notes after they are created (i.e., by adding assets).
Do we want to create a place in memory to store the created note vault hash?
Yes, I think this is a good idea. I think we now also need to track a word with metadata for created notes as well. For example, the layout could look like:
Memory address | Variable | Description |
---|---|---|
meta |
Note's metadata consisting of tag and sender (1 element each). |
|
recipient |
Note's recipient computed by hashing, the note's serial number, script hash, and input hash. | |
vault_hash |
Note's vault hash, computed as a sequential hash of it's assets. | |
num_assets |
Number of assets contained in this note's vault. | |
assets |
A list of all note assets laid out one after another. |
One other thought I had: maybe we should put num_assets
into note metadata? We have 2 elements "free" there. It would add a few cycles to processing a note, but I think it looks cleaner (and the same could be done for consumed notes as well).
I'm not sure I follow here. For created notes we wouldn't expect them to already exist in the DB as they are being created as part of the transaction. I'm not sure I understand what you mean by populating the metadata as part of the prologue.
Ah yes, I was thinking about consumed notes here. For them, we'd need to populate metadata as a part of prologue, but that's no relevant to created notes.
from miden-base.
I'm guessing this would be useful if a user wants to consume a note via a network transaction whilst hiding the connection with the initial account that produced the note?
Could be useful for both network and local transactions as it basically hides sender from the recipient.
What is the benefit of not incrementing the nonce in this scenario?
If the state doesn't change, many users can execute transactions agains the same account concurrently. This means that, for example, there needs to be just a single "relay" account and everyone can use it. If we do increment a nonce, there are going to be synchronization issues - i.e., if you and I try to use the same account at the same time, our transactions would conflict with each other (as we may try to increment the nonce to the same value).
from miden-base.
Transaction epilogue is a program which is executed at the end of a transaction (after note scripts and tx script are executed). The epilogue needs to accomplish the following tasks:
- Compute hash of the final account state and put it on the stack.
a. If the initial and final account states are different, we also need to make sure that account nonce has been incremented by one.
Given recent conversations regarding nonce rules to allow for async transaction execution do we want to loosen this condition and instead ensure that is has increased but not necessarily by one?
- Compute a sequential hash of script roots of all consumed notes and put the result onto the stack.
Computing consumed note script hash
Computing a sequential hash of script roots of all consumed notes should also be pretty straightforward. Consumed notes are laid out as described in #14, and we just need to read MAST roots for each consumed note (located at memory offset n+2), and then absorb them into a hasher state.
As part of the prologue we compute a sequential hash of all (nullifier, script root) pairs (which is also provided as a global input). Do we need this as well?
The reason why we need to do this is to bind the sequence of executed note scripts with the appropriate note inputs/assets. Basically, to prevent the prover from executing a note script of one note against inputs/assets of another note.
I believe the assertions are already provided via the prologue / note setup script?
Do we need to make any modifications to support created note metadata?
from miden-base.
Given recent conversations regarding nonce rules to allow for async transaction execution do we want to loosen this condition and instead ensure that is has increased but not necessarily by one?
Yes - let's do that.
As part of the prologue we compute a sequential hash of all (nullifier, script root) pairs (which is also provided as a global input). Do we need this as well?
No - this is no longer needed.
I believe the assertions are already provided via the prologue / note setup script?
Yes - no need to do this here again.
Do we need to make any modifications to support created note metadata?
Yes, stack state after epilogue is executed should look like this:
[final_acct_hash, created_notes_hash, ...]
Where created_notes_hash
is a sequential hash of all (note_hash, note_meta)
tuples of created notes.
I don't remember if we already have it, but note metadata would be populated by the prologue at the time when we verify that a note is in the note DB.
Overall, I'm imagining the data structure to look like this:
So, note hash and note metadata would be siblings in the note DB.
from miden-base.
To confirm, am I correct in thinking that the created note vault hash is a sequential hash of the associated assets? Is there a reason why this isn't computed at the time of note creation and is instead deferred to the epilogue? Do we want to create a place in memory to store the created note vault hash? Something like:
Memory address | Variable | Description |
---|---|---|
recipient |
Note's recipient computed by hashing, the note's serial number, script hash, and input hash. | |
vault_hash |
Note's vault hash, computed as a sequential hash of it's assets. | |
num_assets |
Number of assets contained in this note's vault. | |
assets |
A list of all note assets laid out one after another. |
from miden-base.
Do we need to make any modifications to support created note metadata?
Yes, stack state after epilogue is executed should look like this:
[final_acct_hash, created_notes_hash, ...]
Where
created_notes_hash
is a sequential hash of all(note_hash, note_meta)
tuples of created notes.I don't remember if we already have it, but note metadata would be populated by the prologue at the time when we verify that a note is in the note DB.
Overall, I'm imagining the data structure to look like this:
So, note hash and note metadata would be siblings in the note DB.
I'm not sure I follow here. For created notes we wouldn't expect them to already exist in the DB as they are being created as part of the transaction. I'm not sure I understand what you mean by populating the metadata as part of the prologue.
The data structure looks good to me.
from miden-base.
- Compute hash of the final account state and put it on the stack.
a. If the initial and final account states are different, we also need to make sure that account nonce has been incremented by one.
In what transaction scenarios would you expect the account hash to stay the same?
As we parse the consumed note commitment as a public input I don't think we will need to leave it on the stack at the end of execution?
from miden-base.
In what transaction scenarios would you expect the account hash to stay the same?
One scenario I was thinking about was "relay" accounts which could be used to further hide the transaction graph. These accounts could consume and the produce the same exact note (minus transaction fees) - but the account state would not change. This way, the re-issued note would look like it came from the "relay" account rather than the original account.
As we parse the consumed note commitment as a public input I don't think we will need to leave it on the stack at the end of execution?
Correct - for consumed notes, the hash is provided via stack inputs. For created notes, the hash would be returned via stack outputs.
from miden-base.
One scenario I was thinking about was "relay" accounts which could be used to further hide the transaction graph. These accounts could consume and the produce the same exact note (minus transaction fees) - but the account state would not change. This way, the re-issued note would look like it came from the "relay" account rather than the original account.
I'm guessing this would be useful if a user wants to consume a note via a network transaction whilst hiding the connection with the initial account that produced the note?
What is the benefit of not incrementing the nonce in this scenario? I guess it would allow for more asynchronicity. One question is whether we should enshrine nonce rules into the kerenel / protocol or if they should be applied at the account / wallet level.
from miden-base.
Closed by #65
from miden-base.
Related Issues (20)
- Add CI job for `doc` + make sure that Miden base passes `make doc` HOT 1
- winter_rand_utils Compiled Under Testing Feature Breaks for WASM Builds HOT 1
- Refactor `apply_delta` for Storage Maps HOT 3
- Allow increasing an account's nonce without changing its state HOT 1
- Add `create_wallet_with_custom_code` wallet helper function in miden-lib HOT 5
- Refactor transaction kernel events and errors HOT 1
- Make memory setters consistent HOT 1
- Checking that a transaction does not consume two identical notes
- Update names used for input/output notes HOT 4
- Refactor batch/block note tree structure
- Refactor `NoteOrigin` / `NoteInclusionProof` structs HOT 3
- Fix the stack management for account procedures HOT 7
- Allow setting block timestamp and block number when using TransactionContextBuilder HOT 3
- Refactor delta's vault and storage to use maps HOT 2
- feat: add a procedure for basic wallets that creates notes with 0 or more assets HOT 1
- Refactor account storage to use sequential hash rather than a Merkle tree
- Make `miden_lib::notes::build_swap_tag()` public HOT 1
- Creation of privacy optimized P2ID note HOT 6
- Remove `send_asset` procedure from the basic wallet. HOT 6
- Improve the doc to add a detailed explanation of how to create public notes
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from miden-base.