Verifying flows in Corda

Question

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?

Answer 1

In detail:

1. It's a DLT (Distributed Ledger Technology); so in a sense, you can't really trust anyone.
2. 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).
3. Even if you gave a node your CorDapp, it can override the responder flow. See links below.
4. Wrong assumptions about responder flows: https://www.corda.net/blog/corda-flow-responder-wrong-assumptions/
5. Configuring responder flows: https://docs.corda.net/flow-overriding.html
6. Overriding flows from external CorDapps: https://dzone.com/articles/extending-and-overriding-flows-from-external-corda
7. 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:

1. Your initiator must validate any received data from the responder(s).
2. 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").

Answer 2

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.