ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-24 07:06:44 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

M6: Regen docsite

Browse Source
This commit is contained in:
Mike Hearn 2016-11-29 18:52:31 +00:00
parent 9f707cd4aa
commit 2a0778c470
624 changed files with 7316 additions and 18243 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/build/doctrees/CLI-vs-IDE.doctree vendored Normal file
View File

Binary file not shown.

BIN
docs/build/doctrees/clauses.doctree vendored Normal file
View File

Binary file not shown.

BIN
docs/build/doctrees/contract-irs.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/corda-configuration-file.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/corda-configuration-files.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/corda-plugins.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/creating-a-cordapp.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/environment.pickle vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/event-scheduling.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/getting-set-up-fault-finding.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/getting-set-up.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/index.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/initialmarginagreement.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/inthebox.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/merkle-trees.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/node-administration.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/node-explorer.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/oracles.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/protocol-state-machines.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/release-notes.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/running-a-notary.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/running-the-demos.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/secure-coding-guidelines.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/transaction-data-types.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/tutorial-building-transactions.doctree vendored Normal file
View File

Binary file not shown.

BIN
docs/build/doctrees/tutorial-clientrpc-api.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/tutorial-contract-clauses.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/tutorial-contract.doctree vendored
View File

Binary file not shown.

BIN
docs/build/doctrees/tutorial-cordapp.doctree vendored Normal file
View File

Binary file not shown.

BIN
docs/build/doctrees/tutorial-integration-testing.doctree vendored Normal file
View File

Binary file not shown.

BIN
docs/build/doctrees/where-to-start.doctree vendored
View File

Binary file not shown.

2
docs/build/html/.buildinfo vendored
View File

@ -1,4 +1,4 @@
# Sphinx build info version 1
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
config: ad4aa434cfebd269fdbb85815bc6eb43
config: caa85c0cfb7660f75ff8985c07fa3b0c
tags: 645f666f9bcd5a90fca523b33c5a78b7

352
docs/build/html/CLI-vs-IDE.html vendored Normal file
View File

