mirror of
https://github.com/corda/corda.git
synced 2024-12-27 16:28:56 +00:00
63 lines
3.5 KiB
ReStructuredText
63 lines
3.5 KiB
ReStructuredText
Flow library
|
|
============
|
|
|
|
There are a number of built-in flows supplied with Corda, which cover some core functionality.
|
|
|
|
FinalityFlow
|
|
------------
|
|
|
|
The ``FinalityFlow`` verifies the given transactions, then sends them to the specified notary.
|
|
|
|
If the notary agrees that the transactions are acceptable then they are from that point onwards committed to the ledger,
|
|
and will be written through to the vault. Additionally they will be distributed to the parties reflected in the participants
|
|
list of the states.
|
|
|
|
The transactions will be topologically sorted before commitment to ensure that dependencies are committed before
|
|
dependers, so you don't need to do this yourself.
|
|
|
|
The transactions are expected to have already been resolved: if their dependencies are not available in local storage or
|
|
within the given set, verification will fail. They must have signatures from all necessary parties other than the notary.
|
|
|
|
If specified, the extra recipients are sent all the given transactions. The base set of parties to inform of each
|
|
transaction are calculated on a per transaction basis from the contract-given set of participants.
|
|
|
|
The flow returns the same transactions, in the same order, with the additional signatures.
|
|
|
|
|
|
CollectSignaturesFlow
|
|
---------------------
|
|
|
|
The ``CollectSignaturesFlow`` is used to automate the collection of signatures from the counter-parties to a transaction.
|
|
|
|
You use the ``CollectSignaturesFlow`` by passing it a ``SignedTransaction`` which has at least been signed by yourself.
|
|
The flow will handle the resolution of the counter-party identities and request a signature from each counter-party.
|
|
|
|
Finally, the flow will verify all the signatures and return a ``SignedTransaction`` with all the collected signatures.
|
|
|
|
When using this flow on the responding side you will have to subclass the ``AbstractCollectSignaturesFlowResponder`` and
|
|
provide your own implementation of the ``checkTransaction`` method. This is to add additional verification logic on the
|
|
responder side. Types of things you will need to check include:
|
|
|
|
* Ensuring that the transaction you are receiving is the transaction you *EXPECT* to receive. I.e. is has the expected
|
|
type of inputs and outputs
|
|
* Checking that the properties of the outputs are as you would expect, this is in the absence of integrating reference
|
|
data sources to facilitate this for us
|
|
* Checking that the transaction is not incorrectly spending (perhaps maliciously) one of your asset states, as potentially
|
|
the transaction creator has access to some of your state references
|
|
|
|
Typically after calling the ``CollectSignaturesFlow`` you then called the ``FinalityFlow``.
|
|
|
|
ResolveTransactionsFlow
|
|
-----------------------
|
|
|
|
This ``ResolveTransactionsFlow`` is used to verify the validity of a transaction by recursively checking the validity of
|
|
all the dependencies. Once a transaction is checked it's inserted into local storage so it can be relayed and won't be
|
|
checked again.
|
|
|
|
A couple of constructors are provided that accept a single transaction. When these are used, the dependencies of that
|
|
transaction are resolved and then the transaction itself is verified. Again, if successful, the results are inserted
|
|
into the database as long as a [SignedTransaction] was provided. If only the ``WireTransaction`` form was provided
|
|
then this isn't enough to put into the local database, so only the dependencies are checked and inserted. This way
|
|
to use the flow is helpful when resolving and verifying an unfinished transaction.
|
|
|
|
The flow returns a list of verified ``LedgerTransaction`` objects, in a depth-first order. |