Add `VerifiedTransaction`

[PhilippGackstatter]

What should be done?

Add VerifiedTransaction struct to ProvenBatch.

Basically, right now, a block does not contain enough info to figure out what happened in a given transaction. This is not something that is critical for building blocks, but it would be nice to have this info to show to the user.
#919 (comment)

How should it be done?

Add the struct (roughly) as defined in #919 (comment).

These should be created from a ProvenTransaction after they were verified in LocalBatchProver::prove.
We then probably should include VerifiedTransaction in a ProvenBatch.

One open question to me is whether ProvenBatch will end up in a Block or not. Then the block would actually contain all the interesting data for the explorer to show I believe.

When is this task done?

Presumably when the block contains enough information so that it's possible (in the explorer, for example)

[...] to show which nullifiers were consumed in the transaction and which output notes were created.
#919 (comment)

Additional context

No response

[PhilippGackstatter]

As mentioned in #1069, it may be useful to have the block header commit to transactions in a merkle tree to allow for simple inclusion proofs of transactions in a block. Currently the block header commits to transactions as a sequential hash, which makes proving inclusion possible but requires providing the complete list of (TransactionId, AccountId) tuples. Using a tree makes this easier, but I'm not sure yet whether it's worth the cost.

This is generally useful to, for example, enable revealing a private transaction to some third party and prove that it was included in some block.

• The use case I had in mind initially was that it would allow proving that some note was created by an account, but that fact is already established as part of NoteMetadata::sender and could be proven that way (i.e. with an inclusion proof in a block's note tree).
• Another use case may be proving that some note was consumed by an account by proving the inclusion of the transaction that consumed it.
• Another use case could be to help establish the duration of holding funds by proving which transactions (and when) moved them.

One question is how this tree is built and by whom (as mentioned in #1069 (comment)). One idea is that the batch kernel could build a tree of its transactions and the block kernel could aggregate those trees into a larger one, similar to how batch note tree and block note tree interact.

Edit: One other use case that came to mind is chained transactions. For example, if TX A produces a note X and TX B consumes note X in the same batch, then the overall batch won't have X as an output note. It would still be useful for someone to be able to prove that their transaction produced note X.

[bobbinth]

One idea is that the batch kernel could build a tree of its transactions and the block kernel could aggregate those trees into a larger one, similar to how batch note tree and block note tree interact.

I think one question we'll need to answer here is whether the tree should be of fixed size, and if so, what should the size be. For notes, the tree at the batch level is 10 levels deep - and so this naturally imposes a limit of 1024 notes per batch. We could probably impose a similar limit on transactions.

[PhilippGackstatter]

Closed by #1247.