@ -0,0 +1,352 @@
<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>CLI vs IDE &mdash; R3 Corda latest documentation</title>
<link rel="stylesheet" href="_static/css/custom.css" type="text/css" />
<link rel="top" title="R3 Corda latest documentation" href="index.html"/>
<link rel="next" title="Data model" href="data-model.html"/>
<link rel="prev" title="Running the demos" href="running-the-demos.html"/>
<script src="_static/js/modernizr.min.js"></script>
</head>
<body class="wy-body-for-nav" role="document">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
<div class="wy-side-scroll">
<div class="wy-side-nav-search">
<a href="index.html" class="icon icon-home"> R3 Corda
</a>
<div class="version">
latest
</div>
<div role="search">
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
<input type="text" name="q" placeholder="Search docs" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
<br>
<a href="api/index.html">API reference</a>
</div>
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
<p class="caption"><span class="caption-text">Getting started</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="inthebox.html">What&#8217;s included?</a></li>
<li class="toctree-l1"><a class="reference internal" href="getting-set-up.html">Getting set up</a></li>
<li class="toctree-l1"><a class="reference internal" href="getting-set-up-fault-finding.html">Getting set up: troubleshooting</a></li>
<li class="toctree-l1"><a class="reference internal" href="running-the-demos.html">Running the demos</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">CLI vs IDE</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#ide-intellij">IDE - IntelliJ</a></li>
<li class="toctree-l2"><a class="reference internal" href="#command-line">Command Line</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#windows-vs-mac-unix">Windows vs Mac / Unix</a></li>
<li class="toctree-l3"><a class="reference internal" href="#frequently-used-gradle-tasks">Frequently Used Gradle Tasks</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#debugging">Debugging</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#via-the-ide">Via the IDE</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<p class="caption"><span class="caption-text">Key concepts</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="data-model.html">Data model</a></li>
<li class="toctree-l1"><a class="reference internal" href="transaction-data-types.html">Data types</a></li>
<li class="toctree-l1"><a class="reference internal" href="merkle-trees.html">Transaction tear-offs</a></li>
<li class="toctree-l1"><a class="reference internal" href="consensus.html">Consensus model</a></li>
<li class="toctree-l1"><a class="reference internal" href="clauses.html">Clauses key concepts</a></li>
</ul>
<p class="caption"><span class="caption-text">CorDapps</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="creating-a-cordapp.html">CorDapps Background</a></li>
<li class="toctree-l1"><a class="reference internal" href="creating-a-cordapp.html#gradle-plugins-for-cordapps">Gradle plugins for CorDapps</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-cordapp.html">The CorDapp Template</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-cordapp.html#building-the-cordapp-template">Building the CorDapp template</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-cordapp.html#running-the-sample-cordapp">Running the Sample CorDapp</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-cordapp.html#using-the-sample-cordapp">Using the sample CorDapp</a></li>
</ul>
<p class="caption"><span class="caption-text">The Corda node</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="clientrpc.html">Client RPC</a></li>
<li class="toctree-l1"><a class="reference internal" href="messaging.html">Networking and messaging</a></li>
<li class="toctree-l1"><a class="reference internal" href="persistence.html">Persistence</a></li>
<li class="toctree-l1"><a class="reference internal" href="node-administration.html">Node administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="corda-configuration-file.html">Node configuration</a></li>
<li class="toctree-l1"><a class="reference internal" href="corda-plugins.html">The Corda plugin framework</a></li>
<li class="toctree-l1"><a class="reference internal" href="node-services.html">Brief introduction to the node services</a></li>
<li class="toctree-l1"><a class="reference internal" href="node-explorer.html">Node Explorer</a></li>
<li class="toctree-l1"><a class="reference internal" href="permissioning.html">Network permissioning</a></li>
</ul>
<p class="caption"><span class="caption-text">Tutorials</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="tutorial-contract.html">Writing a contract</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-contract-clauses.html">Writing a contract using clauses</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-test-dsl.html">Writing a contract test</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-integration-testing.html">Integration Test Tutorial</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-clientrpc-api.html">Client RPC API tutorial</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-building-transactions.html">Building Transactions</a></li>
<li class="toctree-l1"><a class="reference internal" href="flow-state-machines.html">Writing flows</a></li>
<li class="toctree-l1"><a class="reference internal" href="flow-testing.html">Writing flow tests</a></li>
<li class="toctree-l1"><a class="reference internal" href="running-a-notary.html">Running a notary service</a></li>
<li class="toctree-l1"><a class="reference internal" href="using-a-notary.html">Using a notary service</a></li>
<li class="toctree-l1"><a class="reference internal" href="oracles.html">Writing oracle services</a></li>
<li class="toctree-l1"><a class="reference internal" href="oracles.html#implementing-an-oracle-with-continuously-varying-data">Implementing an oracle with continuously varying data</a></li>
<li class="toctree-l1"><a class="reference internal" href="oracles.html#using-an-oracle">Using an oracle</a></li>
<li class="toctree-l1"><a class="reference internal" href="tutorial-attachments.html">Using attachments</a></li>
<li class="toctree-l1"><a class="reference internal" href="event-scheduling.html">Event scheduling</a></li>
</ul>
<p class="caption"><span class="caption-text">Other</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="network-simulator.html">Network Simulator</a></li>
<li class="toctree-l1"><a class="reference internal" href="initial-margin-agreement.html">Initial margin agreements</a></li>
</ul>
<p class="caption"><span class="caption-text">Component library</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="contract-catalogue.html">Contract catalogue</a></li>
<li class="toctree-l1"><a class="reference internal" href="contract-irs.html">Interest rate swaps</a></li>
</ul>
<p class="caption"><span class="caption-text">Appendix</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="loadtesting.html">Load testing</a></li>
<li class="toctree-l1"><a class="reference internal" href="setting-up-a-corda-network.html">Introduction - What is a corda network?</a></li>
<li class="toctree-l1"><a class="reference internal" href="setting-up-a-corda-network.html#setting-up-your-own-network">Setting up your own network</a></li>
<li class="toctree-l1"><a class="reference internal" href="secure-coding-guidelines.html">Secure coding guidelines</a></li>
<li class="toctree-l1"><a class="reference internal" href="release-process.html">Release process</a></li>
<li class="toctree-l1"><a class="reference internal" href="release-process.html#steps-to-cut-a-release">Steps to cut a release</a></li>
<li class="toctree-l1"><a class="reference internal" href="release-notes.html">Release notes</a></li>
<li class="toctree-l1"><a class="reference internal" href="codestyle.html">Code style guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="building-the-docs.html">Building the documentation</a></li>
</ul>
<p class="caption"><span class="caption-text">Glossary</span></p>
<ul>
<li class="toctree-l1"><a class="reference internal" href="glossary.html">Glossary</a></li>
</ul>
</div>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
<nav class="wy-nav-top" role="navigation" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">R3 Corda</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content">
<div role="navigation" aria-label="breadcrumbs navigation">
<ul class="wy-breadcrumbs">
<li><a href="index.html">Docs</a> &raquo;</li>
<li>CLI vs IDE</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/CLI-vs-IDE.txt" rel="nofollow"> View page source</a>
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<div class="section" id="cli-vs-ide">
<h1>CLI vs IDE<a class="headerlink" href="#cli-vs-ide" title="Permalink to this headline"></a></h1>
<p>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.</p>
<div class="section" id="ide-intellij">
<h2>IDE - IntelliJ<a class="headerlink" href="#ide-intellij" title="Permalink to this headline"></a></h2>
<p>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&#8217;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).</p>
<p>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 <a class="reference external" href="https://www.jetbrains.com/idea/documentation/">IntelliJ docs here</a>.</p>
</div>
<div class="section" id="command-line">
<h2>Command Line<a class="headerlink" href="#command-line" title="Permalink to this headline"></a></h2>
<div class="section" id="windows-vs-mac-unix">
<h3>Windows vs Mac / Unix<a class="headerlink" href="#windows-vs-mac-unix" title="Permalink to this headline"></a></h3>
<p>Due to the nature of their respective command interfaces, gradle is typically ran in windows with the command <code class="docutils literal"><span class="pre">gradle.bat</span></code>
(or <code class="docutils literal"><span class="pre">gradlew.bat</span></code> if using the wrapper) and in Mac / Unix environments it is ran via <code class="docutils literal"><span class="pre">./gradlew</span></code>. For brevity, the
simple windows syntax <code class="docutils literal"><span class="pre">gradle</span></code> is used for the majority of the documentation.</p>
<p>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 <code class="docutils literal"><span class="pre">gradle</span> <span class="pre">clean</span></code> 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.</p>
</div>
<div class="section" id="frequently-used-gradle-tasks">
<h3>Frequently Used Gradle Tasks<a class="headerlink" href="#frequently-used-gradle-tasks" title="Permalink to this headline"></a></h3>
<p>Note that the list of tasks can be ran for any gradle project can be displayed by running the task <code class="docutils literal"><span class="pre">tasks</span></code>. 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 <code class="docutils literal"><span class="pre">runSender</span></code> you would use the command <code class="docutils literal"><span class="pre">gradle</span> <span class="pre">samples:attachment-demo:runSender</span></code></p>
<p>The most frequent gradle tasks you will probably be running are <code class="docutils literal"><span class="pre">build</span></code> and <code class="docutils literal"><span class="pre">install</span></code>. The <code class="docutils literal"><span class="pre">build</span></code> command also executes the
unit tests as well. If you want to build without this level of verification, then use the <code class="docutils literal"><span class="pre">assemble</span></code> command - but we do
not recommend this. After running build, the <code class="docutils literal"><span class="pre">install</span></code> 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.</p>
</div>
</div>
<div class="section" id="debugging">
<h2>Debugging<a class="headerlink" href="#debugging" title="Permalink to this headline"></a></h2>
<p>Tasks and processes that are run directly via the IDE (including via the usage of the <code class="docutils literal"><span class="pre">driver</span></code> DSL) can be remotely debugged.
We do not have java debugging currently enabled in the <code class="docutils literal"><span class="pre">runnodes</span></code> scripts generated by a process we refer to as &#8216;cordformation&#8217;
but we will be implementing that shortly.</p>
<div class="section" id="via-the-ide">
<h3>Via the IDE<a class="headerlink" href="#via-the-ide" title="Permalink to this headline"></a></h3>
<p>To debug: From the IDE, configure the debug connectivity option by the &#8220;Edit Configurations&#8221; and choosing &#8220;+&#8221; and then &#8220;Remote&#8221;.
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 <code class="docutils literal"><span class="pre">main</span></code> function of <code class="docutils literal"><span class="pre">Main.kt</span></code> for each sample. Look for the string
<code class="docutils literal"><span class="pre">Listening</span> <span class="pre">for</span> <span class="pre">transport</span> <span class="pre">dt_socket</span> <span class="pre">at</span> <span class="pre">address:5xxx</span></code> 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.</p>
</div>
</div>
</div>
</div>
</div>
<footer>
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
<a href="data-model.html" class="btn btn-neutral float-right" title="Data model" accesskey="n">Next <span class="fa fa-arrow-circle-right"></span></a>
<a href="running-the-demos.html" class="btn btn-neutral" title="Running the demos" accesskey="p"><span class="fa fa-arrow-circle-left"></span> Previous</a>
</div>
<hr/>
<div role="contentinfo">
<p>
&copy; Copyright 2016, R3 Limited.
</p>
</div>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
</footer>
</div>
</div>
</section>
</div>
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT:'./',
VERSION:'latest',
COLLAPSE_INDEX:false,
FILE_SUFFIX:'.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<script type="text/javascript" src="_static/js/theme.js"></script>
<script type="text/javascript">
jQuery(function () {
SphinxRtdTheme.StickyNav.enable();
});
</script>
</body>
</html>

BIN
docs/build/html/_images/allCompositionChart.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
docs/build/html/_images/anyCompositionChart.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
docs/build/html/_images/commPaperClauses.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 13 KiB

BIN
docs/build/html/_images/commPaperExecution.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
docs/build/html/_images/firstCompositionChart.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

BIN
docs/build/html/_images/groupClauseVerifyChart.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 14 KiB

