mirror of
https://github.com/corda/corda.git
synced 2024-12-18 20:47:57 +00:00
Docs: misc fixes and tweaks to the docsite.
This commit is contained in:
Mike Hearn
parent
1243118aa9
commit
d281fe82b5
@ -57,9 +57,12 @@ case the ``node_dir`` is the location where your node server's JAR and configura
|
||||
Starting your node
|
||||
------------------
|
||||
|
||||
Now you have a node server with your app installed, you can run it by navigating to ``<node_dir>`` and running
|
||||
Now you have a node server with your app installed, you can run it by navigating to ``<node_dir>`` and running:
|
||||
|
||||
java -jar corda.jar
|
||||
.. code-block:: shell
|
||||
|
||||
Windows: java -jar corda.jar
|
||||
UNIX: ./corda.jar
|
||||
|
||||
The plugin should automatically be registered and the configuration file used.
|
||||
|
||||
@ -67,7 +70,7 @@ The plugin should automatically be registered and the configuration file used.
|
||||
|
||||
The configuration file and workspace paths can be overidden on the command line e.g.
|
||||
|
||||
``java -jar corda.jar --config-file=test.conf --base-directory=/opt/r3corda/nodes/test``.
|
||||
``./corda.jar --config-file=test.conf --base-directory=/opt/r3corda/nodes/test``.
|
||||
|
||||
Otherwise the workspace folder for the node is the current working path.
|
||||
|
||||
@ -99,35 +102,22 @@ at the present time, and should certainly be treated as read-only.
|
||||
Building against Corda
|
||||
----------------------
|
||||
|
||||
.. warning:: This feature is subject to rapid change
|
||||
|
||||
Corda now supports publishing to Maven local to build against it. To publish to Maven local run the following in the
|
||||
root directory of Corda
|
||||
To publish to your local Maven repository (in ``~/.m2`` on Unix and ``%HOMEPATH%\.m2`` on Windows) run the following
|
||||
in the root directory of the Corda code:
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
./gradlew install
|
||||
|
||||
This will publish corda-$version.jar, finance-$version.jar, core-$version.jar and node-$version.jar to the
|
||||
group net.corda. You can now depend on these as you normally would a Maven dependency.
|
||||
|
||||
Gradle plugins for CorDapps
|
||||
---------------------------
|
||||
group net.corda. You can now depend on these as you normally would a Maven dependency, using the group id
|
||||
``net.corda``.
|
||||
|
||||
There are several Gradle plugins that reduce your build.gradle boilerplate and make development of CorDapps easier.
|
||||
The available plugins are in the gradle-plugins directory of the Corda repository.
|
||||
|
||||
Building Gradle plugins
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To install to your local Maven repository the plugins that CorDapp gradle files require, run the following from the
|
||||
root of the Corda project:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
./gradlew install
|
||||
|
||||
The plugins will now be installed to your local Maven repository in ~/.m2 on Unix and %HOMEPATH%\.m2 on Windows.
|
||||
To install to your local Maven repository the plugins that CorDapp gradle files require, enter the ``gradle-plugins``
|
||||
directory and then run ``../gradle install``. The plugins will now be installed to your local Maven repository.
|
||||
|
||||
Using Gradle plugins
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
@ -135,11 +125,6 @@ Using Gradle plugins
|
||||
To use the plugins, if you are not already using the CorDapp template project, you must modify your build.gradle. Add
|
||||
the following segments to the relevant part of your build.gradle.
|
||||
|
||||
Template build.gradle
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To build against Corda and the plugins that CorDapps use, update your build.gradle to contain the following:
|
||||
|
||||
.. code-block:: groovy
|
||||
|
||||
buildscript {
|
||||
@ -242,10 +227,9 @@ is a three node example;
|
||||
You can create more configurations with new tasks that extend Cordform.
|
||||
|
||||
New nodes can be added by simply adding another node block and giving it a different name, directory and ports. When you
|
||||
run this task it will install the nodes to the directory specified and a script will be generated (for UNIX users only
|
||||
at present) to run the nodes with one command (``runnodes``). On MacOS X this script will run each node in a new
|
||||
terminal tab, and on Linux it will open up a new XTerm for each node. On Windows the (``runnodes.bat``) script will run
|
||||
one node per window.
|
||||
run this task it will install the nodes to the directory specified and a script will be generated to run the nodes with
|
||||
one command (``runnodes``). On MacOS X this script will run each node in a new terminal tab, and on Linux it will open
|
||||
up a new XTerm for each node. On Windows the (``runnodes.bat``) script will run one node per window.
|
||||
|
||||
Other CorDapps can also be specified if they are already specified as classpath or compile dependencies in your
|
||||
``build.gradle``.
|
||||
|
||||
@ -413,9 +413,6 @@ This code is longer but no more complicated. Here are some things to pay attenti
|
||||
As you can see, the flow 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 flow 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
|
||||
-----------------
|
||||
|
||||
@ -530,10 +527,8 @@ Future features
|
||||
The flow 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
|
||||
* Exception management, with a "flow 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 RPC
|
||||
* 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 flows that can be easily sub-classed by local developers in order to integrate internal
|
||||
|
||||
@ -5,12 +5,12 @@ Welcome to the Corda documentation!
|
||||
current state of the code. `Read the docs for milestone release M9.0 <https://docs.corda.net/releases/release-M9.0/>`_.
|
||||
|
||||
`Corda <https://www.corda.net/>`_ is an open-source distributed ledger platform. The latest *milestone* (i.e. stable)
|
||||
release is M9.0. The codebase is on `GitHub <https://github.com/corda>`_, and our community can be found on
|
||||
release is M9.2. The codebase is on `GitHub <https://github.com/corda>`_, and our community can be found on
|
||||
`Slack <https://slack.corda.net/>`_ and in our `forum <https://discourse.corda.net/>`_.
|
||||
|
||||
If you're new to Corda, you should start by learning about its motivating vision and architecture. A good introduction
|
||||
is the `Introduction to Corda webinar <https://vimeo.com/192757743/c2ec39c1e1>`_ and the `Introductory white paper`_. As
|
||||
they become more familiar with Corda, readers with a technical background will also want to dive into the `Technical white paper`_,
|
||||
you become more familiar with Corda, readers with a technical background will also want to dive into the `Technical white paper`_,
|
||||
which describes the platform's envisioned end-state.
|
||||
|
||||
.. note:: Corda training is now available in London, New York and Singapore! `Learn more. <https://www.corda.net/corda-training/>`_
|
||||
|
||||
@ -1,27 +1,51 @@
|
||||
What's included?
|
||||
================
|
||||
|
||||
The Corda prototype currently includes:
|
||||
This Corda early access preview includes:
|
||||
|
||||
* A collection of samples, for instance a web app demo that uses it to implement IRS trading.
|
||||
* A template app you can use to get started, and tutorial app that teaches you the basics.
|
||||
* A peer to peer network with message persistence and delivery retries.
|
||||
* Key data structures for defining contracts and states.
|
||||
* Smart contracts, which you can find in the :doc:`contract-catalogue`.
|
||||
* Algorithms that work with them, such as serialising, hashing, signing, and verification of the signatures.
|
||||
* API documentation and tutorials (what you're reading).
|
||||
* A business process orchestration framework.
|
||||
* A business process workflow framework.
|
||||
* Notary infrastructure for precise timestamping, and elimination of double spending without a blockchain.
|
||||
* A simple REST API, and a web app demo that uses it to present a frontend for IRS trading.
|
||||
* A simple RPC API.
|
||||
* A user interface for administration.
|
||||
|
||||
Some things it does not currently include but should gain later are:
|
||||
|
||||
* Sandboxing, distribution or publication of smart contract code
|
||||
* A user interface for administration
|
||||
* Sandboxing, distribution and publication of smart contract code.
|
||||
* A well specified wire protocol.
|
||||
* An identity framework.
|
||||
|
||||
The prototype's goal is rapid exploration of ideas. Therefore in places it takes shortcuts that a production system
|
||||
would not in order to boost productivity:
|
||||
The open source version of Corda is designed for developers exploring how to write apps. It is not intended to
|
||||
be production grade software. For example it uses an embedded SQL database and doesn't yet have connectivity
|
||||
support for mainstream SQL vendors (Oracle, Postgres, MySQL, SQL Server etc). It hasn't been security audited
|
||||
and the APIs change in every release.
|
||||
|
||||
* It uses an object graph serialization framework instead of a well specified, vendor neutral protocol.
|
||||
* There's currently no permissioning framework.
|
||||
* Some privacy techniques aren't implemented yet.
|
||||
* It uses an embedded SQL database and doesn't yet have connectivity support for mainstream SQL vendors (Oracle,
|
||||
Postgres, MySQL, SQL Server etc).
|
||||
Source tree layout
|
||||
------------------
|
||||
|
||||
The Corda repository comprises the following folders:
|
||||
|
||||
* **buildSrc** contains necessary gradle plugins to build Corda.
|
||||
* **client** contains libraries for connecting to a node, working with it remotely and binding server-side data to JavaFX UI.
|
||||
* **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 the core code of the Corda node (eg: node driver, servlets, node services, messaging, persistence).
|
||||
* **node-api** contains data structures shared between the node and the client module, e.g. types sent via RPC.
|
||||
* **node-schemas** contains entity classes used to represent relational database tables.
|
||||
* **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.
|
||||
|
||||
@ -105,11 +105,13 @@ Validation
|
||||
|
||||
One of the design decisions for a notary is whether or not to **validate** a transaction before accepting it.
|
||||
|
||||
If a transaction is not checked for validity, it opens the platform to "denial of state" attacks, where anyone can build an invalid transaction consuming someone else's states and submit it to the notary to get the states "blocked".
|
||||
However, if the transaction is validated, this requires the notary to be able to see the full contents of the transaction in question and its dependencies.
|
||||
This is an obvious privacy leak.
|
||||
If a transaction is not checked for validity, it opens the platform to "denial of state" attacks, where anyone can build
|
||||
an invalid transaction consuming someone else's states and submit it to the notary to get the states blocked. However,
|
||||
if the transaction is validated, this requires the notary to be able to see the full contents of the transaction in
|
||||
question and its dependencies. This is an obvious privacy leak.
|
||||
|
||||
The platform is flexible and currently supports both validating and non-validating notary implementations -- a party can select which one to use based on its own privacy requirements.
|
||||
The platform is flexible and currently supports both validating and non-validating notary implementations -- a
|
||||
party can select which one to use based on its own privacy requirements.
|
||||
|
||||
.. note:: In the non-validating model, the "denial of state" attack is partially alleviated by requiring the calling
|
||||
party to authenticate and storing its identity for the request. The conflict information returned by the notary
|
||||
@ -117,9 +119,6 @@ The platform is flexible and currently supports both validating and non-validati
|
||||
conflicting transaction is valid, the current one is aborted; if not, a dispute can be raised and the input states
|
||||
of the conflicting invalid transaction are "un-committed" (via a legal process).
|
||||
|
||||
.. note:: At present, all notaries can see the entire contents of a submitted transaction. A future piece of work
|
||||
will enable the processing of :doc:`merkle-trees`, thus providing data hiding of sensitive information.
|
||||
|
||||
Timestamping
|
||||
------------
|
||||
|
||||
|
||||
@ -132,7 +132,7 @@ downloading any missing transactions into local storage and validating them. The
|
||||
.. note:: Non-validating notaries assume transaction validity and do not request transaction data or their dependencies
|
||||
beyond the list of states consumed.
|
||||
|
||||
The tutorial " :doc:`tutorial-contract` "provides a hand-ons walk-through using these concepts.
|
||||
The tutorial ":doc:`tutorial-contract`" provides a hand-ons walk-through using these concepts.
|
||||
|
||||
Transaction Representation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -19,8 +19,8 @@ The security model plays a role in the following areas:
|
||||
beyond the list of states consumed (and thus, their level of trust is much lower and exposed to malicious use of transaction inputs).
|
||||
From an algorithm perspective, Corda currently provides a distributed notary implementation that uses Raft.
|
||||
|
||||
.. note:: Future notary algorithms may include BFT and hardware assisted non-BFT algorithms (where non-BFT algorithms
|
||||
are converted into a more trusted form using remote attestation and hardware protection).
|
||||
.. note:: A byzantine fault tolerant notary based on the BFT-SMaRT algorithm is included in the code, but is
|
||||
still incubating and is not yet ready for use.
|
||||
|
||||
* Authentication, authorisation and entitlements:
|
||||
Network permissioning, including node to node authentication, is performed using TLS and certificates.
|
||||
@ -28,7 +28,6 @@ The security model plays a role in the following areas:
|
||||
|
||||
.. warning:: API level authentication (RPC, Web) is currently simple username/password for demonstration purposes and will be revised.
|
||||
Similarly, authorisation is currently based on permission groups applied to flow execution.
|
||||
This is subject to design review with views to selecting a proven, mature entitlements solution.
|
||||
|
||||
Privacy techniques
|
||||
|
||||
|
||||
@ -104,8 +104,8 @@ validated user is the X.500 subject DN of the client TLS certificate and we assu
|
||||
the peer. This allows the flow framework to authentically determine the ``Party`` initiating a new flow. For RPC clients
|
||||
the validated user is the username itself and the RPC framework uses this to determine what permissions the user has.
|
||||
|
||||
.. note:: ``Party`` lookup is currently done by the legal name which isn't guaranteed to be unique. A future version will
|
||||
use the full X.500 name as it can provide additional structures for uniqueness.
|
||||
.. note:: ``Party`` lookup is currently done by the legal name. A future version will use the full X.500 name as
|
||||
it can provide additional structures for uniqueness.
|
||||
|
||||
The broker also does host verification when connecting to another peer. It checks that the TLS certificate common name
|
||||
matches with the advertised legal name from the network map service.
|
||||
|
||||
@ -346,11 +346,13 @@ external legacy systems by insertion of unpacked data into existing
|
||||
tables. To enable these features the contract state must implement the
|
||||
``QueryableState`` interface to define the mappings.
|
||||
|
||||
Node Web Server
|
||||
---------------
|
||||
Corda Web Server
|
||||
----------------
|
||||
|
||||
A web server comes bundled with the node by default, but is not started
|
||||
automatically. This web server exposes both RPC backed API calls and
|
||||
static content serving. The web server is not automatically started,
|
||||
you must explicitly start it in the node driver or define a web port
|
||||
in your `Cordformation`_ configuration.
|
||||
A simple web server is provided that embeds the Jetty servlet container.
|
||||
The Corda web server is not meant to be used for real, production-quality
|
||||
web apps. Instead it shows one example way of using Corda RPC in web apps
|
||||
to provide a REST API on top of the Corda native RPC mechanism.
|
||||
|
||||
.. note:: The Corda web server may be removed in future and replaced with
|
||||
sample specific webapps using a standard framework like Spring Boot.
|
||||
@ -2,16 +2,13 @@ Network permissioning
|
||||
=====================
|
||||
|
||||
The keystore located in ``<workspace>/certificates/sslkeystore.jks`` is required to connect to the Corda network securely.
|
||||
In development mode (when ``devMode = true``, see :doc:`corda-configuration-file` for more information) a pre-configured
|
||||
In development mode (when ``devMode = true``, see ":doc:`corda-configuration-file`" for more information) a pre-configured
|
||||
keystore will be used if the keystore does not exist. This is to ensure developers can get the nodes working as quickly
|
||||
as possible.
|
||||
|
||||
However this is not secure for the real network. This documentation will explain the procedure of obtaining a signed
|
||||
certificate for TestNet.
|
||||
|
||||
.. warning:: The TestNet has not been setup yet as of Milestone 8 release. You will not be able to connect to the
|
||||
certificate signing server.
|
||||
|
||||
Initial Registration
|
||||
--------------------
|
||||
|
||||
@ -55,4 +52,3 @@ You can also specify the location of ``node.conf`` with ``--config-file`` flag i
|
||||
A ``certificates`` folder containing the keystore and trust store will be created in the base directory when the process is completed.
|
||||
|
||||
.. warning:: The keystore is protected by the keystore password from the node configuration file. The password should kept safe to protect the private key and certificate.
|
||||
.. note:: Password encryption in node configuration will be supported in subsequent release.
|
||||
|
||||
@ -17,9 +17,9 @@ The demos can be run either from the command line, or from inside IntelliJ. Runn
|
||||
recommended if you just want to see the demos run, whereas using IntelliJ can be helpful if you want to debug or
|
||||
extend the demos. For more details about running via the command line or from within IntelliJ, see :doc:`CLI-vs-IDE`.
|
||||
|
||||
.. note:: If you are running the demos from the command line in Unix, you may have to install xterm.
|
||||
If any of the demos don't work, please raise an issue on GitHub.
|
||||
|
||||
.. note:: If any of the demos don't work, please raise an issue on GitHub.
|
||||
.. note:: If you are running the demos from the command line in Linux (but not macOS), you may have to install xterm.
|
||||
|
||||
.. _trader-demo:
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
.. _log4j2: http://logging.apache.org/log4j/2.x/
|
||||
|
||||
What is a corda network?
|
||||
What is a Corda network?
|
||||
========================
|
||||
|
||||
A Corda network consists of a number of machines running nodes, including a single node operating as the network map
|
||||
@ -47,8 +47,7 @@ The most important fields regarding network configuration are:
|
||||
is the hostname *that must be externally resolvable by other nodes in the network*. In the above configuration this is the
|
||||
resolvable name of a machine in a VPN.
|
||||
* ``rpcAddress``: The address to which Artemis will bind for RPC calls.
|
||||
* ``webAddress``: The address the webserver should bind. Note that the port must be distinct from that of ``p2pAddress``
|
||||
and ``rpcAddress`` if they are on the same machine.
|
||||
* ``webAddress``: The address the webserver should bind. Note that the port must be distinct from that of ``p2pAddress`` and ``rpcAddress`` if they are on the same machine.
|
||||
* ``networkMapService``: Details of the node running the network map service. If it's this node that's running the service
|
||||
then this field must not be specified.
|
||||
|
||||
|
||||
@ -7,15 +7,11 @@
|
||||
The example CorDapp
|
||||
===================
|
||||
|
||||
.. note:: The example CorDapp was previously hosted in the `cordapp-template <https://github.com/corda/cordapp-template>`_ repository. It has now been
|
||||
moved into a new `cordapp-tutorial <https://github.com/corda/cordapp-tutorial>`_ repository. Going forward, the cordapp-template repo will contain an
|
||||
actual CorDapp template, which should be used as the basis for your CorDapps going forward.
|
||||
|
||||
This guide covers how to get started with the example CorDapp. Please note there are several Corda repositories:
|
||||
|
||||
* `corda <https://github.com/corda/corda>`_ which contains the core platform code and sample CorDapps.
|
||||
* `cordapp-tutorial <https://github.com/corda/cordapp-tutorial>`_ which contains an example 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.
|
||||
* `cordapp-template <https://github.com/corda/cordapp-template>`_ which contains a bare-bones template on which to build your own CorDapps.
|
||||
* `cordapp-tutorial <https://github.com/corda/cordapp-tutorial>`_ which contains an example CorDapp you can use to bootstrap your own CorDapps. It is the subject of this tutorial and should help you understand the basics.
|
||||
* `cordapp-template <https://github.com/corda/cordapp-template>`_ which contains a bare-bones template designed for starting new projects by copying.
|
||||
|
||||
We recommend you read the non-technical white paper and technical white paper before you get started with Corda:
|
||||
|
||||
@ -29,7 +25,7 @@ We recommend you read the non-technical white paper and technical white paper be
|
||||
Background
|
||||
----------
|
||||
|
||||
The Example CorDapp implements a basic scenario where one party wishes to send an IOU to another party. The scenario
|
||||
The example CorDapp implements a basic scenario where one party wishes to send an IOU to another party. The scenario
|
||||
defines four nodes:
|
||||
|
||||
* **Controller**, which hosts the network map service and validating notary service
|
||||
@ -105,27 +101,6 @@ 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:
|
||||
|
||||
@ -323,9 +298,6 @@ start the build process and output progress to a console window in the IDE.
|
||||
Running the example CorDapp
|
||||
---------------------------
|
||||
|
||||
Running the example CorDapp from the command line
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To run the sample CorDapp navigate to the ``kotlin-source/build/nodes`` folder and execute the ``runnodes`` shell script with:
|
||||
|
||||
Unix: ``./runnodes`` or ``sh runnodes``
|
||||
@ -505,25 +477,25 @@ activity in the terminal windows for NodeA and NodeB (note: the green ticks are
|
||||
|
||||
.. sourcecode:: none
|
||||
|
||||
✅ Generating transaction based on new IOU.
|
||||
✅ Verifying contract constraints.
|
||||
✅ Signing transaction with our private key.
|
||||
✅ Sending proposed transaction to recipient for review.
|
||||
✅ Done
|
||||
✅ Generating transaction based on new IOU.
|
||||
✅ Verifying contract constraints.
|
||||
✅ Signing transaction with our private key.
|
||||
✅ Sending proposed transaction to recipient for review.
|
||||
✅ Done
|
||||
|
||||
*NodeB:*
|
||||
|
||||
.. sourcecode:: none
|
||||
|
||||
✅ Receiving proposed transaction from sender.
|
||||
✅ Verifying signatures and contract constraints.
|
||||
✅ Signing proposed transaction with our private key.
|
||||
✅ Obtaining notary signature and recording transaction.
|
||||
✅ Requesting signature by notary service
|
||||
✅ Requesting signature by Notary service
|
||||
✅ Validating response from Notary service
|
||||
✅ Broadcasting transaction to participants
|
||||
✅ Done
|
||||
✅ Receiving proposed transaction from sender.
|
||||
✅ Verifying signatures and contract constraints.
|
||||
✅ Signing proposed transaction with our private key.
|
||||
✅ Obtaining notary signature and recording transaction.
|
||||
✅ Requesting signature by notary service
|
||||
✅ Requesting signature by Notary service
|
||||
✅ Validating response from Notary service
|
||||
✅ Broadcasting transaction to participants
|
||||
✅ Done
|
||||
|
||||
*NodeC:*
|
||||
|
||||
@ -861,32 +833,25 @@ Running Nodes Across Machines
|
||||
The nodes can also be set up to communicate between separate machines on the
|
||||
same subnet.
|
||||
|
||||
After deploying the nodes, navigate to the build folder (`kotlin-source/build/
|
||||
nodes` or `java-source/build/nodes`) and move some of the individual node folders to
|
||||
separate machines on the same subnet (e.g. using a USB key). It is important
|
||||
that no nodes - including the controller node - end up on more than one
|
||||
machine. Each computer should also have a copy of `runnodes` and
|
||||
`runnodes.bat`.
|
||||
After deploying the nodes, navigate to the build folder (``kotlin-source/build/nodes`` or ``java-source/build/nodes``)
|
||||
and move some of the individual node folders to separate machines on the same subnet (e.g. using a USB key).
|
||||
It is important that no nodes - including the controller node - end up on more than one machine. Each computer
|
||||
should also have a copy of ``runnodes`` and ``runnodes.bat``.
|
||||
|
||||
For example, you may end up with the following layout:
|
||||
|
||||
* Machine 1: `controller`, `nodea`, `runnodes`, `runnodes.bat`
|
||||
* Machine 2: `nodeb`, `nodec`, `runnodes`, `runnodes.bat`
|
||||
* Machine 1: ``controller``, ``nodea``, ``runnodes``, ``runnodes.bat``
|
||||
* Machine 2: ``nodeb``, ``nodec``, ``runnodes``, ``runnodes.bat``
|
||||
|
||||
You must now edit the configuration file for each node, including the
|
||||
controller. Open each node's config file (`[nodeName]/node.conf`), and make
|
||||
the following changes:
|
||||
You must now edit the configuration file for each node, including the controller. Open each node's config file,
|
||||
and make the following changes:
|
||||
|
||||
* Change the Artemis messaging address to the machine's IP address (e.g.
|
||||
`p2pAddress="10.18.0.166:10006"`)
|
||||
* Change the Artemis messaging address to the machine's IP address (e.g. ``p2pAddress="10.18.0.166:10006"``)
|
||||
* Change the network map service details to the IP address of the machine where the
|
||||
controller node is running and to its legal name (e.g. `networkMapService.address="10.18.0.166:10002"` and
|
||||
`networkMapService.legalName=controller`) (please note that the controller will not have the `networkMapService` config)
|
||||
controller node is running and to its legal name (e.g. ``networkMapService.address="10.18.0.166:10002"`` and
|
||||
``networkMapService.legalName=controller``) (please note that the controller will not have the ``networkMapService`` config)
|
||||
|
||||
Each machine should now run its nodes using `runnodes` or `runnodes.bat`
|
||||
files. Once they are up and running, the nodes should be able to create
|
||||
IOUs among themselves in the same way as when they were running on
|
||||
the same machine.
|
||||
Now run each node.
|
||||
|
||||
Debugging your CorDapp
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Loading…
Reference in New Issue
Block a user