ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-19 21:17:58 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge release-v1 onto master (mostly documentation changes) (#1797)

Browse Source 
* Updated corda release version to 1.0.0.RC2 (#1641)

* Fixed Simm Valuation Demo Test and enable serializabe java 8 lambdas. (#1655)

* [CORDA-624] Node Explorer on Issuing cash throws MissingContractAttachements exception (#1656)

(cherry picked from commit 27fea4d)

* BIGINT fix for H2 coin selection. (#1658)

* BIGINT fix for H2 coin selection.

* Review feedback

* CORDA-637 Node Explorer shows Network Map Service in Cash Issue dropdown (#1665)

* [CORDA-637] Node Explorer shows Network Map Service in Cash Issue dropdown

* add TODO to remove the hack

* Declare this internal message string as "const". (#1676)

* Merge "A variety of small fixes" into the 1.0 release branch (#1673)

* Minor: improve javadocs in NodeInfo

* Minor: use package descriptions in Kotlin build of api docs too, not just javadocs.

* RPC: make RPCConnection non-internal, as it's a core API. Move docs around so they're on public API not internal API.

* Add an IntelliJ scope that covers the currently supported Corda API.

This is useful when used in combination with the "Highlight public
declarations with missing KDoc" inspection.

* Ironic: upgrade the version of the Gradle plugin that checks for upgraded versions of things.

It had broken due being incompatible with the new versions of Gradle
itself.

* Docs: flesh out javadocs on ServiceHub

* Docs: add @suppress to a few things that were polluting the Dokka docs.

* Docs: mention RPC access in NodeInfo javadoc

* IRS Fixes to bring UI closer to declared financial types (#1662)

* Made problematic CordaRPCClient c'tor private (with internal bridge methods) and added correct c'tors for public use. (#1653)

initialiseSerialization param has also been removed.

* Fixing flow snapshot feature (#1685)

* Fix validating notary flow to handle notary change transactions properly. (#1687)

Add a notary change test for checking longer chains involving both regular and notary change transactions.

* Unification of VaultQuery And VaultService APIs (into single VaultService interface) to simplify node bootstrapping and usability. (#1677) (#1688)

* Identity documentation (#1620)

* Sketch initial identity docs

* Restructure confidential identity docs to better fit structure

* Split confidential identities into API and concepts

* Further expansion on basic identity conceptS

* Merge Party type into api-identity.rst

* Address feedback on written content

* Rework inline code with literalinclude

* Start addressing feedback from Richard

* Clarify use of "counterparty"

* Address comments on key concepts

* Correct back to US english

* Clarify distribution/publishing of identities

* Update changelog around confidential identities

* CORDA-642 Notary demo documentation fixes (#1682)

* Notary demo documentation fixes.

* One of the tables is prefixed.

* CORDA-641: A temporary fix for contract upgrade transactions (#1700)

* A temporary fix for contract upgrade transactions:
during LedgerTransaction verification run the right logic based on whether
it contains the UpgradeCommand.

* Move ContractUpgradeFlowTest away from createSomeNodes()

* Remove assembleBareTx as it's not used

* Update corda version tag to 1.0.0-RC3 (#1705)

* Hide SerializationContext from public API on TransactionBuilder (#1707)

* Hide SerializationContext from public API on TransactionBuilder

(cherry picked from commit 6ff7b7e)

* Hide SerializationContext from public API on TransactionBuilder

(cherry picked from commit 6ff7b7e)

* Address feedback on confidential identities docs (#1701)

* Address minor comments on confidential identities docs

* Expand on implementation details of confidential identities

* Cleanup

* Clarify details of the data blob in the swap identites flow

* Add that certificate path is not made public for confidential identities

* FlowSession docs (#1693)

* FlowSession docs (#1660)

* FlowSession docs

* PR comments

* Milder example flow name

* Fixes bugs with contract constraints (#1696)

* Added schedulable flows to cordapp scanning

Fixed a bug where the core flows are included in every cordapp. Added a test to prove the scheduled flows are loaded correctly. Added scheduled flow support to cordapp.

Renabled broken test.

Fixed test to prove cordapps aren't retreived from network.

Review fixes.

Fixed a test issue caused by gradle having slightly different paths to IntelliJ

* Fixed test for real this time.

* Consistent use of CordaException and CordaRuntimeException (#1710)

* Custom exceptions in corda, should either derive from an appropriate closely related java exception, or CordaException, or CordaRuntimeException. They should not inherit just from Exception, or RuntimeException.

Handle PR comments

Add nicer constructors to CordaException and CordaRuntimeException

* Fix ambiguous defaulted constructor

* Add @suppress (#1725)

* Git-ignore Node Explorer config. (#1709)

* add message warning windows users they might need to manually kill explorer demo nodes started by gradle (#1717) (#1726)

* Misc documentation fixes (#1694)

(cherry picked from commit 592896f)

* Document -parameters compiler arg for Java CorDapps. (#1712)

* Correct non-anonymous two party trade flow (#1731)

* Parameterize TwoPartyTradeFlowTests to confirm deanonymised functionality works.
* Correct handling of counterparty using well known identity in TWoPartyTradeFlow

* CORDA-594 - SIMM Demo doc update (#1723) (#1735)

* CORDA-594 - SIMM Demo doc update

For V1 write a series of JSON / curl commands a user can follow to run
the demo

* Review Comments

* Updated the rationale behind as to why SIMM was introduced.

* typo

* Cordapps now have a name field. (#1664)

Corrected cordapp name generation.

Added changelog entry.

* Small API fixes against M16 (#1737)

* Move CompositeSignaturesWithKeys into net.corda.core.crypto package.

(cherry picked from commit 8f29562)

* Rename and move CordaPluginRegistry to reflect its real purpose now.
Simplify serialization code a bit.

(cherry picked from commit e2ecd3a)

* Docs: docsite improvements

* Remove discussion of webserver from 'writing a cordapp' page.
* Fixup some flow docs.
* Add a couple more package descriptions.

(cherry picked from commit 2aedc43)

* Review comments

(cherry picked from commit ba1d007)

* Review comments - always apply default whitelist and no longer load it via ServiceLoader

(cherry picked from commit 7d4d7bb)

* Added wording about renaming services resource file

* Update corda version tag to 1.0.0-RC4 (#1734)

* Update corda version tag to 1.0.0-RC3

* Update corda version tag to 1.0.0-RC4

* Update build.gradle

* V1 tests and fixes for the ContractConstraints work (#1739)

* V1 tests and fixes for the ContractConstraints work

* More fixes.

* Added a contract constraints section to the key concepts doc. (#1704)

Documentation for contract constraints.

Added to index.

Review fixes round 1.

More review fixes.

Review fixes.

Explained package contents.

review fixes.

Addressed RGB's final review comments.

Updated source code type to 'java'

* Fixes dead links. (#1749)

* Update gradle plugins version to 1.0.0 (#1753)

* Update Readme (#1756)

* Update Readme

Minor tweaks to Readme -- consistent capitalisation and more descriptive list of features (also reordered to put the important things first)

* Copied master readme.

* Update Readme

Minor tweaks to Readme -- consistent capitalisation and more descriptive list of features (also reordered to put the important things first)

* Fixes .rst formatting. (#1751)

* Updates tutorials. (#1649)

* Updates tutorials.

* Addresses review comments.

* Tutorial refresh for v1.0 and moving of code into separate files. (#1758)

* Moves code sections in tutorials to code files.

* Removes wallet references.

* Updates repo layout doc.

* Removes remaining cordapp-tutorial references, replaced with cordapp-example.

* Fixes broken link.

* Misc docs fixes.

* Refreshes the ServiceHub and rpc ops api pages.

* Updates the cheat sheet.

* Updates cookbooks.

* Refreshes the running-a-notary tutorial.

* Updates flow-testing tutorial

* Updates tear-offs tutorial.

* Refreshes integration-testing tutorial.

* Updates to contract tutorial and accompanying code to bring inline with V1 release.

* Refreshes contract-upgrade tutorial.

* Fixed broken code sample in "writing a contract" and updated contracts dsl.

* Added contract ref to java code. Fixed broken rst markup.

* Updates transaction-building tutorial.

* Updates the client-rpc and flow-state-machines tutorials.

* Updates the oracles tutorial.

* Amended country in X500 names from "UK" to "GB"

* Update FlowCookbook.kt

* Amended cheatsheet. Minor update on contract upgrades tutoraial.

* Added `extraCordappPackagesToScan` to node driver.

* Changes to match new function signature.

* Update to reflect change in location of cash contract name.

* CORDA-670: Correct scanned packages in network visualiser (#1763)

* Add CorDapp dependency of IRS to network visualiser

* Set CorDapp directories

* Checking out the latest milestone will no longer be required. (#1761)

* Updated documentation indices (#1754)

* Update documentation indices.

* Reference a moveable tag for V1 docs.
Remove redundant warning text.

* Reverted proposed usage of new docs release tag

* Minor: print a deprecation warning when the web server starts. (#1767)

* Release and upgrade notes for V1.0 (#1736)

* Release and upgrade notes for V1.0

* Update changelog.rst

* Update changelog.rst

* Formatting.

* Incorporating review feedback from KB and MN.

* "guarantee" instead of "promise"

* Updated with final review comments from KB and RGB.

* Updated upgrade notes to describe migration from removed CordaPluginRegistry.

* Minor clarification.

* Minor updates following final RGB feedback.

* Kat's further pedantic feedback

* Minor changes following feedback from KB.

* Incorporating review feedback from MH.

* killed 'patent-pending'

* Made the visualiser into a regular JVM module - not a CorDapp. (#1771)

* Docs: more package descriptions and take non-stabilised APIs out of the docs build. (#1775)

* Update corda version tag to 1.0.0

* Updated release notes to fix minor typos (#1779)

Fixed bold type on simplified annotation driven scanning bullet and added bold type to module name bullets

* Fixed drop down.. probably. (#1780)

* fixed formatting for release notes. (#1782)

* Improve API page wording (#1784)

* Removed "unreleased" sections from the release notes and change log.

* Merge remote-tracking branch 'origin/release-V1' into colljos-merge-v1-docs

# Conflicts:
#	build.gradle
#	client/jfx/src/main/kotlin/net/corda/client/jfx/model/NodeMonitorModel.kt
#	client/rpc/src/main/kotlin/net/corda/client/rpc/CordaRPCClient.kt
#	client/rpc/src/main/kotlin/net/corda/client/rpc/PermissionException.kt
#	constants.properties
#	core/src/main/kotlin/net/corda/core/flows/FlowSession.kt
#	core/src/test/kotlin/net/corda/core/contracts/DummyContractV2Tests.kt
#	core/src/test/kotlin/net/corda/core/flows/ContractUpgradeFlowTest.kt
#	docs/source/api-flows.rst
#	docs/source/api-index.rst
#	docs/source/changelog.rst
#	docs/source/example-code/src/main/java/net/corda/docs/java/tutorial/testdsl/CommercialPaperTest.java
#	docs/source/example-code/src/main/kotlin/net/corda/docs/FlowCookbook.kt
#	docs/source/example-code/src/main/kotlin/net/corda/docs/tutorial/contract/TutorialContract.kt
#	docs/source/example-code/src/main/kotlin/net/corda/docs/tutorial/testdsl/TutorialTestDSL.kt
#	docs/source/hello-world-state.rst
#	docs/source/key-concepts-contract-constraints.rst
#	docs/source/serialization.rst
#	docs/source/tut-two-party-flow.rst
#	docs/source/tutorial-tear-offs.rst
#	node-api/src/main/kotlin/net/corda/nodeapi/internal/serialization/CordaClassResolver.kt
#	node-api/src/test/java/net/corda/nodeapi/internal/serialization/ForbiddenLambdaSerializationTests.java
#	node-api/src/test/java/net/corda/nodeapi/internal/serialization/LambdaCheckpointSerializationTest.java
#	node/src/integration-test/kotlin/net/corda/node/services/AttachmentLoadingTests.kt
#	node/src/integration-test/kotlin/net/corda/services/messaging/MQSecurityTest.kt
#	node/src/main/kotlin/net/corda/node/internal/NodeStartup.kt
#	node/src/test/kotlin/net/corda/node/internal/cordapp/CordappLoaderTest.kt
#	node/src/test/kotlin/net/corda/node/services/NotaryChangeTests.kt
#	samples/attachment-demo/src/main/kotlin/net/corda/attachmentdemo/AttachmentDemo.kt
#	samples/trader-demo/src/main/kotlin/net/corda/traderdemo/TraderDemo.kt
#	testing/node-driver/src/integration-test/kotlin/net/corda/testing/FlowStackSnapshotTest.kt
#	testing/node-driver/src/main/kotlin/net/corda/testing/driver/Driver.kt
#	testing/node-driver/src/main/kotlin/net/corda/testing/node/MockNode.kt
#	webserver/src/main/kotlin/net/corda/webserver/internal/NodeWebServer.kt
This commit is contained in:
josecoll 2017-10-03 17:32:11 +01:00 committed by GitHub
parent ab7507db69
commit dd3d8ba626
38 changed files with 980 additions and 128 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@ -88,6 +88,9 @@ docs/virtualenv/
# bft-smart
**/config/currentView
# Node Explorer
/tools/explorer/conf/CordaExplorer.properties
# vim
*.swp
*.swn

2
build.gradle
View File

@ -40,7 +40,7 @@ buildscript {
ext.jopt_simple_version = '5.0.2'
ext.jansi_version = '1.14'
ext.hibernate_version = '5.2.6.Final'
ext.h2_version = '1.4.194'
ext.h2_version = '1.4.194' // Update docs if renamed or removed.
ext.rxjava_version = '1.2.4'
ext.dokka_version = '0.9.14'
ext.eddsa_version = '0.2.0'

5
client/jfx/src/main/kotlin/net/corda/client/jfx/model/NetworkIdentityModel.kt
View File

@ -42,7 +42,10 @@ class NetworkIdentityModel {
}.map { it?.party }.filterNotNull()
val notaryNodes: ObservableList<NodeInfo> = notaries.map { rpcProxy.value?.nodeInfoFromParty(it) }.filterNotNull()
val parties: ObservableList<NodeInfo> = networkIdentities.filtered { it.legalIdentities.all { it !in notaries } }
val parties: ObservableList<NodeInfo> = networkIdentities
.filtered { it.legalIdentities.all { it !in notaries } }
// TODO: REMOVE THIS HACK WHEN NETWORK MAP REDESIGN WORK IS COMPLETED.
.filtered { it.legalIdentities.all { it.name.organisation != "Network Map Service" } }
val myIdentity = rpcProxy.map { it?.nodeInfo()?.legalIdentitiesAndCerts?.first()?.party }
fun partyFromPublicKey(publicKey: PublicKey): ObservableValue<NodeInfo?> = identityCache[publicKey]

4
client/jfx/src/main/kotlin/net/corda/client/jfx/model/NodeMonitorModel.kt
View File

@ -57,8 +57,8 @@ class NodeMonitorModel {
*/
fun register(nodeHostAndPort: NetworkHostAndPort, username: String, password: String) {
val client = CordaRPCClient(
hostAndPort = nodeHostAndPort,
configuration = CordaRPCClientConfiguration.DEFAULT.copy(
nodeHostAndPort,
CordaRPCClientConfiguration.DEFAULT.copy(
connectionMaxRetryInterval = 10.seconds
)
)

4
core/src/main/kotlin/net/corda/core/flows/FlowLogic.kt
View File

@ -55,6 +55,10 @@ abstract class FlowLogic<out T> {
*/
val serviceHub: ServiceHub get() = stateMachine.serviceHub
/**
* Creates a communication session with [party]. Subsequently you may send/receive using this session object. Note
* that this function does not communicate in itself, the counter-flow will be kicked off by the first send/receive.
*/
@Suspendable
fun initiateFlow(party: Party): FlowSession = stateMachine.initiateFlow(party, flowUsedForSessions)

4
core/src/main/kotlin/net/corda/core/flows/FlowSession.kt
View File

@ -6,8 +6,8 @@ import net.corda.core.utilities.UntrustworthyData
/**
*
* A [FlowSession] is a handle on a communication sequence between two flows. It is used to send and receive messages
* between flows.
* A [FlowSession] is a handle on a communication sequence between two paired flows, possibly running on separate nodes.
* It is used to send and receive messages between the flows as well as to query information about the counter-flow.
*
* There are two ways of obtaining such a session:
*

1
docs/source/_static/versions
View File

@ -8,5 +8,6 @@
"https://docs.corda.net/releases/release-M12.1": "M12.1",
"https://docs.corda.net/releases/release-M13.0": "M13.0",
"https://docs.corda.net/releases/release-M14.0": "M14.0",
"https://docs.corda.net/releases/release-V1.0": "V1.0",
"https://docs.corda.net/head/": "Master"
}

14
docs/source/api-core-types.rst
View File

@ -20,20 +20,6 @@ Any object that needs to be identified by its hash should implement the ``NamedB
``SecureHash`` is a sealed class that only defines a single subclass, ``SecureHash.SHA256``. There are utility methods
to create and parse ``SecureHash.SHA256`` objects.
Party
-----
Identities on the network are represented by ``AbstractParty``. There are two types of ``AbstractParty``:
* ``Party``, identified by a ``PublicKey`` and a ``CordaX500Name``
* ``AnonymousParty``, identified by a ``PublicKey``
For example, in a transaction sent to your node as part of a chain of custody it is important you can convince yourself
of the transaction's validity, but equally important that you don't learn anything about who was involved in that
transaction. In these cases ``AnonymousParty`` should be used. In contrast, for internal processing where extended
details of a party are required, the ``Party`` class should be used. The identity service provides functionality for
resolving anonymous parties to full parties.
CompositeKey
------------
Corda supports scenarios where more than one signature is required to authorise a state object transition. For example:

93
docs/source/api-flows.rst
View File

@ -377,10 +377,11 @@ as it likes, and each party can invoke a different response flow:
:end-before: DOCEND 6
:dedent: 12
.. warning:: If you initiate several counter flows from the same ``@InitiatingFlow`` flow then on the receiving side you
must be prepared to be initiated by any of the corresponding ``initiateFlow()`` calls! A good way of handling this
ambiguity is to send as a first message a "role" message to the initiated flow, indicating which part of the
initiating flow the rest of the counter-flow should conform to.
.. warning:: If you initiate several flows from the same ``@InitiatingFlow`` flow then on the receiving side you must be
prepared to be initiated by any of the corresponding ``initiateFlow()`` calls! A good way of handling this ambiguity
is to send as a first message a "role" message to the initiated flow, indicating which part of the initiating flow
the rest of the counter-flow should conform to. For example send an enum, and on the other side start with a switch
statement.
SendAndReceive
~~~~~~~~~~~~~~
@ -426,20 +427,52 @@ Our side of the flow must mirror these calls. We could do this as follows:
:end-before: DOCEND 8
:dedent: 12
Porting from the old Party-based API
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why sessions?
^^^^^^^^^^^^^
Before ``FlowSession`` s were introduced the send/receive API looked a bit different. They were functions on
``FlowLogic`` and took the address ``Party`` as argument. The platform internally maintained a mapping from ``Party`` to
session, hiding sessions from the user completely.
However we realised that this could introduce subtle bugs and security issues where sends meant for different sessions
may end up in the same session if the target ``Party`` happens to be the same.
Although this is a convenient API it introduces subtle issues where a message that was originally meant for a specific
session may end up in another.
Therefore the session concept is now exposed through ``FlowSession`` which disambiguates which communication sequence a
message is intended for.
Consider the following contrived example using the old ``Party`` based API:
In the old API the first ``send`` or ``receive`` to a ``Party`` was the one kicking off the counterflow. This is now
.. container:: codeset
.. literalinclude:: ../../docs/source/example-code/src/main/kotlin/net/corda/docs/LaunchSpaceshipFlow.kt
:language: kotlin
:start-after: DOCSTART LaunchSpaceshipFlow
:end-before: DOCEND LaunchSpaceshipFlow
The intention of the flows is very clear: LaunchSpaceshipFlow asks the president whether a spaceship should be launched.
It is expecting a boolean reply. The president in return first tells the secretary that they need coffee, which is also
communicated with a boolean. Afterwards the president replies to the launcher that they don't want to launch.
However the above can go horribly wrong when the ``launcher`` happens to be the same party ``getSecretary`` returns. In
this case the boolean meant for the secretary will be received by the launcher!
This indicates that ``Party`` is not a good identifier for the communication sequence, and indeed the ``Party`` based
API may introduce ways for an attacker to fish for information and even trigger unintended control flow like in the
above case.
Hence we introduced ``FlowSession``, which identifies the communication sequence. With ``FlowSession`` s the above set
of flows would look like this:
.. container:: codeset
.. literalinclude:: ../../docs/source/example-code/src/main/kotlin/net/corda/docs/LaunchSpaceshipFlow.kt
:language: kotlin
:start-after: DOCSTART LaunchSpaceshipFlowCorrect
:end-before: DOCEND LaunchSpaceshipFlowCorrect
Note how the president is now explicit about which session it wants to send to.
Porting from the old Party-based API
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In the old API the first ``send`` or ``receive`` to a ``Party`` was the one kicking off the counter-flow. This is now
explicit in the ``initiateFlow`` function call. To port existing code:
.. container:: codeset
@ -460,24 +493,28 @@ explicit in the ``initiateFlow`` function call. To port existing code:
Subflows
--------
Subflows are pieces of reusable flows that may be run by calling ``FlowLogic.subFlow``.
Subflows are pieces of reusable flows that may be run by calling ``FlowLogic.subFlow``. There are two broad categories
of subflows, inlined and initiating ones. The main difference lies in the counter-flow's starting method, initiating
ones initiate counter-flows automatically, while inlined ones expect some parent counter-flow to run the inlined
counter-part.
Inlined subflows
^^^^^^^^^^^^^^^^
Inlined subflows inherit their calling flow's type when initiating a new session with a counterparty. For example say
Inlined subflows inherit their calling flow's type when initiating a new session with a counterparty. For example, say
we have flow A calling an inlined subflow B, which in turn initiates a session with a party. The FlowLogic type used to
determine which counterflow should be kicked off will be A, not B. Note that this means that the other side of this
session must therefore be called explicitly in the kicked off flow as well.
determine which counter-flow should be kicked off will be A, not B. Note that this means that the other side of this
inlined flow must therefore be implemented explicitly in the kicked off flow as well. This may be done by calling a
matching inlined counter-flow, or by implementing the other side explicitly in the kicked off parent flow.
An example of such a flow is ``CollectSignaturesFlow``. It has a counter-flow ``SignTransactionFlow`` that isn't
annotated with ``InitiatedBy``. This is because both of these flows are inlined, the kick-off relationship will be
annotated with ``InitiatedBy``. This is because both of these flows are inlined; the kick-off relationship will be
defined by the parent flows calling ``CollectSignaturesFlow`` and ``SignTransactionFlow``.
In the code inlined subflows appear as regular ``FlowLogic`` instances, `without` either of the ``@InitiatingFlow`` or
``@InitiatedBy`` annotation.
.. note:: Inlined flows aren't versioned, they inherit their parent flow's version.
.. note:: Inlined flows aren't versioned; they inherit their parent flow's version.
Initiating subflows
^^^^^^^^^^^^^^^^^^^
@ -493,7 +530,7 @@ Core initiating subflows
^^^^^^^^^^^^^^^^^^^^^^^^
Corda-provided initiating subflows are a little different to standard ones as they are versioned together with the
platform, and their initiated counterflows are registered explicitly, so there is no need for the ``InitiatedBy``
platform, and their initiated counter-flows are registered explicitly, so there is no need for the ``InitiatedBy``
annotation.
An example is the ``FinalityFlow``/``FinalityHandler`` flow pair.
@ -504,8 +541,10 @@ Built-in subflows
Corda provides a number of built-in flows that should be used for handling common tasks. The most important are:
* ``CollectSignaturesFlow`` (inlined), which should be used to collect a transaction's required signatures
* ``FinalityFlow`` (initiating), which should be used to notarise and record a transaction
* ``SendTransactionFlow`` (inlined), which should be used to send a signed transaction if it needed to be resolved on the other side.
* ``FinalityFlow`` (initiating), which should be used to notarise and record a transaction as well as to broadcast it to
all relevant parties
* ``SendTransactionFlow`` (inlined), which should be used to send a signed transaction if it needed to be resolved on
the other side.
* ``ReceiveTransactionFlow`` (inlined), which should be used receive a signed transaction
* ``ContractUpgradeFlow`` (initiating), which should be used to change a state's contract
* ``NotaryChangeFlow`` (initiating), which should be used to change a state's notary
@ -641,6 +680,20 @@ We can also send and receive a ``StateAndRef`` dependency chain and automaticall
:end-before: DOCEND 14
:dedent: 12
Why inlined subflows?
^^^^^^^^^^^^^^^^^^^^^
Inlined subflows provide a way to share commonly used flow code `while forcing users to create a parent flow`. Take for
example ``CollectSignaturesFlow``. Say we made it an initiating flow that automatically kicks off
``SignTransactionFlow`` that signs the transaction. This would mean malicious nodes can just send any old transaction to
us using ``CollectSignaturesFlow`` and we would automatically sign it!
By making this pair of flows inlined we provide control to the user over whether to sign the transaction or not by
forcing them to nest it in their own parent flows.
In general if you're writing a subflow the decision of whether you should make it initiating should depend on whether
the counter-flow needs broader context to achieve its goal.
FlowException
-------------
Suppose a node throws an exception while running a flow. Any counterparty flows waiting for a message from the node

129
docs/source/api-identity.rst Normal file
View File

@ -0,0 +1,129 @@
API: Identity
=============
.. note:: Before reading this page, you should be familiar with the key concepts of :doc:`key-concepts-identity`.
.. contents::
Party
-----
Identities on the network are represented by ``AbstractParty``. There are two types of ``AbstractParty``:
* ``Party``, identified by a ``PublicKey`` and a ``CordaX500Name``
* ``AnonymousParty``, identified by a ``PublicKey``
For example, in a transaction sent to your node as part of a chain of custody it is important you can convince yourself
of the transaction's validity, but equally important that you don't learn anything about who was involved in that
transaction. In these cases ``AnonymousParty`` should be used by flows constructing when transaction states and commands.
In contrast, for internal processing where extended details of a party are required, the ``Party`` class should be used
instead. The identity service provides functionality for flows to resolve anonymous parties to full parties, dependent
on the anonymous party's identity having been registered with the node earlier (typically this is handled by
``SwapIdentitiesFlow`` or ``IdentitySyncFlow``, discussed below).
Party names are held within the ``CordaX500Name`` data class, which enforces the structure of names within Corda, as
well as ensuring a consistent rendering of the names in plain text.
The support for both Party and AnonymousParty classes in Corda enables sophisticated selective disclosure of identity
information. For example, it is possible to construct a Transaction using an AnonymousParty, so nobody can learn of your
involvement by inspection of the transaction, yet prove to specific counterparts that this AnonymousParty actually is
owned by your well known identity. This disclosure is achieved through the use of the PartyAndCertificate data class
which can be propagated to those who need to know, and contains the Party's X.509 certificate path to provide proof of
ownership by a well known identity.
The PartyAndCertificate class is also used in the network map service to represent well known identities, in which
scenario the certificate path proves its issuance by the Doorman service.
Confidential Identities
-----------------------
Confidential identities are key pairs where the corresponding X.509 certificate (and path) are not made public, so that parties who
are not involved in the transaction cannot identify its participants. They are owned by a well known identity, which
must sign the X.509 certificate. Before constructing a new transaction the involved parties must generate and send new
confidential identities to each other, a process which is managed using ``SwapIdentitiesFlow`` (discussed below). The
public keys of these confidential identities are then used when generating output states and commands for the transaction.
Where using outputs from a previous transaction in a new transaction, counterparties may need to know who the involved
parties are. One example is in ``TwoPartyTradeFlow`` which delegates to ``CollectSignaturesFlow`` to gather certificates
from both parties. ``CollectSignaturesFlow`` requires that a confidential identity of the initiating node has signed
the transaction, and verifying this requires the receiving node has a copy of the confidential identity for the input
state. ``IdentitySyncFlow`` can be used to synchronize the confidential identities we have the certificate paths for, in
a single transaction, to another node.
.. note:: ``CollectSignaturesFlow`` requires that the initiating node has signed the transaction, and as such all nodes
providing signatures must recognise the signing key used by the initiating node as being either its well known identity
or a confidential identity they have the certificate for.
Swap identities flow
~~~~~~~~~~~~~~~~~~~~
``SwapIdentitiesFlow`` takes the party to swap identities with in its constructor (the counterparty), and is typically run as a subflow of
another flow. It returns a mapping from well known identities of the calling flow and our counterparty to the new
confidential identities; in future this will be extended to handle swapping identities with multiple parties.
You can see an example of it being used in ``TwoPartyDealFlow.kt``:
.. container:: codeset
.. literalinclude:: ../../finance/src/main/kotlin/net/corda/finance/flows/TwoPartyDealFlow.kt
:language: kotlin
:start-after: DOCSTART 2
:end-before: DOCEND 2
The swap identities flow goes through the following key steps:
1. Generate a nonce value to form a challenge to the other nodes.
2. Send nonce value to all counterparties, and receive their nonce values.
3. Generate a new confidential identity from our well known identity.
4. Create a data blob containing the new confidential identity (public key, name and X.509 certificate path),
and the hash of the nonce values.
5. Sign the resulting data blob with the confidential identity's private key.
6. Send the confidential identity and data blob signature to all counterparties, while receiving theirs.
7. Verify the signatures to ensure that identities were generated by the involved set of parties.
8. Verify the confidential identities are owned by the expected well known identities.
9. Store the confidential identities and return them to the calling flow.
This ensures not only that the confidential identity X.509 certificates are signed by the correct well known identities,
but also that the confidential identity private key is held by the counterparty, and that a party cannot claim ownership
another party's confidential identities belong to its well known identity.
Identity synchronization flow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When constructing a transaction whose input states reference confidential identities, it is common for other signing
entities (counterparties) to require to know which well known identities those confidential identities map to. The
``IdentitySyncFlow`` handles this process, and you can see an example of its use in ``TwoPartyTradeFlow.kt``:
.. container:: codeset
.. literalinclude:: ../../finance/src/main/kotlin/net/corda/finance/flows/TwoPartyTradeFlow.kt
:language: kotlin
:start-after: DOCSTART 6
:end-before: DOCEND 6
The identity synchronization flow goes through the following key steps:
1. Extract participant identities from all input and output states and remove any well known identities. Required signers
on commands are currently ignored as they are presumed to be included in the participants on states, or to be well
known identities of services (such as an oracle service).
2. For each counterparty node, send a list of the public keys of the confidential identities, and receive back a list
of those the counterparty needs the certificate path for.
3. Verify the requested list of identities contains only confidential identities in the offered list, and abort otherwise.
4. Send the requested confidential identities as ``PartyAndCertificate`` instances to the counterparty.
.. note:: ``IdentitySyncFlow`` works on a push basis. The initiating node can only send confidential identities it has
the X.509 certificates for, and the remote nodes can only request confidential identities being offered (are
referenced in the transaction passed to the initiating flow). There is no standard flow for nodes to collect
confidential identities before assembling a transaction, and this is left for individual flows to manage if required.
``IdentitySyncFlow`` will serve all confidential identities in the provided transaction, irrespective of well known
identity. This is important for more complex transaction cases with 3+ parties, for example:
* Alice is building the transaction, and provides some input state *x* owned by a confidential identity of Alice
* Bob provides some input state *y* owned by a confidential identity of Bob
* Charlie provides some input state *z* owned by a confidential identity of Charlie
Alice may know all of the confidential identities ahead of time, but Bob not know about Charlie's and vice-versa.
The assembled transaction therefore has three input states *x*, *y* and *z*, for which only Alice possesses certificates
for all confidential identities. ``IdentitySyncFlow`` must send not just Alice's confidential identity but also any other
identities in the transaction to the Bob and Charlie.

1
docs/source/api-index.rst
View File

@ -12,6 +12,7 @@ This section describes the APIs that are available for the development of CorDap
api-vault-query
api-transactions
api-flows
api-identity
api-service-hub
api-rpc
api-core-types

80
docs/source/changelog.rst
View File

@ -19,6 +19,8 @@ UNRELEASED
either annotated with the @CordaSerializable annotation or explicitly whitelisted then a NotSerializableException is
thrown.
.. _changelog_v1:
Release 1.0
-----------
@ -27,36 +29,45 @@ Release 1.0
* Java 8 lambdas now work property with Kryo during check-pointing.
* Java 8 serializable lambdas now work property with Kryo during check-pointing.
* String constants have been marked as ``const`` type in Kotlin, eliminating cases where functions of the form
``get<constant name>()`` were created for the Java API. These can now be referenced by their name directly.
* ``FlowLogic`` communication has been extensively rewritten to use functions on ``FlowSession`` as the base for communication
between nodes.
* Calls to ``send()``, ``receive()`` and ``sendAndReceive()`` on FlowLogic should be replaced with calls
to the function of the same name on ``FlowSession``. Note that the replacement functions do not take in a destination
parameter, as this is defined in the session.
* Initiated flows now take in a ``FlowSession`` instead of ``Party`` in their constructor. If you need to access the
counterparty identity, it is in the ``counterparty`` property of the flow session.
* Added X509EdDSAEngine to intercept and rewrite EdDSA public keys wrapped in X509Key instances. This corrects an issue
with verifying certificate paths loaded from a Java Keystore where they contain EdDSA keys.
* generateSpend() now creates a new confidential identity for the change address rather than using the identity of the
input state owner.
* Confidential identities are now complete:
* The identity negotiation flow is now called ``SwapIdentitiesFlow``, renamed from ``TransactionKeyFlow``.
* generateSpend() now creates a new confidential identity for the change address rather than using the identity of the
input state owner.
* Please see the documentation :doc:`key-concepts-identity` and :doc:`api-identity` for more details.
* Remove the legacy web front end from the SIMM demo.
* ``NodeInfo`` and ``NetworkMapCache`` changes:
* Removed ``NodeInfo::legalIdentity`` in preparation for handling of multiple identities. We left list of ``NodeInfo::legalIdentitiesAndCerts``,
the first identity still plays a special role of main node identity.
the first identity still plays a special role of main node identity.
* We no longer support advertising services in network map. Removed ``NodeInfo::advertisedServices``, ``serviceIdentities``
and ``notaryIdentity``.
and ``notaryIdentity``.
* Removed service methods from ``NetworkMapCache``: ``partyNodes``, ``networkMapNodes``, ``notaryNodes``, ``regulatorNodes``,
``getNodesWithService``, ``getPeersWithService``, ``getRecommended``, ``getNodesByAdvertisedServiceIdentityKey``, ``getAnyNotary``,
``notaryNode``, ``getAnyServiceOfType``. To get all known ``NodeInfo``s call ``allNodes``.
``getNodesWithService``, ``getPeersWithService``, ``getRecommended``, ``getNodesByAdvertisedServiceIdentityKey``, ``getAnyNotary``,
``notaryNode``, ``getAnyServiceOfType``. To get all known ``NodeInfo``'s call ``allNodes``.
* In preparation for ``NetworkMapService`` redesign and distributing notaries through ``NetworkParameters`` we added
``NetworkMapCache::notaryIdentities`` list to enable to lookup for notary parties known to the network. Related ``CordaRPCOps::notaryIdentities``
was introduced. Other special nodes parties like Oracles or Regulators need to be specified directly in CorDapp or flow.
``NetworkMapCache::notaryIdentities`` list to enable to lookup for notary parties known to the network. Related ``CordaRPCOps::notaryIdentities``
was introduced. Other special nodes parties like Oracles or Regulators need to be specified directly in CorDapp or flow.
* Moved ``ServiceType`` and ``ServiceInfo`` to ``net.corda.nodeapi`` package as services are only required on node startup.
* Adding enum support to the class carpenter
@ -71,7 +82,7 @@ Release 1.0
* About half of the code in test-utils has been moved to a new module ``node-driver``,
and the test scope modules are now located in a ``testing`` directory.
* CordaPluginRegistry has been renamed to SerializationWhitelist and moved to the net.corda.core.serialization
* ``CordaPluginRegistry`` has been renamed to ``SerializationWhitelist`` and moved to the ``net.corda.core.serialization``
package. The API for whitelisting types that can't be annotated was slightly simplified. This class used to contain
many things, but as we switched to annotations and classpath scanning over time it hollowed out until this was
the only functionality left. You also need to rename your services resource file to the new class name.
@ -93,10 +104,14 @@ Release 1.0
* Vault Query fix: filter by multiple issuer names in ``FungibleAssetQueryCriteria``
* Following deprecated methods have been removed:
* In ``DataFeed``
* ``first`` and ``current``, replaced by ``snapshot``
* ``second`` and ``future``, replaced by ``updates``
* In ``CordaRPCOps``
* ``stateMachinesAndUpdates``, replaced by ``stateMachinesFeed``
* ``verifiedTransactions``, replaced by ``verifiedTransactionsFeed``
* ``stateMachineRecordedTransactionMapping``, replaced by ``stateMachineRecordedTransactionMappingFeed``
@ -106,13 +121,12 @@ Release 1.0
``ResolveTransactionsFlow`` has been made internal. Instead merge the receipt of the ``SignedTransaction`` and the subsequent
sub-flow call to ``ResolveTransactionsFlow`` with a single call to ``ReceiveTransactionFlow``. The flow running on the counterparty
must use ``SendTransactionFlow`` at the correct place. There is also ``ReceiveStateAndRefFlow`` and ``SendStateAndRefFlow`` for
dealing with ``StateAndRef``s.
dealing with ``StateAndRef``'s.
* Vault query soft locking enhancements and deprecations
* removed original ``VaultService`` ``softLockedStates` query mechanism.
* introduced improved ``SoftLockingCondition`` filterable attribute in ``VaultQueryCriteria`` to enable specification
of different soft locking retrieval behaviours (exclusive of soft locked states, soft locked states only, specified
by set of lock ids)
* introduced improved ``SoftLockingCondition`` filterable attribute in ``VaultQueryCriteria`` to enable specification of different soft locking retrieval behaviours (exclusive of soft locked states, soft locked states only, specified by set of lock ids)
* Trader demo now issues cash and commercial paper directly from the bank node, rather than the seller node self-issuing
commercial paper but labelling it as if issued by the bank.
@ -122,7 +136,7 @@ Release 1.0
If you specifically need well known identities, use the network map, which is the authoritative source of current well
known identities.
* Currency-related API in ``net.corda.core.contracts.ContractsDSL`` has moved to ```net.corda.finance.CurrencyUtils`.
* Currency-related API in ``net.corda.core.contracts.ContractsDSL`` has moved to ```net.corda.finance.CurrencyUtils``.
* Remove `IssuerFlow` as it allowed nodes to request arbitrary amounts of cash to be issued from any remote node. Use
`CashIssueFlow` instead.
@ -174,15 +188,16 @@ Release 1.0
* The unused ``MetaData`` and ``SignatureType`` in ``crypto`` package have been removed.
* The ``class TransactionSignature(bytes: ByteArray, val by: PublicKey, val signatureMetadata: SignatureMetadata): DigitalSignature(bytes)``
class is now utilised Vs the old ``DigitalSignature.WithKey`` for Corda transaction signatures. Practically, it takes
the ``signatureMetadata`` as an extra input, in order to support signing both the transaction and the extra metadata.
* The ``class TransactionSignature(bytes: ByteArray, val by: PublicKey, val signatureMetadata:``
``SignatureMetadata): DigitalSignature(bytes)`` class is now utilised Vs the old ``DigitalSignature.WithKey`` for
Corda transaction signatures. Practically, it takes the ``signatureMetadata`` as an extra input, in order to support
signing both the transaction and the extra metadata.
* To reflect changes in the signing process, the ``Crypto`` object is now equipped with the:
``fun doSign(keyPair: KeyPair, signableData: SignableData): TransactionSignature`` and
``fun doVerify(txId: SecureHash, transactionSignature: TransactionSignature): Boolean`` functions.
* ``SerializationCustomization.addToWhitelist()` now accepts multiple classes via varargs.
* ``SerializationCustomization.addToWhitelist()`` now accepts multiple classes via varargs.
* Two functions to easily sign a ``FilteredTransaction`` have been added to ``ServiceHub``:
``createSignature(filteredTransaction: FilteredTransaction, publicKey: PublicKey)`` and
@ -212,8 +227,8 @@ Release 1.0
* All of the ``serializedHash`` and ``computeNonce`` functions have been removed from ``MerkleTransaction``.
The ``serializedHash(x: T)`` and ``computeNonce`` were moved to ``CryptoUtils``.
* Two overloaded methods ``componentHash(opaqueBytes: OpaqueBytes, privacySalt: PrivacySalt, componentGroupIndex: Int,
internalIndex: Int): SecureHash`` and ``componentHash(nonce: SecureHash, opaqueBytes: OpaqueBytes): SecureHash`` have
* Two overloaded methods ``componentHash(opaqueBytes: OpaqueBytes, privacySalt: PrivacySalt,``
``componentGroupIndex: Int, internalIndex: Int): SecureHash`` and ``componentHash(nonce: SecureHash, opaqueBytes: OpaqueBytes): SecureHash`` have
been added to ``CryptoUtils``. Similarly to ``computeNonce``, they internally use SHA256d for nonce and leaf hash
computations.
@ -224,24 +239,25 @@ Release 1.0
``FilteredTransaction`` now extend ``TraversableTransaction``.
* Two classes, ``ComponentGroup(open val groupIndex: Int, open val components: List<OpaqueBytes>)`` and
``FilteredComponentGroup(override val groupIndex: Int, override val components: List<OpaqueBytes>,
val nonces: List<SecureHash>, val partialMerkleTree: PartialMerkleTree): ComponentGroup(groupIndex, components)``
have been added, which are properties of the ``WireTransaction`` and ``FilteredTransaction``, respectively.
``FilteredComponentGroup(override val groupIndex: Int, override val components:``
``List<OpaqueBytes>, val nonces: List<SecureHash>, val partialMerkleTree:``
``PartialMerkleTree): ComponentGroup(groupIndex, components)`` have been added, which are properties
of the ``WireTransaction`` and ``FilteredTransaction``, respectively.
* ``checkAllComponentsVisible(componentGroupEnum: ComponentGroupEnum)`` is added to ``FilteredTransaction``, a new
function to check if all components are visible in a specific component-group.
* To allow for backwards compatibility, ``WireTransaction`` and ``FilteredTransaction`` have new fields and
constructors: ``WireTransaction(componentGroups: List<ComponentGroup>, privacySalt: PrivacySalt = PrivacySalt())``,
``FilteredTransaction private constructor(id: SecureHash,filteredComponentGroups: List<FilteredComponentGroup>,
groupHashes: List<SecureHash>``. ``FilteredTransaction`` is still built via
``buildFilteredTransaction(wtx: WireTransaction, filtering: Predicate<Any>).
``FilteredTransaction private constructor(id: SecureHash,filteredComponentGroups:``
``List<FilteredComponentGroup>, groupHashes: List<SecureHash>``. ``FilteredTransaction`` is still built via
``buildFilteredTransaction(wtx: WireTransaction, filtering: Predicate<Any>)``.
* ``FilteredLeaves`` class have been removed and as a result we can directly call the components from
``FilteredTransaction``, such as ``ftx.inputs`` Vs the old ``ftx.filteredLeaves.inputs``.
* A new ``ComponentGroupEnum`` is added with the following enum items: ``INPUTS_GROUP``, ``OUTPUTS_GROUP``,
``COMMANDS_GROUP``, ``ATTACHMENTS_GROUP``, ``NOTARY_GROUP``, ``TIMEWINDOW_GROUP``.
``COMMANDS_GROUP``, ``ATTACHMENTS_GROUP``, ``NOTARY_GROUP``, ``TIMEWINDOW_GROUP``.
* ``ContractUpgradeFlow.Initiator`` has been renamed to ``ContractUpgradeFlow.Initiate``
@ -250,6 +266,8 @@ Release 1.0
* Current implementation of SSL in ``CordaRPCClient`` has been removed until we have a better solution which doesn't rely
on the node's keystore.
.. _changelog_m14:
Milestone 14
------------
@ -343,6 +361,8 @@ Milestone 14
* Added JPA ``AbstractPartyConverter`` to ensure identity schema attributes are persisted securely according to type
(well known party, resolvable anonymous party, completely anonymous party).
.. _changelog_m13:
Milestone 13
------------
@ -422,8 +442,10 @@ support for more currencies to the DemoBench and Explorer tools.
* Upgraded BouncyCastle to v1.57.
* Upgraded Requery to v1.3.1.
Milestone 12
------------
.. _changelog_m12:
Milestone 12 (First Public Beta)
--------------------------------
* Quite a few changes have been made to the flow API which should make things simpler when writing CorDapps:

10
docs/source/deploying-a-node.rst
View File

@ -61,6 +61,14 @@ one node as running the network map service, by putting their name in the ``netw
.. warning:: When adding nodes, make sure that there are no port clashes!
If your CorDapp is written in Java, you should also add the following Gradle snippet so that you can pass named arguments to your flows via the Corda shell:
.. sourcecode:: groovy
tasks.withType(JavaCompile) {
options.compilerArgs << "-parameters"
}
Any CorDapps defined in the project's source folders are also automatically registered with all the nodes defined in
``deployNodes``, even if the CorDapps are not listed in each node's ``cordapps`` entry.
@ -86,4 +94,4 @@ run all the nodes at once. Each node in the ``nodes`` folder has the following s
.. note:: Outside of development environments, do not store your node directories in the build folder.
If you make any changes to your ``deployNodes`` task, you will need to re-run the task to see the changes take effect.
If you make any changes to your ``deployNodes`` task, you will need to re-run the task to see the changes take effect.

3
docs/source/example-code/src/main/java/net/corda/docs/FlowCookbookJava.java
View File

@ -267,8 +267,7 @@ public class FlowCookbookJava {
// We then need to pair our output state with a contract.
// DOCSTART 47
String contractName = "net.corda.testing.contracts.DummyContract";
StateAndContract ourOutput = new StateAndContract(ourOutputState, contractName);
StateAndContract ourOutput = new StateAndContract(ourOutputState, DummyContract.PROGRAM_ID);
// DOCEND 47
// Commands pair a ``CommandData`` instance with a list of

3
docs/source/example-code/src/main/kotlin/net/corda/docs/FlowCookbook.kt
View File

@ -255,8 +255,7 @@ class InitiatorFlow(val arg1: Boolean, val arg2: Int, private val counterparty:
// We then need to pair our output state with a contract.
// DOCSTART 47
val contractName: String = "net.corda.testing.contracts.DummyContract"
val ourOutput: StateAndContract = StateAndContract(ourOutputState, contractName)
val ourOutput: StateAndContract = StateAndContract(ourOutputState, DummyContract.PROGRAM_ID)
// DOCEND 47
// Commands pair a ``CommandData`` instance with a list of

99
docs/source/example-code/src/main/kotlin/net/corda/docs/LaunchSpaceshipFlow.kt Normal file
View File

@ -0,0 +1,99 @@
package net.corda.docs
import co.paralleluniverse.fibers.Suspendable
import net.corda.core.flows.FlowLogic
import net.corda.core.flows.FlowSession
import net.corda.core.flows.InitiatedBy
import net.corda.core.flows.InitiatingFlow
import net.corda.core.identity.Party
import net.corda.core.utilities.unwrap
// DOCSTART LaunchSpaceshipFlow
@InitiatingFlow
class LaunchSpaceshipFlow : FlowLogic<Unit>() {
@Suspendable
override fun call() {
val shouldLaunchSpaceship = receive<Boolean>(getPresident()).unwrap { it }
if (shouldLaunchSpaceship) {
launchSpaceship()
}
}
fun launchSpaceship() {
}
fun getPresident(): Party {
TODO()
}
}
@InitiatedBy(LaunchSpaceshipFlow::class)
@InitiatingFlow
class PresidentSpaceshipFlow(val launcher: Party) : FlowLogic<Unit>() {
@Suspendable
override fun call() {
val needCoffee = true
send(getSecretary(), needCoffee)
val shouldLaunchSpaceship = false
send(launcher, shouldLaunchSpaceship)
}
fun getSecretary(): Party {
TODO()
}
}
@InitiatedBy(PresidentSpaceshipFlow::class)
class SecretaryFlow(val president: Party) : FlowLogic<Unit>() {
@Suspendable
override fun call() {
// ignore
}
}
// DOCEND LaunchSpaceshipFlow
// DOCSTART LaunchSpaceshipFlowCorrect
@InitiatingFlow
class LaunchSpaceshipFlowCorrect : FlowLogic<Unit>() {
@Suspendable
override fun call() {
val presidentSession = initiateFlow(getPresident())
val shouldLaunchSpaceship = presidentSession.receive<Boolean>().unwrap { it }
if (shouldLaunchSpaceship) {
launchSpaceship()
}
}
fun launchSpaceship() {
}
fun getPresident(): Party {
TODO()
}
}
@InitiatedBy(LaunchSpaceshipFlowCorrect::class)
@InitiatingFlow
class PresidentSpaceshipFlowCorrect(val launcherSession: FlowSession) : FlowLogic<Unit>() {
@Suspendable
override fun call() {
val needCoffee = true
val secretarySession = initiateFlow(getSecretary())
secretarySession.send(needCoffee)
val shouldLaunchSpaceship = false
launcherSession.send(shouldLaunchSpaceship)
}
fun getSecretary(): Party {
TODO()
}
}
@InitiatedBy(PresidentSpaceshipFlowCorrect::class)
class SecretaryFlowCorrect(val presidentSession: FlowSession) : FlowLogic<Unit>() {
@Suspendable
override fun call() {
// ignore
}
}
// DOCEND LaunchSpaceshipFlowCorrect

3
docs/source/index.rst
View File

@ -1,9 +1,6 @@
Welcome to Corda !
==================
.. warningX:: This build of the docs is from the "|version|" branch, not a milestone release. It may not reflect the
current state of the code. `Read the docs for milestone release M12.1 <https://docs.corda.net/releases/release-M12.1/>`_.
`Corda <https://www.corda.net/>`_ is a blockchain-inspired open source distributed ledger platform. If you’d like a
quick introduction to distributed ledgers and how Corda is different, then watch this short video:

4
docs/source/key-concepts-contract-constraints.rst
View File

@ -15,7 +15,7 @@ A typical constraint is the hash of the CorDapp JAR that contains the contract a
include constraints that require specific signers of the JAR, or both the signer and the hash. Constraints can be
specified when constructing a transaction; if unspecified, an automatic constraint is used.
``TransactionState``s have a ``constraint`` field that represents that state's attachment constraint. When a party
A ``TransactionState`` has a ``constraint`` field that represents that state's attachment constraint. When a party
constructs a ``TransactionState`` without specifying the constraint parameter a default value
(``AutomaticHashConstraint``) is used. This default will be automatically resolved to a specific
``HashAttachmentConstraint`` that contains the hash of the attachment which contains the contract of that
@ -80,7 +80,7 @@ attachment JAR. This allows for trusting of attachments from trusted entities.
Limitations
-----------
``AttachmentConstraint``s are verified by running the ``AttachmentConstraint.isSatisfiedBy`` method. When this is called
An ``AttachmentConstraint`` is verified by running the ``AttachmentConstraint.isSatisfiedBy`` method. When this is called
it is provided only the relevant attachment by the transaction that is verifying it.
Testing

78
docs/source/key-concepts-identity.rst Normal file
View File

@ -0,0 +1,78 @@
Identity
========
.. topic:: Summary
* *Identities in Corda can represent legal identities or service identities*
* *Identities are attested to by X.509 certificate signed by the Doorman or a well known identity*
* *Well known identities are published in the network map*
* *Confidential identities are only shared on a need to know basis*
Identities in Corda can represent:
* Legal identity of an organisation
* Service identity of a network service
Legal identities are used for parties in a transaction, such as the owner of a cash state. Service identities are used
for those providing transaction-related services, such as notary, or oracle. Service identities are distinct to legal
identities so that distributed services can exist on nodes owned by different organisations. Such distributed service
identities are based on ``CompositeKeys``, which describe the valid sets of signers for a signature from the service.
See :doc:`api-core-types` for more technical detail on composite keys.
Identities are either well known or confidential, depending on whether their X.509 certificate (and corresponding
certificate path to a trusted root certificate) is published:
* Well known identities are the generally identifiable public key of a legal entity or service, which makes them
ill-suited to transactions where confidentiality of participants is required. This certificate is published in the
network map service for anyone to access.
* Confidential identities are only published to those who are involved in transactions with the identity. The public
key may be exposed to third parties (for example to the notary service), but distribution of the name and X.509
certificate is limited.
Although there are several elements to the Corda transaction privacy model, including ensuring that transactions are
only shared with those who need to see them, and planned use of Intel SGX, it is important to provide defense in depth against
privacy breaches. Confidential identities are used to ensure that even if a third party gets access to an unencrypted
transaction, they cannot identify the participants without additional information.
Name
----
Identity names are X.500 distinguished names with Corda-specific constraints applied. In order to be compatible with
other implementations (particularly TLS implementations), we constrain the allowed X.500 attribute types to a subset of
the minimum supported set for X.509 certificates (specified in RFC 3280), plus the locality attribute:
* organization (O)
* state (ST)
* locality (L)
* country (C)
* organizational-unit (OU)
* common name (CN) - used only for service identities
The organisation, locality and country attributes are required, while state, organisational-unit and common name are
optional. Attributes cannot be be present more than once in the name. The "country" code is strictly restricted to valid
ISO 3166-1 two letter codes.
Certificates
------------
Nodes must be able to verify the identity of the owner of a public key, which is achieved using X.509 certificates.
When first run a node generates a key pair and submits a certificate signing request to the network Doorman service
(see :doc:`permissioning`).
The Doorman service applies appropriate identity checks then issues a certificate to the node, which is used as the
node certificate authority (CA). From this initial CA certificate the node automatically creates and signs two further
certificates, a TLS certificate and a signing certificate for the node's well known identity. Finally the node
builds a node info record containing its address and well known identity, and registers it with the network map service.
From the signing certificate the organisation can create both well known and confidential identities. Use-cases for
well known identities include clusters of nodes representing a single identity for redundancy purposes, or creating
identities for organisational units.
It is up to organisations to decide which identities they wish to publish in the network map service, making them
well known, and which they wish to keep as confidential identities for privacy reasons (typically to avoid exposing
business sensitive details of transactions). In some cases nodes may also use private network map services in addition
to the main network map service, for operational reasons. Identities registered with such network maps must be
considered well known, and it is never appropriate to store confidential identities in a central directory without
controls applied at the record level to ensure only those who require access to an identity can retrieve its
certificate.
.. TODO: Revisit once design & use cases of private maps is further fleshed out

1
docs/source/key-concepts.rst
View File

@ -13,6 +13,7 @@ This section should be read in order:
key-concepts-ecosystem
key-concepts-ledger
key-concepts-identity
key-concepts-states
key-concepts-contracts
key-concepts-contract-constraints

105
docs/source/release-notes.rst
View File

@ -5,17 +5,112 @@ Here are release notes for each snapshot release from M9 onwards.
Unreleased
----------
Release 1.0
-----------
Corda 1.0 is finally here!
* Flow communications API has been redesigned around session based communication.
This critical step in the Corda journey enables the developer community, clients, and partners to build on Corda with confidence.
Corda 1.0 is the first released version to provide API stability for Corda application (CorDapp) developers.
Corda applications will continue to work against this API with each subsequent release of Corda. The public API for Corda
will only evolve to include new features.
* Merged handling of well known and confidential identities in the identity service.
As of Corda 1.0, the following modules export public APIs for which we guarantee to maintain backwards compatibility,
unless an incompatible change is required for security reasons:
* Remove `IssuerFlow` as it allowed nodes to request arbitrary amounts of cash to be issued from any remote node.
* **core**:
Contains the bulk of the APIs to be used for building CorDapps: contracts, transactions, flows, identity, node services,
cryptographic libraries, and general utility functions.
* Remove the legacy web front end from the SIMM demo. This was a very early sample, and does not reflect the quality of
current Corda code. It may be replaced with a new front end based on a more recent version of AngularJS in a later release.
* **client-rpc**:
An RPC client interface to Corda, for use by both UI facing clients and integration with external systems.
* **client-jackson**:
Utilities and serialisers for working with JSON representations of basic types.
Our extensive testing frameworks will continue to evolve alongside future Corda APIs. As part of our commitment to ease of use and modularity
we have introduced a new test node driver module to encapsulate all test functionality in support of building standalone node integration
tests using our DSL driver.
Please read :doc:`api-index` for complete details.
.. note:: it may be necessary to recompile applications against future versions of the API until we begin offering
`ABI (Application Binary Interface) <https://en.wikipedia.org/wiki/Application_binary_interface>`_ stability as well.
We plan to do this soon after this release of Corda.
Significant changes implemented in reaching Corda API stability include:
* **Flow framework**:
The Flow framework communications API has been redesigned around session based communication with the introduction of a new
``FlowSession`` to encapsulate the counterparty information associated with a flow.
All shipped Corda flows have been upgraded to use the new `FlowSession`. Please read :doc:`api-flows` for complete details.
* **Complete API cleanup**:
Across the board, all our public interfaces have been thoroughly revised and updated to ensure a productive and intuitive developer experience.
Methods and flow naming conventions have been aligned with their semantic use to ease the understanding of CorDapps.
In addition, we provide ever more powerful re-usable flows (such as `CollectSignaturesFlow`) to minimize the boiler-plate code developers need to write.
* **Simplified annotation driven scanning**:
CorDapp configuration has been made simpler through the removal of explicit configuration items in favour of annotations
and classpath scanning. As an example, we have now completely removed the `CordaPluginRegistry` configuration.
Contract definitions are no longer required to explicitly define a legal contract reference hash. In their place an
optional `LegalProseReference` annotation to specify a URI is used.
* **Java usability**:
All code has been updated to enable simple access to static API parameters. Developers no longer need to
call getter methods, and can reference static API variables directly.
In addition to API stability this release encompasses a number of major functional improvements, including:
* **Contract constraints**:
Provides a means with which to enforce a specific implementation of a State's verify method during transaction verification.
When loading an attachment via the attachment classloader, constraints of a transaction state are checked against the
list of attachment hashes provided, and the attachment is rejected if the constraints are not matched.
* **Signature Metadata support**:
Signers now have the ability to add metadata to their digital signatures. Whereas previously a user could only sign the Merkle root of a
transaction, it is now possible for extra information to be attached to a signature, such as a platform version
and the signature-scheme used.
.. image:: resources/signatureMetadata.png
* **Backwards compatibility and improvements to core transaction data structures**:
A new Merkle tree model has been introduced that utilises sub-Merkle trees per component type. Components of the
same type, such as inputs or commands, are grouped together and form their own Merkle tree. Then, the roots of
each group are used as leaves in the top-level Merkle tree. This model enables backwards compatibility, in the
sense that if new component types are added in the future, old clients will still be able to compute the Merkle root
and relay transactions even if they cannot read (deserialise) the new component types. Due to the above,
`FilterTransaction` has been made simpler with a structure closer to `WireTransaction`. This has the effect of making the API
more user friendly and intuitive for both filtered and unfiltered transactions.
* **Enhanced component privacy**:
Corda 1.0 is equipped with a scalable component visibility design based on the above sophisticated
sub-tree model and the introduction of nonces per component. Roughly, an initial base-nonce, the "privacy-salt",
is used to deterministically generate nonces based on the path of each component in the tree. Because each component
is accompanied by a nonce, we protect against brute force attacks, even against low-entropy components. In addition,
a new privacy feature is provided that allows non-validating notaries to ensure they see all inputs and if there was a
`TimeWindow` in the original transaction. Due to the above, a malicious user cannot selectively hide one or more
input states from the notary that would enable her to bypass the double-spending check. The aforementioned
functionality could also be applied to Oracles so as to ensure all of the commands are visible to them.
.. image:: resources/subTreesPrivacy.png
* **Full support for confidential identities**:
This includes rework and improvements to the identity service to handle both `well known` and `confidential` identities.
This work ships in an experimental module in Corda 1.0, called `confidential-identities`. API stabilisation of confidential
identities will occur as we make the integration of this privacy feature into applications even easier for developers.
* **Re-designed network map service**:
The foundations for a completely redesigned network map service have been implemented to enable future increased network
scalability and redundancy, support for multiple notaries, and administration of network compatibility zones and business networks.
Finally, please note that the 1.0 release has not yet been security audited.
We have provided a comprehensive :doc:`upgrade-notes` to ease the transition of migrating CorDapps to Corda 1.0
Upgrading to this release is strongly recommended, and you will be safe in the knowledge that core APIs will no longer break.
Thank you to all contributors for this release!
Milestone 14
------------

2
docs/source/release-process-index.rst
View File

@ -6,4 +6,6 @@ Release process
release-notes
changelog
upgrade-notes
codestyle
testing

BIN
docs/source/resources/signatureMetadata.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs/source/resources/subTreesPrivacy.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 103 KiB

13
docs/source/running-the-demos.rst
View File

@ -143,19 +143,18 @@ To run from the command line in Windows:
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``.
Notary nodes store consumed states in a replicated commit log, which is backed by a H2 database on each node.
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: ``h2/bin/h2.sh`` (or ``h2\bin\h2`` for Windows)
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 ``node`` directory and locate the compile step for ``com.h2database``. Use a client of the same
major version - even if still in beta.
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 node is running,
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``
@ -163,8 +162,8 @@ by using the H2 web console:
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. Note that the raw data is not human-readable,
but we're only interested in the row count for this demo
- 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
.. _bank-of-corda-demo:

8
docs/source/serialization.rst
View File

@ -22,8 +22,8 @@ Classes get onto the whitelist via one of three mechanisms:
#. Via the ``@CordaSerializable`` annotation. In order to whitelist a class, this annotation can be present on the
class itself, on any of the super classes or on any interface implemented by the class or super classes or any
interface extended by an interface implemented by the class or superclasses.
#. By returning the class as part of a plugin via the method ``customizeSerialization``. It's important to return
true from this method if you override it, otherwise the plugin will be excluded. See :doc:`writing-cordapps`.
#. By implementing the ``SerializationWhitelist`` interface and specifying a list of `whitelist` classes.
See :doc:`writing-cordapps`.
#. Via the built in Corda whitelist (see the class ``DefaultWhitelist``). Whilst this is not user editable, it does list
common JDK classes that have been whitelisted for your convenience.
@ -39,8 +39,8 @@ It's reproduced here as an example of both ways you can do this for a couple of
them will automatically be whitelisted. This includes `Contract`, `ContractState` and `CommandData`.
.. warning:: Java 8 Lambda expressions are not serializable except in flow checkpoints, and then not by default. The syntax to declare a serializable Lambda
expression that will work with Corda is ``Runnable r = (Runnable & Serializable) () -> System.out.println("Hello World");``, or
``Callable<String> c = (Callable<String> & Serializable) () -> "Hello World";``.
expression that will work with Corda is ``Runnable r = (Runnable & Serializable) () -> System.out.println("Hello World");``, or
``Callable<String> c = (Callable<String> & Serializable) () -> "Hello World";``.
.. warning:: We will be replacing the use of Kryo in the serialization framework and so additional changes here are
likely.

4
docs/source/shell.rst
View File

@ -99,6 +99,10 @@ Nested objects can be created using curly braces, as in ``{ a: 1, b: 2}``. This
parser is defined for the type you need, for instance, if an API requires a ``Pair<String, Int>``
which could be represented as ``{ first: foo, second: 123 }``.
.. note:: If your CorDapp is written in Java,
named arguments won't work unless you compiled using the ``-parameters`` argument to javac.
See :doc:`deploying-a-node` for how to specify it via Gradle.
The same syntax is also used to specify the parameters for RPCs, accessed via the ``run`` command, like this:
``run registeredFlows``

5
docs/source/troubleshooting.rst
View File

@ -23,6 +23,11 @@ Some of the unit tests, and our serialization framework in general, rely on the
to Java reflection. Make sure you have specified the ``-parameters`` option to the Java compiler. We attempt to set this globally
for gradle and IntelliJ, but it's possible this option is not present in your environment for some reason.
"No matching constructor found: - [arg0: int, arg1: Party]: missing parameter arg0"
***********************************************************************************
Your CorDapp is written in Java and you haven't specified the ``-parameters`` compiler argument. See :doc:`deploying-a-node` for how it can be done using Gradle.
IDEA issues
-----------

24
docs/source/tut-two-party-flow.rst
View File

@ -125,10 +125,10 @@ In a new ``IOUFlowResponder.java`` file in Java, or within the ``App.kt`` file i
...
@InitiatedBy(IOUFlow::class)
class IOUFlowResponder(val otherPartyFlow: FlowSession) : FlowLogic<Unit>() {
class IOUFlowResponder(val otherPartySession: FlowSession) : FlowLogic<Unit>() {
@Suspendable
override fun call() {
val signTransactionFlow = object : SignTransactionFlow(otherPartyFlow, SignTransactionFlow.tracker()) {
val signTransactionFlow = object : SignTransactionFlow(otherPartySession, SignTransactionFlow.tracker()) {
override fun checkTransaction(stx: SignedTransaction) = requireThat {
val output = stx.tx.outputs.single().data
"This must be an IOU transaction." using (output is IOUState)
@ -148,7 +148,11 @@ In a new ``IOUFlowResponder.java`` file in Java, or within the ``App.kt`` file i
import co.paralleluniverse.fibers.Suspendable;
import com.template.state.IOUState;
import net.corda.core.contracts.ContractState;
import net.corda.core.flows.*;
import net.corda.core.flows.FlowException;
import net.corda.core.flows.FlowLogic;
import net.corda.core.flows.FlowSession;
import net.corda.core.flows.InitiatedBy;
import net.corda.core.flows.SignTransactionFlow;
import net.corda.core.transactions.SignedTransaction;
import net.corda.core.utilities.ProgressTracker;
@ -156,18 +160,18 @@ In a new ``IOUFlowResponder.java`` file in Java, or within the ``App.kt`` file i
@InitiatedBy(IOUFlow.class)
public class IOUFlowResponder extends FlowLogic<Void> {
private final FlowSession otherPartyFlow;
private final FlowSession otherPartySession;
public IOUFlowResponder(FlowSession otherPartyFlow) {
this.otherPartyFlow = otherPartyFlow;
public IOUFlowResponder(FlowSession otherPartySession) {
this.otherPartySession = otherPartySession;
}
@Suspendable
@Override
public Void call() throws FlowException {
class signTxFlow extends SignTransactionFlow {
private signTxFlow(FlowSession otherPartyFlow, ProgressTracker progressTracker) {
super(otherPartyFlow, progressTracker);
class SignTxFlow extends SignTransactionFlow {
private signTxFlow(FlowSession otherPartySession, ProgressTracker progressTracker) {
super(otherPartySession, progressTracker);
}
@Override
@ -182,7 +186,7 @@ In a new ``IOUFlowResponder.java`` file in Java, or within the ``App.kt`` file i
}
}
subFlow(new signTxFlow(otherPartyFlow, SignTransactionFlow.Companion.tracker()));
subFlow(new SignTxFlow(otherPartySession, SignTransactionFlow.Companion.tracker()));
return null;
}

9
docs/source/tutorial-tear-offs.rst
View File

@ -49,11 +49,10 @@ The following code snippet is taken from ``NodeInterestRates.kt`` and implements
:end-before: DOCEND 1
:dedent: 8
.. note:: The way the ``FilteredTransaction`` is constructed ensures that after signing of the root hash it's impossible
to add or remove components (leaves). However, it can happen that having transaction with multiple commands one party
reveals only subset of them to the Oracle. As signing is done now over the Merkle root hash, the service signs all
commands of given type, even though it didn't see all of them. In the case however where all of the commands should be
visible to an Oracle, one can type ``ftx.checkAllComponentsVisible(COMMANDS_GROUP)`` before invoking ``ftx.verify``.
.. note:: The way the ``FilteredTransaction`` is constructed ensures that after signing of the root hash it's impossible to add or remove
components (leaves). However, it can happen that having transaction with multiple commands one party reveals only subset of them to the Oracle.
As signing is done now over the Merkle root hash, the service signs all commands of given type, even though it didn't see
all of them. In the case however where all of the commands should be visible to an Oracle, one can type ``ftx.checkAllComponentsVisible(COMMANDS_GROUP)`` before invoking ``ftx.verify``.
``checkAllComponentsVisible`` is using a sophisticated underlying partial Merkle tree check to guarantee that all of
the components of a particular group that existed in the original ``WireTransaction`` are included in the received
``FilteredTransaction``.

349
docs/source/upgrade-notes.rst Normal file
View File

@ -0,0 +1,349 @@
Upgrade notes
=============
These notes provide helpful instructions to upgrade your Corda Applications (CorDapps) from previous versions, starting
from our first public Beta (:ref:`Milestone 12 <changelog_m12>`), to :ref:`V1.0 <changelog_v1>`
General
-------
Always remember to update the version identifiers in your project gradle file:
.. sourcecode:: shell
ext.corda_release_version = '1.0.0'
ext.corda_gradle_plugins_version = '1.0.0'
It may be necessary to update the version of major dependencies:
.. sourcecode:: shell
ext.kotlin_version = '1.1.4'
ext.quasar_version = '0.7.9'
Please consult the relevant release notes of the release in question. If not specified, you may assume the
versions you are currently using are still in force.
We also strongly recommend cross referencing with the :doc:`changelog` to confirm changes.
:ref:`Milestone 14 <changelog_m14>`
------------
Build
^^^^^
* MockNetwork has moved.
A new test driver module dependency needs to be including in your project: `corda-node-driver`. To continue using the
mock network for testing, add the following entry to your gradle build file:
.. sourcecode:: shell
testCompile "net.corda:corda-node-driver:$corda_release_version"
.. note:: you may only need `testCompile "net.corda:corda-test-utils:$corda_release_version"` if not using the Driver DSL.
Configuration
^^^^^^^^^^^^^
* ``CordaPluginRegistry`` has been removed.
The one remaining configuration item ``customizeSerialisation``, which defined a optional whitelist of types for use in
object serialization, has been replaced with the ``SerializationWhitelist`` interface which should be implemented to
define a list of equivalent whitelisted classes.
You will need to rename your services resource file to the new class name:
'resources/META-INF/services/net.corda.core.node.CordaPluginRegistry' becomes 'resources/META-INF/services/net.corda.core.serialization.SerializationWhitelist'
An associated property on ``MockNode`` was renamed from ``testPluginRegistries`` to ``testSerializationWhitelists``.
In general, the ``@CordaSerializable`` annotation is the preferred method for whitelisting as described in :doc:`serialization`
Missing imports
^^^^^^^^^^^^^^^
Use the automatic imports feature of IntelliJ to intelligently resolve the new imports.
* Missing imports for contract types.
CommercialPaper and Cash are now contained within the `finance` module, as are associated helpers functions.
For example:
``import net.corda.contracts.ICommercialPaperState`` becomes ``import net.corda.finance.contracts.ICommercialPaperState``
``import net.corda.contracts.asset.sumCashBy`` becomes ``import net.corda.finance.utils.sumCashBy``
``import net.corda.core.contracts.DOLLARS`` becomes ``import net.corda.finance.DOLLARS``
``import net.corda.core.contracts.issued by`` becomes ``import net.corda.finance.issued by``
``import net.corda.contracts.asset.Cash`` becomes ``import net.corda.finance.contracts.asset.Cash``
* Missing imports for utility functions.
Many common types and helper methods have been consolidated into `net.corda.core.utilities` package.
For example:
``import net.corda.core.crypto.commonName`` becomes ``import net.corda.core.utilities.commonName``
``import net.corda.core.crypto.toBase58String`` becomes ``import net.corda.core.utilities.toBase58String``
``import net.corda.core.getOrThrow`` becomes ``import net.corda.core.utilities.getOrThrow``
* Missing flow imports.
In general all reusable library flows are contained within the **core** API `net.corda.core.flows` package.
Financial domain library flows are contained within the **finance** module `net.corda.finance.flows` package.
Other flows that have moved include:
``import net.corda.core.flows.ResolveTransactionsFlow`` becomes ``import net.corda.core.internal.ResolveTransactionsFlow``
Core data structures
^^^^^^^^^^^^^^^^^^^^
* Missing Contract override.
The contract interace attribute ``legalContractReference`` has been removed, and replaced by
the optional annotation ``@LegalProseReference(uri = "<URI>")``
* Unresolved reference.
Calls to ``AuthenticatedObject`` are replaced by ``CommandWithParties``
* Overrides nothing: ``isRelevant`` in ``LinearState``.
Removed the concept of relevancy from ``LinearState``. A ``ContractState``'s relevance to the vault is now resolved
internally; the vault will process any transaction from a flow which is not derived from transaction resolution verification.
The notion of relevancy is subject to further improvements to enable a developer to control what state the vault thinks
are relevant.
* Calls to ``txBuilder.toLedgerTransaction()`` now requires a serviceHub parameter.
Used by the new Contract Constraints functionality to validate and resolve attachments.
Flow framework
^^^^^^^^^^^^^^
* Flow session deprecations
``FlowLogic`` communication has been upgraded to use functions on ``FlowSession`` as the base for communication
between nodes.
* Calls to ``send()``, ``receive()`` and ``sendAndReceive()`` on FlowLogic should be replaced with calls
to the function of the same name on ``FlowSession``. Note that the replacement functions do not take in a destination
parameter, as this is defined in the session.
* Initiated flows now take in a ``FlowSession`` instead of ``Party`` in their constructor. If you need to access the
counterparty identity, it is in the ``counterparty`` property of the flow session.
See ``FlowSession`` for step by step instructions on porting existing flows to use the new mechanism.
* ``FinalityFlow`` now returns a single ``SignedTransaction``, instead of a ``List<SignedTransaction>``
* ``TransactionKeyFlow`` renamed to ``SwapIdentitiesFlow``
Note that ``SwapIdentitiesFlow`` must be imported from the *confidential-identities** package ''net.corda.confidential''
Node services (ServiceHub)
^^^^^^^^^^^^^^
* VaultQueryService: unresolved reference to `vaultQueryService`.
Replace all references to ``<services>.vaultQueryService`` with ``<services>.vaultService``.
Previously there were two vault APIs. Now there is a single unified API with the same functions: ``VaultService``.
* ``serviceHub.myInfo.legalIdentity`` no longer exists; use the ``ourIdentity`` property of the flow instead.
``FlowLogic.ourIdentity`` has been introduced as a shortcut for retrieving our identity in a flow
* ``getAnyNotary`` is gone - use ``serviceHub.networkMapCache.notaryIdentities[0]`` instead
Note: ongoing work to support multiple notary identities is still in progress.
* ``ServiceHub.networkMapUpdates`` is replaced by ``ServiceHub.networkMapFeed``
* ``ServiceHub.partyFromX500Name`` is replaced by ``ServiceHub.wellKnownPartyFromX500Name``
Note: A "well known" party is one that isn't anonymous and this change was motivated by the confidential identities work.
RPC Client
^^^^^^^^^^
* Missing API methods on `CordaRPCOps` interface.
* Calls to ``verifiedTransactionsFeed()`` and ``verifiedTransactions()`` have been replaced with:
``internalVerifiedTransactionsSnapshot()`` and ``internalVerifiedTransactionsFeed()`` respectively
This is in preparation for the planned integration of Intel SGX™, which will encrypt the transactions feed.
Apps that use this API will not work on encrypted ledgers: you should probably be using the vault query API instead.
* Accessing the `networkMapCache` via ``services.nodeInfo().legalIdentities`` returns a list of identities.
The first element in the list is the Party object referring to a node's single identity.
This is in preparation for allowing a node to host multiple separate identities in future.
Testing
^^^^^^^
Please note that `Clauses` have been removed completely as of V1.0.
We will be revisiting this capability in a future release.
* CorDapps must be explicitly registered in ``MockNetwork`` unit tests.
This is done by calling ``setCordappPackages``, an extension helper function in the ``net.corda.testing`` package,
on the first line of your `@Before` method. This takes a variable number of `String` arguments which should be the
package names of the CorDapps containing the contract verification code you wish to load.
You should unset CorDapp packages in your `@After` method by using ``unsetCordappPackages()`` after `stopNodes()`.
* CorDapps must be explicitly registered in ``DriverDSL`` and ``RPCDriverDSL`` integration tests.
Similarly, you must also register package names of the CorDapps containing the contract verification code you wish to load
using the ``extraCordappPackagesToScan: List<String>`` constructor parameter of the driver DSL.
Finance
^^^^^^^
* `FungibleAsset` interface simplification.
The ``FungibleAsset`` interface has been made simpler. The ``Commands`` grouping interface
that included the ``Move``, ``Issue`` and ``Exit`` interfaces have all been removed, while the ``move`` function has
been renamed to ``withNewOwnerAndAmount`` to be consistent with the ``withNewOwner`` function of the ``OwnableState``.
The following errors may be reported:
* override nothing (FungibleAsset): `move`
* not a subtype of overridden FungibleAsset: `withNewOwner`
* no longer need to override `override val contractHash: SecureHash? = null`
* need to override `override val contract: Class<out Contract>? = null`
Miscellaneous
^^^^^^^^^^^^^
* ``args[0].parseNetworkHostAndPort()`` becomes ``NetworkHostAndPort.parse(args[0])``
* There is no longer a ``NodeInfo.advertisedServices`` property.
The concept of advertised services has been removed from Corda. This is because it was vaguely defined and real world
apps would not typically select random, unknown counterparties from the network map based on self-declared capabilities.
We will introduce a replacement for this functionality, business networks, in a future release.
Gotchas
^^^^^^^
* Beware to use the correct identity when issuing cash:
The 3rd parameter to ``CashIssueFlow`` should be the ** notary ** (not the ** node identity **)
:ref:`Milestone 13 <changelog_m13>`
------------
Core data structures
^^^^^^^^^^^^^^^^^^^^
* `TransactionBuilder` changes.
Use convenience class ``StateAndContract`` instead of ``TransactionBuilder.withItems()`` for passing
around a state and its contract.
* Transaction building DSL changes:
* now need to explicitly pass the ContractClassName into all inputs and outputs.
* `ContractClassName` refers to the class containing the “verifier” method.
* Contract verify method signature change.
``override fun verify(tx: TransactionForContract)`` becomes ``override fun verify(tx: LedgerTransaction)``
* No longer need to override Contract ``contract()`` function.
Node services (ServiceHub)
^^^^^^^^^^^^^
* ServiceHub API method changes.
``services.networkMapUpdates().justSnapshot`` becomes ``services.networkMapSnapshot()``
Configuration
^^^^^^^^^^^^^
* No longer need to define ``CordaPluginRegistry`` and configure ``requiredSchemas``
Custom contract schemas are automatically detected at startup time by class path scanning.
For testing purposes, use the ``SchemaService`` method to register new custom schemas:
eg. ``services.schemaService.registerCustomSchemas(setOf(YoSchemaV1))``
Identity
^^^^^^^^
* Party names are now ``CordaX500Name``, not ``X500Name``
``CordaX500Name`` specifies a predefined set of mandatory (organisation, locality, country)
and optional fields (commonName, organisationUnit, state) with validation checking.
Use new builder CordaX500Name.build(X500Name(target)) or, preferably, explicitly define X500Name parameters using
``CordaX500Name`` constructor.
Testing
^^^^^^^
* MockNetwork Testing.
Mock nodes in node tests are now of type ``StartedNode<MockNode>``, rather than ``MockNode``
MockNetwork now returns a BasketOf(<StartedNode<MockNode>>)
Must call internals on StartedNode to get MockNode:
a = nodes.partyNodes[0].internals
b = nodes.partyNodes[1].internals
* Host and Port change.
Use string helper function ``parseNetworkHostAndPort()`` to parse a URL on startup.
eg. ``val hostAndPort = args[0].parseNetworkHostAndPort()``
* The node driver parameters for starting a node have been reordered, and the node’s name needs to be given as an
``CordaX500Name``, instead of using ``getX509Name``
:ref:`Milestone 12 <changelog_m12>` (First Public Beta)
-----------------------------------
Core data structures
^^^^^^^^^^^^^^^^^^^^
* Transaction building
You no longer need to specify the type of a ``TransactionBuilder`` as ``TransactionType.General``
``TransactionType.General.Builder(notary)`` becomes ``TransactionBuilder(notary)``
Build
^^^^^
* Gradle dependency reference changes.
Module name has changed to include `corda` in the artifacts jar name:
.. sourcecode:: shell
compile "net.corda:core:$corda_release_version" -> compile "net.corda:corda-core:$corda_release_version"
compile "net.corda:finance:$corda_release_version" -> compile "net.corda:corda-finance:$corda_release_version"
compile "net.corda:jackson:$corda_release_version" -> compile "net.corda:corda-jackson:$corda_release_version"
compile "net.corda:node:$corda_release_version" -> compile "net.corda:corda-node:$corda_release_version"
compile "net.corda:rpc:$corda_release_version" -> compile "net.corda:corda-rpc:$corda_release_version"
Node services (ServiceHub)
^^^^^^^^^^^^^
* ServiceHub API changes.
``services.networkMapUpdates()`` becomes ``services.networkMapFeed()``
``services.getCashBalances()`` becomes a helper method within the **finance** module contracts package: ``net.corda.finance.contracts.getCashBalances``
Finance
^^^^^^^
* Financial asset contracts (Cash, CommercialPaper, Obligations) are now a standalone CorDapp within the **finance** module.
Need to import from respective package within `finance` module:
eg. ``net.corda.finance.contracts.asset.Cash``
Likewise, need to import associated asset flows from respective package within `finance` module:
eg. ``net.corda.finance.flows.CashIssueFlow``
``net.corda.finance.flows.CashIssueAndPaymentFlow``
``net.corda.finance.flows.CashExitFlow``
* Moved ``finance`` gradle project files into a ``net.corda.finance`` package namespace.
This may require adjusting imports of Cash flow references and also of ``StartFlow`` permission in ``gradle.build`` files.
Associated flows (`Cash*Flow`, `TwoPartyTradeFlow`, `TwoPartyDealFlow`) must now be imported from this package.

2
finance/src/main/kotlin/net/corda/finance/flows/TwoPartyDealFlow.kt
View File

@ -50,12 +50,14 @@ object TwoPartyDealFlow {
abstract val notaryParty: Party
abstract val otherSideSession: FlowSession
// DOCSTART 2
@Suspendable
override fun call(): SignedTransaction {
progressTracker.currentStep = GENERATING_ID
val txIdentities = subFlow(SwapIdentitiesFlow(otherSideSession.counterparty))
val anonymousMe = txIdentities[ourIdentity] ?: ourIdentity.anonymise()
val anonymousCounterparty = txIdentities[otherSideSession.counterparty] ?: otherSideSession.counterparty.anonymise()
// DOCEND 2
progressTracker.currentStep = SENDING_PROPOSAL
// Make the first message we'll send to kick off the flow.
val hello = Handshake(payload, anonymousMe, anonymousCounterparty)

6
finance/src/main/kotlin/net/corda/finance/flows/TwoPartyTradeFlow.kt
View File

@ -169,6 +169,7 @@ object TwoPartyTradeFlow {
progressTracker.currentStep = SIGNING
val (ptx, cashSigningPubKeys) = assembleSharedTX(assetForSale, tradeRequest, buyerAnonymousIdentity)
// DOCSTART 6
// Now sign the transaction with whatever keys we need to move the cash.
val partSignedTx = serviceHub.signInitialTransaction(ptx, cashSigningPubKeys)
@ -180,6 +181,7 @@ object TwoPartyTradeFlow {
progressTracker.currentStep = COLLECTING_SIGNATURES
val sellerSignature = subFlow(CollectSignatureFlow(partSignedTx, sellerSession, sellerSession.counterparty.owningKey))
val twiceSignedTx = partSignedTx + sellerSignature
// DOCEND 6
// Notarise and record the transaction.
progressTracker.currentStep = RECORDING
@ -202,8 +204,8 @@ object TwoPartyTradeFlow {
// Register the identity we're about to send payment to. This shouldn't be the same as the asset owner
// identity, so that anonymity is enforced.
val wellKnownPayToIdentity = serviceHub.identityService.verifyAndRegisterIdentity(it.payToIdentity)
require(wellKnownPayToIdentity?.party == sellerSession.counterparty) { "Well known identity to pay to must match counterparty identity" }
val wellKnownPayToIdentity = serviceHub.identityService.verifyAndRegisterIdentity(it.payToIdentity) ?: it.payToIdentity
require(wellKnownPayToIdentity.party == sellerSession.counterparty) { "Well known identity to pay to must match counterparty identity" }
if (it.price > acceptablePrice)
throw UnacceptablePriceException(it.price)

9
node/src/integration-test/kotlin/net/corda/node/services/AttachmentLoadingTests.kt
View File

@ -1,7 +1,5 @@
package net.corda.node.services
import net.corda.client.rpc.RPCException
import net.corda.core.concurrent.CordaFuture
import net.corda.core.contracts.Contract
import net.corda.core.contracts.PartyAndReference
import net.corda.core.cordapp.CordappProvider
@ -18,7 +16,6 @@ import net.corda.core.transactions.TransactionBuilder
import net.corda.core.utilities.OpaqueBytes
import net.corda.core.utilities.getOrThrow
import net.corda.core.utilities.loggerFor
import net.corda.node.internal.StartedNode
import net.corda.node.internal.cordapp.CordappLoader
import net.corda.node.internal.cordapp.CordappProviderImpl
import net.corda.node.services.transactions.SimpleNotaryService
@ -27,19 +24,15 @@ import net.corda.nodeapi.internal.ServiceInfo
import net.corda.testing.DUMMY_BANK_A
import net.corda.testing.DUMMY_NOTARY
import net.corda.testing.TestDependencyInjectionBase
import net.corda.testing.driver.DriverDSL
import net.corda.testing.driver.DriverDSLExposedInterface
import net.corda.testing.driver.NodeHandle
import net.corda.testing.driver.driver
import net.corda.testing.node.MockServices
import net.corda.testing.resetTestSerialization
import org.junit.Assert.*
import org.junit.Assert.assertEquals
import org.junit.Before
import org.junit.Test
import java.net.URLClassLoader
import java.nio.file.Files
import java.sql.Driver
import kotlin.test.assertFails
import kotlin.test.assertFailsWith
class AttachmentLoadingTests : TestDependencyInjectionBase() {

15
node/src/test/kotlin/net/corda/node/messaging/TwoPartyTradeFlowTests.kt
View File

@ -51,6 +51,8 @@ import org.assertj.core.api.Assertions.assertThat
import org.junit.After
import org.junit.Before
import org.junit.Test
import org.junit.runner.RunWith
import org.junit.runners.Parameterized
import rx.Observable
import java.io.ByteArrayInputStream
import java.io.ByteArrayOutputStream
@ -69,7 +71,15 @@ import kotlin.test.assertTrue
*
* We assume that Alice and Bob already found each other via some market, and have agreed the details already.
*/
class TwoPartyTradeFlowTests {
@RunWith(Parameterized::class)
class TwoPartyTradeFlowTests(val anonymous: Boolean) {
companion object {
@JvmStatic
@Parameterized.Parameters
fun data(): Collection<Boolean> {
return listOf(true, false)
}
}
private lateinit var mockNet: MockNetwork
@Before
@ -542,8 +552,7 @@ class TwoPartyTradeFlowTests {
private fun runBuyerAndSeller(notary: Party,
sellerNode: StartedNode<MockNetwork.MockNode>,
buyerNode: StartedNode<MockNetwork.MockNode>,
assetToSell: StateAndRef<OwnableState>,
anonymous: Boolean = true): RunResult {
assetToSell: StateAndRef<OwnableState>): RunResult {
val buyerFlows: Observable<out FlowLogic<*>> = buyerNode.internals.registerInitiatedFlow(BuyerAcceptor::class.java)
val firstBuyerFiber = buyerFlows.toFuture().map { it.stateMachine }
val seller = SellerInitiator(buyerNode.info.chooseIdentity(), notary, assetToSell, 1000.DOLLARS, anonymous)

10
samples/network-visualiser/build.gradle
View File

@ -5,10 +5,10 @@ apply plugin: 'application'
apply plugin: 'net.corda.plugins.quasar-utils'
apply plugin: 'us.kirchmeier.capsule'
dependencies {
compile project(':samples:irs-demo')
compile project(':node-driver')
// Warning: The network visualiser is not a Cordapp so please do not use it as an example of how
// to build a cordapp
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version"
testCompile "junit:junit:$junit_version"
@ -17,8 +17,10 @@ dependencies {
compile project(path: ":webserver:webcapsule", configuration: 'runtimeArtifacts')
compile project(':core')
compile project(':finance')
compile project(':node-driver')
compile project(':finance')
compile project(':samples:irs-demo')
// Cordapp dependencies
// GraphStream: For visualisation
compileOnly "co.paralleluniverse:capsule:$capsule_version"
}

2
samples/network-visualiser/src/main/kotlin/net/corda/netmap/simulation/Simulation.kt
View File

@ -21,6 +21,7 @@ import net.corda.testing.node.InMemoryMessagingNetwork
import net.corda.testing.node.MockNetwork
import net.corda.testing.node.TestClock
import net.corda.testing.node.setTo
import net.corda.testing.setCordappPackages
import net.corda.testing.testNodeConfiguration
import rx.Observable
import rx.subjects.PublishSubject
@ -261,6 +262,7 @@ abstract class Simulation(val networkSendManuallyPumped: Boolean,
val networkInitialisationFinished = allOf(*mockNet.nodes.map { it.nodeReadyFuture.toCompletableFuture() }.toTypedArray())
fun start(): Future<Unit> {
setCordappPackages("net.corda.irs.contract", "net.corda.finance.contract")
mockNet.startNodes()
mockNet.registerIdentities()
// Wait for all the nodes to have finished registering with the network map service.

4
testing/test-utils/src/main/kotlin/net/corda/testing/contracts/DummyContract.kt
View File

@ -5,11 +5,13 @@ import net.corda.core.identity.AbstractParty
import net.corda.core.identity.Party
import net.corda.core.transactions.LedgerTransaction
import net.corda.core.transactions.TransactionBuilder
import kotlin.reflect.jvm.jvmName
// The dummy contract doesn't do anything useful. It exists for testing purposes, but has to be serializable
data class DummyContract(val blank: Any? = null) : Contract {
val PROGRAM_ID = "net.corda.testing.contracts.DummyContract"
interface State : ContractState {
val magicNumber: Int
}