public class ValidatingNotaryFlow
extends Service
A notary commit flow that makes sure a given transaction is valid before committing it. This does mean that the calling party has to reveal the whole transaction history; however, we avoid complex conflict resolution logic where a party has its input states "blocked" by a transaction from another party, and needs to establish whether that transaction was indeed valid.
Constructor and Description |
---|
ValidatingNotaryFlow(Party otherSide,
TimestampChecker timestampChecker,
UniquenessProvider uniquenessProvider)
A notary commit flow that makes sure a given transaction is valid before committing it. This does mean that the calling
party has to reveal the whole transaction history; however, we avoid complex conflict resolution logic where a party
has its input states "blocked" by a transaction from another party, and needs to establish whether that transaction was
indeed valid.
|
Modifier and Type | Method and Description |
---|---|
void |
beforeCommit(SignedTransaction stx)
No pre-commit processing is done. Transaction is not checked for contract-validity, as that would require fully
resolving it into a TransactionForVerification, for which the caller would have to reveal the whole transaction
history chain.
As a result, the Notary will commit invalid transactions as well, but as it also records the identity of
the caller, it is possible to raise a dispute and verify the validity of the transaction and subsequently
undo the commit of the input states (the exact mechanism still needs to be worked out).
|
beforeCommit, call, getOtherSide, getTimestampChecker, getUniquenessProvider
call, getCounterpartyMarker, getLogger, getProgressTracker, getRunId, getServiceHub, getStateMachine, receive, send, sendAndReceive, setStateMachine, subFlow, subFlow, track
public ValidatingNotaryFlow(Party otherSide, TimestampChecker timestampChecker, UniquenessProvider uniquenessProvider)
A notary commit flow that makes sure a given transaction is valid before committing it. This does mean that the calling party has to reveal the whole transaction history; however, we avoid complex conflict resolution logic where a party has its input states "blocked" by a transaction from another party, and needs to establish whether that transaction was indeed valid.
public void beforeCommit(SignedTransaction stx)
No pre-commit processing is done. Transaction is not checked for contract-validity, as that would require fully resolving it into a TransactionForVerification, for which the caller would have to reveal the whole transaction history chain. As a result, the Notary will commit invalid transactions as well, but as it also records the identity of the caller, it is possible to raise a dispute and verify the validity of the transaction and subsequently undo the commit of the input states (the exact mechanism still needs to be worked out).