Enable transaction-specified inputs for notes

[bobbinth]

Currently, note scripts have access to the following properties of a note:

• Note assets, accessible via get_assets kernel procedure.
• Note inputs, accessible via get_inputs kernel procedure.
• Note sender, accessible via get_sender note procedure.

The script can also read global transaction variables (e.g., block number) and we can add procedures to the kernel to enable access to global account state, chain MMR etc.

The above is already pretty powerful, but we can make note scripts even more powerful if we enable per-transaction note inputs (I'll call these note args to distinguish them from the current note inputs). These args can be placed on the stack by the kernel runtime right before a note's script is called, and then the script will have access to these args.

One use case for these are orders in an order-book DEX (see #330 (comment)). There, a note can represent an order, and if we can't find a perfect matching order, we may want to "consume" a part of the note.

To consume a part of the note, the note script would need to know how to "split" itself. For example, we could have a script which roughly does the following:

if rem == 0 
    account.swap(some_asset, recipient)
else
    account.swap(some_asset - rem, recipient)
    account.send_remainder(rem, new_recipient)
end

In the above, if rem == 0, the whole note is consumed in the trade. But if rem is greater than 0, then we consume a part of the note in a trade, and send the remainder of the note's assets into a new note (which can then be again consumed by the DEX account).

In the above, rem would be this per-transaction note argument and whoever generates this transaction (e.g., a DEX operator), would be able to specify the value of rem based on the current state of the order book.

[Dominik1999]

I can give it a try

[Dominik1999]

I have started with this, but there are some implementation details that we might need to discuss.

• Do we want note args per note?

If so, we might need to provide a vec![note_arg_0, note_arg_1, ... ] to the TransactionExecutor and inject them into the AdviceProvider and read note args the same way as we read note inputs per note in the transaction prologue. Alternatively, we can inject one value to the transaction kernel, let's say rem from your example. This value would be on top of the stack of note 1 and be manipulated and transferred to note 2 and so on

• Position of note args should be after note script root?

At the moment, any note script has the note script root on top of the stack. We can put the note args at pos 5 of the stack if we stick to the Felt idea. Would you agree?

[bobbinth]

Do we want note args per note?

I think so. We could modify the InputNote definition to include optional note args.

Position of note args should be after note script root?

I'm actually not sure we need to "unhash" not args to memory. Another option is to just move them from the advice provider onto the stack before a note is executed. Though, to avoid potential attacks, it may be good to put a hash of note args into memory during transaction prologue.