Implement transaction epilogue script

[0xpolygonmiden]

Implement transaction epilogue script

[bobbinth]

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
$n$	meta	Note's metadata consisting of tag and sender (1 element each).
$n + 1$	recipient	Note's recipient computed by hashing, the note's serial number, script hash, and input hash.
$n + 2$	vault_hash	Note's vault hash, computed as a sequential hash of it's assets.
$n + 3$	num_assets	Number of assets contained in this note's vault.
$n + 4$	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.

[bobbinth]

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).

[frisitano]

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:

1. 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?

2. 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?

[bobbinth]

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.

[frisitano]

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
$n$	recipient	Note's recipient computed by hashing, the note's serial number, script hash, and input hash.
$n + 1$	vault_hash	Note's vault hash, computed as a sequential hash of it's assets.
$n + 2$	num_assets	Number of assets contained in this note's vault.
$n + 3$	assets	A list of all note assets laid out one after another.

[frisitano]

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.

[frisitano]

1. 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?

[bobbinth]

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.

[frisitano]

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.

[bobbinth]

Closed by #65