diff --git a/docs/source/api-flows.rst b/docs/source/api-flows.rst index 619090bcfe..932f7a9159 100644 --- a/docs/source/api-flows.rst +++ b/docs/source/api-flows.rst @@ -602,7 +602,7 @@ transaction ourselves, we can automatically gather the signatures of the other r :dedent: 12 Each required signer will need to respond by invoking its own ``SignTransactionFlow`` subclass to check the -transaction and provide their signature if they are satisfied: +transaction (by implementing the ``checkTransaction`` method) and provide their signature if they are satisfied: .. container:: codeset @@ -618,6 +618,14 @@ transaction and provide their signature if they are satisfied: :end-before: DOCEND 16 :dedent: 12 +Types of things to check include: + + * Ensuring that the transaction received is the expected type, i.e. has the expected type of inputs and outputs + * Checking that the properties of the outputs are expected, this is in the absence of integrating reference + data sources to facilitate this + * Checking that the transaction is not incorrectly spending (perhaps maliciously) asset states, as potentially + the transaction creator has access to some of signer's state references + SendTransactionFlow/ReceiveTransactionFlow ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Verifying a transaction received from a counterparty also requires verification of every transaction in its diff --git a/docs/source/component-library-index.rst b/docs/source/component-library-index.rst index 415b81b71b..18a6b2d05a 100644 --- a/docs/source/component-library-index.rst +++ b/docs/source/component-library-index.rst @@ -4,7 +4,6 @@ Component library .. toctree:: :maxdepth: 1 - flow-library contract-catalogue financial-model contract-irs \ No newline at end of file diff --git a/docs/source/flow-library.rst b/docs/source/flow-library.rst deleted file mode 100644 index 59cbb0354a..0000000000 --- a/docs/source/flow-library.rst +++ /dev/null @@ -1,61 +0,0 @@ -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 counterparties 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 counterparty identities and request a signature from each counterparty. - -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``. - -SendTransactionFlow/ReceiveTransactionFlow ------------------------------------------- - -The ``SendTransactionFlow`` and ``ReceiveTransactionFlow`` are used to automate the verification of the transaction by -recursively checking the validity of all the dependencies. Once a transaction is received and checked it's inserted into -local storage so it can be relayed and won't be checked again. - -The ``SendTransactionFlow`` sends the transaction to the counterparty and listen for data request as the counterparty -validating the transaction, extra checks can be implemented to restrict data access by overriding the ``verifyDataRequest`` -method inside ``SendTransactionFlow``. - -The ``ReceiveTransactionFlow`` returns a verified ``SignedTransaction``. \ No newline at end of file diff --git a/docs/source/key-concepts-flows.rst b/docs/source/key-concepts-flows.rst index 1452efe2e8..982d646214 100644 --- a/docs/source/key-concepts-flows.rst +++ b/docs/source/key-concepts-flows.rst @@ -76,7 +76,7 @@ logic behind common processes such as: * Gathering signatures from counterparty nodes * Verifying a chain of transactions -Further information on the available built-in flows can be found in :doc:`flow-library`. +Further information on the available built-in flows can be found in :doc:`api-flows`. Concurrency -----------