Reputation: 431
Question : Is there a way to differentiate transactions that the node is involved in or broadcasted vs the chain of txs
Scenario:
FinalityFlow
)When the regulator runs the code below to query its vault, with the intention to only get tx #3, it actually gets all 3 txs. There's no way to distinguish between the 3 txs and only filter tx #3.
val transactionsSnapshot = serviceHub.validatedTransactions.track().snapshot
Is there a way to distinguish transactions that the node are involved in, those it received due to broadcast from some node and those transactions that were part of the chain that you also received due to a broadcast.
Subsequently, when SGX comes, would only the transactions that were received for validation/processing during provenance be in the secure enclave, while transactions that the node is a participant of and received as part of a broadcast exist in the vault storage for querying?
Upvotes: 0
Views: 193
Reputation: 444
To broadcast a transaction, you may have something similar to this ReportToRegulatorFlow. But in addition, on the responder side you could do this
val recorded = subFlow(ReceiveTransactionFlow(otherSideSession, true, StatesToRecord.ONLY_RELEVANT))
// Currently there's no way to distiguish transactions that are from a tx that was broadcasted versus ones from walking the chain and kept in storage
// We use memo/notes to keep track of this to differentiate during tx snapshot enquiry
serviceHub.vaultService.addNoteToTransaction(recorded.id, "BROADCASTED")
To query only the broadcasted tx.
val transactionsSnapshot = serviceHub.validatedTransactions.track().snapshot
val broadcastedTx = transactionsSnapshot.filter{ serviceHub.vaultService.getTransactionNotes(it.tx.id).firstOrNull() == "BROADCASTED" }
To query only participated Tx.
val participatedTx = transactionsSnapshot.filter{ it.tx.requiredSigningKeys.any { resolveKey(it) != null && resolveKey(it) == ourIdentity} }
Upvotes: 0
Reputation: 75
Haven't directly tried what I'm about to suggest in it's entirety; but I have implemented something very similar....implement a future based on a VaultQueryCriteria which only observes states with participants C & D. On every such update, retrieve the transaction (from the list of validated transactions known to the node) where the output state = the state returned from the VaultQueryCriteria.
There's probably a swisher way to do it; but I essentially took a very similar approach to a requirement I had...seems to work satisfactorily. Caveat lector: I'm not so familiar with V2.0 quite yet.
Just a thought - hope it helps.
Upvotes: 0