Emit network notes and transaction status

[Mirko-von-Leipzig]

The mempool should monitor committed blocks for created network notes. These notes should be submitted via gRPC (#695).

Similarly, the mempool should also monitor for network transactions that have been dropped/reverted from the pool, or committed. These status updates should also be sent via gRPC.

These can currently only identified if they consume a network note - however this information would have been erased since network transactions would register these as unauthenticated..

An initial implementation could simply assume that such a method exists by adding an is_network to AuthenticatedTransaction and default to false such that nothing happens in prod yet.

One alternative is add_network_transaction to block-producer's RPC methods, and to simply trust the builder component. However this can wait until the broader question of how to identify network accounts is resolved.

[bobbinth]

These can currently only identified if they consume a network note - however this information would have been erased since network transactions would register these as unauthenticated..

An initial implementation could simply assume that such a method exists by adding an is_network to AuthenticatedTransaction and default to false such that nothing happens in prod yet.

I wonder if we care about the distinction between network and non-network transactions. When a block is committed, the block producer could send the following to the tx builder:

• A list of all transactions IDs in the block.
• A list of all network output notes in the block - these would be linked to the IDs of transactions which produced them.

I think this should be enough to: (a) figure out which network transactions have been committed (because the tx builder would have a set of network transactions it has submitted to the block producer) and (b) which are the new network notes the tx builder should start processing.

Separately, we'll need an endpoint on the tx builder to get a list of transaction that have been dropped from the mempool. This again could be called for any transaction and then the tx builder should be able to filter it down to the transactions which are relevant to it.

[Mirko-von-Leipzig]

I wonder if we care about the distinction between network and non-network transactions. When a block is committed, the block producer could send the following to the tx builder:

• A list of all transactions IDs in the block.
• A list of all network output notes in the block - these would be linked to the IDs of transactions which produced them.

I think this should be enough to: (a) figure out which network transactions have been committed (because the tx builder would have a set of network transactions it has submitted to the block producer) and (b) which are the new network notes the tx builder should start processing.

Separately, we'll need an endpoint on the tx builder to get a list of transaction that have been dropped from the mempool. This again could be called for any transaction and then the tx builder should be able to filter it down to the transactions which are relevant to it.

Ah yes, that actually makes more sense thank you. The only downside is more data being sent but that's likely negligible.

A list of all network output notes in the block - these would be linked to the IDs of transactions which produced them.

What would the builder do with the origin transaction ID? Is just a list of committed tx IDs, and a separate list of network notes enough?

[bobbinth]

A list of all network output notes in the block - these would be linked to the IDs of transactions which produced them.

What would the builder do with the origin transaction ID? Is just a list of committed tx IDs, and a separate list of network notes enough?

I actually think the approach described in #695 is better than what I proposed. Basically, we could have 2 endpoints:

• The first endpoint accepts a list of (tx_id, status) tuples for all transactions. For now the status would be just committed/failed, but in the future we can add more to indicate how the transaction moves through the mempool.
• The second endpoint could be a list of (note, tx_id) where note is a network note and tx_id is the ID of the transaction which crated the note.