Transaction/note execution conditions

[bobbinth]

With note scripts, we can specify almost arbitrary conditions on how notes can be consumed. However, there are some conditions which we cannot specify via note scripts.

For example, when creating a transaction, it may be desirable to specify that either the transaction is included into a block before block $x$ or not included at all. Or we may wish to specify that a transaction must be executed in the context of a current block (i.e., block height for transaction proof must be the same as for the block proof).

A way to specify such conditions is described below. It relies on how we specify transaction inputs/outputs - so, let's review them first.

To execute a transaction, we execute a transaction program which consists of prologue/epilogue/note scripts/tx script. This program is a Miden VM program and the inputs for this program are provided via the stack and outputs are read from the stack after the program finishes execution. Currently, stack inputs/outputs for a transaction are look as follows:

Inputs

• Block hash (4 elements) - hash of the last known block header.
• Account ID (1 element) - ID of the account involved in the transaction.
• Account commitment (4 elements) - hash of the initial account state.
• Note commitment (4 elements) - sequential hash of (nullifier, script_root) tuples for all notes consumed in the transaction.

Outputs

• Account commitment (4 elements) - hash of the final account state.
• Note commitment (4 elements) - sequential hash (note_hash, note_meta) tuples for all notes created during the transaction.

To support extra conditions, we can add one more element to the output: height delta (1 element). This element will specify maximum delta between the height of the block specified by block hash input and the block in which the transaction is included into the chain. The value of height delta would be interpreted as follows:

• 0 - no restrictions, transaction can be included into the chain at any block.
• 1 - transaction can be included into the chain only in the block immediately following the one with the specified block hash.
• 2 - transaction can be included into the chain only within 2 blocks following the block with the specified hash.
• etc.

The user could specify the value for height delta via tx_script (this will probably also imply that height delta needs to be covered by the transaction signature) - basically, the value returned by the tx_script would become the hight delta.

This functionality would already be pretty useful, but we can take it a step further. Specifically, we can allow notes to specify the height delta. The mechanism could work like this:

• If a note's script returns 0 - no extra conditions are imposed (everything is executed as is now).
• If a note's script returns a non-zero value, height delta for the transaction must be set to 1.

This way, we can create a note which must be executed/proved and included into the chain in the context of the same block. This is hugely useful because for notes intended for network execution, block producers will have to execute a note and immediately include it into the chain. Thus, such notes can assume that the state of all accounts committed to via block hash input is current (this is important for things like oracles).