BIN
docs/build/html/_images/intellij-welcome.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
docs/build/html/_images/public-key-tree-2.png vendored
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 5.9 KiB

BIN
docs/build/html/_images/public-key-tree.png vendored
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 8.4 KiB

BIN
docs/build/html/_images/run-config-drop-down.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
docs/build/html/_images/unlinked-gradle-project.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.5 KiB

67
docs/build/html/_sources/CLI-vs-IDE.txt vendored Normal file
View File

@ -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 <https://www.jetbrains.com/idea/documentation/>`_.
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.

278
docs/build/html/_sources/clauses.txt vendored Normal file
View File

@ -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<in S : ContractState, C : CommandData, in K : Any> {
/** Determine whether this clause runs or not */
open val requiredCommands: Set<Class<out CommandData>> = emptySet()
@Throws(IllegalStateException::class)
abstract fun verify(tx: TransactionForContract,
inputs: List<S>,
outputs: List<S>,
commands: List<AuthenticatedObject<C>>,
groupingKey: K?): Set<C>
...
}
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<Commands>(tx, FirstComposition<ContractState, Commands, Unit>(
Clauses.Net<Commands, P>(),
Clauses.Group<P>()
), tx.commands.select<Obligation.Commands>())
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<State, Commands, Issued<Terms>>(
AnyComposition(
Redeem(),
Move(),
Issue())) {
override fun groupStates(tx: TransactionForContract): List<TransactionForContract.InOutGroup<State, Issued<Terms>>>
= tx.groupStates<State, Issued<Terms>> { 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<P> : GroupClauseVerifier<State<P>, Commands, Issued<Terms<P>>>(
AllComposition(
NoZeroSizedOutputs<State<P>, Commands, Terms<P>>(),
FirstComposition(
SetLifecycle<P>(),
AllComposition(
VerifyLifecycle<State<P>, Commands, Issued<Terms<P>>, P>(),
FirstComposition(
Settle<P>(),
Issue(),
ConserveAmount()
)
)
)
)
) {
override fun groupStates(tx: TransactionForContract): List<TransactionForContract.InOutGroup<Obligation.State<P>, Issued<Terms<P>>>>
= tx.groupStates<Obligation.State<P>, Issued<Terms<P>>> { 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<P> : AbstractConserveAmount<State<P>, Commands, Terms<P>>()
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<State, Commands, Terms>(
{ map { Amount(it.faceValue.quantity, it.token) }.sumOrThrow() },
{ token -> map { Amount(it.faceValue.quantity, it.token) }.sumOrZero(token) }) {
override val requiredCommands: Set<Class<out CommandData>> = setOf(Commands.Issue::class.java)
override fun verify(tx: TransactionForContract,
inputs: List<State>,
outputs: List<State>,
commands: List<AuthenticatedObject<Commands>>,
groupingKey: Issued<Terms>?): Set<Commands> {
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.

2
docs/build/html/_sources/corda-configuration-file.txt vendored
View File

@ -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.

115
docs/build/html/_sources/corda-configuration-files.txt vendored
View File

@ -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 <https://github.com/typesafehub/config/>`_ the format of the configuration files can be simple JSON, but for the more powerful substitution features
uses HOCON format see `HOCON documents <https://github.com/typesafehub/config/blob/master/HOCON.md>`_
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 (``<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.

12
docs/build/html/_sources/corda-plugins.txt vendored
View File

@ -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.

10
docs/build/html/_sources/creating-a-cordapp.txt vendored
View File

@ -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
----------------------

15
docs/build/html/_sources/getting-set-up-fault-finding.txt vendored
View File

@ -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
******************************************

6
docs/build/html/_sources/getting-set-up.txt vendored
View File

@ -20,6 +20,12 @@ We strongly recommend the use of IntelliJ's Development Environment known as IDE
`JetBrains <https://www.jetbrains.com/idea/download/>`_. 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
------

27
docs/build/html/_sources/index.txt vendored
View File

@ -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

73
docs/build/html/_sources/initialmarginagreement.txt vendored
View File

@ -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 <https://en.wikipedia.org/wiki/Financial_crisis_of_2007%E2%80%932008>`_,
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 <http://www2.isda.org/news/isda-simm-deployed-today-new-industry-standard-for-calculating-initial-margin-widely-adopted-by-market-participants>`_,
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 <http://www.opengamma.com>`_ 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

155
docs/build/html/_sources/oracles.txt vendored
View File

@ -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<FixOf>): List<Fix>
fun query(queries: List<FixOf>, deadline: Instant): List<Fix>
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<Class<*>> = 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

694
docs/build/html/_sources/protocol-state-machines.txt vendored
View File

@ -1,694 +0,0 @@
.. highlight:: kotlin
.. raw:: html
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/codesets.js"></script>
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<Currency>) : 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<OwnableState>,
val price: Amount<Currency>,
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<OwnableState>,
val price: Amount<Currency>,
val myKeyPair: KeyPair,
override val progressTracker: ProgressTracker = Seller.tracker()) : ProtocolLogic<SignedTransaction>() {
@Suspendable
override fun call(): SignedTransaction {
TODO()
}
}
open class Buyer(val otherSide: Party,
val notary: Party,
val acceptablePrice: Amount<Currency>,
val typeToBuy: Class<out OwnableState>) : ProtocolLogic<SignedTransaction>() {
@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<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<out OwnableState>`` - 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<SignedTransaction>(otherSide, hello)
maybeSTX.unwrap {
// Check that the tx proposed by the buyer is valid.
val missingSigs: Set<PublicKey> = 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<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:
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<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:
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 <http://reactivex.io/>`_ 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<SignedTransaction, SignedTransaction> {
// 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 <api/net.corda.node.internal.testing/-mock-network/index.html>`_ 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.

72
docs/build/html/_sources/release-notes.txt vendored
View File

@ -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
-----------

119
docs/build/html/_sources/running-the-demos.txt vendored
View File

@ -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.
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 <https://en.wikipedia.org/wiki/Financial_crisis_of_2007%E2%80%932008>`_,
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 <http://www2.isda.org/news/isda-simm-deployed-today-new-industry-standard-for-calculating-initial-margin-widely-adopted-by-market-participants>`_,
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 <http://www.opengamma.com>`_ 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 <http://localhost:10009/web/simmvaluationdemo/>`_.
Please note that any URL text after `simmvaluationdemo` should not be bookmarked or navigated directly to as they are only for aesthetics.

2
docs/build/html/_sources/transaction-data-types.txt vendored
View File

@ -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
-----------------------

321
docs/build/html/_sources/tutorial-building-transactions.txt vendored Normal file
View File

@ -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<TradeApprovalContract.State>(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.

57
docs/build/html/_sources/tutorial-clientrpc-api.txt vendored
View File

@ -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<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:
.. 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`

230
docs/build/html/_sources/tutorial-contract-clauses.txt vendored
View File

@ -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<Commands>())
override fun verify(tx: TransactionForContract) = verifyClause(tx, Clauses.Group(), tx.commands.select<Commands>())
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<State, Commands, Issued<Terms>>() {
override val requiredCommands: Set<Class<out CommandData>>
get() = setOf(Commands.Move::class.java)
interface Clauses {
class Move: Clause<State, Commands, Issued<Terms>>() {
override val requiredCommands: Set<Class<out CommandData>>
get() = setOf(Commands.Move::class.java)
override fun verify(tx: TransactionForContract,
override fun verify(tx: TransactionForContract,
inputs: List<State>,
outputs: List<State>,
commands: List<AuthenticatedObject<Commands>>,
groupingKey: Issued<Terms>?): Set<Commands> {
val command = commands.requireSingleCommand<Commands.Move>()
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<Commands.Move>()
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<State, Commands, State> {
@NotNull
@Override
public Set<Class<? extends CommandData>> getRequiredCommands() {
return Collections.singleton(Commands.Move.class);
}
@NotNull
@Override
public Set<Commands> verify(@NotNull TransactionForContract tx,
@NotNull List<? extends State> inputs,
@NotNull List<? extends State> outputs,
@NotNull List<? extends AuthenticatedObject<? extends Commands>> commands,
@NotNull State groupingKey) {
AuthenticatedObject<Commands.Move> 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<State, Commands, State> {
@NotNull
@Override
public Set<Class<? extends CommandData>> getRequiredCommands() {
return Collections.singleton(Commands.Move.class);
}
@NotNull
@Override
public Set<Commands> verify(@NotNull TransactionForContract tx,
@NotNull List<? extends State> inputs,
@NotNull List<? extends State> outputs,
@NotNull List<? extends AuthenticatedObject<? extends Commands>> commands,
@NotNull State groupingKey) {
AuthenticatedObject<Commands.Move> 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
---------

2
docs/build/html/_sources/tutorial-contract.txt vendored
View File

@ -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
------------------

852
docs/build/html/_sources/tutorial-cordapp.txt vendored Normal file
View File

@ -0,0 +1,852 @@
.. highlight:: kotlin
.. raw:: html
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/codesets.js"></script>
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 <https://docs.corda.r3cev.com/_static/corda-introductory-whitepaper.pdf>`_ 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 <https://docs.corda.r3cev.com/_static/corda-technical-whitepaper.pdf>`_ 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 <https://bintray.com/r3/corda>`_.
**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 <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 <corda-configuration-file>`.
**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<String>) {
// 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 <clientrpc>`
* :doc:`Client RPC tutorial <tutorial-clientrpc-api>`
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 <https://docs.gradle.org/current/userguide/dependency_management.html>`_.
**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 name>/node.conf`` files for your nodes. For more information on
doing this, see the :doc:`Corda configuration file <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<String>) {
// 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.

117
docs/build/html/_sources/tutorial-integration-testing.txt vendored Normal file
View File

@ -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

69
docs/build/html/_sources/where-to-start.txt vendored
View File

@ -1,69 +0,0 @@
.. highlight:: kotlin
.. raw:: html
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/codesets.js"></script>
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.

190
docs/build/html/_static/css/custom.css vendored
View File

@ -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;
}

15
docs/build/html/api/net.corda.client.mock/-event-generator/client-to-service-command-generator.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>EventGenerator.clientToServiceCommandGenerator - </title>
<link rel="stylesheet" href="../../style.css">
</HEAD>
<BODY>
<a href="../index.html">net.corda.client.mock</a>&nbsp;/&nbsp;<a href="index.html">EventGenerator</a>&nbsp;/&nbsp;<a href=".">clientToServiceCommandGenerator</a><br/>
<br/>
<h1>clientToServiceCommandGenerator</h1>
<a name="net.corda.client.mock.EventGenerator$clientToServiceCommandGenerator"></a>
<code><span class="keyword">val </span><span class="identifier">clientToServiceCommandGenerator</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

16
docs/build/html/api/net.corda.client.model/-gathered-transaction-data-model/gathered-transaction-data-list.html vendored
View File

@ -1,16 +0,0 @@
<HTML>
<HEAD>
<title>GatheredTransactionDataModel.gatheredTransactionDataList - </title>
<link rel="stylesheet" href="../../style.css">
</HEAD>
<BODY>
<a href="../index.html">net.corda.client.model</a>&nbsp;/&nbsp;<a href="index.html">GatheredTransactionDataModel</a>&nbsp;/&nbsp;<a href=".">gatheredTransactionDataList</a><br/>
<br/>
<h1>gatheredTransactionDataList</h1>
<a name="net.corda.client.model.GatheredTransactionDataModel$gatheredTransactionDataList"></a>
<code><span class="keyword">val </span><span class="identifier">gatheredTransactionDataList</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code><br/>
<p>We JOIN the transaction list with state machines</p>
<br/>
<br/>
</BODY>
</HTML>

14
docs/build/html/api/net.corda.client.model/-protocol-status/-init-.html vendored
View File

@ -1,14 +0,0 @@
<HTML>
<HEAD>
<title>ProtocolStatus.<init> - </title>
<link rel="stylesheet" href="../../style.css">
</HEAD>
<BODY>
<a href="../index.html">net.corda.client.model</a>&nbsp;/&nbsp;<a href="index.html">ProtocolStatus</a>&nbsp;/&nbsp;<a href=".">&lt;init&gt;</a><br/>
<br/>
<h1>&lt;init&gt;</h1>
<code><span class="identifier">ProtocolStatus</span><span class="symbol">(</span><span class="identifier" id="net.corda.client.model.ProtocolStatus$<init>(kotlin.String)/status">status</span><span class="symbol">:</span>&nbsp;<span class="identifier">String</span><span class="symbol">)</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

36
docs/build/html/api/net.corda.client.model/-protocol-status/index.html vendored
View File

@ -1,36 +0,0 @@
<HTML>
<HEAD>
<title>ProtocolStatus - </title>
<link rel="stylesheet" href="../../style.css">
</HEAD>
<BODY>
<a href="../index.html">net.corda.client.model</a>&nbsp;/&nbsp;<a href=".">ProtocolStatus</a><br/>
<br/>
<h1>ProtocolStatus</h1>
<code><span class="keyword">data</span> <span class="keyword">class </span><span class="identifier">ProtocolStatus</span></code><br/>
<br/>
<br/>
<h3>Constructors</h3>
<table>
<tbody>
<tr>
<td>
<a href="-init-.html">&lt;init&gt;</a></td>
<td>
<code><span class="identifier">ProtocolStatus</span><span class="symbol">(</span><span class="identifier" id="net.corda.client.model.ProtocolStatus$<init>(kotlin.String)/status">status</span><span class="symbol">:</span>&nbsp;<span class="identifier">String</span><span class="symbol">)</span></code></td>
</tr>
</tbody>
</table>
<h3>Properties</h3>
<table>
<tbody>
<tr>
<td>
<a href="status.html">status</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">status</span><span class="symbol">: </span><span class="identifier">String</span></code></td>
</tr>
</tbody>
</table>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.client.model/-protocol-status/status.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>ProtocolStatus.status - </title>
<link rel="stylesheet" href="../../style.css">
</HEAD>
<BODY>
<a href="../index.html">net.corda.client.model</a>&nbsp;/&nbsp;<a href="index.html">ProtocolStatus</a>&nbsp;/&nbsp;<a href=".">status</a><br/>
<br/>
<h1>status</h1>
<a name="net.corda.client.model.ProtocolStatus$status"></a>
<code><span class="keyword">val </span><span class="identifier">status</span><span class="symbol">: </span><span class="identifier">String</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.client.model/-state-machine-data/protocol-status.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>StateMachineData.protocolStatus - </title>
<link rel="stylesheet" href="../../style.css">
</HEAD>
<BODY>
<a href="../index.html">net.corda.client.model</a>&nbsp;/&nbsp;<a href="index.html">StateMachineData</a>&nbsp;/&nbsp;<a href=".">protocolStatus</a><br/>
<br/>
<h1>protocolStatus</h1>
<a name="net.corda.client.model.StateMachineData$protocolStatus"></a>
<code><span class="keyword">val </span><span class="identifier">protocolStatus</span><span class="symbol">: </span><span class="identifier">ObservableValue</span><span class="symbol">&lt;</span><a href="../-protocol-status/index.html"><span class="identifier">ProtocolStatus</span></a><span class="symbol">?</span><span class="symbol">&gt;</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.contracts/-r.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>R - </title>
<link rel="stylesheet" href="../style.css">
</HEAD>
<BODY>
<a href="index.html">net.corda.core.contracts</a>&nbsp;/&nbsp;<a href=".">R</a><br/>
<br/>
<h1>R</h1>
<a name="net.corda.core.contracts$R"></a>
<code><span class="keyword">val </span><span class="identifier">R</span><span class="symbol">: </span><a href="-requirements/index.html"><span class="identifier">Requirements</span></a></code><br/>
<br/>
<br/>
</BODY>
</HTML>

14
docs/build/html/api/net.corda.core.contracts/-requirements/-init-.html vendored
View File

@ -1,14 +0,0 @@
<HTML>
<HEAD>
<title>Requirements.<init> - </title>
<link rel="stylesheet" href="../../style.css">
</HEAD>
<BODY>
<a href="../index.html">net.corda.core.contracts</a>&nbsp;/&nbsp;<a href="index.html">Requirements</a>&nbsp;/&nbsp;<a href=".">&lt;init&gt;</a><br/>
<br/>
<h1>&lt;init&gt;</h1>
<code><span class="identifier">Requirements</span><span class="symbol">(</span><span class="symbol">)</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-null-public-key-tree.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>NullPublicKeyTree - </title>
<link rel="stylesheet" href="../style.css">
</HEAD>
<BODY>
<a href="index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href=".">NullPublicKeyTree</a><br/>
<br/>
<h1>NullPublicKeyTree</h1>
<a name="net.corda.core.crypto$NullPublicKeyTree"></a>
<code><span class="keyword">val </span><span class="identifier">NullPublicKeyTree</span><span class="symbol">: </span><a href="-public-key-tree/index.html"><span class="identifier">PublicKeyTree</span></a></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-builder/-init-.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Builder.<init> - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Builder</a>&nbsp;/&nbsp;<a href=".">&lt;init&gt;</a><br/>
<br/>
<h1>&lt;init&gt;</h1>
<code><span class="identifier">Builder</span><span class="symbol">(</span><span class="symbol">)</span></code><br/>
<p>A helper class for building a <a href="../-node/index.html">PublicKeyTree.Node</a>.</p>
<br/>
<br/>
</BODY>
</HTML>

16
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-builder/add-key.html vendored
View File

@ -1,16 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Builder.addKey - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Builder</a>&nbsp;/&nbsp;<a href=".">addKey</a><br/>
<br/>
<h1>addKey</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Builder$addKey(net.corda.core.crypto.PublicKeyTree, kotlin.Int)"></a>
<code><span class="keyword">fun </span><span class="identifier">addKey</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$addKey(net.corda.core.crypto.PublicKeyTree, kotlin.Int)/publicKey">publicKey</span><span class="symbol">:</span>&nbsp;<a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">, </span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$addKey(net.corda.core.crypto.PublicKeyTree, kotlin.Int)/weight">weight</span><span class="symbol">:</span>&nbsp;<span class="identifier">Int</span>&nbsp;<span class="symbol">=</span>&nbsp;1<span class="symbol">)</span><span class="symbol">: </span><a href="index.html"><span class="identifier">Builder</span></a></code><br/>
<p>Adds a child <a href="../index.html">PublicKeyTree</a> node. Specifying a <a href="add-key.html#net.corda.core.crypto.PublicKeyTree.Builder$addKey(net.corda.core.crypto.PublicKeyTree, kotlin.Int)/weight">weight</a> for the child is optional and will default to 1.</p>
<br/>
<br/>
</BODY>
</HTML>

17
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-builder/add-keys.html vendored
View File

@ -1,17 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Builder.addKeys - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Builder</a>&nbsp;/&nbsp;<a href=".">addKeys</a><br/>
<br/>
<h1>addKeys</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Builder$addKeys(kotlin.Array((net.corda.core.crypto.PublicKeyTree)))"></a>
<code><span class="keyword">fun </span><span class="identifier">addKeys</span><span class="symbol">(</span><span class="keyword">vararg</span> <span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$addKeys(kotlin.Array((net.corda.core.crypto.PublicKeyTree)))/publicKeys">publicKeys</span><span class="symbol">:</span>&nbsp;<a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">)</span><span class="symbol">: </span><a href="index.html"><span class="identifier">Builder</span></a></code><br/>
<a name="net.corda.core.crypto.PublicKeyTree.Builder$addKeys(kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)))"></a>
<code><span class="keyword">fun </span><span class="identifier">addKeys</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$addKeys(kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)))/publicKeys">publicKeys</span><span class="symbol">:</span>&nbsp;<span class="identifier">List</span><span class="symbol">&lt;</span><a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><a href="index.html"><span class="identifier">Builder</span></a></code><br/>
<br/>
<br/>
</BODY>
</HTML>

17
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-builder/build.html vendored
View File

@ -1,17 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Builder.build - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Builder</a>&nbsp;/&nbsp;<a href=".">build</a><br/>
<br/>
<h1>build</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Builder$build(kotlin.Int)"></a>
<code><span class="keyword">fun </span><span class="identifier">build</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$build(kotlin.Int)/threshold">threshold</span><span class="symbol">:</span>&nbsp;<span class="identifier">Int</span><span class="symbol">?</span>&nbsp;<span class="symbol">=</span>&nbsp;null<span class="symbol">)</span><span class="symbol">: </span><a href="../index.html"><span class="identifier">PublicKeyTree</span></a></code><br/>
<p>Builds the <a href="../-node/index.html">PublicKeyTree.Node</a>. If <a href="build.html#net.corda.core.crypto.PublicKeyTree.Builder$build(kotlin.Int)/threshold">threshold</a> is not specified, it will default to
the size of the children, effectively generating an "N of N" requirement.</p>
<br/>
<br/>
</BODY>
</HTML>

54
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-builder/index.html vendored
View File

@ -1,54 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Builder - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href=".">Builder</a><br/>
<br/>
<h1>Builder</h1>
<code><span class="keyword">class </span><span class="identifier">Builder</span></code><br/>
<p>A helper class for building a <a href="../-node/index.html">PublicKeyTree.Node</a>.</p>
<br/>
<br/>
<h3>Constructors</h3>
<table>
<tbody>
<tr>
<td>
<a href="-init-.html">&lt;init&gt;</a></td>
<td>
<code><span class="identifier">Builder</span><span class="symbol">(</span><span class="symbol">)</span></code><p>A helper class for building a <a href="../-node/index.html">PublicKeyTree.Node</a>.</p>
</td>
</tr>
</tbody>
</table>
<h3>Functions</h3>
<table>
<tbody>
<tr>
<td>
<a href="add-key.html">addKey</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">addKey</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$addKey(net.corda.core.crypto.PublicKeyTree, kotlin.Int)/publicKey">publicKey</span><span class="symbol">:</span>&nbsp;<a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">, </span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$addKey(net.corda.core.crypto.PublicKeyTree, kotlin.Int)/weight">weight</span><span class="symbol">:</span>&nbsp;<span class="identifier">Int</span>&nbsp;<span class="symbol">=</span>&nbsp;1<span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Builder</span></code><p>Adds a child <a href="../index.html">PublicKeyTree</a> node. Specifying a <a href="add-key.html#net.corda.core.crypto.PublicKeyTree.Builder$addKey(net.corda.core.crypto.PublicKeyTree, kotlin.Int)/weight">weight</a> for the child is optional and will default to 1.</p>
</td>
</tr>
<tr>
<td>
<a href="add-keys.html">addKeys</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">addKeys</span><span class="symbol">(</span><span class="keyword">vararg</span> <span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$addKeys(kotlin.Array((net.corda.core.crypto.PublicKeyTree)))/publicKeys">publicKeys</span><span class="symbol">:</span>&nbsp;<a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Builder</span></code><br/>
<code><span class="keyword">fun </span><span class="identifier">addKeys</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$addKeys(kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)))/publicKeys">publicKeys</span><span class="symbol">:</span>&nbsp;<span class="identifier">List</span><span class="symbol">&lt;</span><a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Builder</span></code></td>
</tr>
<tr>
<td>
<a href="build.html">build</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">build</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Builder$build(kotlin.Int)/threshold">threshold</span><span class="symbol">:</span>&nbsp;<span class="identifier">Int</span><span class="symbol">?</span>&nbsp;<span class="symbol">=</span>&nbsp;null<span class="symbol">)</span><span class="symbol">: </span><a href="../index.html"><span class="identifier">PublicKeyTree</span></a></code><p>Builds the <a href="../-node/index.html">PublicKeyTree.Node</a>. If <a href="build.html#net.corda.core.crypto.PublicKeyTree.Builder$build(kotlin.Int)/threshold">threshold</a> is not specified, it will default to
the size of the children, effectively generating an "N of N" requirement.</p>
</td>
</tr>
</tbody>
</table>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-leaf/-init-.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Leaf.<init> - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Leaf</a>&nbsp;/&nbsp;<a href=".">&lt;init&gt;</a><br/>
<br/>
<h1>&lt;init&gt;</h1>
<code><span class="identifier">Leaf</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Leaf$<init>(java.security.PublicKey)/publicKey">publicKey</span><span class="symbol">:</span>&nbsp;<a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">)</span></code><br/>
<p>The leaf node of the public key tree – a wrapper around a <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a> primitive</p>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-leaf/equals.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Leaf.equals - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Leaf</a>&nbsp;/&nbsp;<a href=".">equals</a><br/>
<br/>
<h1>equals</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Leaf$equals(kotlin.Any)"></a>
<code><span class="keyword">fun </span><span class="identifier">equals</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Leaf$equals(kotlin.Any)/other">other</span><span class="symbol">:</span>&nbsp;<span class="identifier">Any</span><span class="symbol">?</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Boolean</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-leaf/hash-code.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Leaf.hashCode - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Leaf</a>&nbsp;/&nbsp;<a href=".">hashCode</a><br/>
<br/>
<h1>hashCode</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Leaf$hashCode()"></a>
<code><span class="keyword">fun </span><span class="identifier">hashCode</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Int</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

111
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-leaf/index.html vendored
View File

@ -1,111 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Leaf - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href=".">Leaf</a><br/>
<br/>
<h1>Leaf</h1>
<code><span class="keyword">class </span><span class="identifier">Leaf</span>&nbsp;<span class="symbol">:</span>&nbsp;<a href="../index.html"><span class="identifier">PublicKeyTree</span></a></code><br/>
<p>The leaf node of the public key tree – a wrapper around a <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a> primitive</p>
<br/>
<br/>
<h3>Constructors</h3>
<table>
<tbody>
<tr>
<td>
<a href="-init-.html">&lt;init&gt;</a></td>
<td>
<code><span class="identifier">Leaf</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Leaf$<init>(java.security.PublicKey)/publicKey">publicKey</span><span class="symbol">:</span>&nbsp;<a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">)</span></code><p>The leaf node of the public key tree – a wrapper around a <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a> primitive</p>
</td>
</tr>
</tbody>
</table>
<h3>Properties</h3>
<table>
<tbody>
<tr>
<td>
<a href="keys.html">keys</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">keys</span><span class="symbol">: </span><span class="identifier">Set</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span></code><p>Returns all <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a>s contained within the tree leaves</p>
</td>
</tr>
<tr>
<td>
<a href="public-key.html">publicKey</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">publicKey</span><span class="symbol">: </span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a></code></td>
</tr>
</tbody>
</table>
<h3>Inherited Properties</h3>
<table>
<tbody>
<tr>
<td>
<a href="../single-key.html">singleKey</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">singleKey</span><span class="symbol">: </span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a></code><p>Returns the enclosed <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a> for a <a href="../index.html">PublicKeyTree</a> with a single node</p>
</td>
</tr>
</tbody>
</table>
<h3>Functions</h3>
<table>
<tbody>
<tr>
<td>
<a href="equals.html">equals</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">equals</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Leaf$equals(kotlin.Any)/other">other</span><span class="symbol">:</span>&nbsp;<span class="identifier">Any</span><span class="symbol">?</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Boolean</span></code></td>
</tr>
<tr>
<td>
<a href="hash-code.html">hashCode</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">hashCode</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Int</span></code></td>
</tr>
<tr>
<td>
<a href="is-fulfilled-by.html">isFulfilledBy</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">isFulfilledBy</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Leaf$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))/keys">keys</span><span class="symbol">:</span>&nbsp;<span class="identifier">Iterable</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code><p>Checks whether <a href="is-fulfilled-by.html#net.corda.core.crypto.PublicKeyTree.Leaf$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))/keys">keys</a> match a sufficient amount of leaf nodes</p>
</td>
</tr>
<tr>
<td>
<a href="to-string.html">toString</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">toString</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">String</span></code></td>
</tr>
</tbody>
</table>
<h3>Inherited Functions</h3>
<table>
<tbody>
<tr>
<td>
<a href="../contains-any.html">containsAny</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">containsAny</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree$containsAny(kotlin.collections.Iterable((java.security.PublicKey)))/otherKeys">otherKeys</span><span class="symbol">:</span>&nbsp;<span class="identifier">Iterable</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code><p>Checks whether any of the given <a href="../keys.html">keys</a> matches a leaf on the tree</p>
</td>
</tr>
<tr>
<td>
<a href="../is-fulfilled-by.html">isFulfilledBy</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">isFulfilledBy</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree$isFulfilledBy(java.security.PublicKey)/key">key</span><span class="symbol">:</span>&nbsp;<a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code></td>
</tr>
<tr>
<td>
<a href="../to-base58-string.html">toBase58String</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">toBase58String</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">String</span></code></td>
</tr>
</tbody>
</table>
</BODY>
</HTML>

17
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-leaf/is-fulfilled-by.html vendored
View File

@ -1,17 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Leaf.isFulfilledBy - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Leaf</a>&nbsp;/&nbsp;<a href=".">isFulfilledBy</a><br/>
<br/>
<h1>isFulfilledBy</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Leaf$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))"></a>
<code><span class="keyword">fun </span><span class="identifier">isFulfilledBy</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Leaf$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))/keys">keys</span><span class="symbol">:</span>&nbsp;<span class="identifier">Iterable</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code><br/>
Overrides <a href="../is-fulfilled-by.html">PublicKeyTree.isFulfilledBy</a><br/>
<p>Checks whether <a href="is-fulfilled-by.html#net.corda.core.crypto.PublicKeyTree.Leaf$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))/keys">keys</a> match a sufficient amount of leaf nodes</p>
<br/>
<br/>
</BODY>
</HTML>

20
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-leaf/keys.html vendored
View File

@ -1,20 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Leaf.keys - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Leaf</a>&nbsp;/&nbsp;<a href=".">keys</a><br/>
<br/>
<h1>keys</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Leaf$keys"></a>
<code><span class="keyword">val </span><span class="identifier">keys</span><span class="symbol">: </span><span class="identifier">Set</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span></code><br/>
Overrides <a href="../keys.html">PublicKeyTree.keys</a><br/>
<p>Returns all <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a>s contained within the tree leaves</p>
<p><strong>Getter</strong><br/>
<p>Returns all <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a>s contained within the tree leaves</p>
</p>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-leaf/public-key.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Leaf.publicKey - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Leaf</a>&nbsp;/&nbsp;<a href=".">publicKey</a><br/>
<br/>
<h1>publicKey</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Leaf$publicKey"></a>
<code><span class="keyword">val </span><span class="identifier">publicKey</span><span class="symbol">: </span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-leaf/to-string.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Leaf.toString - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Leaf</a>&nbsp;/&nbsp;<a href=".">toString</a><br/>
<br/>
<h1>toString</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Leaf$toString()"></a>
<code><span class="keyword">fun </span><span class="identifier">toString</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">String</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

20
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/-init-.html vendored
View File

@ -1,20 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.<init> - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">&lt;init&gt;</a><br/>
<br/>
<h1>&lt;init&gt;</h1>
<code><span class="identifier">Node</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/threshold">threshold</span><span class="symbol">:</span>&nbsp;<span class="identifier">Int</span><span class="symbol">, </span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/children">children</span><span class="symbol">:</span>&nbsp;<span class="identifier">List</span><span class="symbol">&lt;</span><a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">&gt;</span><span class="symbol">, </span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/weights">weights</span><span class="symbol">:</span>&nbsp;<span class="identifier">List</span><span class="symbol">&lt;</span><span class="identifier">Int</span><span class="symbol">&gt;</span><span class="symbol">)</span></code><br/>
<p>Represents a node in the <a href="../index.html">PublicKeyTree</a>. It maintains a list of child nodes – sub-trees, and associated
<a href="-init-.html#net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/weights">weights</a> carried by child node signatures.</p>
<p>The <a href="-init-.html#net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/threshold">threshold</a> 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.</p>
<br/>
<br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/children.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.children - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">children</a><br/>
<br/>
<h1>children</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Node$children"></a>
<code><span class="keyword">val </span><span class="identifier">children</span><span class="symbol">: </span><span class="identifier">List</span><span class="symbol">&lt;</span><a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">&gt;</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/equals.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.equals - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">equals</a><br/>
<br/>
<h1>equals</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Node$equals(kotlin.Any)"></a>
<code><span class="keyword">fun </span><span class="identifier">equals</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$equals(kotlin.Any)/other">other</span><span class="symbol">:</span>&nbsp;<span class="identifier">Any</span><span class="symbol">?</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Boolean</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/hash-code.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.hashCode - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">hashCode</a><br/>
<br/>
<h1>hashCode</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Node$hashCode()"></a>
<code><span class="keyword">fun </span><span class="identifier">hashCode</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Int</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

129
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/index.html vendored
View File

@ -1,129 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href=".">Node</a><br/>
<br/>
<h1>Node</h1>
<code><span class="keyword">class </span><span class="identifier">Node</span>&nbsp;<span class="symbol">:</span>&nbsp;<a href="../index.html"><span class="identifier">PublicKeyTree</span></a></code><br/>
<p>Represents a node in the <a href="../index.html">PublicKeyTree</a>. It maintains a list of child nodes – sub-trees, and associated
<a href="weights.html">weights</a> carried by child node signatures.</p>
<p>The <a href="threshold.html">threshold</a> 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.</p>
<br/>
<br/>
<br/>
<br/>
<h3>Constructors</h3>
<table>
<tbody>
<tr>
<td>
<a href="-init-.html">&lt;init&gt;</a></td>
<td>
<code><span class="identifier">Node</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/threshold">threshold</span><span class="symbol">:</span>&nbsp;<span class="identifier">Int</span><span class="symbol">, </span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/children">children</span><span class="symbol">:</span>&nbsp;<span class="identifier">List</span><span class="symbol">&lt;</span><a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">&gt;</span><span class="symbol">, </span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/weights">weights</span><span class="symbol">:</span>&nbsp;<span class="identifier">List</span><span class="symbol">&lt;</span><span class="identifier">Int</span><span class="symbol">&gt;</span><span class="symbol">)</span></code><p>Represents a node in the <a href="../index.html">PublicKeyTree</a>. It maintains a list of child nodes – sub-trees, and associated
<a href="-init-.html#net.corda.core.crypto.PublicKeyTree.Node$<init>(kotlin.Int, kotlin.collections.List((net.corda.core.crypto.PublicKeyTree)), kotlin.collections.List((kotlin.Int)))/weights">weights</a> carried by child node signatures.</p>
</td>
</tr>
</tbody>
</table>
<h3>Properties</h3>
<table>
<tbody>
<tr>
<td>
<a href="children.html">children</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">children</span><span class="symbol">: </span><span class="identifier">List</span><span class="symbol">&lt;</span><a href="../index.html"><span class="identifier">PublicKeyTree</span></a><span class="symbol">&gt;</span></code></td>
</tr>
<tr>
<td>
<a href="keys.html">keys</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">keys</span><span class="symbol">: </span><span class="identifier">Set</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span></code><p>Returns all <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a>s contained within the tree leaves</p>
</td>
</tr>
<tr>
<td>
<a href="threshold.html">threshold</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">threshold</span><span class="symbol">: </span><span class="identifier">Int</span></code></td>
</tr>
<tr>
<td>
<a href="weights.html">weights</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">weights</span><span class="symbol">: </span><span class="identifier">List</span><span class="symbol">&lt;</span><span class="identifier">Int</span><span class="symbol">&gt;</span></code></td>
</tr>
</tbody>
</table>
<h3>Inherited Properties</h3>
<table>
<tbody>
<tr>
<td>
<a href="../single-key.html">singleKey</a></td>
<td>
<code><span class="keyword">val </span><span class="identifier">singleKey</span><span class="symbol">: </span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a></code><p>Returns the enclosed <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a> for a <a href="../index.html">PublicKeyTree</a> with a single node</p>
</td>
</tr>
</tbody>
</table>
<h3>Functions</h3>
<table>
<tbody>
<tr>
<td>
<a href="equals.html">equals</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">equals</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$equals(kotlin.Any)/other">other</span><span class="symbol">:</span>&nbsp;<span class="identifier">Any</span><span class="symbol">?</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Boolean</span></code></td>
</tr>
<tr>
<td>
<a href="hash-code.html">hashCode</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">hashCode</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Int</span></code></td>
</tr>
<tr>
<td>
<a href="is-fulfilled-by.html">isFulfilledBy</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">isFulfilledBy</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))/keys">keys</span><span class="symbol">:</span>&nbsp;<span class="identifier">Iterable</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Boolean</span></code><p>Checks whether <a href="is-fulfilled-by.html#net.corda.core.crypto.PublicKeyTree.Node$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))/keys">keys</a> match a sufficient amount of leaf nodes</p>
</td>
</tr>
<tr>
<td>
<a href="to-string.html">toString</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">toString</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">String</span></code></td>
</tr>
</tbody>
</table>
<h3>Inherited Functions</h3>
<table>
<tbody>
<tr>
<td>
<a href="../contains-any.html">containsAny</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">containsAny</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree$containsAny(kotlin.collections.Iterable((java.security.PublicKey)))/otherKeys">otherKeys</span><span class="symbol">:</span>&nbsp;<span class="identifier">Iterable</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code><p>Checks whether any of the given <a href="../keys.html">keys</a> matches a leaf on the tree</p>
</td>
</tr>
<tr>
<td>
<a href="../is-fulfilled-by.html">isFulfilledBy</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">isFulfilledBy</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree$isFulfilledBy(java.security.PublicKey)/key">key</span><span class="symbol">:</span>&nbsp;<a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code></td>
</tr>
<tr>
<td>
<a href="../to-base58-string.html">toBase58String</a></td>
<td>
<code><span class="keyword">fun </span><span class="identifier">toBase58String</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">String</span></code></td>
</tr>
</tbody>
</table>
</BODY>
</HTML>

17
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/is-fulfilled-by.html vendored
View File

@ -1,17 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.isFulfilledBy - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">isFulfilledBy</a><br/>
<br/>
<h1>isFulfilledBy</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Node$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))"></a>
<code><span class="keyword">fun </span><span class="identifier">isFulfilledBy</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree.Node$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))/keys">keys</span><span class="symbol">:</span>&nbsp;<span class="identifier">Iterable</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">Boolean</span></code><br/>
Overrides <a href="../is-fulfilled-by.html">PublicKeyTree.isFulfilledBy</a><br/>
<p>Checks whether <a href="is-fulfilled-by.html#net.corda.core.crypto.PublicKeyTree.Node$isFulfilledBy(kotlin.collections.Iterable((java.security.PublicKey)))/keys">keys</a> match a sufficient amount of leaf nodes</p>
<br/>
<br/>
</BODY>
</HTML>

20
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/keys.html vendored
View File

@ -1,20 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.keys - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">keys</a><br/>
<br/>
<h1>keys</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Node$keys"></a>
<code><span class="keyword">val </span><span class="identifier">keys</span><span class="symbol">: </span><span class="identifier">Set</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span></code><br/>
Overrides <a href="../keys.html">PublicKeyTree.keys</a><br/>
<p>Returns all <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a>s contained within the tree leaves</p>
<p><strong>Getter</strong><br/>
<p>Returns all <a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html">PublicKey</a>s contained within the tree leaves</p>
</p>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/threshold.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.threshold - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">threshold</a><br/>
<br/>
<h1>threshold</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Node$threshold"></a>
<code><span class="keyword">val </span><span class="identifier">threshold</span><span class="symbol">: </span><span class="identifier">Int</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/to-string.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.toString - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">toString</a><br/>
<br/>
<h1>toString</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Node$toString()"></a>
<code><span class="keyword">fun </span><span class="identifier">toString</span><span class="symbol">(</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">String</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

15
docs/build/html/api/net.corda.core.crypto/-public-key-tree/-node/weights.html vendored
View File

@ -1,15 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.Node.weights - </title>
<link rel="stylesheet" href="../../../style.css">
</HEAD>
<BODY>
<a href="../../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="../index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href="index.html">Node</a>&nbsp;/&nbsp;<a href=".">weights</a><br/>
<br/>
<h1>weights</h1>
<a name="net.corda.core.crypto.PublicKeyTree.Node$weights"></a>
<code><span class="keyword">val </span><span class="identifier">weights</span><span class="symbol">: </span><span class="identifier">List</span><span class="symbol">&lt;</span><span class="identifier">Int</span><span class="symbol">&gt;</span></code><br/>
<br/>
<br/>
</BODY>
</HTML>

16
docs/build/html/api/net.corda.core.crypto/-public-key-tree/contains-any.html vendored
View File

@ -1,16 +0,0 @@
<HTML>
<HEAD>
<title>PublicKeyTree.containsAny - </title>
<link rel="stylesheet" href="../../style.css">
</HEAD>
<BODY>
<a href="../index.html">net.corda.core.crypto</a>&nbsp;/&nbsp;<a href="index.html">PublicKeyTree</a>&nbsp;/&nbsp;<a href=".">containsAny</a><br/>
<br/>
<h1>containsAny</h1>
<a name="net.corda.core.crypto.PublicKeyTree$containsAny(kotlin.collections.Iterable((java.security.PublicKey)))"></a>
<code><span class="keyword">fun </span><span class="identifier">containsAny</span><span class="symbol">(</span><span class="identifier" id="net.corda.core.crypto.PublicKeyTree$containsAny(kotlin.collections.Iterable((java.security.PublicKey)))/otherKeys">otherKeys</span><span class="symbol">:</span>&nbsp;<span class="identifier">Iterable</span><span class="symbol">&lt;</span><a href="http://docs.oracle.com/javase/6/docs/api/java/security/PublicKey.html"><span class="identifier">PublicKey</span></a><span class="symbol">&gt;</span><span class="symbol">)</span><span class="symbol">: </span><span class="identifier">&lt;ERROR CLASS&gt;</span></code><br/>
<p>Checks whether any of the given <a href="keys.html">keys</a> matches a leaf on the tree</p>
<br/>
<br/>
</BODY>
</HTML>

Some files were not shown because too many files have changed in this diff Show More