We have tried to make every demo, example, tutorial and sample to be both usuable via the command line and also the IntelliJ IDE.
+Most developers will find writing, editing and debugging code more easily done via tools such as an IDE, but when code needs
+to be deployed to run as nodes, control must be done via the command line - no organisations allow their systems to be running via
+a developer environment.
IntelliJ (the preferred IDE in R3) integrates well with gradle (our chosed build, deploy and CLI tool). IntelliJ understands gradle
+tasks and dependencies, automatically loading them in the background when a project is first loaded or the gradle
+project changes. Occasionally, however, you may need to refresh the gradle project manually - but this is hinted to you
+by the IDE. It’s a good idea to do this before carrying on with other work (and in fact you may find it is essential to pick
+up new libraries etc).
+
There are some great resources about how to get started using IntelliJ. As opposed to trying to repeat them here, we advise
+you to go to the IntelliJ docs here.
Due to the nature of their respective command interfaces, gradle is typically ran in windows with the command gradle.bat
+(or gradlew.bat if using the wrapper) and in Mac / Unix environments it is ran via ./gradlew. For brevity, the
+simple windows syntax gradle is used for the majority of the documentation.
+
As well as including the most significant run and build configurations in the IDE, we also provide gradle tasks to build, install
+and run significant parts of Corda demos and tools. Gradle is highly extensible and we use it for downloading required resources,
+building components, installing those built components into shared areas, configuring the scripts that run nodes, starting
+up demonstration API calls amongst other things. It is exceptionally good at deriving dependency maps and therefore performing
+the preceeding tasks required in order to do the requested task. However, when confusing build errors manifest, then sometimes
+a gradleclean may be required in order to clear out any build areas that have an inconsistent state. The total build time
+from downloading / cloaning the repo to a complete build should be only a few minutes, obviously slightly longer if the
+unit tests are run.
Note that the list of tasks can be ran for any gradle project can be displayed by running the task tasks. Also note that
+gradle is hierachical and therefore tasks in child directories can be run using a colon seperator - ie if you want to run
+the sample attachment-demo runSender you would use the command gradlesamples:attachment-demo:runSender
+
The most frequent gradle tasks you will probably be running are build and install. The build command also executes the
+unit tests as well. If you want to build without this level of verification, then use the assemble command - but we do
+not recommend this. After running build, the install tasks copies over the built jars into the local maven repository
+which will then makes these available for either the sample code or use with the CorDapp template.
Tasks and processes that are run directly via the IDE (including via the usage of the driver DSL) can be remotely debugged.
+We do not have java debugging currently enabled in the runnodes scripts generated by a process we refer to as ‘cordformation’
+but we will be implementing that shortly.
To debug: From the IDE, configure the debug connectivity option by the “Edit Configurations” and choosing “+” and then “Remote”.
+The debug port start at 5005 and increments for each additional node that starts, the order given by the list in the main
+driver configuration (which is primarily listed in the main function of Main.kt for each sample. Look for the string
+Listeningfortransportdt_socketataddress:5xxx in the log output to determine the exact port for that node. If the log
+messages are mixed from several nodes to the same console, then (as earlier stated), the port numbers increment in the order
+they are listed in the driver DSL configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/build/html/_images/allCompositionChart.png b/docs/build/html/_images/allCompositionChart.png
new file mode 100644
index 0000000000..e33304d8db
Binary files /dev/null and b/docs/build/html/_images/allCompositionChart.png differ
diff --git a/docs/build/html/_images/anyCompositionChart.png b/docs/build/html/_images/anyCompositionChart.png
new file mode 100644
index 0000000000..7ee61cf001
Binary files /dev/null and b/docs/build/html/_images/anyCompositionChart.png differ
diff --git a/docs/build/html/_images/commPaperClauses.png b/docs/build/html/_images/commPaperClauses.png
new file mode 100644
index 0000000000..19f22cbdfe
Binary files /dev/null and b/docs/build/html/_images/commPaperClauses.png differ
diff --git a/docs/build/html/_images/commPaperExecution.png b/docs/build/html/_images/commPaperExecution.png
new file mode 100644
index 0000000000..1921e59e91
Binary files /dev/null and b/docs/build/html/_images/commPaperExecution.png differ
diff --git a/docs/build/html/_images/firstCompositionChart.png b/docs/build/html/_images/firstCompositionChart.png
new file mode 100644
index 0000000000..57dbb869d8
Binary files /dev/null and b/docs/build/html/_images/firstCompositionChart.png differ
diff --git a/docs/build/html/_images/groupClauseVerifyChart.png b/docs/build/html/_images/groupClauseVerifyChart.png
new file mode 100644
index 0000000000..417ac70592
Binary files /dev/null and b/docs/build/html/_images/groupClauseVerifyChart.png differ
diff --git a/docs/build/html/_images/intellij-welcome.png b/docs/build/html/_images/intellij-welcome.png
new file mode 100644
index 0000000000..4c3192b547
Binary files /dev/null and b/docs/build/html/_images/intellij-welcome.png differ
diff --git a/docs/build/html/_images/public-key-tree-2.png b/docs/build/html/_images/public-key-tree-2.png
deleted file mode 100644
index 5dc70e11e2..0000000000
Binary files a/docs/build/html/_images/public-key-tree-2.png and /dev/null differ
diff --git a/docs/build/html/_images/public-key-tree.png b/docs/build/html/_images/public-key-tree.png
deleted file mode 100644
index 66909de006..0000000000
Binary files a/docs/build/html/_images/public-key-tree.png and /dev/null differ
diff --git a/docs/build/html/_images/run-config-drop-down.png b/docs/build/html/_images/run-config-drop-down.png
new file mode 100644
index 0000000000..ef4e04ab5e
Binary files /dev/null and b/docs/build/html/_images/run-config-drop-down.png differ
diff --git a/docs/build/html/_images/unlinked-gradle-project.png b/docs/build/html/_images/unlinked-gradle-project.png
new file mode 100644
index 0000000000..f4d8377cf6
Binary files /dev/null and b/docs/build/html/_images/unlinked-gradle-project.png differ
diff --git a/docs/build/html/_sources/CLI-vs-IDE.txt b/docs/build/html/_sources/CLI-vs-IDE.txt
new file mode 100644
index 0000000000..0b58c86c88
--- /dev/null
+++ b/docs/build/html/_sources/CLI-vs-IDE.txt
@@ -0,0 +1,67 @@
+CLI vs IDE
+==========
+
+We have tried to make every demo, example, tutorial and sample to be both usuable via the command line and also the IntelliJ IDE.
+Most developers will find writing, editing and debugging code more easily done via tools such as an IDE, but when code needs
+to be deployed to run as nodes, control must be done via the command line - no organisations allow their systems to be running via
+a developer environment.
+
+IDE - IntelliJ
+--------------
+
+IntelliJ (the preferred IDE in R3) integrates well with gradle (our chosed build, deploy and CLI tool). IntelliJ understands gradle
+tasks and dependencies, automatically loading them in the background when a project is first loaded or the gradle
+project changes. Occasionally, however, you may need to refresh the gradle project manually - but this is hinted to you
+by the IDE. It's a good idea to do this before carrying on with other work (and in fact you may find it is essential to pick
+up new libraries etc).
+
+There are some great resources about how to get started using IntelliJ. As opposed to trying to repeat them here, we advise
+you to go to the `IntelliJ docs here `_.
+
+Command Line
+------------
+
+Windows vs Mac / Unix
+*********************
+
+Due to the nature of their respective command interfaces, gradle is typically ran in windows with the command ``gradle.bat``
+(or ``gradlew.bat`` if using the wrapper) and in Mac / Unix environments it is ran via ``./gradlew``. For brevity, the
+simple windows syntax ``gradle`` is used for the majority of the documentation.
+
+As well as including the most significant run and build configurations in the IDE, we also provide gradle tasks to build, install
+and run significant parts of Corda demos and tools. Gradle is highly extensible and we use it for downloading required resources,
+building components, installing those built components into shared areas, configuring the scripts that run nodes, starting
+up demonstration API calls amongst other things. It is exceptionally good at deriving dependency maps and therefore performing
+the preceeding tasks required in order to do the requested task. However, when confusing build errors manifest, then sometimes
+a ``gradle clean`` may be required in order to clear out any build areas that have an inconsistent state. The total build time
+from downloading / cloaning the repo to a complete build should be only a few minutes, obviously slightly longer if the
+unit tests are run.
+
+Frequently Used Gradle Tasks
+****************************
+
+Note that the list of tasks can be ran for any gradle project can be displayed by running the task ``tasks``. Also note that
+gradle is hierachical and therefore tasks in child directories can be run using a colon seperator - ie if you want to run
+the sample attachment-demo ``runSender`` you would use the command ``gradle samples:attachment-demo:runSender``
+
+The most frequent gradle tasks you will probably be running are ``build`` and ``install``. The ``build`` command also executes the
+unit tests as well. If you want to build without this level of verification, then use the ``assemble`` command - but we do
+not recommend this. After running build, the ``install`` tasks copies over the built jars into the local maven repository
+which will then makes these available for either the sample code or use with the CorDapp template.
+
+Debugging
+---------
+
+Tasks and processes that are run directly via the IDE (including via the usage of the ``driver`` DSL) can be remotely debugged.
+We do not have java debugging currently enabled in the ``runnodes`` scripts generated by a process we refer to as 'cordformation'
+but we will be implementing that shortly.
+
+Via the IDE
+***********
+
+To debug: From the IDE, configure the debug connectivity option by the "Edit Configurations" and choosing "+" and then "Remote".
+The debug port start at 5005 and increments for each additional node that starts, the order given by the list in the main
+driver configuration (which is primarily listed in the ``main`` function of ``Main.kt`` for each sample. Look for the string
+``Listening for transport dt_socket at address:5xxx`` in the log output to determine the exact port for that node. If the log
+messages are mixed from several nodes to the same console, then (as earlier stated), the port numbers increment in the order
+they are listed in the driver DSL configuration.
\ No newline at end of file
diff --git a/docs/build/html/_sources/clauses.txt b/docs/build/html/_sources/clauses.txt
new file mode 100644
index 0000000000..9e55fc1e4c
--- /dev/null
+++ b/docs/build/html/_sources/clauses.txt
@@ -0,0 +1,278 @@
+Clauses key concepts
+====================
+
+Basic clause structure
+----------------------
+
+A clause is a small building block for assembling contract verification logic, reusable and ready to test in separation.
+To see clauses in action go to: :doc:`tutorial-contract-clauses`.
+Let's take a look at a simplified structure of the ``Clause`` class:
+
+.. container:: codeset
+
+ .. sourcecode:: kotlin
+
+ abstract class Clause {
+
+ /** Determine whether this clause runs or not */
+ open val requiredCommands: Set> = emptySet()
+
+ @Throws(IllegalStateException::class)
+ abstract fun verify(tx: TransactionForContract,
+ inputs: List,
+ outputs: List,
+ commands: List>,
+ groupingKey: K?): Set
+ ...
+ }
+
+Basic clause structure contains two important components: ``requiredCommands`` and ``verify`` function.
+A clause is triggered when all ``requiredCommands`` are present in transaction's command set (opposite inclusion doesn't have to hold).
+Then the ``verify`` function is run, which checks if transaction meets conditions specified by this clause. Verification
+is no different than normal contract verification but using clauses it's split into smaller generic code blocks with single verify method.
+
+When writing a contract you need to override the contract's ``verify`` function which should call ``verifyClause``. See: :ref:`verify_ref`.
+
+.. note:: A clause ``verify`` function returns the set of processed commands, at the end of ``verifyClause`` execution
+ there is a check if all of transaction's commands were matched. If not then an exception is raised. This is done to
+ enforce that spurious commands cannot be included in a transaction, ensuring that the transaction is as clear as
+ possible. As an example imagine a transaction with two commands: ``Move`` and ``Issue`` included, with verification written
+ using ``FirstComposition`` on clauses that require single command set. Thus only one of transaction's commands will match
+ leaving the second unprocessed. It should raise an error - we want to ensure that commands set is minimal to simplify
+ analysis of intent of a transaction.
+
+An example ``verify`` from ``Obligation`` contract:
+
+.. container:: codeset
+
+ .. sourcecode:: kotlin
+
+ override fun verify(tx: TransactionForContract) = verifyClause(tx, FirstComposition(
+ Clauses.Net(),
+ Clauses.Group
()
+ ), tx.commands.select())
+
+It takes transaction to be verified, and passes it along with a top-level clause and commands to the ``verifyClause``
+function. As you can see above we have used ``FirstComposition`` which is a special type of clause, which extends the
+``CompositeClause`` abstract class (in that particular case, it ensures that either ``Net`` or ``Group`` will run - for explanation see `FirstComposition`_).
+It's a type of clause that adds support for encapsulating multiple clauses and defines common behaviour for that composition.
+There is also a ``GroupClauseVerifier`` special clause, which specifies how to group transaction input/output states
+together and passes them to adequate clause for further processing.
+
+Composition clauses
+-------------------
+
+One of the most important concepts of clauses - composition clauses which extend ``CompositeClause`` abstract class,
+providing a range of ways of assembling clauses together. They define a logic of verification execution specifying which clauses
+will be run.
+
+AllComposition
+~~~~~~~~~~~~~~
+
+**Description**
+
+Composes a number of clauses, such that all of the clauses must run for verification to pass.
+
+.. image:: resources/allCompositionChart.png
+
+Short description:
+
+- ``AllComposition`` holds clauses *Cl1,..,Cl5*.
+- Check if all clauses that compose ``AllComposition`` have associated commands in a command set - if not, verification fails.
+- After successful check runs verification logic specific for every clause *Cl1,..,Cl5* from that composition.
+
+**Usage**
+
+See code in `GroupClauseVerifier`_.
+
+AnyComposition
+~~~~~~~~~~~~~~
+
+**Description**
+
+Composes a number of clauses, such that 0 or more of the clauses can be run.
+
+.. image:: resources/anyCompositionChart.png
+
+Short description:
+
+- Checks if zero or more clauses that compose AnyComposition have associated commands in a command set.
+- After success runs verification logic specific for every *matched* (in this case *Cl2, Cl4, Cl5*) clause from composition.
+
+**Usage**
+
+Example from ``CommercialPaper.kt``:
+
+.. container:: codeset
+
+ .. sourcecode:: kotlin
+
+ class Group : GroupClauseVerifier>(
+ AnyComposition(
+ Redeem(),
+ Move(),
+ Issue())) {
+ override fun groupStates(tx: TransactionForContract): List>>
+ = tx.groupStates> { it.token }
+ }
+
+FirstComposition
+~~~~~~~~~~~~~~~~
+
+**Description**
+
+Composes a number of clauses, such that the first match is run, and it errors if none is run.
+
+.. image:: resources/firstCompositionChart.png
+
+Short description:
+
+- Takes first clause that matches and if none found throws an exception.
+- If successful runs verification on the clause that matched (in this case *Cl4*).
+
+**Usage**
+
+See code in `GroupClauseVerifier`_.
+
+
+Other types of clauses
+----------------------
+
+There are certain types of clauses that are specialized in particular types of contracts (like ``AbstractIssue``) or generally
+should be used as helpers in building parts of logic (the most important one is ``GroupClauseVerifier``).
+
+GroupClauseVerifier
+~~~~~~~~~~~~~~~~~~~
+
+**Description**
+
+Groups input and output states according to ``groupStates`` function. Runs the top-level clause verification on each
+group in turn.
+
+.. image:: resources/groupClauseVerifyChart.png
+
+Short description:
+
+``GroupClauseVerifier`` wraps clause *Cl1*. After grouping relevant states together with ``groupStates`` into three groups
+*Gr1, Gr2, Gr3* runs *Cl1.verify(Gr1), Cl1.verify(Gr2), Cl1.verify(Gr3)*.
+
+For more detailed example head to :ref:`state_ref`.
+
+**Usage**
+
+You need to extend ``GroupClauseVerifier`` clause and define ``groupStates`` function which takes transaction and returns
+grouped input and output states with a grouping key used for each group. Example from ``Obligation.kt`` contract:
+
+.. container:: codeset
+
+ .. sourcecode:: kotlin
+
+ class Group
(),
+ Issue(),
+ ConserveAmount()
+ )
+ )
+ )
+ )
+ ) {
+ override fun groupStates(tx: TransactionForContract): List, Issued>>>
+ = tx.groupStates, Issued>> { it.amount.token }
+ }
+
+Usually it's convenient to use ``groupStates`` function defined on ``TransactionForContract`` class. Which given a type and a
+selector function, that returns a grouping key, associates inputs and outputs together so that they can be processed as one.
+The grouping key is any arbitrary object that can act as a map key (so must implement equals and hashCode).
+
+AbstractConserveAmount
+~~~~~~~~~~~~~~~~~~~~~~
+
+**Description**
+
+Standardised clause for checking input/output balances of fungible assets. Requires that a
+Move command is provided, and errors if absent. Conserve amount clause can only be used on grouped states.
+
+**Usage**
+
+.. container:: codeset
+
+ .. sourcecode:: kotlin
+
+ /**
+ * Generic move/exit clause for fungible assets
+ */
+ class ConserveAmount
: AbstractConserveAmount, Commands, Terms
>()
+
+See code in `GroupClauseVerifier`_.
+
+AbstractIssue
+~~~~~~~~~~~~~
+
+**Description**
+
+Standard issue clause for contracts that issue fungible assets.
+
+**Usage**
+
+Example from ``CommercialPaper.kt``:
+
+.. container:: codeset
+
+ .. sourcecode:: kotlin
+
+ class Issue : AbstractIssue(
+ { map { Amount(it.faceValue.quantity, it.token) }.sumOrThrow() },
+ { token -> map { Amount(it.faceValue.quantity, it.token) }.sumOrZero(token) }) {
+ override val requiredCommands: Set> = setOf(Commands.Issue::class.java)
+
+ override fun verify(tx: TransactionForContract,
+ inputs: List,
+ outputs: List,
+ commands: List>,
+ groupingKey: Issued?): Set {
+ val consumedCommands = super.verify(tx, inputs, outputs, commands, groupingKey)
+ ...
+
+First function in constructor converts a list of states into an amount of the token. Must error if there are no states in the list.
+Second function converts a list of states into an amount of the token, and returns zero if there are no states in the list.
+Takes in an instance of the token definition for constructing the zero amount if needed.
+
+NoZeroSizedOutputs
+~~~~~~~~~~~~~~~~~~
+
+**Description**
+
+Clause for fungible asset contracts, which enforces that no output state should have a balance of zero.
+
+**Usage**
+
+See code in `GroupClauseVerifier`_.
+
+FilterOn
+~~~~~~~~
+
+**Description**
+
+Filter the states that are passed through to the wrapped clause, to restrict them to a specific type.
+
+``FilterOn`` narrows the scope of the states being verified.
+Let's take a transaction with multiple cash states of different currencies, we want to run a clause that focuses
+on only GBP cash states rather than all cash states.
+
+**Usage**
+
+.. container:: codeset
+
+ .. sourcecode:: kotlin
+
+ FilterOn(clause, { states -> states.filter { it.amount.token == GBP} })
+
+
+Takes ``filterStates`` function that limits states passed to ``clause`` verification.
diff --git a/docs/build/html/_sources/corda-configuration-file.txt b/docs/build/html/_sources/corda-configuration-file.txt
index 77faacb2cc..4da238dfc5 100644
--- a/docs/build/html/_sources/corda-configuration-file.txt
+++ b/docs/build/html/_sources/corda-configuration-file.txt
@@ -78,7 +78,7 @@ Fields
.. note:: If HTTPS is enabled then the browser security checks will require that the accessing url host name is one of either the machine name, fully qualified machine name, or server IP address to line up with the Subject Alternative Names contained within the development certificates. This is addition to requiring the ``/config/dev/corda_dev_ca.cer`` root certificate be installed as a Trusted CA.
-:extraAdvertisedServiceIds: A list of ServiceType id strings to be advertised to the NetworkMapService and thus be available when other nodes query the NetworkMapCache for supporting nodes. This can also include plugin services loaded from .jar files in the plugins folder.
+:extraAdvertisedServiceIds: A list of ServiceType id strings to be advertised to the NetworkMapService and thus be available when other nodes query the NetworkMapCache for supporting nodes. This can also include plugin services loaded from .jar files in the plugins folder. Optionally, a custom advertised service name can be provided by appending it to the service type id: ``"corda.notary.validating|Notary A"``
:notaryNodeAddress: The host and port to which to bind the embedded Raft server. Required only when running a distributed notary service. A group of Corda nodes can run a distributed notary service by each running an embedded Raft server and joining them to the same cluster to replicate the committed state log. Note that the Raft cluster uses a separate transport layer for communication that does not integrate with ArtemisMQ messaging services.
diff --git a/docs/build/html/_sources/corda-configuration-files.txt b/docs/build/html/_sources/corda-configuration-files.txt
deleted file mode 100644
index e7e9d441fb..0000000000
--- a/docs/build/html/_sources/corda-configuration-files.txt
+++ /dev/null
@@ -1,115 +0,0 @@
-The Corda Configuration File
-============================
-
-Configuration File Location
----------------------------
-
-The Corda all-in-one ``corda.jar`` file is generated by the ``gradle buildCordaJAR`` task and defaults to reading configuration from a ``node.conf`` file in the present working directory.
-This behaviour can be overidden using the ``--config-file`` command line option to target configuration files with different names, or different file location (relative paths are relative to the current working directory).
-Also, the ``--base-directory`` command line option alters the Corda node workspace location and if specified a ``node.conf`` configuration file is then expected in the root of the workspace.
-
-The configuration file templates used for the ``gradle deployNodes`` task are to be found in the ``/config/dev`` folder. Also note that there is a basic set of defaults loaded from
-the built in resource file ``/node/src/main/resources/reference.conf`` of the ``:node`` gradle module. All properties in this can be overidden in the file configuration
-and for rarely changed properties this defaulting allows the property to be excluded from the configuration file.
-
-Configuration File Format
--------------------------
-
-Corda uses the Typesafe configuration library to parse the configuration see the `typesafe config on Github `_ the format of the configuration files can be simple JSON, but for the more powerful substitution features
-uses HOCON format see `HOCON documents `_
-
-Configuration File Examples
----------------------------
-
-General node configuration file for hosting the IRSDemo services.
-
-.. code-block:: text
-
- basedir : "./nodea"
- myLegalName : "Bank A"
- nearestCity : "London"
- keyStorePassword : "cordacadevpass"
- trustStorePassword : "trustpass"
- dataSourceProperties : {
- dataSourceClassName : org.h2.jdbcx.JdbcDataSource
- "dataSource.url" : "jdbc:h2:"${basedir}"/persistence"
- "dataSource.user" : sa
- "dataSource.password" : ""
- }
- artemisAddress : "localhost:31337"
- webAddress : "localhost:31339"
- extraAdvertisedServiceIds: "corda.interest_rates"
- networkMapAddress : "localhost:12345"
- useHTTPS : false
- rpcUsers : [
- { user=user1, password=letmein, permissions=[ cash ] }
- ]
-
-NetworkMapService plus Simple Notary configuration file.
-
-.. code-block:: text
-
- basedir : "./nameserver"
- myLegalName : "Notary Service"
- nearestCity : "London"
- keyStorePassword : "cordacadevpass"
- trustStorePassword : "trustpass"
- artemisAddress : "localhost:12345"
- webAddress : "localhost:12346"
- extraAdvertisedServiceIds: ""
- useHTTPS : false
-
-Configuration File Fields
--------------------------
-
-:basedir: This specifies the node workspace folder either as an absolute path, or relative to the current working directory. It can be overidden by the ``--base-directory`` command line option, in which case the the value in the file is ignored and a ``node.conf`` file is expected in that workspace directory as the configuration source.
-
-:myLegalName: The legal identity of the node acts as a human readable alias to the node's public key and several demos use this to lookup the NodeInfo.
-
-:nearestCity: The location of the node as used to locate coordinates on the world map when running the network simulator demo. See :doc:`network-simulator`.
-
-:keyStorePassword:
- The password to unlock the KeyStore file (``/certificates/sslkeystore.jks``) containing the node certificate and private key.
-
- note:: This is the non-secret value for the development certificates automatically generated during the first node run. Longer term these keys will be managed in secure hardware devices.
-
-:trustStorePassword:
- The password to unlock the Trust store file (``/certificates/truststore.jks``) containing the R3 Corda root certificate. This is the non-secret value for the development certificates automatically generated during the first node run.
-
- .. note:: Longer term these keys will be managed in secure hardware devices.
-
-:dataSourceProperties:
- This section is used to configure the jdbc connection and database driver used for the nodes persistence. Currently the defaults in ``/node/src/main/resources/reference.conf`` are as shown in the first example. This is currently the only configuration that has been tested, although in the future full support for other storage layers will be validated.
-
-:artemisAddress:
- The host and port on which the node is available for protocol operations over ArtemisMQ.
-
- .. note:: In practice the ArtemisMQ messaging services bind to all local addresses on the specified port. However, note that the host is the included as the advertised entry in the NetworkMapService. As a result the value listed here must be externally accessible when running nodes across a cluster of machines.
-
-:messagingServerAddress:
- The address of the ArtemisMQ broker instance. If not provided the node will run one locally.
-
-:webAddress:
- The host and port on which the node is available for web operations.
-
- .. note:: If HTTPS is enabled then the browser security checks will require that the accessing url host name is one of either the machine name, fully qualified machine name, or server IP address to line up with the Subject Alternative Names contained within the development certificates. This is addition to requiring the ``/config/dev/corda_dev_ca.cer`` root certificate be installed as a Trusted CA.
-
-:extraAdvertisedServiceIds: A list of ServiceType id strings to be advertised to the NetworkMapService and thus be available when other nodes query the NetworkMapCache for supporting nodes. This can also include plugin services loaded from .jar files in the plugins folder.
-
-:notaryNodeAddress: The host and port to which to bind the embedded Raft server. Required only when running a distributed notary service. A group of Corda nodes can run a distributed notary service by each running an embedded Raft server and joining them to the same cluster to replicate the committed state log. Note that the Raft cluster uses a separate transport layer for communication that does not integrate with ArtemisMQ messaging services.
-
-:notaryClusterAddresses: List of Raft cluster member addresses used to joining the cluster. At least one of the specified members must be active and be able to communicate with the cluster leader for joining. If empty, a new cluster will be bootstrapped. Required only when running a distributed notary service.
-
-:networkMapAddress: If `null`, or missing the node is declaring itself as the NetworkMapService host. Otherwise the configuration value is the remote HostAndPort string for the ArtemisMQ service on the hosting node.
-
-:useHTTPS: If false the node's web server will be plain HTTP. If true the node will use the same certificate and private key from the ``/certificates/sslkeystore.jks`` file as the ArtemisMQ port for HTTPS. If HTTPS is enabled then unencrypted HTTP traffic to the node's **webAddress** port is not supported.
-
-:rpcUsers:
- A list of users who are authorised to access the RPC system. Each user in the list is a config object with the
- following fields:
-
- :user: Username consisting only of word characters (a-z, A-Z, 0-9 and _)
- :password: The password
- :permissions: A list of permission strings which RPC methods can use to control access
-
- If this field is absent or an empty list then RPC is effectively locked down.
diff --git a/docs/build/html/_sources/corda-plugins.txt b/docs/build/html/_sources/corda-plugins.txt
index 92e200f63c..6bff41d4aa 100644
--- a/docs/build/html/_sources/corda-plugins.txt
+++ b/docs/build/html/_sources/corda-plugins.txt
@@ -65,8 +65,14 @@ extensions to be created, or registered at startup. In particular:
d. The ``servicePlugins`` property returns a list of classes which will
be instantiated once during the ``AbstractNode.start`` call. These
classes must provide a single argument constructor which will receive a
- ``PluginServiceHub`` reference. These singleton instances are regarded
- as trusted components and can be used for a number of purposes.
+ ``PluginServiceHub`` reference. They must also extend the abstract class
+ ``SingletonSerializeAsToken`` which ensures that if any reference to your
+ service is captured in a flow checkpoint (i.e. serialized by Kryo as
+ part of Quasar checkpoints, either on the stack or by reference within
+ your flows) it is stored as a simple token representing your service.
+ When checkpoints are restored, after a node restart for example,
+ the latest instance of the service will be substituted back in place of
+ the token stored in the checkpoint.
i. Firstly, they can call ``PluginServiceHub.registerFlowInitiator`` and
register flows that will be initiated locally in response to remote flow
@@ -79,7 +85,7 @@ extensions to be created, or registered at startup. In particular:
to the service plugin when initiated (as defined by the
``registerFlowInitiator`` call). The flow can then call into functions
on the plugin service singleton. Note, care should be taken to not allow
- flows to hold references to plugin services, or fields which are not
+ flows to hold references to fields which are not
also ``SingletonSerializeAsToken``, otherwise Quasar suspension in the
``StateMachineManager`` will fail with exceptions. An example oracle can
be seen in ``NodeInterestRates.kt`` in the irs-demo sample.
diff --git a/docs/build/html/_sources/creating-a-cordapp.txt b/docs/build/html/_sources/creating-a-cordapp.txt
index 9f2d279382..742e3bc988 100644
--- a/docs/build/html/_sources/creating-a-cordapp.txt
+++ b/docs/build/html/_sources/creating-a-cordapp.txt
@@ -1,5 +1,5 @@
-Creating a CorDapp
-==================
+CorDapps Background
+===================
A Cordapp is an application that runs on the Corda platform using the platform APIs and plugin system. They are self
contained in separate JARs from the node server JAR that are created and distributed.
@@ -21,7 +21,7 @@ specific details of the implementation, but you can extend the server in the fol
Services
--------
-Services are classes which are constructed after the node has started. It is provided a `ServiceHubInternal`_ which
+Services are classes which are constructed after the node has started. It is provided a `PluginServiceHub`_ which
allows a richer API than the `ServiceHub`_ exposed to contracts. It enables adding flows, registering
message handlers and more. The service does not run in a separate thread, so the only entry point to the service is during
construction, where message handlers should be registered and threads started.
@@ -93,8 +93,8 @@ The name and column layout of the internal node tables is in a state of flux and
at the present time, and should certainly be treated as read-only.
.. _CordaPluginRegistry: api/net.corda.core.node/-corda-plugin-registry/index.html
-.. _ServiceHubInternal: api/net.corda.node.services.api/-service-hub-internal/index.html
-.. _ServiceHub: api/net.corda.node.services.api/-service-hub/index.html
+.. _PluginServiceHub: api/net.corda.core.node/-plugin-service-hub/index.html
+.. _ServiceHub: api/net.corda.core.node/-service-hub/index.html
Building against Corda
----------------------
diff --git a/docs/build/html/_sources/getting-set-up-fault-finding.txt b/docs/build/html/_sources/getting-set-up-fault-finding.txt
index e6cfebadc5..cfe2e0c954 100644
--- a/docs/build/html/_sources/getting-set-up-fault-finding.txt
+++ b/docs/build/html/_sources/getting-set-up-fault-finding.txt
@@ -1,9 +1,20 @@
-Getting Set Up : Faultfinding
-=============================
+Getting set up: troubleshooting
+===============================
IntelliJ issues
---------------
+Run configurations are missing
+******************************
+
+If you opened the Corda project using "Import" from the IntelliJ splash screen rather than using "Open" and then
+importing the Gradle build system from the popup bubble, then a bug in IntelliJ will cause it to wipe and recreate
+the ``.idea`` directory where the run configurations are stored. The fix is simple and doesn't require you to
+re-import the project: just undelete the files! You can do that by either:
+
+1. Running ``git checkout .idea/runConfigurations`` to restore that part of the tree to its normal state.
+2. Using the "Version Control" pane in IntelliJ to undelete the files via the GUI.
+
If IntelliJ complains about lack of an SDK
******************************************
diff --git a/docs/build/html/_sources/getting-set-up.txt b/docs/build/html/_sources/getting-set-up.txt
index 2faa6f160e..d4cd8cb4de 100644
--- a/docs/build/html/_sources/getting-set-up.txt
+++ b/docs/build/html/_sources/getting-set-up.txt
@@ -20,6 +20,12 @@ We strongly recommend the use of IntelliJ's Development Environment known as IDE
`JetBrains `_. The primary reason we recommend this particular IDE is that it integrates
very well with our choice of language for Corda, "Kotlin", as Jetbrains also support the development of Kotlin.
+.. warning:: When opening the Corda project for the first time from the IntelliJ splash screen, please use "Open"
+ and then agree to import the Gradle project from the popup bubble. Don't pick "Import" on the splash screen,
+ because a bug in IntelliJ will cause the pre-packaged run configurations to be erased. If you see this warning
+ too late, it's no problem, just use ``git checkout .idea/runConfiguration`` or the version control tab in IntelliJ
+ to undelete the files.
+
Kotlin
------
diff --git a/docs/build/html/_sources/index.txt b/docs/build/html/_sources/index.txt
index 4469b53b4d..b985bc4727 100644
--- a/docs/build/html/_sources/index.txt
+++ b/docs/build/html/_sources/index.txt
@@ -1,8 +1,5 @@
-Welcome to the Corda!
-=====================
-
-.. warning:: This build of the docs is from the *master branch*, not a milestone release. It may not reflect the
- current state of the code.
+Welcome to the Corda documentation!
+===================================
This is the developer guide for Corda, a proposed architecture for distributed ledgers. Here are the sources
of documentation you may find useful, from highest level to lowest:
@@ -29,7 +26,9 @@ Read on to learn:
inthebox
getting-set-up
+ getting-set-up-fault-finding
running-the-demos
+ CLI-vs-IDE
.. toctree::
:maxdepth: 2
@@ -39,6 +38,14 @@ Read on to learn:
transaction-data-types
merkle-trees
consensus
+ clauses
+
+.. toctree::
+ :maxdepth: 2
+ :caption: CorDapps
+
+ creating-a-cordapp
+ tutorial-cordapp
.. toctree::
:maxdepth: 2
@@ -54,21 +61,16 @@ Read on to learn:
node-explorer
permissioning
-.. toctree::
- :maxdepth: 2
- :caption: CorDapps
-
- creating-a-cordapp
-
.. toctree::
:maxdepth: 2
:caption: Tutorials
- where-to-start
tutorial-contract
tutorial-contract-clauses
tutorial-test-dsl
+ tutorial-integration-testing
tutorial-clientrpc-api
+ tutorial-building-transactions
flow-state-machines
flow-testing
running-a-notary
@@ -96,6 +98,7 @@ Read on to learn:
:caption: Appendix
loadtesting
+ setting-up-a-corda-network
secure-coding-guidelines
release-process
release-notes
diff --git a/docs/build/html/_sources/initialmarginagreement.txt b/docs/build/html/_sources/initialmarginagreement.txt
deleted file mode 100644
index 06504b85d2..0000000000
--- a/docs/build/html/_sources/initialmarginagreement.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-Initial Margin Agreements
-=========================
-
-This app is a demonstration of how Corda can be used for the real world requirement of initial margin calculation and
-agreement; featuring the integration of complex and industry proven third party libraries into Corda nodes.
-
-SIMM Introduction
------------------
-
-SIMM is an acronym for "Standard Initial Margin Model". It is effectively the calculation of a "margin" that is paid
-by one party to another when they agree a trade on certain types of transaction. This margin is
-paid such that, in the event of one of the counterparties suffering a credit event
-(a financial term and a polite way to say defaulting, not paying the debts that are due, or potentially even bankruptcy),
-then the party that is owed any sum already has some of the amount that it should have been paid. This payment to the
-receiving party is a preventative measure in order to reduce the risk of a potentially catastrophic default domino
-effect that caused the `Great Financial Crisis `_,
-as it means that they can be assured that if they need to pay another party, they will have a proportion of the funds
-that they have been relying on.
-
-To enact this, in September 2016, the ISDA committee - with full backing from various governing bodies -
-`issued a ruling on what is known as the ISDA SIMM ™ model `_,
-a way of fairly and consistently calculating this margin. Any parties wishing to trade a financial product that is
-covered under this ruling would, independently, use this model and calculate their margin payment requirement,
-agree it with their trading counterparty and then pay (or receive, depending on the results of this calculation)
-this amount. In the case of disagreement that is not resolved in a timely fashion, this payment would increase
-and so therefore it is in the parties interest to reach agreement in a short as time frame as possible.
-
-To be more accurate, the SIMM calculation is not performed on just one trade - it is calculated on an aggregate of
-intermediary values (which in this model are sensitivities to risk factors) from a portfolio of trades; therefore
-the input to a SIMM is actually this data, not the individual trades itself.
-
-Also note that implementations of the SIMM are actually protected and subject to license restrictions by ISDA
-(this is due to the model itself being protected). We were fortunate enough to technically partner with
-`OpenGamma `_ who allowed us to demonstrate the SIMM process using their proprietary model.
-In the source code released, we have replaced their analytics engine with very simple stub functions that allow
-the process to run and can easily be swapped out in place for their real libraries.
-
-Process steps
--------------
-
-Preliminaries
- - Ensure that there are a number of live trades with another party financial products that are covered under the
- ISDA SIMM agreement (if none, then use the demo to enter some simple trades as described below).
-
-Initial Margin Agreement Process
- - Agree that one will be performing the margining calculation against a portfolio of trades with another party, and agree the trades in that portfolio. In practice, one node will start the protocol but it does not matter which node does.
- - Individually (at the node level), identify the data (static, reference etc) one will need in order to be able to calculate the metrics on those trades
- - Confirm with the other counterparty the dataset from the above set
- - Calculate any intermediary steps and values needed for the margin calculation (ie sensitivities to risk factors)
- - Agree on the results of these steps
- - Calculate the initial margin
- - Agree on the calculation of the above with the other party
- - In practice, pay (or receive) this margin (omitted for the sake of complexity for this example)
-
-
-Running the app
----------------
-
-The demonstration can be run in two ways - via IntelliJ (which will allow you to add breakpoints, debug, etc), or via gradle and the command line.
-
-Run with IntelliJ::
-
- 1. Open the `cordapp-samples` project with IntelliJ
- 2. Run the shared run configuration "SIMM Valuation Demo"
- 3. Browse to http://localhost:10005/web/simmvaluationdemo
-
-Run via CLI::
-
- 1. Navigate to the `cordapp-samples` directory in your shell
- 2. Run the gradle target `deployNodes` (ie; ./gradlew deployNodes for Unix or gradlew.bat on Windows)
- 1. Unix: `cd simm-valuation-demo/build/nodes && ./runnodes`.
- 2. Windows: `cd simm-valuation-demo/build/nodes & runnodes.bat`
- 4. Browse to http://localhost:10005/web/simmvaluationdemo
diff --git a/docs/build/html/_sources/oracles.txt b/docs/build/html/_sources/oracles.txt
index 06f5843818..80fe2a1643 100644
--- a/docs/build/html/_sources/oracles.txt
+++ b/docs/build/html/_sources/oracles.txt
@@ -75,8 +75,6 @@ Here's a quick way to decide which approach makes more sense for your data sourc
Asserting continuously varying data
-----------------------------------
-.. note:: A future version of the platform will include a complete tutorial on implementing this type of oracle.
-
Let's look at the interest rates oracle that can be found in the ``NodeInterestRates`` file. This is an example of
an oracle that uses a command because the current interest rate fix is a constantly changing fact.
@@ -93,15 +91,15 @@ So the way we actually implement it is like this:
1. The creator of the transaction that depends on the interest rate asks for the current rate. They can abort at this point
if they want to.
2. They insert a command with that rate and the time it was obtained into the transaction.
-3. They then send it to the oracle for signing, along with everyone else in parallel. The oracle checks that the command
- has correct data for the asserted time, and signs if so.
+3. They then send it to the oracle for signing, along with everyone else, potentially in parallel. The oracle checks that
+ the command has the correct data for the asserted time, and signs if so.
This same technique can be adapted to other types of oracle.
The oracle consists of a core class that implements the query/sign operations (for easy unit testing), and then a separate
class that binds it to the network layer.
-Here is an extract from the ``NodeService.Oracle`` class and supporting types:
+Here is an extract from the ``NodeInterestRates.Oracle`` class and supporting types:
.. sourcecode:: kotlin
@@ -112,13 +110,31 @@ Here is an extract from the ``NodeService.Oracle`` class and supporting types:
data class Fix(val of: FixOf, val value: BigDecimal) : CommandData
class Oracle {
- fun query(queries: List): List
+ fun query(queries: List, deadline: Instant): List
- fun sign(wtx: WireTransaction): DigitalSignature.LegallyIdentifiable
+ fun sign(ftx: FilteredTransaction, merkleRoot: SecureHash): DigitalSignature.LegallyIdentifiable
}
-Because the fix contains a timestamp (the ``forDay`` field), there can be an arbitrary delay between a fix being
-requested via ``query`` and the signature being requested via ``sign``.
+Because the fix contains a timestamp (the ``forDay`` field), that identifies the version of the data being requested,
+there can be an arbitrary delay between a fix being requested via ``query`` and the signature being requested via ``sign``
+as the Oracle can know which, potentially historical, value it is being asked to sign for. This is an important
+technique for continously varying data.
+
+The ``query`` method takes a deadline, which is a point in time the requester is willing to wait until for the necessary
+data to be available. Not every oracle will need this. This can be useful where data is expected to be available on a
+particular schedule and we use scheduling functionality to automatically launch the processing associated with it.
+We can schedule for the expected announcement (or publish) time and give a suitable deadline at which the lack of the
+information being available and the delay to processing becomes significant and may need to be escalated.
+
+Hiding transaction data from the oracle
+---------------------------------------
+
+Because the transaction is sent to the oracle for signing, ordinarily the oracle would be able to see the entire contents
+of that transaction including the inputs, output contract states and all the commands, not just the one (in this case)
+relevant command. This is an obvious privacy leak for the other participants. We currently solve this with
+``FilteredTransaction``-s and the use of Merkle Trees. These reveal only the necessary parts of the transaction to the
+oracle but still allow it to sign it by providing the Merkle hashes for the remaining parts. See :doc:`merkle-trees` for
+more details.
Pay-per-play oracles
--------------------
@@ -132,3 +148,124 @@ contract could in theory include a transaction parsing and signature checking li
would be conclusive evidence of intent to disobey the rules of the service (*res ipsa loquitur*). In an environment
where parties are legally identifiable, usage of such a contract would by itself be sufficient to trigger some sort of
punishment.
+
+Implementing an oracle with continuously varying data
+=====================================================
+
+Implement the core classes
+--------------------------
+
+The key is to implement your oracle in a similar way to the ``NodeInterestRates.Oracle`` outline we gave above with
+both ``query`` and ``sign`` methods. Typically you would want one class that encapsulates the parameters to the ``query``
+method (``FixOf`` above), and a ``CommandData`` implementation (``Fix`` above) that encapsulates both an instance of
+that parameter class and an instance of whatever the result of the ``query`` is (``BigDecimal`` above).
+
+The ``NodeInterestRates.Oracle`` allows querying for multiple ``Fix``-es but that is not necessary and is
+provided for the convenience of callers who might need multiple and can do it all in one query request. Likewise
+the *deadline* functionality is optional and can be avoided initially.
+
+Let's see what parameters we pass to the constructor of this oracle.
+
+.. sourcecode:: kotlin
+
+ class Oracle(val identity: Party, private val signingKey: KeyPair, val clock: Clock) = TODO()
+
+Here we see the oracle needs to have its own identity, so it can check which transaction commands it is expected to
+sign for, and also needs a pair of signing keys with which it signs transactions. The clock is used for the deadline
+functionality which we will not discuss further here.
+
+Assuming you have a data source and can query it, it should be very easy to implement your ``query`` method and the
+parameter and ``CommandData`` classes.
+
+Let's see how the ``sign`` method for ``NodeInterestRates.Oracle`` is written:
+
+.. literalinclude:: ../../samples/irs-demo/src/main/kotlin/net/corda/irs/api/NodeInterestRates.kt
+ :language: kotlin
+ :start-after: DOCSTART 1
+ :end-before: DOCEND 1
+
+Here we can see that there are several steps:
+
+1. Ensure that the transaction we have been sent is indeed valid and passes verification, even though we cannot see all
+ of it.
+2. Check that we only received commands as expected, and each of those commands expects us to sign for them and is of
+ the expected type (``Fix`` here).
+3. Iterate over each of the commands we identified in the last step and check that the data they represent matches
+ exactly our data source. The final step, assuming we have got this far, is to generate a signature for the
+ transaction and return it.
+
+Binding to the network via CorDapp plugin
+-----------------------------------------
+
+.. note:: Before reading any further, we advise that you understand the concept of flows and how to write them and use
+ them. See :doc:`flow-state-machines`. Likewise some understanding of Cordapps, plugins and services will be helpful.
+ See :doc:`creating-a-cordapp`.
+
+The first step is to create a service to host the oracle on the network. Let's see how that's implemented:
+
+.. literalinclude:: ../../samples/irs-demo/src/main/kotlin/net/corda/irs/api/NodeInterestRates.kt
+ :language: kotlin
+ :start-after: DOCSTART 2
+ :end-before: DOCEND 2
+
+This may look complicated, but really it's made up of some relatively simple elements (in the order they appear in the code):
+
+1. Accept a ``PluginServiceHub`` in the constructor. This is your interface to the Corda node.
+2. Ensure you extend the abstract class ``SingletonSerializeAsToken`` (see :doc:`corda-plugins`).
+3. Create an instance of your core oracle class that has the ``query`` and ``sign`` methods as discussed above.
+4. Register your client sub-flows (in this case both in ``RatesFixFlow``. See the next section) for querying and
+ signing as initiating your service flows that actually do the querying and signing using your core oracle class instance.
+5. Implement your service flows that call your core oracle class instance.
+
+The final step is to register your service with the node via the plugin mechanism. Do this by
+implementing a plugin. Don't forget the resources file to register it with the ``ServiceLoader`` framework
+(see :doc:`corda-plugins`).
+
+.. sourcecode:: kotlin
+
+ class Plugin : CordaPluginRegistry() {
+ override val servicePlugins: List> = listOf(Service::class.java)
+ }
+
+Providing client sub-flows for querying and signing
+---------------------------------------------------
+
+We mentioned the client sub-flow briefly above. They are the mechanism that clients, in the form of other flows, will
+interact with your oracle. Typically there will be one for querying and one for signing. Let's take a look at
+those for ``NodeInterestRates.Oracle``.
+
+.. literalinclude:: ../../samples/irs-demo/src/main/kotlin/net/corda/irs/flows/RatesFixFlow.kt
+ :language: kotlin
+ :start-after: DOCSTART 1
+ :end-before: DOCEND 1
+
+You'll note that the ``FixSignFlow`` requires a ``FilterFuns`` instance with the appropriate filter to include only
+the ``Fix`` commands. You can find a further explanation of this in :doc:`merkle-trees`.
+
+Using an oracle
+===============
+
+The oracle is invoked through sub-flows to query for values, add them to the transaction as commands and then get
+the transaction signed by the the oracle. Following on from the above examples, this is all encapsulated in a sub-flow
+called ``RatesFixFlow``. Here's the ``call`` method of that flow.
+
+.. literalinclude:: ../../samples/irs-demo/src/main/kotlin/net/corda/irs/flows/RatesFixFlow.kt
+ :language: kotlin
+ :start-after: DOCSTART 2
+ :end-before: DOCEND 2
+
+As you can see, this:
+
+1. Queries the oracle for the fact using the client sub-flow for querying from above.
+2. Does some quick validation.
+3. Adds the command to the transaction containing the fact to be signed for by the oracle.
+4. Calls an extension point that allows clients to generate output states based on the fact from the oracle.
+5. Requests the signature from the oracle using the client sub-flow for signing from above.
+6. Adds the signature returned from the oracle.
+
+Here's an example of it in action from ``FixingFlow.Fixer``.
+
+.. literalinclude:: ../../samples/irs-demo/src/main/kotlin/net/corda/irs/flows/FixingFlow.kt
+ :language: kotlin
+ :start-after: DOCSTART 1
+ :end-before: DOCEND 1
\ No newline at end of file
diff --git a/docs/build/html/_sources/protocol-state-machines.txt b/docs/build/html/_sources/protocol-state-machines.txt
deleted file mode 100644
index e06b039fbf..0000000000
--- a/docs/build/html/_sources/protocol-state-machines.txt
+++ /dev/null
@@ -1,694 +0,0 @@
-.. highlight:: kotlin
-.. raw:: html
-
-
-
-
-Protocol state machines
-=======================
-
-This article explains our experimental approach to modelling financial protocols in code. It explains how the
-platform's state machine framework is used, and takes you through the code for a simple 2-party asset trading protocol
-which is included in the source.
-
-Introduction
-------------
-
-Shared distributed ledgers are interesting because they allow many different, mutually distrusting parties to
-share a single source of truth about the ownership of assets. Digitally signed transactions are used to update that
-shared ledger, and transactions may alter many states simultaneously and atomically.
-
-Blockchain systems such as Bitcoin support the idea of building up a finished, signed transaction by passing around
-partially signed invalid transactions outside of the main network, and by doing this you can implement
-*delivery versus payment* such that there is no chance of settlement failure, because the movement of cash and the
-traded asset are performed atomically by the same transaction. To perform such a trade involves a multi-step protocol
-in which messages are passed back and forth privately between parties, checked, signed and so on.
-
-Despite how useful these protocols are, platforms such as Bitcoin and Ethereum do not assist the developer with the rather
-tricky task of actually building them. That is unfortunate. There are many awkward problems in their implementation
-that a good platform would take care of for you, problems like:
-
-* Avoiding "callback hell" in which code that should ideally be sequential is turned into an unreadable mess due to the
- desire to avoid using up a thread for every protocol instantiation.
-* Surviving node shutdowns/restarts that may occur in the middle of the protocol without complicating things. This
- implies that the state of the protocol must be persisted to disk.
-* Error handling.
-* Message routing.
-* Serialisation.
-* Catching type errors, in which the developer gets temporarily confused and expects to receive/send one type of message
- when actually they need to receive/send another.
-* Unit testing of the finished protocol.
-
-Actor frameworks can solve some of the above but they are often tightly bound to a particular messaging layer, and
-we would like to keep a clean separation. Additionally, they are typically not type safe, and don't make persistence or
-writing sequential code much easier.
-
-To put these problems in perspective, the *payment channel protocol* in the bitcoinj library, which allows bitcoins to
-be temporarily moved off-chain and traded at high speed between two parties in private, consists of about 7000 lines of
-Java and took over a month of full time work to develop. Most of that code is concerned with the details of persistence,
-message passing, lifecycle management, error handling and callback management. Because the business logic is quite
-spread out the code can be difficult to read and debug.
-
-As small contract-specific trading protocols are a common occurence in finance, we provide a framework for the
-construction of them that automatically handles many of the concerns outlined above.
-
-Theory
-------
-
-A *continuation* is a suspended stack frame stored in a regular object that can be passed around, serialised,
-unserialised and resumed from where it was suspended. This concept is sometimes referred to as "fibers". This may
-sound abstract but don't worry, the examples below will make it clearer. The JVM does not natively support
-continuations, so we implement them using a library called Quasar which works through behind-the-scenes
-bytecode rewriting. You don't have to know how this works to benefit from it, however.
-
-We use continuations for the following reasons:
-
-* It allows us to write code that is free of callbacks, that looks like ordinary sequential code.
-* A suspended continuation takes far less memory than a suspended thread. It can be as low as a few hundred bytes.
- In contrast a suspended Java thread stack can easily be 1mb in size.
-* It frees the developer from thinking (much) about persistence and serialisation.
-
-A *state machine* is a piece of code that moves through various *states*. These are not the same as states in the data
-model (that represent facts about the world on the ledger), but rather indicate different stages in the progression
-of a multi-stage protocol. Typically writing a state machine would require the use of a big switch statement and some
-explicit variables to keep track of where you're up to. The use of continuations avoids this hassle.
-
-A two party trading protocol
-----------------------------
-
-We would like to implement the "hello world" of shared transaction building protocols: a seller wishes to sell some
-*asset* (e.g. some commercial paper) in return for *cash*. The buyer wishes to purchase the asset using his cash. They
-want the trade to be atomic so neither side is exposed to the risk of settlement failure. We assume that the buyer
-and seller have found each other and arranged the details on some exchange, or over the counter. The details of how
-the trade is arranged isn't covered in this article.
-
-Our protocol has two parties (B and S for buyer and seller) and will proceed as follows:
-
-1. S sends a ``StateAndRef`` pointing to the state they want to sell to B, along with info about the price they require
- B to pay.
-2. B sends to S a ``SignedTransaction`` that includes the state as input, B's cash as input, the state with the new
- owner key as output, and any change cash as output. It contains a single signature from B but isn't valid because
- it lacks a signature from S authorising movement of the asset.
-3. S signs it and hands the now finalised ``SignedTransaction`` back to B.
-
-You can find the implementation of this protocol in the file ``finance/src/main/kotlin/net.corda.protocols/TwoPartyTradeProtocol.kt``.
-
-Assuming no malicious termination, they both end the protocol being in posession of a valid, signed transaction that
-represents an atomic asset swap.
-
-Note that it's the *seller* who initiates contact with the buyer, not vice-versa as you might imagine.
-
-We start by defining a wrapper that namespaces the protocol code, two functions to start either the buy or sell side
-of the protocol, and two classes that will contain the protocol definition. We also pick what data will be used by
-each side.
-
-.. note:: The code samples in this tutorial are only available in Kotlin, but you can use any JVM language to
- write them and the approach is the same.
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- object TwoPartyTradeProtocol {
-
- class UnacceptablePriceException(val givenPrice: Amount) : Exception("Unacceptable price: $givenPrice")
- class AssetMismatchException(val expectedTypeName: String, val typeName: String) : Exception() {
- override fun toString() = "The submitted asset didn't match the expected type: $expectedTypeName vs $typeName"
- }
-
- // This object is serialised to the network and is the first protocol message the seller sends to the buyer.
- data class SellerTradeInfo(
- val assetForSale: StateAndRef,
- val price: Amount,
- val sellerOwnerKey: PublicKey
- )
-
- data class SignaturesFromSeller(val sellerSig: DigitalSignature.WithKey,
- val notarySig: DigitalSignature.LegallyIdentifiable)
-
- open class Seller(val otherSide: Party,
- val notaryNode: NodeInfo,
- val assetToSell: StateAndRef,
- val price: Amount,
- val myKeyPair: KeyPair,
- override val progressTracker: ProgressTracker = Seller.tracker()) : ProtocolLogic() {
- @Suspendable
- override fun call(): SignedTransaction {
- TODO()
- }
- }
-
- open class Buyer(val otherSide: Party,
- val notary: Party,
- val acceptablePrice: Amount,
- val typeToBuy: Class) : ProtocolLogic() {
- @Suspendable
- override fun call(): SignedTransaction {
- TODO()
- }
- }
- }
-
-This code defines several classes nested inside the main ``TwoPartyTradeProtocol`` singleton. Some of the classes are
-simply protocol messages or exceptions. The other two represent the buyer and seller side of the protocol.
-
-Going through the data needed to become a seller, we have:
-
-- ``otherSide: Party`` - the party with which you are trading.
-- ``notaryNode: NodeInfo`` - the entry in the network map for the chosen notary. See ":doc:`consensus`" for more
- information on notaries.
-- ``assetToSell: StateAndRef`` - a pointer to the ledger entry that represents the thing being sold.
-- ``price: Amount`` - the agreed on price that the asset is being sold for (without an issuer constraint).
-- ``myKeyPair: KeyPair`` - the key pair that controls the asset being sold. It will be used to sign the transaction.
-
-And for the buyer:
-
-- ``acceptablePrice: Amount`` - the price that was agreed upon out of band. If the seller specifies
- a price less than or equal to this, then the trade will go ahead.
-- ``typeToBuy: Class`` - the type of state that is being purchased. This is used to check that the
- sell side of the protocol isn't trying to sell us the wrong thing, whether by accident or on purpose.
-
-Alright, so using this protocol shouldn't be too hard: in the simplest case we can just create a Buyer or Seller
-with the details of the trade, depending on who we are. We then have to start the protocol in some way. Just
-calling the ``call`` function ourselves won't work: instead we need to ask the framework to start the protocol for
-us. More on that in a moment.
-
-Suspendable functions
----------------------
-
-The ``call`` function of the buyer/seller classes is marked with the ``@Suspendable`` annotation. What does this mean?
-
-As mentioned above, our protocol framework will at points suspend the code and serialise it to disk. For this to work,
-any methods on the call stack must have been pre-marked as ``@Suspendable`` so the bytecode rewriter knows to modify
-the underlying code to support this new feature. A protocol is suspended when calling either ``receive``, ``send`` or
-``sendAndReceive`` which we will learn more about below. For now, just be aware that when one of these methods is
-invoked, all methods on the stack must have been marked. If you forget, then in the unit test environment you will
-get a useful error message telling you which methods you didn't mark. The fix is simple enough: just add the annotation
-and try again.
-
-.. note:: Java 9 is likely to remove this pre-marking requirement completely.
-
-Starting your protocol
-----------------------
-
-The ``StateMachineManager`` is the class responsible for taking care of all running protocols in a node. It knows
-how to register handlers with the messaging system (see ":doc:`messaging`") and iterate the right state machine
-when messages arrive. It provides the send/receive/sendAndReceive calls that let the code request network
-interaction and it will save/restore serialised versions of the fiber at the right times.
-
-Protocols can be invoked in several ways. For instance, they can be triggered by scheduled events,
-see ":doc:`event-scheduling`" to learn more about this. Or they can be triggered via the HTTP API. Or they can
-be triggered directly via the Java-level node APIs from your app code.
-
-You request a protocol to be invoked by using the ``ServiceHub.invokeProtocolAsync`` method. This takes a
-Java reflection ``Class`` object that describes the protocol class to use (in this case, either ``Buyer`` or ``Seller``).
-It also takes a set of arguments to pass to the constructor. Because it's possible for protocol invocations to
-be requested by untrusted code (e.g. a state that you have been sent), the types that can be passed into the
-protocol are checked against a whitelist, which can be extended by apps themselves at load time.
-
-The process of starting a protocol returns a ``ListenableFuture`` that you can use to either block waiting for
-the result, or register a callback that will be invoked when the result is ready.
-
-In a two party protocol only one side is to be manually started using ``ServiceHub.invokeProtocolAsync``. The other side
-has to be registered by its node to respond to the initiating protocol via ``ServiceHubInternal.registerProtocolInitiator``.
-In our example it doesn't matter which protocol is the initiator and which is the initiated. For example, if we are to
-take the seller as the initiator then we would register the buyer as such:
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- val services: ServiceHubInternal = TODO()
-
- services.registerProtocolInitiator(Seller::class) { otherParty ->
- val notary = services.networkMapCache.notaryNodes[0]
- val acceptablePrice = TODO()
- val typeToBuy = TODO()
- Buyer(otherParty, notary, acceptablePrice, typeToBuy)
- }
-
-This is telling the buyer node to fire up an instance of ``Buyer`` (the code in the lambda) when the initiating protocol
-is a seller (``Seller::class``).
-
-Implementing the seller
------------------------
-
-Let's implement the ``Seller.call`` method. This will be run when the protocol is invoked.
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- @Suspendable
- override fun call(): SignedTransaction {
- val partialTX: SignedTransaction = receiveAndCheckProposedTransaction()
- val ourSignature: DigitalSignature.WithKey = computeOurSignature(partialTX)
- val allPartySignedTx = partialTX + ourSignature
- val notarySignature = getNotarySignature(allPartySignedTx)
- val result: SignedTransaction = sendSignatures(allPartySignedTx, ourSignature, notarySignature)
- return result
- }
-
-Here we see the outline of the procedure. We receive a proposed trade transaction from the buyer and check that it's
-valid. The buyer has already attached their signature before sending it. Then we calculate and attach our own signature so that the transaction is
-now signed by both the buyer and the seller. We then send this request to a notary to assert with another signature that the
-timestamp in the transaction (if any) is valid and there are no double spends, and send back both
-our signature and the notaries signature. Note we should not send to the notary until all other required signatures have been appended
-as the notary may validate the signatures as well as verifying for itself the transactional integrity.
-Finally, we hand back to the code that invoked the protocol the finished transaction.
-
-Let's fill out the ``receiveAndCheckProposedTransaction()`` method.
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- @Suspendable
- private fun receiveAndCheckProposedTransaction(): SignedTransaction {
- // Make the first message we'll send to kick off the protocol.
- val hello = SellerTradeInfo(assetToSell, price, myKeyPair.public)
-
- val maybeSTX = sendAndReceive(otherSide, hello)
-
- maybeSTX.unwrap {
- // Check that the tx proposed by the buyer is valid.
- val missingSigs: Set = it.verifySignatures(throwIfSignaturesAreMissing = false)
- val expected = setOf(myKeyPair.public, notaryNode.identity.owningKey)
- if (missingSigs != expected)
- throw SignatureException("The set of missing signatures is not as expected: ${missingSigs.toStringsShort()} vs ${expected.toStringsShort()}")
-
- val wtx: WireTransaction = it.tx
- logger.trace { "Received partially signed transaction: ${it.id}" }
-
- // Download and check all the things that this transaction depends on and verify it is contract-valid,
- // even though it is missing signatures.
- subProtocol(ResolveTransactionsProtocol(wtx, otherSide))
-
- if (wtx.outputs.map { it.data }.sumCashBy(myKeyPair.public).withoutIssuer() != price)
- throw IllegalArgumentException("Transaction is not sending us the right amount of cash")
-
- return it
- }
- }
-
-Let's break this down. We fill out the initial protocol message with the trade info, and then call ``sendAndReceive``.
-This function takes a few arguments:
-
-- The party on the other side.
-- The thing to send. It'll be serialised and sent automatically.
-- Finally a type argument, which is the kind of object we're expecting to receive from the other side. If we get
- back something else an exception is thrown.
-
-Once ``sendAndReceive`` is called, the call method will be suspended into a continuation and saved to persistent
-storage. If the node crashes or is restarted, the protocol will effectively continue as if nothing had happened. Your
-code may remain blocked inside such a call for seconds, minutes, hours or even days in the case of a protocol that
-needs human interaction!
-
-.. note:: There are a couple of rules you need to bear in mind when writing a class that will be used as a continuation.
- The first is that anything on the stack when the function is suspended will be stored into the heap and kept alive by
- the garbage collector. So try to avoid keeping enormous data structures alive unless you really have to.
-
- The second is that as well as being kept on the heap, objects reachable from the stack will be serialised. The state
- of the function call may be resurrected much later! Kryo doesn't require objects be marked as serialisable, but even so,
- doing things like creating threads from inside these calls would be a bad idea. They should only contain business
- logic and only do I/O via the methods exposed by the protocol framework.
-
- It's OK to keep references around to many large internal node services though: these will be serialised using a
- special token that's recognised by the platform, and wired up to the right instance when the continuation is
- loaded off disk again.
-
-The buyer is supposed to send us a transaction with all the right inputs/outputs/commands in response to the opening
-message, with their cash put into the transaction and their signature on it authorising the movement of the cash.
-
-You get back a simple wrapper class, ``UntrustworthyData``, which is just a marker class that reminds
-us that the data came from a potentially malicious external source and may have been tampered with or be unexpected in
-other ways. It doesn't add any functionality, but acts as a reminder to "scrub" the data before use.
-
-Our "scrubbing" has three parts:
-
-1. Check that the expected signatures are present and correct. At this point we expect our own signature to be missing,
- because of course we didn't sign it yet, and also the signature of the notary because that must always come last.
-2. We resolve the transaction, which we will cover below.
-3. We verify that the transaction is paying us the demanded price.
-
-Subprotocols
-------------
-
-Protocols can be composed via nesting. Invoking a sub-protocol looks similar to an ordinary function call:
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- @Suspendable
- private fun getNotarySignature(stx: SignedTransaction): DigitalSignature.LegallyIdentifiable {
- progressTracker.currentStep = NOTARY
- return subProtocol(NotaryProtocol.Client(stx))
- }
-
-In this code snippet we are using the ``NotaryProtocol.Client`` to request notarisation of the transaction.
-We simply create the protocol object via its constructor, and then pass it to the ``subProtocol`` method which
-returns the result of the protocol's execution directly. Behind the scenes all this is doing is wiring up progress
-tracking (discussed more below) and then running the objects ``call`` method. Because this little helper method can
-be on the stack when network IO takes place, we mark it as ``@Suspendable``.
-
-Going back to the previous code snippet, we use a subprotocol called ``ResolveTransactionsProtocol``. This is
-responsible for downloading and checking all the dependencies of a transaction, which in Corda are always retrievable
-from the party that sent you a transaction that uses them. This protocol returns a list of ``LedgerTransaction``
-objects, but we don't need them here so we just ignore the return value.
-
-.. note:: Transaction dependency resolution assumes that the peer you got the transaction from has all of the
- dependencies itself. It must do, otherwise it could not have convinced itself that the dependencies were themselves
- valid. It's important to realise that requesting only the transactions we require is a privacy leak, because if
- we don't download a transaction from the peer, they know we must have already seen it before. Fixing this privacy
- leak will come later.
-
-After the dependencies, we check the proposed trading transaction for validity by running the contracts for that as
-well (but having handled the fact that some signatures are missing ourselves).
-
-Here's the rest of the code:
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- open fun computeOurSignature(partialTX: SignedTransaction) = myKeyPair.signWithECDSA(partialTX.txBits)
-
- @Suspendable
- private fun sendSignatures(allPartySignedTX: SignedTransaction, ourSignature: DigitalSignature.WithKey,
- notarySignature: DigitalSignature.LegallyIdentifiable): SignedTransaction {
- val fullySigned = allPartySignedTX + notarySignature
- logger.trace { "Built finished transaction, sending back to secondary!" }
- send(otherSide, SignaturesFromSeller(ourSignature, notarySignature))
- return fullySigned
- }
-
-It's all pretty straightforward from now on. Here ``txBits`` is the raw byte array representing the serialised
-transaction, and we just use our private key to calculate a signature over it. As a reminder, in Corda signatures do
-not cover other signatures: just the core of the transaction data.
-
-In ``sendSignatures``, we take the two signatures we obtained and add them to the partial transaction we were sent.
-There is an overload for the + operator so signatures can be added to a SignedTransaction easily. Finally, we wrap the
-two signatures in a simple wrapper message class and send it back. The send won't block waiting for an acknowledgement,
-but the underlying message queue software will retry delivery if the other side has gone away temporarily.
-
-You can also see that every protocol instance has a logger (using the SLF4J API) which you can use to log progress
-messages.
-
-.. warning:: This sample code is **not secure**. Other than not checking for all possible invalid constructions, if the
- seller stops before sending the finalised transaction to the buyer, the seller is left with a valid transaction
- but the buyer isn't, so they can't spend the asset they just purchased! This sort of thing will be fixed in a
- future version of the code.
-
-Implementing the buyer
-----------------------
-
-OK, let's do the same for the buyer side:
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- @Suspendable
- override fun call(): SignedTransaction {
- val tradeRequest = receiveAndValidateTradeRequest()
- val (ptx, cashSigningPubKeys) = assembleSharedTX(tradeRequest)
- val stx = signWithOurKeys(cashSigningPubKeys, ptx)
-
- val signatures = swapSignaturesWithSeller(stx)
-
- logger.trace { "Got signatures from seller, verifying ... " }
-
- val fullySigned = stx + signatures.sellerSig + signatures.notarySig
- fullySigned.verifySignatures()
-
- logger.trace { "Signatures received are valid. Trade complete! :-)" }
- return fullySigned
- }
-
- @Suspendable
- private fun receiveAndValidateTradeRequest(): SellerTradeInfo {
- // Wait for a trade request to come in from the other side
- val maybeTradeRequest = receive(otherParty)
- maybeTradeRequest.unwrap {
- // What is the seller trying to sell us?
- val asset = it.assetForSale.state.data
- val assetTypeName = asset.javaClass.name
- logger.trace { "Got trade request for a $assetTypeName: ${it.assetForSale}" }
-
- if (it.price > acceptablePrice)
- throw UnacceptablePriceException(it.price)
- if (!typeToBuy.isInstance(asset))
- throw AssetMismatchException(typeToBuy.name, assetTypeName)
-
- // Check the transaction that contains the state which is being resolved.
- // We only have a hash here, so if we don't know it already, we have to ask for it.
- subProtocol(ResolveTransactionsProtocol(setOf(it.assetForSale.ref.txhash), otherSide))
-
- return it
- }
- }
-
- @Suspendable
- private fun swapSignaturesWithSeller(stx: SignedTransaction): SignaturesFromSeller {
- progressTracker.currentStep = SWAPPING_SIGNATURES
- logger.trace { "Sending partially signed transaction to seller" }
-
- // TODO: Protect against the seller terminating here and leaving us in the lurch without the final tx.
-
- return sendAndReceive(otherSide, stx).unwrap { it }
- }
-
- private fun signWithOurKeys(cashSigningPubKeys: List, ptx: TransactionBuilder): SignedTransaction {
- // Now sign the transaction with whatever keys we need to move the cash.
- for (k in cashSigningPubKeys) {
- val priv = serviceHub.keyManagementService.toPrivate(k)
- ptx.signWith(KeyPair(k, priv))
- }
-
- return ptx.toSignedTransaction(checkSufficientSignatures = false)
- }
-
- private fun assembleSharedTX(tradeRequest: SellerTradeInfo): Pair> {
- val ptx = TransactionType.General.Builder(notary)
- // Add input and output states for the movement of cash, by using the Cash contract to generate the states.
- val wallet = serviceHub.walletService.currentWallet
- val cashStates = wallet.statesOfType()
- val cashSigningPubKeys = Cash().generateSpend(ptx, tradeRequest.price, tradeRequest.sellerOwnerKey, cashStates)
- // Add inputs/outputs/a command for the movement of the asset.
- ptx.addInputState(tradeRequest.assetForSale)
- // Just pick some new public key for now. This won't be linked with our identity in any way, which is what
- // we want for privacy reasons: the key is here ONLY to manage and control ownership, it is not intended to
- // reveal who the owner actually is. The key management service is expected to derive a unique key from some
- // initial seed in order to provide privacy protection.
- val freshKey = serviceHub.keyManagementService.freshKey()
- val (command, state) = tradeRequest.assetForSale.state.data.withNewOwner(freshKey.public)
- ptx.addOutputState(state, tradeRequest.assetForSale.state.notary)
- ptx.addCommand(command, tradeRequest.assetForSale.state.data.owner)
-
- // And add a request for timestamping: it may be that none of the contracts need this! But it can't hurt
- // to have one.
- val currentTime = serviceHub.clock.instant()
- ptx.setTime(currentTime, 30.seconds)
- return Pair(ptx, cashSigningPubKeys)
- }
-
-This code is longer but no more complicated. Here are some things to pay attention to:
-
-1. We do some sanity checking on the received message to ensure we're being offered what we expected to be offered.
-2. We create a cash spend in the normal way, by using ``Cash().generateSpend``. See the contracts tutorial if this
- part isn't clear.
-3. We access the *service hub* when we need it to access things that are transient and may change or be recreated
- whilst a protocol is suspended, things like the wallet or the network map.
-4. Finally, we send the unfinished, invalid transaction to the seller so they can sign it. They are expected to send
- back to us a ``SignaturesFromSeller``, which once we verify it, should be the final outcome of the trade.
-
-As you can see, the protocol logic is straightforward and does not contain any callbacks or network glue code, despite
-the fact that it takes minimal resources and can survive node restarts.
-
-.. warning:: In the current version of the platform, exceptions thrown during protocol execution are not propagated
- back to the sender. A thorough error handling and exceptions framework will be in a future version of the platform.
-
-Progress tracking
------------------
-
-Not shown in the code snippets above is the usage of the ``ProgressTracker`` API. Progress tracking exports information
-from a protocol about where it's got up to in such a way that observers can render it in a useful manner to humans who
-may need to be informed. It may be rendered via an API, in a GUI, onto a terminal window, etc.
-
-A ``ProgressTracker`` is constructed with a series of ``Step`` objects, where each step is an object representing a
-stage in a piece of work. It is therefore typical to use singletons that subclass ``Step``, which may be defined easily
-in one line when using Kotlin. Typical steps might be "Waiting for response from peer", "Waiting for signature to be
-approved", "Downloading and verifying data" etc.
-
-Each step exposes a label. By default labels are fixed, but by subclassing ``RelabelableStep``
-you can make a step that can update its label on the fly. That's useful for steps that want to expose non-structured
-progress information like the current file being downloaded. By defining your own step types, you can export progress
-in a way that's both human readable and machine readable.
-
-Progress trackers are hierarchical. Each step can be the parent for another tracker. By altering the
-``ProgressTracker.childrenFor[step] = tracker`` map, a tree of steps can be created. It's allowed to alter the hierarchy
-at runtime, on the fly, and the progress renderers will adapt to that properly. This can be helpful when you don't
-fully know ahead of time what steps will be required. If you _do_ know what is required, configuring as much of the
-hierarchy ahead of time is a good idea, as that will help the users see what is coming up.
-
-Every tracker has not only the steps given to it at construction time, but also the singleton
-``ProgressTracker.UNSTARTED`` step and the ``ProgressTracker.DONE`` step. Once a tracker has become ``DONE`` its
-position may not be modified again (because e.g. the UI may have been removed/cleaned up), but until that point, the
-position can be set to any arbitrary set both forwards and backwards. Steps may be skipped, repeated, etc. Note that
-rolling the current step backwards will delete any progress trackers that are children of the steps being reversed, on
-the assumption that those subtasks will have to be repeated.
-
-Trackers provide an `Rx observable `_ which streams changes to the hierarchy. The top level
-observable exposes all the events generated by its children as well. The changes are represented by objects indicating
-whether the change is one of position (i.e. progress), structure (i.e. new subtasks being added/removed) or some other
-aspect of rendering (i.e. a step has changed in some way and is requesting a re-render).
-
-The protocol framework is somewhat integrated with this API. Each ``ProtocolLogic`` may optionally provide a tracker by
-overriding the ``protocolTracker`` property (``getProtocolTracker`` method in Java). If the
-``ProtocolLogic.subProtocol`` method is used, then the tracker of the sub-protocol will be made a child of the current
-step in the parent protocol automatically, if the parent is using tracking in the first place. The framework will also
-automatically set the current step to ``DONE`` for you, when the protocol is finished.
-
-Because a protocol may sometimes wish to configure the children in its progress hierarchy _before_ the sub-protocol
-is constructed, for sub-protocols that always follow the same outline regardless of their parameters it's conventional
-to define a companion object/static method (for Kotlin/Java respectively) that constructs a tracker, and then allow
-the sub-protocol to have the tracker it will use be passed in as a parameter. This allows all trackers to be built
-and linked ahead of time.
-
-In future, the progress tracking framework will become a vital part of how exceptions, errors, and other faults are
-surfaced to human operators for investigation and resolution.
-
-Unit testing
-------------
-
-A protocol can be a fairly complex thing that interacts with many services and other parties over the network. That
-means unit testing one requires some infrastructure to provide lightweight mock implementations. The MockNetwork
-provides this testing infrastructure layer; you can find this class in the node module
-
-A good example to examine for learning how to unit test protocols is the ``ResolveTransactionsProtocol`` tests. This
-protocol takes care of downloading and verifying transaction graphs, with all the needed dependencies. We start
-with this basic skeleton:
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- class ResolveTransactionsProtocolTest {
- lateinit var net: MockNetwork
- lateinit var a: MockNetwork.MockNode
- lateinit var b: MockNetwork.MockNode
- lateinit var notary: Party
-
- @Before
- fun setup() {
- net = MockNetwork()
- val nodes = net.createSomeNodes()
- a = nodes.partyNodes[0]
- b = nodes.partyNodes[1]
- notary = nodes.notaryNode.info.identity
- net.runNetwork()
- }
-
- @After
- fun tearDown() {
- net.stopNodes()
- }
- }
-
-We create a mock network in our ``@Before`` setup method and create a couple of nodes. We also record the identity
-of the notary in our test network, which will come in handy later. We also tidy up when we're done.
-
-Next, we write a test case:
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- @Test
- fun resolveFromTwoHashes() {
- val (stx1, stx2) = makeTransactions()
- val p = ResolveTransactionsProtocol(setOf(stx2.id), a.info.identity)
- val future = b.services.startProtocol("resolve", p)
- net.runNetwork()
- val results = future.get()
- assertEquals(listOf(stx1.id, stx2.id), results.map { it.id })
- assertEquals(stx1, b.storage.validatedTransactions.getTransaction(stx1.id))
- assertEquals(stx2, b.storage.validatedTransactions.getTransaction(stx2.id))
- }
-
-We'll take a look at the ``makeTransactions`` function in a moment. For now, it's enough to know that it returns two
-``SignedTransaction`` objects, the second of which spends the first. Both transactions are known by node A
-but not node B.
-
-The test logic is simple enough: we create the protocol, giving it node A's identity as the target to talk to.
-Then we start it on node B and use the ``net.runNetwork()`` method to bounce messages around until things have
-settled (i.e. there are no more messages waiting to be delivered). All this is done using an in memory message
-routing implementation that is fast to initialise and use. Finally, we obtain the result of the protocol and do
-some tests on it. We also check the contents of node B's database to see that the protocol had the intended effect
-on the node's persistent state.
-
-Here's what ``makeTransactions`` looks like:
-
-.. container:: codeset
-
- .. sourcecode:: kotlin
-
- private fun makeTransactions(): Pair {
- // Make a chain of custody of dummy states and insert into node A.
- val dummy1: SignedTransaction = DummyContract.generateInitial(MEGA_CORP.ref(1), 0, notary).let {
- it.signWith(MEGA_CORP_KEY)
- it.signWith(DUMMY_NOTARY_KEY)
- it.toSignedTransaction(false)
- }
- val dummy2: SignedTransaction = DummyContract.move(dummy1.tx.outRef(0), MINI_CORP_PUBKEY).let {
- it.signWith(MEGA_CORP_KEY)
- it.signWith(DUMMY_NOTARY_KEY)
- it.toSignedTransaction()
- }
- a.services.recordTransactions(dummy1, dummy2)
- return Pair(dummy1, dummy2)
- }
-
-We're using the ``DummyContract``, a simple test smart contract which stores a single number in its states, along
-with ownership and issuer information. You can issue such states, exit them and re-assign ownership (move them).
-It doesn't do anything else. This code simply creates a transaction that issues a dummy state (the issuer is
-``MEGA_CORP``, a pre-defined unit test identity), signs it with the test notary and MegaCorp keys and then
-converts the builder to the final ``SignedTransaction``. It then does so again, but this time instead of issuing
-it re-assigns ownership instead. The chain of two transactions is finally committed to node A by sending them
-directly to the ``a.services.recordTransaction`` method (note that this method doesn't check the transactions are
-valid).
-
-And that's it: you can explore the documentation for the `MockNode API `_ here.
-
-Versioning
-----------
-
-Fibers involve persisting object-serialised stack frames to disk. Although we may do some R&D into in-place upgrades
-in future, for now the upgrade process for protocols is simple: you duplicate the code and rename it so it has a
-new set of class names. Old versions of the protocol can then drain out of the system whilst new versions are
-initiated. When enough time has passed that no old versions are still waiting for anything to happen, the previous
-copy of the code can be deleted.
-
-Whilst kind of ugly, this is a very simple approach that should suffice for now.
-
-.. warning:: Protocols are not meant to live for months or years, and by implication they are not meant to implement entire deal
- lifecycles. For instance, implementing the entire life cycle of an interest rate swap as a single protocol - whilst
- technically possible - would not be a good idea. The platform provides a job scheduler tool that can invoke
- protocols for this reason (see ":doc:`event-scheduling`")
-
-Future features
----------------
-
-The protocol framework is a key part of the platform and will be extended in major ways in future. Here are some of
-the features we have planned:
-
-* Identity based addressing
-* Exposing progress trackers to local (inside the firewall) clients using message queues and/or WebSockets
-* Exception propagation and management, with a "protocol hospital" tool to manually provide solutions to unavoidable
- problems (e.g. the other side doesn't know the trade)
-* Being able to interact with internal apps and tools via HTTP and similar
-* Being able to interact with people, either via some sort of external ticketing system, or email, or a custom UI.
- For example to implement human transaction authorisations.
-* A standard library of protocols that can be easily sub-classed by local developers in order to integrate internal
- reporting logic, or anything else that might be required as part of a communications lifecycle.
diff --git a/docs/build/html/_sources/release-notes.txt b/docs/build/html/_sources/release-notes.txt
index 77a8fd17a0..a7e5e5e5ba 100644
--- a/docs/build/html/_sources/release-notes.txt
+++ b/docs/build/html/_sources/release-notes.txt
@@ -3,6 +3,78 @@ Release notes
Here are brief summaries of what's changed between each snapshot release.
+Milestone 6
+-----------
+
+* Added the `Corda technical white paper <_static/corda-technical-whitepaper.pdf>`_. Note that its current version
+ is 0.5 to reflect the fact that the Corda design is still evolving. Although we expect only relatively small tweaks
+ at this point, when Corda reaches 1.0 so will the white paper.
+
+* Major documentation restructuring and new content:
+
+ * More details on Corda node internals.
+ * New CorDapp tutorial.
+ * New tutorial on building transactions.
+ * New tutorials on how to run and use a notary service.
+
+* An experimental version of the deterministic JVM sandbox has been added. It is not integrated with the node and will
+ undergo some significant changes in the coming releases before it is integrated, as the code is finished, as bugs are
+ found and fixed, and as the platform subset we choose to expose is finalised. Treat this as an outline of the basic
+ approach rather than something usable for production.
+
+* Developer experience:
+
+ * Samples have been merged back into the main repository. All samples can now be run via command line or IntelliJ.
+
+ * Added a Client RPC python example.
+
+ * Node console output now displays concise startup information, such as startup time or web address. All logging to
+ the console is suppressed apart from errors and flow progress tracker steps. It can be re-enabled by passing
+ ``--log-to-console`` command line parameter. Note that the log file remains unchanged an will still contain all
+ log entries.
+
+ * The ``runnodes`` scripts generated by the Gradle plugins now open each node in separate terminal windows or (on macOS) tabs.
+
+ * A much more complete template app.
+
+ * JARs now available on Maven Central.
+
+* Data model: A party is now identified by a composite key (formerly known as a "public key tree") instead of a single public key.
+ Read more in :ref:`composite-keys`. This allows expressing distributed service identities, e.g. a distributed notary.
+ In the future this will also allow parties to use multiple signing keys for their legal identity.
+
+* Decentralised consensus: A prototype RAFT based notary composed of multiple nodes has been added. This implementation
+ is optimised for high performance over robustness against malicious cluster members, which may be appropriate for
+ some financial situations. See :ref:`notary-demo` to try it out. A BFT notary will be added later.
+
+* Node explorer app:
+
+ * New theme aligned with the Corda branding.
+ * The New Transaction screen moved to the Cash View (as it is used solely for cash transactions)
+ * Removed state machine/flow information from Transaction table. A new view for this will be created in a future release.
+ * Added a new Network View that displays details of all nodes on the network.
+ * Users can now configure the reporting currency in settings.
+ * Various layout and performance enhancements.
+
+* Client RPC:
+
+ * Added a generic ``startFlow`` method that enables starting of any flow, given sufficient permissions.
+ * Added the ability for plugins to register additional classes or custom serialisers with Kryo for use in RPC.
+ * ``rpc-users.properties`` file has been removed with RPC user settings moved to the config file.
+
+* Configuration changes: It is now possible to specify a custom legal name for any of the node's advertised services.
+
+* Added a load testing framework which allows stress testing of a node cluster, as well as specifying different ways of
+ disrupting the normal operation of nodes. See :doc:`loadtesting`.
+
+* Improvements to the experimental contract DSL, by Sofus Mortensen of Nordea Bank (please give Nordea a shoutout too).
+
+API changes:
+
+* The top level package has been renamed from ``com.r3corda`` to ``net.corda``.
+* Protocols have been renamed to "flows".
+* ``OpaqueBytes`` now uses ``bytes`` as the field name rather than ``bits``.
+
Milestone 5
-----------
diff --git a/docs/build/html/_sources/running-the-demos.txt b/docs/build/html/_sources/running-the-demos.txt
index fe1fb1bdf7..a1a3939591 100644
--- a/docs/build/html/_sources/running-the-demos.txt
+++ b/docs/build/html/_sources/running-the-demos.txt
@@ -16,15 +16,21 @@ so far. We have:
.. note:: If any demos don't work please jump on our mailing list and let us know.
+
+Important : Common Instructions for all demos
+---------------------------------------------
+
The demos can be run either from the command line, or from inside IntelliJ. Running from the command line is
recommended if you are just wanting to see them run, using IntelliJ can be helpful if you want to debug or
-develop the demos themselves.
+develop the demos themselves. For more details about running via the command line or within IntelliJ - see :doc:`CLI-vs-IDE`.
+
+*For all demos:* The ``install`` gradle task is automatically ran if required; this no longer needs to be run independently.
Trader demo
-----------
This demo brings up three nodes: Bank A, Bank B and a notary/network map node that they both use. Bank A will
-be the buyer, and self-issues some cash in order to acquire the commercial paper from Bank B, the seller.
+be the buyer, and self-issues some cash in order to acquire commercial paper from Bank B, the seller.
To run from the command line:
@@ -54,7 +60,7 @@ on a simulated clock passes.
To run from the command line:
-1. Run ``./gradlew samples:irs-demo:deployNodes samples:irs-demo:installDist`` to install configs and a command line tool under ``samples/irs-demo/build``.
+1. Run ``./gradlew samples:irs-demo:deployNodes`` to install configs and a command line tool under ``samples/irs-demo/build``.
2. Change to the ``samples/irs-demo/build`` directory.
3. Run ``./nodes/runnodes`` (or ``runnodes.bat`` on Windows) to open up three new terminals with the three nodes.
4. Run ``./install/irs-demo/bin/irs-demo --role UploadRates`` (or use ``irs-demo.bat`` on Windows). You should see a
@@ -104,19 +110,6 @@ Or you can run them from inside IntelliJ, but when done this way, all the node o
In the "Attachment Demo: Run Nodes" window you should see some log lines scroll past, and within a few seconds the
message "File received - we're happy!" should be printed.
-SIMM and Portfolio demo
------------------------
-
-.. note:: Read more about this demo at :doc:`initial-margin-agreement`.
-
-To run the demo run:
-
-1. Open the Corda project in IntelliJ and run the "Install" configuration
-2. Open the Corda samples project in IntelliJ and run the "Simm Valuation Demo" configuration
-
-Now open http://localhost:10005/web/simmvaluationdemo and http://localhost:10007/web/simmvaluationdemo to view the two nodes that this
-will have started respectively. You can now use the demo by creating trades and agreeing the valuations.
-
.. _notary-demo:
Distributed Notary demo
@@ -161,4 +154,96 @@ by using the H2 web console:
You can use the string on the right to connect to the h2 database: just paste it in to the `JDBC URL` field and click *Connect*.
You will be presented with a web application that enumerates all the available tables and provides an interface for you to query them using SQL.
- The committed states are stored in the ``NOTARY_COMMITTED_STATES`` table. Note that the raw data is not human-readable,
- but we're only interested in the row count for this demo.
\ No newline at end of file
+ but we're only interested in the row count for this demo.
+
+SIMM and Portfolio Demo - aka the Initial Margin Agreement Demo
+---------------------------------------------------------------
+
+Background and SIMM Introduction
+********************************
+
+This app is a demonstration of how Corda can be used for the real world requirement of initial margin calculation and
+agreement; featuring the integration of complex and industry proven third party libraries into Corda nodes.
+
+SIMM is an acronym for "Standard Initial Margin Model". It is effectively the calculation of a "margin" that is paid
+by one party to another when they agree a trade on certain types of transaction. This margin is
+paid such that, in the event of one of the counterparties suffering a credit event
+(a financial term and a polite way to say defaulting, not paying the debts that are due, or potentially even bankruptcy),
+then the party that is owed any sum already has some of the amount that it should have been paid. This payment to the
+receiving party is a preventative measure in order to reduce the risk of a potentially catastrophic default domino
+effect that caused the `Great Financial Crisis `_,
+as it means that they can be assured that if they need to pay another party, they will have a proportion of the funds
+that they have been relying on.
+
+To enact this, in September 2016, the ISDA committee - with full backing from various governing bodies -
+`issued a ruling on what is known as the ISDA SIMM ™ model `_,
+a way of fairly and consistently calculating this margin. Any parties wishing to trade a financial product that is
+covered under this ruling would, independently, use this model and calculate their margin payment requirement,
+agree it with their trading counterparty and then pay (or receive, depending on the results of this calculation)
+this amount. In the case of disagreement that is not resolved in a timely fashion, this payment would increase
+and so therefore it is in the parties' interest to reach agreement in as short as time frame as possible.
+
+To be more accurate, the SIMM calculation is not performed on just one trade - it is calculated on an aggregate of
+intermediary values (which in this model are sensitivities to risk factors) from a portfolio of trades; therefore
+the input to a SIMM is actually this data, not the individual trades themselves.
+
+Also note that implementations of the SIMM are actually protected and subject to license restrictions by ISDA
+(this is due to the model itself being protected). We were fortunate enough to technically partner with
+`OpenGamma `_ who allowed us to demonstrate the SIMM process using their proprietary model.
+In the source code released, we have replaced their analytics engine with very simple stub functions that allow
+the process to run without actually calculating correct values, and can easily be swapped out in place for their real libraries.
+
+
+Open the Corda samples project in IntelliJ and run the "Simm Valuation Demo" configuration
+
+Now open http://localhost:10005/web/simmvaluationdemo and http://localhost:10007/web/simmvaluationdemo to view the two
+nodes that this will have started respectively. You can now use the demo by creating trades and agreeing the valuations.
+Also see the README located in samples/simm-valuation-demo.
+
+
+What happens in the demo (notionally)
+*************************************
+
+Preliminaries
+ - Ensure that there are a number of live trades with another party financial products that are covered under the
+ ISDA SIMM agreement (if none, then use the demo to enter some simple trades as described below).
+
+Initial Margin Agreement Process
+ - Agree that one will be performing the margining calculation against a portfolio of trades with another party, and agree the trades in that portfolio. In practice, one node will start the flow but it does not matter which node does.
+ - Individually (at the node level), identify the data (static, reference etc) one will need in order to be able to calculate the metrics on those trades
+ - Confirm with the other counterparty the dataset from the above set
+ - Calculate any intermediary steps and values needed for the margin calculation (ie sensitivities to risk factors)
+ - Agree on the results of these steps
+ - Calculate the initial margin
+ - Agree on the calculation of the above with the other party
+ - In practice, pay (or receive) this margin (omitted for the sake of complexity for this example)
+
+
+Demo execution (step by step)
+*****************************
+
+The demonstration can be run in two ways - via IntelliJ (which will allow you to add breakpoints, debug, etc), or via gradle and the command line.
+
+Run with IntelliJ
+
+ 1. Open the ``corda`` project with IntelliJ
+ 2. Run the shared run configuration "SIMM Valuation Demo"
+
+Run via CLI
+
+ 1. Navigate to the ``samples/simm-valuation-demo`` directory in your shell
+ 2. Run the gradle target ``deployNodes`` (ie; ``./gradlew deployNodes`` for Unix or ``gradlew.bat`` on Windows)
+
+ a. Unix: ``cd simm-valuation-demo/build/nodes && ./runnodes``
+ b. Windows: ``cd simm-valuation-demo/build/nodes & runnodes.bat``
+
+Then (for both)
+ 3. Browse to http://localhost:10005/web/simmvaluationdemo
+ 4. Select the other counterparty (ie Bank B)
+ 5. Enter at least 3 trades - via the "Create New Trade" tab.
+ 6. On the "Agree Valuations" tab, click the "Start Calculations" button.
+
+
+Additionally, you can confirm that these trades are not visible from `Bank C's node `_.
+
+Please note that any URL text after `simmvaluationdemo` should not be bookmarked or navigated directly to as they are only for aesthetics.
\ No newline at end of file
diff --git a/docs/build/html/_sources/transaction-data-types.txt b/docs/build/html/_sources/transaction-data-types.txt
index 7c855883d8..752071c8fe 100644
--- a/docs/build/html/_sources/transaction-data-types.txt
+++ b/docs/build/html/_sources/transaction-data-types.txt
@@ -145,6 +145,8 @@ that has been signed by a set of parties.
.. note:: These types are provisional and will change significantly in future as the identity framework becomes more
fleshed out.
+.. _composite-keys:
+
Multi-signature support
-----------------------
diff --git a/docs/build/html/_sources/tutorial-building-transactions.txt b/docs/build/html/_sources/tutorial-building-transactions.txt
new file mode 100644
index 0000000000..f157a3056d
--- /dev/null
+++ b/docs/build/html/_sources/tutorial-building-transactions.txt
@@ -0,0 +1,321 @@
+Building Transactions
+=====================
+
+Introduction
+------------
+
+Understanding and implementing transactions in Corda is key to building
+and implementing real world smart contracts. It is only through
+construction of valid Corda transactions containing appropriate data
+that nodes on the ledger can map real world business objects into a
+shared digital view of the data in the Corda ledger. More importantly as
+the developer of new smart contracts it is the code which determines
+what data is well formed and what data should be rejected as mistakes,
+or to prevent malicious activity. This document details some of the
+considerations and APIs used to when constructing transactions as part
+of a flow.
+
+The Basic Lifecycle Of Transactions
+-----------------------------------
+
+Transactions in Corda are constructed in stages and contain a number of
+elements. In particular a transaction’s core data structure is the
+``net.corda.core.transactions.WireTransaction``, which is usually
+manipulated via a
+``net.corda.core.contracts.General.TransactionBuilder`` and contains:
+
+1. A set of Input state references that will be consumed by the final
+accepted transaction.
+
+2. A set of Output states to create/replace the consumed states and thus
+become the new latest versions of data on the ledger.
+
+3. A set of ``Attachment`` items which can contain legal documents, contract
+code, or private encrypted sections as an extension beyond the native
+contract states.
+
+4. A set of ``Command`` items which give a context to the type of ledger
+transition that is encoded in the transaction. Also each command has an
+associated set of signer keys, which will be required to sign the
+transaction.
+
+5. A signers list, which is populated by the ``TransactionBuilder`` to
+be the union of the signers on the individual Command objects.
+
+6. A notary identity to specify the Notary node which is tracking the
+state consumption. (If the input states are registered with different
+notary nodes the flow will have to insert additional ``NotaryChange``
+transactions to migrate the states across to a consistent notary node,
+before being allowed to mutate any states.)
+
+7. Optionally a timestamp that can used in the Notary to time bound the
+period in which the proposed transaction stays valid.
+
+Typically, the ``WireTransaction`` should be regarded as a proposal and
+may need to be exchanged back and forth between parties before it can be
+fully populated. This is an immediate consequence of the Corda privacy
+model, which means that the input states are likely to be unknown to the
+other node.
+
+Once the proposed data is fully populated the flow code should freeze
+the ``WireTransaction`` and form a ``SignedTransaction``. This is key to
+the ledger agreement process, as once a flow has attached a node’s
+signature it has stated that all details of the transaction are
+acceptable to it. A flow should take care not to attach signatures to
+intermediate data, which might be maliciously used to construct a
+different ``SignedTransaction``. For instance in a foreign exchange
+scenario we shouldn't send a ``SignedTransaction`` with only our sell
+side populated as that could be used to take the money without the
+expected return of the other currency. Also, it is best practice for
+flows to receive back the ``DigitalSignature.WithKey`` of other parties
+rather than a full ``SignedTransaction`` objects, because otherwise we
+have to separately check that this is still the same
+``SignedTransaction`` and not a malicious substitute.
+
+The final stage of committing the transaction to the ledger is to
+notarise the ``SignedTransaction``, distribute this to all appropriate
+parties and record the data into the ledger. These actions are best
+delegated to the ``FinalityFlow``, rather than calling the inidividual
+steps manually. However, do note that the final broadcast to the other
+nodes is asynchronous, so care must be used in unit testing to
+correctly await the Vault updates.
+
+Gathering Inputs
+----------------
+
+One of the first steps to forming a transaction is gathering the set of
+input references. This process will clearly vary according to the nature
+of the business process being captured by the smart contract and the
+parameterised details of the request. However, it will generally involve
+searching the Vault via the ``VaultService`` interface on the
+``ServiceHub`` to locate the input states.
+
+To give a few more specific details consider two simplified real world
+scenarios. First, a basic foreign exchange Cash transaction. This
+transaction needs to locate a set of funds to exchange. A flow
+modelling this is implemented in ``FxTransactionBuildTutorial.kt``.
+Second, a simple business model in which parties manually accept, or
+reject each other's trade proposals which is implemented in
+``WorkflowTransactionBuildTutorial.kt``. To run and explore these
+examples using the IntelliJ IDE one can run/step the respective unit
+tests in ``FxTransactionBuildTutorialTest.kt`` and
+``WorkflowTransactionBuildTutorialTest.kt``, which drive the flows as
+part of a simulated in-memory network of nodes. When creating the
+IntelliJ run configuration for these unit test set the workspace
+points to the root ``r3prototyping`` folder and add
+``-javaagent:lib/quasar.jar`` to the VM options, so that the ``Quasar``
+instrumentation is correctly configured.
+
+For the Cash transaction let’s assume the cash resources are using the
+standard ``CashState`` in the ``:financial`` Gradle module. The Cash
+contract uses ``FungibleAsset`` states to model holdings of
+interchangeable assets and allow the split/merge and summing of
+states to meet a contractual obligation. We would normally use the
+``generateSpend`` method on the ``VaultService`` to gather the required
+amount of cash into a ``TransactionBuilder``, set the outputs and move
+command. However, to elucidate more clearly example flow code is shown
+here that will manually carry out the inputs queries using the lower
+level ``VaultService``.
+
+.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/FxTransactionBuildTutorial.kt
+ :language: kotlin
+ :start-after: DOCSTART 1
+ :end-before: DOCEND 1
+
+As a foreign exchange transaction we expect an exchange of two
+currencies, so we will also require a set of input states from the other
+counterparty. However, the Corda privacy model means we do not know the
+other node’s states. Our flow must therefore negotiate with the other
+node for them to carry out a similar query and populate the inputs (See
+the ``ForeignExchangeFlow`` for more details of the exchange). Having
+identified a set of Input ``StateRef`` items we can then create the
+output as discussed below.
+
+For the trade approval flow we need to implement a simple workflow
+pattern. We start by recording the unconfirmed trade details in a state
+object implementing the ``LinearState`` interface. One field of this
+record is used to map the business workflow to an enumerated state.
+Initially the initiator creates a new state object which receives a new
+``UniqueIdentifier`` in its ``linearId`` property and a starting
+workflow state of ``NEW``. The ``Contract.verify`` method is written to
+allow the initiator to sign this initial transaction and send it to the
+other party. This pattern ensures that a permanent copy is recorded on
+both ledgers for audit purposes, but the state is prevented from being
+maliciously put in an approved state. The subsequent workflow steps then
+follow with transactions that consume the state as inputs on one side
+and output a new version with whatever state updates, or amendments
+match to the business process, the ``linearId`` being preserved across
+the changes. Attached ``Command`` objects help the verify method
+restrict changes to appropriate fields and signers at each step in the
+workflow. In this it is typical to have both parties sign the change
+transactions, but it can be valid to allow unilateral signing, if for instance
+one side could block a rejection. Commonly the manual initiator of these
+workflows will query the Vault for states of the right contract type and
+in the right workflow state over the RPC interface. The RPC will then
+initiate the relevant flow using ``StateRef``, or ``linearId`` values as
+parameters to the flow to identify the states being operated upon. Thus
+code to gather the latest input state would be:
+
+.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/WorkflowTransactionBuildTutorial.kt
+ :language: kotlin
+ :start-after: DOCSTART 1
+ :end-before: DOCEND 1
+
+.. container:: codeset
+
+ .. sourcecode:: kotlin
+
+ // Pull in the latest Vault version of the StateRef as a full StateAndRef
+ val latestRecord = serviceHub.latest(ref)
+
+
+Generating Commands
+-------------------
+
+For the commands that will be added to the transaction, these will need
+to correctly reflect the task at hand. These must match because inside
+the ``Contract.verify`` method the command will be used to select the
+validation code path. The ``Contract.verify`` method will then restrict
+the allowed contents of the transaction to reflect this context. Typical
+restrictions might include that the input cash amount must equal the
+output cash amount, or that a workflow step is only allowed to change
+the status field. Sometimes, the command may capture some data too e.g.
+the foreign exchange rate, or the identity of one party, or the StateRef
+of the specific input that originates the command in a bulk operation.
+This data will be used to further aid the ``Contract.verify``, because
+to ensure consistent, secure and reproducible behaviour in a distributed
+environment the ``Contract.verify``, transaction is the only allowed to
+use the content of the transaction to decide validity.
+
+Another essential requirement for commands is that the correct set of
+``CompositeKeys`` are added to the Command on the builder, which will be
+used to form the set of required signers on the final validated
+transaction. These must correctly align with the expectations of the
+``Contract.verify`` method, which should be written to defensively check
+this. In particular, it is expected that at minimum the owner of an
+asset would have to be signing to permission transfer of that asset. In
+addition, other signatories will often be required e.g. an Oracle
+identity for an Oracle command, or both parties when there is an
+exchange of assets.
+
+Generating Outputs
+------------------
+
+Having located a set of ``StateAndRefs`` as the transaction inputs, the
+flow has to generate the output states. Typically, this is a simple call
+to the Kotlin ``copy`` method to modify the few fields that will
+transitioned in the transaction. The contract code may provide a
+``generateXXX`` method to help with this process if the task is more
+complicated. With a workflow state a slightly modified copy state is
+usually sufficient, especially as it is expected that we wish to preserve
+the ``linearId`` between state revisions, so that Vault queries can find
+the latest revision.
+
+For fungible contract states such as ``Cash`` it is common to distribute
+and split the total amount e.g. to produce a remaining balance output
+state for the original owner when breaking up a large amount input
+state. Remember that the result of a successful transaction is always to
+fully consume/spend the input states, so this is required to conserve
+the total cash. For example from the demo code:
+
+.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/FxTransactionBuildTutorial.kt
+ :language: kotlin
+ :start-after: DOCSTART 2
+ :end-before: DOCEND 2
+
+Building the WireTransaction
+----------------------------
+
+Having gathered all the ingredients for the transaction we now need to
+use a ``TransactionBuilder`` to construct the full ``WireTransaction``.
+The initial ``TransactionBuilder`` should be created by calling the
+``TransactionType.General.Builder`` method. (The other
+``TransactionBuilder`` implementation is only used for the ``NotaryChange`` flow where
+``ContractStates`` need moving to a different Notary.) At this point the
+Notary to associate with the states should be recorded. Then we keep
+adding inputs, outputs, commands and attachments to fill the
+transaction. Examples of this process are:
+
+.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/WorkflowTransactionBuildTutorial.kt
+ :language: kotlin
+ :start-after: DOCSTART 2
+ :end-before: DOCEND 2
+
+.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/FxTransactionBuildTutorial.kt
+ :language: kotlin
+ :start-after: DOCSTART 3
+ :end-before: DOCEND 3
+
+Completing the SignedTransaction
+--------------------------------
+
+Having created an initial ``WireTransaction`` and converted this to an
+initial ``SignedTransaction`` the process of verifying and forming a
+full ``SignedTransaction`` begins and then completes with the
+notarisation. In practice this is a relatively stereotypical process,
+because assuming the ``WireTransaction`` is correctly constructed the
+verification should be immediate. However, it is also important to
+recheck the business details of any data received back from an external
+node, because a malicious party could always modify the contents before
+returning the transaction. Each remote flow should therefore check as
+much as possible of the initial ``SignedTransaction`` inside the ``unwrap`` of
+the receive before agreeing to sign. Any issues should immediately throw
+an exception to abort the flow. Similarly the originator, should always
+apply any new signatures to its original proposal to ensure the contents
+of the transaction has not been altered by the remote parties.
+
+The typical code therefore checks the received ``SignedTransaction``
+using the ``verifySignatures`` method, but excluding itself, the notary
+and any other parties yet to apply their signature. The contents of the
+``WireTransaction`` inside the ``SignedTransaction`` should be fully
+verified further by expanding with ``toLedgerTransaction`` and calling
+``verify``. Further context specific and business checks should then be
+made, because the ``Contract.verify`` is not allowed to access external
+context. For example the flow may need to check that the parties are the
+right ones, or that the ``Command`` present on the transaction is as
+expected for this specific flow. An example of this from the demo code is:
+
+.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/WorkflowTransactionBuildTutorial.kt
+ :language: kotlin
+ :start-after: DOCSTART 3
+ :end-before: DOCEND 3
+
+After verification the remote flow will return its signature to the
+originator. The originator should apply that signature to the starting
+``SignedTransaction`` and recheck the signatures match.
+
+Committing the Transaction
+--------------------------
+
+Once all the party signatures are applied to the SignedTransaction the
+final step is notarisation. This involves calling ``NotaryFlow.Client``
+to confirm the transaction, consume the inputs and return its confirming
+signature. Then the flow should ensure that all nodes end with all
+signatures and that they call ``ServiceHub.recordTransactions``. The
+code for this is standardised in the ``FinalityFlow``, or more explictly
+an example is:
+
+.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/WorkflowTransactionBuildTutorial.kt
+ :language: kotlin
+ :start-after: DOCSTART 4
+ :end-before: DOCEND 4
+
+Partially Visible Transactions
+------------------------------
+
+The discussion so far has assumed that the parties need full visibility
+of the transaction to sign. However, there may be situations where each
+party needs to store private data for audit purposes, or for evidence to
+a regulator, but does not wish to share that with the other trading
+partner. The tear-off/Merkle tree support in Corda allows flows to send
+portions of the full transaction to restrict visibility to remote
+parties. To do this one can use the
+``WireTransaction.buildFilteredTransaction`` extension method to produce
+a ``FilteredTransaction``. The elements of the ``SignedTransaction``
+which we wish to be hide will be replaced with their secure hash. The
+overall transaction txid is still provable from the
+``FilteredTransaction`` preventing change of the private data, but we do
+not expose that data to the other node directly. A full example of this
+can be found in the ``NodeInterestRates`` Oracle code from the
+``irs-demo`` project which interacts with the ``RatesFixFlow`` flow.
+Also, refer to the :doc:`merkle-trees` documentation.
diff --git a/docs/build/html/_sources/tutorial-clientrpc-api.txt b/docs/build/html/_sources/tutorial-clientrpc-api.txt
index 67ef519769..a4cdcd85bd 100644
--- a/docs/build/html/_sources/tutorial-clientrpc-api.txt
+++ b/docs/build/html/_sources/tutorial-clientrpc-api.txt
@@ -32,9 +32,12 @@ We start generating transactions in a different thread (``generateTransactions``
:start-after: interface CordaRPCOps
:end-before: }
+.. warning:: This API is evolving and will continue to grow as new functionality and features added to Corda are made available to RPC clients.
+
The one we need in order to dump the transaction graph is ``verifiedTransactions``. The type signature tells us that the
RPC will return a list of transactions and an Observable stream. This is a general pattern, we query some data and the
-node will return the current snapshot and future updates done to it.
+node will return the current snapshot and future updates done to it. Observables are described in further detail in
+:doc:`clientrpc`
.. literalinclude:: example-code/src/main/kotlin/net/corda/docs/ClientRpcTutorial.kt
:language: kotlin
@@ -66,7 +69,7 @@ The RPC we need to initiate a Cash transaction is ``startFlowDynamic`` which may
Finally we have everything in place: we start a couple of nodes, connect to them, and start creating transactions while listening on successfully created ones, which are dumped to the console. We just need to run it!:
-.. sourcecode:: bash
+.. code-block:: text
# Build the example
./gradlew docs/source/example-code:installDist
@@ -97,3 +100,53 @@ See more on plugins in :doc:`creating-a-cordapp`.
.. warning:: We will be replacing the use of Kryo in RPC with a stable message format and this will mean that this plugin
customisation point will either go away completely or change.
+
+Security
+--------
+RPC credentials associated with a Client must match the permission set configured on the server Node.
+This refers to both authentication (username and password) and role-based authorisation (a permissioned set of RPC operations an
+authenticated user is entitled to run).
+
+.. note:: Permissions are represented as *String's* to allow RPC implementations to add their own permissioning.
+ Currently the only permission type defined is *StartFlow*, which defines a list of whitelisted flows an authenticated use may execute.
+
+In the instructions above the server node permissions are configured programmatically in the driver code:
+
+.. code-block:: text
+
+ driver(driverDirectory = baseDirectory) {
+ val user = User("user", "password", permissions = setOf(startFlowPermission()))
+ val node = startNode("Alice", rpcUsers = listOf(user)).get()
+
+When starting a standalone node using a configuration file we must supply the RPC credentials as follows:
+
+.. code-block:: text
+
+ rpcUsers : [
+ { user=user, password=password, permissions=[ StartFlow.net.corda.flows.CashFlow ] }
+ ]
+
+When using the gradle Cordformation plugin to configure and deploy a node you must supply the RPC credentials in a similar manner:
+
+.. code-block:: text
+
+ rpcUsers = [
+ ['user' : "user",
+ 'password' : "password",
+ 'permissions' : ["StartFlow.net.corda.flows.CashFlow"]]
+ ]
+
+You can then deploy and launch the nodes (Notary and Alice) as follows:
+
+.. code-block:: text
+
+ # to create a set of configs and installs under ``docs/source/example-code/build/nodes`` run
+ ./gradlew docs/source/example-code:deployNodes
+ # to open up two new terminals with the two nodes run
+ ./docs/source/example-code/build/nodes/runnodes
+ # followed by the same commands as before:
+ ./docs/source/example-code/build/install/docs/source/example-code/bin/client-rpc-tutorial Print
+ ./docs/source/example-code/build/install/docs/source/example-code/bin/client-rpc-tutorial Visualise
+
+See more on security in :doc:`secure-coding-guidelines`, node configuration in :doc:`corda-configuration-file` and
+Cordformation in :doc:`creating-a-cordapp`
diff --git a/docs/build/html/_sources/tutorial-contract-clauses.txt b/docs/build/html/_sources/tutorial-contract-clauses.txt
index 9b4b24438a..01d1f68a5e 100644
--- a/docs/build/html/_sources/tutorial-contract-clauses.txt
+++ b/docs/build/html/_sources/tutorial-contract-clauses.txt
@@ -9,43 +9,63 @@ Writing a contract using clauses
This tutorial will take you through restructuring the commercial paper contract to use clauses. You should have
already completed ":doc:`tutorial-contract`".
+As before, the example is focused on basic implementation of commercial paper, which is essentially a simpler version of a corporate
+bond. A company issues CP with a particular face value, say $100, but sells it for less, say $90. The paper can be redeemed
+for cash at a given date in the future. Thus this example would have a 10% interest rate with a single repayment.
+Whole Kotlin code can be found in ``CommercialPaper.kt``.
+
+What are clauses and why to use them?
+-------------------------------------
Clauses are essentially micro-contracts which contain independent verification logic, and can be logically composed
-together to form a contract. Clauses are designed to enable re-use of common logic, for example issuing state objects
+together to form a contract. Clauses are designed to enable re-use of common verification parts, for example issuing state objects
is generally the same for all fungible contracts, so a common issuance clause can be inherited for each contract's
issue clause. This cuts down on scope for error, and improves consistency of behaviour. By splitting verification logic
into smaller chunks, they can also be readily tested in isolation.
-Clauses can be composed of subclauses, for example the ``AllClause`` or ``AnyClause`` clauses take list of clauses
-that they delegate to. Clauses can also change the scope of states and commands being verified, for example grouping
-together fungible state objects and running a clause against each distinct group.
+How clauses work?
+-----------------
-The commercial paper contract has a ``Group`` outermost clause, which contains the ``Issue``, ``Move`` and ``Redeem``
-clauses. The result is a contract that looks something like this:
+We have different types of clauses, the most basic are the ones that define verification logic for particular command set.
+We will see them later as elementary building blocks that commercial paper consist of - ``Move``, ``Issue`` and ``Redeem``.
+As a developer you need to identify reusable parts of your contract and decide how they should be combined. It is where
+composite clauses become useful. They gather many clause subcomponents and resolve how and which of them should be checked.
- 1. Group input and output states together, and then apply the following clauses on each group:
- a. If an ``Issue`` command is present, run appropriate tests and end processing this group.
- b. If a ``Move`` command is present, run appropriate tests and end processing this group.
- c. If a ``Redeem`` command is present, run appropriate tests and end processing this group.
+For example, assume that we want to verify a transaction using all constraints defined in separate clauses. We need to
+wrap classes that define them into ``AllComposition`` composite clause. It assures that all clauses from that combination
+match with commands in a transaction - only then verification logic can be executed.
+It may be a little confusing, but composite clause is also a clause and you can even wrap it in the special grouping clause.
+In ``CommercialPaper`` it looks like that:
+
+.. image:: resources/commPaperClauses.png
+
+The most basic types of composite clauses are ``AllComposition``, ``AnyComposition`` and ``FirstComposition``.
+In this tutorial we will use ``GroupClauseVerifier`` and ``AnyComposition``. It's important to understand how they work.
+Charts showing execution and more detailed information can be found in :doc:`clauses`.
+
+.. _verify_ref:
Commercial paper class
----------------------
-To use the clause verification logic, the contract needs to call the ``verifyClause`` function, passing in the
-transaction, a clause to verify, and a collection of commands the clauses are expected to handle all of. This list of
-commands is important because ``verifyClause`` checks that none of the commands are left unprocessed at the end, and
-raises an error if they are. The top level clause would normally be a composite clause (such as ``AnyComposition``,
-``AllComposition``, etc.) which contains further clauses. The following examples are trimmed to the modified class
-definition and added elements, for brevity:
+We start from defining ``CommercialPaper`` class. As in previous tutorial we need some elementary parts: ``Commands`` interface,
+``generateMove``, ``generateIssue``, ``generateRedeem`` - so far so good that stays the same. The new part is verification and
+``Clauses`` interface (you will see them later in code). Let's start from the basic structure:
.. container:: codeset
.. sourcecode:: kotlin
- class CommercialPaper : Contract {
- override val legalContractReference: SecureHash = SecureHash.sha256("https://en.wikipedia.org/wiki/Commercial_paper")
+ class CommercialPaper : Contract {
+ override val legalContractReference: SecureHash = SecureHash.sha256("https://en.wikipedia.org/wiki/Commercial_paper")
- override fun verify(tx: TransactionForContract) = verifyClause(tx, Clauses.Group(), tx.commands.select())
+ override fun verify(tx: TransactionForContract) = verifyClause(tx, Clauses.Group(), tx.commands.select())
+
+ interface Commands : CommandData {
+ data class Move(override val contractHash: SecureHash? = null) : FungibleAsset.Commands.Move, Commands
+ class Redeem : TypeOnlyCommandData(), Commands
+ data class Issue(override val nonce: Long = random63BitValue()) : IssueCommand, Commands
+ }
.. sourcecode:: java
@@ -60,88 +80,135 @@ definition and added elements, for brevity:
ClauseVerifier.verifyClause(tx, new Clauses.Group(), extractCommands(tx));
}
-Clauses
--------
+ public interface Commands extends CommandData {
+ class Move implements Commands {
+ @Override
+ public boolean equals(Object obj) { return obj instanceof Move; }
+ }
-We'll tackle the inner clauses that contain the bulk of the verification logic, first, and the clause which handles
-grouping of input/output states later. The clauses must extend the ``Clause`` abstract class, which defines
-the ``verify`` function, and the ``requiredCommands`` property used to determine the conditions under which a clause
-is triggered. Composite clauses should extend the ``CompositeClause`` abstract class, which extends ``Clause`` to
-add support for wrapping around multiple clauses.
+ class Redeem implements Commands {
+ @Override
+ public boolean equals(Object obj) { return obj instanceof Redeem; }
+ }
-The ``verify`` function defined in the ``Clause`` interface is similar to the conventional ``Contract`` verification
-function, although it adds new parameters and returns the set of commands which it has processed. Normally this returned
-set is identical to the ``requiredCommands`` used to trigger the clause, however in some cases the clause may process
-further optional commands which it needs to report that it has handled.
+ class Issue implements Commands {
+ @Override
+ public boolean equals(Object obj) { return obj instanceof Issue; }
+ }
+ }
-The ``Move`` clause for the commercial paper contract is relatively simple, so we will start there:
+As you can see we used ``verifyClause`` function with ``Clauses.Group()`` in place of previous verification.
+It's an entry point to running clause logic. ``verifyClause`` takes the transaction, a clause (usually a composite one)
+to verify, and a collection of commands the clause is expected to handle all of. This list of commands is important because
+``verifyClause`` checks that none of the commands are left unprocessed at the end, and raises an error if they are.
+
+Simple Clauses
+--------------
+
+Let's move to constructing contract logic in terms of clauses language. Commercial paper contract has three commands and
+three corresponding behaviours: ``Issue``, ``Move`` and ``Redeem``. Each of them has a specific set of requirements that must be satisfied -
+perfect material for defining clauses. For brevity we will show only ``Move`` clause, rest is constructed in similar manner
+and included in the ``CommercialPaper.kt`` code.
.. container:: codeset
.. sourcecode:: kotlin
- class Move: Clause>() {
- override val requiredCommands: Set>
- get() = setOf(Commands.Move::class.java)
+ interface Clauses {
+ class Move: Clause>() {
+ override val requiredCommands: Set>
+ get() = setOf(Commands.Move::class.java)
- override fun verify(tx: TransactionForContract,
+ override fun verify(tx: TransactionForContract,
inputs: List,
outputs: List,
commands: List>,
groupingKey: Issued?): Set {
- val command = commands.requireSingleCommand()
- val input = inputs.single()
- requireThat {
- "the transaction is signed by the owner of the CP" by (input.owner in command.signers)
- "the state is propagated" by (outputs.size == 1)
- // Don't need to check anything else, as if outputs.size == 1 then the output is equal to
- // the input ignoring the owner field due to the grouping.
+ val command = commands.requireSingleCommand()
+ val input = inputs.single()
+ requireThat {
+ "the transaction is signed by the owner of the CP" by (input.owner in command.signers)
+ "the state is propagated" by (outputs.size == 1)
+ // Don't need to check anything else, as if outputs.size == 1 then the output is equal to
+ // the input ignoring the owner field due to the grouping.
+ }
+ return setOf(command.value)
}
- return setOf(command.value)
}
- }
+ ...
.. sourcecode:: java
- class Move extends Clause {
- @NotNull
- @Override
- public Set> getRequiredCommands() {
- return Collections.singleton(Commands.Move.class);
- }
-
- @NotNull
- @Override
- public Set verify(@NotNull TransactionForContract tx,
- @NotNull List inputs,
- @NotNull List outputs,
- @NotNull List> commands,
- @NotNull State groupingKey) {
- AuthenticatedObject cmd = requireSingleCommand(tx.getCommands(), Commands.Move.class);
- // There should be only a single input due to aggregation above
- State input = single(inputs);
-
- if (!cmd.getSigners().contains(input.getOwner()))
- throw new IllegalStateException("Failed requirement: the transaction is signed by the owner of the CP");
-
- // Check the output CP state is the same as the input state, ignoring the owner field.
- if (outputs.size() != 1) {
- throw new IllegalStateException("the state is propagated");
+ public interface Clauses {
+ class Move extends Clause {
+ @NotNull
+ @Override
+ public Set> getRequiredCommands() {
+ return Collections.singleton(Commands.Move.class);
+ }
+
+ @NotNull
+ @Override
+ public Set verify(@NotNull TransactionForContract tx,
+ @NotNull List inputs,
+ @NotNull List outputs,
+ @NotNull List> commands,
+ @NotNull State groupingKey) {
+ AuthenticatedObject cmd = requireSingleCommand(tx.getCommands(), Commands.Move.class);
+ // There should be only a single input due to aggregation above
+ State input = single(inputs);
+
+ if (!cmd.getSigners().contains(input.getOwner()))
+ throw new IllegalStateException("Failed requirement: the transaction is signed by the owner of the CP");
+
+ // Check the output CP state is the same as the input state, ignoring the owner field.
+ if (outputs.size() != 1) {
+ throw new IllegalStateException("the state is propagated");
+ }
+ // Don't need to check anything else, as if outputs.size == 1 then the output is equal to
+ // the input ignoring the owner field due to the grouping.
+ return Collections.singleton(cmd.getValue());
}
- // Don't need to check anything else, as if outputs.size == 1 then the output is equal to
- // the input ignoring the owner field due to the grouping.
- return Collections.singleton(cmd.getValue());
}
- }
+ ...
+
+We took part of code for ``Command.Move`` verification from previous tutorial and put it into the verify function
+of ``Move`` class. Notice that this class must extend the ``Clause`` abstract class, which defines
+the ``verify`` function, and the ``requiredCommands`` property used to determine the conditions under which a clause
+is triggered. In the above example it means that the clause will run verification when the ``Commands.Move`` is present in a transaction.
+
+.. note:: Notice that commands refer to all input and output states in a transaction. For clause to be executed, transaction has
+ to include all commands from ``requiredCommands`` set.
+
+Few important changes:
+
+- ``verify`` function returns the set of commands which it has processed. Normally this returned set is identical to the
+ ``requiredCommands`` used to trigger the clause, however in some cases the clause may process further optional commands
+ which it needs to report that it has handled.
+
+- Verification takes new parameters. Usually inputs and outputs are some subset of the original transaction entries
+ passed to the clause by outer composite or grouping clause. ``groupingKey`` is a key used to group original states.
+
+As a simple example imagine input states:
+
+1. 1000 GBP issued by Bank of England
+2. 500 GBP issued by Bank of England
+3. 1000 GBP issued by Bank of Scotland
+
+We will group states by Issuer so in the first group we have inputs 1 and 2, in second group input number 3. Grouping keys are:
+'GBP issued by Bank of England' and 'GBP issued by Bank of Scotland'.
+
+How the states can be grouped and passed in that form to the ``Move`` clause? That leads us to the concept of ``GroupClauseVerifier``.
Group clause
------------
-We need to wrap the move clause (as well as the issue and redeem clauses - see the relevant contract code for their
-full specifications) in an outer clause that understands how to group contract states and objects. For this we extend
-the standard ``GroupClauseVerifier`` and specify how to group input/output states, as well as the top-level to run on
-each group. As with the top level clause on a contract, this is normally a composite clause that delegates to subclauses.
-
+We may have a transaction with similar but unrelated state evolutions which need to be validated independently. It
+makes sense to check ``Move`` command on groups of related inputs and outputs (see example above). Thus, we need to collect
+relevant states together.
+For this we extend the standard ``GroupClauseVerifier`` and specify how to group input/output states, as well as the top-level
+clause to run on each group. In our example a top-level is a composite clause - ``AnyCompostion`` that delegates verification to
+it's subclasses (wrapped move, issue, redeem). Any in this case means that it will take 0 or more clauses that match transaction commands.
.. container:: codeset
@@ -174,17 +241,20 @@ each group. As with the top level clause on a contract, this is normally a compo
}
}
-For the ``CommercialPaper`` contract, this is the top level clause for the contract, and is passed directly into
-``verifyClause`` (see the example code at the top of this tutorial).
+For the ``CommercialPaper`` contract, ``Group`` is the main clause for the contract, and is passed directly into
+``verifyClause`` (see the example code at the top of this tutorial). We used ``groupStates`` function here, it's worth reminding
+how it works: :ref:`state_ref`.
Summary
-------
In summary the top level contract ``CommercialPaper`` specifies a single grouping clause of type
``CommercialPaper.Clauses.Group`` which in turn specifies ``GroupClause`` implementations for each type of command
-(``Redeem``, ``Move`` and ``Issue``). This reflects the flow of verification: In order to verify a ``CommercialPaper``
+(``Redeem``, ``Move`` and ``Issue``). This reflects the flow of verification: in order to verify a ``CommercialPaper``
we first group states, check which commands are specified, and run command-specific verification logic accordingly.
+.. image:: resources/commPaperExecution.png
+
Debugging
---------
diff --git a/docs/build/html/_sources/tutorial-contract.txt b/docs/build/html/_sources/tutorial-contract.txt
index 2db18bdf4f..87f5e17c97 100644
--- a/docs/build/html/_sources/tutorial-contract.txt
+++ b/docs/build/html/_sources/tutorial-contract.txt
@@ -321,6 +321,8 @@ The second line does what the code suggests: it searches for a command object th
``CommercialPaper.Commands`` supertype, and either returns it, or throws an exception if there's zero or more than one
such command.
+.. _state_ref:
+
Using state groups
------------------
diff --git a/docs/build/html/_sources/tutorial-cordapp.txt b/docs/build/html/_sources/tutorial-cordapp.txt
new file mode 100644
index 0000000000..2097ac4267
--- /dev/null
+++ b/docs/build/html/_sources/tutorial-cordapp.txt
@@ -0,0 +1,852 @@
+.. highlight:: kotlin
+.. raw:: html
+
+
+
+
+The CorDapp Template
+====================
+
+This guide covers how to get started with the `cordapp-template`. Please note there are two Corda repositories:
+
+* ``corda`` which contains the core platform code and sample CorDapps.
+* ``cordapp-template`` which contains a template CorDapp you can use to bootstrap your own CorDapps. It is the subject
+ of this tutorial and should help you understand the basics of building a CorDapp.
+
+We recommend you read the non-technical white paper and technical white paper before you get started with Corda:
+
+1. `The Introductory white paper `_ describes the
+ motivating vision and background of the project. It is the kind of document your boss should read. It describes why the
+ project exists and briefly compares it to alternative systems on the market.
+2. `The Technical white paper `_ describes the entire
+ intended design from beginning to end. It is the kind of document that you should read, or at least, read parts of. Note
+ that because the technical white paper describes the intended end state, it does not always align with the implementation.
+
+Getting started
+---------------
+
+There are two ways to get started with the CorDapp template. You can either work from a milestone release of Corda or a
+SNAPSHOT release of Corda.
+
+**Using a monthly Corda milestone release.** If you wish to develop your CorDapp using the most recent milestone release
+then you can get started simply by cloning the ``cordapp-template`` repository. Gradle will grab all the required dependencies
+for you from our `public Maven repository `_.
+
+**Using a Corda SNAPSHOT build.** Alternatively, if you wish to work from the master branch of the Corda repo which contains
+the most up-to-date Corda feature set then you will need to clone the ``corda`` repository and publish the latest master
+build (or previously tagged releases) to your local Maven repository. You will then need to ensure that Gradle
+grabs the correct dependencies for you from Maven local by changing the ``corda_version`` in ``build.gradle``. This will be
+covered below in `Using a SNAPSHOT release`_.
+
+Firstly, follow the :doc:`getting set up ` page to download the JDK, IntelliJ and git if you didn't
+already have it.
+
+Working from milestone releases
+-------------------------------
+
+If you wish to build a CorDapp against a milestone release then please use these instructions.
+
+The process for developing your CorDapp from a milestone release is the most simple way to get started and is the preferred
+approach.
+
+We publish all our milestone releases to a public Maven repository on a monthly basis. As such, Gradle will automatically
+grab the appropriately versioned (specified in the ``cordapp-template``'s ``build.gradle`` file) dependencies for you from Maven.
+All you have to do is check out the release tag of the template version you wish to use.
+
+By default, the ``master`` branch of the ``cordapp-template`` points to a SNAPSHOT release of Corda, this is because it is
+being constantly updated to reflect the changes in the master branch of the `corda` repository.
+
+.. note:: If you wish to use a SNAPSHOT release then follow the instructions below: `Using a SNAPSHOT release`_.
+
+To clone the ``cordapp-template`` repository, use the following command:
+
+``git clone https://github.com/corda/cordapp-template``
+
+Now change directories to the freshly cloned repo:
+
+``cd cordapp-template``
+
+To enumerate all the tagged releases. Use:
+
+``git tag``
+
+To checkout a specific tag, use:
+
+``git checkout -b [local_branch_name] tags/[tag_name]``
+
+where ``local_branch_name`` is a name of your choice and ``tag_name`` is the name of the tag you wish to checkout.
+
+Gradle will handle all the dependencies for you. Now you are now ready to get started `building the CorDapp Template`_.
+
+Using a SNAPSHOT release
+------------------------
+
+If you wish to build a CorDapp against the most current version of Corda, follow these instructions.
+
+The Corda repository comprises the following folders:
+
+* **buildSrc** contains necessary gradle plugins to build Corda.
+* **client** contains the RPC client framework.
+* **config** contains logging configurations and the default node configuration file.
+* **core** containing the core Corda libraries such as crypto functions, types for Corda's building blocks: states,
+ contracts, transactions, attachments, etc. and some interfaces for nodes and protocols.
+* **docs** contains the Corda docsite in restructured text format as well as the built docs in html. The docs can be
+ accessed via ``/docs/index.html`` from the root of the repo.
+* **finance** defines a range of elementary contracts (and associated schemas) and protocols, such as abstract fungible
+ assets, cash, obligation and commercial paper.
+* **gradle** contains the gradle wrapper which you'll use to execute gradle commands.
+* **gradle-plugins** contains some additional plugins which we use to deploy Corda nodes.
+* **lib** contains some dependencies.
+* **node** contains anything specifically required for creating, running and managing nodes (eg: node driver, servlets,
+ node services, messaging, persistence).
+* **samples** contains all our Corda demos and code samples.
+* **test-utils** contains some utilities for unit testing contracts ( the contracts testing DSL) and protocols (the
+ mock network) implementation.
+* **tools** contains the explorer which is a GUI front-end for Corda.
+
+Firstly navigate to the folder on your machine you wish to clone the Corda repository to. Then use the following command
+to clone the Corda repository:
+
+``git clone https://github.com/corda/corda.git``
+
+Now change directories:
+
+``cd corda``
+
+Once you've cloned the ``corda`` repository and are in the repo directory you have the option to remain on the master
+branch or checkout a specific branch. Use:
+
+``git branch --all``
+
+to enumerate all the branches. To checkout a specific branch, use:
+
+``git checkout -b [local_branch_name] origin/[remote_branch_name]``
+
+where ``local_branch_name`` is a name of your choice and ``remote_branch_name`` is the name of the remote branch you wish
+to checkout.
+
+.. note:: When working with ``master`` you will have access to the most up-to-date feature set. However you will be
+ potentially sacrificing stability. We will endeavour to keep the ``master`` branch of the ``cordapp-template`` repo in sync
+ with the ``master`` branch of ``corda`` repo. A milestone tagged release would be more stable for CorDapp development.
+
+The next step is to publish the Corda JARs to your local Maven repository. By default the Maven local repository can be
+found:
+
+* ``~/.m2/repository`` on Unix/Mac OS X
+* ``%HOMEPATH%\.m2`` on windows.
+
+Publishing can be done with running the following Gradle task from the root project directory:
+
+Unix/Mac OSX: ``./gradlew install``
+
+Windows: ``gradlew.bat install``
+
+This will install all required modules, along with sources and JavaDocs to your local Maven repository. The ``version``
+and ``groupid`` of Corda installed to Maven local is specified in the ``build.gradle`` file in the root of the ``corda``
+repository. You shouldn't have to change these values unless you want to publish multiple versions of a SNAPSHOT, e.g.
+if you are trying out new features, in this case you can change ``version`` for each SNAPSHOT you publish.
+
+.. note:: **A quick point on corda version numbers used by Gradle.**
+
+ In the ``build.gradle`` file for your CorDapp, you can specify the ``corda_version`` to use. It is important that when
+ developing your CorDapp that you use the correct version number. For example, when wanting to work from a SNAPSHOT
+ release, the release numbers are suffixed with 'SNAPSHOT', e.g. if the latest milestone release is M6 then the
+ SNAPSHOT release will be 0.7-SNAPSHOT, and so on. As such, you will set your ``corda_version`` to ``'0.7-SNAPSHOT'``
+ in the ``build.gradle`` file in your CorDapp. Gradle will automatically grab the SNAPSHOT dependencies from your local
+ Maven repository. Alternatively, if working from a milestone release, you will use the version number only, for example
+ ``0.6`` or ``0.7``.
+
+ Lastly, as the Corda repository evolves on a daily basis up until the next milestone release, it is worth nothing that
+ the substance of two SNAPSHOT releases of the same number may be different. If you are using a SNAPSHOT and need help
+ debugging an error then please tell us the **commit** you are working from. This will help us ascertain the issue.
+
+As additional feature branches are merged into Corda you can ``git pull`` the new changes from the ``corda`` repository.
+If you are feeling inquisitive, you may also wish to review some of the current feature branches. All new features are
+developed on separate branches. To enumerate all the current branches use:
+
+``git branch --all``
+
+and to check out an open feature branch, use:
+
+``git checkout -b [local_branch_name] origin/[branch_name]``
+
+.. note:: Publishing Corda JARs from unmerged feature branches might cause some unexpected behaviour / broken CorDapps.
+ It would also replace any previously published SNAPSHOTS of the same version.
+
+.. warning:: If you do modify Corda after you have previously published it to Maven local then you must republish your
+ SNAPSHOT build such that Maven reflects the changes you have made.
+
+Once you have published the Corda JARs to your local Maven repository, you are ready to get started building your
+CorDapp using the latest Corda features.
+
+Opening the CorDapp Template with IntelliJ
+------------------------------------------
+
+For those familiar with IntelliJ, you can skip this section.
+
+As noted in the getting started guide, we recommend using the IntelliJ IDE. Assuming you have already downloaded and
+installed IntelliJ, lets now open the CorDapp Template with IntelliJ.
+
+**For those completely new to IntelliJ**
+
+Firstly, load up IntelliJ. A dialogue will appear:
+
+.. image:: resources/intellij-welcome.png
+ :width: 400
+
+Click open, then navigate to the folder where you cloned the ``cordapp-template`` and click OK.
+
+Next, IntelliJ will show a bunch of pop-up windows. One of which requires our attention:
+
+.. image:: resources/unlinked-gradle-project.png
+ :width: 400
+
+Click the 'import gradle project' link. A dialogue will pop-up. Press OK. Gradle will now begin obtianing all the
+project dependencies and perform some indexing. It usually takes a minute or so. If you miss the 'import gradle project'
+dialogue, simply close and re-open IntelliJ again to see it again.
+
+**Alternative approach**
+
+Alternatively, one can instruct IntelliJ to create a new project through cloning a repository. From the IntelliJ welcome
+dialogue (shown above), opt to 'check out from version control', then select git and enter the git url for the CorDpp tempalte
+(https://github.com/corda/cordapp-template). You'll then need to import the Gradle project when prompted, as explained above.
+
+**If you already have IntelliJ open**
+
+From the ``File`` menu, navigate to ``Open ...`` and then navigate to the directory where you cloned the ``cordapp-template``.
+Alternatively, if you wish to clone from github directly then navigate to ``File > New > Project from existing sources ...``
+and enter the URL to the CorDapp Template (specified above). When instructed, be sure to import the Gradle project when prompted.
+
+**The Gradle plugin**
+
+IntelliJ can be used to run Gradle tasks through the Gradle plugin which can be found via ``View > Tool windows > Gradle``.
+All the Gradle projects are listed in the window on the right hand side of the IDE. Click on a project, then 'tasks' to
+see all available Gradle tasks.
+
+* For the CorDapp Template repo there will only be one Gradle project listed.
+* For the Corda repo there will be many project listed, the root project ``corda`` and associated sub-projects: ``core``,
+ ``finance``, ``node``, etc.
+
+.. note:: It's worth noting that when you change branch in the CorDapp template, the ``corda_version`` will change to
+ reflect the version of the branch you are working from.
+
+To execute a task, double click it. The output will be shown in a console window.
+
+Building the CorDapp template
+=============================
+
+**From the command line**
+
+Firstly, return to your terminal window used above and make sure you are in the ``cordapp-template`` directory.
+
+To build the CorDapp template use the following command:
+
+Unix/Mac OSX: ``./gradlew deployNodes``
+
+Windows: ``gradlew.bat deployNodes``
+
+Building straight away will build the example CorDapp defined the the CorDapp template source. For more information on the example
+CorDapp see "The Example CorDapp" section below. Gradle will then grab all the dependencies for you and build the
+example CorDapp.
+
+The ``deployNodes`` Gradle task allows you easily create a formation of Corda nodes. In the case of the example CorDapp
+we are creating ``four`` nodes.
+
+After the building process has finished to see the newly built nodes, you can navigate to the ``/build/nodes`` folder
+located in the ``cordapp-template`` root directory. You can ignore the other folders in ``/build`` for now. The ``nodes``
+folder has the following structure:
+
+.. sourcecode:: none
+
+ . nodes
+ ├── controller
+ │ ├── corda.jar
+ │ ├── dependencies
+ │ ├── node.conf
+ │ └── plugins
+ ├── nodea
+ │ ├── corda.jar
+ │ ├── dependencies
+ │ ├── node.conf
+ │ └── plugins
+ ├── nodeb
+ │ ├── corda.jar
+ │ ├── dependencies
+ │ ├── node.conf
+ │ └── plugins
+ ├── nodec
+ │ ├── corda.jar
+ │ ├── dependencies
+ │ ├── node.conf
+ │ └── plugins
+ ├── runnodes
+ └── runnodes.bat
+
+There will be one folder generated for each node you build (more on later when we get into the detail of the
+``deployNodes`` Gradle task) and a ``runnodes`` shell script (batch file on Widnows).
+
+Each node folder contains the Corda JAR, a folder for dependencies and a folder for plugins (or CorDapps). There is also
+a node.conf file. See :doc:`Corda configuration files `.
+
+**Building from IntelliJ**
+
+Open the Gradle window by selecting ``View > Tool windows > Gradle`` from the main menu. You will see the Gradle window
+open on the right hand side of the IDE. Expand `tasks` and then expand `other`. Double click on `deployNodes`. Gradle will
+start the build process and output progress to a console window in the IDE.
+
+Running the Sample CorDapp
+==========================
+
+Running the Sample CorDapp from the command line
+------------------------------------------------
+
+To run the sample CorDapp navigate to the ``build/nodes`` folder and execute the ``runnodes`` shell script with:
+
+Unix: ``./runnodes`` or ``sh runnodes``
+
+Windows: ``runnodes.bat``
+
+The ``runnodes`` scripts should create a terminal tab for each node. In each terminal tab, you'll see the Corda welcome
+message and some pertinent config information, see below:
+
+.. sourcecode:: none
+
+ ______ __
+ / ____/ _________/ /___ _
+ / / __ / ___/ __ / __ `/ Computer science and finance together.
+ / /___ /_/ / / / /_/ / /_/ / You should see our crazy Christmas parties!
+ \____/ /_/ \__,_/\__,_/
+
+ --- DEVELOPER SNAPSHOT ------------------------------------------------------------
+
+ Logs can be found in : /Users/rogerwillis/Documents/Corda/cordapp-template/build/nodes/nodea/logs
+ Database connection url is : jdbc:h2:tcp://10.18.0.196:50661/node
+ Node listening on address : localhost:10004
+ Loaded plugins : com.example.plugin.ExamplePlugin
+ Embedded web server is listening on : http://10.18.0.196:10005/
+ Node started up and registered in 39.0 sec
+
+You'll need to refer to the above later on for the JDBC connection string and port numbers.
+
+Depending on the speed of your machine, it usually takes around 30 seconds for the nodes to finish starting up. If you
+want to double check all the nodes are running you can query the 'status' end-point located at
+``http://host:post/api/status``.
+
+When booted up, the node will generate a bunch of files and directories in addition to the ones covered above:
+
+.. sourcecode:: none
+
+ .
+ ├── artemis
+ ├── attachments
+ ├── cache
+ ├── certificates
+ ├── corda.jar
+ ├── dependencies
+ ├── identity-private-key
+ ├── identity-public
+ ├── logs
+ ├── node.conf
+ ├── persistence.mv.db
+ └── plugins
+
+Notably:
+
+* **artemis** contains the internal files for Artemis MQ, our message broker.
+* **attachments** contains any persisted attachments.
+* **certificates** contains the certificate store.
+* **identity-private-key** is the node's private key.
+* **identity-public** is the node's public key.
+* **logs** contains the node's log files.
+* **persistence.mv.db** is the h2 database where transactions and other data is persisted.
+
+Additional files and folders are added as the node is running.
+
+Running CorDapps on separate machines
+-------------------------------------
+
+Corda nodes can be run on separate machines with little additional configuration to the above instructions.
+
+When you have successfully run the ``deployNodes`` gradle task, choose which nodes you would like to run on separate
+machines. Copy the folders for those nodes from ``build/nodes`` to the other machines. Make sure that you set the
+``networkMapAddress`` property in ``node.conf`` to the correct hostname:port where the network map service node is
+hosted.
+
+The nodes can be run on each machine with ``java -jar corda.jar`` from the node's directory.
+
+Running the example CorDapp via IntelliJ
+----------------------------------------
+
+To run the example CorDapp via IntelliJ you can use the ``Run Example CorDapp`` run configuration. Select it from the drop
+down menu at the top right-hand side of the IDE and press the green arrow to start the nodes. See image below:
+
+.. image:: resources/run-config-drop-down.png
+ :width: 400
+
+The node driver defined in ``/src/main/kotlin/com/example/Main.kt`` allows you to specify how many nodes you would like
+to run and the various configuration settings for each node. With the example CorDapp, the Node driver starts four nodes
+and sets up an RPC user for all but the "Controller" node (which hosts the notary Service and network map service):
+
+.. sourcecode:: kotlin
+
+ fun main(args: Array) {
+ // No permissions required as we are not invoking flows.
+ val user = User("user1", "test", permissions = setOf())
+ driver(dsl = {
+ startNode("Controller", setOf(ServiceInfo(ValidatingNotaryService.type)))
+ startNode("NodeA", rpcUsers = listOf(user))
+ startNode("NodeB", rpcUsers = listOf(user))
+ startNode("NodeC", rpcUsers = listOf(user))
+ waitForAllNodesToFinish()
+ }, isDebug = true)
+ }
+
+To stop the nodes, press the red "stop" button at the top right-hand side of the IDE.
+
+The node driver can also be used to as a basis for `debugging your CorDapp`_
+
+Using the sample CorDapp
+========================
+
+Background
+----------
+
+The Example CorDapp implements a basic scenario where a buyer wishes to submit purchase orders to a seller. The scenario
+defines four nodes:
+
+* **Controller** which hosts the network map service and validating notary service.
+* **NodeA** who is the buyer.
+* **NodeB** who is the seller.
+* **NodeC** an unrelated third party.
+
+NodeA can generate purchase orders for lists and quantities of items and associated metadata such as delivery address
+and delivery date. The flows used to facilitate the agreement process always results in an agreement with the seller as
+long as the purchase order meets the contract constraints which are defined in ``PurchaseOrderContract.kt``.
+
+All agreed purchase orders between NodeA and NodeB become "shared facts" between NodeA and NodeB. But note that NodeC
+won't see any of these transactions or have copies of any of the resulting ``PurchaseOrderState`` objects. This is
+because data is only propagated on a need-to-know basis.
+
+Interfaces
+----------
+
+The CorDapp defines a few HTTP API end-points and also serves some static web content. The end-points allow you to
+list purchase orders and add purchase orders.
+
+The nodes can be found using the following port numbers, defined in build.gradle and the respective node.conf file for
+each node found in `build/nodes/NodeX`` etc:
+
+* Controller: ``localhost:10003``
+* NodeA: ``localhost:10005``
+* NodeB: ``localhost:10007``
+* NodeC: ``localhost:10009``
+
+Note that the ``deployNodes`` Gradle task is used to generate the ``node.conf`` files for each node.
+
+As the nodes start-up they should tell you which host and port the embedded web server is running on. The API endpoints
+served are as follows:
+
+* ``/api/example/me``
+* ``/api/example/peers``
+* ``/api/example/purchase-orders``
+* ``/api/example/{COUNTERPARTY}/create-purchase-order``
+
+The static web content is served from ``/web/example``.
+
+A purchase order can be created via accessing the ``api/example/create-purchase-order`` end-point directly or through the
+the web form hosted at ``/web/example``.
+
+ .. warning:: **The content in ``web/example`` is only available for demonstration purposes and does not implement any
+ anti-XSS, anti-XSRF or any other security techniques. Do not copy such code directly into products meant for production use.**
+
+**Submitting a purchase order via HTTP API:**
+
+To create a purchase order from NodeA to NodeB, use:
+
+.. sourcecode:: bash
+
+ echo '{"orderNumber": "1","deliveryDate": "2018-09-15","deliveryAddress": {"city": "London","country": "UK"},"items" : [{"name": "widget","amount": "3"},{"name": "thing","amount": "4"}]}' | curl -T - -H 'Content-Type: application/json' http://localhost:10005/api/example/NodeB/create-purchase-order
+
+Note the port number ``10005`` (NodeA) and NodeB referenced in the API end-point path. This command instructs NodeA to
+create and send a purchase order to NodeB. Upon verification and completion of the process, both nodes (but not NodeC) will
+have a signed, notarised copy of the purchase order.
+
+**Submitting a purchase order via web/example:**
+
+Navigate to the "create purchase order" button at the top left of the page, enter in the purchase order details e.g.
+
+.. sourcecode:: none
+
+ Counter-party: Select from list
+ Order Number: 1
+ Delivery Date: 2018-09-15
+ City: London
+ Country Code: UK
+ Item name: Wow such item
+ Item amount: 5
+
+and click submit (note you can add additional item types and amounts). Upon pressing submit, the modal dialogue should close.
+To check what validation is performed over the purchase order data, have a look at the ``PurchaseOrderContract.Place`` class in
+``PurchaseOrderContract.kt`` which defines the following contract constraints (among others not included here):
+
+.. sourcecode:: kotlin
+
+ // Purchase order specific constraints.
+ "We only deliver to the UK." by (out.po.deliveryAddress.country == "UK")
+ "You must order at least one type of item." by (out.po.items.size > 0)
+ "You cannot order zero or negative amounts of an item." by (out.po.items.map(Item::amount).all { it > 0 })
+ "You can only order up to 10 items at a time." by (out.po.items.map(Item::amount).sum() <= 10)
+ val time = tx.timestamp?.midpoint
+ "The delivery date must be in the future." by (out.po.deliveryDate.toInstant() > time)
+
+**Once a purchase order has been submitted:**
+
+Inspect the terminal windows for the nodes. Assume all of the above contract constraints are met, you should see some
+activity in the terminal windows for NodeA and NodeB (note: the green ticks are only visible on unix/mac):
+
+*NodeA:*
+
+.. sourcecode:: none
+
+ ✅ Constructing proposed purchase order.
+ ✅ Sending purchase order to seller for review.
+ ✅ Received partially signed transaction from seller.
+ ✅ Verifying signatures and contract constraints.
+ ✅ Signing transaction with our private key.
+ ✅ Obtaining notary signature.
+ ✅ Requesting signature by Notary service
+ ✅ Validating response from Notary service
+ ✅ Recording transaction in vault.
+ ✅ Sending fully signed transaction to seller.
+ ✅ Done
+
+*NodeB:*
+
+.. sourcecode:: none
+
+ ✅ Receiving proposed purchase order from buyer.
+ ✅ Generating transaction based on proposed purchase order.
+ ✅ Signing proposed transaction with our private key.
+ ✅ Sending partially signed transaction to buyer and wait for a response.
+ ✅ Verifying signatures and contract constraints.
+ ✅ Recording transaction in vault.
+ ✅ Done
+
+*NodeC:*
+
+.. sourcecode:: none
+
+ You shouldn't see any activity.
+
+Next you can view the newly created purchase order by accessing the vault of NodeA or NodeB:
+
+*Via the HTTP API:*
+
+For NodeA. navigate to http://localhost:10005/api/example/purchase-orders. For NodeB,
+navigate to http://localhost:10007/api/example/purchase-orders.
+
+*Via web/example:*
+
+Navigate to http://localhost:10005/web/example the refresh button in the top left-hand side of the page. You should
+see the newly created agreement on the page.
+
+**Accessing the h2 database via h2 web console:**
+
+You can connect to the h2 database to see the current state of the ledger, among other data such as the current state of
+the network map cache. Firstly, navigate to the folder where you downloaded the h2 web console as part of the pre-requisites
+section, above. Change directories to the bin folder:
+
+``cd h2/bin``
+
+Where there are a bunch of shell scripts and batch files. Run the web console:
+
+Unix:
+
+``sh h2.sh``
+
+Windows:
+
+``h2.bat``
+
+The h2 web console should start up in a web browser tab. To connect we first need to obtain a JDBC connection string. Each
+node outputs its connection string in the terminal window as it starts up. In a terminal window where a node is running,
+look for the following string:
+
+``Database connection url is : jdbc:h2:tcp://10.18.0.150:56736/node``
+
+you can use the string on the right to connect to the h2 database: just paste it in to the JDBC URL field and click Connect.
+You will be presented with a web application that enumerates all the available tables and provides an interface for you to
+query them using SQL.
+
+**Using the Example RPC client:**
+
+The ``/src/main/kotlin/com/example/client/ExampleClientRPC.kt`` file is a simple utility which uses the client RPC library
+to connect to a node and log the 'placed' purchase orders. It will log any existing purchase orders and listen for any future
+purchase orders. If you haven't placed any purchase orders when you connect to to one of the Nodes via RPC then the client will log
+and future purchase orders which are agreed.
+
+To build the client use the following gradle task:
+
+``./gradlew runExampleClientRPC``
+
+*To run the client, via IntelliJ:*
+
+Select the 'Run Example RPC Client' run configuration which, by default, connects to NodeA (Artemis port 10004). Click the
+Green Arrow to run the client. You can edit the run configuration to connect on a different port.
+
+*Via command line:*
+
+Run the following gradle task:
+
+``./gradlew runExampleClientRPC localhost:10004``
+
+To close the application use ``ctrl+C``. For more information on the client RPC interface and how to build an RPC client
+application see:
+
+* :doc:`Client RPC documentation `
+* :doc:`Client RPC tutorial `
+
+CorDapp-template Project Structure
+----------------------------------
+
+The CorDapp template has the following directory structure:
+
+.. sourcecode:: none
+
+ . cordapp-template
+ ├── README.md
+ ├── LICENSE
+ ├── build.gradle
+ ├── config
+ │ ├── ...
+ ├── gradle
+ │ └── ...
+ ├── gradle.properties
+ ├── gradlew
+ ├── gradlew.bat
+ ├── lib
+ │ ├── ...
+ ├── settings.gradle
+ └── src
+ ├── main
+ │ ├── java
+ │ ├── kotlin
+ │ │ └── com
+ │ │ └── example
+ │ │ ├── Main.kt
+ │ │ ├── api
+ │ │ │ └── ExampleApi.kt
+ │ │ ├── client
+ │ │ │ └── ExampleClientRPC.kt
+ │ │ ├── contract
+ │ │ │ ├── PurchaseOrderContract.kt
+ │ │ │ └── PurchaseOrderState.kt
+ │ │ ├── model
+ │ │ │ └── PurchaseOrder.kt
+ │ │ ├── plugin
+ │ │ │ └── ExamplePlugin.kt
+ │ │ └── flow
+ │ │ └── ExampleFlow.kt
+ │ │ └── service
+ │ │ └── ExampleService.kt
+ │ ├── python
+ │ └── resources
+ │ ├── META-INF
+ │ │ └── services
+ │ │ └── net.corda.core.node.CordaPluginRegistry
+ │ ├── certificates
+ │ │ ├── readme.txt
+ │ │ ├── sslkeystore.jks
+ │ │ └── truststore.jks
+ │ └── exampleWeb
+ │ ├── index.html
+ │ └── js
+ │ └── example.js
+ └── test
+ ├── java
+ ├── kotlin
+ │ └── com
+ │ └── example
+ │ └── ExampleTest.kt
+ └── resources
+
+In the file structure above, the most important files and directories to note are:
+
+* The **root directory** contains some gradle files, a README and a LICENSE.
+* **config** contains log4j configs.
+* **gradle** contains the gradle wrapper, which allows the use of Gradle without installing it yourself and worrying
+ about which version is required.
+* **lib** contains the Quasar.jar which is required for runtime instrumentation of classes by Quasar.
+* **src/main/kotlin** contains the source code for the example CorDapp.
+* **src/main/python** contains a python script which accesses nodes via RPC.
+* **src/main/resources** contains the certificate store, some static web content to be served by the nodes and the
+ PluginServiceRegistry file.
+* **src/test/kotlin** contains unit tests for protocols, contracts, etc.
+
+Some elements are covered in more detail below.
+
+The build.gradle File
+---------------------
+
+It is usually necessary to make a couple of changes to the ``build.gradle`` file. Here will cover the most pertinent bits.
+
+**The buildscript**
+
+The buildscript is always located at the top of the file. It determines which plugins, task classes, and other classes
+are available for use in the rest of the build script. It also specifies version numbers for dependencies, among other
+things.
+
+If you are working from a Corda SNAPSHOT release which you have publish to Maven local then ensure that
+``corda_version`` is the same as the version of the Corda core modules you published to Maven local. If not then change the
+``kotlin_version`` property. Also, if you are working from a previous milestone release, then be sure to ``git checkout``
+the correct version of the CorDapp template from the ``cordapp-template`` repo.
+
+.. sourcecode:: groovy
+
+ buildscript {
+ ext.kotlin_version = '1.0.4'
+ ext.corda_version = '0.5-SNAPSHOT' // Ensure this version is the same as the corda core modules you are using.
+ ext.quasar_version = '0.7.6'
+ ext.jersey_version = '2.23.1'
+
+ repositories {
+ ...
+ }
+
+ dependencies {
+ ...
+ }
+ }
+
+**Project dependencies**
+
+If you have any additional external dependencies for your CorDapp then add them below the comment at the end of this
+code snippet.package. Use the standard format:
+
+``compile "{groupId}:{artifactId}:{versionNumber}"``
+
+.. sourcecode:: groovy
+
+ dependencies {
+ compile "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
+ testCompile group: 'junit', name: 'junit', version: '4.11'
+
+ // Corda integration dependencies
+ compile "net.corda:client:$corda_version"
+ compile "net.corda:core:$corda_version"
+ compile "net.corda:contracts:$corda_version"
+ compile "net.corda:node:$corda_version"
+ compile "net.corda:corda:$corda_version"
+ compile "net.corda:test-utils:$corda_version"
+
+ ...
+
+ // Cordapp dependencies
+ // Specify your cordapp's dependencies below, including dependent cordapps
+ }
+
+For further information about managing dependencies with `look at the Gradle docs `_.
+
+**CordFormation**
+
+This is the local node deployment system for CorDapps, the nodes generated are intended to be used for experimenting,
+debugging, and testing node configurations but not intended for production or testnet deployment.
+
+In the CorDapp build.gradle file you'll find a ``deployNodes`` task, this is where you configure the nodes you would
+like to deploy for testing. See further details below:
+
+.. sourcecode:: groovy
+
+ task deployNodes(type: com.r3corda.plugins.Cordform, dependsOn: ['build']) {
+ directory "./build/nodes" // The output directory.
+ networkMap "Controller" // The artemis address of the node to be used as the network map.
+ node {
+ name "Controller" // Artemis name of node to be deployed.
+ dirName "controller" // Directory to which the node will
+ nearestCity "London" // For use with the network visualiser.
+ advertisedServices = ["corda.notary.validating"] // A list of services you wish the node to offer.
+ artemisPort 10002
+ webPort 10003 // Usually 1 higher than the Artemis port.
+ cordapps = [] // Add package names of CordaApps.
+ }
+ node { // Create an additional node.
+ name "NodeA"
+ dirName "nodea"
+ nearestCity "London"
+ advertisedServices = []
+ artemisPort 10004
+ webPort 10005
+ cordapps = []
+ }
+ ...
+ }
+
+You can add any number of nodes, with any number of services / CorDapps by editing the templates in ``deployNodes``. The
+only requirement is that you must specify a node to run as the network map service and one as the notary service.
+
+.. note:: CorDapps in the current cordapp-template project are automatically registered with all nodes defined in
+ ``deployNodes``, although we expect this to change in the near future.
+
+.. warning:: Make sure that there are no port clashes!
+
+When you are finished editing your *CordFormation* the changes will be reflected the next time you run ``./gradlew deployNodes``.
+
+Service Provider Configuration File
+-----------------------------------
+
+If you are building a CorDapp from scratch or adding a new CorDapp to the CorDapp-template project then you must provide
+a reference to your sub-class of ``CordaPluginRegistry`` in the provider-configuration file in located in the the
+``resources/META-INF/services`` directory.
+
+Re-Deploying Your Nodes Locally
+-------------------------------
+
+If you need to create any additional nodes you can do it via the ``build.gradle`` file as discussed above in
+``the build.gradle file`` and in more detail in the "cordFormation" section.
+
+You may also wish to edit the ``/build/nodes//node.conf`` files for your nodes. For more information on
+doing this, see the :doc:`Corda configuration file ` page.
+
+Once you have made some changes to your CorDapp you can redeploy it with the following command:
+
+Unix/Mac OSX: ``./gradlew deployNodes``
+
+Windows: ``gradlew.bat deployNodes``
+
+Debugging your CorDapp
+----------------------
+
+Debugging is done via IntelliJ and can be done using the following steps.
+
+1. Set your breakpoints.
+2. Edit the node driver code in ``Main.kt`` to reflect how many nodes you wish to start along with any other
+ configuration options. For example, the below starts 4 nodes, with one being the network map service / notary and
+ sets up RPC credentials for 3 of the nodes.
+
+.. sourcecode:: kotlin
+
+ fun main(args: Array) {
+ // No permissions required as we are not invoking flows.
+ val user = User("user1", "test", permissions = setOf())
+ driver(dsl = {
+ startNode("Controller", setOf(ServiceInfo(ValidatingNotaryService.type)))
+ startNode("NodeA", rpcUsers = listOf(user))
+ startNode("NodeB", rpcUsers = listOf(user))
+ startNode("NodeC", rpcUsers = listOf(user))
+ waitForAllNodesToFinish()
+ }, isDebug = true)
+ }
+
+3. Select and run the “Run Example CorDapp” run configuration in IntelliJ.
+4. IntelliJ will build and run the CorDapp. Observe the console output for the remote debug ports. The “Controller”
+ node will generally be on port 5005, with NodeA on port 5006 an so-on.
+
+.. sourcecode:: none
+
+ Listening for transport dt_socket at address: 5008
+ Listening for transport dt_socket at address: 5007
+ Listening for transport dt_socket at address: 5006
+
+5. Edit the “Debug CorDapp” run configuration with the port of the node you wish to connect to.
+6. Run the “Debug CorDapp” run configuration.
+
diff --git a/docs/build/html/_sources/tutorial-integration-testing.txt b/docs/build/html/_sources/tutorial-integration-testing.txt
new file mode 100644
index 0000000000..4cca59f009
--- /dev/null
+++ b/docs/build/html/_sources/tutorial-integration-testing.txt
@@ -0,0 +1,117 @@
+Integration Test Tutorial
+=========================
+
+Integration testing involves bringing up nodes locally and testing
+invariants about them by starting flows and inspecting their state.
+
+In this tutorial we will bring up three nodes Alice, Bob and a
+Notary. Alice will issue Cash to Bob, then Bob will send this Cash
+back to Alice. We will see how to test some simple deterministic and
+nondeterministic invariants in the meantime.
+
+(Note that this example where Alice is self-issuing Cash is purely for
+demonstration purposes, in reality Cash would be issued by a bank and
+subsequently passed around.)
+
+In order to spawn nodes we will use the Driver DSL. This DSL allows
+one to start up node processes from code. It manages a network map
+service and safe shutting down of nodes in the background.
+
+.. literalinclude:: example-code/src/integration-test/kotlin/net/corda/docs/IntegrationTestingTutorial.kt
+ :language: kotlin
+ :start-after: START 1
+ :end-before: END 1
+
+The above code creates a ``User`` permissioned to start the
+``CashFlow`` protocol. It then starts up Alice and Bob with this user,
+allowing us to later connect to the nodes.
+
+Then the notary is started up. Note that we need to add
+``ValidatingNotaryService`` as an advertised service in order for this
+node to serve notary functionality. This is also where flows added in
+plugins should be specified. Note also that we won't connect to the
+notary directly, so there's no need to pass in the test ``User``.
+
+The ``startNode`` function returns a future that completes once the
+node is fully started. This allows starting of the nodes to be
+parallel. We wait on these futures as we need the information
+returned; their respective ``NodeInfo`` s.
+
+.. literalinclude:: example-code/src/integration-test/kotlin/net/corda/docs/IntegrationTestingTutorial.kt
+ :language: kotlin
+ :start-after: START 2
+ :end-before: END 2
+
+Next we connect to Alice and Bob respectively from the test process
+using the test user we created. Then we establish RPC links that allow
+us to start flows and query state.
+
+Note that Driver nodes start up with test server certificiates, so
+it's enough to pass in ``configureTestSSL()`` for the clients.
+
+.. literalinclude:: example-code/src/integration-test/kotlin/net/corda/docs/IntegrationTestingTutorial.kt
+ :language: kotlin
+ :start-after: START 3
+ :end-before: END 3
+
+We will be interested in changes to Alice's and Bob's vault, so we
+query a stream of vault updates from each.
+
+Now that we're all set up we can finally get some Cash action going!
+
+.. literalinclude:: example-code/src/integration-test/kotlin/net/corda/docs/IntegrationTestingTutorial.kt
+ :language: kotlin
+ :start-after: START 4
+ :end-before: END 4
+
+The first loop creates 10 threads, each starting a ``CashFlow`` flow
+on the Alice node. We specify that we want to issue ``i`` dollars to
+Bob, using the Notary as the notary responsible for notarising the
+created states. Note that no notarisation will occur yet as we're not
+spending any states, only entering new ones to the ledger.
+
+We started the flows from different threads for the sake of the
+tutorial, to demonstrate how to test non-determinism, which is what
+the ``expectEvents`` block does.
+
+The Expect DSL allows ordering constraints to be checked on a stream
+of events. The above code specifies that we are expecting 10 updates
+to be emitted on the ``bobVaultUpdates`` stream in unspecified order
+(this is what the ``parallel`` construct does). We specify a
+(otherwise optional) ``match`` predicate to identify specific updates
+we are interested in, which we then print.
+
+If we run the code written so far we should see 4 nodes starting up
+(Alice,Bob,Notary + implicit Network Map service), then 10 logs of Bob
+receiving 1,2,...10 dollars from Alice in some unspecified order.
+
+Next we want Bob to send this Cash back to Alice.
+
+.. literalinclude:: example-code/src/integration-test/kotlin/net/corda/docs/IntegrationTestingTutorial.kt
+ :language: kotlin
+ :start-after: START 5
+ :end-before: END 5
+
+This time we'll do it sequentially. We make Bob pay 1,2,..10 dollars
+to Alice in order. We make sure that a the ``CashFlow`` has finished
+by waiting on ``startFlow`` 's ``returnValue``.
+
+Then we use the Expect DSL again, this time using ``sequence`` to test
+for the updates arriving in the order we expect them to.
+
+Note that ``parallel`` and ``sequence`` may be nested into each other
+arbitrarily to test more complex scenarios.
+
+That's it! We saw how to start up several corda nodes locally, how to
+connect to them, and how to test some simple invariants about
+``CashFlow``.
+
+To run the complete test you can open
+``example-code/src/integration-test/kotlin/net/corda/docs/IntegrationTestingTutorial.kt``
+from IntelliJ and run the test, or alternatively use gradle:
+
+
+.. sourcecode:: bash
+
+ # Run example-code integration tests
+ ./gradlew docs/source/example-code:integrationTest -i
diff --git a/docs/build/html/_sources/where-to-start.txt b/docs/build/html/_sources/where-to-start.txt
deleted file mode 100644
index 123517639a..0000000000
--- a/docs/build/html/_sources/where-to-start.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-.. highlight:: kotlin
-.. raw:: html
-
-
-
-
-Where to start
-==============
-
-So you want to start experimenting with Corda. Where do you begin? Although Corda is still very early and missing
-large chunks of important functionality, this article will hopefully put you on the right place.
-
-An experiment with Corda is started by picking a *scenario* and then turning it into a *demo*. It is important to
-understand that at this stage in its life, Corda does not have a single unified server that loads everything
-dynamically. Instead, Corda provides an object oriented API which is then used by a *driver* program, with one driver
-per scenario. You can see the existing demo apps in action by :doc:`running-the-demos`.
-
-In future this design will change and there will be a single server that does everything. But for now, there isn't.
-
-A scenario contains:
-
-* A set of participating nodes and their roles.
-* Some business process you wish to automate (typically simplified from the real thing).
-* The smart contracts and flows that will automate that process.
-
-It may also specify a REST/JSON API, but this is optional.
-
-Here's are two example scenarios included in the box:
-
-1. Bank A wishes to buy some commercial paper in return for cash. Bank B wants to issue and sell some CP to Bank A.
- This is probably the simplest scenario in Corda that still does something interesting. It's like the buttered
- bread of finance.
-2. Bank A and Bank B want to enter into an interest rate swap and evolve it through its lifecycle.
-
-The process of implementing a scenario looks like this:
-
-1. First of all, design your states and transaction types. Read about the :doc:`data-model` if you aren't sure what that
- involves.
-2. Now, create a new file in the finance/src/main directory. You can either any JVM language but we only provide examples
- in Java and Kotlin. The file should define your state classes and your contract class, which will define the
- allowable state transitions. You can learn how these are constructed by reading the ":doc:`tutorial-contract`" tutorial.
-3. It isn't enough to just define static data and logic that controls what's allowed. You must also orchestrate the
- business process. This is the job of the flow framework. You can learn how to author these by reading
- ":doc:`flow-state-machines`".
-4. Once you have created your states, transactions and flows, you need a way to demonstrate them (outside of the
- unit tests, of course). This topic is covered below.
-
-The trader demo
----------------
-
-Until Corda has a unified server that can dynamically load every aspect of an application (i.e. software implementing a scenario),
-we have to do a bit of copy/paste wiring ourselves.
-
-The trader demo is a good place to start understanding this, which can be found in src/main/kotlin/demos/TraderDemo.kt
-
-The idea of a driver program is that it starts a node in one of several roles, according to a command line flag. The
-driver may step through some pre-programmed scenario automatically or it may register an API to be exported via HTTP.
-You would then have to drive the node externally for your demo.
-
-The best way to create your own scenario is not to write a driver from scratch but to copy the existing trader or IRS
-demo drivers and then customise them, as much of the code would end up being shared (like for command line parsing).
-
-Things you will want to adjust:
-
-1. The name of the grouping directory each node role will create its private directory under.
-2. The demo flows that just wrap the real business process in some kind of fake trading logic.
-
-The IRS driver program registers REST APIs, but as this is seriously in flux right now and the APIs will change a lot,
-we do not recommend you try this as part of your initial explorations unless you are feeling adventurous.
\ No newline at end of file
diff --git a/docs/build/html/_static/css/custom.css b/docs/build/html/_static/css/custom.css
index d680f9cc32..7dfbdc74cf 100644
--- a/docs/build/html/_static/css/custom.css
+++ b/docs/build/html/_static/css/custom.css
@@ -1,12 +1,15 @@
@import "theme.css";
+
/* Highlights */
.highlight .k,
.highlight .kd {
- color: #263673;
+ color: #263673;
}
- /* Text */
+
+/* Text */
+
body,
h1,
h2,
@@ -16,106 +19,108 @@ h4,
h5,
h6,
legend,
-input{
- color:#010101;
- letter-spacing:0.3px
+input {
+ color: #010101;
+ letter-spacing: 0.3px
}
p {
- font-size: 100%; /* Get rid of RTD rule that assumes nobody changes their browser font size */
-}
-
- /* Links */
-a{
- color: #263673
-}
-a:hover{
- color: #005CAB
-}
-a:visited{
- color:#ADAFB3
-}
-
- /* Side navigation bar */
-
-.wy-side-nav-search{
- background-color:#010101;
-
-}
-
-.wy-side-nav-search a.icon-home{
- color:transparent;
- background-image:url('../images/fg002_corda_w3.png');
- background-repeat:no-repeat;
- background-size: Auto 20px;
- background-position:center top;
- background-origin:content box;
- height:20px;
- width:100%
-
-}
-
-.wy-side-nav-search input[type=text]{
- border-radius:5px
-}
-
-.wy-menu-vertical a:hover{
- background-color: #ADAFB3;
- color:#FFF
-}
-
-.wy-nav-content{
- background-color:#fff
- max-width: 1000px;
-}
-
-.wy-nav-side{
- background:#010101
-}
- /* Navigation headers */
-.rst-content tt.literal, .rst-content tt.literal, .rst-content code.literal
-{
- color:#EC1D24;
- text-transform:none;
+ font-size: 100%; /* Get rid of RTD rule that assumes nobody changes their browser font size */
}
-.wy-menu-vertical header, .wy-menu-vertical p.caption
-{
- font-size:1.1em;
- color:#EC1D24;
- text-transform:none;
- background-color: #3C3C3E;
- padding: 0 0.5em;
- margin-top: 0.5em;
+/* Links */
+
+a {
+ color: #263673
}
- /* Code snippets */
+a:hover {
+ color: #005CAB
+}
+
+a:visited {
+ color: #ADAFB3
+}
+
+
+/* Side navigation bar */
+
+.wy-side-nav-search {
+ background-color: #252627;
+}
+
+.wy-side-nav-search a.icon-home {
+ color: transparent;
+ background-image: url('../images/fg002_corda_w3.png');
+ background-repeat: no-repeat;
+ background-size: Auto 20px;
+ background-position: center top;
+ background-origin: content box;
+ height: 20px;
+ width: 100%
+}
+
+.wy-side-nav-search input[type=text] {
+ border-radius: 5px
+}
+
+.wy-menu-vertical a:hover {
+ background-color: #ADAFB3;
+ color: #FFF
+}
+
+.wy-nav-content {
+ background-color: #fff max-width: 1000px;
+}
+
+.wy-nav-side {
+ background-color: #252627;
+}
+
+
+/* Navigation headers */
+
+.rst-content tt.literal,
+.rst-content tt.literal,
+.rst-content code.literal {
+ color: #EC1D24;
+ text-transform: none;
+}
+
+.wy-menu-vertical header,
+.wy-menu-vertical p.caption {
+ color: #EC1D24;
+}
+
+
+/* Code snippets */
.codesnippet-widgets {
- min-width: 100%;
- display: block;
- background: #005CAB;
- color: white;
- padding: 10px 0;
- margin: 0 0 -1px 0;
+ min-width: 100%;
+ display: block;
+ background: #005CAB;
+ color: white;
+ padding: 10px 0;
+ margin: 0 0 -1px 0;
}
.codesnippet-widgets > span {
- padding: 10px;
- cursor: pointer;
+ padding: 10px;
+ cursor: pointer;
}
.codesnippet-widgets > .current {
- background: #263673;
+ background: #263673;
}
.codeset > .highlight-java {
- display: none;
+ display: none;
}
/* Notification boxes */
+
.wy-alert.wy-alert-warning .wy-alert-title,
.rst-content .wy-alert-warning.note .wy-alert-title,
.rst-content .attention .wy-alert-title,
@@ -132,16 +137,16 @@ a:visited{
.rst-content .wy-alert.wy-alert-warning .admonition-title,
.rst-content .wy-alert-warning.note .admonition-title,
.rst-content .attention .admonition-title,
-.rst-content .caution .admonition-title, .rst-content
-.wy-alert-warning.danger .admonition-title,
+.rst-content .caution .admonition-title,
+.rst-content .wy-alert-warning.danger .admonition-title,
.rst-content .wy-alert-warning.error .admonition-title,
.rst-content .wy-alert-warning.hint .admonition-title,
.rst-content .wy-alert-warning.important .admonition-title,
.rst-content .wy-alert-warning.tip .admonition-title,
.rst-content .warning .admonition-title,
.rst-content .wy-alert-warning.seealso .admonition-title,
-.rst-content .admonition-todo .admonition-title{
- background-color: #263673
+.rst-content .admonition-todo .admonition-title {
+ background-color: #263673
}
.wy-alert,
@@ -155,7 +160,22 @@ a:visited{
.rst-content .tip,
.rst-content .warning,
.rst-content .seealso,
-.rst-content .admonition-todo{
- background-color:#d9e5ef
+.rst-content .admonition-todo {
+ background-color: #d9e5ef
}
+
+/* Mobile view */
+
+.wy-nav-top {
+ background-color: #252627;
+}
+
+.wy-nav-top a {
+ color: transparent;
+ background-image: url('../images/fg002_corda_w3.png');
+ background-repeat: no-repeat;
+ background-size: Auto 19px;
+ background-position: center top;
+ background-origin: content box;
+}
diff --git a/docs/build/html/api/net.corda.client.mock/-event-generator/client-to-service-command-generator.html b/docs/build/html/api/net.corda.client.mock/-event-generator/client-to-service-command-generator.html
deleted file mode 100644
index 09c9117879..0000000000
--- a/docs/build/html/api/net.corda.client.mock/-event-generator/client-to-service-command-generator.html
+++ /dev/null
@@ -1,15 +0,0 @@
-
-
-EventGenerator.clientToServiceCommandGenerator -
-
-
-
-net.corda.client.mock / EventGenerator / clientToServiceCommandGenerator
-
-
Builds the PublicKeyTree.Node. If threshold is not specified, it will default to
-the size of the children, effectively generating an "N of N" requirement.
Builds the PublicKeyTree.Node. If threshold is not specified, it will default to
-the size of the children, effectively generating an "N of N" requirement.
Represents a node in the PublicKeyTree. It maintains a list of child nodes – sub-trees, and associated
-weights carried by child node signatures.
-
The threshold specifies the minimum total weight required (in the simple case – the minimum number of child
-signatures required) to satisfy the public key sub-tree rooted at this node.
Represents a node in the PublicKeyTree. It maintains a list of child nodes – sub-trees, and associated
-weights carried by child node signatures.
-
The threshold specifies the minimum total weight required (in the simple case – the minimum number of child
-signatures required) to satisfy the public key sub-tree rooted at this node.
A tree data structure that enables the representation of composite public keys.
-
In the simplest case it may just contain a single node encapsulating a PublicKey – a Leaf.
-
For more complex scenarios, such as "Both Alice and Bob need to sign to consume a state S", we can represent
-the requirement by creating a tree with a root Node, and Alice and Bob as children – Leafs.
-The root node would specify weights for each of its children and a threshold – the minimum total weight required
-(e.g. the minimum number of child signatures required) to satisfy the tree signature requirement.
-
Using these constructs we can express e.g. 1 of N (OR) or N of N (AND) signature requirements. By nesting we can
-create multi-level requirements such as "either the CEO or 3 of 5 of his assistants need to sign".
A Map with an entry for each consumed protocol used by the webAPIs.
-The key of each map entry should contain the ProtocolLogic class name.
-The associated map values are the union of all concrete class names passed to the protocol constructor.
-Standard java.lang.* and kotlin.* types do not need to be included explicitly.
-This is used to extend the white listed protocols that can be initiated from the ServiceHub invokeProtocolAsync method.
-
-abstractfun registerProtocolInitiator(markerClass:KClass<*>, protocolFactory:(Party)->ProtocolLogic<*>): Unit
-
Register the protocol factory we wish to use when a initiating party attempts to communicate with us. The
-registration is done against a marker KClass which is sent in the session handshake by the other party. If this
-marker class has been registered then the corresponding factory will be used to create the protocol which will
-communicate with the other side. If there is no mapping then the session attempt is rejected.
-
Parameters
-
-markerClass - The marker KClass present in a session initiation attempt, which is a 1:1 mapping to a Class
-using the ::class construct. Conventionally this is a ProtocolLogic subclass, however any class can
-be used, with the default being the class of the initiating protocol. This enables the registration to be of the
-form: registerProtocolInitiator(InitiatorProtocol::class, ::InitiatedProtocol)
-
-
-protocolFactory - The protocol factory generating the initiated protocol.
-
-
-
-
diff --git a/docs/build/html/api/net.corda.core.node/-service-hub/invoke-protocol-async.html b/docs/build/html/api/net.corda.core.node/-service-hub/invoke-protocol-async.html
deleted file mode 100644
index b3c4762513..0000000000
--- a/docs/build/html/api/net.corda.core.node/-service-hub/invoke-protocol-async.html
+++ /dev/null
@@ -1,19 +0,0 @@
-
-
-ServiceHub.invokeProtocolAsync -
-
-
-
-net.corda.core.node / ServiceHub / invokeProtocolAsync
-
-
This is just some way to track what attachments need to be in the class loader, but may later include some app
-properties loaded from the attachments. And perhaps the authenticated user for an API call?
This is just some way to track what attachments need to be in the class loader, but may later include some app
-properties loaded from the attachments. And perhaps the authenticated user for an API call?
This is just some way to track what attachments need to be in the class loader, but may later include some app
-properties loaded from the attachments. And perhaps the authenticated user for an API call?
Validation of types is performed on the way in and way out in case this object is passed between JVMs which might have differing
-whitelists.
-
TODO: Ways to populate whitelist of "blessed" protocols per node/party
-TODO: Ways to populate argument types whitelist. Per node/party or global?
-TODO: Align with API related logic for passing in ProtocolLogic references (ProtocolRef)
-TODO: Actual support for AppContext / AttachmentsClassLoader
Validation of types is performed on the way in and way out in case this object is passed between JVMs which might have differing
-whitelists.
-
TODO: Ways to populate whitelist of "blessed" protocols per node/party
-TODO: Ways to populate argument types whitelist. Per node/party or global?
-TODO: Align with API related logic for passing in ProtocolLogic references (ProtocolRef)
-TODO: Actual support for AppContext / AttachmentsClassLoader
A sub-class of ProtocolLogic implements a protocol flow using direct, straight line blocking code. Thus you
-can write complex protocol logic in an ordinary fashion, without having to think about callbacks, restarting after
-a node crash, how many instances of your protocol there are running and so on.
-
Invoking the network will cause the call stack to be suspended onto the heap and then serialized to a database using
-the Quasar fibers framework. Because of this, if you need access to data that might change over time, you should
-request it just-in-time via the serviceHub property which is provided. Dont try and keep data you got from a
-service across calls to send/receive/sendAndReceive because the world might change in arbitrary ways out from
-underneath you, for instance, if the node is restarted or reconfigured
-
Additionally, be aware of what data you pin either via the stack or in your ProtocolLogic implementation. Very large
-objects or datasets will hurt performance by increasing the amount of data stored in each checkpoint.
-
If youd like to use another ProtocolLogic class as a component of your own, construct it on the fly and then pass
-it to the subProtocol method. It will return the result of that protocol when it completes.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
A sub-class of ProtocolLogic implements a protocol flow using direct, straight line blocking code. Thus you
-can write complex protocol logic in an ordinary fashion, without having to think about callbacks, restarting after
-a node crash, how many instances of your protocol there are running and so on.
-
Invoking the network will cause the call stack to be suspended onto the heap and then serialized to a database using
-the Quasar fibers framework. Because of this, if you need access to data that might change over time, you should
-request it just-in-time via the serviceHub property which is provided. Dont try and keep data you got from a
-service across calls to send/receive/sendAndReceive because the world might change in arbitrary ways out from
-underneath you, for instance, if the node is restarted or reconfigured
-
Additionally, be aware of what data you pin either via the stack or in your ProtocolLogic implementation. Very large
-objects or datasets will hurt performance by increasing the amount of data stored in each checkpoint.
-
If youd like to use another ProtocolLogic class as a component of your own, construct it on the fly and then pass
-it to the subProtocol method. It will return the result of that protocol when it completes.
A sub-class of ProtocolLogic implements a protocol flow using direct, straight line blocking code. Thus you
-can write complex protocol logic in an ordinary fashion, without having to think about callbacks, restarting after
-a node crash, how many instances of your protocol there are running and so on.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
A protocol to be used for obtaining a signature from a NotaryService ascertaining the transaction
-timestamp is correct and none of its inputs have been used in another completed transaction.
This protocol is used to verify the validity of a transaction by recursively checking the validity of all the
-dependencies. Once a transaction is checked its inserted into local storage so it can be relayed and wont be
-checked again.
Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict
-if any of the input states have been previously committed.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
-
-fun <R>subProtocol(subLogic:ProtocolLogic<R>, shareParentSessions:Boolean= false): R
-
Invokes the given subprotocol by simply passing through this ProtocolLogics reference to the
-ProtocolStateMachine and then calling the call method.
-
Parameters
-
-shareParentSessions - In certain situations the need arises to use the same sessions the parent protocol has
-already established. However this also prevents the subprotocol from creating new sessions with those parties.
-For this reason the default value is false.
-
-
-
-
diff --git a/docs/build/html/api/net.corda.core.protocols/-protocol-logic/track.html b/docs/build/html/api/net.corda.core.protocols/-protocol-logic/track.html
deleted file mode 100644
index 18fd7c5b01..0000000000
--- a/docs/build/html/api/net.corda.core.protocols/-protocol-logic/track.html
+++ /dev/null
@@ -1,15 +0,0 @@
-
-
-ProtocolLogic.track -
-
-
-
-net.corda.core.protocols / ProtocolLogic / track
-
-
A ProtocolStateMachine instance is a suspendable fiber that delegates all actual logic to a ProtocolLogic instance.
-For any given flow there is only one PSM, even if that protocol invokes subprotocols.
-
These classes are created by the StateMachineManager when a new protocol is started at the topmost level. If
-a protocol invokes a sub-protocol, then it will pass along the PSM to the child. The call method of the topmost
-logic element gets to return the value that the entire state machine resolves to.
This is just some way to track what attachments need to be in the class loader, but may later include some app
-properties loaded from the attachments. And perhaps the authenticated user for an API call?
A sub-class of ProtocolLogic implements a protocol flow using direct, straight line blocking code. Thus you
-can write complex protocol logic in an ordinary fashion, without having to think about callbacks, restarting after
-a node crash, how many instances of your protocol there are running and so on.
A ProtocolStateMachine instance is a suspendable fiber that delegates all actual logic to a ProtocolLogic instance.
-For any given flow there is only one PSM, even if that protocol invokes subprotocols.
-
-
diff --git a/docs/build/html/api/net.corda.flows/-abstract-state-replacement-flow/-acceptor/index.html b/docs/build/html/api/net.corda.flows/-abstract-state-replacement-flow/-acceptor/index.html
index 62b2362eaf..ae3482b3e4 100644
--- a/docs/build/html/api/net.corda.flows/-abstract-state-replacement-flow/-acceptor/index.html
+++ b/docs/build/html/api/net.corda.flows/-abstract-state-replacement-flow/-acceptor/index.html
@@ -130,8 +130,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-abstract-state-replacement-flow/-instigator/index.html b/docs/build/html/api/net.corda.flows/-abstract-state-replacement-flow/-instigator/index.html
index 194c97332b..bbcd10bf4d 100644
--- a/docs/build/html/api/net.corda.flows/-abstract-state-replacement-flow/-instigator/index.html
+++ b/docs/build/html/api/net.corda.flows/-abstract-state-replacement-flow/-instigator/index.html
@@ -133,8 +133,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-broadcast-transaction-flow/index.html b/docs/build/html/api/net.corda.flows/-broadcast-transaction-flow/index.html
index 26122ec185..12c984bbd7 100644
--- a/docs/build/html/api/net.corda.flows/-broadcast-transaction-flow/index.html
+++ b/docs/build/html/api/net.corda.flows/-broadcast-transaction-flow/index.html
@@ -140,8 +140,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-cash-flow/index.html b/docs/build/html/api/net.corda.flows/-cash-flow/index.html
index ae63253e00..6b634dacc9 100644
--- a/docs/build/html/api/net.corda.flows/-cash-flow/index.html
+++ b/docs/build/html/api/net.corda.flows/-cash-flow/index.html
@@ -103,8 +103,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-fetch-data-flow/index.html b/docs/build/html/api/net.corda.flows/-fetch-data-flow/index.html
index d2db1e192d..d7747a3355 100644
--- a/docs/build/html/api/net.corda.flows/-fetch-data-flow/index.html
+++ b/docs/build/html/api/net.corda.flows/-fetch-data-flow/index.html
@@ -179,8 +179,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-notary-flow/-service/index.html b/docs/build/html/api/net.corda.flows/-notary-flow/-service/index.html
index 5a7011870a..3ade5fe2a3 100644
--- a/docs/build/html/api/net.corda.flows/-notary-flow/-service/index.html
+++ b/docs/build/html/api/net.corda.flows/-notary-flow/-service/index.html
@@ -143,8 +143,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-resolve-transactions-flow/index.html b/docs/build/html/api/net.corda.flows/-resolve-transactions-flow/index.html
index ac8b4e704b..8d7b952e5b 100644
--- a/docs/build/html/api/net.corda.flows/-resolve-transactions-flow/index.html
+++ b/docs/build/html/api/net.corda.flows/-resolve-transactions-flow/index.html
@@ -139,8 +139,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-two-party-deal-flow/-primary/index.html b/docs/build/html/api/net.corda.flows/-two-party-deal-flow/-primary/index.html
index fed98421a0..b4810fa25a 100644
--- a/docs/build/html/api/net.corda.flows/-two-party-deal-flow/-primary/index.html
+++ b/docs/build/html/api/net.corda.flows/-two-party-deal-flow/-primary/index.html
@@ -200,8 +200,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-two-party-deal-flow/-secondary/index.html b/docs/build/html/api/net.corda.flows/-two-party-deal-flow/-secondary/index.html
index 6626508ce6..059e3f715e 100644
--- a/docs/build/html/api/net.corda.flows/-two-party-deal-flow/-secondary/index.html
+++ b/docs/build/html/api/net.corda.flows/-two-party-deal-flow/-secondary/index.html
@@ -164,8 +164,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-two-party-trade-flow/-buyer/index.html b/docs/build/html/api/net.corda.flows/-two-party-trade-flow/-buyer/index.html
index 2297fa134a..325f367c6e 100644
--- a/docs/build/html/api/net.corda.flows/-two-party-trade-flow/-buyer/index.html
+++ b/docs/build/html/api/net.corda.flows/-two-party-trade-flow/-buyer/index.html
@@ -145,8 +145,8 @@ will do as long as the other side registers with it.
diff --git a/docs/build/html/api/net.corda.flows/-two-party-trade-flow/-seller/index.html b/docs/build/html/api/net.corda.flows/-two-party-trade-flow/-seller/index.html
index d873ad3ab8..454dad97f7 100644
--- a/docs/build/html/api/net.corda.flows/-two-party-trade-flow/-seller/index.html
+++ b/docs/build/html/api/net.corda.flows/-two-party-trade-flow/-seller/index.html
@@ -163,8 +163,8 @@ will do as long as the other side registers with it.
This method would not return until the protocol is finished (hence the "Sync").
-
Longer term wed add an Async version that returns some kind of ProtocolInvocationRef that could be queried and
-would appear on some kind of event message that is broadcast informing of progress.
-
-abstractfun provideProtocolResponse(protocol:ProtocolInstanceRef, choice:SecureHash, args:Map<String,Any?>): Unit
-
Provide the response that a protocol is waiting for.
-
Parameters
-
-protocol - Should refer to a previously supplied ProtocolRequiringAttention.
-
-
-stepId - Which step of the protocol are we referring too.
-
-
-choice - Should be one of the choices presented in the ProtocolRequiringAttention.
-
-
-args - Any arguments required.
-
-
-
-
diff --git a/docs/build/html/api/net.corda.node.api/-protocol-class-ref/-init-.html b/docs/build/html/api/net.corda.node.api/-protocol-class-ref/-init-.html
deleted file mode 100644
index 04b34ef4e5..0000000000
--- a/docs/build/html/api/net.corda.node.api/-protocol-class-ref/-init-.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-ProtocolClassRef.<init> -
-
-
-
-net.corda.node.api / ProtocolClassRef / <init>
-
-
This method would not return until the protocol is finished (hence the "Sync").
-
Longer term wed add an Async version that returns some kind of ProtocolInvocationRef that could be queried and
-would appear on some kind of event message that is broadcast informing of progress.
Provide the response that a protocol is waiting for.
-
Parameters
-
-protocol - Should refer to a previously supplied ProtocolRequiringAttention.
-
-
-stepId - Which step of the protocol are we referring too.
-
-
-choice - Should be one of the choices presented in the ProtocolRequiringAttention.
-
-
-args - Any arguments required.
-
-
-
-
diff --git a/docs/build/html/api/net.corda.node.internal/-abstract-node/protocol-logic-factory.html b/docs/build/html/api/net.corda.node.internal/-abstract-node/protocol-logic-factory.html
deleted file mode 100644
index ac8c6661e6..0000000000
--- a/docs/build/html/api/net.corda.node.internal/-abstract-node/protocol-logic-factory.html
+++ /dev/null
@@ -1,15 +0,0 @@
-
-
-AbstractNode.protocolLogicFactory -
-
-
-
-net.corda.node.internal / AbstractNode / protocolLogicFactory
-
-
TODO: borrowing this method from service manager work in another branch. Its required to avoid circular dependency
-between SMM and the scheduler. That particular problem should also be resolved by the service manager work
-itself, at which point this method would not be needed (by the scheduler).
-
-
-
-
diff --git a/docs/build/html/api/net.corda.node.services.events/-node-scheduler-service/-run-scheduled/index.html b/docs/build/html/api/net.corda.node.services.events/-node-scheduler-service/-run-scheduled/index.html
index d6e337152e..8d20afe1c7 100644
--- a/docs/build/html/api/net.corda.node.services.events/-node-scheduler-service/-run-scheduled/index.html
+++ b/docs/build/html/api/net.corda.node.services.events/-node-scheduler-service/-run-scheduled/index.html
@@ -115,8 +115,8 @@ will do as long as the other side registers with it.
These allow type safe invocations of protocols from Kotlin, e.g.:
-
val rpc: CordaRPCOps = (..)
-rpc.startProtocol(::ResolveTransactionsProtocol, setOf(), aliceIdentity)
-
Note that the passed in constructor function is only used for unification of other type parameters and reification of
-the Class instance of the protocol. This could be changed to use the constructor function directly.
-
-val SUBSCRIPTION_PROTOCOL_TOPIC: String
-
-
-
-
diff --git a/docs/build/html/api/net.corda.node.services.persistence/-data-vending/-service/-notify-transaction-handler/index.html b/docs/build/html/api/net.corda.node.services.persistence/-data-vending/-service/-notify-transaction-handler/index.html
index b247856190..5e19769f54 100644
--- a/docs/build/html/api/net.corda.node.services.persistence/-data-vending/-service/-notify-transaction-handler/index.html
+++ b/docs/build/html/api/net.corda.node.services.persistence/-data-vending/-service/-notify-transaction-handler/index.html
@@ -111,8 +111,8 @@ will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Check the state change proposal to confirm that its acceptable to this node. Rules for verification depend
-on the change proposed, and may further depend on the node itself (for example configuration). The
-proposal is returned if acceptable, otherwise an exception is thrown.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Check the state change proposal to confirm that its acceptable to this node. Rules for verification depend
-on the change proposed, and may further depend on the node itself (for example configuration). The
-proposal is returned if acceptable, otherwise an exception is thrown.
Abstract protocol to be used for replacing one state with another, for example when changing the notary of a state.
-Notably this requires a one to one replacement of states, states cannot be split, merged or issued as part of these
-protocols.
-
The Instigator assembles the transaction for state replacement and sends out change proposals to all participants
-(Acceptor) of that state. If participants agree to the proposed change, they each sign the transaction.
-Finally, Instigator sends the transaction containing all signatures back to each participant so they can record it and
-use the new updated state for future transactions.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Abstract protocol to be used for replacing one state with another, for example when changing the notary of a state.
-Notably this requires a one to one replacement of states, states cannot be split, merged or issued as part of these
-protocols.
-
The Instigator assembles the transaction for state replacement and sends out change proposals to all participants
-(Acceptor) of that state. If participants agree to the proposed change, they each sign the transaction.
-Finally, Instigator sends the transaction containing all signatures back to each participant so they can record it and
-use the new updated state for future transactions.
Abstract protocol to be used for replacing one state with another, for example when changing the notary of a state.
-Notably this requires a one to one replacement of states, states cannot be split, merged or issued as part of these
-protocols.
Notify all involved parties about a transaction, including storing a copy. Normally this would be called via
-FinalityProtocol.
-
Parameters
-
-notarisedTransaction - transaction which has been notarised (if needed) and is ready to notify nodes about.
-
-
-participants - a list of participants involved in the transaction.
-
Return
-a list of participants who were successfully notified of the transaction.
Notify all involved parties about a transaction, including storing a copy. Normally this would be called via
-FinalityProtocol.
-
Parameters
-
-notarisedTransaction - transaction which has been notarised (if needed) and is ready to notify nodes about.
-
-
-participants - a list of participants involved in the transaction.
-
Return
-a list of participants who were successfully notified of the transaction.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
-
-amount - the amount of currency to issue on to the ledger.
-
-
-issueRef - the reference to specify on the issuance, used to differentiate pools of cash. Convention is
-to use the single byte "0x01" as a default.
-
-
-recipient - the party to issue the cash to.
-
-
-notary - the notary to use for this transaction.
-
-
-
-
diff --git a/docs/build/html/api/net.corda.protocols/-cash-command/-issue-cash/amount.html b/docs/build/html/api/net.corda.protocols/-cash-command/-issue-cash/amount.html
deleted file mode 100644
index 156250cb4e..0000000000
--- a/docs/build/html/api/net.corda.protocols/-cash-command/-issue-cash/amount.html
+++ /dev/null
@@ -1,15 +0,0 @@
-
-
-CashCommand.IssueCash.amount -
-
-
-
-net.corda.protocols / CashCommand / IssueCash / amount
-
-
-
-amount - the amount of currency to issue on to the ledger.
-
-
-issueRef - the reference to specify on the issuance, used to differentiate pools of cash. Convention is
-to use the single byte "0x01" as a default.
-
-
-recipient - the party to issue the cash to.
-
-
-notary - the notary to use for this transaction.
-
-
-
State indicating the action undertaken failed, either directly (it is not something which requires a
-state machine), or before a state machine was started.
State indicating the action undertaken failed, either directly (it is not something which requires a
-state machine), or before a state machine was started.
State indicating the action undertaken failed, either directly (it is not something which requires a
-state machine), or before a state machine was started.
-
-transaction - the transaction created as a result, in the case where the protocol completed successfully.
-
-
-
-
diff --git a/docs/build/html/api/net.corda.protocols/-cash-protocol-result/-success/id.html b/docs/build/html/api/net.corda.protocols/-cash-protocol-result/-success/id.html
deleted file mode 100644
index a00917a1e2..0000000000
--- a/docs/build/html/api/net.corda.protocols/-cash-protocol-result/-success/id.html
+++ /dev/null
@@ -1,15 +0,0 @@
-
-
-CashProtocolResult.Success.id -
-
-
-
-net.corda.protocols / CashProtocolResult / Success / id
-
-
State indicating the action undertaken failed, either directly (it is not something which requires a
-state machine), or before a state machine was started.
State indicating the action undertaken failed, either directly (it is not something which requires a
-state machine), or before a state machine was started.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Given a set of hashes either loads from from local storage or requests them from the other peer. Downloaded
-attachments are saved to local storage automatically.
Given a set of hashes either loads from from local storage or requests them from the other peer. Downloaded
-attachments are saved to local storage automatically.
Given a set of hashes either loads from from local storage or requests them from the other peer. Downloaded
-attachments are saved to local storage automatically.
An abstract protocol for fetching typed data from a remote peer.
-
Given a set of hashes (IDs), either loads them from local disk or asks the remote peer to provide them.
-
A malicious response in which the data provided by the remote peer does not hash to the requested hash results in
-DownloadedVsRequestedDataMismatch being thrown. If the remote peer doesnt have an entry, it results in a
-HashNotFound exception being thrown.
-
By default this class does not insert data into any local database, if you want to do that after missing items were
-fetched then override maybeWriteToDisk. You must override load. If the wire type is not the same as the
-ultimate type, you must also override convert.
-
-
-
Parameters
-
-T - The ultimate type of the data being fetched.
-
-
-W - The wire type of the data being fetched, for when it isnt the same as the ultimate type.
-
-
-
-
diff --git a/docs/build/html/api/net.corda.protocols/-fetch-data-protocol/-request/-init-.html b/docs/build/html/api/net.corda.protocols/-fetch-data-protocol/-request/-init-.html
deleted file mode 100644
index 3eb8647b5c..0000000000
--- a/docs/build/html/api/net.corda.protocols/-fetch-data-protocol/-request/-init-.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
-FetchDataProtocol.Request.<init> -
-
-
-
-net.corda.protocols / FetchDataProtocol / Request / <init>
-
-
An abstract protocol for fetching typed data from a remote peer.
-
Given a set of hashes (IDs), either loads them from local disk or asks the remote peer to provide them.
-
A malicious response in which the data provided by the remote peer does not hash to the requested hash results in
-DownloadedVsRequestedDataMismatch being thrown. If the remote peer doesnt have an entry, it results in a
-HashNotFound exception being thrown.
-
By default this class does not insert data into any local database, if you want to do that after missing items were
-fetched then override maybeWriteToDisk. You must override load. If the wire type is not the same as the
-ultimate type, you must also override convert.
-
-
-
Parameters
-
-T - The ultimate type of the data being fetched.
-
-
-W - The wire type of the data being fetched, for when it isnt the same as the ultimate type.
-
-
-
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Given a set of hashes either loads from from local storage or requests them from the other peer. Downloaded
-attachments are saved to local storage automatically.
Given a set of tx hashes (IDs), either loads them from local disk or asks the remote peer to provide them.
-
A malicious response in which the data provided by the remote peer does not hash to the requested hash results in
-FetchDataProtocol.DownloadedVsRequestedDataMismatch being thrown. If the remote peer doesnt have an entry, it
-results in a FetchDataProtocol.HashNotFound exception. Note that returned transactions are not inserted into
-the database, because its up to the caller to actually verify the transactions are valid.
Given a set of tx hashes (IDs), either loads them from local disk or asks the remote peer to provide them.
-
A malicious response in which the data provided by the remote peer does not hash to the requested hash results in
-FetchDataProtocol.DownloadedVsRequestedDataMismatch being thrown. If the remote peer doesnt have an entry, it
-results in a FetchDataProtocol.HashNotFound exception. Note that returned transactions are not inserted into
-the database, because its up to the caller to actually verify the transactions are valid.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
For example, if the proposed new notary has the same behaviour (e.g. both are non-validating)
-and is also in a geographically convenient location we can just automatically approve the change.
-TODO: In more difficult cases this should call for human attention to manually verify and approve the proposal
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
A protocol to be used for changing a states Notary. This is required since all input states to a transaction
-must point to the same notary.
-
The Instigator assembles the transaction for notary replacement and sends out change proposals to all participants
-(Acceptor) of that state. If participants agree to the proposed change, they each sign the transaction.
-Finally, Instigator sends the transaction containing all signatures back to each participant so they can record it and
-use the new updated state for future transactions.
A protocol to be used for obtaining a signature from a NotaryService ascertaining the transaction
-timestamp is correct and none of its inputs have been used in another completed transaction.
-
Exceptions
-
-NotaryException - in case the any of the inputs to the transaction have been consumed
-by another transaction or the timestamp is invalid.
-
-
-
-
diff --git a/docs/build/html/api/net.corda.protocols/-notary-protocol/-client/-r-e-q-u-e-s-t-i-n-g.html b/docs/build/html/api/net.corda.protocols/-notary-protocol/-client/-r-e-q-u-e-s-t-i-n-g.html
deleted file mode 100644
index c6cbccea2c..0000000000
--- a/docs/build/html/api/net.corda.protocols/-notary-protocol/-client/-r-e-q-u-e-s-t-i-n-g.html
+++ /dev/null
@@ -1,42 +0,0 @@
-
-
-NotaryProtocol.Client.REQUESTING -
-
-
-
-net.corda.protocols / NotaryProtocol / Client / REQUESTING
-
-
A protocol to be used for obtaining a signature from a NotaryService ascertaining the transaction
-timestamp is correct and none of its inputs have been used in another completed transaction.
-
Exceptions
-
-NotaryException - in case the any of the inputs to the transaction have been consumed
-by another transaction or the timestamp is invalid.
-
-
-
A protocol to be used for obtaining a signature from a NotaryService ascertaining the transaction
-timestamp is correct and none of its inputs have been used in another completed transaction.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict
-if any of the input states have been previously committed.
-
Extend this class, overriding beforeCommit to add custom transaction processing/validation logic.
-
TODO: the notary service should only be able to see timestamp commands and inputs
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).
Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict
-if any of the input states have been previously committed.
-
Extend this class, overriding beforeCommit to add custom transaction processing/validation logic.
-
TODO: the notary service should only be able to see timestamp commands and inputs
Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict
-if any of the input states have been previously committed.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
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).
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
A notary commit protocol 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.
A protocol to be used for obtaining a signature from a NotaryService ascertaining the transaction
-timestamp is correct and none of its inputs have been used in another completed transaction.
Checks that the timestamp command is valid (if present) and commits the input state, or returns a conflict
-if any of the input states have been previously committed.
This protocol is used to verify the validity of a transaction by recursively checking the validity of all the
-dependencies. Once a transaction is checked its inserted into local storage so it can be relayed and wont 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 isnt enough to put into the local database, so only the dependencies are checked and inserted. This way
-to use the protocol is helpful when resolving and verifying a finished but partially signed transaction.
-
The protocol returns a list of verified LedgerTransaction objects, in a depth-first order.
This protocol is used to verify the validity of a transaction by recursively checking the validity of all the
-dependencies. Once a transaction is checked its inserted into local storage so it can be relayed and wont 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 isnt enough to put into the local database, so only the dependencies are checked and inserted. This way
-to use the protocol is helpful when resolving and verifying a finished but partially signed transaction.
-
The protocol returns a list of verified LedgerTransaction objects, in a depth-first order.
This protocol is used to verify the validity of a transaction by recursively checking the validity of all the
-dependencies. Once a transaction is checked its inserted into local storage so it can be relayed and wont be
-checked again.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Primary at the end sends the signed tx to all the regulator parties. This a seperate workflow which needs a
-sepearate session with the regulator. This interface is used to do that in Primary.getCounterpartyMarker.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Primary at the end sends the signed tx to all the regulator parties. This a seperate workflow which needs a
-sepearate session with the regulator. This interface is used to do that in Primary.getCounterpartyMarker.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
Provides access to big, heavy classes that may be reconstructed from time to time, e.g. across restarts. It is
-only available once the protocol has started, which means it cannnot be accessed in the constructor. Either
-access this lazily or from inside call.
Return the marker Class which party has used to register the counterparty protocol that is to execute on the
-other side. The default implementation returns the class object of this ProtocolLogic, but any Class instance
-will do as long as the other side registers with it.
Override this to provide a ProgressTracker. If one is provided and stepped, the framework will do something
-helpful with the progress reports. If this protocol is invoked as a sub-protocol of another, then the
-tracker will be made a child of the current step in the parent. If its null, this protocol doesnt track
-progress.
-
Note that this has to return a tracker before the protocol is invoked. You cant change your mind half way
-through.
This asset trading protocol implements a "delivery vs payment" type swap. It has two parties (B and S for buyer
-and seller) and the following steps:
-
S sends the StateAndRef pointing to what they want to sell to B, along with info about the price they require
-B to pay. For example this has probably been agreed on an exchange.
-
B sends to S a SignedTransaction that includes the state as input, Bs cash as input, the state with the new
-owner key as output, and any change cash as output. It contains a single signature from B but isnt valid because
-it lacks a signature from S authorising movement of the asset.
-
S signs it and hands the now finalised SignedWireTransaction back to B.
-
Assuming no malicious termination, they both end the protocol being in posession of a valid, signed transaction
-that represents an atomic asset swap.
-
Note that its the seller who initiates contact with the buyer, not vice-versa as you might imagine.
-
To initiate the protocol, use either the runBuyer or runSeller methods, depending on which side of the trade
-your node is taking. These methods return a future which will complete once the trade is over and a fully signed
-transaction is available: you can either block your thread waiting for the protocol to complete by using
-ListenableFuture.get or more usefully, register a callback that will be invoked when the time comes.
-
To see an example of how to use this class, look at the unit tests.
A notary commit protocol 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.
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).
A notary commit protocol 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.
A notary commit protocol 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.
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).
Abstract protocol to be used for replacing one state with another, for example when changing the notary of a state.
-Notably this requires a one to one replacement of states, states cannot be split, merged or issued as part of these
-protocols.
Given a set of hashes either loads from from local storage or requests them from the other peer. Downloaded
-attachments are saved to local storage automatically.
This protocol is used to verify the validity of a transaction by recursively checking the validity of all the
-dependencies. Once a transaction is checked its inserted into local storage so it can be relayed and wont be
-checked again.
A notary commit protocol 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.
A clause is a small building block for assembling contract verification logic, reusable and ready to test in separation.
+To see clauses in action go to: Writing a contract using clauses.
+Let’s take a look at a simplified structure of the Clause class:
Basic clause structure contains two important components: requiredCommands and verify function.
+A clause is triggered when all requiredCommands are present in transaction’s command set (opposite inclusion doesn’t have to hold).
+Then the verify function is run, which checks if transaction meets conditions specified by this clause. Verification
+is no different than normal contract verification but using clauses it’s split into smaller generic code blocks with single verify method.
+
When writing a contract you need to override the contract’s verify function which should call verifyClause. See: Commercial paper class.
+
+
Note
+
A clause verify function returns the set of processed commands, at the end of verifyClause execution
+there is a check if all of transaction’s commands were matched. If not then an exception is raised. This is done to
+enforce that spurious commands cannot be included in a transaction, ensuring that the transaction is as clear as
+possible. As an example imagine a transaction with two commands: Move and Issue included, with verification written
+using FirstComposition on clauses that require single command set. Thus only one of transaction’s commands will match
+leaving the second unprocessed. It should raise an error - we want to ensure that commands set is minimal to simplify
+analysis of intent of a transaction.
It takes transaction to be verified, and passes it along with a top-level clause and commands to the verifyClause
+function. As you can see above we have used FirstComposition which is a special type of clause, which extends the
+CompositeClause abstract class (in that particular case, it ensures that either Net or Group will run - for explanation see FirstComposition).
+It’s a type of clause that adds support for encapsulating multiple clauses and defines common behaviour for that composition.
+There is also a GroupClauseVerifier special clause, which specifies how to group transaction input/output states
+together and passes them to adequate clause for further processing.
One of the most important concepts of clauses - composition clauses which extend CompositeClause abstract class,
+providing a range of ways of assembling clauses together. They define a logic of verification execution specifying which clauses
+will be run.
There are certain types of clauses that are specialized in particular types of contracts (like AbstractIssue) or generally
+should be used as helpers in building parts of logic (the most important one is GroupClauseVerifier).
Groups input and output states according to groupStates function. Runs the top-level clause verification on each
+group in turn.
+
+
Short description:
+
GroupClauseVerifier wraps clause Cl1. After grouping relevant states together with groupStates into three groups
+Gr1, Gr2, Gr3 runs Cl1.verify(Gr1), Cl1.verify(Gr2), Cl1.verify(Gr3).
You need to extend GroupClauseVerifier clause and define groupStates function which takes transaction and returns
+grouped input and output states with a grouping key used for each group. Example from Obligation.kt contract:
Usually it’s convenient to use groupStates function defined on TransactionForContract class. Which given a type and a
+selector function, that returns a grouping key, associates inputs and outputs together so that they can be processed as one.
+The grouping key is any arbitrary object that can act as a map key (so must implement equals and hashCode).
Standardised clause for checking input/output balances of fungible assets. Requires that a
+Move command is provided, and errors if absent. Conserve amount clause can only be used on grouped states.
First function in constructor converts a list of states into an amount of the token. Must error if there are no states in the list.
+Second function converts a list of states into an amount of the token, and returns zero if there are no states in the list.
+Takes in an instance of the token definition for constructing the zero amount if needed.
Filter the states that are passed through to the wrapped clause, to restrict them to a specific type.
+
FilterOn narrows the scope of the states being verified.
+Let’s take a transaction with multiple cash states of different currencies, we want to run a clause that focuses
+on only GBP cash states rather than all cash states.
@@ -284,7 +296,7 @@ This is likely to change in a future release.
In the present implementation of the node we use Kryo to generate the on the wire representation of contracts states
or any other classes that form part of the RPC arguments or response. To avoid the RPC interface being wide open to all
classes on the classpath, Cordapps will currently have to register any classes or custom serialisers they require with Kryo
-if they are not one of those registered by default in RPCKryo via the plugin architecture. See Creating a CorDapp.
+if they are not one of those registered by default in RPCKryo via the plugin architecture. See CorDapps Background.
This will require some familiarity with Kryo. An example is shown in Client RPC API tutorial.
Warning
@@ -304,7 +316,7 @@ customisation point will either go away completely or change.
Next
- Previous
+ Previous
@@ -313,7 +325,7 @@ customisation point will either go away completely or change.
@@ -348,7 +360,7 @@ clocks at the US Naval Observatory. This time feed is extremely accurate and ava
-
A list of ServiceType id strings to be advertised to the NetworkMapService and thus be available when other nodes query the NetworkMapCache for supporting nodes. This can also include plugin services loaded from .jar files in the plugins folder.
+
A list of ServiceType id strings to be advertised to the NetworkMapService and thus be available when other nodes query the NetworkMapCache for supporting nodes. This can also include plugin services loaded from .jar files in the plugins folder. Optionally, a custom advertised service name can be provided by appending it to the service type id: "corda.notary.validating|NotaryA"
The Corda all-in-one corda.jar file is generated by the gradlebuildCordaJAR task and defaults to reading configuration from a node.conf file in the present working directory.
-This behaviour can be overidden using the --config-file command line option to target configuration files with different names, or different file location (relative paths are relative to the current working directory).
-Also, the --base-directory command line option alters the Corda node workspace location and if specified a node.conf configuration file is then expected in the root of the workspace.
-
The configuration file templates used for the gradledeployNodes task are to be found in the /config/dev folder. Also note that there is a basic set of defaults loaded from
-the built in resource file /node/src/main/resources/reference.conf of the :node gradle module. All properties in this can be overidden in the file configuration
-and for rarely changed properties this defaulting allows the property to be excluded from the configuration file.
Corda uses the Typesafe configuration library to parse the configuration see the typesafe config on Github the format of the configuration files can be simple JSON, but for the more powerful substitution features
-uses HOCON format see HOCON documents
This specifies the node workspace folder either as an absolute path, or relative to the current working directory. It can be overidden by the --base-directory command line option, in which case the the value in the file is ignored and a node.conf file is expected in that workspace directory as the configuration source.
-
-
-
myLegalName:
The legal identity of the node acts as a human readable alias to the node’s public key and several demos use this to lookup the NodeInfo.
-
-
-
nearestCity:
The location of the node as used to locate coordinates on the world map when running the network simulator demo. See Network Simulator.
-
-
-
keyStorePassword:
-
The password to unlock the KeyStore file (<workspace>/certificates/sslkeystore.jks) containing the node certificate and private key.
-
note:: This is the non-secret value for the development certificates automatically generated during the first node run. Longer term these keys will be managed in secure hardware devices.
-
-
-
trustStorePassword:
-
The password to unlock the Trust store file (<workspace>/certificates/truststore.jks) containing the R3 Corda root certificate. This is the non-secret value for the development certificates automatically generated during the first node run.
-
-
Note
-
Longer term these keys will be managed in secure hardware devices.
-
-
-
-
dataSourceProperties:
-
This section is used to configure the jdbc connection and database driver used for the nodes persistence. Currently the defaults in /node/src/main/resources/reference.conf are as shown in the first example. This is currently the only configuration that has been tested, although in the future full support for other storage layers will be validated.
-
-
-
artemisAddress:
The host and port on which the node is available for protocol operations over ArtemisMQ.
-
-
Note
-
In practice the ArtemisMQ messaging services bind to all local addresses on the specified port. However, note that the host is the included as the advertised entry in the NetworkMapService. As a result the value listed here must be externally accessible when running nodes across a cluster of machines.
-
-
-
-
messagingServerAddress:
-
The address of the ArtemisMQ broker instance. If not provided the node will run one locally.
-
-
-
webAddress:
The host and port on which the node is available for web operations.
-
-
Note
-
If HTTPS is enabled then the browser security checks will require that the accessing url host name is one of either the machine name, fully qualified machine name, or server IP address to line up with the Subject Alternative Names contained within the development certificates. This is addition to requiring the /config/dev/corda_dev_ca.cer root certificate be installed as a Trusted CA.
-
-
-
-
extraAdvertisedServiceIds:
-
A list of ServiceType id strings to be advertised to the NetworkMapService and thus be available when other nodes query the NetworkMapCache for supporting nodes. This can also include plugin services loaded from .jar files in the plugins folder.
-
-
-
notaryNodeAddress:
-
The host and port to which to bind the embedded Raft server. Required only when running a distributed notary service. A group of Corda nodes can run a distributed notary service by each running an embedded Raft server and joining them to the same cluster to replicate the committed state log. Note that the Raft cluster uses a separate transport layer for communication that does not integrate with ArtemisMQ messaging services.
-
-
-
notaryClusterAddresses:
-
List of Raft cluster member addresses used to joining the cluster. At least one of the specified members must be active and be able to communicate with the cluster leader for joining. If empty, a new cluster will be bootstrapped. Required only when running a distributed notary service.
-
-
-
networkMapAddress:
-
If null, or missing the node is declaring itself as the NetworkMapService host. Otherwise the configuration value is the remote HostAndPort string for the ArtemisMQ service on the hosting node.
-
-
-
useHTTPS:
If false the node’s web server will be plain HTTP. If true the node will use the same certificate and private key from the <workspace>/certificates/sslkeystore.jks file as the ArtemisMQ port for HTTPS. If HTTPS is enabled then unencrypted HTTP traffic to the node’s webAddress port is not supported.
-
-
-
rpcUsers:
A list of users who are authorised to access the RPC system. Each user in the list is a config object with the
-following fields:
-
-
-
-
-
-
user:
Username consisting only of word characters (a-z, A-Z, 0-9 and _)
-
-
password:
The password
-
-
permissions:
A list of permission strings which RPC methods can use to control access
-
-
-
-
-
If this field is absent or an empty list then RPC is effectively locked down.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/build/html/corda-plugins.html b/docs/build/html/corda-plugins.html
index 00cd62e8f3..cf73a779c4 100644
--- a/docs/build/html/corda-plugins.html
+++ b/docs/build/html/corda-plugins.html
@@ -89,7 +89,9 @@
@@ -204,7 +216,7 @@ by numerous application extensions (CorDapps). These extensions will
package together all of the Corda contract code, state structures,
protocols/flows to create and modify state as well as RPC extensions for
node clients. Details of writing these CorDapps is given elsewhere
-Creating a CorDapp.
To enable these plugins to register dynamically with the Corda framework
the node uses the Java ServiceLoader to locate and load the plugin
components during the AbstractNode.start call. Therefore,
@@ -254,8 +266,14 @@ the scheduler.
d. The servicePlugins property returns a list of classes which will
be instantiated once during the AbstractNode.start call. These
classes must provide a single argument constructor which will receive a
-PluginServiceHub reference. These singleton instances are regarded
-as trusted components and can be used for a number of purposes.
+PluginServiceHub reference. They must also extend the abstract class
+SingletonSerializeAsToken which ensures that if any reference to your
+service is captured in a flow checkpoint (i.e. serialized by Kryo as
+part of Quasar checkpoints, either on the stack or by reference within
+your flows) it is stored as a simple token representing your service.
+When checkpoints are restored, after a node restart for example,
+the latest instance of the service will be substituted back in place of
+the token stored in the checkpoint.
i. Firstly, they can call PluginServiceHub.registerFlowInitiator and
register flows that will be initiated locally in response to remote flow
@@ -267,7 +285,7 @@ typically be exposed to other nodes by flows which are given a reference
to the service plugin when initiated (as defined by the
registerFlowInitiator call). The flow can then call into functions
on the plugin service singleton. Note, care should be taken to not allow
-flows to hold references to plugin services, or fields which are not
+flows to hold references to fields which are not
also SingletonSerializeAsToken, otherwise Quasar suspension in the
StateMachineManager will fail with exceptions. An example oracle can
be seen in NodeInterestRates.kt in the irs-demo sample.
@@ -304,7 +322,7 @@ various threads and needs to be stable and thread safe.
A Cordapp is an application that runs on the Corda platform using the platform APIs and plugin system. They are self
contained in separate JARs from the node server JAR that are created and distributed.
@@ -235,8 +247,8 @@ specific details of the implementation, but you can extend the server in the fol
Services are classes which are constructed after the node has started. It is provided a ServiceHubInternal which
-allows a richer API than the ServiceHub exposed to contracts. It enables adding flows, registering
+
Services are classes which are constructed after the node has started. It is provided a PluginServiceHub which
+allows a richer API than the ServiceHub exposed to contracts. It enables adding flows, registering
message handlers and more. The service does not run in a separate thread, so the only entry point to the service is during
construction, where message handlers should be registered and threads started.
@@ -445,10 +457,10 @@ one node per window.
@@ -457,7 +469,7 @@ one node per window.
If you opened the Corda project using “Import” from the IntelliJ splash screen rather than using “Open” and then
+importing the Gradle build system from the popup bubble, then a bug in IntelliJ will cause it to wipe and recreate
+the .idea directory where the run configurations are stored. The fix is simple and doesn’t require you to
+re-import the project: just undelete the files! You can do that by either:
+
+
Running gitcheckout.idea/runConfigurations to restore that part of the tree to its normal state.
+
Using the “Version Control” pane in IntelliJ to undelete the files via the GUI.
If on attempting to open the project (including importing Gradle project), IntelliJ refuses because an SDK was not selected,
@@ -253,12 +298,21 @@ opened by clicking on “Event Log” at the bottom right of the Intelli
This article explains our experimental approach to modelling financial protocols in code. It explains how the
-platform’s state machine framework is used, and takes you through the code for a simple 2-party asset trading protocol
-which is included in the source.
Shared distributed ledgers are interesting because they allow many different, mutually distrusting parties to
-share a single source of truth about the ownership of assets. Digitally signed transactions are used to update that
-shared ledger, and transactions may alter many states simultaneously and atomically.
-
Blockchain systems such as Bitcoin support the idea of building up a finished, signed transaction by passing around
-partially signed invalid transactions outside of the main network, and by doing this you can implement
-delivery versus payment such that there is no chance of settlement failure, because the movement of cash and the
-traded asset are performed atomically by the same transaction. To perform such a trade involves a multi-step protocol
-in which messages are passed back and forth privately between parties, checked, signed and so on.
-
Despite how useful these protocols are, platforms such as Bitcoin and Ethereum do not assist the developer with the rather
-tricky task of actually building them. That is unfortunate. There are many awkward problems in their implementation
-that a good platform would take care of for you, problems like:
-
-
Avoiding “callback hell” in which code that should ideally be sequential is turned into an unreadable mess due to the
-desire to avoid using up a thread for every protocol instantiation.
-
Surviving node shutdowns/restarts that may occur in the middle of the protocol without complicating things. This
-implies that the state of the protocol must be persisted to disk.
-
Error handling.
-
Message routing.
-
Serialisation.
-
Catching type errors, in which the developer gets temporarily confused and expects to receive/send one type of message
-when actually they need to receive/send another.
-
Unit testing of the finished protocol.
-
-
Actor frameworks can solve some of the above but they are often tightly bound to a particular messaging layer, and
-we would like to keep a clean separation. Additionally, they are typically not type safe, and don’t make persistence or
-writing sequential code much easier.
-
To put these problems in perspective, the payment channel protocol in the bitcoinj library, which allows bitcoins to
-be temporarily moved off-chain and traded at high speed between two parties in private, consists of about 7000 lines of
-Java and took over a month of full time work to develop. Most of that code is concerned with the details of persistence,
-message passing, lifecycle management, error handling and callback management. Because the business logic is quite
-spread out the code can be difficult to read and debug.
-
As small contract-specific trading protocols are a common occurence in finance, we provide a framework for the
-construction of them that automatically handles many of the concerns outlined above.
A continuation is a suspended stack frame stored in a regular object that can be passed around, serialised,
-unserialised and resumed from where it was suspended. This concept is sometimes referred to as “fibers”. This may
-sound abstract but don’t worry, the examples below will make it clearer. The JVM does not natively support
-continuations, so we implement them using a library called Quasar which works through behind-the-scenes
-bytecode rewriting. You don’t have to know how this works to benefit from it, however.
-
We use continuations for the following reasons:
-
-
It allows us to write code that is free of callbacks, that looks like ordinary sequential code.
-
A suspended continuation takes far less memory than a suspended thread. It can be as low as a few hundred bytes.
-In contrast a suspended Java thread stack can easily be 1mb in size.
-
It frees the developer from thinking (much) about persistence and serialisation.
-
-
A state machine is a piece of code that moves through various states. These are not the same as states in the data
-model (that represent facts about the world on the ledger), but rather indicate different stages in the progression
-of a multi-stage protocol. Typically writing a state machine would require the use of a big switch statement and some
-explicit variables to keep track of where you’re up to. The use of continuations avoids this hassle.
We would like to implement the “hello world” of shared transaction building protocols: a seller wishes to sell some
-asset (e.g. some commercial paper) in return for cash. The buyer wishes to purchase the asset using his cash. They
-want the trade to be atomic so neither side is exposed to the risk of settlement failure. We assume that the buyer
-and seller have found each other and arranged the details on some exchange, or over the counter. The details of how
-the trade is arranged isn’t covered in this article.
-
Our protocol has two parties (B and S for buyer and seller) and will proceed as follows:
-
-
S sends a StateAndRef pointing to the state they want to sell to B, along with info about the price they require
-B to pay.
-
B sends to S a SignedTransaction that includes the state as input, B’s cash as input, the state with the new
-owner key as output, and any change cash as output. It contains a single signature from B but isn’t valid because
-it lacks a signature from S authorising movement of the asset.
-
S signs it and hands the now finalised SignedTransaction back to B.
-
-
You can find the implementation of this protocol in the file finance/src/main/kotlin/net.corda.protocols/TwoPartyTradeProtocol.kt.
-
Assuming no malicious termination, they both end the protocol being in posession of a valid, signed transaction that
-represents an atomic asset swap.
-
Note that it’s the seller who initiates contact with the buyer, not vice-versa as you might imagine.
-
We start by defining a wrapper that namespaces the protocol code, two functions to start either the buy or sell side
-of the protocol, and two classes that will contain the protocol definition. We also pick what data will be used by
-each side.
-
-
Note
-
The code samples in this tutorial are only available in Kotlin, but you can use any JVM language to
-write them and the approach is the same.
-
-
-
objectTwoPartyTradeProtocol{
-
- classUnacceptablePriceException(valgivenPrice:Amount<Currency>):Exception("Unacceptable price: $givenPrice")
- classAssetMismatchException(valexpectedTypeName:String,valtypeName:String):Exception(){
- overridefuntoString()="The submitted asset didn't match the expected type: $expectedTypeName vs $typeName"
- }
-
- // This object is serialised to the network and is the first protocol message the seller sends to the buyer.
- dataclassSellerTradeInfo(
- valassetForSale:StateAndRef<OwnableState>,
- valprice:Amount<Currency>,
- valsellerOwnerKey:PublicKey
- )
-
- dataclassSignaturesFromSeller(valsellerSig:DigitalSignature.WithKey,
- valnotarySig:DigitalSignature.LegallyIdentifiable)
-
- openclassSeller(valotherSide:Party,
- valnotaryNode:NodeInfo,
- valassetToSell:StateAndRef<OwnableState>,
- valprice:Amount<Currency>,
- valmyKeyPair:KeyPair,
- overridevalprogressTracker:ProgressTracker=Seller.tracker()):ProtocolLogic<SignedTransaction>(){
- @Suspendable
- overridefuncall():SignedTransaction{
- TODO()
- }
- }
-
- openclassBuyer(valotherSide:Party,
- valnotary:Party,
- valacceptablePrice:Amount<Currency>,
- valtypeToBuy:Class<outOwnableState>):ProtocolLogic<SignedTransaction>(){
- @Suspendable
- overridefuncall():SignedTransaction{
- TODO()
- }
- }
-}
-
-
-
-
This code defines several classes nested inside the main TwoPartyTradeProtocol singleton. Some of the classes are
-simply protocol messages or exceptions. The other two represent the buyer and seller side of the protocol.
-
Going through the data needed to become a seller, we have:
-
-
otherSide:Party - the party with which you are trading.
-
notaryNode:NodeInfo - the entry in the network map for the chosen notary. See “Consensus model” for more
-information on notaries.
-
assetToSell:StateAndRef<OwnableState> - a pointer to the ledger entry that represents the thing being sold.
-
price:Amount<Currency> - the agreed on price that the asset is being sold for (without an issuer constraint).
-
myKeyPair:KeyPair - the key pair that controls the asset being sold. It will be used to sign the transaction.
-
-
And for the buyer:
-
-
acceptablePrice:Amount<Currency> - the price that was agreed upon out of band. If the seller specifies
-a price less than or equal to this, then the trade will go ahead.
-
typeToBuy:Class<outOwnableState> - the type of state that is being purchased. This is used to check that the
-sell side of the protocol isn’t trying to sell us the wrong thing, whether by accident or on purpose.
-
-
Alright, so using this protocol shouldn’t be too hard: in the simplest case we can just create a Buyer or Seller
-with the details of the trade, depending on who we are. We then have to start the protocol in some way. Just
-calling the call function ourselves won’t work: instead we need to ask the framework to start the protocol for
-us. More on that in a moment.
The call function of the buyer/seller classes is marked with the @Suspendable annotation. What does this mean?
-
As mentioned above, our protocol framework will at points suspend the code and serialise it to disk. For this to work,
-any methods on the call stack must have been pre-marked as @Suspendable so the bytecode rewriter knows to modify
-the underlying code to support this new feature. A protocol is suspended when calling either receive, send or
-sendAndReceive which we will learn more about below. For now, just be aware that when one of these methods is
-invoked, all methods on the stack must have been marked. If you forget, then in the unit test environment you will
-get a useful error message telling you which methods you didn’t mark. The fix is simple enough: just add the annotation
-and try again.
-
-
Note
-
Java 9 is likely to remove this pre-marking requirement completely.
The StateMachineManager is the class responsible for taking care of all running protocols in a node. It knows
-how to register handlers with the messaging system (see “Networking and messaging”) and iterate the right state machine
-when messages arrive. It provides the send/receive/sendAndReceive calls that let the code request network
-interaction and it will save/restore serialised versions of the fiber at the right times.
-
Protocols can be invoked in several ways. For instance, they can be triggered by scheduled events,
-see “Event scheduling” to learn more about this. Or they can be triggered via the HTTP API. Or they can
-be triggered directly via the Java-level node APIs from your app code.
-
You request a protocol to be invoked by using the ServiceHub.invokeProtocolAsync method. This takes a
-Java reflection Class object that describes the protocol class to use (in this case, either Buyer or Seller).
-It also takes a set of arguments to pass to the constructor. Because it’s possible for protocol invocations to
-be requested by untrusted code (e.g. a state that you have been sent), the types that can be passed into the
-protocol are checked against a whitelist, which can be extended by apps themselves at load time.
-
The process of starting a protocol returns a ListenableFuture that you can use to either block waiting for
-the result, or register a callback that will be invoked when the result is ready.
-
In a two party protocol only one side is to be manually started using ServiceHub.invokeProtocolAsync. The other side
-has to be registered by its node to respond to the initiating protocol via ServiceHubInternal.registerProtocolInitiator.
-In our example it doesn’t matter which protocol is the initiator and which is the initiated. For example, if we are to
-take the seller as the initiator then we would register the buyer as such:
Here we see the outline of the procedure. We receive a proposed trade transaction from the buyer and check that it’s
-valid. The buyer has already attached their signature before sending it. Then we calculate and attach our own signature so that the transaction is
-now signed by both the buyer and the seller. We then send this request to a notary to assert with another signature that the
-timestamp in the transaction (if any) is valid and there are no double spends, and send back both
-our signature and the notaries signature. Note we should not send to the notary until all other required signatures have been appended
-as the notary may validate the signatures as well as verifying for itself the transactional integrity.
-Finally, we hand back to the code that invoked the protocol the finished transaction.
-
Let’s fill out the receiveAndCheckProposedTransaction() method.
-
-
@Suspendable
-privatefunreceiveAndCheckProposedTransaction():SignedTransaction{
- // Make the first message we'll send to kick off the protocol.
- valhello=SellerTradeInfo(assetToSell,price,myKeyPair.public)
-
- valmaybeSTX=sendAndReceive<SignedTransaction>(otherSide,hello)
-
- maybeSTX.unwrap{
- // Check that the tx proposed by the buyer is valid.
- valmissingSigs:Set<PublicKey>=it.verifySignatures(throwIfSignaturesAreMissing=false)
- valexpected=setOf(myKeyPair.public,notaryNode.identity.owningKey)
- if(missingSigs!=expected)
- throwSignatureException("The set of missing signatures is not as expected: ${missingSigs.toStringsShort()} vs ${expected.toStringsShort()}")
-
- valwtx:WireTransaction=it.tx
- logger.trace{"Received partially signed transaction: ${it.id}"}
-
- // Download and check all the things that this transaction depends on and verify it is contract-valid,
- // even though it is missing signatures.
- subProtocol(ResolveTransactionsProtocol(wtx,otherSide))
-
- if(wtx.outputs.map{it.data}.sumCashBy(myKeyPair.public).withoutIssuer()!=price)
- throwIllegalArgumentException("Transaction is not sending us the right amount of cash")
-
- returnit
- }
-}
-
-
-
-
Let’s break this down. We fill out the initial protocol message with the trade info, and then call sendAndReceive.
-This function takes a few arguments:
-
-
The party on the other side.
-
The thing to send. It’ll be serialised and sent automatically.
-
Finally a type argument, which is the kind of object we’re expecting to receive from the other side. If we get
-back something else an exception is thrown.
-
-
Once sendAndReceive is called, the call method will be suspended into a continuation and saved to persistent
-storage. If the node crashes or is restarted, the protocol will effectively continue as if nothing had happened. Your
-code may remain blocked inside such a call for seconds, minutes, hours or even days in the case of a protocol that
-needs human interaction!
-
-
Note
-
There are a couple of rules you need to bear in mind when writing a class that will be used as a continuation.
-The first is that anything on the stack when the function is suspended will be stored into the heap and kept alive by
-the garbage collector. So try to avoid keeping enormous data structures alive unless you really have to.
-
The second is that as well as being kept on the heap, objects reachable from the stack will be serialised. The state
-of the function call may be resurrected much later! Kryo doesn’t require objects be marked as serialisable, but even so,
-doing things like creating threads from inside these calls would be a bad idea. They should only contain business
-logic and only do I/O via the methods exposed by the protocol framework.
-
It’s OK to keep references around to many large internal node services though: these will be serialised using a
-special token that’s recognised by the platform, and wired up to the right instance when the continuation is
-loaded off disk again.
-
-
The buyer is supposed to send us a transaction with all the right inputs/outputs/commands in response to the opening
-message, with their cash put into the transaction and their signature on it authorising the movement of the cash.
-
You get back a simple wrapper class, UntrustworthyData<SignedTransaction>, which is just a marker class that reminds
-us that the data came from a potentially malicious external source and may have been tampered with or be unexpected in
-other ways. It doesn’t add any functionality, but acts as a reminder to “scrub” the data before use.
-
Our “scrubbing” has three parts:
-
-
Check that the expected signatures are present and correct. At this point we expect our own signature to be missing,
-because of course we didn’t sign it yet, and also the signature of the notary because that must always come last.
-
We resolve the transaction, which we will cover below.
-
We verify that the transaction is paying us the demanded price.
In this code snippet we are using the NotaryProtocol.Client to request notarisation of the transaction.
-We simply create the protocol object via its constructor, and then pass it to the subProtocol method which
-returns the result of the protocol’s execution directly. Behind the scenes all this is doing is wiring up progress
-tracking (discussed more below) and then running the objects call method. Because this little helper method can
-be on the stack when network IO takes place, we mark it as @Suspendable.
-
Going back to the previous code snippet, we use a subprotocol called ResolveTransactionsProtocol. This is
-responsible for downloading and checking all the dependencies of a transaction, which in Corda are always retrievable
-from the party that sent you a transaction that uses them. This protocol returns a list of LedgerTransaction
-objects, but we don’t need them here so we just ignore the return value.
-
-
Note
-
Transaction dependency resolution assumes that the peer you got the transaction from has all of the
-dependencies itself. It must do, otherwise it could not have convinced itself that the dependencies were themselves
-valid. It’s important to realise that requesting only the transactions we require is a privacy leak, because if
-we don’t download a transaction from the peer, they know we must have already seen it before. Fixing this privacy
-leak will come later.
-
-
After the dependencies, we check the proposed trading transaction for validity by running the contracts for that as
-well (but having handled the fact that some signatures are missing ourselves).
It’s all pretty straightforward from now on. Here txBits is the raw byte array representing the serialised
-transaction, and we just use our private key to calculate a signature over it. As a reminder, in Corda signatures do
-not cover other signatures: just the core of the transaction data.
-
In sendSignatures, we take the two signatures we obtained and add them to the partial transaction we were sent.
-There is an overload for the + operator so signatures can be added to a SignedTransaction easily. Finally, we wrap the
-two signatures in a simple wrapper message class and send it back. The send won’t block waiting for an acknowledgement,
-but the underlying message queue software will retry delivery if the other side has gone away temporarily.
-
You can also see that every protocol instance has a logger (using the SLF4J API) which you can use to log progress
-messages.
-
-
Warning
-
This sample code is not secure. Other than not checking for all possible invalid constructions, if the
-seller stops before sending the finalised transaction to the buyer, the seller is left with a valid transaction
-but the buyer isn’t, so they can’t spend the asset they just purchased! This sort of thing will be fixed in a
-future version of the code.
@Suspendable
-override fun call(): SignedTransaction {
- val tradeRequest = receiveAndValidateTradeRequest()
- val (ptx, cashSigningPubKeys) = assembleSharedTX(tradeRequest)
- val stx = signWithOurKeys(cashSigningPubKeys, ptx)
-
- val signatures = swapSignaturesWithSeller(stx)
-
- logger.trace { "Got signatures from seller, verifying ... " }
-
- val fullySigned = stx + signatures.sellerSig + signatures.notarySig
- fullySigned.verifySignatures()
-
- logger.trace { "Signatures received are valid. Trade complete! :-)" }
- return fullySigned
-}
-
-@Suspendable
-private fun receiveAndValidateTradeRequest(): SellerTradeInfo {
- // Wait for a trade request to come in from the other side
- val maybeTradeRequest = receive<SellerTradeInfo>(otherParty)
- maybeTradeRequest.unwrap {
- // What is the seller trying to sell us?
- val asset = it.assetForSale.state.data
- val assetTypeName = asset.javaClass.name
- logger.trace { "Got trade request for a $assetTypeName: ${it.assetForSale}" }
-
- if (it.price > acceptablePrice)
- throw UnacceptablePriceException(it.price)
- if (!typeToBuy.isInstance(asset))
- throw AssetMismatchException(typeToBuy.name, assetTypeName)
-
- // Check the transaction that contains the state which is being resolved.
- // We only have a hash here, so if we don't know it already, we have to ask for it.
- subProtocol(ResolveTransactionsProtocol(setOf(it.assetForSale.ref.txhash), otherSide))
-
- return it
- }
-}
-
-@Suspendable
-private fun swapSignaturesWithSeller(stx: SignedTransaction): SignaturesFromSeller {
- progressTracker.currentStep = SWAPPING_SIGNATURES
- logger.trace { "Sending partially signed transaction to seller" }
-
- // TODO: Protect against the seller terminating here and leaving us in the lurch without the final tx.
-
- return sendAndReceive<SignaturesFromSeller>(otherSide, stx).unwrap { it }
-}
-
-private fun signWithOurKeys(cashSigningPubKeys: List<PublicKey>, ptx: TransactionBuilder): SignedTransaction {
- // Now sign the transaction with whatever keys we need to move the cash.
- for (k in cashSigningPubKeys) {
- val priv = serviceHub.keyManagementService.toPrivate(k)
- ptx.signWith(KeyPair(k, priv))
- }
-
- return ptx.toSignedTransaction(checkSufficientSignatures = false)
-}
-
-private fun assembleSharedTX(tradeRequest: SellerTradeInfo): Pair<TransactionBuilder, List<PublicKey>> {
- val ptx = TransactionType.General.Builder(notary)
- // Add input and output states for the movement of cash, by using the Cash contract to generate the states.
- val wallet = serviceHub.walletService.currentWallet
- val cashStates = wallet.statesOfType<Cash.State>()
- val cashSigningPubKeys = Cash().generateSpend(ptx, tradeRequest.price, tradeRequest.sellerOwnerKey, cashStates)
- // Add inputs/outputs/a command for the movement of the asset.
- ptx.addInputState(tradeRequest.assetForSale)
- // Just pick some new public key for now. This won't be linked with our identity in any way, which is what
- // we want for privacy reasons: the key is here ONLY to manage and control ownership, it is not intended to
- // reveal who the owner actually is. The key management service is expected to derive a unique key from some
- // initial seed in order to provide privacy protection.
- val freshKey = serviceHub.keyManagementService.freshKey()
- val (command, state) = tradeRequest.assetForSale.state.data.withNewOwner(freshKey.public)
- ptx.addOutputState(state, tradeRequest.assetForSale.state.notary)
- ptx.addCommand(command, tradeRequest.assetForSale.state.data.owner)
-
- // And add a request for timestamping: it may be that none of the contracts need this! But it can't hurt
- // to have one.
- val currentTime = serviceHub.clock.instant()
- ptx.setTime(currentTime, 30.seconds)
- return Pair(ptx, cashSigningPubKeys)
-}
-
-
-
-
This code is longer but no more complicated. Here are some things to pay attention to:
-
-
We do some sanity checking on the received message to ensure we’re being offered what we expected to be offered.
-
We create a cash spend in the normal way, by using Cash().generateSpend. See the contracts tutorial if this
-part isn’t clear.
-
We access the service hub when we need it to access things that are transient and may change or be recreated
-whilst a protocol is suspended, things like the wallet or the network map.
-
Finally, we send the unfinished, invalid transaction to the seller so they can sign it. They are expected to send
-back to us a SignaturesFromSeller, which once we verify it, should be the final outcome of the trade.
-
-
As you can see, the protocol logic is straightforward and does not contain any callbacks or network glue code, despite
-the fact that it takes minimal resources and can survive node restarts.
-
-
Warning
-
In the current version of the platform, exceptions thrown during protocol execution are not propagated
-back to the sender. A thorough error handling and exceptions framework will be in a future version of the platform.
Not shown in the code snippets above is the usage of the ProgressTracker API. Progress tracking exports information
-from a protocol about where it’s got up to in such a way that observers can render it in a useful manner to humans who
-may need to be informed. It may be rendered via an API, in a GUI, onto a terminal window, etc.
-
A ProgressTracker is constructed with a series of Step objects, where each step is an object representing a
-stage in a piece of work. It is therefore typical to use singletons that subclass Step, which may be defined easily
-in one line when using Kotlin. Typical steps might be “Waiting for response from peer”, “Waiting for signature to be
-approved”, “Downloading and verifying data” etc.
-
Each step exposes a label. By default labels are fixed, but by subclassing RelabelableStep
-you can make a step that can update its label on the fly. That’s useful for steps that want to expose non-structured
-progress information like the current file being downloaded. By defining your own step types, you can export progress
-in a way that’s both human readable and machine readable.
-
Progress trackers are hierarchical. Each step can be the parent for another tracker. By altering the
-ProgressTracker.childrenFor[step]=tracker map, a tree of steps can be created. It’s allowed to alter the hierarchy
-at runtime, on the fly, and the progress renderers will adapt to that properly. This can be helpful when you don’t
-fully know ahead of time what steps will be required. If you _do_ know what is required, configuring as much of the
-hierarchy ahead of time is a good idea, as that will help the users see what is coming up.
-
Every tracker has not only the steps given to it at construction time, but also the singleton
-ProgressTracker.UNSTARTED step and the ProgressTracker.DONE step. Once a tracker has become DONE its
-position may not be modified again (because e.g. the UI may have been removed/cleaned up), but until that point, the
-position can be set to any arbitrary set both forwards and backwards. Steps may be skipped, repeated, etc. Note that
-rolling the current step backwards will delete any progress trackers that are children of the steps being reversed, on
-the assumption that those subtasks will have to be repeated.
-
Trackers provide an Rx observable which streams changes to the hierarchy. The top level
-observable exposes all the events generated by its children as well. The changes are represented by objects indicating
-whether the change is one of position (i.e. progress), structure (i.e. new subtasks being added/removed) or some other
-aspect of rendering (i.e. a step has changed in some way and is requesting a re-render).
-
The protocol framework is somewhat integrated with this API. Each ProtocolLogic may optionally provide a tracker by
-overriding the protocolTracker property (getProtocolTracker method in Java). If the
-ProtocolLogic.subProtocol method is used, then the tracker of the sub-protocol will be made a child of the current
-step in the parent protocol automatically, if the parent is using tracking in the first place. The framework will also
-automatically set the current step to DONE for you, when the protocol is finished.
-
Because a protocol may sometimes wish to configure the children in its progress hierarchy _before_ the sub-protocol
-is constructed, for sub-protocols that always follow the same outline regardless of their parameters it’s conventional
-to define a companion object/static method (for Kotlin/Java respectively) that constructs a tracker, and then allow
-the sub-protocol to have the tracker it will use be passed in as a parameter. This allows all trackers to be built
-and linked ahead of time.
-
In future, the progress tracking framework will become a vital part of how exceptions, errors, and other faults are
-surfaced to human operators for investigation and resolution.
A protocol can be a fairly complex thing that interacts with many services and other parties over the network. That
-means unit testing one requires some infrastructure to provide lightweight mock implementations. The MockNetwork
-provides this testing infrastructure layer; you can find this class in the node module
-
A good example to examine for learning how to unit test protocols is the ResolveTransactionsProtocol tests. This
-protocol takes care of downloading and verifying transaction graphs, with all the needed dependencies. We start
-with this basic skeleton:
We create a mock network in our @Before setup method and create a couple of nodes. We also record the identity
-of the notary in our test network, which will come in handy later. We also tidy up when we’re done.
-
Next, we write a test case:
-
-
@Test
-fun resolveFromTwoHashes() {
- val (stx1, stx2) = makeTransactions()
- val p = ResolveTransactionsProtocol(setOf(stx2.id), a.info.identity)
- val future = b.services.startProtocol("resolve", p)
- net.runNetwork()
- val results = future.get()
- assertEquals(listOf(stx1.id, stx2.id), results.map { it.id })
- assertEquals(stx1, b.storage.validatedTransactions.getTransaction(stx1.id))
- assertEquals(stx2, b.storage.validatedTransactions.getTransaction(stx2.id))
-}
-
-
-
-
We’ll take a look at the makeTransactions function in a moment. For now, it’s enough to know that it returns two
-SignedTransaction objects, the second of which spends the first. Both transactions are known by node A
-but not node B.
-
The test logic is simple enough: we create the protocol, giving it node A’s identity as the target to talk to.
-Then we start it on node B and use the net.runNetwork() method to bounce messages around until things have
-settled (i.e. there are no more messages waiting to be delivered). All this is done using an in memory message
-routing implementation that is fast to initialise and use. Finally, we obtain the result of the protocol and do
-some tests on it. We also check the contents of node B’s database to see that the protocol had the intended effect
-on the node’s persistent state.
-
Here’s what makeTransactions looks like:
-
-
privatefunmakeTransactions():Pair<SignedTransaction,SignedTransaction>{
- // Make a chain of custody of dummy states and insert into node A.
- valdummy1:SignedTransaction=DummyContract.generateInitial(MEGA_CORP.ref(1),0,notary).let{
- it.signWith(MEGA_CORP_KEY)
- it.signWith(DUMMY_NOTARY_KEY)
- it.toSignedTransaction(false)
- }
- valdummy2:SignedTransaction=DummyContract.move(dummy1.tx.outRef(0),MINI_CORP_PUBKEY).let{
- it.signWith(MEGA_CORP_KEY)
- it.signWith(DUMMY_NOTARY_KEY)
- it.toSignedTransaction()
- }
- a.services.recordTransactions(dummy1,dummy2)
- returnPair(dummy1,dummy2)
-}
-
-
-
-
We’re using the DummyContract, a simple test smart contract which stores a single number in its states, along
-with ownership and issuer information. You can issue such states, exit them and re-assign ownership (move them).
-It doesn’t do anything else. This code simply creates a transaction that issues a dummy state (the issuer is
-MEGA_CORP, a pre-defined unit test identity), signs it with the test notary and MegaCorp keys and then
-converts the builder to the final SignedTransaction. It then does so again, but this time instead of issuing
-it re-assigns ownership instead. The chain of two transactions is finally committed to node A by sending them
-directly to the a.services.recordTransaction method (note that this method doesn’t check the transactions are
-valid).
-
And that’s it: you can explore the documentation for the MockNode API here.
Fibers involve persisting object-serialised stack frames to disk. Although we may do some R&D into in-place upgrades
-in future, for now the upgrade process for protocols is simple: you duplicate the code and rename it so it has a
-new set of class names. Old versions of the protocol can then drain out of the system whilst new versions are
-initiated. When enough time has passed that no old versions are still waiting for anything to happen, the previous
-copy of the code can be deleted.
-
Whilst kind of ugly, this is a very simple approach that should suffice for now.
-
-
Warning
-
Protocols are not meant to live for months or years, and by implication they are not meant to implement entire deal
-lifecycles. For instance, implementing the entire life cycle of an interest rate swap as a single protocol - whilst
-technically possible - would not be a good idea. The platform provides a job scheduler tool that can invoke
-protocols for this reason (see “Event scheduling”)
The protocol framework is a key part of the platform and will be extended in major ways in future. Here are some of
-the features we have planned:
-
-
Identity based addressing
-
Exposing progress trackers to local (inside the firewall) clients using message queues and/or WebSockets
-
Exception propagation and management, with a “protocol hospital” tool to manually provide solutions to unavoidable
-problems (e.g. the other side doesn’t know the trade)
-
Being able to interact with internal apps and tools via HTTP and similar
-
Being able to interact with people, either via some sort of external ticketing system, or email, or a custom UI.
-For example to implement human transaction authorisations.
-
A standard library of protocols that can be easily sub-classed by local developers in order to integrate internal
-reporting logic, or anything else that might be required as part of a communications lifecycle.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/docs/build/html/release-notes.html b/docs/build/html/release-notes.html
index 542510e47d..4db9ae545f 100644
--- a/docs/build/html/release-notes.html
+++ b/docs/build/html/release-notes.html
@@ -89,14 +89,26 @@
Added the Corda technical white paper. Note that its current version
+is 0.5 to reflect the fact that the Corda design is still evolving. Although we expect only relatively small tweaks
+at this point, when Corda reaches 1.0 so will the white paper.
+
+
Major documentation restructuring and new content:
+
+
+
More details on Corda node internals.
+
New CorDapp tutorial.
+
New tutorial on building transactions.
+
New tutorials on how to run and use a notary service.
+
+
+
+
An experimental version of the deterministic JVM sandbox has been added. It is not integrated with the node and will
+undergo some significant changes in the coming releases before it is integrated, as the code is finished, as bugs are
+found and fixed, and as the platform subset we choose to expose is finalised. Treat this as an outline of the basic
+approach rather than something usable for production.
+
+
Developer experience:
+
+
+
Samples have been merged back into the main repository. All samples can now be run via command line or IntelliJ.
+
Added a Client RPC python example.
+
Node console output now displays concise startup information, such as startup time or web address. All logging to
+the console is suppressed apart from errors and flow progress tracker steps. It can be re-enabled by passing
+--log-to-console command line parameter. Note that the log file remains unchanged an will still contain all
+log entries.
+
The runnodes scripts generated by the Gradle plugins now open each node in separate terminal windows or (on macOS) tabs.
+
A much more complete template app.
+
JARs now available on Maven Central.
+
+
+
+
Data model: A party is now identified by a composite key (formerly known as a “public key tree”) instead of a single public key.
+Read more in Multi-signature support. This allows expressing distributed service identities, e.g. a distributed notary.
+In the future this will also allow parties to use multiple signing keys for their legal identity.
+
+
Decentralised consensus: A prototype RAFT based notary composed of multiple nodes has been added. This implementation
+is optimised for high performance over robustness against malicious cluster members, which may be appropriate for
+some financial situations. See Distributed Notary demo to try it out. A BFT notary will be added later.
+
+
Node explorer app:
+
+
+
New theme aligned with the Corda branding.
+
The New Transaction screen moved to the Cash View (as it is used solely for cash transactions)
+
Removed state machine/flow information from Transaction table. A new view for this will be created in a future release.
+
Added a new Network View that displays details of all nodes on the network.
+
Users can now configure the reporting currency in settings.
+
Various layout and performance enhancements.
+
+
+
+
Client RPC:
+
+
+
Added a generic startFlow method that enables starting of any flow, given sufficient permissions.
+
Added the ability for plugins to register additional classes or custom serialisers with Kryo for use in RPC.
+
rpc-users.properties file has been removed with RPC user settings moved to the config file.
+
+
+
+
Configuration changes: It is now possible to specify a custom legal name for any of the node’s advertised services.
+
+
Added a load testing framework which allows stress testing of a node cluster, as well as specifying different ways of
+disrupting the normal operation of nodes. See Load testing.
+
+
Improvements to the experimental contract DSL, by Sofus Mortensen of Nordea Bank (please give Nordea a shoutout too).
+
+
+
API changes:
+
+
The top level package has been renamed from com.r3corda to net.corda.
+
Protocols have been renamed to “flows”.
+
OpaqueBytes now uses bytes as the field name rather than bits.
@@ -325,7 +424,7 @@ not currently running a permissioning service.
The Corda libraries that app developers need to link against can now be installed into your local Maven
-repository, where they can then be used like any other JAR. See Creating a Cordapp.
+repository, where they can then be used like any other JAR. See CorDapps Background.
The demos can be run either from the command line, or from inside IntelliJ. Running from the command line is
recommended if you are just wanting to see them run, using IntelliJ can be helpful if you want to debug or
-develop the demos themselves.
+develop the demos themselves. For more details about running via the command line or within IntelliJ - see CLI vs IDE.
+
For all demos: The install gradle task is automatically ran if required; this no longer needs to be run independently.
This demo brings up three nodes: Bank A, Bank B and a notary/network map node that they both use. Bank A will
-be the buyer, and self-issues some cash in order to acquire the commercial paper from Bank B, the seller.
+be the buyer, and self-issues some cash in order to acquire commercial paper from Bank B, the seller.
To run from the command line:
Run ./gradlewsamples:trader-demo:deployNodes to create a set of configs and installs under samples/trader-demo/build/nodes
@@ -256,7 +278,7 @@ oracle together. The two banks agree on an interest rate swap, and then do regul
on a simulated clock passes.
To run from the command line:
-
Run ./gradlewsamples:irs-demo:deployNodessamples:irs-demo:installDist to install configs and a command line tool under samples/irs-demo/build.
+
Run ./gradlewsamples:irs-demo:deployNodes to install configs and a command line tool under samples/irs-demo/build.
Change to the samples/irs-demo/build directory.
Run ./nodes/runnodes (or runnodes.bat on Windows) to open up three new terminals with the three nodes.
Run ./install/irs-demo/bin/irs-demo--roleUploadRates (or use irs-demo.bat on Windows). You should see a
@@ -303,20 +325,6 @@ Now look at the other windows to see the output of the demo.
In the “Attachment Demo: Run Nodes” window you should see some log lines scroll past, and within a few seconds the
message “File received - we’re happy!” should be printed.
This is a simple demonstration showing a party getting transactions notarised by a distributed Raft-based notary service.
@@ -359,6 +367,103 @@ but we’re only interested in the row count for this demo.
+
+
SIMM and Portfolio Demo - aka the Initial Margin Agreement Demo¶
This app is a demonstration of how Corda can be used for the real world requirement of initial margin calculation and
+agreement; featuring the integration of complex and industry proven third party libraries into Corda nodes.
+
SIMM is an acronym for “Standard Initial Margin Model”. It is effectively the calculation of a “margin” that is paid
+by one party to another when they agree a trade on certain types of transaction. This margin is
+paid such that, in the event of one of the counterparties suffering a credit event
+(a financial term and a polite way to say defaulting, not paying the debts that are due, or potentially even bankruptcy),
+then the party that is owed any sum already has some of the amount that it should have been paid. This payment to the
+receiving party is a preventative measure in order to reduce the risk of a potentially catastrophic default domino
+effect that caused the Great Financial Crisis,
+as it means that they can be assured that if they need to pay another party, they will have a proportion of the funds
+that they have been relying on.
+
To enact this, in September 2016, the ISDA committee - with full backing from various governing bodies -
+issued a ruling on what is known as the ISDA SIMM ™ model,
+a way of fairly and consistently calculating this margin. Any parties wishing to trade a financial product that is
+covered under this ruling would, independently, use this model and calculate their margin payment requirement,
+agree it with their trading counterparty and then pay (or receive, depending on the results of this calculation)
+this amount. In the case of disagreement that is not resolved in a timely fashion, this payment would increase
+and so therefore it is in the parties’ interest to reach agreement in as short as time frame as possible.
+
To be more accurate, the SIMM calculation is not performed on just one trade - it is calculated on an aggregate of
+intermediary values (which in this model are sensitivities to risk factors) from a portfolio of trades; therefore
+the input to a SIMM is actually this data, not the individual trades themselves.
+
Also note that implementations of the SIMM are actually protected and subject to license restrictions by ISDA
+(this is due to the model itself being protected). We were fortunate enough to technically partner with
+OpenGamma who allowed us to demonstrate the SIMM process using their proprietary model.
+In the source code released, we have replaced their analytics engine with very simple stub functions that allow
+the process to run without actually calculating correct values, and can easily be swapped out in place for their real libraries.
+
Open the Corda samples project in IntelliJ and run the “Simm Valuation Demo” configuration
Ensure that there are a number of live trades with another party financial products that are covered under the
+ISDA SIMM agreement (if none, then use the demo to enter some simple trades as described below).
+
+
+
Initial Margin Agreement Process
+
+
Agree that one will be performing the margining calculation against a portfolio of trades with another party, and agree the trades in that portfolio. In practice, one node will start the flow but it does not matter which node does.
+
Individually (at the node level), identify the data (static, reference etc) one will need in order to be able to calculate the metrics on those trades
+
Confirm with the other counterparty the dataset from the above set
+
Calculate any intermediary steps and values needed for the margin calculation (ie sensitivities to risk factors)
+
Agree on the results of these steps
+
Calculate the initial margin
+
Agree on the calculation of the above with the other party
+
In practice, pay (or receive) this margin (omitted for the sake of complexity for this example)
Enter at least 3 trades - via the “Create New Trade” tab.
+
On the “Agree Valuations” tab, click the “Start Calculations” button.
+
+
+
+
Additionally, you can confirm that these trades are not visible from Bank C’s node.
+
Please note that any URL text after simmvaluationdemo should not be bookmarked or navigated directly to as they are only for aesthetics.
+
+
@@ -368,10 +473,10 @@ but we’re only interested in the row count for this demo.
@@ -380,7 +485,7 @@ but we’re only interested in the row count for this demo.
diff --git a/docs/build/html/searchindex.js b/docs/build/html/searchindex.js
index 387e1b6ca4..8667cefbc8 100644
--- a/docs/build/html/searchindex.js
+++ b/docs/build/html/searchindex.js
@@ -1 +1 @@
-Search.setIndex({envversion:49,filenames:["building-the-docs","clientrpc","codestyle","consensus","contract-catalogue","contract-irs","corda-configuration-file","corda-plugins","creating-a-cordapp","data-model","event-scheduling","flow-state-machines","flow-testing","further-notes-on-kotlin","getting-set-up","getting-set-up-fault-finding","glossary","index","initial-margin-agreement","inthebox","loadtesting","merkle-trees","messaging","network-simulator","node-administration","node-explorer","node-services","oracles","permissioning","persistence","release-notes","release-process","running-a-notary","running-the-demos","secure-coding-guidelines","setting-up-a-corda-network","transaction-data-types","tutorial-attachments","tutorial-clientrpc-api","tutorial-contract","tutorial-contract-clauses","tutorial-test-dsl","using-a-notary","where-to-start"],objects:{},objnames:{},objtypes:{},terms:{"00z":39,"0_xx":15,"10000l":20,"1000l":37,"17t16":39,"1mb":11,"300px":[],"5000l":20,"8u45":[],"_before_":11,"_do_":11,"_foo":2,"abstract":[9,11,26,29,30,39,40],"boolean":[9,12,20,30,38,39],"break":[11,27,31],"byte":[2,9,11,41],"case":[2,3,6,7,8,9,11,12,14,18,20,27,29,30,36,37,39,40],"catch":[2,11,14,34],"class":[],"default":[1,2,4,6,7,8,11,14,16,18,20,21,23,24,25,26,28,30,34,35,36,39],"enum":[30,38],"export":[11,24,29,43],"fa\u00e7ad":24,"final":[3,5,7,9,11,12,15,21,30,33,35,38,39,41],"float":[4,5,10],"function":[],"import":[2,9,10,11,15,29,30,35,36,39,40,41,43],"instanceof":39,"int":[2,20,29,39,42],"long":[2,4,7,9,10,20,29,39],"new":[2,3,5,6,7,8,9,11,13,22,23,24,25,26,28,30,31,33,36,37,38,39,40,41,42,43],"null":[6,10,12,20,29,37,39,42],"public":[2,6,8,9,11,16,19,22,24,26,28,30,33,35,36,39,40,41],"return":[1,2,3,5,7,10,11,12,20,24,26,29,30,34,37,38,39,40,41,42,43],"short":[10,18,31],"static":[7,8,9,11,18,27,39,41,43],"super":[2,40],"switch":[11,30,39],"throw":[1,2,11,20,21,38,39,40,42],"transient":11,"true":[3,6,9,12,16,20,27,28,35,38,39],"try":[1,2,9,11,15,30,32,38,43],"var":[12,29,38],"void":[39,40,41],"while":[23,36,38],abil:[9,23],abl:[3,6,8,9,11,18,21,24,25,26,27,28,30,33,39,42],abort:[3,27],about:[],abov:[2,5,9,11,18,21,24,35,39,40,41],absent:6,absolut:[3,6,9],abstractnod:[7,26],abstractstatereplacementprotocol:30,acccess:7,accept:[2,3,4,9,14,16,33,39],acceptablepric:11,access:[],accid:11,accident:[2,34],accompani:[2,39],accord:43,accordingli:[35,40],account:[9,20,30,36],accrual:5,accur:[3,18],accuraci:9,achiev:[3,9,35,36],achiv:21,ack:30,acknowledg:[11,26],acquir:33,acronym:18,across:[4,6,9,20,26,29,30,33,37],act:[3,6,9,11,26,27],action:[10,20,26,32,39,43],activ:[5,6,7,10,14,20,23,26,29,30,33,39],actor:[2,9,11],actual:[3,5,11,18,20,26,27,34,37,39,40,41,42],adapt:[2,11,27],add:[2,8,9,11,16,18,20,21,22,24,26,32,34,37,38,39,40,41,42],addattach:[12,37],addcommand:[11,39,42],addedg:38,adding:[],addinputst:[11,39],addit:[2,3,6,8,9,26,29,30,36,38,39],addition:[9,11,13,14,29,31],addmessagehandl:30,addnod:38,addoutputst:[11,39,42],address:[3,6,8,9,11,22,25,26,30,35,39],addvaulttransactionnot:38,adjust:[2,5,31,39,43],admin:[25,26,28],administr:[],advanc:[4,5],advantag:9,adventur:43,advertis:[1,6,26,32,38,39,42],advertisedservic:[8,38],advic:31,affect:[15,27,35],affinityexecutor:2,afraid:2,after:[3,4,5,8,10,11,12,13,15,16,20,21,26,27,39],again:[5,9,11,12,20,26,27,39,42],against:[],agent:[20,24,26],agentlib:8,aggreg:[9,18,39,40],agre:[5,10,11,16,18,33,34],agree:[5,18],agreement:[],ahead:[11,39],aid:30,aim:[2,9,20],aka:16,albeit:30,albertsen:30,alert:15,algorithm:[9,19,30,36,39],alia:6,alice:[16,25,36,38,39,42],alice_key:37,aliceparti:42,align:17,aliv:11,all:[0,1,2,3,4,5,6,7,8,9,11,12,13,15,16,20,21,24,25,26,27,29,30,31,33,34,35,36,37,38,39,40,42,43],allclaus:40,allcomposit:40,allevi:3,alloc:33,allow:[1,2,3,4,5,6,7,8,9,10,11,16,18,20,22,26,27,29,30,34,36,39,41,43],allpartysignedtx:11,almost:39,along:[3,11,12,14,27,39,42],alongsid:39,alreadi:[2,8,10,11,17,18,21,27,30,37,39,40,41,42],alright:11,also:[1,2,3,4,5,6,7,8,9,10,11,12,14,15,16,18,20,21,22,23,24,25,26,28,29,30,33,36,37,39,40,41,42,43],alter:[6,11,24],altern:[0,2,6,17,22,23,24,25,36,39],although:[5,6,9,11,14,15,25,26,37,39,40,43],alwai:[2,9,10,11,17,24,29,35,36,39],amount:[],amqp:[22,30],analysi:9,analyt:18,andresen:9,ani:[1,2,3,4,5,7,9,10,11,12,14,16,18,24,25,26,27,29,30,31,32,33,34,35,36,37,38,39,42,43],annot:[1,2,7,11,29],announc:31,anonym:[9,26],anonymis:26,anoth:[1,2,3,8,9,11,15,16,18,24,26,27,30,33,37,39,41,42],answer:[2,27],anticip:2,any:[1,4,10,18,24,26,38],anybodi:9,anyclaus:40,anycomposit:40,anyon:[3,39],anyth:[3,9,11,12,34,36,39,40],anytim:28,anywher:[27,30,39],apach:22,apart:3,api:[],app:[],appear:[15,33,39],append:[11,24],appendix:17,apple:14,appli:[2,4,5,8,9,20,25,39,40],applic:[7,8,9,16,22,26,27,30,33,34,39,43],applicat:16,applyfix:5,appoint:3,approach:[],appropri:[2,22,26,29,32,40],approv:[9,10,11,28],approxim:3,april:30,arbitrari:[2,9,11,27,34,36,38],arbitrarili:9,architectur:[1,17,27],area:29,aren:[1,10,19,39,43],arg:[8,30,38],argument:[1,2,7,9,11,20,38,39],aris:[9,14],around:[3,9,11,12,21,30,31,36,38,39,40],arrai:[9,38],arrang:11,arriv:[11,16,27],arrow:[5,15],art:36,artemi:[8,16,22,35],artemisaddress:[6,35,38],artemismq:[6,26],artemisport:8,articl:[3,9,10,11,27,30,39,43],artifact:8,ascertain:33,ask:[2,11,27,39],aspect:[11,43],assembl:[9,21,39],assemblesharedtx:11,assert:[],assertequ:[12,37],asset:[],assetforsal:11,assetmismatchexcept:11,assettosel:11,assettypenam:11,assign:[9,12,17,27],assist:[10,11,29,36],associ:[3,9,10,22,29,30,35,36,39],assum:[3,9,11,17,20,21,34,38,39,42],assume:[11,21],assumpt:11,assur:18,asynchron:20,atom:[3,9,11,30,33,39],attach:[],attachment:[],attachmentdemo:37,attachmentstorag:26,attack:[3,34],attch:21,attempt:[9,15,34],attent:11,attest:3,attribut:2,audit:9,authent:[1,3,26,30,38],authenticatedobject:[36,39,40],author:[2,3,14,26,31,42,43],authoris:[6,11,26,36],auto:[2,39],autoclos:1,autom:[9,10,39,43],automat:[0,1,3,6,8,10,11,22,23,26,29,30,37,39,42,43],auxiliari:26,avail:[0,3,5,6,8,10,11,14,23,24,26,30,31,33,34,37,39,42],avoid:[1,2,9,11,29],awai:[1,9,11,38],await:8,awar:[1,2,10,11,26,30,39],awg:31,awkward:[2,11],axi:5,back:[1,2,9,11,18,26,27,30,33,34,36,39],backend:30,background:[1,2,9,17],backoff:22,backport:31,backward:[11,31],bad:[2,11,39,41],balanc:[3,4,9,25,39,41],banana:36,bananast:36,banco:30,band:11,bandwidth:2,banish:16,bank:[5,6,9,30,33,35,36,37,39,42,43],bankrupt:39,bankruptci:[3,9,18,27],banner:35,bar:15,barreca:30,barrel:30,base:[2,3,5,6,8,9,10,11,16,20,22,24,26,28,30,33,35,36,39,42],basedir:[6,8,35],basedirectori:38,basi:[5,10,14,23,24,26],basic:[],bat:[8,18,23,25,28,33],batch:20,bbva:30,bear:11,becaus:[2,3,9,10,11,15,17,24,26,27,36,39,40,41,42],becom:[2,5,9,10,11,31,36],been:[3,5,6,9,11,14,16,18,27,28,30,31,36,39,40,42],befor:[3,5,8,9,10,11,12,20,26,30,31,32,36,37,39,40],begin:[2,9,17,26,39,43],behav:39,behaviour:[3,4,6,20,24,40,41],behind:[11,16,22,39],believ:30,belong:21,below:[2,5,8,9,10,11,14,18,21,26,36,39,43],beneath:16,beneficiari:4,benefit:[3,11],best:[2,43],bet:27,better:[2,13,30,39],between:[2,3,5,9,10,11,16,22,23,26,27,29,30,31,33,34,36,38,39],beyond:9,big:[2,9,11,30,39],bigdecim:[27,36],bilater:[4,5,30],bill:39,bin:[33,38],binari:[9,21,26,27,38],bind:[3,6,9,23,24,27,35],bip:9,bit:[36,39,41,42,43],bitbucket:[],bitcoinj:11,blah:2,blank:[2,24,25,28,39],block:[1,2,3,8,9,11,26,27,30,33,34],blockchain:[9,11,19,21,39],bloom:2,bloomfilt:2,blotter:33,blue:[5,21],bob:[16,25,36,39],bodi:[2,18],boil:[9,20],boilerpl:8,bond:39,bookkeep:39,boost:19,bootstrap:[6,8],bore:39,boss:17,both:[3,4,5,9,11,12,13,16,20,23,27,29,30,33,34,35,36,39],bottom:15,bounc:12,bound:[3,11,30,35,39],box:43,branch:[17,21,30,31],breach:9,bread:43,breakpoint:18,breviti:40,bridg:26,brief:[],briefli:[17,22],bring:[9,20,33],broadcast:[9,39,42],broadcasttransactionflow:42,broadcasttransactionprotocol:[],broader:35,broke:2,broken:30,broker:[6,22,26],brows:[18,24],browser:[6,33],buffer:1,bug:[2,30,31],bugfix:31,bui:[11,43],buildcertsigningrequestutilityjar:28,buildcordajar:[6,28,35],builder:[11,12,30,34,37,42],buildmerkletransact:21,buildscript:[8,16],built:[6,8,11,21,30,34,39],bulk:[9,40],bullet:2,bundl:9,busi:[9,10,11,16,19,27,29,30,36,39,43],businesscalendar:36,butter:43,button:33,buyer:[],bytearrai:29,bytecod:[9,11,39],cach:[22,37,42],calcul:[3,5,10,11,18,21,34,36,39],calculateoursignatur:11,calendar:[5,27,36],call:[1,2,3,5,7,9,11,13,24,26,30,31,33,34,36,37,38,39,40,41,42],callback:[1,2,11,26,30],caller:[39,42],came:11,camel:2,can:[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,18,19,20,21,22,23,24,25,26,27,28,29,30,32,33,34,35,36,37,38,39,40,41,42,43],candid:29,cannnot:7,cannot:[3,4,9,16,23,27,30,34,36,39,42],capabl:39,capit:2,capitan:0,capsul:23,capsule_cache_dir:8,captur:10,cardon:30,care:[2,3,7,9,11,12,34,41],carefulli:13,carri:26,cash_stat:29,cashcommand:[20,38],cashflow:38,cashkt:39,cashprotocol:[6,35],cashschema:29,cashschemav1:29,cashsigningpubkei:11,cashstat:[],cast:1,catastroph:18,categori:35,caught:1,caus:[2,16,18,33,39],cbc:20,ccy_cod:29,cent:36,center:39,central:[36,39,42],ceo:36,cer:6,certain:[2,7,18,30,39],certainli:8,certainti:3,certif:[6,17,20,26,30],certificatesigningservic:[6,28,35],certificatespath:38,certsigningrequestutil:[28,35],cev:28,chain:[],chaincash:41,chaincashdoublespend:41,chaincashdoublespendfailswith:41,challeng:9,chanc:[2,11],chang:[],changenotari:3,channel:11,charact:[2,6],characterist:16,charg:27,charli:36,check:[],checkabl:[27,30],checknotnul:39,checkpoint:[26,30],checkstat:39,checksufficientsignatur:[11,36,42],child:[11,36],children:[11,36],childrenfor:11,choic:[2,3,9,14,39],choos:[3,25,39,42],choreographi:16,chosen:[3,9,11,20,42],chronolog:10,chunk:[39,40,43],circl:23,claim:[9,39],clarifi:39,clash:[2,29],classic:39,classpath:[1,7,8,9],claus:[],clauseverifi:40,clean:[11,30],cleaner:30,cleanup:30,clear:[1,11,20,34,36],cleardatabasebeforerun:20,clearer:11,clearli:2,cli:[],click:[15,25,33],clock:[3,9,10,11,33],clone:[2,15,39],close:[1,3,4],closeabl:1,closer:3,closur:[2,41],cloud:24,cluster:[],cmd:[21,39,40],coars:9,code:[],codebas:[2,29],cognit:9,coin:9,collabor:30,collaps:20,colleagu:2,collect:[1,2,16,20,24,29,30,32,39,40],collector:[2,11,24],collis:2,column:[8,24,29],com:[0,14,15,28],combin:[9,16,36,39],come:[1,9,11,12,30,31,34,39],command:[],commanddata:[27,39,40],commercial_pap:[39,40],commercialpap:[4,29,39,40],commercialpaperlegaci:39,commit:[3,6,10,12,26,31,32,33,42],committe:18,common:[4,5,7,9,11,26,29,30,36,39,40,41],commonleg:5,commun:[6,11,16,26,30,34,35],compani:[27,28],companion:[11,39,40],compar:[9,17,21,33,39],compat:[1,16,31],compel:3,compet:9,complementari:10,complet:[1,9,10,11,26,27,28,30,33,36,37,38,39,40,41],complex:[2,4,9,12,18,29,36,37,39],complic:[11,39,40],compon:[7,8,10,16,17,22,26,30],compos:[11,30,36,39,40],composit:[],compositeclaus:40,compositekei:[11,26,36],compound:30,compris:5,comput:[5,16,27],computeoursignatur:11,concaten:21,concept:[3,4,9,10,11,17,21,27,30,39],concern:[9,11,39],concis:30,conclus:[9,27],concret:[7,26],concurr:20,concurrenthashmap:2,condit:[3,7,20,26,27,30,40,41],conf:[6,8,26,28,35],confgur:29,config:[6,8,20,24,28,33,38],configur:[],configurationfil:24,confirm:[3,15,16,18],conflict:[3,9,20,42],confus:11,connect:[1,6,8,19,20,24,25,26,28,33],consid:[2,5,9,10,16,27,30,31,36,39],consider:39,consist:[5,6,9,11,16,18,20,26,27,30,35,40],consol:[24,33,35,38],consortium:16,constant:[2,29,39],constantli:27,constraint:[11,27,30,39],construct:[],constructor:[7,10,11],consum:[1,3,9,10,16,26,30,33,36,39,42],consumingtx:42,consumpt:[10,27],contact:[11,26,30],contain:[3,5,6,7,8,9,11,16,21,22,24,25,26,27,28,30,31,33,36,37,39,40,41,42,43],content:[2,3,7,8,9,10,12,15,24,27,36],context:[2,9,24,26,27,36,42],continu:[],contract:[],contractreject:41,contractst:[3,10,21,29,30,36,38,39],contrast:[9,11,27],contribut:36,control:2,conveni:[2,9,36,39],convent:[5,11,40],convers:[25,36],convert:[3,4,5,12,26,29,30,36,39],convinc:[11,21,36],coordin:6,copi:[2,9,11,22,24,26,37,39,41,42,43],copycat:32,copyonwritearraylist:2,copyright:2,copyvault:20,corda:[],corda_dev_ca:6,corda_gradle_plugins_vers:8,corda_vers:8,cordacadevpass:[6,35,38],cordapluginregistri:[7,8,38],cordarpccli:[1,38],cordarpcop:[1,11,38],cordarpcopsimpl:26,core:[4,7,8,9,11,15,20,24,26,27,29,30,36,37,39,41],corner:15,correct:[4,9,11,15,27,30,31,39,41],correctli:[9,11,15,16,26,27,30,39],correspond:[1,16,20,33,36,39],correspondingli:[2,37],cost:[1,27,39],could:[2,3,4,9,11,20,27,34,36,39],couldn:21,count:[5,33],countabl:30,counter:[2,11],counterparti:[4,5,16,18,33,34],countri:[27,36],coupl:[11,12,20,38],cours:[11,20,24,27,29,39,43],coven:39,cover:[3,4,9,11,18,27,36,39,43],cpu:20,crash:[11,26],creat:[],createcommand:42,createdummyirs:5,createsomenod:12,creation:[5,9,21,39],creator:27,credenti:25,credit:[18,30],crisi:18,crisp:39,criteria:4,critic:[9,31],crop:9,crypto:30,cryptograph:[16,21,36],cryptographi:[],csr:30,curl:24,currenc:[4,5,11,20,25,29,30,36,39],current:[1,2,3,5,6,8,9,10,11,17,19,20,21,22,23,25,26,27,28,29,30,31,32,34,36,38,39,41,42],currenti:23,currentstep:11,currenttim:11,currentwallet:[],curv:5,custodi:[12,36],custom:[1,3,7,11,24,26,29,30,33,36],customis:[1,29,38,43],cut:[],cutoff:20,cycl:[2,11,39],dai:[3,5,11,24,27,31,36],daniel:30,danks:30,dashboard:[24,25],data:[],databas:[],databaseschema:29,databasetransact:12,dataset:[5,18],datasourc:[6,35],datasourceclassnam:[6,35],datasourceproperti:[6,35],datastructur:20,date:[],dateoffset:30,daterollconvent:36,david:30,dcapsul:8,dead:22,deadlin:36,deal:[2,11,27,33,36,39],dealstat:36,debt:[4,18],debugg:8,decd098666b9657314870e192ced0c3519c2c9d395507a238338f8d003929de9:24,decd:24,decentralis:[9,27,30],decid:[15,21,27,29,39],decis:[3,9,39],declar:[2,6,7,26,41],dedic:2,dedupl:[26,30],defaultissu:39,defin:[2,3,7,9,11,12,19,20,24,26,29,30,36,38,39,40,41,43],definit:[3,11,16,30,36,39,40],delai:[5,27],deleg:[40,42],delet:[2,9,11,26,30,39],deliber:[9,41],deliv:[4,12,26,36],deliveri:[11,19,22,33],demand:[3,9,11,30],demo:[],demonstr:[14,18,30,33,43],denial:3,denot:21,dens:2,depend:[2,3,8,9,10,11,12,14,15,16,18,27,30,35,39],dependson:8,deploi:[8,16],deploy:[8,16,23],deploynod:[6,8,18,33],deployvisualis:23,deposit:[39,41],deprec:30,deregist:22,deriv:[5,11,16,29,30,36,39],describ:[2,3,9,10,11,17,18,20,21,26,34,36,38,39,42],descript:2,deserv:[20,31],design:[2,3,9,13,16,17,27,30,34,39,40,43],desir:[7,11,36],desktop:24,despit:[11,37,39],destroi:[4,9,39],destructur:39,detail:[],detect:2,determin:[4,5,10,15,16,39,40],determinist:[1,20],dev:[6,20,24],develop:[2,6,8,9,11,13,14,17,26,28,29,30,31,33,39],devic:[6,9],devis:9,devmod:[6,28,35],diagnos:35,diagram:[5,39],diamond:16,did:21,didn:[2,11,21,31,39],differ:[2,3,4,5,6,7,8,9,10,11,14,20,25,27,29,30,33,36,38,39,41],differenti:42,difficult:11,difficulti:40,digest:3,digit:[9,11,27,30,39],digitalsignatur:[11,27,42],dir:[28,35],direct:[2,16,26,29],directli:[1,2,11,12,16,22,24,26,30,36,38,39,40,42],directori:[0,6,8,15,18,20,24,26,28,33,35,43],directthreadexecutor:2,dirnam:8,dirti:39,disabl:[26,36],disadvantag:9,disagr:18,disambigu:29,discard:34,discov:9,discoveri:23,discuss:[9,11,36],disk:[11,22,30,36],disobei:27,displai:[3,33,38],disput:[3,5,39],disrupt:[20,22],disruptionpattern:20,disruptionspec:20,distinct:[2,35,40],distribut:[3,6,7,8,9,11,16,17,19,27,30,32],distrust:[3,11],divid:3,divis:36,dlog4j:24,doc:[0,1,2,17,30,38],docker:24,docsit:[0,31],doe:[2,3,4,5,6,8,9,10,11,12,17,18,19,24,26,27,28,29,34,39,41,42,43],doesn:[2,3,9,11,12,15,19,24,34,39,41,42],dokka:0,dollar:[36,39,41],dollars:[39,41],domain:[16,30,36,39],domicil:39,domino:18,don:[1,2,9,11,13,15,20,25,27,31,33,34,36,39,40,41],done:[0,1,9,11,12,14,20,21,28,30,33,38,39],dot:[5,21],doubl:[9,11,19,25,26,35,39],doubt:2,down:[2,6,9,11,20,25,37,39,40],download:[],downsid:[2,9],drain:[1,11],draw:[30,38],drawn:38,drive:[9,43],driven:33,driver:[6,24,29,30,38,43],driverdirectori:38,drm:27,dsl:[8,16,30,41],dt_socket:8,due:[2,3,5,9,10,11,13,14,18,26,29,39,40],dummi:[4,12,41],dummy1:12,dummy2:12,dummy_cash_issuer:41,dummy_notary_key:12,dummy_pubkey_1:[39,41],dummy_pubkey_2:41,dummycontract:[12,42],dump:38,duplic:[11,21],durat:[10,27],durationsecond:20,dure:[2,5,6,7,8,11,23,24,26,30,39],dynam:[7,9,30,39,43],each:[1,2,3,5,6,7,8,9,10,11,16,20,21,23,26,27,29,30,31,33,35,36,38,39,40,41,43],earli:[2,4,26,43],earlier:34,earliest:[5,10],easi:[2,9,13,27,30,39],easier:[2,8,11,14,30,39],easiest:[1,39],easili:[2,11,18,39],econom:5,ed25519:30,edg:38,edge:38,edit:[24,35],edition:[],editor:15,effect:[5,6,9,11,12,18,29,41],effort:14,either:[1,2,3,4,5,6,9,11,15,16,20,21,29,33,36,38,39,41,43],elbonia:36,element:[2,9,16,21,39,40],elimin:[19,30],els:[3,8,9,11,12,26,27,36,38,39,40,42],elsewher:7,email:11,emailaddress:28,embed:[6,7,9,19,21,24,27,30],embedd:22,emit:[1,30],emoji:37,empti:[6,30,39,41],emptyledg:41,emptyset:37,enabl:[6,7,8,26,37,40],enact:18,enc:20,encapsul:[2,36],enclos:2,encod:27,encount:[10,26],encourag:[29,37],encrypt:28,encumb:39,encumberedst:39,encumbr:[29,39],encumbranc:[],end:[2,3,5,9,11,17,20,26,27,31,40,43],endpoint:[8,22,24],enforc:[2,9,39],enforceverifyorfail:41,engin:18,english:[2,39],enjoy:30,enorm:11,enough:[2,11,12,18,39,43],ensur:[2,3,9,11,15,16,21,26,28,30,31,34,36,39,40],ensure:[3,15,18],enter:[8,18,41,43],entir:[3,5,9,11,17,26,27,39],entireti:5,entiti:[3,9,21,27,29,36,39],entri:[5,6,8,9,11,29,34,39],enumer:[5,29,33],environ:[2,8,11,14,27],envisag:39,equal:[3,11,30,36,39,40,41],equiti:29,equival:[2,5,25,26,32,36,39],especi:36,essenti:[24,26,27,39,40],establish:[10,14,22,33,35],etc:[2,3,4,5,11,16,18,19,25,27,30,31,35,36,39,40],euribor:[24,27],euro:36,evalu:[5,24,27,40],even:[1,3,9,11,13,18,21,26,27,29,30,39,41],event:[],eventu:[20,26,35],eventual:[3,31],ever:[2,9],everi:[1,3,7,9,11,20,21,22,26,27,29,30,31,33,34,36,39,43],everybodi:9,everyon:[3,27,39],everyth:[3,34,38,39,43],evid:27,evolut:9,evolv:[29,35,39,43],exact:3,exactli:[9,26,36,39],examin:[2,8,9,12,39],exampl:[],examplerpccordapluginregistri:38,examplerpcvalu:38,exce:20,excel:27,except:[1,2,7,11,34,39],exception:[2,11],excess:2,exchang:[5,11,16,26,36],exclud:[6,29],exclus:4,execut:[3,8,9,10,11,16,20,23,25,26,30,36,37,39],executor:2,exhaust:[26,30],exist:[2,3,4,5,6,8,9,10,17,23,26,28,29,30,36,38,39,41,43],exit:[4,6,12,25,26,28,30,38,39],exitcash:38,expand:25,expect:[1,2,4,6,10,11,20,26,28,29,30,31,33,34,36,37,39,40,41],expectedtypenam:11,expens:[1,2],experi:[8,14,30,31,43],experienc:9,experiment:[2,30],expir:28,explain:[2,10,11,20,23,28,30],explan:[2,23,38],explicit:[2,9,11,39],explicitli:[2,7,9,41],explor:[2,9,12,15,19,24,25,30,39,43],explorer:[],expos:[2,7,8,9,10,11,24,26,29,30,36,38,42],expose:36,exposur:[4,5,16],expound:14,express:[3,5,9,16,30,36,39,41],ext:8,extend:[2,3,7,8,11,13,25,26,30,36,39,40],extens:[2,7,11,16,23,24,26,30,34,36,39],extent:9,extern:[6,11,26,35,37,43],extraadvertisedserviceid:[6,26,32,35],extract:[9,24,27,33,36,39],extractcommand:40,extrem:[3,9,13,16,20],face:39,facevalu:39,facil:[16,26],fact:[2,3,5,9,11,16,27,35,39,41],factor:[5,9,18],fail:[7,37,39,40,41],failswith:41,failur:[11,16,37,41],fairli:[2,12,18],fake:43,fals:[2,6,11,12,27,35,36,39,42],famili:29,familiar:[1,9,39,42],famou:[9,30],fanci:39,far:[11,33,39],fashion:[2,18,29],fast:[9,12],fault:11,faultfind:[],fear:16,featur:[],fed:23,feed:[3,27],feedback:30,feel:[39,43],fetch:[22,24,26,27,37],fetchtransactionsflow:37,fetchtransactionsprotocol:[],few:[2,11,13,24,27,31,33,39],fiber:[11,26],field:[],file:[],fill:[2,11,33,39],filter:[2,20,21,29,30],filtercommand:21,filteredleav:21,filteredtransact:21,filterfun:21,filterisinst:39,finalis:[5,11,30],finalisetransact:[],finalityflow:[37,42],finalityprotocol:[],financ:[8,11,30,43],financi:[9,10,11,16,18,30,36],find:[0,9,11,12,13,14,17,19,24,34],fine:[1,9,41],finish:[11,30],fire:11,firewal:[],first:[1,2,3,5,6,8,10,11,12,13,14,15,16,22,24,27,28,29,30,33,36,37,38,39,40,42,43],firstli:[7,33,39],fit:[2,9],fix:[],fixabledealst:36,fixedleg:5,fixedlegpaymentschedul:5,fixedratepaymentev:5,fixingroledecid:10,fixingsessioninitiationhandl:10,fixof:[21,27],flag:[6,24,28,43],flat:29,flesh:36,flexibl:[3,9,36],flight:[1,9],floatingleg:[5,10],floatinglegpaymentschedul:5,floatingratepaymentev:5,flow:2,flowhandl:[11,38],flowlog:[10,11,26,38],flowlogicreffactori:[7,10],flowstatemachineimpl:26,flowtrack:11,flux:[8,43],fly:11,focu:21,fold:[2,38],folder:[0,6,8,26,28,33],follow:[0,2,3,6,8,9,10,11,14,15,20,23,24,25,26,28,32,33,39,40,41,42],font:2,foo:[2,38],foobrokenexcept:2,foot:34,fooutil:39,forc:[9,24,30,39,41],fordai:[10,27],foreach:38,forev:31,forget:[11,39],form:[1,3,8,9,10,11,21,26,33,39,40],format:[],former:38,formula:30,forth:[1,11],fortun:18,forward:[11,22,26,27,31,33],found:[6,11,14,15,24,27,31,36,43],four:[35,39],fourpmtimelock:39,fraction:36,frame:[2,11,18,26],framework:[],free:[3,9,11,14],freed:1,freeli:27,frequenc:5,frequent:39,fresh:[27,39,41],freshkei:11,freshli:36,friend:35,friendli:26,from:[0,2,27,30,31],fromcountri:36,front:39,frontend:19,frustrat:9,ftx:21,fulfil:[4,9],full:[2,3,4,6,7,11,18,21,22,23,26,38,39,40],fulli:[2,3,6,7,9,11,16,23,26,29,30,35,36],fullnodeconfigur:38,fullysign:11,fun:[3,10,11,12,20,21,27,29,37,38,39,40,41,42],fund:[9,18,39],fundament:[3,9,39],fungibl:[4,16,36,39,40],fungibleasset:[],further:[],futur:[],futuretransact:38,fuzz:30,gain:19,garbag:[1,2,11,24],gather:[20,39],gatherfrequ:20,gatherremotest:20,gavin:9,gcd:9,gear:31,gener:[],generatecount:20,generateiniti:12,generateirsandfixsom:5,generateissu:39,generatemappedobject:29,generatemov:39,generateredeem:39,generatespend:[11,39],generatetransact:38,genuin:2,get:[],getamount:41,getanynotari:42,getbefor:39,getbloomfilters:2,getclass:39,getcommand:[39,40],getcontract:39,getdummy_cash_issuer:41,getdummy_pubkey_1:41,getdummy_pubkey_2:41,getencumbr:39,getfacevalu:39,getfix:5,getflowtrack:11,getinput:[30,39],getinstat:30,getissuanc:39,getkei:39,getlegalcontractrefer:[39,40],getmaturityd:39,getmega_corp:41,getmega_corp_pubkey:41,getnotari:42,getnotarysignatur:11,getorthrow:12,getoutput:[30,39],getoutst:30,getowner:[39,40],getparticip:39,getprotocoltrack:[],getprotocolvers:1,getrequiredcommand:40,getresourceasstream:37,getresultorthrow:20,getsign:[39,40],getter:[29,39],gettimestamp:39,gettransact:12,getvalu:[39,40],getvaulttransactionnot:38,git:[],github:[0,6,14,15],giusepp:30,give:[3,8,9,12,22,26,30,37,39],given:[3,7,9,11,21,27,29,32,36,38,39,42],givenpric:11,glanc:25,global:[2,3,9,30,36],glue:11,gnu:0,goal:[2,9,16,19,31],goe:1,gone:[11,30,39],good:[2,11,12,21,39,41,43],got:[11,21,24],gover:39,govern:18,gps:3,grade:36,gradl:[],gradlew:[8,15,18,20,23,25,28,33,35,38],grain:1,grammar:2,granular:9,graph:[1,9,12,19,24,29,30,38],graphit:24,graphstream:38,great:[18,30],greater:2,greatest:9,green:15,grip:14,groom:9,group:[],groupclaus:40,groupclauseverifi:40,groupingkei:40,groupstat:[39,40],guarante:[16,31,36],guava:[2,39],gui:11,guidelin:[],hack:[9,30],had:[3,11,12,30,36,39],hand:[10,11,14,23,26,35,39],handa:30,handi:12,handler:[8,10,11,26],happen:[],happi:[33,37],hard:[2,9,11,31],harder:[9,34,39],hardwar:6,hase:5,hash:[3,9,11,12,16,19,21,24,27,30,36,38,39],hashcod:39,hashmap:20,haskel:30,hasn:20,hassl:11,hat:31,have:[1,2,3,4,5,7,8,9,10,11,12,14,15,16,17,18,19,20,21,22,24,25,26,27,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],haven:39,head:38,heap:11,hearn:9,heart:39,heavi:31,heavili:9,hedg:[4,5],heirarchi:2,held:[26,29,39],hell:11,hello:11,help:[2,9,10,11,23,33,39],helper:[5,7,11,26,36,39,42],henc:[3,5,9,26],her:39,here:[2,3,6,8,9,11,12,13,15,16,17,21,23,24,27,29,30,36,38,39,41,43],herself:38,hidden:[22,26],hide:[],hierarch:11,hierarchi:11,high:[9,11],higher:[1,2,3,24],highest:17,highli:30,highlight:30,histori:32,hit:[9,37],hoc:30,hocon:6,hold:[7,9,20,21,26,30],holder:[2,9,39],holidai:[5,27,36],home:[15,33],homepath:8,hood:41,hope:26,hopefulli:43,hospit:11,host1:20,host2:20,host:[6,8,20,23,26,28,35],hostandport:6,hostil:34,hostnam:35,hotspot:2,hour:11,hous:25,how:[],howev:[3,4,5,6,9,11,21,26,27,28,29,32,36,37,39,40,41],html:[0,2],http:[0,6,14,15,18,24,26,27,28,33,35,37,39,40,43],https:6,hub:[11,16],human:[3,6,9,11,27,33],hundr:11,hurt:11,icon:14,ide:[13,14,15,24,30],idea:[2,9,11,14,19,43],ideal:[11,39],ident:[3,6,9,11,12,16,17,20,21,22,27,30,36,41],identicon:30,identifi:[5,7,9,11,16,18,21,22,24,26,27,29,36],identiti:[],identityless:9,identityservic:26,ifmatch:30,ifnotmatch:30,ignor:[6,11,38,39,40],iii:7,illegalargumentexcept:[2,11,38,39,40,41],illegalstateexcept:[2,39,40],illustr:[23,36,39],illustrat:2,imag:21,imagin:[2,11,39],immedi:[1,9,26],immut:[2,5,9,27,39],immutabl:[2,9],immutablelist:39,imper:2,implement:[],impli:[11,29],implic:[3,9,11],implicitli:5,important:31,importattach:37,impos:[27,39],imposs:[9,21,27],improv:[30,31,39,40],improve:9,improvement:30,inact:26,inadvert:39,includ:[],include:7,inclus:21,incom:[26,30],incompat:41,incomplet:20,inconveni:39,incorpor:[14,27],increas:[2,18],increment:1,indent:2,independ:[3,18,27,29,33,40],index:[5,9,10,15,29,31,39,42],indexsourc:10,indic:[1,2,5,6,10,11,30,35,39],indicat:20,individu:[],indivis:36,industri:[13,14,16,18,24],inf:7,infer:41,influenc:24,info:[11,12,29,38],inform:[2,3,6,7,9,11,12,15,25,26,28,30,36,37,39],infrastructur:[1,9,12,19,24,26,30,39],inher:9,inherit:[2,39,40],initi:[3,7,11,15,18,20,26,30,33,35,38,43],initial:[],initialis:[12,23,26,29,42],inlin:11,inmemorynetworkmapservic:26,inner:40,inoutgroup:[39,40],input:[3,4,9,11,16,18,20,21,25,27,30,32,37,38,39,40,41,42],inputcash:41,inputindex:42,inputst:42,insert:[2,3,12,24,26,27,29],insid:[1,7,9,11,12,21,26,33,34,39],inspect:20,instal:[0,6,8,10,14,15,30,33,38,39],installdist:[33,38],instanc:[],instance:41,instant:[2,10,11,36,39],instanti:[7,9,10,11,24,30],instat:41,instead:[2,9,11,12,19,22,26,30,36,39,42,43],instigat:3,institut:9,instruct:[14,15,16,24,37,39],instrument:[4,5,10,26],insuffici:9,insufficientbalanceexcept:39,integ:[1,30,36,39,42],integer:39,integr:[2,6,9,11,14,15,18,21,24,27,29,30,37],intellig:2,intend:[2,4,8,9,11,12,17,24,25,26,27,29,34,36,41],intent:[7,23,27,30,39],intention:2,inter:30,interact:[1,2,9,11,12,22,27,30,39],interchang:[16,36],interest:[],interest_r:[6,35],interfac:[],interior:30,interleav:20,interledg:30,intermediari:[18,36],intern:[2,7,8,11,22,24,26,29,30,36,39],internalis:2,interop:[13,30,39],interoper:26,interpol:36,interpret:[2,9,20],intersect:39,interv:[20,36],intervent:26,intesa:30,introduc:[2,3,10,16,27,30,39],introductori:17,intuit:[2,25],invalid:[3,11,27,36,39],invari:[20,39],investig:11,invoc:[1,11],invoic:37,invok:[1,2,7,9,10,11,24,26,30],invoke:11,invokeflowasync:[],invokeprotocolasync:[],involv:[3,4,9,11,26,32,36,39,42,43],ipsa:27,irrelev:10,irs:[],irsdemo:[6,21,33],irsexport:5,irstest:5,irsutil:5,isbefor:39,isconsist:20,isda:[18,30],isempti:39,isinstanc:11,isn:[1,2,9,11,34,36,39,43],isnotari:38,isnotempti:37,isol:40,issu:[],issuanc:[4,36,39,40],issue:[4,16,20,38,39,40],issuecash:[20,38],issuedbi:41,issuer:[4,9,11,12,25,36,39,41],issuer_kei:29,issuer_ref:29,issueref:38,issuerparti:29,issuerref:29,issuetransact:42,item:[16,39],iter:[11,30,31,39],iterabl:[29,38],itself:[1,3,5,6,9,10,11,18,22,24,26,27,29,30,35,37,38,39,41],jar:[0,6,7,8,9,23,24,28,30,35,37],jarandsourc:8,java:[1,2,7,8,9,10,11,13,14,16,24,26,28,29,30,35,36,37,38,39,40,41,43],javaclass:[11,29],javacommercialpap:39,javadoc:[2,8],javadocjar:8,javafx:30,javatesthelp:41,javax:29,jax:7,jdbc:[6,8,24,29,30,33,35],jdbcdatasourc:[6,35],jdbcx:[6,35],jdk1:15,jdk:[14,15,30,36,39],jdwp:8,jetbrain:[13,14,15],jms:22,jmx2graphit:24,jmx:24,jmxtran:24,job:[11,20,43],jobs:20,johann:30,join:[6,22,29,30,39],jolokia:24,jpa:29,json:[6,24,26,43],judgement:2,jump:33,just:[1,2,9,11,15,18,20,22,24,30,33,34,36,37,38,39,41,42,43],jvm:[],kdoc:2,keep:[9,11,39],kei:[],kept:[11,28,42],keymanagementservic:[11,26],keypair:[11,26,39,42],keystor:[6,26,28],keystorepassword:[6,35,38],keyword:[2,41],kick:11,kill:20,kind:[9,11,17,27,34,36,39,43],knob:20,know:[1,3,9,10,11,12,13,21,27,33,34,39,40,41,42],knowledg:27,known:[5,9,12,14,16,18,21,26,31],koan:14,korea:39,kotlin:[],kryo:[],label:[11,41],lack:[],lambda:[11,24,41],land:5,lang:[7,41],languag:[1,2,8,9,11,13,14,15,16,30,36,39,43],larg:[9,11,22,27,30,33,36,37,39,43],larger:[2,9,34],last:[11,20,31,41],lateinit:12,latenc:3,later:[1,2,11,12,14,19,27,29,30,34,35,36,38,39,40],latest:[2,14,15,30],latex:30,latter:[2,38,39],launch:10,layer:[6,9,11,12,22,26,27,29,30,32],layout:[8,23],lazili:24,ldap:30,lead:[2,9],leader:6,leaf:[16,21],leak:[1,3,9,11],learn:[9,11,12,13,17,33,36,39,43],least:[6,17,20,37,39],leav:[2,11,21,25,36],ledger:[3,4,5,9,11,16,17,24,27,29,30,33,35,36,37,39,41],ledgertransact:[11,30,36],leewai:34,left:[11,23,28,33,40,41],leg:[5,10],legaci:26,legal:[3,6,9,26,27,28,36,39,42],legalcontractrefer:[39,40],legalident:[12,38,42],legalidentitykei:42,legallyidentifi:[11,27],less:[11,30,37],lesser:39,let:[2,9,10,11,12,20,21,22,24,27,30,33,36,37,38,39,41,42],letmein:[6,35],letter:[2,22],level:[2,3,5,7,11,15,17,18,20,21,22,24,25,26,34,36,39,40,41],lib:[0,8,23,28,35],liber:2,libor:[5,24,27],librari:[1,2,6,11,16,17,18,24,26,27,30,36,38,39],licens:[2,18],life:[11,39,43],lifecycl:[],lifecyl:4,lifetim:[5,7],lightweight:[12,16],like:[1,2,3,5,9,10,11,12,14,20,21,22,23,24,27,30,31,36,38,39,40,43],likewis:39,limit:[4,9,16,20,39,42],line:[],linear:[26,36],linearst:36,liner:2,link:[2,9,11,27,30,35,36],linkabl:9,linkag:9,linux:[8,24,30],list:[0,6,7,9,11,20,21,26,27,29,30,31,32,33,36,38,39,40,42],listen:[2,26,38],listenablefutur:[],listof:[12,29,38,39],liter:9,littl:[2,11,39,41],live:[5,7,11,18,26,30],livelock:9,lizard:16,llc:28,load:[],loadtest:20,loan:[4,5,27],local:[0,6,7,8,9,11,15,16,20,23,24,26,29,30,41],localcertificatesbasedirectori:20,locald:27,localhost:[6,18,24,25,33,35],localtunnelstartingport:20,lock:[2,4,6,29,39],log4j2:[24,35],log4j:30,log:[],log_sender:37,logger:[11,24],loggerfor:24,logic:[3,9,10,11,12,16,22,29,30,34,36,37,39,40,43],logictyp:38,login:[8,25,38],loglevel:24,london:[6,8,28,35,37],longer:[2,5,6,11,28,30],longrang:20,look:[2,5,11,12,20,22,24,27,31,33,36,37,39,40,41,43],lookup:6,loop:[2,5,20,38,39],loquitur:27,loss:27,lot:[2,5,9,14,30,33,34,39,43],low:[3,11],lower:2,lowest:[17,22],lurch:11,mac:[15,24,33],machin:[],macos:8,made:[2,5,9,11,26,30,31,36],magicnumb:42,mai:[1,2,3,8,9,11,14,15,16,17,20,22,23,24,26,27,29,30,31,34,35,36,38,39,40,41,43],mail:[31,33],mailbox:26,main:[6,10,11,14,20,22,26,28,30,37,38,43],mainstream:19,maintain:[3,9,16,39,42],maintan:27,mainten:22,major:[11,31],make:[],maker:13,maketransact:12,malici:[11,34],manag:[],mandatori:39,mani:[2,3,8,9,10,11,12,20,27,30,36,37,39],manipul:36,manner:[9,11,30,39],manual:[8,10,11,23,42],map:[],mapchang:38,mappabl:39,mappedschema:29,mappedtyp:29,margin:[],mark:[1,2,4,11,16,29,39],markdown:2,marker:[11,34],market:17,marshal:1,master:[17,31],match:[1,9,11,21,34,36,37,40],math:[],mathemat:36,matter:[11,18,39],matur:[3,4,5,23,24,27,39],maturityd:39,maven:[8,15,30,39],mavenloc:8,mavenpubl:8,maximis:9,maximum:9,maybestx:11,maybetraderequest:11,mbean:24,mean:[1,2,3,7,9,10,11,12,14,16,18,20,21,27,36,38],meandref:38,meaning:[3,4],meaningfulli:37,meant:[11,20],meanwhil:38,measur:[5,18],mechan:[7,16,30],meet:[26,39],mega_corp:[12,41],mega_corp_key:12,mega_corp_pubkey:41,megacorp:12,member:[5,6,30,33],memori:[11,12,22,26],menlo:2,mention:[10,11,14,39],menu:14,mere:5,merg:[9,30,36,39],mergeabl:39,merkl:[],merkleroot:21,merkletreeexcept:21,mess:11,messag:[],messagingserveraddress:[6,26],messagingservic:[22,26],met:[7,36],meta:7,metadata:[37,42],method:[1,2,3,6,7,10,11,12,20,24,26,29,30,34,35,36,39,42],metric:[18,24],micro:[30,40],mid:3,middl:[2,11],middlewar:[16,26],might:[2,5,9,11,15,27,29,34,39],mike:9,mileston:[],min:38,mind:[2,11,27],mine:9,miner:9,mini_corp_pubkey:12,minim:[9,11],minimis:[3,4,9,22],minimum:[1,5,9,36],minor:[30,31],minu:39,minut:[11,13,27],mismatch:[9,39,41],miss:[2,6,11,15,29,39,41,42,43],missingsig:[],mission:24,mistak:[30,34],mix:[2,30],mock:12,mocknetwork:[12,23],mocknod:[12,26],mockservic:36,mode:[6,23,28,30],model:[],modest:9,modif:[26,36,39],modifi:[3,4,5,7,8,11,15,16,36,39,40],modul:[2,6,12,30,39],moment:[11,12,30],monei:[27,39],monitor:[],month:[5,11,31],more:[1,2,3,4,5,6,8,9,11,12,13,14,15,16,18,21,23,24,26,27,28,29,30,32,33,36,37,38,39,42],moreexecutor:2,mortensen:30,most:[2,5,9,11,14,23,24,35,39],mostli:39,motiv:17,move:[4,7,9,11,12,25,30,31,33,38,39,40,41,42],movement:[11,39],movetransact:42,movetransactionbuild:42,much:[2,9,11,13,29,30,33,34,39,43],multi:[],multigraph:38,multilater:[4,30],multipl:[],multipli:5,must:[1,2,3,4,6,7,8,9,10,11,24,26,27,29,30,34,35,36,37,39,40,43],mustafa:30,mutabl:[2,9,36,39],mutat:[9,26],mutual:[3,4,11,34],myfil:24,myident:42,myinfo:42,mykei:36,mykeypair:11,mylegalnam:[6,28,35],mypublickei:11,mysigningkei:42,mysql:19,nail:2,namedbyhash:[],nameserv:6,namespac:11,narrow:[2,25],nativ:[11,14],natixi:30,natur:39,naval:3,navig:[8,18,33],navistar:3,nearestc:[6,8,28,35],neat:41,necessari:[2,3,16,30,31],necessarili:[29,36],nee:30,need:[0,2,3,5,7,9,10,11,12,14,15,16,18,20,21,24,26,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],neg:36,negoti:[9,36],neither:11,nest:11,net:[4,5,6,7,8,11,12,24,26,28,29,30,32,35,37,39,41],network:[],networkmap:8,networkmapaddress:[6,8,35],networkmapcach:[6,7,11,26,38,42],networkmapservic:[],networkmapupd:38,neutral:19,never:[2,3,9,16,39],newli:[10,42],newnotari:3,newowner:[39,42],newsecurerandom:30,next:[2,5,10,12,15,21,23,30,34,39,42],nextdoubl:38,nextfixingof:10,nextlong:38,nextscheduledact:10,nfinal:37,nice:[27,39],nio:2,noddi:24,node:[],node_dir:8,node_directory:35,nodea:[6,8,35],nodeb:8,nodefilt:20,nodehandl:20,nodehost:20,nodeident:38,nodeinfo:[6,11,26,38],nodeinterestr:[7,27],nodeservic:27,nodesslconfigur:38,nodisruptionwindowm:20,non:[],none:[10,11,18,21,29,40],nonemptyset:30,nordea:30,normal:[1,4,5,7,8,11,20,21,23,26,30,36,37,39,40,42],north:39,notabl:2,notaris:[3,9,11,17,30,33,36,39],notary:11,notary_committed_states:33,notarychang:30,notarychangeflow:3,notarychangeprotocol:[],notaryclusteraddress:[6,26],notaryexcept:42,notaryflow:[11,26,42],notaryident:[11,12,38],notarynod:[11,12],notarynodeaddress:6,notaryprotocol:[],notaryservic:[],notarysig:11,notarysignatur:[11,42],notarytous:36,note:[],noth:[2,9,10,11,30,34,39],notic:[2,33],notif:[20,22,26,37],notifi:[22,23,42],notion:[5,9,30,39],notnul:[39,40],now:[2,8,9,11,12,17,21,24,30,33,35,36,38,39,41,42,43],nugget:39,nullabl:39,nullpublickei:39,number:[2,4,5,7,9,12,16,18,20,25,26,27,29,31,33,35,36,39],numer:[7,9],obj:39,object:[],oblig:[4,5,30,36],obligor:4,observ:[1,3,5,9,10,11,20,23,30,38],observatori:3,obsolet:[10,30],obtain:[],obviou:[2,3,9,27],obvious:[5,16,23],occasion:[14,15],occur:[3,10,11,26,39],occurr:3,odd:39,off:[],offer:[11,15,26,29],offlin:22,offset:5,often:[2,4,5,9,11,15,27,39],oftenor:27,oil:[30,41],old:[3,11,16,30,39,42],omit:[10,18],onc:[1,2,3,7,11,16,28,31,36,39],once:[0,5,8,10,11,16,23,28,29,33,35,36,37,39,43],onchainasset:4,one:[3,15,21,33],ongo:1,onledgerasset:39,onli:[1,2,3,5,6,8,9,10,11,13,16,21,22,23,24,25,26,27,28,30,31,33,34,35,36,39,40,42,43],only:[11,26,35],onto:[1,2,11,39],opaquebyt:38,open:[1,3,8,9,11,15,18,24,26,30,33],openattach:37,opengamma:[18,30],openjdk:[],openssl:20,oper:[5,6,10,11,14,16,24,26,27,30,34,35,36,39,42],opt:[8,20],optim:2,option:[0,2,5,6,10,11,16,20,23,28,29,30,39,40,42,43],oracl:[],orchestr:[19,30,43],ordain:5,order:[0,1,2,3,4,5,9,11,15,18,19,20,23,26,27,29,30,33,35,36,37,38,39,40],ordinari:[9,11,30,39],org:[0,6,35,39,40],organis:29,orient:[],origin:[21,29,30,36,37,39],originalst:3,orm:29,otc:29,other:[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,20,21,23,25,26,27,28,29,30,33,34,35,36,37,39,41],otherparti:11,othersid:[11,37],otherwis:[1,2,6,7,8,10,11,26,34,38,39],our:[2,3,9,10,11,12,13,14,20,21,26,30,31,33,36,38,39,41,42],ournotari:42,ourselv:[11,39,42,43],oursignatur:11,out:[2,3,4,9,10,11,14,18,21,22,24,26,27,30,31,32,34,36,38,39,40,42],outcom:11,outer:40,outermost:40,outlin:[9,11],outpoint:9,output:[3,4,8,9,11,16,21,25,27,30,33,37,38,39,40,41,42],outref:12,outsid:[8,9,11,26,27,35,43],outstand:4,over:[2,3,5,6,8,9,11,12,16,20,21,22,24,27,29,33,36,39],overal:[3,10,41],overdu:10,overflow:2,overidden:[6,8],overload:[11,36],overlord:16,overnight:36,overrid:[7,10,11,20,29,38,39,40],overridden:7,overutilis:20,overwhelm:9,own:[2,3,4,8,10,11,14,20,23,24,25,26,27,29,30,31,36,41,43],ownablest:[11,36,39],ownedquant:38,owner:[10,11,29,36,39,40,41,42],owner_kei:29,ownership:[11,12,39,42],owningkei:[11,21,39,42],ozturk:30,p2p:30,pack:39,packag:[7,14,29,30,36],packet:9,page:[15,27,31,33],pai:[],paid:[4,5,9,18,39],pair:[9,11,12,26,28,36,38,39],paragraph:20,parallel:[1,9,20,27],parallelis:9,param:[20,29,42],paramet:[1,2,7,10,11,20,24,36,39,40],parameteris:[9,20],parent:[11,16],pars:[6,27,36,39,43],part:[1,2,3,4,8,9,10,11,17,20,21,26,28,29,30,33,34,35,36,39,43],parti:[],partial:[3,9,11,21,34,39,41],partialtx:[11,21],particip:[3,9,25,26,30,39,42,43],particular:[],partner:18,partyandrefer:[2,38,39],partynod:12,partyrefer:[2,39],pascal:2,pass:[7,11,20,21,24,26,29,33,37,39,40,42],password:[1,6,8,24,25,28,30,35,38],past:[2,33,39,43],patch:[2,30],path:[2,6,7,8,10,15,20,22,24,30,38,39],path_to_loadtest_conf:20,pattern:[2,9,38],paus:[8,23],paycash:38,paye:9,payer:[5,9],payment:[4,5,9,10,11,16,18,27,33,39],pdf:[27,37],peer:[11,19,21,25,26,27,39],penni:[29,36,39],peopl:[2,9,11,13,16,39],per:[],perform:[2,3,5,9,10,11,14,16,18,20,27,30,33,36,37,39,40],perhap:[2,9,22,35,39],period:[5,28,33],perman:[11,37,39],permiss:[1,6,17,19,30],persist:[],persistentcashst:29,persistentst:29,perspect:[9,11,26,39],phase:30,phrase:27,physic:[3,26,30,35],pick:[11,22,30,31,39,43],piec:[2,3,9,11,16,20,35,36,39,41],pip:0,pki:[9,30],place:[0,2,5,9,10,11,14,18,19,21,22,27,30,31,33,36,38,39,43],plai:[],plain:6,plan:[9,11,27,30],platform:[3,5,7,8,9,10,11,13,14,21,27,33,34,36,39],pleas:[2,9,29,30,33,37],ploadtest:20,plu:[6,26,36],pluggabl:30,plugin:[],pluginservicehub:[7,11,26,30],point:[1,2,3,4,7,8,9,11,16,20,24,26,27,29,31,34,38,39],pointer:[3,11,36],pointless:2,polish:30,polit:18,poll:[20,28],pool:[2,9],poor:9,pop:15,popul:26,popular:13,popup:15,port:[6,8,20,25,26,30,31,35],portfolio:[],posess:11,posit:[2,9,11,39,42],possess:[3,42],possibl:[9,11,14,18,20,26,27,28,37,39],post:26,postgr:19,potenti:[2,3,11,13,18,39],pound:[36,39],power:[6,9,26],practic:[6,9,18,30,39],pre:[0,5,11,12,28,39,41,43],preced:39,precis:[3,9,19],precondit:[2,39],predict:20,predominantli:14,prefer:[2,15,25,29],prefix:[2,29],preliminari:18,prepar:[9,30,39],prescrib:35,present:[1,3,4,5,6,7,8,11,19,20,23,29,30,32,33,36,39,40,42],preserv:[3,9],press:14,pretend:[24,36],pretti:[9,11],prevent:[18,34,39],previou:[9,11,20,30,36,41,42],previous:[5,10,27,30,42],price:[9,11,27],primari:[14,27],primarili:4,primit:[36,41],print:[1,24,30,33,34,35,38],println:[37,38],printorvisualis:38,prior:42,priv:[],privaci:[2,3,9,11,19,30,39],privat:[2,6,7,9,11,12,28,29,35,37,39,43],privatefoo:2,privatekei:[11,26],probabl:[39,43],problem:[3,9,11,14,15,27,35],proce:11,procedur:[11,28,39],process:[],processor:[9,20],produc:[0,10,23,39,41],product:[2,8,10,13,14,18,19,30,31,35,36],profound:9,program:[1,2,9,24,26,30,33,36,39,43],progress:[],progresstrack:11,project:[8,14,15,17,18,26,28,30,33,39],prolif:30,promis:30,prompt:14,proof:[4,9,21],propag:[1,11,24,39,40],properli:[11,26,34],properti:[],proport:18,propos:[11,17,26,34],proprietari:[18,30],prose:[27,36,39],prospectus_hash:37,protect:[11,18,26,28],protocolhandl:[],protocollog:[],protocollogicreffactori:[],protocoltrack:[],protocolvers:1,prototyp:[2,19,27,30,32,39],prove:[3,9,39],proven:18,provid:[0,1,2,3,4,5,6,7,8,9,11,12,14,16,20,21,22,23,24,25,26,27,29,30,32,33,34,35,36,39,42,43],provision:36,proxi:[1,38],pseudo:27,pseudonom:36,ptx:[11,37],pubkei:41,publicfoo:2,publickei:[],publickeytre:[],publish:8,pull:15,punish:27,purchas:[11,33],pure:[4,9,27],purpos:[3,4,7,11,16,29,32,36,38,39],push:[1,31],put:[],python:0,qualifi:[6,7,29],quantiti:[9,20,36,38,39],quasar:[7,8,11,16,26],quasarscan:[],queri:[1,5,6,7,10,26,27,29,30,33,35,38],queryablest:[26,29],question:[2,3,10,15,27,36],queu:[16,22],queue:[1,2,11,22,26],quick:27,quickcheck:30,quickli:[9,16,28,34,39],quit:[1,2,3,11,14,39],r3cev:20,r3corda:8,r3dlg:31,r3prototyp:0,r3repositori:[],raft:[6,26,30,32,33],rais:[3,40],random:[9,10,20,30,33,36,38,42],randomis:30,randomli:[20,38],rang:[3,29],rapid:[2,8,19,31],rare:[6,36],rate:[],ratesfixflow:21,ratesfixprotocol:[],rather:[2,9,11,22,23,30,35,38,39],raw:[22,24,33],rdbms:[29,30],rdms:30,reach:[3,5,9,10,18,27],reachabl:11,react:20,reactiv:30,read:[2,6,8,9,11,13,17,19,21,24,26,30,33,39,43],readabl:[6,11,13,33],readi:[31,39],readili:[36,40],readme:2,real:[2,18,23,27,28,30,36,39,43],realis:11,realist:36,realiti:5,realli:[2,3,9,11,21,39],reason:[2,3,5,9,11,14,20,30,34,36,39],reassign:39,recal:5,receipt:26,receiv:[1,4,5,7,9,11,16,18,20,26,27,30,31,33,34,37,39],receiveandcheckproposedtransact:11,receiveandvalidatetraderequest:11,receiving:11,recent:[14,30],recipi:[4,9,33,37,39],recognis:[7,9,11,14,39],recommend:[2,14,22,32,33,43],record:[3,10,12,16,26,29,37,38,42],recordtransact:[12,26,42],recreat:11,red:[5,21],redeem:[4,39,40],redempt:39,redesign:30,redirect:35,reduc:[2,8,18],redund:2,ref:[11,12,36,38,41],refactor:30,refer:[2,3,4,5,6,7,9,10,11,14,16,18,26,27,30,32,36,37,39,41,42],referenc:[3,37],refin:30,reflect:[11,17,20,30,39,40],refresh:[14,30],refus:15,regard:[3,7,14,35],regardless:11,regener:[5,31],regist:[],registerflowiniti:[7,11],registerprotocoliniti:[],registerrpckryotyp:[7,38],registr:[7,26],registri:7,regul:39,regular:[11,16,24,33,35,36,39],reissu:39,reissuanc:9,reject:[26,39],rel:[6,8,9,13,14,40],relabelablestep:11,relai:37,relat:[],relationship:[26,39],relax:[20,30],releas:[],relev:[7,8,9,10,16,17,26,30,36,39,40,42],reli:[1,8,9,18,30,34],reliabl:26,relianc:9,relic:24,religi:2,remain:[8,10,11,39],remeb:[],rememb:[2,10,15,34],remind:[11,34],remot:[6,7,8,15,20,23,26,35,37],remotemessagingport:20,remotenodedirectori:20,remotesystemdservicenam:20,remov:[11,21,30,31,38,39],renam:[11,30],render:[2,11,23,25,30],renderifsupport:37,repeat:[2,5,11],replac:[1,3,5,14,18,24,30,31,36,38,39],replai:30,replic:[6,9,32,33],repoint:3,report:[11,25,40],repositori:[2,8,14,15,30,31,33],repres:[2,4,5,9,11,20,26,27,29,30,36,38,39],represent:[1,5,29],request:[1,3,6,7,9,11,17,20,22,26,27,30,34,37],requestingparti:42,requiredcommand:[30,40],requiredflow:7,requiresinglecommand:[39,40],requirethat:[39,40],research:30,resel:27,resend:26,resent:26,reset:[5,23],reshap:9,resid:26,resolut:[9,11,42],resolv:[2,11,12,18,35,36,39],resolvefromtwohash:[],resolvetransactionsflow:[11,12,37],resolvetransactionsflowtest:12,resolvetransactionsprotocol:[],resolvetransactionsprotocoltest:[],resourc:[1,6,7,9,11,20],respect:[2,9,11,33],respend:9,respond:[11,26],respons:[1,3,7,9,10,11,22,26,29,38,42],rest:[3,7,9,11,19,24,30,43],restart:[11,26,28],restor:[11,16],restrict:[2,18,23],restructur:40,restructuredtext:0,result:[2,3,5,6,9,11,12,18,25,26,27,28,29,30,34,38,39,40,42],resultfutur:12,resum:[11,26,28,30],resurrect:11,resync:14,retain:22,rethrown:1,retri:[11,19,22],retriev:[5,11,28,32,37,38],retrieveoutput:41,reus:[1,9,41],reusabl:[16,27,30,37,39],reveal:[3,9,11,21,30],revers:[11,26],revert:4,review:[2,30,31],revis:[5,15],rewrit:11,richer:8,right:[2,11,14,15,24,30,31,33,34,43],rightmost:21,rigid:9,rigidli:2,risk:[11,18],robert:30,robust:30,role:[9,10,26,33,37,43],roll:[5,11,30,33],rollov:[36,39],root:[6,8,21,26,28,31,35],rotat:[24,30],roughli:[3,31],rout:[11,12,14,22,30],row:[24,25,29,33,36,39],rpcexception:1,rpckryo:1,rpcreturnsobserv:[1,38],rpcsincevers:1,rpcuser:[6,25,35,38],rui:30,ruin:41,rule:[2,11,18,26,27,30,39],run:[],runbuy:33,rundemonod:[25,30],runnetwork:12,runnod:[8,18,33],runparamet:20,runrecipi:[33,37],runsel:33,runsend:[33,37],runshellcommandgetoutput:20,runtim:[2,11],safe:[1,2,7,9,11,28,34,38],sai:[2,3,9,14,18,20,33,35,39,42],sake:18,sale:[33,39],same:[1,2,3,4,5,6,8,9,10,11,20,26,27,30,36,39,40,41],sampl:[7,8,11,18,23,30,33],sanction:39,sandbox:[9,10,19,30,34],saniti:11,santiago:30,sate:42,satisfi:[33,36,39],save:[2,11,30,39],scala:[13,39],scalabl:[2,9],scale:[5,34],scan:[],scenario:[9,23,26,36,43],scene:[11,39],schedul:[],schedulablest:[10,26],scheduledact:10,schedulerservic:26,schema:[],schemafamili:29,schemaopt:29,schemaservic:29,scheme:[21,26],scope:[7,9,25,40],scotiabank:30,scrape:24,scratch:[36,39,43],screen:[2,15,25,30,39],script:[0,8,9,33],scroll:33,scrub:11,seamless:13,search:[25,26,39],second:[5,7,11,12,20,33,36,39],secondari:11,secp256r1:30,secret:6,section:[6,9,17,20,30,31,42],securehash:[12,21,36,38,39,40,42],securerandom:30,see:[0,1,2,3,4,5,6,8,10,11,12,14,15,20,21,23,27,28,29,30,32,33,35,36,37,38,39,40,43],seed:11,seek:[9,30],seem:9,seemless:14,seemlessli:14,seen:[2,5,7,11,27,39],segment:8,select:[3,14,15,29,30,39,40],selectschema:29,self:[8,20,30,33],selfissuecommand:20,selfissuest:20,selfissuetest:20,sell:[11,39,43],seller:[],sellerownerkei:11,sellersig:11,sellertradeinfo:11,semi:9,send:[2,3,9,11,12,21,22,24,26,27,30,31,33,37,39,41,42],sendandrec:11,sender:[9,11,33,37],sendsignatur:11,sens:[5,27,39],sensit:[10,18,21,34],sent:[10,11,30,36,39],separ:[3,6,7,8,9,11,21,22,24,27,33,36,39],septemb:18,sequenc:[9,26,30],sequenti:11,seri:11,serial:[1,19,26,39],serialis:[1,2,7,9,11,16,19,39],seriou:[9,31],serious:43,serv:8,server:[1,6,7,8,19,22,24,26,28,30,43],servicehub:[7,8,11,22,26,37,42],servicehubintern:[8,30],serviceinfo:38,serviceload:7,serviceplugin:7,servicetyp:[6,26,42],session:[10,22,26,30],sessionid:10,set:[],setof:[11,12,37,38,40,42],setter:[29,39],settim:[11,36],settl:[4,12,36,37],settlement:[4,11],setup:[8,10,12,23,28,35],sever:[6,8,9,11,26,29,32,33,35,38,39,41,43],sha256:[21,36,39,40],sha256sum:24,sha:[9,24],shape:9,share:[4,5,9,11,16,18,26,27,30,34,37,39,43],shasum:24,she:39,shell:[18,20],shoot:34,shortcut:19,shorthand:41,should:[2,3,4,7,8,9,10,11,15,17,18,19,20,21,26,28,29,30,33,34,35,36,38,39,40,41,43],shoulder:2,shouldn:[11,21,39],show:[9,13,15,23,25,26,30,33,39],shown:[1,6,11,12,23,36],shut:37,shutdown:[11,26],side:[1,9,10,11,14,23,27,33,34,36,37],sidebar:23,sidenot:35,sig:[30,39],sign:[3,5,6,9,11,12,16,17,19,21,22,26,27,30,34,36,41],signal:16,signatureexcept:[],signaturesfromsel:11,signedtransact:[11,12,36,38,39,42],signer:[21,27,33,39,40],signfirsttx:12,signific:[9,30],significantli:[5,20,36,37],signing:11,signoff:3,signwith:[11,12,36,37,39,42],signwithecdsa:11,signwithourkei:11,silver:2,similar:[2,9,11,30,39,40],similarli:29,simm:[],simmvaluationdemo:[18,33],simpl:[1,2,4,5,6,7,9,11,12,14,18,19,20,24,26,30,32,33,36,37,38,39,40,42],simplecash:41,simplecashdoesntcompil:41,simplecashfailswith:41,simplecashsuccess:41,simplecashtweaksuccess:41,simplecashtweaksuccesstopleveltransact:41,simplenam:29,simplenotaryservic:[],simpler:[9,13],simplest:[9,11,35,39,43],simpli:[2,8,9,11,12,20,22,26,29,30,32,36,39,41],simplif:30,simplifi:[2,4,9,26,32,36,39,43],simul:[],simultan:[9,11,36,39],sinc:39,singl:[],singlemessagerecipi:22,singleownerst:42,singleton:[7,11,39,40],singletonserializeastoken:7,site:[2,30,31],situat:[2,9,21],size:[2,5,9,11,38,39,40],skeleton:12,skip:[11,36,39],sl4j:24,sleep:[20,37,38],slf4j:11,slightli:[32,39],slip:31,slot:30,slow:[2,9,20],slowest:9,small:[1,9,10,11,27,33,34,39],smaller:[30,40],smallest:36,smart:[],smooth:39,snake:41,snapshot:[9,30,31,38],snide:0,snippet:11,socket:24,softwar:[9,11,31,34,43],sofu:30,sold:[11,36],solut:11,solv:[9,11,27],solvenc:27,some:[1,2,3,4,7,9,10,11,12,14,18,19,20,21,24,26,27,29,30,33,35,36,38,39,40,41,42,43],somed:39,somehow:20,someon:[3,9,39,42],someth:[1,2,5,9,11,30,33,39,40,43],sometim:[9,11,16,24,36],someusernam:20,somewhat:[1,9,11,20,30],somewher:39,soon:[30,39],sophist:9,sort:[11,27,30],sound:[2,11,39],sourc:[],sourcejar:8,sourceset:24,sparingli:2,spawn:7,speak:30,spec:30,special:[1,3,9,11,41],specif:[1,3,4,7,8,9,10,11,14,16,20,22,24,26,30,36,37,39,40],specifi:[0,1,2,3,4,6,8,9,11,16,19,20,21,28,29,30,35,36,39,40,41,42,43],speed:[9,11,13],spend:[9,11,12,19,26,34,35,39],spent:[9,39,41],sphinx:0,sphinx_rtd_them:0,spin:20,spirit:30,spline:36,split:[9,21,22,30,36,39,40],splittabl:39,splittablerandom:[20,38],spot:30,spread:[3,11],spreadsheet:27,sql:[19,29,30,33],src:[6,11,26,37,43],ssh:20,sshuser:20,ssl:[6,30],sslconfig:38,sslkeystor:[6,28],stabilis:31,stabl:[1,7,31,38],stack:[11,26],stage:[2,4,11,36,39,43],stai:[9,26,39],stake:9,standalon:[23,27,30],standard:[2,7,8,11,14,16,18,23,24,26,30,33,35,36,38,39,40],standardis:[9,36],start:[],startflow:[11,12,37,38],startflowdynam:[11,38],startflowpermiss:38,startnod:38,startprotocol:[6,35],startprotocoldynam:[],startprotocolpermiss:[],startup:[6,7,24,30],startwith:38,state:[],stateandref:[3,11,36,38,39,42],statehistori:42,stateless:9,statemachineinfo:38,statemachinemanag:[],statemachinerecordedtransactionmap:38,statemachinerunid:11,statemachinesandupd:38,statemachinetransactionmap:38,statemachineupd:38,statement:[2,9,11,27,39],stateref:[9,10,21,29,36,42],statesoftyp:39,staticservedir:7,statist:24,status:9,stem:39,step:[],still:[3,9,10,11,15,23,27,30,39,43],stock:[9,27],stone:20,stood:29,stop:[2,11,26,37],stopnod:12,storag:[],storageservic:37,store:[3,6,8,11,12,24,26,28,30,32,33,36,37,39,42],stori:[2,30],straightforward:[11,39],strain:20,straincpu:20,stream:[1,11,22,23,30,38],stress:[2,20],strictli:[5,7,9],string:[6,11,20,27,29,33,36,38,39,42],strip:39,strong:13,strongli:14,structur:[2,7,9,11,15,16,19,21,27,30,36,39],stub:[18,30],studi:39,stuff:2,stx1:12,stx2:12,stx:[11,36],sub:2,subclass:[4,11,29,36,39],subclaus:40,subdirectori:24,subflow:[3,7,11,26,42],subfold:[7,26],subgroup:9,subject:[6,8,16,18],submiss:27,submit:[2,3,11,20,22,28,30,33],subproject:[],subprotocol:[],subscrib:[1,22,30,37,38],subsequ:[16,28,33,39,41],subset:[4,21],substitut:6,subsystem:[7,22],subtask:11,subtl:[2,9],subtract:36,subvert:34,success:37,successfulli:[35,38],successor:[3,10,13],succinct:2,sudo:0,suffer:[9,18],suffic:11,suffici:[9,27,31,33,36,38],suggest:[8,14,22,39],suggestinterestrateannouncementtimewindow:10,suit:[30,37],suitabl:[10,22,26,31],sukrit:30,sum:[18,20,38,39,41],sumcashbi:[11,39],summari:[],summaris:9,sun:2,superclass:[4,30,36],superior:2,supersed:9,supertyp:39,suppli:[4,20],support:[],supportedschema:29,suppos:[11,39],suppress:[2,30],suppresswarn:2,sure:[3,30,31,34,37,39,43],surfac:11,surround:2,surviv:11,suspend:[],suspens:[7,26],swapping_signatures:11,swapsignatureswithsel:11,symbol:[],sync:[26,39],synchronis:[2,3,9,26,33],syntax:[13,39],system:[1,3,6,8,9,11,14,17,19,20,21,24,25,26,29,30,37,39],systemd:[20,35],tab:[2,8,14,15,33],tabl:[8,24,25,26,29,30,33],tableprefix:29,tackl:[30,40],tag:[1,2,16,31],take:[2,5,7,10,11,12,19,20,21,24,28,30,31,33,34,36,39,40,41],taken:[7,39],talk:12,tamper:11,target:[0,2,6,9,12,13,18,23,24],task:[6,8,9,10,11,14],tcp:[8,24,33],team:[],tear:[],teardown:12,techniqu:[2,9,19,27],technolog:17,tediou:[],tell:[0,11,38],templat:[],temporari:[8,11],temporarili:[11,31],tempt:[34,39],ten:39,tend:16,tenor:[5,24,27,36],term:[4,6,9,10,16,18,22,35,36,40],termin:[5,8,11,24,26,33],terminolog:9,test:[],testnam:20,testnet:[6,8,28,30,35],testtimelock:39,text:[2,15,24,30,41],than:[1,2,3,8,9,11,22,23,24,30,36,39],thank:30,thedao:30,thei:[1,2,3,4,5,7,8,9,10,11,16,18,20,21,23,24,26,27,29,30,31,33,34,36,37,39,40],them:[1,2,5,6,7,9,10,11,12,14,15,19,20,21,22,24,26,29,30,31,33,35,36,37,38,39,40,41,42,43],theme:34,themselv:[1,11,12,20,22,23,26,27,33,34,36,38,39],theori:[],therefor:[1,7,8,9,11,15,16,18,19,26,31,34,39],thi:[0,1,2,3,4,5,6,7,8,9,10,11,12,14,15,16,17,18,20,21,23,24,25,26,27,28,29,30,31,33,34,35,36,37,38,39,40,41,42,43],thin:22,thing:[],think:[2,9,11,15,22,34,39],third:[9,18,21,30],thisstateref:10,thorough:11,those:[1,3,9,10,11,18,24,34,39],though:[11,21,24,39],thought:[9,13],thousand:41,threadsaf:2,three:[8,11,21,25,33,36,39],threshold:[16,24,26,30,36],through:[1,5,7,9,10,11,14,22,23,24,26,30,37,39,40,41,43],throughput:[3,9],throwifsignaturesaremiss:[],thrown:[1,11,34,39],thu:[2,3,6,9,10,24,26,27,30,36,39],ticket:11,tidi:12,tighten:39,tightli:11,time:[],timelin:39,timem:39,timeout:1,timestamp:[],titl:15,tls1:26,tls:[22,30],todo:[2,11,39],togeth:[4,7,9,14,21,30,33,39,40],token:[11,36,40],told:2,toledgertransact:36,toler:[3,10],too:[2,11,39],took:11,tool:[11,13,14,16,20,22,23,24,25,29,30,33],toolbar:15,top:[2,7,9,11,15,20,22,25,30,33,38,40],topic:[22,39,43],topicsess:[22,30],toplevel:41,topriv:11,torn:30,tosignedtransact:[11,12,36,37,39,42],tostr:[2,11,29,39],tostringsshort:[],total:[9,20,36],toward:[30,31],towiretransact:[21,36],trace:[11,24,40],track:[],tracker:11,trade:[],tradeoff:[],trader:[],traderdemo:43,traderequest:11,tradit:9,traffic:[6,9,23],transac:16,transact:[],transactionbuild:[11,30,36,37,39,42],transactionforcontract:[39,40],transactionforverif:39,transactionst:[3,21,30,36],transactionstorag:26,transactiontyp:[11,30,37,42],transactionverificationexcept:41,transfer:[34,39,41,42],transit:[26,34,36,39,43],translat:26,transmit:[],transport:[6,8],travel:39,treat:[8,34,39],tree:[],tri:[9,14,30,39],tricki:[9,11],trigger:[4,10,11,20,26,27,33,40],trim:40,trivial:[2,9,37],troubl:15,trust:[4,6,7,9,26,28,34],trustpass:[6,35,38],truststor:[6,26,35],truststorepassword:[6,35,38],truth:11,tunnel:35,tupl:2,ture:9,turn:[9,11,36,39,40,41,43],tutori:[],tweak:[20,30,41],twice:41,two:[],twopartydealflow:10,twopartydealprotocol:[],twopartytradeflow:11,twopartytradeprotocol:[],txb:36,txbit:[],txhash:[9,11,38,39,42],txnid:38,txnnote:38,txt:24,type:[],typenam:11,typeonlycommanddata:39,typesaf:6,typetobui:11,typic:[7,9,10,11,22,24,26,29,34,36,37,39,43],ugli:11,ultim:26,ultimat:24,unaccept:11,unacceptablepriceexcept:11,unavoid:11,unclutt:11,unconsum:[26,29],under:[0,8,18,20,26,30,31,33,36,39,40,41,43],underli:[4,5,9,11,30,36],underscor:2,understand:[9,23,24,39,40,43],unencrypt:6,unexpect:[11,34],unfinish:11,unfortun:[11,34,39],unicredit:30,unifi:[30,43],uniform:10,unindex:15,uniqu:[3,9,11,26,27,30,36,37],uniqueidentifi:[],uniquenessprovid:26,unit:[],univers:30,unix:[8,18,24,33],unknow:3,unknown:36,unless:[2,11,27,31,39,43],unlik:[26,39],unlike:[4,7],unlink:15,unlock:6,unnatur:9,unpack:[8,26,39],unprocess:40,unqiu:10,unread:11,unrecognis:39,unrel:39,unschedul:10,unserialis:11,unset:5,unspent:[9,16],unstarted:11,unsubscrib:1,unsubscript:1,unsupportedoperationexcept:[1,39],until:[1,3,5,9,10,11,12,26,30,31,33,35,41,43],untrust:11,untrustworthydata:[11,30,34],unverifiedtransact:41,unwrap:[11,30],upcom:[10,30],updat:[1,7,8,9,11,15,20,22,26,30,31,37,38,39],update:[14,38],upgrad:[11,15,29,30,39],upgrade:30,uphold:39,upload:[],uploadrat:33,upon:[5,8,11,16,26,39],upward:31,urandom:20,url:[6,8,24,28,30,33,35],usabl:[30,31,39],usag:[],usage:38,usd:[20,25,38],use:[2,4,9],used:16,usehttps:[6,35],useless:39,user1:[6,25,35],user:[0,1,2,6,8,9,11,17,19,20,25,27,30,33,35,38],usernam:[1,6,24,25],usr:0,usual:[2,8,9,33,39],usualli:31,utc:10,util:[3,6,8,12,14,17,24,26,30,36],utilis:[23,38],utiliti:28,uuid:[30,36],vagu:2,val:[2,3,10,11,12,20,21,27,29,36,37,38,39,40,41,42],valid:[],validatedtransact:[12,37],validatingnotaryservic:[],validfrom:39,valu:[2,3,4,5,6,7,9,11,18,21,25,26,27,30,32,33,39,40,41],valuabl:27,valuat:[5,18,30,33],valueof:38,vanilla:[4,5],vararg:38,vari:[],variabl:[2,5,8,9,11,39],variant:[26,39],variou:[2,7,9,11,18,24,26,34,39],vault:[],vaultandupdat:38,vaultservic:[7,11,26],vaultsselfissu:20,vcs:14,vega:30,vehicl:9,vendor:[19,24],verbos:39,veri:[2,4,9,11,14,16,18,26,27,34,39,41,43],verif:[],verifi:[],verifiedtransact:38,verifyclaus:40,verifying:11,verifypropos:30,verifysignatur:11,versa:[4,5,9,11,36],versu:11,vertic:2,vet:34,via:[0,2],vice:[4,5,9,11,36],view:[],virtual:[7,9,16,34],visibl:[3,9,21,25,26,38],vision:17,visual:[25,30],visualis:[22,23,38],vital:11,vpn:35,wai:[1,2,3,8,9,10,11,15,16,18,20,21,22,24,25,27,29,30,33,35,39,41,43],wait:[10,11,12,15,20,26,30,33],waitforallnodestofinish:38,wake:30,wallet:[9,10,11,16,30,39],walletservic:[],want:[1,2,9,11,15,20,21,24,27,30,33,34,36,39,41,42,43],warn:[],watch:34,weak:[27,36],wear:31,web:[6,7,8,18,19,24,26,27,30,33],webaddress:[6,35],webapi:7,webapp:30,webport:8,webserv:35,websit:[14,15],websocket:[],week:13,weekend:5,weight:36,well:[0,2,3,5,7,9,10,11,14,16,19,21,24,26,29,30,37,38,39,40],went:2,were:[2,9,11,18,26,27,39],what:[],whatev:[2,11,23,26,36],when:[1,2,3,4,5,6,7,8,9,10,11,12,15,18,20,22,23,24,25,26,27,28,29,30,33,34,36,37,38,39,41],whenev:[2,14],where:[],wherea:[5,15],wherev:24,whether:[1,3,4,11,20,26,27,35,36,39,40],which:[0,1,2,3,4,5,6,7,8,9,10,11,12,14,15,16,18,19,20,21,22,23,24,26,27,29,30,31,33,35,36,37,38,39,40,41,42,43],whilst:[9,11,23,26,27,30,34,39],white:[7,17,30],whitelist:[4,7,8,10,11],who:[2,6,9,11,13,18,30,36,39],whole:[21,26,32,41],whom:[4,9],whose:[4,24,36],why:[2,9,13,17],wide:[1,2,21],widescreen:2,widespread:2,widget:25,width:2,wiki:[9,39,40],wikipedia:[39,40],window:[3,8,9,11,15,18,23,24,25,28,33],wiretransact:[11,21,27,36],wish:[8,9,11,17,18,27,29,30,36,39,43],wit:35,withattach:12,within:[0,2],withitem:[36,39],withkei:11,withnewown:[11,39],without:[],withoutissu:[11,39],withoutown:[39,40],withowner:39,won:[11,22,25,27,30,38,39,41],word:[2,3,6],work:[1,2,3,5,6,8,9,10,11,14,19,20,23,24,26,27,28,30,32,33,36,37,38,39,42],worker:2,workflow:7,workspac:[6,7,8,26,28],world:[6,9,11,18,23,25,27,35,39,41],worn:39,worri:[2,11,39],worst:9,worth:[2,34,39],worthless:27,would:[1,2,4,5,7,8,9,11,14,16,18,19,23,24,27,34,36,37,39,40,42,43],wouldn:27,wrap:[2,11,22,24,26,30,34,36,39,40,43],wrapper:[2,3,11,38],write:[],written:[0,1,5,9,13,14,30,39],wrong:[1,2,11,41],wrote:9,wtx:[11,21,27],www:0,xcode:14,xml:24,xterm:8,year:[5,11],yet:[2,5,9,11,16,19,23,25,28,30,36],yield:9,york:8,you:[0,1,2,8,9,10,11,12,13,14,15,17,18,19,20,21,22,23,24,25,27,28,29,30,32,33,34,35,36,38,39,40,41,43],your:[],your_usernam:[],yourself:[9,10,34,36],zero:[9,16,39],zip:[9,24,33,37],zone:10,zoneddatetim:10},titles:["Building the documentation","Client RPC","Code style guide","Consensus model","Contract catalogue","Interest rate swaps","Node configuration","The Corda plugin framework","Creating a CorDapp","Data model","Event scheduling","Writing flows","Writing flow tests","Further notes on Kotlin","Getting set up","Getting Set Up : Faultfinding","Glossary","Welcome to the Corda!","Initial margin agreements","What’s included?","Load testing","Transaction tear-offs","Networking and messaging","Network Simulator","Node administration","Node Explorer","Brief introduction to the node services","Writing oracle services","Network permissioning","Persistence","Release notes","Release process","Running a notary service","Running the demos","Secure coding guidelines","Introduction - What is a corda network?","Data types","Using attachments","Client RPC API tutorial","Writing a contract","Writing a contract using clauses","Writing a contract test","Using a notary service","Where to start"],titleterms:{"class":[1,38,39,40],"function":[11,39],about:15,access:24,adding:39,administr:24,adopt:9,against:8,agreement:18,amount:36,api:[38,39],app:[8,18],approach:27,artemismessagingserv:26,assert:27,assertion:2,asset:39,assign:42,attach:[24,37],attachment:[33,37],basic:27,bitcoin:9,brief:26,build:[0,8,28],buyer:11,cash:[4,36],catalogu:4,certif:[28,35],chain:41,chang:3,check:39,claus:[39,40],cli:15,client:[1,38],cluster:20,code:[2,14,34,39],command:39,comment:2,commerci:[4,39,40],commod:4,comparison:9,compil:2,complain:15,composit:36,con:9,configur:[6,20,35],connect:35,consensu:3,construct:39,continu:27,contract:[4,34,39,40,41],control:14,corda:[7,8,14,17,21,35],cordapp:[8,38],cordform:8,creat:[5,8],cryptographi:36,cut:31,data:[9,21,27,36],databas:24,date:36,dbcheckpointstorag:26,dbtransactionmappingstorag:26,dbtransactionstorag:26,debug:[8,40],demo:[25,33,37,43],detail:5,distribut:33,document:0,download:24,e2etestkeymanagementservic:26,encumbranc:39,error:[1,2],ethereum:9,event:[10,26],exampl:[6,10,21],explorer:25,faultfind:15,featur:11,field:6,file:6,fix:24,flow:[11,12,26,34],format:6,framework:[7,26],from:38,fungibleasset:36,further:13,futur:11,gener:[2,39],get:[14,15],git:14,glossari:16,gradl:[8,14,15],group:[39,40],guid:2,guidelin:34,handl:1,happen:39,hibernateobserv:26,hide:21,how:[10,20,39],ident:26,identiti:[],implement:[10,11,26],includ:19,individu:20,initial:18,inmemoryidentityservic:26,inmemorynetworkmapcach:26,inmemorystatemachinerecordedtransactionmappingstorag:26,inmemoryuniquenessprovid:26,install:8,installat:15,instanc:5,intellij:[14,15],interest:[4,5,24],interfac:[23,25],introduct:[10,11,18,26,27,35],irs:33,issu:15,jvm:14,kei:[26,36],kotlin:[13,14,15],kryo:[1,38],lack:15,length:2,lifecycl:[5,36],line:2,load:20,locat:6,log:[24,35],machin:[],make:39,manag:26,map:[22,29],margin:18,math:36,merkl:21,messag:[22,26],mileston:30,model:[3,9],monitor:24,multi:[36,39],multipl:3,name:2,namedbyhash:36,network:[22,23,26,28,35],networkmapservic:26,node:[6,8,24,25,26,35],nodeattachmentservic:26,nodemessagingcli:26,nodeschedulerservic:26,nodeschemaservic:26,nodevaultservic:26,non:39,notari:[3,26,32,33,42],notaris:42,notaryservic:26,note:[13,30],object:29,obligat:4,observabl:1,obtain:[],off:21,oracl:27,orient:39,overview:9,own:35,pai:27,paper:[4,39,40],parti:[11,36,39],particular:39,per:27,permiss:28,persist:[8,26,29],persistentkeymanagementservic:26,persistentnetworkmapservic:26,persistentuniquenessprovid:26,plai:27,plugin:[7,8],portfolio:33,pro:9,process:[18,31],progress:11,properti:2,protocol:1,publickei:36,put:39,raftuniquenessprovid:26,raftvalidatingnotaryservic:26,rate:[4,5,24],rational:9,regist:[1,38],relat:[26,29],releas:[30,31],request:28,requir:[0,39],rpc:[1,38],run:[18,20,25,28,32,33],safeti:1,schedul:[10,26],schema:29,sdk:15,secur:[1,34],seller:11,servic:[8,22,26,27,32,42],set:[14,15,35],sign:28,signatur:36,simm:[18,33],simplenotaryservic:26,simul:23,singl:41,smart:39,sourc:14,space:2,start:[8,11,35,39,43],state:[8,36,39],statemachinemanag:26,step:[18,31],storag:26,storageserviceimpl:26,style:[2,9],sub:11,subprotocol:[],summari:40,support:36,suspend:11,swap:[4,5],tear:21,technic:5,templat:8,test:[12,20,39,41],theori:11,thing:39,thread:[1,2],time:39,timestamp:3,track:11,trade:11,tradeoff:9,trader:[33,43],transact:[21,36,39,41,42],transmit:39,tree:21,troubleshoot:14,tutori:38,two:[11,27],type:[22,36],uniqueidentifi:36,unit:[],upload:24,usag:21,using:[8,37,39,42],util:28,utxo:9,valid:3,validatingnotaryservic:26,vari:27,vault:26,verif:36,verifi:39,version:[1,11,14],via:[14,15],view:8,warn:2,welcom:17,what:[19,23,35],where:[39,43],wire:1,within:[15,26],without:15,write:[11,12,20,27,39,40,41],your:[8,11,24,35,38,39]}})
\ No newline at end of file
+Search.setIndex({envversion:49,filenames:["CLI-vs-IDE","building-the-docs","clauses","clientrpc","codestyle","consensus","contract-catalogue","contract-irs","corda-configuration-file","corda-plugins","creating-a-cordapp","data-model","event-scheduling","flow-state-machines","flow-testing","further-notes-on-kotlin","getting-set-up","getting-set-up-fault-finding","glossary","index","initial-margin-agreement","inthebox","loadtesting","merkle-trees","messaging","network-simulator","node-administration","node-explorer","node-services","oracles","permissioning","persistence","release-notes","release-process","running-a-notary","running-the-demos","secure-coding-guidelines","setting-up-a-corda-network","transaction-data-types","tutorial-attachments","tutorial-building-transactions","tutorial-clientrpc-api","tutorial-contract","tutorial-contract-clauses","tutorial-cordapp","tutorial-integration-testing","tutorial-test-dsl","using-a-notary"],objects:{},objnames:{},objtypes:{},terms:{"00z":42,"0_xx":17,"10000l":22,"1000l":39,"100l":45,"17t16":42,"1mb":13,"5000l":22,"5xxx":0,"___":44,"____":44,"______":44,"_________":44,"_before_":13,"_do_":13,"_foo":4,"abstract":[2,9,11,13,28,29,31,32,42,43,44],"boolean":[11,14,22,32,41,42,43],"break":[13,29,33,40],"byte":[4,11,13,29,32,46],"case":[2,4,5,8,9,10,11,13,14,16,20,22,29,31,32,35,38,39,42,43,44],"catch":[4,13,16,36],"class":2,"default":[3,4,6,8,9,10,13,16,18,20,22,23,25,26,27,28,30,32,35,36,37,38,42,44],"enum":[32,41],"export":[13,26,31],"fa\u00e7ad":26,"final":[5,7,9,11,13,14,17,23,29,32,35,37,40,41,42,45,46],"float":[6,7,12],"function":[0,2,4,6,7,9,11],"import":[2,4,11,12,13,16,17,29,31,32,37,38,40,42,43,44,46],"instanceof":[42,43],"int":[4,22,31,42,47],"long":[4,6,9,11,12,22,31,40,42,43,44],"new":[0,4,5,7,8,9,10,11,13,15,24,25,26,27,28,30,32,33,35,38,39,40,41,42,43,44,45,46,47],"null":[8,12,14,22,29,31,39,40,42,43,47],"public":[4,8,10,11,13,18,21,24,26,28,30,32,35,37,38,42,43,44,46],"return":[2,3,4,5,7,9,12,13,14,22,26,28,29,31,32,36,39,40,41,42,43,44,45,46,47],"short":[2,12,20,33,35],"static":[9,10,11,13,20,29,35,42,44,46],"super":[2,4,43],"switch":[13,32,42],"throw":[2,3,4,13,22,23,29,40,41,42,43,47],"transient":13,"true":[5,8,11,14,18,22,29,30,37,41,42,44],"try":[0,3,4,11,13,17,32,34,41,44],"var":[14,31,40,41],"void":[42,43,46],"while":[25,38,41],abil:[11,25,32],abl:[5,8,10,11,13,20,23,26,27,28,29,30,32,35,42,47],abort:[5,29,40],about:[0,4,5,9,11,13,15,16],abov:[2,4,7,11,13,20,23,26,29,35,37,41,42,43,44,45,46],absent:[2,8],absolut:[5,8,11],abstractnod:[9,28],abstractstatereplacementprotocol:32,acccess:9,accept:[4,5,6,11,16,18,29,35,40,42],acceptablepric:13,acceptsfileupload:29,access:[3,4,8,9,13,16,19,22,24],accid:13,accident:[4,36,40],accompani:[4,42],accord:[2,40],accordingli:[37,43],account:[11,22,32,38],accrual:7,accur:[5,20,35],accuraci:11,achiev:[5,11,37,38],achiv:23,ack:32,acknowledg:[13,28],acquir:35,acronym:[20,35],across:[6,8,11,22,28,31,32,35,39,40],act:[2,5,8,11,13,28,29],action:[2,12,22,28,29,34,40,42,45],activ:[7,8,9,12,16,22,25,28,31,32,35,40,42,44],actor:[4,11,13],actual:[5,7,13,20,22,28,29,35,36,39,42,43,46,47],adapt:[4,13,29],add:[2,4,10,11,13,18,20,22,23,24,26,28,29,34,35,36,39,40,41,42,44,45,46,47],addattach:[14,39],addcommand:[13,29,40,42,47],added:32,addedg:41,addfix:29,adding:19,addinputst:[13,42],addit:[0,4,5,8,10,11,28,31,32,38,40,41,42,44],addition:[11,13,15,16,31,33,35,44],addmessagehandl:32,addnod:41,addoutputst:[13,42,47],address:[0,5,8,10,11,13,24,27,28,32,37,42,44,45],addsignatureuncheck:29,addvaulttransactionnot:41,adequ:2,adjust:[4,7,33,42],admin:[27,28,30],administr:[19,21],advanc:[6,7],advantag:11,advertis:[3,8,28,32,34,41,42,45,47],advertisedservic:[10,41,44,45],advic:33,advis:[0,29],aesthet:35,affect:[17,29,37],affinityexecutor:4,afraid:4,after:[0,2,5,6,7,9,10,12,13,14,15,17,18,22,23,28,29,35,40,42,44],again:[7,11,13,14,22,28,29,42,44,45,47],against:7,agent:[22,26,28],agentlib:10,aggreg:[11,20,35,42,43],agre:[7,12,13,16,18,20,35,36,40,44],agree:[7,20,35],agreement:[7,11,18,19],ahead:[13,42],aid:[32,40],aim:[4,11,22],aka:[18,19],albeit:32,albertsen:32,alert:17,algorithm:[11,21,32,38,42],alia:8,alic:45,alice:[18,27,38,41,42,45,47],alice_key:39,alicecli:45,alicefutur:45,aliceparti:47,aliceproxi:45,alicevaultupd:45,align:[19,32,40,44],aliv:13,all:[1,2,3,4,5,6,7,8,9,10,11,13,14,15,17,18,19,22,23,26,27,28,29,31,32,33],allevi:5,alloc:35,allow:[0,3,4,5,6,7,8,9,10,11,12,13,18,20,22,24,28,29,31,32,35,36,38,40,41,42,44,45,46],allpartysignedtx:[13,40],almost:42,along:[2,5,13,14,16,29,42,44,47],alongsid:42,alreadi:[4,10,12,13,19,20,23,29,32,35,39,40,42,43,44,46,47],alright:13,also:[0,2,3,4,5,6,7,8,9,10,11,12,13,14,16,17,18,20,22,23,24,25,26,27,28,29,30,31,32,35,38,39,40,42,43,44,45,46,47],alter:[8,13,26,40],altern:[1,4,8,19,24,25,26,27,38,42,44,45],although:[7,8,11,13,16,17,27,28,32,39,42,44],alwai:[4,11,12,13,19,26,31,37,38,40,42,44],amend:40,among:44,amongst:0,amount:[2,3,6,7,11,13,19,20,22,32,35],amountrequir:40,amqp:[24,32],analysi:[2,11],analyt:[20,35],andresen:11,ani:[0,2,3,4,5,6,7,9,11,12,13,14,16,18,20,26,27,28,29,31,32,33,34,35,36,37,38,39,40,41,42,44,45,47],annot:[3,4,9,13,31],announc:[29,33],anonym:[11,28],anonymis:28,anoth:[3,4,5,10,11,13,17,18,20,26,28,29,32,35,39,42,46,47],another:40,answer:[4,29],anti:44,anticip:4,any:[2,3,6,12,20,26,28,35,40,41,43],anybodi:11,anycompost:43,anyon:[5,42],anyth:[5,11,13,14,36,38,42,43,44],anytim:30,anywher:[29,32,42],apach:24,apart:[5,32,40],api:[0,1,3,4,10,13,14,18,19,21,26,28,31,32,33,35,37,40],app:3,appear:[17,29,35,42,44],append:[8,13,26],appendix:19,apple:16,appli:[4,6,7,10,11,22,27,40,42],applic:[9,10,11,18,24,28,29,32,35,36,42,44],applicat:18,applyfix:7,appoint:5,approach:[11,12,13,19],appropri:[4,24,28,29,31,32,34,40,44],approv:[11,12,13,30,40],approxim:5,april:32,arbitrari:[2,4,11,13,29,36,38,41],arbitrarili:[11,45],architectur:[3,19,29],area:[0,31],aren:[3,12,21,42],arg:[10,32,41,44],argument:[3,4,9,11,13,22,41,42],aris:[11,16],around:[5,11,13,14,23,32,33,38,40,41,42,44,45],arrai:[11,41,44],arrang:13,arraylist:29,arriv:[13,18,29,45],arrow:[7,17,44],art:38,artemi:[10,18,24,37,44],artemisaddress:[8,37,41],artemismessagingcompon:45,artemismq:[8,28],artemisport:[10,44],articl:[5,11,12,13,29,32,42],artifact:10,artifactid:44,ascertain:[35,44],ask:[4,13,29,42],aspect:13,assembl:[0,2,11,23,42],assemblesharedtx:13,assert:[4,13,19],assertequ:[14,39,45],asset:[2,6,13,19,32,35,36,38,40],assetforsal:13,assetmismatchexcept:13,assettosel:13,assettypenam:13,assign:[11,14,19,29,40],assist:[12,13,31,38],associ:[2,5,11,12,24,29,31,32,37,38,40,41,42,44],assum:[5,11,13,19,22,23,29,36,40,41,42,43,47],assume:[13,23,29,44],assumpt:13,assur:[20,35,43],asynchron:[22,40],atom:[5,11,13,32,35,42],attach:[0,10,11,13,18,19,23],attachment:[11,18,19,26],attachmentdemo:39,attachmentstorag:28,attack:[5,36],attch:23,attempt:[11,17,29,36],attent:[13,44],attest:5,attribut:4,audit:[11,40],authent:[3,5,28,32,41],authenticatedobject:[2,38,42,43],author:[4,5,16,28,33,47],authoris:[8,13,28,38,41],auto:[4,42],autoclos:3,autom:[11,12,42],automat:[0,1,3,5,8,10,12,13,24,25,28,29,31,32,35,39,42,44,47],auxiliari:28,avail:[0,1,5,7,8,10,12,13,16,25,26,28,29,32,33,35,36,39,41,42,44,47],avoid:[3,4,11,13,29,31],awai:[3,11,13,41,44],await:[10,40],awar:[3,4,12,13,28,32,42],awg:33,awkward:[4,13],axi:7,back:[3,4,9,11,13,20,28,29,32,35,36,38,40,42,45],backend:32,background:[0,3,4,9],backoff:24,backport:33,backward:[13,33],bad:[4,13,42,46],balanc:[2,5,6,11,27,40,42,46],banana:38,bananast:38,banco:32,band:13,bandwidth:4,banish:18,bank:[7,8,11,32,35,37,38,39,42,43,45,47],bankrupt:42,bankruptci:[5,11,20,29,35],banner:37,bar:17,barreca:32,barrel:32,base:[4,5,7,8,10,11,12,13,18,22,24,26,28,29,30,32,35,37,38,41,42,44,47],basedir:[8,10,37],basedirectori:41,basi:[7,12,16,25,26,28,44],bat:[0,10,20,25,27,30,35,44],batch:[22,44],bbva:32,bear:13,becaus:[4,5,11,12,13,16,17,19,26,28,29,38,40,42,43,44,46,47],becom:[4,7,11,12,13,29,33,38,40,43,44],been:[5,7,8,11,13,16,18,20,29,30,32,33,35,38,40,42,43,44,47],befor:[0,5,7,10,11,12,13,14,22,28,29,32,33,34,38,39,40,41,42,43,44],beforesign:29,begin:[4,11,19,28,40,42,44],behav:42,behaviour:[2,5,6,8,22,26,40,43,44,46],behind:[13,18,24,42],believ:32,belong:23,below:[4,7,10,11,12,13,16,20,23,28,35,38,40,42,44],beneath:18,beneficiari:6,benefit:[5,13],best:[4,40],bet:29,better:[4,15,32,42],between:[4,5,7,11,12,13,18,24,25,28,29,31,32,33,35,36,38,40,41,42,44],beyond:[11,40],bft:32,big:[4,11,13,32,42],bigdecim:[29,38],bilater:[6,7,32],bill:42,bin:[35,41,44],binari:[11,23,28,29,41],bind:[5,8,11,19,25,26],bip:11,bit:[32,38,42,44,46,47],bitcoinj:13,blah:4,blank:[4,26,27,30,42],block:[2,3,4,5,10,11,13,28,29,32,35,36,40,43,44,45],blockchain:[11,13,21,23,42],bloom:4,bloomfilt:4,blotter:35,blue:[7,23],bob:[18,27,38,42,45],bobclient:45,bobfutur:45,bobproxi:45,bobvaultupd:45,bodi:[4,20,35],boil:[11,22],boilerpl:10,bond:[42,43],bookkeep:42,bookmark:35,boost:21,boot:44,bootstrap:[8,10,44],bore:42,boss:[19,44],both:[0,5,6,7,11,13,14,15,18,22,25,29,31,32,35,36,37,38,40,41,42,44],bottom:17,bounc:14,bound:[5,13,32,37,40,42],branch:[23,32,33,44],branch_nam:44,brand:32,breach:11,breakpoint:[20,35,44],breviti:[0,43],bridg:28,brief:[3,19],briefli:[19,24,29,44],bring:[11,22,35,45],broadcast:[11,40,42,47],broadcasttransactionflow:47,broader:37,broke:4,broken:[32,44],broker:[8,24,28,44],brought:40,brows:[20,26,35],browser:[8,35,44],bubbl:[16,17],buffer:3,bug:[4,16,17,32,33],bugfix:33,bui:13,build:0,buildcertsigningrequestutilityjar:30,buildcordajar:[8,30,37],builder:[13,14,32,36,39,40,47],buildfilteredtransact:40,buildmerkletransact:[23,29],buildscript:[10,18,44],buildsrc:44,buildtradepropos:40,built:[0,8,10,13,23,32,36,42,44],bulk:[11,40],bullet:4,bunch:44,bundl:11,busi:[11,12,13,18,21,29,31,32,38,40,42],businesscalendar:38,button:[35,44],bytearrai:31,bytecod:[11,13,42],cach:[24,39,44,47],calcul:[5,7,12,13,20,23,35,36,38,42],calculateoursignatur:13,calendar:[7,29,38],call:[0,2,3,4,5,7,9,11,13,15,26,28,29,32,33,35,36,38,39,40,41,42,46,47],callback:[3,4,13,28,32],caller:[29,40,42,47],came:13,camel:4,can:[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,20,21,22,23,24,25,26,27,28,29,30,31,32,34,35,36,37,38,39,40,41,42,43,44,45,46,47],candid:31,cannnot:9,cannot:[2,5,6,11,18,25,29,32,36,38,40,42,44,47],capabl:42,capit:4,capitan:1,capsul:25,capsule_cache_dir:10,captur:[9,12,40],cardon:32,care:[4,5,9,11,13,14,36,40,46],carefulli:15,carri:[0,28,40],cash:2,cash_stat:31,cashcommand:[22,41,45],cashflow:[41,45],cashflowresult:45,cashkt:42,cashprotocol:[8,37],cashschema:31,cashschemav1:31,cashsigningpubkei:13,cashstat:40,cast:3,catastroph:[20,35],categori:37,caught:3,caus:[4,16,17,18,20,35,42,44],cbc:22,ccy_cod:31,cent:38,center:42,central:[32,38,42,47],ceo:38,cer:8,certain:[2,4,9,20,32,35,40,42],certainli:10,certainti:5,certif:[8,19,22,28],certificatesigningservic:[8,30,37],certificatespath:41,certifici:45,certsigningrequestutil:[30,37],cev:30,chain:[6,11,13,14,19,28,29,32,38,42],chaincash:46,chaincashdoublespend:46,chaincashdoublespendfailswith:46,challeng:11,chanc:[4,13],chang:[0,1,3,4],changenotari:5,channel:13,charact:[4,8],characterist:18,charg:29,charli:38,chart:43,check:[2,4,5,8,12,13,14,16,19,22,23,25,28,29,32,36,37,38,39,40,41],checkabl:[29,32],checkfixisnearexpect:29,checknotnul:42,checkout:[16,17,44],checkpoint:[9,28,32],checksignatur:29,checkstat:42,checksufficientsignatur:[13,38,40,47],child:[0,13,38],children:[13,38],childrenfor:13,choic:[4,5,11,16,42,44],choos:[0,5,27,32,42,44,47],choreographi:18,chose:0,chosen:[5,11,13,22,47],christma:44,chronolog:12,chunk:[42,43],circl:25,citi:44,cl1:2,cl2:2,cl4:2,cl5:2,claim:[11,42],clarifi:42,clash:[4,31,44],classic:42,classpath:[3,9,10,11],clauseverifi:43,clean:[0,13,32],cleaner:32,cleanup:32,clear:[0,2,3,13,22,36,38],cleardatabasebeforerun:22,clearer:13,clearli:[4,40],click:[17,27,35,44],cloan:0,clock:[5,11,12,13,29,35,40],clone:[4,17,42,44],close:[3,5,6,44],closeabl:3,closer:5,closur:[4,46],cloud:26,cluster:[5,8,19],cmd:[23,42,43],coars:11,code:[0,1,2],codebas:[4,31],cognit:11,coin:11,collabor:32,collaps:22,colleagu:4,collect:[3,4,18,22,26,31,32,34,40,42,43],collector:[4,13,26],collis:4,colon:0,column:[10,26,31],com:[1,16,17,30,32,44],combin:[11,18,38,42,43],come:[3,11,13,14,32,33,36,42],commanddata:[2,29,42,43],commerci:2,commercial_pap:[42,43],commercialpap:[2,6,31,42,43],commercialpaperlegaci:42,commit:[5,8,12,14,19,28,33,34,35],committe:[20,35],common:[2,6,7,9,11,13,19,28,31,32],commonleg:7,commonli:40,commun:[8,13,18,28,32,36,37],compani:[29,30,43],companion:[13,29,42,43],compar:[11,19,23,35,42,44],compat:[3,18,33],compel:5,compet:11,complementari:12,complet:[0,3,11,12,13,19,28,30,32,35,38,39],completetx:40,complex:[4,6,11,14,20,31,35,38,39,42,45],complic:[13,29,40,42,43],compon:[0,2,9,10,12,18,19,24,28,32],compos:[2,13,32,38,42,43],compositeclaus:2,compositekei:[13,28,38,40],compound:32,compris:[7,44],comput:[7,18,29,44],computeoursignatur:13,concaten:23,concern:[11,13,42],concis:32,conclus:[11,29],concret:[9,28],concurr:22,concurrenthashmap:4,condit:[2,5,9,22,28,29,32,43,46],conf:[8,10,28,30,37,44],confgur:31,config:[8,10,22,26,30,32,35,41,44,45],configur:[0,3],configurationfil:26,configuretestssl:45,confirm:[5,17,18,20,35,40],conflict:[5,11,22,47],confus:[0,13,43],connect:[0,3,8,10,19,21,22,26,27,28,30,35],consequ:40,conserv:[2,40],conserveamount:2,consid:[4,7,11,12,18,29,32,33,38,40,42],consider:[40,42],consist:[7,8,11,13,18,20,22,28,29,32,35,37,40,43],consol:[0,26,32,35,37,41,44],consortium:18,constant:[4,31,42],constantli:[29,44],constraint:[13,29,32,42,43,44,45],construct:[2,4,5,9,10,13,19,23,28,31,32,36,38,40],constructor:[2,9,12,13,29],consum:[3,5,11,12,18,28,32,35,38,40,42,47],consumedcommand:2,consumingtx:47,consumpt:[12,29,40],contact:[13,28,32],contain:[2,5,7,8,9,10,11,13,18,23,24,26,27,28,29,30,32,33,35,38,39,40,42,43,44,46,47],content:[4,5,9,10,11,12,14,17,26,29,32,38,40,44],context:[4,11,26,28,29,38,40,47],contin:29,continu:[7,13,19],contract:[2,3,5],contracthash:43,contractreject:46,contractst:[2,5,12,23,31,32,38,40,41,42],contractu:40,contrast:[11,13,29],contribut:38,control:[0,3,4,5,8,9,10,11,13],conveni:[2,4,11,29,38,40,42],convent:[7,13],convers:[27,38],convert:[2,5,6,7,14,28,31,32,38,40,42],convinc:[13,23,38],coordin:8,copi:[0,4,11,13,24,26,28,39,40,42,44,46,47],copycat:34,copyonwritearraylist:4,copyright:4,copyvault:22,corda:[0,5,6,8],corda_dev_ca:8,corda_gradle_plugins_vers:10,corda_vers:[10,44],cordaapp:44,cordacadevpass:[8,37,41],cordapluginregistri:[9,10,29,41,44],cordapp:[0,3,9],cordarpccli:[3,41,45],cordarpcop:[3,13,41],cordarpcopsimpl:28,cordform:0,cordpp:44,core:[6,9,10,11,13,17,19,22,26,28],corner:17,corpor:43,correct:[6,11,13,17,29,32,33,35,40,42,44,46],correctli:[11,13,17,18,28,29,32,40,42],correspond:[3,18,22,35,38,42,43],correspondingli:[4,39],cost:[3,29,42],could:[4,5,6,11,13,22,29,36,38,40,42],couldn:[23,29],count:[7,35],countabl:32,counter:[4,13,44],counterparti:[6,7,18,20,35,36,40],counterparty:44,countri:[29,38,44],coupl:[13,14,22,41,44],cours:[13,22,26,29,31,42],coven:42,cover:[5,6,11,13,20,29,35,38,42,44],cpu:22,crash:[13,28,29],crazi:44,creat:[3,4,5],createcommand:47,createdummyirs:7,createsomenod:14,creation:[7,11,23,42],creator:29,credenti:[27,41,44],credit:[20,32,35],crisi:[20,35],crisp:42,criteria:6,critic:[11,33],crop:11,crypto:[32,44],cryptograph:[18,23,38],cryptographi:19,csr:32,ctrl:44,curl:[26,44],currenc:[2,6,7,13,22,27,31,32,38,40,42],current:[0,3,4,5,7,8,10,11,12,13,19,21,22,23,24,25,27,28,29,30,31,32,33,34,36,38,41,42,44,46,47],currenti:25,currentstep:[13,29],currenttim:13,currentvault:40,curv:7,custodi:[14,38],custom:[3,5,8,9,13,26,28,31,32,35,38],customis:[3,31,41],cut:19,cutoff:22,cycl:[4,13,42],dai:[5,7,13,26,29,33,38],daili:44,daniel:32,danks:32,dashboard:[26,27],data:[1,4,5,6,7,9,10],databas:[8,9,10,11,14,19,21,22],databaseschema:31,databasetransact:14,dataset:[7,20,35],datasourc:[8,37],datasourceclassnam:[8,37],datasourceproperti:[8,37],datastructur:22,date:[5,6,7,12,17,19,26,33,35],dateoffset:32,daterollconvent:38,david:32,dcapsul:10,dead:24,deadlin:[29,38],deal:[4,13,29,35,38,42],dealstat:38,debt:[6,20,35],debugg:10,decd098666b9657314870e192ced0c3519c2c9d395507a238338f8d003929de9:26,decd:26,decentralis:[11,29,32],decid:[17,23,29,31,40,42,43],decis:[5,11,40,42],declar:[4,8,9,28,46],dedic:4,dedupl:[28,32],defaultissu:42,defens:40,defin:[2,4,5,9,11,13,14,21,22,26,28,31,32,38,41,42,43,44,46],definit:[2,5,13,18,32,38,42],delai:[7,29],deleg:[40,43,47],delet:[4,11,13,28,32,42],deliber:[11,46],deliv:[6,14,28,38,44],deliveri:[13,21,24,35,44],deliveryaddress:44,deliveryd:44,demand:[5,11,13,32],demo:[0,8,9,10,19,20,21],demonstr:[0,16,20,32,35,44,45],denial:5,denot:23,dens:4,depend:[0,4,5,10,11,12,13,14,16,17,18,20,29,32,35,37,40,42,44],dependson:[10,44],deploi:[0,10,18,19,41],deploy:[10,18,25,44],deploynod:[8,10,20,35,41,44],deployvisualis:25,deposit:[42,46],deprec:32,deregist:24,deriv:[0,7,13,18,31,32,38,42],describ:[4,5,11,12,13,19,20,22,23,28,35,36,38,41,42,44,47],descript:[2,4],deserv:[22,33],design:[4,5,11,15,18,19,29,32,36,42,43,44],desir:[9,13,38],desktop:26,despit:[13,39,42],destroi:[6,11,40,42],destructur:42,detail:[2,3,4,6],detect:4,determin:[0,2,6,7,12,17,18,40,42,43,44,45],determinist:[3,22,32,45],dev:[8,22,26],develop:[0,4,8,10,11,13,15,16,19,28,30,31,32,33,35,40,42,43,44],developer:44,devic:[8,11],devis:11,devmod:[8,30,37],diagnos:37,diagram:[7,42],dialogu:44,diamond:18,did:23,didn:[4,13,23,33,42,44],differ:[2,4,5,6,7,8,9,10,11,12,13,16,22,27,29,31,32,35,38,40,41,42,43,44,45,46],differenti:47,difficult:13,difficulti:43,digest:5,digit:[11,13,29,32,40,42],digitalsignatur:[13,29,40,47],dir:[30,37],direct:[4,18,28,31],directli:[0,3,4,13,14,18,24,26,28,32,35,38,40,41,42,43,44,45,47],directori:[0,1,8,10,17,20,22,26,28,30,35,37,44],directthreadexecutor:4,dirnam:[10,44],dirti:42,disabl:[28,38],disadvantag:11,disagr:[20,35],disambigu:31,discard:36,discov:11,discoveri:25,discuss:[11,13,29,38,40,44],disk:[13,24,32,38],disobei:29,displai:[0,5,32,35,41],disput:[5,7,42],disrupt:[22,24,32],disruptionpattern:22,disruptionspec:22,distinct:[4,37],distribut:[5,8,9,10,11,13,18,19,21,29,32,34],distrust:[5,13],divid:5,divis:38,dlog4j:26,doc:[0,1,3,4,19,32,41,44,45],docker:26,docsit:[1,33,44],document:0,doe:[4,5,6,7,8,10,11,12,13,14,19,20,21,26,28,29,30,31,35,36,40,42,44,45,46,47],doesn:[2,4,5,11,13,14,17,21,26,29,36,42,46,47],dokka:1,dollar:[38,42,45,46],dollars:[42,45,46],domain:[18,32,38,42],domicil:42,domino:[20,35],don:[3,4,11,13,15,16,17,22,27,29,33,35,36,38,42,43,46],done:[0,1,2,3,11,13,14,16,22,23,30,32,35,41,42,44],dot:[7,23],doubl:[11,13,21,27,28,37,42,44],doubt:4,down:[4,8,11,13,22,27,39,40,42,43,44,45],download:[0,3,13,14,16,17,19],downsid:[4,11],drain:[3,13],draw:[32,41],drawn:41,drive:[11,40],driven:35,driver:[0,8,26,31,32,41,44,45],driverdirectori:41,drm:29,drop:44,dsl:[0,10,18,32,44,45,46],dt_socket:[0,10,44],due:[0,4,5,7,11,12,13,15,16,20,28,31,35,42,43],dummi:[6,14,46],dummy1:14,dummy2:14,dummy_cash_issuer:46,dummy_notary_key:14,dummy_pubkey_1:[42,46],dummy_pubkey_2:46,dummycontract:[14,47],dump:41,duplic:[13,23],durat:[12,29,40],durationsecond:22,dure:[4,7,8,9,10,13,25,26,28,32,42],dynam:[9,11,32,42],each:[0,2,3,4,5,7,8,9,10,11,12,13,18,22,23,25,28,29,31,32,33,35,37,38,40,41,42,43,44,45,46],earli:[4,6,28],earlier:[0,36],earliest:[7,12],easi:[4,11,15,29,32,42],easier:[4,10,13,16,32,42],easiest:[3,42],easili:[0,4,13,20,35,42,44],echo:44,econom:7,ed25519:32,edg:41,edge:41,edit:[0,26,37,44],editor:17,effect:[7,8,11,13,14,20,31,35,46],effort:16,either:[0,2,3,4,5,6,7,8,9,11,13,17,18,22,23,31,35,38,41,42,44,46],elbonia:38,element:[4,11,18,23,29,40,42,44],elementari:[43,44],elimin:[21,32],els:[5,10,11,13,14,28,29,38,40,41,42,43,47],elsewher:9,elucid:40,email:13,emailaddress:30,embed:[8,9,11,21,23,26,29,32,44],embedd:24,emit:[3,32,45],emoji:39,empti:[8,32,42,46],emptyledg:46,emptyset:[2,39],enabl:[0,8,9,10,28,32,39,43],enact:[20,35],enc:22,encapsul:[2,4,29,38],enclos:4,encod:[29,40],encount:[12,28,40],encourag:[31,39],encrypt:[30,40],encumb:42,encumberedst:42,encumbr:[31,42],encumbranc:19,end:[2,4,5,7,11,13,19,22,28,29,33,40,43,44],endeavour:44,endpoint:[10,24,26,44],enforc:[2,4,11,42],enforceverifyorfail:46,engin:[20,35],england:43,english:[4,42],enhanc:32,enjoy:32,enorm:13,enough:[4,13,14,20,35,40,42,45],ensur:[2,4,5,9,11,13,17,18,23,28,30,32,33,36,38,40,42,43,44],ensure:[5,17,20,29,35,44],enter:[10,20,35,44,45,46],entir:[5,7,11,13,19,28,29,42,44],entireti:7,entiti:[5,11,23,29,31,38,42],entitl:41,entri:[7,8,10,11,13,31,32,36,42,43],enumer:[7,31,35,40,44],environ:[0,4,10,13,16,29,40],envisag:42,equal:[2,5,13,32,38,40,42,43,46],equiti:31,equival:[4,7,27,28,34,38,40,42],eras:16,error:[0,2],escal:29,especi:[38,40],essenti:[0,26,28,29,40,42,43],establish:[12,16,24,35,37,45],etc:[0,4,5,6,7,13,18,20,21,27,29,32,33,35,37,38,42,43,44],euribor:[26,29],euro:38,evalu:[7,26,29,43],even:[3,5,11,13,15,20,23,28,29,31,32,35,42,43,46],event:[4,5,7,11],eventu:[22,28,37],eventual:[5,33],ever:[4,11],everi:[0,2,3,5,9,11,13,22,23,24,28,29,31,32,33,35,36,38,42],everybodi:11,everyon:[5,29,42],everyth:[5,36,41,42],evid:[29,40],evolut:[11,43],evolv:[31,32,37,41,42,44],exact:[0,5],exactli:[11,28,29,38,42],examin:[4,10,11,14,42],exampl:[0,1,2,3,4,5,6,7],exampleapi:44,exampleclientrpc:44,exampleflow:44,exampleplugin:44,examplerpccordapluginregistri:41,examplerpcvalu:41,exampleservic:44,exampletest:44,exampleweb:44,exce:22,excel:29,except:[2,3,4,9,13,36,40,42],exception:[0,4,13],excess:4,exchang:[7,13,18,28,38,40],exclud:[8,31,40],exclus:6,execut:[0,2,5,10,11,12,13,18,22,25,27,28,32],executor:4,exhaust:[28,32],exist:[4,5,6,7,8,10,11,12,19,25,28,30,31,32,38,41,42,44,46],exit:[2,6,8,14,27,28,30,32,41,42],exitcash:41,expand:[27,40,44],expect:[3,4,6,8,12,13,22,28,29,30,31,32,33,35,36,38,39,40,42,43,44,45,46],expectedtypenam:13,expectev:45,expens:[3,4],experi:[10,16,32,33,44],experienc:11,experiment:[4,32],expir:30,explain:[4,12,13,22,25,30,32,44],explan:[2,4,25,29,41],explicit:[4,11,13,40,42],explicitli:[4,9,11,46],explictli:40,explor:[4,11,14,17,21,26,27,32,40,42,44],explorer:19,expos:[4,9,10,11,12,13,26,28,31,32,38,40,41,47],expose:38,exposur:[6,7,18],expound:16,express:[5,7,11,18,32,38,42,46],ext:[10,44],extend:[2,4,5,9,10,13,15,27,28,29,32,38,42,43],extens:[0,4,9,13,18,25,26,28,29,32,36,38,40,42],extent:11,extern:[8,13,28,37,39,40,44],extraadvertisedserviceid:[8,28,34,37],extract:[11,26,29,35,38,40,42],extractcommand:43,extrem:[5,11,15,18,22],face:[42,43],facevalu:[2,42],facil:[18,28],facilit:44,fact:[0,4,5,7,11,13,18,29,32,37,42,44,46],factor:[7,11,20,35],fail:[2,9,39,42,43,46],failswith:46,failur:[13,18,39,46],fairli:[4,14,20,35],fals:[4,8,13,14,29,37,38,40,42,47],famili:31,familiar:[3,11,42,44,47],famou:[11,32],fanci:42,far:[13,29,35,40,42,43,45],fashion:[4,20,31,35],fast:[11,14],fault:13,fear:18,featur:[3,4,8,10,11],fed:25,feed:[5,29],feedback:32,feel:[42,44],fetch:[24,26,28,29,39],fetchtransactionsflow:39,few:[0,4,13,15,26,29,33,35,40,42,43,44],fiber:[13,28,29],field:[4,7],file:[1,3,4],fill:[4,13,35,40,42],filter:[2,4,22,23,29,31,32,40],filtercommand:[23,29],filteredleav:[23,29],filteredtransact:[23,29,40],filterfun:[23,29],filterisinst:42,filterst:2,finalis:[7,13,32],finalityflow:[39,40,47],financ:[10,13,32,44],financi:[11,12,13,18,20,32,35,38,40],find:[0,1,11,13,14,15,16,19,21,26,29,36,40,44],fine:[3,11,46],finish:[13,32,44,45],fire:13,first:[0,2,3,4,5,7,8,10,12,13,14,15,16,17,18,24,26,29,30,31,32,35,38,39,40,41,42,43,44,45,47],firstli:[9,35,42,44],fit:[4,11],fix:[4,6,7,11,12,13,17,19,22,23],fixabledealst:38,fixedleg:7,fixedlegpaymentschedul:7,fixedratepaymentev:7,fixer:29,fixingflow:29,fixingroledecid:12,fixingsessioninitiationhandl:12,fixof:[23,29],fixqueryflow:29,fixqueryhandl:29,fixsignflow:29,fixsignhandl:29,flag:[8,26,30],flat:31,flesh:38,flexibl:[5,11,38],flight:[3,11],floatingleg:[7,12],floatinglegpaymentschedul:7,floatingratepaymentev:7,flow:[4,5,7,9,10,11,12],flowhandl:[13,41,45],flowlog:[12,13,28,29,41],flowlogicreffactori:[9,12],flowstatemachineimpl:28,flowtrack:13,flux:10,fly:13,focu:23,focus:[2,43],fold:[4,41],folder:[1,8,10,28,30,35,40,44],follow:[1,4,5,8,10,11,12,13,16,17,22,25,26,27,28,29,30,34,35,40,41,42,44,46,47],font:4,foo:[4,41],foobrokenexcept:4,foot:36,fooutil:42,forc:[11,26,32,42,46],fordai:[12,29],foreach:41,foreign:40,foreignexchangeflow:40,forev:33,forget:[13,29,42],form:[3,5,10,11,12,13,23,28,29,35,40,42,43,44],format:[1,3,4],former:41,formerli:32,formula:32,forth:[3,13,40],fortun:[20,35],forward:[13,24,28,29,33,35],found:[2,8,13,16,17,26,29,32,33,38,40,43,44],four:[37,42,44],fourpmtimelock:42,fraction:38,frame:[4,13,20,28,35],free:[5,11,13,16],freed:3,freeli:29,freez:40,frequenc:7,fresh:[29,42,46],freshkei:13,freshli:[38,44],friend:37,friendli:28,from:[0,1,2,3,4,5,6,7,8,9,10,11,13,14,15,16,17,18,19,20,22,23,25,26,27,28],fromcountri:38,front:[42,44],frontend:21,frustrat:11,ftx:[23,29],fulfil:[6,11],full:[4,5,6,8,9,13,20,23,24,25,28,35,40,41,42],fulli:[4,5,8,9,11,13,18,25,28,31,32,37,38,40,44,45],fullnodeconfigur:41,fullysign:13,fun:[2,5,12,13,14,22,23,29,31,39,40,41,42,43,44,46,47],fund:[11,20,35,40,42],fundament:[5,11,42],fungibl:[2,6,18,38,40,42,43,44],fungibleasset:[6,19,32],further:[2,7,11],futur:[3,5,6,8,11],futuretransact:41,fuzz:32,fxrespons:40,fxtransactionbuildtutori:40,fxtransactionbuildtutorialtest:40,gain:21,garbag:[3,4,13,26],gather:[19,22],gatherfrequ:22,gatherourinput:40,gatherremotest:22,gave:29,gavin:11,gbp:[2,43],gcd:11,gear:33,gener:[0,1,2,3],generatecount:22,generatefix:29,generateiniti:14,generateirsandfixsom:7,generateissu:[42,43],generatemappedobject:31,generatemov:[42,43],generateredeem:[42,43],generatespend:[13,40,42],generatetransact:41,generatexxx:40,genuin:4,get:[0,3,4,5,11,13],getamount:46,getanynotari:47,getbefor:42,getbloomfilters:4,getclass:42,getcommand:[42,43],getcontract:42,getdummy_cash_issuer:46,getdummy_pubkey_1:46,getdummy_pubkey_2:46,getencumbr:42,getfacevalu:42,getfix:7,getflowtrack:13,getinput:[32,42],getinstat:32,getissuanc:42,getkei:42,getlegalcontractrefer:[42,43],getmaturityd:42,getmega_corp:46,getmega_corp_pubkey:46,getnotari:47,getnotarysignatur:13,getorthrow:14,getoutput:[32,42],getoutst:32,getowner:[42,43],getparticip:42,getprotocolvers:3,getrequiredcommand:43,getresourceasstream:39,getresultorthrow:22,getsign:[42,43],getter:[31,42],gettimestamp:42,gettransact:[14,40],getvalu:[42,43],getvaulttransactionnot:41,github:[1,8,16,17,44],giusepp:32,give:[5,10,11,14,24,28,29,32,39,40,42],given:[0,2,5,9,11,13,23,29,31,32,34,38,41,42,43,47],givenpric:13,glanc:27,global:[4,5,11,32,38],glue:13,gnu:1,goal:[4,11,18,21,33],goe:3,gone:[13,32,42],good:[0,4,13,14,23,42,43,46],got:[13,23,26,29,45],gover:42,govern:[20,35],gps:5,gr1:2,gr2:2,gr3:2,grab:44,grade:38,gradlew:[0,10,17,20,22,25,27,30,35,37,41,44,45],grain:3,grammar:4,granular:11,graph:[3,11,14,21,26,31,32,41],graphit:26,graphstream:41,great:[0,20,32,35],greater:4,greatest:11,green:[17,44],grip:16,groom:11,group:[2,6,8,10,11,19,23,27,28],groupclaus:43,groupid:44,groupingkei:[2,43],groupstat:[2,42,43],grow:41,guarante:[18,33,38],guava:[4,42],gui:[13,17,44],guidelin:[16,17,19,32],hack:[11,32],had:[5,13,14,32,38,42],hand:[12,13,16,25,28,37,40,42,44],handa:32,handi:14,handler:[10,12,13,28],handshak:29,happen:[4,5,11,12,13,19,23,29,33],happi:[35,39],happili:29,hard:[4,11,13,33],harder:[11,36,42],hardwar:8,hase:7,hash:[5,11,13,14,18,21,23,26,29,32,38,40,41,42],hashcod:[2,42],hashmap:22,haskel:32,hasn:22,hassl:13,hat:33,have:[0,2,3,4,5,6,7,9,10,11,12,13,14,16,17,18,19,20,21,22,23,24,26,27,28,29,31,32,33,34,35,36,37,38,39,40,41,42,43,44,46,47],haven:[42,44],head:[2,41],heap:13,hearn:11,heart:42,heavi:33,heavili:11,hedg:[6,7],heirarchi:4,held:[28,31,42],hell:13,hello:13,help:[4,11,12,13,25,29,35,40,42,44],helper:[2,7,9,13,28,38,40,42,47],henc:[5,7,11,28],her:42,here:[0,4,5,8,10,11,13,14,15,17,18,19,23,25,26,29,31,32,38,40,41,42,43,44,46],herself:41,hidden:[24,28],hide:19,hierach:0,hierarch:13,hierarchi:13,high:[11,13,32],higher:[3,4,5,26,44],highest:19,highli:[0,32],highlight:32,hint:0,histor:29,histori:34,hit:[11,39],hoc:32,hocon:8,hold:[2,9,11,22,23,28,32,40],holder:[4,11,42],holidai:[7,29,38],home:[17,35],homepath:[10,44],hood:46,hope:28,hospit:13,host1:22,host2:22,host:[8,10,22,25,28,29,30,37,44,45],hostandport:8,hostil:36,hostnam:[37,44],hotspot:4,hour:13,hous:27,how:[0,2,3,4,6,11],howev:[0,5,6,7,8,11,13,23,28,29,30,31,34,38,39,40,42,43,44,46],html:[1,4,44],http:[1,8,16,17,20,26,28,29,30,35,37,39,42,43,44],https:8,hub:[13,18],human:[5,8,11,13,29,35],hundr:13,hurt:[13,29],icon:16,idea:[0,4,11,13,16,17,21],ideal:[13,42],ident:[5,8,11,13,14,18,19,22,23,24],identicon:32,identifi:[7,9,11,13,18,20,23,24,26,28,29,31,32,35,38,40,43,45],identiti:[5,13,28,38,47],identityless:11,identityservic:28,ifmatch:32,ifnotmatch:32,ignor:[8,13,41,42,43,44],iii:9,illegalargumentexcept:[4,13,29,41,42,43,46],illegalstateexcept:[2,4,40,42,43],illustr:[25,38,42],illustrat:4,imag:[23,44],imagin:[2,4,13,42,43],immedi:[3,11,28,40],immut:[4,7,11,29,42],immutabl:[4,11],immutablelist:42,imper:4,implement:[0,2,3,4,5,6,7,9,10,11],impli:[13,31],implic:[5,11,13],implicit:45,implicitli:7,important:[19,33],importantli:40,importattach:39,impos:[29,42],imposs:[11,23,29],improv:[32,33,42,43],improve:11,improvement:32,inact:28,inadvert:42,includ:[0,2,4,5,6,8,9,11,13,17,18,19],include:9,inclus:[2,23],incom:[28,32],incompat:46,incomplet:22,inconsist:0,inconveni:42,incorpor:[16,29],increas:[4,20,35],increment:[0,3],inde:29,indent:4,independ:[5,20,29,31,35,43],index:[7,11,12,17,31,33,40,42,44,47],indexsourc:12,indic:[3,4,7,8,12,13,32,37,40,42],indicat:22,individu:[4,19,20],indivis:38,industri:[15,16,18,20,26,35],inf:[9,44],infer:46,influenc:26,info:[13,14,31,41],inform:[4,5,8,9,11,13,14,17,27,28,29,30,32,38,39,42,43,44,45],infrastructur:[3,11,14,21,26,28,32,42],ingredi:40,inher:11,inherit:[4,42,43],inidividu:40,init:29,initi:[5,9,13,17,20,22,28,29,32,35,37,40,41],initial:[18,19],initialis:[14,25,28,31,47],inlin:[13,40],inmemorynetworkmapservic:28,inoutgroup:[2,42,43],input:[2,5,6,11,13,18,19,20,22,23,27,29,32,34,35,39],inputcash:46,inputindex:47,inputslist:40,inputst:47,inquisit:44,insert:[4,5,14,26,28,29,31,40],insid:[3,9,11,13,14,23,28,35,36,40,42],inspect:[22,44,45],instal:[0,1,8,10,12,16,17,32,35,41,42,44],installdist:41,instanc:[2,4],instance:46,instant:[4,12,13,29,38,40,42],instanti:[9,11,12,13,26,32],instat:46,instead:[4,11,13,14,21,24,28,32,38,42,47],instigat:5,institut:11,instruct:[16,17,18,26,39,41,42,44],instruction:19,instrument:[6,7,12,28,40,44],insuffici:[11,40],insufficientbalanceexcept:42,integ:[3,32,38,42,47],integer:42,integr:[0,4,8,11,13,16,17,20,23,26,29,31,32,35,39,44,45],integrat:19,integrationtest:45,integrationtestingtutori:45,intellig:4,intend:[4,6,10,11,13,14,19,26,27,28,29,31,36,38,44,46],intent:[2,9,25,29,32,42],intention:4,inter:32,interact:[3,4,11,13,14,24,29,32,40,42],interchang:[18,38,40],interest:3,interest_r:[8,37],interfac:[0,3,4,6,9,12,19,21,24],interior:32,interleav:22,interledg:32,intermedi:40,intermediari:[20,35,38],intern:[4,9,10,13,24,26,28,31,32,38,42,44],internalis:4,interop:[15,32,42],interoper:28,interpol:38,interpret:[4,11,22],intersect:42,interv:[22,38],intervent:28,intesa:32,introduc:[4,5,12,18,29,32,42],introductori:[19,44],intuit:[4,27],invalid:[5,13,29,38,42],invari:[22,42,45],investig:13,invoc:[3,13],invoic:39,invok:[3,4,9,11,12,13,26,28,29,32,44],invoke:13,involv:[5,6,11,13,28,34,38,40,42,45,47],ipsa:29,irrelev:12,irs:[6,7,19,21,29,32],irsdemo:[8,23,35],irsexport:7,irstest:7,irsutil:7,isbefor:42,isconsist:22,isda:[20,32,35],isdebug:44,isempti:[29,40,42],isinstanc:13,isn:[3,4,11,13,36,38,42],isnotari:41,isnotempti:39,isol:43,issu:[2,5,6,11,14,16],issuanc:[6,38,42,43],issue:[2,6,18,22,41,42,43],issuecash:[22,41,45],issuecommand:43,issuedbi:[45,46],issuer:[6,11,13,14,27,38,40,42,43,46],issuer_kei:31,issuer_ref:31,issueref:[41,45],issuerparti:31,issuerref:31,issuetransact:47,item:[18,40,42,44],iter:[13,32,33,42],iterabl:[31,41],iterat:[29,40],itself:[3,5,7,8,11,12,13,20,24,26,28,29,31,32,35,37,39,40,41,42,46],jar:[0,1,8,9,10,11,25,26,30,32,37,39,40,44],jarandsourc:10,java:[0,2,3,4,9,10,11,12,13,15,16,18,26,28,29,30,31,32,37,38,39,41,42,43,44,46],javaag:40,javaclass:[13,31],javacommercialpap:42,javadoc:[4,10,44],javadocjar:10,javafx:32,javatesthelp:46,javax:31,jax:9,jdbc:[8,10,26,31,32,35,37,44],jdbcdatasourc:[8,37],jdbcx:[8,37],jdk1:17,jdk:[16,17,32,38,42,44],jdwp:10,jersey_vers:44,jetbrain:[15,16,17,44],jms:24,jmx2graphit:26,jmx:26,jmxtran:26,job:[13,22],jobs:22,johann:32,join:[8,24,31,32,42],jolokia:26,jpa:31,json:[8,26,28,44],judgement:4,jump:35,junit:44,just:[3,4,11,13,16,17,20,22,24,26,29,32,35,36,38,39,40,41,42,44,46,47],jvm:[3,10,11,13,15],kdoc:4,keep:[11,13,40,42,44],kept:[13,30,47],keymanagementservic:[13,28,29],keypair:[13,28,29,42,47],keystor:[8,28,30],keystorepassword:[8,37,41],keyword:[4,46],kick:13,kill:22,kind:[11,13,19,29,36,38,42,44],knob:22,know:[3,5,11,12,13,14,15,23,29,35,36,40,42,43,44,46,47],knowledg:29,known:[7,11,14,16,18,20,23,28,29,32,33,35],knownfix:29,koan:16,korea:42,kotlin:[1,4,9,13],kotlin_vers:44,label:[13,46],lack:[11,13],lambda:[13,26,46],land:7,lang:[9,46],languag:[3,4,10,11,13,15,16,17,18,32,38,42,43],larg:[11,13,24,29,32,35,38,39,40,42],larger:[4,11,36],last:[13,22,29,33,46],lastli:44,late:16,lateinit:14,latenc:5,later:[3,4,13,14,16,21,29,31,32,36,37,38,41,42,43,44,45],latest:[4,9,16,17,32,40,44],latestrecord:40,latex:32,latter:[4,41,42],launch:[12,29,41],layer:[8,11,13,14,24,28,29,31,32,34],layout:[10,25,32],lazi:29,lazili:26,ldap:32,lead:[4,11,43],leader:8,leaf:[18,23],leak:[3,5,11,13,29],learn:[11,13,14,15,19,35,38,42],least:[8,19,22,35,39,42,44],leav:[2,4,13,23,27,29,38],ledger:[5,6,7,11,13,18,19,26,29,31,32,35,37,38,39,40,42,44,45,46],ledgertransact:[13,32,38],leewai:36,left:[13,25,30,35,43,44,46],leg:[7,12],legaci:28,legal:[5,8,11,28,29,30,32,38,40,42,47],legalcontractrefer:[42,43],legalident:[14,40,41,45,47],legalidentitykei:[40,47],legallyidentifi:[13,29],less:[13,32,39,43],lesser:42,let:[2,4,11,12,13,14,22,23,24,26,29,32,35,38,39,40,41,42,43,44,46,47],letmein:[8,37],letter:[4,24],level:[0,2,4,5,7,9,13,17,19,20,22,23,24,26,27,28,32,35,36,38,40,42,43,46],lib:[1,10,25,30,37,40,44],liber:4,libor:[7,26,29],librari:[0,3,4,8,13,18,19,20,26,28,29,32,35,38,41,42,44],licens:[4,20,35],license:44,life:[13,42],lifecycl:6,lifecyl:6,lifetim:[7,9],lightweight:[14,18],like:[2,3,4,5,7,11,12,13,14,16,22,23,24,25,26,29,32,33,38,40,41,42,43,44],likewis:[29,42],limit:[2,6,11,18,22,42,47],linear:[28,38],linearhead:40,linearheadsoftyp:40,linearid:40,linearst:[38,40],liner:4,link:[4,11,13,29,32,37,38,44,45],linkabl:11,linkag:11,linux:[10,26,32],list:[0,1,2,8,9,11,13,22,23,28,29,31,32,33,34,35,38,40,41,42,43,44,47],listen:[0,4,28,41,44],listof:[14,29,31,40,41,42,44,45],liter:11,littl:[4,13,42,43,44,46],live:[7,9,13,20,28,32,35],livelock:11,lizard:18,llc:30,load:[0,5,8,9,11,13,19],loadtest:22,loan:[6,7,29],local:[0,1,8,9,10,11,13,17,18,19,22,25,26,28,31,32],local_branch_nam:44,localcertificatesbasedirectori:22,locald:29,localhost:[8,20,26,27,35,37,44],localtunnelstartingport:22,lock:[4,6,8,31,42],log4j2:[26,37],log4j:[32,44],log:[0,3,8,10,13,17,19],log_sender:39,logger:[13,26],loggerfor:26,logic:[2,5,11,12,13,14,18,24,31,32,36,38,39,40,42,43],logictyp:41,login:[10,27,41],loglevel:26,london:[8,10,30,37,39,44],longer:[0,4,7,8,13,30,32,35],longrang:22,look:[0,2,4,7,13,14,22,24,26,29,33,35,38,39,42,43,44,46],lookup:8,loop:[4,7,22,41,42,45],loquitur:29,loss:29,lot:[4,7,11,16,32,35,36,42],low:[5,13],lower:[4,40],lowest:[19,24],lurch:13,machin:[8,11,12,13,18,19,22,32,37,41],macos:[10,32],made:[4,7,11,13,28,29,32,33,38,40,41,44],magicnumb:47,mai:[0,3,4,5,10,11,13,16,17,18,19,22,24,25,26,28,29,31,32,33,36,37,38,40,41,42,43,44,45,46],mail:[33,35],mailbox:28,main:[0,8,12,13,16,22,24,28,30,32,39,41,43,44],mainstream:21,maintain:[5,11,18,42,47],maintan:29,mainten:24,major:[0,13,32,33],make:[0,1,3,4,5,7,10,11,13,14,16,19,22,29,32,33,35,36,39,40],maker:15,maketransact:14,malici:[13,32,36,40],manag:[8,11,13,16,18,19,22,24,26],mandatori:42,mani:[4,5,10,11,12,13,14,22,29,32,38,39,42,43,44],manifest:0,manipul:[38,40],manner:[11,13,32,41,42,43],manual:[0,10,12,13,25,40,47],map:[0,2,4,7,8,9,13,14,18,19,22],mapchang:41,mappabl:42,mappedschema:31,mappedtyp:31,margin:[18,19],mark:[3,4,6,13,18,31,42],markdown:4,marker:[13,36],market:[19,44],marshal:3,master:[33,44],match:[2,3,11,13,23,29,36,38,39,40,41,43,45],materi:43,math:19,mathemat:38,matter:[13,20,29,35,42],matur:[5,6,7,25,26,29,42],maturityd:42,maven:[0,10,17,32,42,44],mavenloc:10,mavenpubl:10,maximis:11,maximum:11,maybestx:13,maybetraderequest:13,mbean:26,mean:[3,4,5,9,11,12,13,14,16,18,20,22,23,29,35,38,40,41,43],meandref:41,meaning:[5,6],meaningfulli:39,meant:[13,22,44],meantim:45,meanwhil:41,measur:[7,20,35],mechan:[9,18,29,32],meet:[2,28,40,42,44],mega_corp:[14,46],mega_corp_key:14,mega_corp_pubkey:46,megacorp:14,member:[7,8,32,35],memori:[13,14,24,28,40],menlo:4,mention:[12,13,16,29,42],menu:[16,44],mere:7,merg:[11,32,38,40,42,44],mergeabl:42,merkl:[18,19],merkleroot:[23,29],merkletreeexcept:[23,29],mess:13,messag:[0,3,4,8,10,11,13,14,18,19,21,22],messagingserveraddress:[8,28],messagingservic:[24,28],met:[9,38,44],meta:[9,44],metadata:[39,44,47],method:[2,3,4,5,8,9,12,13,14,22,26,28,29,31,32,36,37,38,40,42,47],metric:[20,26,35],micro:[32,43],mid:5,middl:[4,13],middlewar:[18,28],midpoint:44,might:[4,7,11,13,17,29,31,36,40,42,44],migrat:40,mike:11,mileston:[19,30],min:41,mind:[4,13,29],mine:11,miner:11,mini_corp_pubkey:14,minim:[2,11,13],minimis:[5,6,11,24],minimum:[3,7,11,38,40],minor:[32,33],minu:42,minut:[0,13,15,29,44],mismatch:[11,42,46],miss:[4,8,13],mission:26,mistak:[32,36,40],mix:[0,4,32],mock:[14,44],mocknetwork:[14,25],mocknod:[14,28],mockservic:38,modal:44,mode:[8,25,30,32],model:4,modest:11,modif:[28,38,40,42],modifi:[5,6,7,9,10,13,17,18,38,40,42,44],modul:[4,8,14,32,40,42,44],moment:[13,14,32],monei:[29,40,42],monitor:[4,9,19],month:[7,13,33],monthli:44,more:[0,2,3,4,5,6,7,8,10,11,13,14,15,16,17,18,20,23,25,26,28,29,30,31,32,34,35,38,39,40,41,42,43,44,45,47],moreexecutor:4,mortensen:32,most:[0,2,4,7,11,13,16,25,26,37,42,43,44],mostli:42,motiv:[19,44],move:[2,6,9,11,13,14,27,32,33,35,40,41,42,43,46,47],movement:[13,42],movetransact:47,movetransactionbuild:47,much:[4,11,13,15,29,31,32,35,36,40,42],multi:[4,13,19,24,32],multigraph:41,multilater:[6,32],multipl:[2,3],multipli:7,must:[0,2,3,4,5,6,8,9,10,11,12,13,26,28,29,31,32,36,37,38,39,40,41,42,43,44],mustafa:32,mutabl:[4,11,38,42],mutablelistof:40,mutat:[11,28,40],mutual:[5,6,13,36],myfil:26,myident:[29,47],myinfo:[29,40,47],mykei:38,mykeypair:13,mylegalnam:[8,30,37],mynodeinfo:29,mypublickei:13,mysigningkei:[29,47],mysql:21,nail:4,namedbyhash:19,nameserv:8,namespac:13,narrow:[2,4,27],nativ:[13,16,40],natixi:32,natur:[0,40,42],naval:5,navig:[10,20,35,44],navistar:5,nearestc:[8,10,30,37,44],neat:46,necessari:[4,5,18,29,32,33,44],necessarili:[31,38],nee:32,need:[0,1,2,4,5,7,9,11,12,13,14,16,17,18,20,22,23,26,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],neg:[38,44],negoti:[11,38,40],neither:13,nest:[13,45],net:[2,6,7,8,9,10,13,14,26,28,30,31,32,34,37,39,40,41,42,44,45,46],network:[5,8,11,12,13,14,18,19,21,22,23],networkmap:[10,44],networkmapaddress:[8,10,37,44],networkmapcach:[8,9,13,28,41,47],networkmapservic:8,networkmapupd:41,neutral:21,never:[4,5,11,18,42],newdeal:29,newli:[12,44,47],newnotari:5,newowner:[42,47],newsecurerandom:32,newstat:40,next:[4,7,12,14,17,23,25,29,32,36,42,44,45,47],nextdoubl:41,nextfixingof:12,nextlong:41,nextscheduledact:12,nfinal:39,nice:[29,42],nio:4,noddi:26,node:[0,3,6],node_dir:10,node_directory:37,nodea:[8,10,37,44],nodeb:[10,44],nodec:44,nodefilt:22,nodehandl:22,nodehost:22,nodeident:41,nodeinfo:[8,13,28,41,45],nodeinterestr:[9,29,40],nodesslconfigur:41,nodex:44,nodisruptionwindowm:22,non:[1,3,4,5,6,8,11,13,18,19,22,24,28,32,38,40],nonc:43,nondeterminist:45,none:[2,12,13,20,23,29,31,35,43],nonemptyset:32,nordea:32,normal:[2,3,6,7,9,10,13,17,22,23,25,28,32,38,39,40,42,43,47],north:42,notabl:[4,44],notaris:[5,11,13,19,32,35,38,40,42,44,45],notary:13,notary_committed_states:35,notarychang:[32,40],notarychangeflow:5,notaryclusteraddress:[8,28],notaryexcept:47,notaryflow:[13,28,40,47],notaryfutur:45,notaryident:[13,14,41,45],notarynod:[13,14],notarynodeaddress:8,notarysig:13,notarysignatur:[13,47],notarytous:38,note:[0,1,4,6,7,8,9,10,11,13,14],noth:[4,11,12,13,32,36,42,44],notic:[4,35,43],notif:[22,24,28,39],notifi:[24,25,47],notion:[7,11,32],notnul:[42,43],now:[4,10,11,13,14,19,23,26,32,35,37,38,40,41,42,44,45,46,47],nugget:42,nullabl:42,nullpublickei:42,number:[0,2,4,6,7,11,14,18,20,22,27,28,29,31,33,35,37,38,40,42,43,44],numer:[9,11],obj:[42,43],object:[2,3,4,6,7,8,11,12,13,14,18,19,21,24,26,29],oblig:[6,7,32,38,40,44],obligat:2,obligor:6,observ:[3,5,7,11,12,13,22,25,32,41,44],observatori:5,obsolet:[12,32],obtain:[4,5,8,12,13,14,16,23,29,30,32,35,44,47],obtian:44,obviou:[4,5,11,29],obvious:[0,7,18,25],occasion:[0,16,17],occur:[5,12,13,28,42,45],occurr:5,odd:42,off:[13,19],offer:[13,17,28,31,44],offlin:24,offset:7,ofsecond:40,often:[4,6,7,11,13,17,29,40,42],oftenor:29,oil:[32,46],old:[5,13,18,32,40,42,47],omit:[12,20,35],onc:[3,4,5,9,13,18,30,33,38,40,42,45],once:[1,7,10,12,13,18,25,30,31,35,37,38,39,40,42,44],onchainasset:6,one:[2,5,17,23,29,35,40,44],ongo:3,onledgerasset:42,onli:[0,2,3,4,5,7,8,10,11,12,13,15,18,23,24,25,26,27,28,29,30,32,33,35,36,37,38,40,41,42,43,44,45,47],only:[13,28,37],onto:[3,4,13,42],opaquebyt:[32,41,45],open:[2,3,5,10,11,13,16,17,20,26,28,32,35,41,44,45],openattach:39,opene:19,opengamma:[20,32,35],openssl:22,oper:[7,8,12,13,16,18,26,28,29,32,36,37,38,40,41,42,47],oppos:0,opposit:2,opt:[10,22,44],optim:4,optimis:32,option:[0,1,4,7,8,12,13,18,22,25,29,30,31,32,40,42,43,44,45,47],optional:[8,40],oracl:[7,9,11,16,18,19,21,23,24,26,28],oracleparti:29,orchestr:[21,32],ordain:7,order:[0,1,3,4,5,6,7,11,13,17,20,21,22,25,28,29,31,32,35,37,38,39,41,42,43,44,45],ordernumb:44,ordinari:[11,13,32,42],ordinarili:29,org:[1,8,37,42,43,44],organis:[0,31],orient:19,origin:[23,31,32,38,39,40,42,43,44],originalst:5,orm:31,osx:44,otc:31,other:0,otherparti:[13,29],othersid:[13,39],otherwis:[3,4,8,9,10,12,13,28,29,36,40,41,42,45],our:[0,4,5,11,12,13,14,15,16,22,23,28,29,32,33,35,38,40,41,42,43,44,46,47],ourkei:40,ournotari:47,ourselv:[13,29,42,47],oursign:40,oursignatur:13,ourstat:40,out:[0,2,4,5,6,11,12,13,16,20,23,24,26,28,29,32,33,34,35,36,38,40,41,42,43,44,47],outcom:13,outer:43,outlin:[11,13,29,32],outpoint:11,output:[0,2,5,6,10,11,13,18,19,23,27,29,32,35,39],outref:[14,40],outsid:[10,11,13,28,29,37],outstand:6,over:[0,4,5,7,8,10,11,13,14,18,22,23,24,26,29,31,32,35,38,40,42,44],overal:[5,12,40,46],overdu:12,overflow:4,overidden:[8,10],overload:[13,38],overlord:18,overnight:38,overrid:[2,9,12,13,22,29,31,41,42,43],overridden:9,overutilis:22,overwhelm:11,own:[4,5,6,10,12,13,16,19,22,25,26,27,28,29,31,32,33],ownablest:[13,38,42],ownedquant:41,owner:[12,13,31,38,40,42,43,46,47],owner_kei:31,ownership:[13,14,42,47],owningkei:[13,23,29,40,42,47],ozturk:32,p2p:32,pack:42,packag:[9,16,31,32,38,44],packet:11,page:[17,29,33,35,44],pai:[6,13,19,20,27],paid:[6,7,11,20,35,42],pair:[11,13,14,28,29,30,38,40,41,42],pane:17,paper:2,paragraph:22,parallel:[3,11,22,29,45],parallelis:11,param:[22,31,47],paramet:[3,4,9,12,13,22,26,29,32,38,40,42,43],parameteris:[11,22,40],parent:[13,18],pars:[8,29,38,42],part:[0,2,3,4,5,6,9,10,11,12,13,17,19,22,23,28,29,30,31,32,35,36,37,38,40,42,43,44],parti:[4,5,6,7,11,12],partial:[5,11,13,19,23,29,36],partialmerkletx:29,partialtx:[13,23],particip:[5,11,27,28,29,32,42,47],particular:[2,4,5,9,11,13,16,18,19,23,26,29,31,32,38,40],partner:[20,35,40],partyandrefer:[4,41,42],partynod:14,partyrefer:[4,42],pascal:4,pass:[2,9,13,22,23,26,28,29,31,32,35,39,40,42,43,45,47],password:[3,8,10,26,27,30,32,37,41],past:[4,35,42,44],patch:[4,32],path:[4,8,9,10,12,17,22,24,26,32,40,41,42,44],path_to_loadtest_conf:22,pattern:[4,11,40,41],paus:[10,25],paycash:[41,45],paye:11,payer:[7,11],payload:29,payment:[6,7,11,12,13,18,20,29,35,42],pdf:[29,39],peer:[13,21,23,27,28,29,42,44],penni:[31,38,42],peopl:[4,11,13,15,18,42],per:[4,10,11,12,19],perfect:43,perform:[0,4,5,7,11,12,13,16,18,20,22,29,32,35,38,39,42,43,44],perhap:[4,11,24,37,42],period:[7,30,35,40],perman:[13,39,40,42],permiss:[3,8,19,21],persist:8,persistentcashst:31,persistentst:31,perspect:[11,13,28,42],pertin:44,phase:32,phrase:29,physic:[5,28,32,37],pick:[0,13,16,24,32,33,42],piec:[4,5,11,13,18,22,37,38,42,46],pip:1,pki:[11,32],place:[1,4,7,9,11,12,13,16,20,21,23,24,29,32,33,35,38,41,42,43,44],plai:[11,19,22],plain:8,plan:[11,13,29,32],platform:[5,7,9,10,11,12,13,15,16,23,32,35,36,38,42,44],pleas:[4,11,16,31,32,35,39,44],ploadtest:22,plu:[8,28,38],pluggabl:32,plugin:[3,8],pluginservicehub:[9,10,13,28,29,32],pluginserviceregistri:44,point:[3,4,5,6,9,10,11,13,18,22,26,28,29,31,32,33,36,40,41,42,43,44],pointer:[5,13,38],pointless:4,polish:32,polit:[20,35],poll:[22,30],pool:[4,11],poor:11,pop:[17,44],popul:[28,40],popular:15,popup:[16,17],port:[0,8,10,22,27,28,32,33,37,44],portfolio:[19,20,32],portion:40,posess:13,posit:[4,11,13,42,47],possess:[5,47],possibl:[2,11,13,16,20,22,28,29,30,32,35,39,40,42],post:[28,44],postgr:21,potenti:[4,5,13,15,20,29,35,42,44],pound:[38,42],power:[8,11,28],practic:[8,11,20,32,35,40,42],pre:[1,7,13,14,16,30,42,44,46],preced:42,preceed:0,precis:[5,11,21],precondit:[4,42],predic:45,predict:22,predominantli:16,prefer:[0,4,17,27,31,44],prefix:[4,31],preliminari:[20,35],prepar:[11,32,42],prescrib:37,present:[2,3,5,6,7,8,9,10,13,21,22,25,29,31,32,34,35,38,40,42,43,44,47],preserv:[5,11,40],press:[16,44],pretend:[26,38],pretti:[11,13],prevent:[20,35,36,40,42],previou:[11,13,22,32,38,43,44,46,47],previous:[7,12,29,32,44,47],price:[11,13,29],primari:[16,29],primarili:[0,6],primit:[38,46],print:[3,26,32,35,36,37,41,45],println:[39,41,45],printorvisualis:41,prior:47,privaci:[4,5,11,13,21,29,32,40,42],privat:[4,8,9,11,13,14,29,30,31,37,39,40,42,44],privatefoo:4,privatekei:[13,28],probabl:[0,42],problem:[5,11,13,16,17,29,37],proce:13,procedur:[13,30,42],process:[0,2,3,5,7,9,10,11,12,13,19],processor:[11,22],produc:[1,12,25,40,42,45,46],product:[4,10,12,15,16,20,21,32,33,35,37,38,40,44],profound:11,program:[3,4,11,26,28,32,35,38,42],programmat:41,progress:[5,7],progresstrack:[13,29],project:[0,10,16,17,19,20,28,30,32,35,40,42],prolif:32,promis:32,prompt:[16,44],proof:[6,11,23],propag:[3,13,26,42,43,44],properli:[13,28,36],properti:3,proport:[20,35],propos:[13,19,28,36,40,44],proprietari:[20,32,35],prose:[29,38,42],prospectus_hash:39,protect:[13,20,28,30,35],protocolvers:3,prototyp:[4,21,29,32,34,42],provabl:40,prove:[5,11,42],proven:[20,35],provid:[0,1,2,3,4,5,6,7,8,9,10,11,13,14,16,18,19,22,23,24,25,26,27,28],provision:38,proxi:[3,41,45],pseudo:29,pseudonom:38,ptx:[13,29,39],pubkei:46,publicfoo:4,publickei:[13,19,28],publish:[10,29,44],pull:[17,40,44],punish:29,purchas:[13,35,44],purchaseord:44,purchaseordercontract:44,purchaseorderst:44,pure:[6,11,29,45],purpos:[5,6,13,18,31,34,38,40,41,42,44,45],push:[3,33],put:[4,13,18,19,22,33,40,41],python:[1,32,44],qualifi:[8,9,31],qualiti:40,quantiti:[2,11,22,38,40,41,42,44,45],quasar:[9,10,13,18,28,29,40,44],quasar_vers:44,queri:[3,7,8,9,12,19,28],queryablest:[28,31],queryrequest:29,question:[4,5,12,17,29,38],queu:[18,24],queue:[3,4,13,24,28],quick:[29,44],quickcheck:32,quickli:[11,18,30,36,42],quit:[3,4,5,13,16,42],r3cev:22,r3corda:[10,32,44],r3dlg:33,r3prototyp:[1,40],raft:[8,28,32,34,35],rais:[2,5,43],ran:[0,35],random63bitvalu:43,random:[11,12,22,32,35,38,40,41,47],randomis:32,randomli:[22,41],rang:[2,5,31,44],rapid:[4,10,21,33],rare:[8,38],rate:4,ratesfixflow:[23,29,40],rather:[2,4,11,13,17,24,25,32,37,40,41,42],raw:[24,26,35],rdbms:[31,32],rdms:32,reach:[5,7,11,12,20,29,32,35],reachabl:13,react:22,reactiv:32,read:[4,8,10,11,13,15,19,21,23,26,28,29,32,42,44],readabl:[8,13,15,35],readi:[2,33,42,44],readili:[38,43],readm:44,readme:[4,35,44],real:[4,20,25,29,30,32,35,38,40,42],realis:13,realist:38,realiti:[7,45],realli:[4,5,11,13,23,29,42],reason:[4,5,7,11,13,16,22,32,36,38,42],reassign:42,recal:7,receipt:28,receiv:[3,6,7,9,11,13,18,20,22,28,29,32,33,35,36,39,40,42,44,45],receiveandcheckproposedtransact:13,receiveandvalidatetraderequest:13,received:29,receiving:13,recent:[16,32,44],recheck:40,recipi:[6,11,35,39,42,45],recognis:[9,11,13,16,42],recommend:[0,4,16,24,34,35,44],record:[5,12,14,18,28,31,39,40,41,44,47],recordtransact:[14,28,40,47],recreat:[13,17],red:[7,23,44],redeem:[2,6,42,43],redempt:42,redeploi:44,redesign:32,redirect:37,reduc:[4,10,20,35],redund:4,ref:[13,14,29,38,40,41,45,46],refactor:32,refer:[0,4,5,6,7,8,9,11,12,13,16,18,20,28,29,32,34,35,38,39,40,41,42,43,44,46,47],referenc:[5,39,44],refin:32,reflect:[13,22,32,40,42,43,44],refresh:[0,16,32,44],refus:17,regard:[5,16,37,40],regardless:13,regener:[7,33],registerflowiniti:[9,13,29],registerrpckryotyp:[9,41],registr:[9,28],registri:9,regul:[40,42],regular:[13,18,26,35,37,38,42],reifi:40,reissu:42,reissuanc:11,reject:[28,29,40,42],rel:[8,10,11,15,16,29,32,40],relabelablestep:13,relai:39,relat:[7,12,19],relationship:[28,42],relax:[22,32],releas:[3,18,19,20,27,30],relev:[2,9,10,11,12,18,19,28,29,32,38,40,42,43,47],reli:[3,10,11,20,32,35,36],reliabl:28,relianc:11,relic:26,religi:4,remain:[10,12,13,29,32,40,42,44],rememb:[4,12,17,36,40],remind:[13,36,43],remot:[0,8,9,10,17,22,25,28,37,39,40,44],remote_branch_nam:44,remotemessagingport:22,remotenodedirectori:22,remotesystemdservicenam:22,remov:[13,23,32,33,41,42],renam:[13,32],render:[4,13,25,27,32],renderifsupport:39,repay:43,repeat:[0,4,7,13],replac:[3,5,7,16,20,26,32,33,35,38,40,41,42,44],replai:32,replic:[8,11,34,35],repo:[0,44],repoint:5,report:[13,27,32,43],repositori:[0,4,10,16,17,32,33,35,44],repres:[4,6,7,9,11,13,22,28,29,31,32,38,40,41,42],represent:[3,7,31],reproduc:40,republish:44,request:[0,3,5,8,9,11,13,19,22,24,28,29],requestingparti:47,requir:0,requiredcommand:[2,32,43],requiredflow:9,requiresinglecommand:[42,43],requirethat:[42,43],requisit:44,research:32,resel:29,resend:28,resent:28,reset:[7,25],reshap:11,resid:28,residu:40,residualamount:40,residualoutput:40,resolut:[11,13,47],resolv:[4,13,14,20,29,35,37,38,42,43],resolvetransactionsflow:[13,14,39],resolvetransactionsflowtest:14,resourc:[0,3,8,9,11,13,22,29,40,44],resp:29,respect:[0,4,11,13,35,40,44,45],respend:11,respond:[13,28],respons:[3,5,9,11,12,13,24,28,29,31,40,41,44,45,47],rest:[5,9,11,13,21,26,32,43,44],restart:[9,13,28,30],restor:[9,13,17,18],restrict:[2,4,20,25,35,40],restructur:[32,43,44],restructuredtext:1,result:[4,5,7,8,11,13,14,20,27,28,29,30,31,32,35,36,40,41,42,44,47],resultfutur:14,resum:[13,28,30,32],resurrect:13,resync:16,retain:24,rethrown:3,retri:[13,21,24],retriev:[7,13,30,34,39,41],retrieveoutput:46,returnvalu:45,reus:[3,11,46],reusabl:[2,18,29,32,39,42,43],reveal:[5,11,13,23,29,32],revers:[13,28],revert:6,review:[4,32,33,44],revis:[7,17,40],rewrit:13,richer:10,right:[4,13,16,17,26,29,32,33,35,36,40,44],rightmost:23,rigid:11,rigidli:4,risk:[13,20,35],robert:32,robust:32,rogerwilli:44,role:[11,12,28,35,39,41],roll:[7,13,32,35],rollov:[38,42],root:[8,10,23,28,30,33,37,40,44],roothash:29,rotat:[26,32],roughli:[5,33],rout:[13,14,16,24,32],row:[26,27,31,35,38,42],rpcexception:3,rpckryo:3,rpcreturnsobserv:[3,41],rpcsincevers:3,rpcuser:[8,27,37,41,44,45],rui:32,ruin:46,rule:[4,13,20,28,29,32,35,42],run:[0,1,2,3,4,5,8,10,11,12,13,14,16],runbuy:35,runconfigur:[16,17],rundemonod:[27,32],runexampleclientrpc:44,runnetwork:14,runnod:[0,10,20,32,35,41,44],runparamet:22,runrecipi:[35,39],runsel:35,runsend:[0,35,39],runshellcommandgetoutput:22,runtim:[4,13,44],sacrif:44,safe:[3,4,9,11,13,30,36,41,45],sai:[4,5,11,16,20,22,35,37,42,43,47],sake:[20,35,45],sale:[35,42],same:[0,3,4,5,6,7,8,10,11,12,13,22,28,29,32,38,40,41,42,43,44,46],sampl:[0,9,10,13,19,20,25,32,35],sanction:42,sandbox:[11,12,21,32,36],saniti:13,santiago:32,sate:47,satisfi:[35,38,42,43],save:[4,13,32,42],saw:45,scala:[15,42],scalabl:[4,11],scale:[7,36],scenario:[11,25,28,38,40,44,45],scene:[13,42],schedul:[7,9],schedulablest:[12,28],scheduledact:12,schedulerservic:28,schema:19,schemafamili:31,schemaopt:31,schemaservic:31,scheme:[23,28],scienc:44,scope:[2,9,11,27,43],scotiabank:32,scotland:43,scrape:26,scratch:[38,42,44],screen:[4,16,17,27,32,42],script:[0,1,10,11,32,35,44],scroll:35,scrub:13,seamless:15,search:[27,28,40,42],sec:44,second:[2,7,9,13,14,22,29,35,38,40,42,43,44,45],secondari:13,secp256r1:32,secret:8,section:[8,11,19,22,29,32,33,40,44,47],securehash:[14,23,29,38,41,42,43,47],securerandom:32,see:[1,2,3,4,5,6,7,8,10,12,13,14,16,17,22,23,25,29,30,31,32,34,35,37,38,39,40,41,42,43,44,45],seed:13,seek:[11,32],seem:11,seemless:16,seemlessli:16,seen:[4,7,9,13,29,42],segment:10,select:[2,5,16,17,31,32,35,40,42,43,44],selector:2,selectschema:31,self:[10,22,32,35,45],selfissuecommand:22,selfissuest:22,selfissuetest:22,selfsignedtx:40,sell:[13,40,42,43],sellamount:40,sellerownerkei:13,sellersig:13,sellertradeinfo:13,semi:11,send:[4,5,11,13,14,23,24,26,28,29,32,33,35,39,40,42,44,45,46,47],sendandrec:[13,29],sender:[11,13,35,39],sending:29,sendsignatur:13,sens:[7,29,42,43],sensit:[12,20,23,35,36],sent:[12,13,29,32,38,40,42],separ:[2,5,8,9,10,11,13,19,23,24,26,29,32,35,38,40,42,43],seper:0,septemb:[20,35],sequenc:[11,28,32,45],sequenti:[13,45],seri:13,serial:[3,9,21,28,42],serialis:[3,4,9,11,13,18,21,29,32,42],seriou:[11,33],serv:[10,44,45],server:[3,8,9,10,21,24,26,28,30,32,41,44,45],servic:[8,9],servicehub:[9,10,13,24,28,29,39,40,47],servicehubintern:32,serviceident:29,serviceinfo:[41,44,45],serviceload:[9,29],serviceplugin:[9,29],servicetyp:[8,28,47],servlet:44,session:[12,24,28,32],sessionid:12,set:[2,3,7,8,9,10,11,12,13],setlifecycl:2,setof:[2,13,14,39,40,41,43,44,45,47],setter:[31,42],settim:[13,29,38,40],settl:[2,6,14,38,39],settlement:[6,13],setup:[10,12,14,25,30,37],sever:[0,8,10,11,13,28,29,31,34,35,37,41,42,45,46],sha256:[23,38,42,43],sha256sum:26,sha:[11,26],shape:11,share:[0,6,7,11,13,18,20,28,29,32,35,36,39,40,42,44],shasum:26,she:42,shell:[20,22,35,44],shoot:36,shortcut:21,shorthand:46,shortli:0,should:[0,2,4,5,6,9,10,11,12,13,17,19,20,21,22,23,28,29,30,31,32,35,36,37,38,40,41,42,43,44,45,46],shoulder:4,shouldn:[13,23,40,42,44],shoutout:32,show:[11,15,17,25,27,28,32,35,42,43,44],shown:[3,8,13,14,25,38,40,44],shut:[39,45],shutdown:[13,28],side:[3,11,12,13,16,25,29,35,36,38,39,40,44],sidebar:25,sidenot:37,sig:[29,32,42],sign:[5,7,8,11,13,14,18,19,21,23,24,28],signal:[18,40],signatori:40,signatur:[5,6,11,13,18,19,21,23,27,29,32,35],signaturesfromsel:13,signedtransact:[13,14,19,38],signer:[23,29,35,40,42,43],signfirsttx:14,signific:[0,11,29,32],significantli:[7,22,38,39],signing:[13,29],signingkei:29,signoff:5,signrequest:29,signwith:[13,14,38,39,40,42,47],signwithecdsa:[13,29],signwithourkei:13,silver:4,similar:[4,11,13,29,32,40,41,42,43],similarli:[31,40],simm:[18,19],simmvaluationdemo:[20,35],simpl:[0,3,4,6,7,8,9,11,13,14,16,17,19,20,21,22,26,28,29,32,34,35,38,39,40,41,42],simplecash:46,simplecashdoesntcompil:46,simplecashfailswith:46,simplecashsuccess:46,simplecashtweaksuccess:46,simplecashtweaksuccesstopleveltransact:46,simplenam:31,simpler:[11,15,43],simplest:[11,13,37,42],simpli:[4,10,11,13,14,22,24,28,31,32,34,38,42,44,46],simplic:40,simplif:32,simplifi:[2,4,6,11,28,34,38,40,42],simul:[8,19],simultan:[11,13,38,42],sinc:42,singl:[2,3,4,6,9,11,13,14,19,22,25,26,28,29,32,34,35,37,38,40,41,42,43],singlemessagerecipi:24,singleownerst:47,singleton:[9,13,29,42,43],singletonserializeastoken:[9,29],site:[4,32,33],situat:[4,11,23,32,40],size:[4,7,11,13,29,41,42,43,44],skeleton:14,skip:[13,38,42,44],sl4j:26,sleep:[22,39,41],slf4j:13,slightli:[0,34,40,42],slip:33,slot:32,slow:[4,11,22],slowest:11,small:[2,3,11,12,13,29,32,35,36,42],smaller:[2,32,43],smallest:38,smart:[14,19,21,29,32,40],smooth:42,snake:46,snapshot:[11,19,29,32,33,41],snapshots:44,snide:1,snippet:[13,44],socket:26,softwar:[11,13,33,36],sofu:32,sold:[13,38],sole:32,solut:13,solv:[11,13,29],solvenc:29,some:[0,3,4,5,6,9,11,12,13,14,16,20,21,22,23,26,28,29,31,32,35,37,38,40,41,42,43,44,45,46,47],somed:42,somehow:22,someon:[5,11,42,47],someth:[3,4,7,11,13,29,32,35,42],sometim:[0,11,13,18,26,38,40],someusernam:22,somewhat:[3,11,13,22,32],somewher:42,soon:[32,42],sophist:11,sort:[13,29,32],sound:[4,13,42],sourc:[7,8,10,12,13],sourcejar:10,sourcenotari:40,sourceset:26,sparingli:4,spawn:[9,45],speak:32,spec:32,special:[2,3,5,11,13,43,46],specif:[2,3,5,6,9,10,11,12,13,16,18,22,24,26,28,32,38,39,40,42,43,44,45],specifi:[1,2,3,4,5,6,8,10,11,13,18,21,22,23,30,31,32,37,38,40,42,43,44,45,46,47],speed:[11,13,15,44],spend:[11,13,14,21,28,36,37,40,42,45],spent:[11,42,46],sphinx:1,sphinx_rtd_them:1,spin:22,spirit:32,splash:[16,17],spline:38,split:[2,11,23,24,32,38,40,42,43],splittabl:42,splittablerandom:[22,41],spot:32,spread:[5,13],spreadsheet:29,spuriou:2,sql:[21,31,32,35,44],src:[8,13,28,39,44,45],ssh:22,sshuser:22,ssl:[8,32],sslconfig:41,sslkeystor:[8,30,44],stabil:44,stabilis:33,stabl:[3,9,33,41,44],stack:[9,13,28,29],stage:[4,6,13,38,40,42],stai:[11,28,40,42,43],stake:11,standalon:[25,29,32,41],standard:[2,4,9,10,13,16,18,20,25,26,28,32,35,37,38,40,41,42,43,44],standardis:[2,11,38,40],start:[0,3,4,7,9],startflow:[13,14,32,39,41,45],startflowdynam:[13,41],startflowpermiss:[41,45],startnod:[41,44,45],startprotocol:[8,37],startup:[8,9,26,32],startwith:41,state:[0,2,3,5,6,7,8,9],stateandref:[5,13,29,38,40,41,42,47],statehistori:47,stateless:11,statemachineinfo:41,statemachinemanag:[9,13],statemachinerecordedtransactionmap:41,statemachinerunid:13,statemachinesandupd:41,statemachinetransactionmap:41,statemachineupd:41,statement:[4,11,13,29,42],stateref:[11,12,23,31,38,40,47],statesoftyp:[40,42],staticservedir:9,statist:26,statu:[40,44],status:11,stdlib:44,stem:42,step:[5,12,13,19],stereotyp:40,still:[5,11,12,13,17,25,29,32,40,42],stock:[11,29],stone:22,stood:31,stop:[4,13,28,39,44],stopnod:14,storag:[8,11,13,14,18,19],storageservic:[39,40],store:[5,8,9,10,13,14,17,26,28,30,32,34,35,38,39,40,42,44,47],stori:[4,32],straight:44,straightforward:[13,42],strain:22,straincpu:22,stream:[3,13,24,25,32,41,45],stress:[4,22,32],strictli:[7,9,11],string:[0,8,13,22,29,31,35,38,41,42,44,47],strip:42,strong:15,strongli:16,stub:[20,32,35],studi:42,stuff:4,stx1:14,stx2:14,stx:[13,38],sub:[3,4],subclass:[6,13,31,38,42,43],subcompon:43,subdirectori:26,subflow:[5,9,13,28,29,40,47],subfold:[9,28],subgroup:11,subject:[8,10,18,20,35,44],submiss:29,submit:[4,5,13,22,24,30,32,35,44],subscrib:[3,24,32,39,41],subsequ:[18,30,35,40,42,45,46],subset:[6,23,32,43],substanc:44,substitut:[8,9,40],subsystem:[9,24],subtask:13,subtl:[4,11],subtract:38,subvert:36,success:[2,39,40,45],successfulli:[37,41,44],successor:[5,12,15],succinct:4,sudo:1,suffer:[11,20,35],suffic:13,suffici:[11,29,32,33,35,38,40,41],suffix:44,suggest:[10,16,24,42],suggestinterestrateannouncementtimewindow:[12,29],suit:[32,39],suitabl:[12,24,28,29,33],suitablecashst:40,sukrit:32,sum:[20,22,35,40,41,42,44,46],sumcashbi:[13,42],summari:[19,32,33,38],summaris:11,sumorthrow:2,sumorzero:2,sun:4,superclass:[6,32,38],superior:4,supersed:11,supertyp:42,suppli:[6,22,41],support:[2,3,4,5,6,7,8,9,10,11,13,15,16,19,21,24,25,26,29,30,31,32],supportedschema:31,suppos:[13,42],suppress:[4,32],suppresswarn:4,sure:[5,32,33,36,39,42,44,45],surfac:13,surround:4,surviv:13,suspend:[5,10],suspens:[9,28],swapping_signatures:13,swapsignatureswithsel:13,sync:[28,42,44],synchronis:[4,5,11,28,35],syntax:[0,15,42],system:[0,3,5,8,10,11,13,16,17,19,21,22,23,26,27,28,31,32,39,42,44],systemd:[22,37],tab:[4,10,16,17,32,35,44],tabl:[10,26,27,28,31,32,35,44],tableprefix:31,tackl:32,tag:[3,4,18,33,44],tag_nam:44,take:[2,4,7,9,12,13,14,21,22,23,26,29,30,32,33,35,36,38,40,42,43,44,46],taken:[9,42],talk:14,tamper:13,target:[1,4,8,11,14,15,20,25,26,35],tcp:[10,26,35,44],tear:19,teardown:14,techniqu:[4,11,21,29,44],technolog:19,tell:[1,13,41,44],tempalt:44,templat:[0,8],temporari:[10,13],temporarili:[13,33],tempt:[36,42],ten:42,tend:18,tenor:[7,26,29,38],term:[2,6,8,11,12,18,20,24,35,37,38,43],termin:[7,10,13,26,28,32,35,41,44],terminolog:11,test:[0,1,2,6,8,10,13],testcompil:44,testnam:22,testnet:[8,10,30,32,37,44],testpassword:45,testtimelock:42,testuser:45,text:[4,17,26,32,35,44,46],than:[2,3,4,5,10,11,13,17,24,25,26,29,32,38,40,42,44],thank:32,thedao:32,thei:[0,2,3,4,5,6,7,9,10,11,12,13,18,20,22,23,25,26,28,29,31,32,33,35,36,38,39,40,42,43,44],theirsign:40,theirstat:40,them:[0,2,3,4,7,8,9,11,12,13,14,16,17,19,21,22,23,24,26,28,29,31,32,33,35,37,38,39,40,41,42],theme:[32,36],themselv:[3,13,14,22,24,25,28,29,35,36,38,41,42],therefor:[0,3,9,10,11,13,17,18,20,21,28,33,35,36,40,42],thi:[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,16,17,18,19,20,22,23,25,26,27,28,29,30,31,32,33,35,36,37,38,39,40,41,42,43,44,45,46,47],thin:24,thing:[0,4,11,12,13,14,19,21,22,29,32,36,38,41],think:[4,11,13,17,24,36,42],third:[11,20,23,32,35,44],thisstateref:12,thorough:13,those:[0,3,5,11,12,13,20,26,29,35,36,42,44],though:[13,23,26,29,42],thought:[11,15],thousand:46,threadsaf:4,three:[2,10,13,23,27,35,38,42,43,45],threshold:[18,26,28,32,38],through:[2,3,7,9,11,12,13,16,24,25,26,28,29,32,39,40,42,43,44,46],throughput:[5,11],thrown:[3,13,36,42],thu:[2,4,5,8,11,12,26,28,29,32,38,40,42,43],tick:44,ticket:13,tidi:14,tighten:42,tightli:13,time:[0,4,5,6,7,10,11,12,13,14,16,17,18,19,20,25,26,28,29,30,31,32,35,38,39,40],timelin:42,timem:42,timeout:3,timestamp:4,titl:17,tls1:28,tls:[24,32],toblock:45,todo:[4,13,29,42],togeth:[2,6,9,11,16,23,32,35,42,43,44],tohostandport:45,toinstant:44,token:[2,9,13,38,40,43],tokeypair:29,told:4,toledgertransact:[38,40],toler:[5,12],tolist:40,too:[4,13,16,32,40,42],took:[13,43],tool:[0,13,15,16,18,22,24,25,26,27,31,32,35,44],toolbar:17,top:[2,4,9,11,13,17,22,24,27,32,35,41,43,44],topic:[24,42],topicsess:[24,32],toplevel:46,topriv:13,torn:32,toset:40,tosignedtransact:[13,14,38,39,40,42,47],tostateandref:40,tostr:[4,13,31,42],total:[0,11,22,38,40],totypedarrai:40,toward:[32,33],towiretransact:[23,29,38],trace:[13,26,43],track:[11,12],tracker:[13,32],trade:[5,7],tradeapprovalcontract:40,tradeoff:4,trader:[19,32],traderequest:13,tradit:11,traffic:[8,11,25],transac:18,transact:[2,5,6,9,11,12,13,14,18,19,20],transactionbuild:[13,29,32,38,39,40,42,47],transactionforcontract:[2,42,43],transactionforverif:42,transactionst:[5,23,32,38],transactionstorag:28,transactiontyp:[13,32,39,40,47],transactionverificationexcept:46,transfer:[36,40,42,46,47],transferedfundsoutput:40,transit:[28,36,38,40,42],translat:28,transmit:[19,32],transport:[0,8,10,44],travel:42,treat:[10,32,36,42],tree:[13,17,18,19],tri:[0,11,16,32,42],tricki:[11,13],trigger:[2,6,12,13,22,28,29,35,43],trivial:[4,11,39],troubl:17,trust:[6,8,11,28,30,36,40],trustpass:[8,37,41],truststor:[8,28,37,44],truststorepassword:[8,37,41],truth:13,tunnel:37,tupl:4,ture:11,turn:[2,11,13,38,42,43,46],tutori:[0,3,6,13,15,16,19,21,25,32,37,39],tweak:[22,32,46],twice:46,two:[2,4,5,6,7,10,11,12],twopartydealflow:12,twopartytradeflow:13,txb:38,txhash:[11,13,40,41,42,47],txid:40,txnid:41,txnnote:41,txstate:29,txt:[26,44],typenam:13,typeonlycommanddata:[42,43],typesaf:8,typetobui:13,typic:[0,9,11,12,13,24,26,28,29,31,36,38,39,40,42],ugli:13,ultim:[28,40],ultimat:26,unaccept:13,unacceptablepriceexcept:13,unavoid:13,unchang:32,unclutt:13,unconfirm:40,unconsum:[28,31],undelet:[16,17],under:[1,10,20,22,28,32,33,35,38,41,42,43,46],undergo:32,underli:[6,7,11,13,32,38],underscor:4,understand:[0,11,25,26,29,40,42,43,44],unencrypt:8,unexpect:[13,36,44],unfinish:13,unfortun:[13,36,42],unicredit:32,unifi:32,uniform:12,unilater:40,unindex:17,union:40,uniqu:[5,11,13,28,29,32,38,39],uniqueidentifi:[19,32],uniquenessprovid:28,unit:[0,2,5,11,13,14,17,22,24,28,29,32,38,40,42,44,46],univers:32,unknow:5,unknown:[38,40],unknownfix:29,unless:[4,13,29,33,42,44],unlik:[28,42],unlike:[6,9],unlink:17,unlock:8,unmerg:44,unnatur:11,unpack:[10,28,42],unprocess:[2,43],unqiu:12,unread:13,unrecognis:42,unrel:[42,43,44],unschedul:12,unserialis:13,unset:7,unspecifi:45,unspent:[11,18],unstarted:13,unsubscrib:3,unsubscript:3,unsupportedoperationexcept:[3,42],until:[3,5,7,11,12,13,14,28,29,32,33,35,37,44,46],untrust:13,untrustworthydata:[13,32,36],unverifiedtransact:46,unwrap:[13,29,32,40],upcom:[12,32],updat:[3,9,10,11,13,17,22,24,28,32,33,39,40,41,42,44,45],update:[16,41,45],upgrad:[13,17,31,32,42],upgrade:32,uphold:42,upload:19,uploadrat:35,upon:[7,10,13,18,28,40,42,44],upward:33,urandom:22,url:[8,10,26,30,32,35,37,44],usabl:[32,33,42],usag:[0,4,13,19],usage:[2,41],usd:[22,27,41],use:[4,6,11,44],usehttps:[8,37],useless:42,user1:[8,27,37,44],user:[1,3,4,8,10,11,13,19,21,22,27,29,32,35,37,41,44,45],usernam:[3,8,26,27,41],using:2,usr:1,usuabl:0,usual:[4,10,11,35,40,42,43,44],usualli:[2,33,43,44],utc:12,util:[5,8,10,14,16,19,26,28],utilis:[25,41],utiliti:30,uuid:[32,38],vagu:4,val:[2,4,5,12,13,14,22,23,29,31,38,39,40,41,42,43,44,45,46,47],valid:3,validatedtransact:[14,39,40],validfrom:42,valu:[4,5,6,7,8,9,11,13,20,23,27,28,29,32,34,35,40,42,43,44,46],valuabl:29,valuat:[7,20,32,35],valueof:41,vanilla:[6,7],vararg:41,vari:19,variabl:[4,7,10,11,13,42],variant:[28,42],variou:[4,9,11,13,20,26,28,32,35,36,42,44],vault:[9,13,19,22,27],vaultandupdat:[41,45],vaultservic:[9,13,28,40],vaultsselfissu:22,vcs:16,vega:32,vehicl:11,vendor:[21,26],verbos:42,verdict:40,veri:[4,6,11,13,16,18,20,28,29,35,36,42,46],verif:[0,2,6,11,18,21,23,28,29,32],verifi:[2,5,11,13,14,18,19,23,28,29,32,38,39,40],verifiedtransact:41,verifyclaus:[2,43],verifying:13,verifylifecycl:2,verifypropos:32,verifysignatur:[13,40],versa:[6,7,11,13,38],versionnumb:44,versu:13,vertic:4,vet:36,vice:[6,7,11,13,38],view:[4,7],virtual:[9,11,18,36],visibl:[5,11,19,23,27,28,35],vision:[19,44],visual:[27,32],visualis:[24,25,41,44],vital:13,vpn:37,wai:[2,3,4,5,10,11,12,13,17,18,20,22,23,24,26,27,29,31,32,35,37,40,42,44,46],wait:[12,13,14,17,22,28,29,32,35,44,45],waitforallnodestofinish:[41,44],wake:32,wallet:[11,12,13,18,32,42],want:[0,2,3,4,11,13,17,22,23,26,29,32,35,36,38,42,43,44,45,46,47],warn:3,watch:36,weak:[29,38],wear:33,web:[8,9,10,20,21,26,28,29,32,35,44],webaddress:[8,37],webapi:9,webapp:32,webport:[10,44],webserv:37,websit:[16,17],week:15,weekend:7,weight:38,well:[0,1,4,5,7,9,11,12,13,16,18,21,23,26,28,31,32,39,40,41,42,43,44],went:4,were:[2,4,11,13,20,28,29,35,40,42],what:[4,5,6,7,11,12,13,14,17,19,20],whatev:[4,13,25,28,29,38,40],when:[0,2,3,4,5,6,7,8,9,10,11,12,13,14,16,17,20,22,24,25,26,27,28,29,30,31,32,35,36,38,39,40,41,42,43,44,46],whenev:[4,16],where:[3,4,5,10,11,13,16,17,18,19,22,23,25,26,27,28,29,31,32,33,35,38,39,40],wherea:[7,17],wherev:26,whether:[2,3,5,6,13,22,28,29,37,38,42,43],which:[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,16,17,18,20,21,22,23,24,25,26,28,29,31,32,33,35,37,38,39,40,41,42,43,44,45,46,47],whilst:[11,13,25,28,29,32,36,42],white:[9,19,32,44],whitelist:[6,9,10,12,13,41],who:[4,8,11,13,15,20,29,32,35,38,42,44],whole:[23,28,34,43,46],whom:[6,11],whose:[6,26,38],why:[4,11,15,19],wide:[3,4,23],widescreen:4,widespread:4,widget:[27,44],widnow:44,width:4,wiki:[11,42,43],wikipedia:[42,43],wipe:17,wiretransact:[13,19,23,38],wish:[10,11,13,19,20,29,31,32,35,38,40,42,44],wit:37,withattach:14,within:[1,4,5,8,9,11,14,15,16],withitem:[38,40,42],withkei:[13,40],withnewown:[13,42],without:[0,4,13],withoutissu:[13,42],withoutown:[42,43],withowner:42,won:[13,24,27,29,32,41,42,44,45,46],word:[4,5,8],work:[0,3,4,5,7,8,10,11,12,13,16,19,21,22,25,26,28,29,30,32,34,35,38,39,41,42],worker:4,workflow:[9,40],workflowtransactionbuildtutori:40,workflowtransactionbuildtutorialtest:40,working:29,workspac:[8,9,10,28,30,40],world:[8,11,13,20,25,27,29,35,37,40,42,46],worn:42,worri:[4,13,42,44],worst:11,worth:[4,36,42,43,44],worthless:29,would:[0,3,4,6,7,9,10,11,13,16,18,20,21,25,26,29,35,36,38,39,40,42,43,44,45,47],wouldn:29,wow:44,wrap:[2,4,13,24,26,28,32,36,38,42,43],wrapper:[0,4,5,13,41,44],write:[0,2,4,9],written:[1,2,3,7,11,15,16,29,32,40,42,45],wrong:[3,4,13,46],wrote:11,wtx:[13,23,29,40],www:1,xcode:16,xml:26,xsrf:44,xss:44,xterm:10,year:[7,13],yet:[4,7,11,13,18,21,25,27,30,32,38,40,45],yield:11,york:10,you:[0,1,2,3,4,10,11,12,13,14,15,16,17,19,20,21,22,23,24,25,26,27,29,30,31,32,34,35,36,37,38,41,42,43,44,45,46],your:[3,4,9],yourself:[11,12,36,38,44],zero:[2,11,18,29,42,44],zip:[11,26,35,39],zone:12,zoneddatetim:12},titles:["CLI vs IDE","Building the documentation","Clauses key concepts","Client RPC","Code style guide","Consensus model","Contract catalogue","Interest rate swaps","Node configuration","The Corda plugin framework","CorDapps Background","Data model","Event scheduling","Writing flows","Writing flow tests","Further notes on Kotlin","Getting set up","Getting set up: troubleshooting","Glossary","Welcome to the Corda documentation!","Initial margin agreements","What’s included?","Load testing","Transaction tear-offs","Networking and messaging","Network Simulator","Node administration","Node Explorer","Brief introduction to the node services","Writing oracle services","Network permissioning","Persistence","Release notes","Release process","Running a notary service","Running the demos","Secure coding guidelines","Introduction - What is a corda network?","Data types","Using attachments","Building Transactions","Client RPC API tutorial","Writing a contract","Writing a contract using clauses","The CorDapp Template","Integration Test Tutorial","Writing a contract test","Using a notary service"],titleterms:{"class":[3,29,41,42,43],"function":[13,42],about:17,abstractconserveamount:2,abstractissu:2,access:26,adding:42,administr:26,adopt:11,against:10,agreement:[20,35],aka:35,all:35,allcomposit:2,amount:38,anycomposit:2,api:[41,42],app:[10,20],approach:29,artemismessagingserv:28,assert:29,assertion:4,asset:42,assign:47,attach:[26,39],attachment:[35,39],background:[10,35,44],basic:[2,29,40],bind:29,bitcoin:11,brief:28,build:[1,10,30,40,44],buyer:13,cash:[6,38],catalogu:6,certif:[30,37],chain:46,chang:5,check:42,claus:[2,42,43],cli:[0,17],client:[3,29,41],cluster:22,code:[4,16,36,42],command:[0,40,42,44],comment:4,commerci:[6,42,43],commit:40,commod:6,common:35,comparison:11,compil:4,complain:17,complet:40,composit:[2,38],con:11,concept:2,configur:[8,17,22,37,44],connect:37,consensu:5,construct:42,continu:29,contract:[6,36,42,43,46],control:16,corda:[9,10,16,19,23,37],cordapp:[10,29,41,44],cordform:10,core:29,creat:7,cryptographi:38,cut:33,data:[11,23,29,38],databas:26,date:38,dbcheckpointstorag:28,dbtransactionmappingstorag:28,dbtransactionstorag:28,debug:[0,10,43,44],demo:[27,35,39],deploi:44,detail:7,distribut:35,document:[1,19],download:26,e2etestkeymanagementservic:28,encumbranc:42,error:[3,4],ethereum:11,event:[12,28],exampl:[8,12,23,44],execut:35,explorer:27,featur:13,field:8,file:[8,44],filteron:2,firstcomposit:2,fix:26,flow:[13,14,28,29,36],format:8,framework:[9,28],frequent:0,from:[29,41,44],fungibleasset:38,further:15,futur:13,gather:40,gener:[4,40,42],get:[16,17,44],git:16,glossari:18,gradl:[0,10,16,17,44],group:[42,43],groupclauseverifi:2,guid:4,guidelin:36,handl:3,happen:[35,42],hibernateobserv:28,hide:[23,29],how:[12,22,42,43],ide:0,ident:28,implement:[12,13,28,29],important:35,includ:21,individu:22,initial:[20,35],inmemoryidentityservic:28,inmemorynetworkmapcach:28,inmemorystatemachinerecordedtransactionmappingstorag:28,inmemoryuniquenessprovid:28,input:40,install:10,installat:17,instanc:7,instruction:35,integrat:45,intellij:[0,16,17,44],interest:[6,7,26],interfac:[25,27,44],introduct:[12,13,20,28,29,35,37,40],irs:35,issu:17,jvm:16,kei:[2,28,38],kotlin:[15,16,17],kryo:[3,41],lack:17,length:4,lifecycl:[7,38,40],line:[0,4,44],load:22,local:44,locat:8,log:[26,37],mac:0,machin:44,make:42,manag:28,map:[24,31],margin:[20,35],math:38,merkl:23,messag:[24,28],mileston:[32,44],miss:17,model:[5,11],monitor:26,multi:[38,42],multipl:5,name:4,namedbyhash:38,network:[24,25,28,29,30,37],networkmapservic:28,node:[8,10,26,27,28,37,44],nodeattachmentservic:28,nodemessagingcli:28,nodeschedulerservic:28,nodeschemaservic:28,nodevaultservic:28,non:42,notari:[5,28,34,35,47],notaris:47,notaryservic:28,note:[15,32],notion:35,nozerosizedoutput:2,object:31,obligat:6,observabl:3,off:23,opene:44,oracl:29,orient:42,other:2,output:40,overview:11,own:37,pai:29,paper:[6,42,43],parti:[13,38,42],partial:40,particular:42,per:29,permiss:30,persist:[10,28,31],persistentkeymanagementservic:28,persistentnetworkmapservic:28,persistentuniquenessprovid:28,plai:29,plugin:[9,10,29],portfolio:35,pro:11,process:[20,33],progress:13,project:44,properti:4,protocol:3,provid:[29,44],publickei:38,put:42,queri:29,raftuniquenessprovid:28,raftvalidatingnotaryservic:28,rate:[6,7,26],rational:11,regist:[3,41],relat:[28,31],releas:[32,33,44],request:30,requir:[1,42],rpc:[3,41],run:[17,20,22,27,30,34,35,44],safeti:3,sampl:44,schedul:[12,28],schema:31,sdk:17,secur:[3,36,41],seller:13,separ:44,servic:[10,24,28,29,34,44,47],set:[16,17,37],sign:[29,30],signatur:38,signedtransact:40,simm:[20,35],simpl:43,simplenotaryservic:28,simul:25,singl:46,smart:42,snapshot:44,sourc:16,space:4,start:[10,13,37,42,44],state:[10,38,42],statemachinemanag:28,step:[20,33,35],storag:28,storageserviceimpl:28,structur:[2,44],style:[4,11],sub:[13,29],summari:43,support:38,suspend:13,swap:[6,7],task:0,tear:23,technic:7,templat:[10,44],test:[14,22,42,45,46],them:43,theori:13,thing:42,thread:[3,4],time:42,timestamp:5,track:13,trade:13,tradeoff:11,trader:35,transact:[23,29,38,40,42,46,47],transmit:42,tree:23,troubleshoot:[16,17],tutori:[41,45],two:[13,29],type:[2,24,38],uniqueidentifi:38,unix:0,upload:26,usag:23,used:0,using:[10,29,39,42,44,47],util:30,utxo:11,valid:5,validatingnotaryservic:28,vari:29,vault:28,verif:38,verifi:42,version:[3,13,16],via:[0,16,17,29,44],view:10,visibl:40,warn:4,welcom:19,what:[21,25,35,37,43],where:42,why:43,window:0,wire:3,wiretransact:40,within:[17,28],without:17,work:[43,44],write:[13,14,22,29,42,43,46],your:[10,13,26,37,41,42,44]}})
\ No newline at end of file
diff --git a/docs/build/html/secure-coding-guidelines.html b/docs/build/html/secure-coding-guidelines.html
index a6d9b8f3f5..d000b243b2 100644
--- a/docs/build/html/secure-coding-guidelines.html
+++ b/docs/build/html/secure-coding-guidelines.html
@@ -32,7 +32,7 @@
-
+
@@ -89,14 +89,26 @@
Corda supports scenarios where more than one key or party is required to authorise a state object transition, for example:
“Either the CEO or 3 out of 5 of his assistants need to provide signatures”.
This is achieved by public key composition, using a tree data structure CompositeKey. A CompositeKey is a tree that
stores the cryptographic public key primitives in its leaves and the composition logic in the intermediary nodes. Every intermediary
node specifies a threshold of how many child signatures it requires.
@@ -400,7 +415,7 @@ splines. These can be found in the
- Next
+ Next Previous
@@ -412,7 +427,7 @@ splines. These can be found in the
Understanding and implementing transactions in Corda is key to building
+and implementing real world smart contracts. It is only through
+construction of valid Corda transactions containing appropriate data
+that nodes on the ledger can map real world business objects into a
+shared digital view of the data in the Corda ledger. More importantly as
+the developer of new smart contracts it is the code which determines
+what data is well formed and what data should be rejected as mistakes,
+or to prevent malicious activity. This document details some of the
+considerations and APIs used to when constructing transactions as part
+of a flow.
Transactions in Corda are constructed in stages and contain a number of
+elements. In particular a transaction’s core data structure is the
+net.corda.core.transactions.WireTransaction, which is usually
+manipulated via a
+net.corda.core.contracts.General.TransactionBuilder and contains:
+
1. A set of Input state references that will be consumed by the final
+accepted transaction.
+
2. A set of Output states to create/replace the consumed states and thus
+become the new latest versions of data on the ledger.
+
3. A set of Attachment items which can contain legal documents, contract
+code, or private encrypted sections as an extension beyond the native
+contract states.
+
4. A set of Command items which give a context to the type of ledger
+transition that is encoded in the transaction. Also each command has an
+associated set of signer keys, which will be required to sign the
+transaction.
+
5. A signers list, which is populated by the TransactionBuilder to
+be the union of the signers on the individual Command objects.
+
6. A notary identity to specify the Notary node which is tracking the
+state consumption. (If the input states are registered with different
+notary nodes the flow will have to insert additional NotaryChange
+transactions to migrate the states across to a consistent notary node,
+before being allowed to mutate any states.)
+
7. Optionally a timestamp that can used in the Notary to time bound the
+period in which the proposed transaction stays valid.
+
Typically, the WireTransaction should be regarded as a proposal and
+may need to be exchanged back and forth between parties before it can be
+fully populated. This is an immediate consequence of the Corda privacy
+model, which means that the input states are likely to be unknown to the
+other node.
+
Once the proposed data is fully populated the flow code should freeze
+the WireTransaction and form a SignedTransaction. This is key to
+the ledger agreement process, as once a flow has attached a node’s
+signature it has stated that all details of the transaction are
+acceptable to it. A flow should take care not to attach signatures to
+intermediate data, which might be maliciously used to construct a
+different SignedTransaction. For instance in a foreign exchange
+scenario we shouldn’t send a SignedTransaction with only our sell
+side populated as that could be used to take the money without the
+expected return of the other currency. Also, it is best practice for
+flows to receive back the DigitalSignature.WithKey of other parties
+rather than a full SignedTransaction objects, because otherwise we
+have to separately check that this is still the same
+SignedTransaction and not a malicious substitute.
+
The final stage of committing the transaction to the ledger is to
+notarise the SignedTransaction, distribute this to all appropriate
+parties and record the data into the ledger. These actions are best
+delegated to the FinalityFlow, rather than calling the inidividual
+steps manually. However, do note that the final broadcast to the other
+nodes is asynchronous, so care must be used in unit testing to
+correctly await the Vault updates.
One of the first steps to forming a transaction is gathering the set of
+input references. This process will clearly vary according to the nature
+of the business process being captured by the smart contract and the
+parameterised details of the request. However, it will generally involve
+searching the Vault via the VaultService interface on the
+ServiceHub to locate the input states.
+
To give a few more specific details consider two simplified real world
+scenarios. First, a basic foreign exchange Cash transaction. This
+transaction needs to locate a set of funds to exchange. A flow
+modelling this is implemented in FxTransactionBuildTutorial.kt.
+Second, a simple business model in which parties manually accept, or
+reject each other’s trade proposals which is implemented in
+WorkflowTransactionBuildTutorial.kt. To run and explore these
+examples using the IntelliJ IDE one can run/step the respective unit
+tests in FxTransactionBuildTutorialTest.kt and
+WorkflowTransactionBuildTutorialTest.kt, which drive the flows as
+part of a simulated in-memory network of nodes. When creating the
+IntelliJ run configuration for these unit test set the workspace
+points to the root r3prototyping folder and add
+-javaagent:lib/quasar.jar to the VM options, so that the Quasar
+instrumentation is correctly configured.
+
For the Cash transaction let’s assume the cash resources are using the
+standard CashState in the :financial Gradle module. The Cash
+contract uses FungibleAsset states to model holdings of
+interchangeable assets and allow the split/merge and summing of
+states to meet a contractual obligation. We would normally use the
+generateSpend method on the VaultService to gather the required
+amount of cash into a TransactionBuilder, set the outputs and move
+command. However, to elucidate more clearly example flow code is shown
+here that will manually carry out the inputs queries using the lower
+level VaultService.
+
// This is equivalent to the VaultService.generateSpend
+// Which is brought here to make the filtering logic more visible in the example
+privatefungatherOurInputs(serviceHub:ServiceHub,
+ amountRequired:Amount<Issued<Currency>>,
+ notary:Party?):Pair<List<StateAndRef<Cash.State>>,Long>{
+ // Collect cash type inputs
+ valcashStates=serviceHub.vaultService.currentVault.statesOfType<Cash.State>()
+ // extract our key identity for convenience
+ valourKey=serviceHub.myInfo.legalIdentity.owningKey
+ // Filter down to our own cash states with right currency and issuer
+ valsuitableCashStates=cashStates.filter{
+ valstate=it.state.data
+ (state.owner==ourKey)
+ &&(state.amount.token==amountRequired.token)
+ }
+ require(!suitableCashStates.isEmpty()){"Insufficient funds"}
+ varremaining=amountRequired.quantity
+ // We will need all of the inputs to be on the same notary.
+ // For simplicity we just filter on the first notary encountered
+ // A production quality flow would need to migrate notary if the
+ // the amounts were not sufficient in any one notary
+ valsourceNotary:Party=notary?:suitableCashStates.first().state.notary
+
+ valinputsList=mutableListOf<StateAndRef<Cash.State>>()
+ // Iterate over filtered cash states to gather enough to pay
+ for(cashinsuitableCashStates.filter{it.state.notary==sourceNotary}){
+ inputsList+=cash
+ if(remaining<=cash.state.data.amount.quantity){
+ returnPair(inputsList,cash.state.data.amount.quantity-remaining)
+ }
+ remaining-=cash.state.data.amount.quantity
+ }
+ throwIllegalStateException("Insufficient funds")
+}
+
+
+
As a foreign exchange transaction we expect an exchange of two
+currencies, so we will also require a set of input states from the other
+counterparty. However, the Corda privacy model means we do not know the
+other node’s states. Our flow must therefore negotiate with the other
+node for them to carry out a similar query and populate the inputs (See
+the ForeignExchangeFlow for more details of the exchange). Having
+identified a set of Input StateRef items we can then create the
+output as discussed below.
+
For the trade approval flow we need to implement a simple workflow
+pattern. We start by recording the unconfirmed trade details in a state
+object implementing the LinearState interface. One field of this
+record is used to map the business workflow to an enumerated state.
+Initially the initiator creates a new state object which receives a new
+UniqueIdentifier in its linearId property and a starting
+workflow state of NEW. The Contract.verify method is written to
+allow the initiator to sign this initial transaction and send it to the
+other party. This pattern ensures that a permanent copy is recorded on
+both ledgers for audit purposes, but the state is prevented from being
+maliciously put in an approved state. The subsequent workflow steps then
+follow with transactions that consume the state as inputs on one side
+and output a new version with whatever state updates, or amendments
+match to the business process, the linearId being preserved across
+the changes. Attached Command objects help the verify method
+restrict changes to appropriate fields and signers at each step in the
+workflow. In this it is typical to have both parties sign the change
+transactions, but it can be valid to allow unilateral signing, if for instance
+one side could block a rejection. Commonly the manual initiator of these
+workflows will query the Vault for states of the right contract type and
+in the right workflow state over the RPC interface. The RPC will then
+initiate the relevant flow using StateRef, or linearId values as
+parameters to the flow to identify the states being operated upon. Thus
+code to gather the latest input state would be:
+
// Helper method to access the StorageService and expand a StateRef into a StateAndRef
+fun <T : ContractState> ServiceHub.toStateAndRef(ref: StateRef): StateAndRef<T> {
+ return storageService.validatedTransactions.getTransaction(ref.txhash)!!.tx.outRef<T>(ref.index)
+}
+
+// Helper method to locate the latest Vault version of a LinearState from a possibly out of date StateRef
+inline fun <reified T : LinearState> ServiceHub.latest(ref: StateRef): StateAndRef<T> {
+ val linearHeads = vaultService.linearHeadsOfType<T>()
+ val original = toStateAndRef<T>(ref)
+ return linearHeads.get(original.state.data.linearId)!!
+}
+
+
+
+
// Pull in the latest Vault version of the StateRef as a full StateAndRef
+vallatestRecord=serviceHub.latest<TradeApprovalContract.State>(ref)
+
For the commands that will be added to the transaction, these will need
+to correctly reflect the task at hand. These must match because inside
+the Contract.verify method the command will be used to select the
+validation code path. The Contract.verify method will then restrict
+the allowed contents of the transaction to reflect this context. Typical
+restrictions might include that the input cash amount must equal the
+output cash amount, or that a workflow step is only allowed to change
+the status field. Sometimes, the command may capture some data too e.g.
+the foreign exchange rate, or the identity of one party, or the StateRef
+of the specific input that originates the command in a bulk operation.
+This data will be used to further aid the Contract.verify, because
+to ensure consistent, secure and reproducible behaviour in a distributed
+environment the Contract.verify, transaction is the only allowed to
+use the content of the transaction to decide validity.
+
Another essential requirement for commands is that the correct set of
+CompositeKeys are added to the Command on the builder, which will be
+used to form the set of required signers on the final validated
+transaction. These must correctly align with the expectations of the
+Contract.verify method, which should be written to defensively check
+this. In particular, it is expected that at minimum the owner of an
+asset would have to be signing to permission transfer of that asset. In
+addition, other signatories will often be required e.g. an Oracle
+identity for an Oracle command, or both parties when there is an
+exchange of assets.
Having located a set of StateAndRefs as the transaction inputs, the
+flow has to generate the output states. Typically, this is a simple call
+to the Kotlin copy method to modify the few fields that will
+transitioned in the transaction. The contract code may provide a
+generateXXX method to help with this process if the task is more
+complicated. With a workflow state a slightly modified copy state is
+usually sufficient, especially as it is expected that we wish to preserve
+the linearId between state revisions, so that Vault queries can find
+the latest revision.
+
For fungible contract states such as Cash it is common to distribute
+and split the total amount e.g. to produce a remaining balance output
+state for the original owner when breaking up a large amount input
+state. Remember that the result of a successful transaction is always to
+fully consume/spend the input states, so this is required to conserve
+the total cash. For example from the demo code:
+
// Gather our inputs. We would normally use VaultService.generateSpend
+ // to carry out the build in a single step. To be more explicit
+ // we will use query manually in the helper function below.
+ // Putting this into a non-suspendable function also prevents issues when
+ // the flow is suspended.
+ val (inputs, residual) = gatherOurInputs(serviceHub, sellAmount, request.notary)
+
+ // Build and an output state for the counterparty
+ val transferedFundsOutput = Cash.State(sellAmount, request.counterparty.owningKey, null)
+
+ if (residual > 0L) {
+ // Build an output state for the residual change back to us
+ val residualAmount = Amount(residual, sellAmount.token)
+ val residualOutput = Cash.State(residualAmount, serviceHub.myInfo.legalIdentity.owningKey, null)
+ return FxResponse(inputs, listOf(transferedFundsOutput, residualOutput))
+ } else {
+ return FxResponse(inputs, listOf(transferedFundsOutput))
+ }
+
Having gathered all the ingredients for the transaction we now need to
+use a TransactionBuilder to construct the full WireTransaction.
+The initial TransactionBuilder should be created by calling the
+TransactionType.General.Builder method. (The other
+TransactionBuilder implementation is only used for the NotaryChange flow where
+ContractStates need moving to a different Notary.) At this point the
+Notary to associate with the states should be recorded. Then we keep
+adding inputs, outputs, commands and attachments to fill the
+transaction. Examples of this process are:
+
// Modify the state field for new output. We use copy, to ensure no other modifications.
+ // It is especially important for a LinearState that the linearId is copied across,
+ // not accidentally assigned a new random id.
+ valnewState=latestRecord.state.data.copy(state=verdict)
+
+ // We have to use the original notary for the new transaction
+ valnotary=latestRecord.state.notary
+
+ // Get and populate the new TransactionBuilder
+ // To destroy the old proposal state and replace with the new completion state.
+ // Also add the Completed command with keys of all parties to signal the Tx purpose
+ // to the Contract verify method.
+ valtx=TransactionType.
+ General.
+ Builder(notary).
+ withItems(
+ latestRecord,
+ newState,
+ Command(TradeApprovalContract.Commands.Completed(),
+ listOf(serviceHub.myInfo.legalIdentity.owningKey,latestRecord.state.data.source.owningKey)))
+ tx.setTime(serviceHub.clock.instant(),Duration.ofSeconds(60))
+ // We can sign this transaction immediately as we have already checked all the fields and the decision
+ // is ultimately a manual one from the caller.
+ tx.signWith(serviceHub.legalIdentityKey)
+ // Convert to SignedTransaction we can pass around certain that it cannot be modified.
+ valselfSignedTx=tx.toSignedTransaction(false)
+
+
+
privatefunbuildTradeProposal(ourStates:FxResponse,theirStates:FxResponse):SignedTransaction{
+ // This is the correct way to create a TransactionBuilder,
+ // do not construct directly.
+ // We also set the notary to match the input notary
+ valbuilder=TransactionType.General.Builder(ourStates.inputs.first().state.notary)
+
+ // Add the move commands and key to indicate all the respective owners and need to sign
+ valourSigners=ourStates.inputs.map{it.state.data.owner}.toSet()
+ valtheirSigners=theirStates.inputs.map{it.state.data.owner}.toSet()
+ builder.addCommand(Cash.Commands.Move(),(ourSigners+theirSigners).toList())
+
+ // Build and add the inputs and outputs
+ builder.withItems(*ourStates.inputs.toTypedArray())
+ builder.withItems(*theirStates.inputs.toTypedArray())
+ builder.withItems(*ourStates.outputs.toTypedArray())
+ builder.withItems(*theirStates.outputs.toTypedArray())
+
+ // We have already validated their response and trust our own data
+ // so we can sign
+ builder.signWith(serviceHub.legalIdentityKey)
+ // create a signed transaction, but pass false as parameter, because we know it is not fully signed
+ valsignedTransaction=builder.toSignedTransaction(checkSufficientSignatures=false)
+ returnsignedTransaction
+ }
+
Having created an initial WireTransaction and converted this to an
+initial SignedTransaction the process of verifying and forming a
+full SignedTransaction begins and then completes with the
+notarisation. In practice this is a relatively stereotypical process,
+because assuming the WireTransaction is correctly constructed the
+verification should be immediate. However, it is also important to
+recheck the business details of any data received back from an external
+node, because a malicious party could always modify the contents before
+returning the transaction. Each remote flow should therefore check as
+much as possible of the initial SignedTransaction inside the unwrap of
+the receive before agreeing to sign. Any issues should immediately throw
+an exception to abort the flow. Similarly the originator, should always
+apply any new signatures to its original proposal to ensure the contents
+of the transaction has not been altered by the remote parties.
+
The typical code therefore checks the received SignedTransaction
+using the verifySignatures method, but excluding itself, the notary
+and any other parties yet to apply their signature. The contents of the
+WireTransaction inside the SignedTransaction should be fully
+verified further by expanding with toLedgerTransaction and calling
+verify. Further context specific and business checks should then be
+made, because the Contract.verify is not allowed to access external
+context. For example the flow may need to check that the parties are the
+right ones, or that the Command present on the transaction is as
+expected for this specific flow. An example of this from the demo code is:
+
// First we receive the verdict transaction signed by their single key
+ valcompleteTx=receive<SignedTransaction>(source).unwrap{
+ // Check the transaction is signed apart from our own key and the notary
+ valwtx=it.verifySignatures(serviceHub.myInfo.legalIdentity.owningKey,it.tx.notary!!.owningKey)
+ // Check the transaction data is correctly formed
+ wtx.toLedgerTransaction(serviceHub).verify()
+ // Confirm that this is the expected type of transaction
+ require(wtx.commands.single().valueisTradeApprovalContract.Commands.Completed){
+ "Transaction must represent a workflow completion"
+ }
+ // Check the context dependent parts of the transaction as the
+ // Contract verify method must not use serviceHub queries.
+ valstate=wtx.outRef<TradeApprovalContract.State>(0)
+ require(state.state.data.source==serviceHub.myInfo.legalIdentity){
+ "Proposal not one of our original proposals"
+ }
+ require(state.state.data.counterparty==source){
+ "Proposal not for sent from correct source"
+ }
+ it
+ }
+
+
+
After verification the remote flow will return its signature to the
+originator. The originator should apply that signature to the starting
+SignedTransaction and recheck the signatures match.
Once all the party signatures are applied to the SignedTransaction the
+final step is notarisation. This involves calling NotaryFlow.Client
+to confirm the transaction, consume the inputs and return its confirming
+signature. Then the flow should ensure that all nodes end with all
+signatures and that they call ServiceHub.recordTransactions. The
+code for this is standardised in the FinalityFlow, or more explictly
+an example is:
+
// Run the FinalityFlow to notarise and distribute the completed transaction.
+ subFlow(FinalityFlow(allPartySignedTx,
+ setOf(latestRecord.state.data.source,latestRecord.state.data.counterparty)))
+
The discussion so far has assumed that the parties need full visibility
+of the transaction to sign. However, there may be situations where each
+party needs to store private data for audit purposes, or for evidence to
+a regulator, but does not wish to share that with the other trading
+partner. The tear-off/Merkle tree support in Corda allows flows to send
+portions of the full transaction to restrict visibility to remote
+parties. To do this one can use the
+WireTransaction.buildFilteredTransaction extension method to produce
+a FilteredTransaction. The elements of the SignedTransaction
+which we wish to be hide will be replaced with their secure hash. The
+overall transaction txid is still provable from the
+FilteredTransaction preventing change of the private data, but we do
+not expose that data to the other node directly. A full example of this
+can be found in the NodeInterestRates Oracle code from the
+irs-demo project which interacts with the RatesFixFlow flow.
+Also, refer to the Transaction tear-offs documentation.
@@ -298,9 +311,14 @@ fun main(args: Array<String>) {
fun getVaultTransactionNotes(txnId: SecureHash): Iterable<String>
+
+
Warning
+
This API is evolving and will continue to grow as new functionality and features added to Corda are made available to RPC clients.
+
The one we need in order to dump the transaction graph is verifiedTransactions. The type signature tells us that the
RPC will return a list of transactions and an Observable stream. This is a general pattern, we query some data and the
-node will return the current snapshot and future updates done to it.
+node will return the current snapshot and future updates done to it. Observables are described in further detail in
+Client RPC
val (transactions: List<SignedTransaction>, futureTransactions: Observable<SignedTransaction>) = proxy.verifiedTransactions()
@@ -351,9 +369,9 @@ latter.
Then in a loop we generate randomly either an Issue, a Pay or an Exit transaction.
The RPC we need to initiate a Cash transaction is startFlowDynamic which may start an arbitrary flow, given sufficient permissions to do so. We won’t use this function directly, but rather a type-safe wrapper around it startFlow that type-checks the arguments for us.
Finally we have everything in place: we start a couple of nodes, connect to them, and start creating transactions while listening on successfully created ones, which are dumped to the console. We just need to run it!:
-
# Build the example
+
# Build the example
./gradlew docs/source/example-code:installDist
-# Start it
+# Start it
./docs/source/example-code/build/install/docs/source/example-code/bin/client-rpc-tutorial Print
@@ -400,13 +418,56 @@ requests or responses with the Kryo instance RPC uses. Here’
}
We will be replacing the use of Kryo in RPC with a stable message format and this will mean that this plugin
customisation point will either go away completely or change.
RPC credentials associated with a Client must match the permission set configured on the server Node.
+This refers to both authentication (username and password) and role-based authorisation (a permissioned set of RPC operations an
+authenticated user is entitled to run).
+
+
Note
+
Permissions are represented as String’s to allow RPC implementations to add their own permissioning.
+Currently the only permission type defined is StartFlow, which defines a list of whitelisted flows an authenticated use may execute.
+
+
In the instructions above the server node permissions are configured programmatically in the driver code:
+
driver(driverDirectory = baseDirectory) {
+ val user = User("user", "password", permissions = setOf(startFlowPermission<CashFlow>()))
+ val node = startNode("Alice", rpcUsers = listOf(user)).get()
+
+
+
When starting a standalone node using a configuration file we must supply the RPC credentials as follows:
You can then deploy and launch the nodes (Notary and Alice) as follows:
+
# to create a set of configs and installs under ``docs/source/example-code/build/nodes`` run
+./gradlew docs/source/example-code:deployNodes
+# to open up two new terminals with the two nodes run
+./docs/source/example-code/build/nodes/runnodes
+# followed by the same commands as before:
+./docs/source/example-code/build/install/docs/source/example-code/bin/client-rpc-tutorial Print
+./docs/source/example-code/build/install/docs/source/example-code/bin/client-rpc-tutorial Visualise
+
@@ -416,10 +477,10 @@ customisation point will either go away completely or change.
@@ -428,7 +489,7 @@ customisation point will either go away completely or change.
This tutorial will take you through restructuring the commercial paper contract to use clauses. You should have
-already completed “Writing a contract”.
+already completed “Writing a contract”.
+As before, the example is focused on basic implementation of commercial paper, which is essentially a simpler version of a corporate
+bond. A company issues CP with a particular face value, say $100, but sells it for less, say $90. The paper can be redeemed
+for cash at a given date in the future. Thus this example would have a 10% interest rate with a single repayment.
+Whole Kotlin code can be found in CommercialPaper.kt.
+
Clauses are essentially micro-contracts which contain independent verification logic, and can be logically composed
-together to form a contract. Clauses are designed to enable re-use of common logic, for example issuing state objects
+together to form a contract. Clauses are designed to enable re-use of common verification parts, for example issuing state objects
is generally the same for all fungible contracts, so a common issuance clause can be inherited for each contract’s
issue clause. This cuts down on scope for error, and improves consistency of behaviour. By splitting verification logic
into smaller chunks, they can also be readily tested in isolation.
-
Clauses can be composed of subclauses, for example the AllClause or AnyClause clauses take list of clauses
-that they delegate to. Clauses can also change the scope of states and commands being verified, for example grouping
-together fungible state objects and running a clause against each distinct group.
-
The commercial paper contract has a Group outermost clause, which contains the Issue, Move and Redeem
-clauses. The result is a contract that looks something like this:
-
-
-
-
Group input and output states together, and then apply the following clauses on each group:
-
-
If an Issue command is present, run appropriate tests and end processing this group.
-
If a Move command is present, run appropriate tests and end processing this group.
-
If a Redeem command is present, run appropriate tests and end processing this group.
We have different types of clauses, the most basic are the ones that define verification logic for particular command set.
+We will see them later as elementary building blocks that commercial paper consist of - Move, Issue and Redeem.
+As a developer you need to identify reusable parts of your contract and decide how they should be combined. It is where
+composite clauses become useful. They gather many clause subcomponents and resolve how and which of them should be checked.
+
For example, assume that we want to verify a transaction using all constraints defined in separate clauses. We need to
+wrap classes that define them into AllComposition composite clause. It assures that all clauses from that combination
+match with commands in a transaction - only then verification logic can be executed.
+It may be a little confusing, but composite clause is also a clause and you can even wrap it in the special grouping clause.
+In CommercialPaper it looks like that:
+
+
The most basic types of composite clauses are AllComposition, AnyComposition and FirstComposition.
+In this tutorial we will use GroupClauseVerifier and AnyComposition. It’s important to understand how they work.
+Charts showing execution and more detailed information can be found in Clauses key concepts.
To use the clause verification logic, the contract needs to call the verifyClause function, passing in the
-transaction, a clause to verify, and a collection of commands the clauses are expected to handle all of. This list of
-commands is important because verifyClause checks that none of the commands are left unprocessed at the end, and
-raises an error if they are. The top level clause would normally be a composite clause (such as AnyComposition,
-AllComposition, etc.) which contains further clauses. The following examples are trimmed to the modified class
-definition and added elements, for brevity:
We start from defining CommercialPaper class. As in previous tutorial we need some elementary parts: Commands interface,
+generateMove, generateIssue, generateRedeem - so far so good that stays the same. The new part is verification and
+Clauses interface (you will see them later in code). Let’s start from the basic structure:
As you can see we used verifyClause function with Clauses.Group() in place of previous verification.
+It’s an entry point to running clause logic. verifyClause takes the transaction, a clause (usually a composite one)
+to verify, and a collection of commands the clause is expected to handle all of. This list of commands is important because
+verifyClause checks that none of the commands are left unprocessed at the end, and raises an error if they are.
We’ll tackle the inner clauses that contain the bulk of the verification logic, first, and the clause which handles
-grouping of input/output states later. The clauses must extend the Clause abstract class, which defines
-the verify function, and the requiredCommands property used to determine the conditions under which a clause
-is triggered. Composite clauses should extend the CompositeClause abstract class, which extends Clause to
-add support for wrapping around multiple clauses.
-
The verify function defined in the Clause interface is similar to the conventional Contract verification
-function, although it adds new parameters and returns the set of commands which it has processed. Normally this returned
-set is identical to the requiredCommands used to trigger the clause, however in some cases the clause may process
-further optional commands which it needs to report that it has handled.
-
The Move clause for the commercial paper contract is relatively simple, so we will start there:
Let’s move to constructing contract logic in terms of clauses language. Commercial paper contract has three commands and
+three corresponding behaviours: Issue, Move and Redeem. Each of them has a specific set of requirements that must be satisfied -
+perfect material for defining clauses. For brevity we will show only Move clause, rest is constructed in similar manner
+and included in the CommercialPaper.kt code.
interfaceClauses{
+ classMove:Clause<State,Commands,Issued<Terms>>(){
+ overridevalrequiredCommands:Set<Class<outCommandData>>
+ get()=setOf(Commands.Move::class.java)
- overridefunverify(tx:TransactionForContract,
+ overridefunverify(tx:TransactionForContract,inputs:List<State>,outputs:List<State>,commands:List<AuthenticatedObject<Commands>>,groupingKey:Issued<Terms>?):Set<Commands>{
- valcommand=commands.requireSingleCommand<Commands.Move>()
- valinput=inputs.single()
- requireThat{
- "the transaction is signed by the owner of the CP"by(input.ownerincommand.signers)
- "the state is propagated"by(outputs.size==1)
+ valcommand=commands.requireSingleCommand<Commands.Move>()
+ valinput=inputs.single()
+ requireThat{
+ "the transaction is signed by the owner of the CP"by(input.ownerincommand.signers)
+ "the state is propagated"by(outputs.size==1)
+ // Don't need to check anything else, as if outputs.size == 1 then the output is equal to
+ // the input ignoring the owner field due to the grouping.
+ }
+ returnsetOf(command.value)
+ }
+ }
+ ...
+
+
+
publicinterfaceClauses{
+ classMoveextendsClause<State,Commands,State>{
+ @NotNull
+ @Override
+ publicSet<Class<?extendsCommandData>>getRequiredCommands(){
+ returnCollections.singleton(Commands.Move.class);
+ }
+
+ @NotNull
+ @Override
+ publicSet<Commands>verify(@NotNullTransactionForContracttx,
+ @NotNullList<?extendsState>inputs,
+ @NotNullList<?extendsState>outputs,
+ @NotNullList<?extendsAuthenticatedObject<?extendsCommands>>commands,
+ @NotNullStategroupingKey){
+ AuthenticatedObject<Commands.Move>cmd=requireSingleCommand(tx.getCommands(),Commands.Move.class);
+ // There should be only a single input due to aggregation above
+ Stateinput=single(inputs);
+
+ if(!cmd.getSigners().contains(input.getOwner()))
+ thrownewIllegalStateException("Failed requirement: the transaction is signed by the owner of the CP");
+
+ // Check the output CP state is the same as the input state, ignoring the owner field.
+ if(outputs.size()!=1){
+ thrownewIllegalStateException("the state is propagated");
+ }// Don't need to check anything else, as if outputs.size == 1 then the output is equal to// the input ignoring the owner field due to the grouping.
- }
- returnsetOf(command.value)
- }
-}
-
-
-
classMoveextendsClause<State,Commands,State>{
- @NotNull
- @Override
- publicSet<Class<?extendsCommandData>>getRequiredCommands(){
- returnCollections.singleton(Commands.Move.class);
- }
-
- @NotNull
- @Override
- publicSet<Commands>verify(@NotNullTransactionForContracttx,
- @NotNullList<?extendsState>inputs,
- @NotNullList<?extendsState>outputs,
- @NotNullList<?extendsAuthenticatedObject<?extendsCommands>>commands,
- @NotNullStategroupingKey){
- AuthenticatedObject<Commands.Move>cmd=requireSingleCommand(tx.getCommands(),Commands.Move.class);
- // There should be only a single input due to aggregation above
- Stateinput=single(inputs);
-
- if(!cmd.getSigners().contains(input.getOwner()))
- thrownewIllegalStateException("Failed requirement: the transaction is signed by the owner of the CP");
-
- // Check the output CP state is the same as the input state, ignoring the owner field.
- if(outputs.size()!=1){
- thrownewIllegalStateException("the state is propagated");
+ returnCollections.singleton(cmd.getValue());}
- // Don't need to check anything else, as if outputs.size == 1 then the output is equal to
- // the input ignoring the owner field due to the grouping.
- returnCollections.singleton(cmd.getValue());}
-}
+ ...
+
We took part of code for Command.Move verification from previous tutorial and put it into the verify function
+of Move class. Notice that this class must extend the Clause abstract class, which defines
+the verify function, and the requiredCommands property used to determine the conditions under which a clause
+is triggered. In the above example it means that the clause will run verification when the Commands.Move is present in a transaction.
+
+
Note
+
Notice that commands refer to all input and output states in a transaction. For clause to be executed, transaction has
+to include all commands from requiredCommands set.
+
+
Few important changes:
+
+
verify function returns the set of commands which it has processed. Normally this returned set is identical to the
+requiredCommands used to trigger the clause, however in some cases the clause may process further optional commands
+which it needs to report that it has handled.
+
Verification takes new parameters. Usually inputs and outputs are some subset of the original transaction entries
+passed to the clause by outer composite or grouping clause. groupingKey is a key used to group original states.
+
+
As a simple example imagine input states:
+
+
1000 GBP issued by Bank of England
+
500 GBP issued by Bank of England
+
1000 GBP issued by Bank of Scotland
+
+
We will group states by Issuer so in the first group we have inputs 1 and 2, in second group input number 3. Grouping keys are:
+‘GBP issued by Bank of England’ and ‘GBP issued by Bank of Scotland’.
+
How the states can be grouped and passed in that form to the Move clause? That leads us to the concept of GroupClauseVerifier.
We need to wrap the move clause (as well as the issue and redeem clauses - see the relevant contract code for their
-full specifications) in an outer clause that understands how to group contract states and objects. For this we extend
-the standard GroupClauseVerifier and specify how to group input/output states, as well as the top-level to run on
-each group. As with the top level clause on a contract, this is normally a composite clause that delegates to subclauses.
+
We may have a transaction with similar but unrelated state evolutions which need to be validated independently. It
+makes sense to check Move command on groups of related inputs and outputs (see example above). Thus, we need to collect
+relevant states together.
+For this we extend the standard GroupClauseVerifier and specify how to group input/output states, as well as the top-level
+clause to run on each group. In our example a top-level is a composite clause - AnyCompostion that delegates verification to
+it’s subclasses (wrapped move, issue, redeem). Any in this case means that it will take 0 or more clauses that match transaction commands.
classGroup:GroupClauseVerifier<State,Commands,Issued<Terms>>(AnyComposition(
@@ -366,15 +434,17 @@ each group. As with the top level clause on a contract, this is normally a compo
-
For the CommercialPaper contract, this is the top level clause for the contract, and is passed directly into
-verifyClause (see the example code at the top of this tutorial).
+
For the CommercialPaper contract, Group is the main clause for the contract, and is passed directly into
+verifyClause (see the example code at the top of this tutorial). We used groupStates function here, it’s worth reminding
+how it works: Using state groups.
In summary the top level contract CommercialPaper specifies a single grouping clause of type
CommercialPaper.Clauses.Group which in turn specifies GroupClause implementations for each type of command
-(Redeem, Move and Issue). This reflects the flow of verification: In order to verify a CommercialPaper
+(Redeem, Move and Issue). This reflects the flow of verification: in order to verify a CommercialPaper
we first group states, check which commands are specified, and run command-specific verification logic accordingly.
The simplest way to write a smart contract would be to say that each transaction can have a single input state and a
single output state of the kind govered by that contract. This would be easy for the developer, but would prevent many
important use cases.
@@ -953,7 +965,7 @@ frequently needed chunks of logic “clauses”, and they can simplify d
Next
- Previous
+ Previous
@@ -962,7 +974,7 @@ frequently needed chunks of logic “clauses”, and they can simplify d
This guide covers how to get started with the cordapp-template. Please note there are two Corda repositories:
+
+
corda which contains the core platform code and sample CorDapps.
+
cordapp-template which contains a template CorDapp you can use to bootstrap your own CorDapps. It is the subject
+of this tutorial and should help you understand the basics of building a CorDapp.
+
+
We recommend you read the non-technical white paper and technical white paper before you get started with Corda:
+
+
The Introductory white paper describes the
+motivating vision and background of the project. It is the kind of document your boss should read. It describes why the
+project exists and briefly compares it to alternative systems on the market.
+
The Technical white paper describes the entire
+intended design from beginning to end. It is the kind of document that you should read, or at least, read parts of. Note
+that because the technical white paper describes the intended end state, it does not always align with the implementation.
There are two ways to get started with the CorDapp template. You can either work from a milestone release of Corda or a
+SNAPSHOT release of Corda.
+
Using a monthly Corda milestone release. If you wish to develop your CorDapp using the most recent milestone release
+then you can get started simply by cloning the cordapp-template repository. Gradle will grab all the required dependencies
+for you from our public Maven repository.
+
Using a Corda SNAPSHOT build. Alternatively, if you wish to work from the master branch of the Corda repo which contains
+the most up-to-date Corda feature set then you will need to clone the corda repository and publish the latest master
+build (or previously tagged releases) to your local Maven repository. You will then need to ensure that Gradle
+grabs the correct dependencies for you from Maven local by changing the corda_version in build.gradle. This will be
+covered below in Using a SNAPSHOT release.
+
Firstly, follow the getting set up page to download the JDK, IntelliJ and git if you didn’t
+already have it.
If you wish to build a CorDapp against a milestone release then please use these instructions.
+
The process for developing your CorDapp from a milestone release is the most simple way to get started and is the preferred
+approach.
+
We publish all our milestone releases to a public Maven repository on a monthly basis. As such, Gradle will automatically
+grab the appropriately versioned (specified in the cordapp-template‘s build.gradle file) dependencies for you from Maven.
+All you have to do is check out the release tag of the template version you wish to use.
+
By default, the master branch of the cordapp-template points to a SNAPSHOT release of Corda, this is because it is
+being constantly updated to reflect the changes in the master branch of the corda repository.
+
+
Note
+
If you wish to use a SNAPSHOT release then follow the instructions below: Using a SNAPSHOT release.
+
+
To clone the cordapp-template repository, use the following command:
+
gitclonehttps://github.com/corda/cordapp-template
+
Now change directories to the freshly cloned repo:
+
cdcordapp-template
+
To enumerate all the tagged releases. Use:
+
gittag
+
To checkout a specific tag, use:
+
gitcheckout-b[local_branch_name]tags/[tag_name]
+
where local_branch_name is a name of your choice and tag_name is the name of the tag you wish to checkout.
+
Gradle will handle all the dependencies for you. Now you are now ready to get started building the CorDapp Template.
If you wish to build a CorDapp against the most current version of Corda, follow these instructions.
+
The Corda repository comprises the following folders:
+
+
buildSrc contains necessary gradle plugins to build Corda.
+
client contains the RPC client framework.
+
config contains logging configurations and the default node configuration file.
+
core containing the core Corda libraries such as crypto functions, types for Corda’s building blocks: states,
+contracts, transactions, attachments, etc. and some interfaces for nodes and protocols.
+
docs contains the Corda docsite in restructured text format as well as the built docs in html. The docs can be
+accessed via /docs/index.html from the root of the repo.
+
finance defines a range of elementary contracts (and associated schemas) and protocols, such as abstract fungible
+assets, cash, obligation and commercial paper.
+
gradle contains the gradle wrapper which you’ll use to execute gradle commands.
+
gradle-plugins contains some additional plugins which we use to deploy Corda nodes.
+
lib contains some dependencies.
+
node contains anything specifically required for creating, running and managing nodes (eg: node driver, servlets,
+node services, messaging, persistence).
+
samples contains all our Corda demos and code samples.
+
test-utils contains some utilities for unit testing contracts ( the contracts testing DSL) and protocols (the
+mock network) implementation.
+
tools contains the explorer which is a GUI front-end for Corda.
+
+
Firstly navigate to the folder on your machine you wish to clone the Corda repository to. Then use the following command
+to clone the Corda repository:
+
gitclonehttps://github.com/corda/corda.git
+
Now change directories:
+
cdcorda
+
Once you’ve cloned the corda repository and are in the repo directory you have the option to remain on the master
+branch or checkout a specific branch. Use:
+
gitbranch--all
+
to enumerate all the branches. To checkout a specific branch, use:
where local_branch_name is a name of your choice and remote_branch_name is the name of the remote branch you wish
+to checkout.
+
+
Note
+
When working with master you will have access to the most up-to-date feature set. However you will be
+potentially sacrificing stability. We will endeavour to keep the master branch of the cordapp-template repo in sync
+with the master branch of corda repo. A milestone tagged release would be more stable for CorDapp development.
+
+
The next step is to publish the Corda JARs to your local Maven repository. By default the Maven local repository can be
+found:
+
+
~/.m2/repository on Unix/Mac OS X
+
%HOMEPATH%\.m2 on windows.
+
+
Publishing can be done with running the following Gradle task from the root project directory:
+
Unix/Mac OSX: ./gradlewinstall
+
Windows: gradlew.batinstall
+
This will install all required modules, along with sources and JavaDocs to your local Maven repository. The version
+and groupid of Corda installed to Maven local is specified in the build.gradle file in the root of the corda
+repository. You shouldn’t have to change these values unless you want to publish multiple versions of a SNAPSHOT, e.g.
+if you are trying out new features, in this case you can change version for each SNAPSHOT you publish.
+
+
Note
+
A quick point on corda version numbers used by Gradle.
+
In the build.gradle file for your CorDapp, you can specify the corda_version to use. It is important that when
+developing your CorDapp that you use the correct version number. For example, when wanting to work from a SNAPSHOT
+release, the release numbers are suffixed with ‘SNAPSHOT’, e.g. if the latest milestone release is M6 then the
+SNAPSHOT release will be 0.7-SNAPSHOT, and so on. As such, you will set your corda_version to '0.7-SNAPSHOT'
+in the build.gradle file in your CorDapp. Gradle will automatically grab the SNAPSHOT dependencies from your local
+Maven repository. Alternatively, if working from a milestone release, you will use the version number only, for example
+0.6 or 0.7.
+
Lastly, as the Corda repository evolves on a daily basis up until the next milestone release, it is worth nothing that
+the substance of two SNAPSHOT releases of the same number may be different. If you are using a SNAPSHOT and need help
+debugging an error then please tell us the commit you are working from. This will help us ascertain the issue.
+
+
As additional feature branches are merged into Corda you can gitpull the new changes from the corda repository.
+If you are feeling inquisitive, you may also wish to review some of the current feature branches. All new features are
+developed on separate branches. To enumerate all the current branches use:
Publishing Corda JARs from unmerged feature branches might cause some unexpected behaviour / broken CorDapps.
+It would also replace any previously published SNAPSHOTS of the same version.
+
+
+
Warning
+
If you do modify Corda after you have previously published it to Maven local then you must republish your
+SNAPSHOT build such that Maven reflects the changes you have made.
+
+
Once you have published the Corda JARs to your local Maven repository, you are ready to get started building your
+CorDapp using the latest Corda features.
For those familiar with IntelliJ, you can skip this section.
+
As noted in the getting started guide, we recommend using the IntelliJ IDE. Assuming you have already downloaded and
+installed IntelliJ, lets now open the CorDapp Template with IntelliJ.
+
For those completely new to IntelliJ
+
Firstly, load up IntelliJ. A dialogue will appear:
+
+
Click open, then navigate to the folder where you cloned the cordapp-template and click OK.
+
Next, IntelliJ will show a bunch of pop-up windows. One of which requires our attention:
+
+
Click the ‘import gradle project’ link. A dialogue will pop-up. Press OK. Gradle will now begin obtianing all the
+project dependencies and perform some indexing. It usually takes a minute or so. If you miss the ‘import gradle project’
+dialogue, simply close and re-open IntelliJ again to see it again.
+
Alternative approach
+
Alternatively, one can instruct IntelliJ to create a new project through cloning a repository. From the IntelliJ welcome
+dialogue (shown above), opt to ‘check out from version control’, then select git and enter the git url for the CorDpp tempalte
+(https://github.com/corda/cordapp-template). You’ll then need to import the Gradle project when prompted, as explained above.
+
If you already have IntelliJ open
+
From the File menu, navigate to Open... and then navigate to the directory where you cloned the cordapp-template.
+Alternatively, if you wish to clone from github directly then navigate to File>New>Projectfromexistingsources...
+and enter the URL to the CorDapp Template (specified above). When instructed, be sure to import the Gradle project when prompted.
+
The Gradle plugin
+
IntelliJ can be used to run Gradle tasks through the Gradle plugin which can be found via View>Toolwindows>Gradle.
+All the Gradle projects are listed in the window on the right hand side of the IDE. Click on a project, then ‘tasks’ to
+see all available Gradle tasks.
+
+
For the CorDapp Template repo there will only be one Gradle project listed.
+
For the Corda repo there will be many project listed, the root project corda and associated sub-projects: core,
+finance, node, etc.
+
+
+
Note
+
It’s worth noting that when you change branch in the CorDapp template, the corda_version will change to
+reflect the version of the branch you are working from.
+
+
To execute a task, double click it. The output will be shown in a console window.
Firstly, return to your terminal window used above and make sure you are in the cordapp-template directory.
+
To build the CorDapp template use the following command:
+
Unix/Mac OSX: ./gradlewdeployNodes
+
Windows: gradlew.batdeployNodes
+
Building straight away will build the example CorDapp defined the the CorDapp template source. For more information on the example
+CorDapp see “The Example CorDapp” section below. Gradle will then grab all the dependencies for you and build the
+example CorDapp.
+
The deployNodes Gradle task allows you easily create a formation of Corda nodes. In the case of the example CorDapp
+we are creating four nodes.
+
After the building process has finished to see the newly built nodes, you can navigate to the /build/nodes folder
+located in the cordapp-template root directory. You can ignore the other folders in /build for now. The nodes
+folder has the following structure:
There will be one folder generated for each node you build (more on later when we get into the detail of the
+deployNodes Gradle task) and a runnodes shell script (batch file on Widnows).
+
Each node folder contains the Corda JAR, a folder for dependencies and a folder for plugins (or CorDapps). There is also
+a node.conf file. See Corda configuration files.
+
Building from IntelliJ
+
Open the Gradle window by selecting View>Toolwindows>Gradle from the main menu. You will see the Gradle window
+open on the right hand side of the IDE. Expand tasks and then expand other. Double click on deployNodes. Gradle will
+start the build process and output progress to a console window in the IDE.
To run the sample CorDapp navigate to the build/nodes folder and execute the runnodes shell script with:
+
Unix: ./runnodes or shrunnodes
+
Windows: runnodes.bat
+
The runnodes scripts should create a terminal tab for each node. In each terminal tab, you’ll see the Corda welcome
+message and some pertinent config information, see below:
+
______ __
+ / ____/ _________/ /___ _
+ / / __ / ___/ __ / __ `/ Computer science and finance together.
+/ /___ /_/ / / / /_/ / /_/ / You should see our crazy Christmas parties!
+\____/ /_/ \__,_/\__,_/
+
+--- DEVELOPER SNAPSHOT ------------------------------------------------------------
+
+Logs can be found in : /Users/rogerwillis/Documents/Corda/cordapp-template/build/nodes/nodea/logs
+Database connection url is : jdbc:h2:tcp://10.18.0.196:50661/node
+Node listening on address : localhost:10004
+Loaded plugins : com.example.plugin.ExamplePlugin
+Embedded web server is listening on : http://10.18.0.196:10005/
+Node started up and registered in 39.0 sec
+
+
+
You’ll need to refer to the above later on for the JDBC connection string and port numbers.
+
Depending on the speed of your machine, it usually takes around 30 seconds for the nodes to finish starting up. If you
+want to double check all the nodes are running you can query the ‘status’ end-point located at
+http://host:post/api/status.
+
When booted up, the node will generate a bunch of files and directories in addition to the ones covered above:
Corda nodes can be run on separate machines with little additional configuration to the above instructions.
+
When you have successfully run the deployNodes gradle task, choose which nodes you would like to run on separate
+machines. Copy the folders for those nodes from build/nodes to the other machines. Make sure that you set the
+networkMapAddress property in node.conf to the correct hostname:port where the network map service node is
+hosted.
+
The nodes can be run on each machine with java-jarcorda.jar from the node’s directory.
To run the example CorDapp via IntelliJ you can use the RunExampleCorDapp run configuration. Select it from the drop
+down menu at the top right-hand side of the IDE and press the green arrow to start the nodes. See image below:
+
+
The node driver defined in /src/main/kotlin/com/example/Main.kt allows you to specify how many nodes you would like
+to run and the various configuration settings for each node. With the example CorDapp, the Node driver starts four nodes
+and sets up an RPC user for all but the “Controller” node (which hosts the notary Service and network map service):
+
funmain(args:Array<String>){
+ // No permissions required as we are not invoking flows.
+ valuser=User("user1","test",permissions=setOf())
+ driver(dsl={
+ startNode("Controller",setOf(ServiceInfo(ValidatingNotaryService.type)))
+ startNode("NodeA",rpcUsers=listOf(user))
+ startNode("NodeB",rpcUsers=listOf(user))
+ startNode("NodeC",rpcUsers=listOf(user))
+ waitForAllNodesToFinish()
+ },isDebug=true)
+}
+
+
+
To stop the nodes, press the red “stop” button at the top right-hand side of the IDE.
The Example CorDapp implements a basic scenario where a buyer wishes to submit purchase orders to a seller. The scenario
+defines four nodes:
+
+
Controller which hosts the network map service and validating notary service.
+
NodeA who is the buyer.
+
NodeB who is the seller.
+
NodeC an unrelated third party.
+
+
NodeA can generate purchase orders for lists and quantities of items and associated metadata such as delivery address
+and delivery date. The flows used to facilitate the agreement process always results in an agreement with the seller as
+long as the purchase order meets the contract constraints which are defined in PurchaseOrderContract.kt.
+
All agreed purchase orders between NodeA and NodeB become “shared facts” between NodeA and NodeB. But note that NodeC
+won’t see any of these transactions or have copies of any of the resulting PurchaseOrderState objects. This is
+because data is only propagated on a need-to-know basis.
The CorDapp defines a few HTTP API end-points and also serves some static web content. The end-points allow you to
+list purchase orders and add purchase orders.
+
The nodes can be found using the following port numbers, defined in build.gradle and the respective node.conf file for
+each node found in build/nodes/NodeX` etc:
+
+
Controller: localhost:10003
+
NodeA: localhost:10005
+
NodeB: localhost:10007
+
NodeC: localhost:10009
+
+
Note that the deployNodes Gradle task is used to generate the node.conf files for each node.
+
As the nodes start-up they should tell you which host and port the embedded web server is running on. The API endpoints
+served are as follows:
+
+
/api/example/me
+
/api/example/peers
+
/api/example/purchase-orders
+
/api/example/{COUNTERPARTY}/create-purchase-order
+
+
The static web content is served from /web/example.
+
A purchase order can be created via accessing the api/example/create-purchase-order end-point directly or through the
+the web form hosted at /web/example.
+
+
+
Warning
+
The content in ``web/example`` is only available for demonstration purposes and does not implement any
+anti-XSS, anti-XSRF or any other security techniques. Do not copy such code directly into products meant for production use.
+
+
+
Submitting a purchase order via HTTP API:
+
To create a purchase order from NodeA to NodeB, use:
Note the port number 10005 (NodeA) and NodeB referenced in the API end-point path. This command instructs NodeA to
+create and send a purchase order to NodeB. Upon verification and completion of the process, both nodes (but not NodeC) will
+have a signed, notarised copy of the purchase order.
+
Submitting a purchase order via web/example:
+
Navigate to the “create purchase order” button at the top left of the page, enter in the purchase order details e.g.
+
Counter-party: Select from list
+Order Number: 1
+Delivery Date: 2018-09-15
+City: London
+Country Code: UK
+Item name: Wow such item
+Item amount: 5
+
+
+
and click submit (note you can add additional item types and amounts). Upon pressing submit, the modal dialogue should close.
+To check what validation is performed over the purchase order data, have a look at the PurchaseOrderContract.Place class in
+PurchaseOrderContract.kt which defines the following contract constraints (among others not included here):
+
// Purchase order specific constraints.
+"We only deliver to the UK."by(out.po.deliveryAddress.country=="UK")
+"You must order at least one type of item."by(out.po.items.size>0)
+"You cannot order zero or negative amounts of an item."by(out.po.items.map(Item::amount).all{it>0})
+"You can only order up to 10 items at a time."by(out.po.items.map(Item::amount).sum()<=10)
+valtime=tx.timestamp?.midpoint
+"The delivery date must be in the future."by(out.po.deliveryDate.toInstant()>time)
+
+
+
Once a purchase order has been submitted:
+
Inspect the terminal windows for the nodes. Assume all of the above contract constraints are met, you should see some
+activity in the terminal windows for NodeA and NodeB (note: the green ticks are only visible on unix/mac):
+
NodeA:
+
✅ Constructing proposed purchase order.
+✅ Sending purchase order to seller for review.
+✅ Received partially signed transaction from seller.
+✅ Verifying signatures and contract constraints.
+✅ Signing transaction with our private key.
+✅ Obtaining notary signature.
+ ✅ Requesting signature by Notary service
+ ✅ Validating response from Notary service
+✅ Recording transaction in vault.
+✅ Sending fully signed transaction to seller.
+✅ Done
+
+
+
NodeB:
+
✅ Receiving proposed purchase order from buyer.
+✅ Generating transaction based on proposed purchase order.
+✅ Signing proposed transaction with our private key.
+✅ Sending partially signed transaction to buyer and wait for a response.
+✅ Verifying signatures and contract constraints.
+✅ Recording transaction in vault.
+✅ Done
+
+
+
NodeC:
+
You shouldn't see any activity.
+
+
+
Next you can view the newly created purchase order by accessing the vault of NodeA or NodeB:
Navigate to http://localhost:10005/web/example the refresh button in the top left-hand side of the page. You should
+see the newly created agreement on the page.
+
Accessing the h2 database via h2 web console:
+
You can connect to the h2 database to see the current state of the ledger, among other data such as the current state of
+the network map cache. Firstly, navigate to the folder where you downloaded the h2 web console as part of the pre-requisites
+section, above. Change directories to the bin folder:
+
cdh2/bin
+
Where there are a bunch of shell scripts and batch files. Run the web console:
+
Unix:
+
shh2.sh
+
Windows:
+
h2.bat
+
The h2 web console should start up in a web browser tab. To connect we first need to obtain a JDBC connection string. Each
+node outputs its connection string in the terminal window as it starts up. In a terminal window where a node is running,
+look for the following string:
you can use the string on the right to connect to the h2 database: just paste it in to the JDBC URL field and click Connect.
+You will be presented with a web application that enumerates all the available tables and provides an interface for you to
+query them using SQL.
+
Using the Example RPC client:
+
The /src/main/kotlin/com/example/client/ExampleClientRPC.kt file is a simple utility which uses the client RPC library
+to connect to a node and log the ‘placed’ purchase orders. It will log any existing purchase orders and listen for any future
+purchase orders. If you haven’t placed any purchase orders when you connect to to one of the Nodes via RPC then the client will log
+and future purchase orders which are agreed.
+
To build the client use the following gradle task:
+
./gradlewrunExampleClientRPC
+
To run the client, via IntelliJ:
+
Select the ‘Run Example RPC Client’ run configuration which, by default, connects to NodeA (Artemis port 10004). Click the
+Green Arrow to run the client. You can edit the run configuration to connect on a different port.
+
Via command line:
+
Run the following gradle task:
+
./gradlewrunExampleClientRPClocalhost:10004
+
To close the application use ctrl+C. For more information on the client RPC interface and how to build an RPC client
+application see:
It is usually necessary to make a couple of changes to the build.gradle file. Here will cover the most pertinent bits.
+
The buildscript
+
The buildscript is always located at the top of the file. It determines which plugins, task classes, and other classes
+are available for use in the rest of the build script. It also specifies version numbers for dependencies, among other
+things.
+
If you are working from a Corda SNAPSHOT release which you have publish to Maven local then ensure that
+corda_version is the same as the version of the Corda core modules you published to Maven local. If not then change the
+kotlin_version property. Also, if you are working from a previous milestone release, then be sure to gitcheckout
+the correct version of the CorDapp template from the cordapp-template repo.
+
buildscript{
+ ext.kotlin_version='1.0.4'
+ ext.corda_version='0.5-SNAPSHOT'// Ensure this version is the same as the corda core modules you are using.
+ ext.quasar_version='0.7.6'
+ ext.jersey_version='2.23.1'
+
+ repositories{
+ ...
+ }
+
+ dependencies{
+ ...
+ }
+}
+
+
+
Project dependencies
+
If you have any additional external dependencies for your CorDapp then add them below the comment at the end of this
+code snippet.package. Use the standard format:
This is the local node deployment system for CorDapps, the nodes generated are intended to be used for experimenting,
+debugging, and testing node configurations but not intended for production or testnet deployment.
+
In the CorDapp build.gradle file you’ll find a deployNodes task, this is where you configure the nodes you would
+like to deploy for testing. See further details below:
+
taskdeployNodes(type:com.r3corda.plugins.Cordform,dependsOn:['build']){
+ directory"./build/nodes"// The output directory.
+ networkMap"Controller"// The artemis address of the node to be used as the network map.
+ node{
+ name"Controller"// Artemis name of node to be deployed.
+ dirName"controller"// Directory to which the node will
+ nearestCity"London"// For use with the network visualiser.
+ advertisedServices=["corda.notary.validating"]// A list of services you wish the node to offer.
+ artemisPort10002
+ webPort10003// Usually 1 higher than the Artemis port.
+ cordapps=[]// Add package names of CordaApps.
+ }
+ node{// Create an additional node.
+ name"NodeA"
+ dirName"nodea"
+ nearestCity"London"
+ advertisedServices=[]
+ artemisPort10004
+ webPort10005
+ cordapps=[]
+ }
+ ...
+}
+
+
+
You can add any number of nodes, with any number of services / CorDapps by editing the templates in deployNodes. The
+only requirement is that you must specify a node to run as the network map service and one as the notary service.
+
+
Note
+
CorDapps in the current cordapp-template project are automatically registered with all nodes defined in
+deployNodes, although we expect this to change in the near future.
+
+
+
Warning
+
Make sure that there are no port clashes!
+
+
When you are finished editing your CordFormation the changes will be reflected the next time you run ./gradlewdeployNodes.
If you are building a CorDapp from scratch or adding a new CorDapp to the CorDapp-template project then you must provide
+a reference to your sub-class of CordaPluginRegistry in the provider-configuration file in located in the the
+resources/META-INF/services directory.
If you need to create any additional nodes you can do it via the build.gradle file as discussed above in
+thebuild.gradlefile and in more detail in the “cordFormation” section.
+
You may also wish to edit the /build/nodes/<nodename>/node.conf files for your nodes. For more information on
+doing this, see the Corda configuration file page.
+
Once you have made some changes to your CorDapp you can redeploy it with the following command:
Debugging is done via IntelliJ and can be done using the following steps.
+
+
Set your breakpoints.
+
Edit the node driver code in Main.kt to reflect how many nodes you wish to start along with any other
+configuration options. For example, the below starts 4 nodes, with one being the network map service / notary and
+sets up RPC credentials for 3 of the nodes.
+
+
funmain(args:Array<String>){
+ // No permissions required as we are not invoking flows.
+ valuser=User("user1","test",permissions=setOf())
+ driver(dsl={
+ startNode("Controller",setOf(ServiceInfo(ValidatingNotaryService.type)))
+ startNode("NodeA",rpcUsers=listOf(user))
+ startNode("NodeB",rpcUsers=listOf(user))
+ startNode("NodeC",rpcUsers=listOf(user))
+ waitForAllNodesToFinish()
+ },isDebug=true)
+}
+
+
+
+
Select and run the “Run Example CorDapp” run configuration in IntelliJ.
+
IntelliJ will build and run the CorDapp. Observe the console output for the remote debug ports. The “Controller”
+node will generally be on port 5005, with NodeA on port 5006 an so-on.
+
+
Listening for transport dt_socket at address: 5008
+Listening for transport dt_socket at address: 5007
+Listening for transport dt_socket at address: 5006
+
+
+
+
Edit the “Debug CorDapp” run configuration with the port of the node you wish to connect to.
Integration testing involves bringing up nodes locally and testing
+invariants about them by starting flows and inspecting their state.
+
In this tutorial we will bring up three nodes Alice, Bob and a
+Notary. Alice will issue Cash to Bob, then Bob will send this Cash
+back to Alice. We will see how to test some simple deterministic and
+nondeterministic invariants in the meantime.
+
(Note that this example where Alice is self-issuing Cash is purely for
+demonstration purposes, in reality Cash would be issued by a bank and
+subsequently passed around.)
+
In order to spawn nodes we will use the Driver DSL. This DSL allows
+one to start up node processes from code. It manages a network map
+service and safe shutting down of nodes in the background.
The above code creates a User permissioned to start the
+CashFlow protocol. It then starts up Alice and Bob with this user,
+allowing us to later connect to the nodes.
+
Then the notary is started up. Note that we need to add
+ValidatingNotaryService as an advertised service in order for this
+node to serve notary functionality. This is also where flows added in
+plugins should be specified. Note also that we won’t connect to the
+notary directly, so there’s no need to pass in the test User.
+
The startNode function returns a future that completes once the
+node is fully started. This allows starting of the nodes to be
+parallel. We wait on these futures as we need the information
+returned; their respective NodeInfo s.
Next we connect to Alice and Bob respectively from the test process
+using the test user we created. Then we establish RPC links that allow
+us to start flows and query state.
+
Note that Driver nodes start up with test server certificiates, so
+it’s enough to pass in configureTestSSL() for the clients.
The first loop creates 10 threads, each starting a CashFlow flow
+on the Alice node. We specify that we want to issue i dollars to
+Bob, using the Notary as the notary responsible for notarising the
+created states. Note that no notarisation will occur yet as we’re not
+spending any states, only entering new ones to the ledger.
+
We started the flows from different threads for the sake of the
+tutorial, to demonstrate how to test non-determinism, which is what
+the expectEvents block does.
+
The Expect DSL allows ordering constraints to be checked on a stream
+of events. The above code specifies that we are expecting 10 updates
+to be emitted on the bobVaultUpdates stream in unspecified order
+(this is what the parallel construct does). We specify a
+(otherwise optional) match predicate to identify specific updates
+we are interested in, which we then print.
+
If we run the code written so far we should see 4 nodes starting up
+(Alice,Bob,Notary + implicit Network Map service), then 10 logs of Bob
+receiving 1,2,...10 dollars from Alice in some unspecified order.
This time we’ll do it sequentially. We make Bob pay 1,2,..10 dollars
+to Alice in order. We make sure that a the CashFlow has finished
+by waiting on startFlow ‘s returnValue.
+
Then we use the Expect DSL again, this time using sequence to test
+for the updates arriving in the order we expect them to.
+
Note that parallel and sequence may be nested into each other
+arbitrarily to test more complex scenarios.
+
That’s it! We saw how to start up several corda nodes locally, how to
+connect to them, and how to test some simple invariants about
+CashFlow.
+
To run the complete test you can open
+example-code/src/integration-test/kotlin/net/corda/docs/IntegrationTestingTutorial.kt
+from IntelliJ and run the test, or alternatively use gradle:
+
# Run example-code integration tests
+./gradlew docs/source/example-code:integrationTest -i
+
+
+
+
+
+
