ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-22 14:22:28 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
9a1c27e3e0
corda/samples/notary-demo
History
Andrius Dagys e31d2b0cad
CORDA-1208: Notary service should persist the notarisation request si… (#2823) 
* CORDA-1208: Notary service should persist the notarisation request signature along with the committed input states.

This required modifying the uniqueness provider interface to accept the signature in addition to input states.
Until now the committed state log used to be stored as a map of (state reference -> (tranasction id, consuming party)).
Adding the serialized signature would mean inflating each state entry by around 700 bytes, which would be grossly inefficient.
Instead, two tables are now used: one for storing (state referece -> transaction id) map, and another for storing the notarisation
request details (transaction id, consuming party, date, signature).

* Update api - all of these changes are only related to custom notaries
2018-03-15 13:29:42 +00:00
..
src/main/kotlin/net/corda/notarydemo CORDA-1208: Notary service should persist the notarisation request si… (#2823) 2018-03-15 13:29:42 +00:00
build.gradle Overhaul of the Bank of Corda demo to fix two problems it had: 2017-11-29 14:48:05 +00:00
README.md Reflects V1.0 changes on Master re: internal samples and identity sync flow API. 2017-10-25 09:29:32 +01:00

README.md

Notary demo

This demo shows a party getting transactions notarised by either a single-node or a distributed notary service. All versions of the demo start two counterparty nodes.

One of the counterparties will generate transactions that transfer a self-issued asset to the other party and submit them for notarisation.

The Raft (https://raft.github.io/) version of the demo will start three distributed notary nodes. The BFT SMaRt (https://bft-smart.github.io/library/) version of the demo will start four distributed notary nodes.

The output will display a list of notarised transaction IDs and corresponding signer public keys. In the Raft distributed notary, every node in the cluster can service client requests, and one signature is sufficient to satisfy the notary composite key requirement. In the BFT SMaRt distributed notary, three signatures are required. You will notice that successive transactions get signed by different members of the cluster (usually allocated in a random order).

To run the Raft version of the demo from the command line in Unix:

  1. Run ./gradlew samples:notary-demo:deployNodes, which will create all three types of notaries' node directories with configs under samples/notary-demo/build/nodes/nodesRaft (nodesBFT and nodesSingle for BFT and Single notaries).
  2. Run ./samples/notary-demo/build/nodes/nodesRaft/runnodes, which will start the nodes in separate terminal windows/tabs. Wait until a "Node started up and registered in ..." message appears on each of the terminals
  3. Run ./gradlew samples:notary-demo:notarise to make a call to the "Party" node to initiate notarisation requests In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys

To run from the command line in Windows:

  1. Run gradlew samples:notary-demo:deployNodes, which will create all three types of notaries' node directories with configs under samples/notary-demo/build/nodes/nodesRaft (nodesBFT and nodesSingle for BFT and Single notaries).
  2. Run samples\notary-demo\build\nodes\nodesRaft\runnodes, which will start the nodes in separate terminal windows/tabs. Wait until a "Node started up and registered in ..." message appears on each of the terminals
  3. Run gradlew samples:notary-demo:notarise to make a call to the "Party" node to initiate notarisation requests In a few seconds you will see a message "Notarised 10 transactions" with a list of transaction ids and the signer public keys

To run the BFT SMaRt notary demo, use nodesBFT instead of nodesRaft in the path (you will see messages from notary nodes trying to communicate each other sometime with connection errors, that's normal). For a single notary node, use nodesSingle.

Distributed notary nodes store consumed states in a replicated commit log, which is backed by a H2 database on each node. You can ascertain that the commit log is synchronised across the cluster by accessing and comparing each of the nodes' backing stores by using the H2 web console:

  • Firstly, download H2 web console (http://www.h2database.com/html/download.html) (download the "platform-independent zip"), and start it using a script in the extracted folder: sh h2/bin/h2.sh (or h2\bin\h2 for Windows)

  • If you are uncertain as to which version of h2 to install or if you have connectivity issues, refer to build.gradle located in the corda directory and locate h2_version. Use a client of the same major version - even if still in beta.

  • 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 notary 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 into 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 (for Raft) or NODE_BFT_SMART_NOTARY_COMMITTED_STATES (for BFT). Note that in the Raft case the raw data is not human-readable, but we're only interested in the row count for this demo