As per corda documentaion and my understanding contract verification called at time of transactionBuilder. For R&D I put logger on contract verification function. One thing observed that contract verification called at time of transactionBuilder also in collectSignature and in finalityflow also.
In collectSignatureFlow called 3 times and Finality flow also called 3 times.
Current setup have 2 nodes one notary in non-validating mode.
My question is that in collectSignatureFlow verify called on diffrent nodes and if yes does notary called verify function too. Same question is with finality flow.
CollectSignaturesFlow, called by the node gathering the signatures, calls verify. SignTransactionFlow, the responder flow called by the nodes adding their signatures, also calls verify before signing.
FinalityFlow calls verify. NotaryServiceFlow, the flow run by the notary in response to FinalityFlow, should call verify if the notary is validating (in fact, this is the definition of a validating notary). And finally, ReceiveTransactionFlow, the flow run by the transaction's participants in response to FinalityFlow, calls verify before storing the transaction.
Related
I want to regularly check that output state is not consumed by tampering, so I want to ask the notary whether the state is consumed or not. Is this possible ?
I believe you would need to write a flow that is executed by the corda notary which then performs the vault query on the notary. This is listed as an experimental feature in the corda docs so you may want to rethink how you are designing your cordapp first. I haven't utilised this feature a great deal before myself so I'm unsure how well it's supported but it should work. This does mean however you are likely to be running your own corda network as you need control over how the notary is deployed.
It may be more appropriate to have another trusted node or party that has visibility and is a signer on the ContractState's that you want to check. Your third party would then also have a responder flow that performs a vault query on it's own vault and responds back to initiator.
You can query a node for consumed states by specifying Vault.StateStatus in the vault query API
val vaultSnapshot = proxy.vaultQueryBy<ContractState>(
QueryCriteria.VaultQueryCriteria(Vault.StateStatus.UNCONSUMED))
I need to store some information from Corda (such as LinearId, Transaction Hash etc) in an off-ledger database (not an extra table in the node database) for subsequent external processing and downstream actions.
The key is that the code has to run after a specific flow (not all flows) has completed and only on one side/node of the transaction.
The node trigger could write to the external database directly
Or the trigger could write the data to a JMS queue for an external engine to pick up and process
How can I trigger an action after a flow has completed?
One way you could do this is with a responder flow. It depends on your use case but one thing you could do is just hold off on the return statement in the responder flow and just run some additional code or make an HTTP request from the responder flow.
Here's a code example: (you can see how it returns the subflow, but you can return it later and run some code after the return as well potentially)
https://github.com/corda/samples-kotlin/blob/master/Advanced/obligation-cordapp/workflows/src/main/kotlin/net/corda/samples/obligation/flows/IOUSettleFlow.kt#L98-L113
More on responders flows: https://docs.corda.net/docs/corda-os/4.7/api-flows.html
Making an HTTP request from a flow: https://github.com/corda/samples-java/blob/master/Basic/flow-http-access/workflows/src/main/java/net/corda/samples/flowhttp/HttpCallFlow.java#L35-L39
How does a notary/node verify that a specific flow has been called when it receives the transaction?
Does this mean Corda can guarantee that the flow has not been modified from what was stated in the corresponding Cordapp?
In detail:
It's a DLT (Distributed Ledger Technology); so in a sense, you can't really trust anyone.
The notary doesn't receive flows, it receives transactions and makes sure that there is no double-spend (i.e. consumed inputs are not being consumed again).
Even if you gave a node your CorDapp, it can override the responder flow. See links below.
Wrong assumptions about responder flows: https://www.corda.net/blog/corda-flow-responder-wrong-assumptions/
Configuring responder flows: https://docs.corda.net/flow-overriding.html
Overriding flows from external CorDapps: https://dzone.com/articles/extending-and-overriding-flows-from-external-corda
When you send and receive data between an initiator and its responders; the received data (on both ends) is considered untrusted; you must unwrap it and validate it: https://docs.corda.net/api-flows.html#receive
So in short:
Your initiator must validate any received data from the responder(s).
Your responder must validate any received data from the initiator; plus if you expect the initiator to be a certain entity, you must validate that the counter-party (that sent you the flow session) is who you expect it to be (e.g. flowSession.counterParty == "O=Good Org, L=London, C=UK").
Adel's answer covers the right ways to not trust your counterparties from the application flow level but there are also operational protections which can used. Strong contracts can help prevent badly formed transactions as Corda does not allow for unknown contracts in a well setup network.
The network parameters defines what smart contract cordapp jars are acceptable for validation. The most common form of contract constraints is signature constraints which means that any contract jar signed by the same developer key can be accepted. This prevents a malicious counterparty from forcing you to run weak validation: https://docs.corda.net/api-contract-constraints.html#signature-constraints
As of Corda 4 any unrecognized contract cordapp jar will not be trusted unless the node operator explicitly tells Corda to trust the jar. https://docs.corda.net/cordapp-build-systems.html#cordapp-contract-attachments Once a signature is trusted then any future jars signed by that signature will implicitly be trusted.
There is a bank which creates a contract which is then accepted by the lender and the borrower. After signing the contract the lender provides fund to the borrower. The bank then creates an obligation state based on the data received by calling an external service automatically.
And Now
1) In API Layer, I am calling first flow which creates one state.
2) In API layer itself, On success of first flow , I am calling the http request to external service and get the data.
3) Now I pass the http response to the the second flow for creating the other state.
Can you please let me know if there is any issue with this approach.
Requirment is I want to trigger the first flow manually, but calling external service and initiating the second flow should happen automatically
I had referred the link given below.
Making asynchronous HTTP calls from flows
You'll make calls to an external service during the running of flows.
The best place to get started would be looking at the CorDapp samples here. In particular, take a look at the Accessing External Data section
I am trying to implement the following use-case in Corda:
FlowA has been invoked on PartyA via startFlowDynamic. FlowA creates a partially signed transaction and invokes FlowB on PartyB via sendAndReceive. A human user shall now review and manually approve this transaction. Ideally FlowB should suspend after receiving the transaction. I would like to be able to query for suspended instances of FlowB via RPC, and present those (or rather some representation of the transaction therein) to the user in my UI. Then, after the user actions his approval, I would like to resume FlowB via RPC, which would then sign the transaction and return it to FlowA on PartyA.
I noticed that I can inspect suspended flows to some degree via CordaRPCOps.stateMachineAndUpdates and I read the tutorial on progress tracking, but it doesn't quite suffice for my case. I also read that interacting with people from flows is listed as a future feature, I just wondered if there isn't already some way to accomplish this ?
See the Negotiation Cordapp sample for an example of how this would work in practice here.
Corda doesn't currently support suspending a flow for user interaction.
However, you can support this kind of workflow as follows. Suppose you're writing a CorDapp for loan applications. You could have an initial flow that agrees the creation of a loanApplicationstate between two parties. From there, the approver can inspect the loan application, and either kick off an approve flow that creates a transaction to transform the loanApplication into an approvedLoan state, or kick off a reject flow to consume the loanApplication state without issuing an approvedLoan state.
Equally, you could add a status field to the loan state, specifying whether the loan is approved or not. Initially, the loan state would have the field set to unapproved. Then the approver could kick off one of two flows to update the loan state, to either have an approved or a rejected status.
I'm not sure if this is a "recommended approach" but I implemented a Quasar compatible AsynchListenableFuture in my flow as someone else had described here.
I needed to suspend a flow and wait for the production of a state from another flow (in response to a user interaction). It seems to work, but suspect it could be regarded as rather off-piste(?!).
Splitting the activities into atomic flows invoked directly by UI interaction is fine, but I needed a sort of "monitoring" flow to wait for an external (e.g. user) event before determining which sub flow to initiate next, and this needed to happen automatically and from within a flow already invoked prior to the the user interaction - the flow logic is then conditional on a state change which may arise from a user interaction or an incoming transaction from another node. In my case, this high level monitoring flow detects the consumption of a known state on the node, then invokes a subflow in response. The high level flow waits on the AsynchListenableFuture as described in the answer referenced above. I created a composite VaultQuery on an attribute of states of contract state types of interest (e.g custom field X = Y), and converted the returned observable (returned from trackBy.future) to a Quasar compatible AsynchListenableFuture. When the state is consumed by a transaction created by a flow triggered by the external action, the future returns and the automatic event (in my case the creation of an other transaction with another party) is executed.
I'm only experimenting / evaluating Corda, not sure how robust this approach would be in production reality, but it seems to work OK, hope this helps in some way.
Some form of higher level workflow flows in Corda, which can wait on external events and conditionally invoke other flows depending on the external action would be of real interest in my context.