Corda 4.1

It's been a little under 3 1/2 months since the release of Corda 4.0 and all of the brand new features that added to the powerful suite of tools Corda offers. Now, following the release of Corda Enterprise 4.0, we are proud to release Corda 4.1, bringing over 150 fixes and documentation updates to bring additional stability and quality of life improvements to those developing on the Corda platform.

Information on Corda Enterprise 4.0 can be found here.

Corda 4.1 brings the lessons and bug fixes discovered during the process of building and shipping Enterprise 4.0 back to the open source community. As mentioned above there are over 150 fixes and tweaks here. With this release the core feature sets of both entities are far closer aligned than past major releases of the Corda that should make testing your CorDapps in mixed type environments much easier.

As such, we recommend you upgrade from Corda 4.0 to Corda 4.1 as soon possible.

Corda 3.4

In response to the recently released Corda 4.0 Corda 3.4 brings a number of fixes that address several interoperability issues we've discovered between nodes. These should make the deployment of mixed version networks far smoother and the upgrade path from 3 to 4 easier.

The majority of these fixes surround the serialisation and class synthesis frameworks where receiving states and messages from newer (Version 4) nodes highlighted a few edge cases, bugs, and performance enhancements we could make.

Issues Fixed

Don't fail deserialisation with carpentry errors if the carpented types would be discarded through evolution [CORDA-2704]
RPC Vault query incompatibility between Corda 3.3 and Corda 4 [CORDA-2687]
V3 node unable to record finalised transaction containing a V3 FungibleAsset state created by a V4 node [CORDA-2422]
V3 node is unable to evolve serialised type that has introduced a property that is of an unknown type [CORDA-2314]
ClassCastException during initiate Contract Upgrade [CORDA-2109]

Corda 3.3

Corda 3.3 is now available!

Corda 3.3 brings together many small improvements, fixes, and community contributions to deliver a stable and polished release of Corda. Where both the 3.1 and 3.2 releases delivered a smaller number of critical bug fixes addressing immediate and impactful error conditions, 3.3 addresses a much greater number of issues, both small and large, that have been found and fixed since the release of 3.0 back in March. Rolling up a great many improvements and polish to truly make the Corda experience just that much better.

In addition to work undertaken by the main Corda development team, we've taken the opportunity in 3.3 to bring back many of the contributions made by community members from master onto the currently released stable branch. It has been said many times before, but the community and its members are the real life-blood of Corda and anyone who takes the time to contribute is a star in our eyes. Bringing that code into the current version we hope gives people the opportunity to see their work in action, and to help their fellow community members by having these contributions available in a supported release.

Changes of Note

Serialization fixes

Things "in the lab" always work so much better than they do in the wild, where everything you didn't think of is thrown at your code and a mockery is made of some dearly held assumptions. A great example of this is the serialization framework which delivers Corda's wire stability guarantee that was introduced in 3.0 and has subsequently been put to a rigorous test by our users. Corda 3.3 consolidates a great many fixes in that framework, both programmatically in terms of fixing bugs, but also in the documentation, hopefully making things clearer and easier to work with.

Certificate Hierarchy

After consultation, collaboration, and discussion with industry experts, we have decided to alter the default Certificate Hierarchy (PKI) utilized by Corda and the Corda Network. To facilitate this, the nodes have had their certificate path verification logic made much more flexible. All existing certificate hierarchy, certificates, and networks will remain valid. The possibility now exists for nodes to recognize a deeper certificate chain and thus Compatibility Zone operators can deploy and adhere to the PKI standards they expect and are comfortable with.

Practically speaking, the old code assumed a 3-level hierarchy of Root -> Intermediate CA (Doorman) -> Node, and this was hard coded. From 3.3 onward an arbitrary depth of certificate chain is supported. For the Corda Network, this means the introduction of an intermediate layer between the root and the signing certificates (Network Map and Doorman). This has the effect of allowing the root certificate to always be kept offline and never retrieved or used. Those new intermediate certificates can be used to generate, if ever needed, new signing certs without risking compromise of the root key.

Special Thanks

The Corda community is a vibrant and exciting ecosystem that spreads far outside the virtual walls of the
R3 organisation. Without that community, and the most welcome contributions of its members, the Corda project
would be a much poorer place.

We're therefore happy to extend thanks to the following members of that community for their contributions

• Dan Newton for a fix to cleanup node registration in the test framework. The changes can be found here.
• Tushar Singh Bora for a number of documentation tweaks. In addition, some updates to the tutorial documentation here.
• Jiachuan Li for a number of corrections to our documentation. Those contributions can be found here and here.
• Yogesh for a documentation tweak that can be see here.
• Roman Plášil for speeding up node shutdown when connecting to an http network map. This fix can be found here.
• renlulu for a small PR to optimize some of the imports.
• cxyzhang0 for making the IdentitySyncFlow more useful. See here.
• Venelin Stoykov with updates to the documentation around the progress tracker.
• Mohamed Amine Legheraba for updates to the Azure documentation that can be seen here.
• Stanly Johnson with a fix to the network bootstrapper.
• Tittu Varghese for adding a favicon to the docsite. This commit can be found here

Corda 3.2

Corda 3.2

As we see more Corda deployments in production this minor release of the open source platform brings
several fixes that make it easier for a node to join Corda networks broader than those used when
operating as part of an internal testing deployment. This will ensure Corda nodes will be free to interact
with upcoming network offerings from R3 and others who may make broad-access Corda networks available.

The Corda Network Builder

To make it easier to create more dynamic, flexible, networks for testing and deployment,
with the 3.2 release of Corda we are shipping a graphical network bootstrapping tool
to facilitate the simple creation of more dynamic ad hoc dev-mode environments.

Using a graphical interface you can dynamically create and alter Corda test networks, adding
nodes and CorDapps with the click of a button! Additionally, you can leverage its integration
with Azure cloud services for remote hosting of Nodes and Docker instances for local testing.

Split Compatibility Zone

Prior to this release compatibility zone membership was denoted with a single configuration setting

compatibilityZoneURL : "http://<host>(:<port>)"

That would indicate both the location of the Doorman service the node should use for registration
of its identity as well as the Network Map service where it would publish its signed Node Info and
retrieve the Network Map.

Compatibility Zones can now, however, be configured with the two disparate services, Doorman and
Network Map, running on different URLs. If the compatibility zone your node is connecting to
is configured in this manner, the new configuration looks as follows.

networkServices {
    doormanURL: "http://<host>(:<port>)"
    networkMapURL: "http://<host>(:<port>)"
}

NOTE: The compatibilityZoneURL setting should be considered deprecated in favor of the new networkServices settings group.

The Blob Inspector

The blob inspector brings the ability to unpack serialized Corda blobs at the
command line, giving a human-readable interpretation of the encoded date.

NOTE: This tool has been shipped as a separate Jar previously. We are now including it as part of an official release.

Documentation on its use can be found here :doc:blob-inspector

The Event Horizon

One part of joining a node to a Corda network is agreeing to the rules that govern that network as set out
by the network operator. A node's membership of a network is communicated to other nodes through the network
map, the service to which the node will have published its Node Info, and through which it receives the
set of NodeInfos currently present on the network. Membership of that list is a finite thing determined by
the network operator.

Periodically a node will republish its NodeInfo to the Network Map service. The Network Map uses this as a
heartbeat to determine the status of nodes registered with it. Those that don't "beep" within the
determined interval are removed from the list of registered nodes. The Event Horizon network parameter
sets the upper limit within which a node must respond or be considered inactive.

.. important:: This does not mean a node is unregistered from the Doorman, only that its NodeInfo is
removed from the Network Map. Should the node come back online it will be re-added to the published
set of NodeInfos

Issues Fixed

• Update Jolokia to a more secure version [CORDA-1744]
• Add the Blob Inspector [CORDA-1709]
• Add support for the Event Horizon Network Parameter [CORDA-866]
• Add the Network Bootstrapper [CORDA-1717]
• Fixes for the finance CordApp[CORDA-1711]
• Allow Doorman and NetworkMap to be configured independently [CORDA-1510]
• Serialization fix for generics when evolving a class [CORDA-1530]
• Correct typo in an internal database table name [CORDA-1499] and [CORDA-1804]
• Hibernate session not flushed before handing over raw JDBC session to user code [CORDA-1548]
• Fix Postgres db bloat issue [CORDA-1812]
• Roll back flow transaction on exception [CORDA-1790]

Corda 3.1

Corda 3.1

This rapid follow-up to Corda 3.0 corrects an issue discovered by some users of Spring Boot and a number of other smaller issues discovered post release. All users are recommended to upgrade.

Special Thanks

Without passionate and engaged users Corda would be all the poorer. As such, we are extremely grateful to Bret Lichtenwald (@bret540) for helping nail down a reproducible test case for the Spring Boot issue.

Major Bug Fixes

Corda Serialization fails with "Unknown constant pool tag"

This issue is most often seen when running a CorDapp with a Rest API using / provided by Spring Boot.

The fundamental cause was Corda 3.0 shipping with an out of date dependency for the fast-classpath-scanner library, where the manifesting bug was already fixed in a released version newer than our dependant one. In response, we've updated our dependent version to one including that bug fix.

Corda Versioning

Those eagle eyed amongst you will have noticed for the 3.0 release we altered the versioning scheme from that used by previous Corda releases (1.0.0, 2.0.0, etc) with the addition of an prepended product name, resulting in corda-3.0. The reason for this was so that developers could clearly distinguish between the base open source platform and any distributions based on on Corda that may be shipped in the future (including from R3), However, we have heard the complaints and feel the pain that's caused by various tools not coping well with this change. As such, from now on the versioning scheme will be inverted, with this release being 3.1-corda.

As to those curious as to why we dropped the patch number from the version string, the reason is very simple: there won't be any patches applied to a release of Corda. Either a release will be a collection of bug fixes and non API breaking changes, thus eliciting a minor version bump as with this release, or major functional changes or API additions and warrant a major version bump. Thus, rather than leave a dangling .0 patch version on every release we've just dropped it. In the case where a major security flaw needed addressing, for example, then that would generate a release of a new minor version.

Issues Fixed

• RPC server leaks if a single client submits a lot of requests over time [CORDA-1295]
• Flaky startup, no db transaction in context, when using postgresql [CORDA-1276]
• Corda's JPA classes should not be final or have final methods [CORDA-1267]
• Backport api-scanner changes [CORDA-1178]
• Misleading error message shown when node is restarted after the flag day
• Hash constraints not working from Corda 3.0 onwards
• Serialisation Error between Corda 3 RC01 and Corda 3
• Nodes don't start when network-map/doorman is down

Corda V3.0

Release 3.0

Corda 3.0 is here and brings with it a commitment to a wire stable platform, a path for contract and node upgradability, and a host of other exciting features. The aim of which is to enhance the developer and user experience whilst providing for the long-term usability of deployed Corda instances. This release will provide functionality to ensure anyone wishing to move to the anticipated release of R3 Corda can do so seamlessly and with the assurance that stateful data persisted to the vault will remain understandable between newer and older nodes.

Special Thanks

As ever, we are grateful to the enthusiastic user and developer community that has grown up to surround Corda.
As an open project, we are always grateful to take code contributions from individual users where they feel they
can add functionality useful to themselves and the wider community.

As such we'd like to extend special thanks to

• Ben Wyeth for providing a mechanism for registering a callback on app shutdown

  Ben's contribution can be found on GitHub here

• Tomas Tauber for adding support for running Corda atop PostgresSQL in place of the in-memory H2 service

  Tomas's contribution can be found on GitHub here

  Note: This is an experimental feature that has not been tested as part of our standard release testing.

• Rose Molina Atienza for correcting our careless spelling slip

  Rose's change can be found on GitHub here

Significant Changes in 3.0

Wire Stability

Wire stability brings the same promise to developers for their data that API stability did for their code. From this point, any state generated by a Corda system will always be retrievable, understandable, and seen as valid by any subsequently released version (versions 3.0 and above).

Systems can thus be deployed safely in the knowledge that valuable and important information will always be accessible through upgrade and change. Practically speaking this means from this point forward upgrading all, or part, of a Corda network, will not require the replaying of data; "it will just work".

This has been facilitated by the switchover from Kryo to Corda's own AMQP based serialization framework, a framework designed to interoperate with stateful information and allow the evolution of such contract states over time as developers refine and improve their systems written atop the core Corda platform.

AMQP Serialization

AMQP Serialization is now enabled for both peer-to-peer communication and the writing of states to the vault. This change brings a serialization format that will allow us to deliver enhanced security and wire stability. This was a key prerequisite to enabling different Corda node versions to coexist on the same network and to enable easier upgrades.

Details on the AMQP serialization framework can be found in the docs. This provides an introduction and overview of the framework whilst more specific details on object evolution as it relates to serialization can be found in the documentation

This release delivers the bulk of our transition from Kryo serialization to AMQP serialization. This means that many of the restrictions that were documented in previous versions of Corda are now enforced.

In particular, you are advised to review the section titled Custom Types. To aid with the transition, we have included support in this release for default construction and instantiation of objects with inaccessible private fields, but it is not guaranteed that this support will continue into future versions; the restrictions documented at the link above are the canonical source.

Whilst this is an important step for Corda, in no way is this the end of the serialization story. We have many new features and tools planned for future releases but feel it is more important to deliver the guarantees discussed above as early as possible to allow the community to develop with greater confidence.

Note: Whilst Corda has stabilized its wire protocol and infrastructure for peer to peer communication and persistent storage of states, the RPC framework will, for this release, not be covered by this guarantee. The moving of the client and server contexts away from Kryo to our stable AMQP implementation is planned for the next release of Corda

Artemis and Bridges

Corda has now achieved the long-stated goal of using the AMQP 1.0 open protocol standard as its communication protocol between peers. This forms a strong and flexible framework upon which we can deliver future enhancements that will allow for much smoother integrations between Corda and third-party brokers, languages, and messaging systems. In addition, this is also an important step towards formally defining the official peer to peer messaging protocol of Corda, something required for more in-depth security audits of the Corda protocol.

New Network Map Service

This release introduces the new network map architecture. The network map service has been completely redesigned and implemented to enable future increased network scalability and redundancy, reduced runtime operational overhead, support for multiple notaries, and administration of network compatibility zones (CZ).

A Corda Compatibility Zone is defined as a grouping of participants and services (notaries, oracles, doorman, network map server) configured within an operational Corda network to be interoperable and compatible with each other.

We introduce the concept of network parameters to specify precisely the set of constants (or ranges of constants) upon which the nodes within a network need to agree in order to be assured of seamless inter-operation. Additional security controls ensure that all network map data is now signed, thus reducing the power of the network operator to tamper with the map.

There is also support for a group of nodes to operate locally, which is achieved by copying each node's signed info file to the other nodes' directories. We've added a bootstrapping tool to facilitate this use case.

Note: This replaces the Network Map service that was present in Corda 1.0 and Corda 2.0.

Contract Upgrade

Support for the upgrading of contracts has been significantly extended in this release.

Contract states express which attached JARs can define and verify them using constraints. In older versions, the only supported constraint was a hash constraint. This provides similar behaviour as public blockchain systems like Bitcoin and Ethereum, in which code is entirely fixed once deployed and cannot be changed later. In Corda there is an upgrade path that involves the cooperation of all involved parties (as advertised by the states themselves), but this requires explicit transactions to be applied to all states and be signed by all parties.

Hash constraints provide for maximum decentralization and minimum trust, at the cost of flexibility. In Corda 3.0 we add a new constraint, a _network parameters_ constraint, that allows the list of acceptable contract JARs to be maintained by the operator of the compatibility zone rather than being hard-coded. This allows for simple upgrades at the cost of the introduction of an element of centralization.

Zone constraints provide a less restrictive but more centralized control mechanism. This can be useful when you want the ability to upgrade an app and you don’t mind the upgrade taking effect “just in time” when a transaction happens to be required for other business reasons. These allow you to specify that the network parameters of a compatibility zone (see the documentation) is expected to contain a map of class name to hashes of JARs that are allowed to provide that class. The process for upgrading an app then involves asking the zone operator to add the hash of your new JAR to the parameters file and trigger the network parameters upgrade process. This involves each node operator running a shell command to accept the new parameters file and then restarting the node. Node owners who do not restart their node in time effectively stop being a part of the network.

Prior to running the verification code of a contract, the JAR within which the verification code of the contract resides is tested for compliance with the contract constraints:

• For the HashConstraint: the hash of the deployed CorDapp jar must be the same as the hash found in the Transaction.
• For the ZoneConstraint: the Transaction must come with a whitelisted attachment for each Contract State.

If this step fails the normal transaction verification failure path is followed.

Corda 3.0 lays the groundwork for future releases, when contract verification will be done against the attached contract JARs rather than requiring a locally deployed CorDapp of the exact version specified by the transaction. The future vision for this feature will entail the dynamic downloading of the appropriate version of the smart contract and its execution within a sandboxed environment.

Future versions of Corda will add support for signature-based constraints, in which any JAR signed by a given identity can be attached to the transaction. This final constraint type provides a balance of all requirements: smooth rolling upgrades can be performed without any additional steps or transactions being signed, at the cost of trusting the app developer more and some additional complexity around managing app signing.

Please see the upgrading cordapps documentation for more information on upgrading contracts.

Test API Stability

A great deal of work has been carried out to refine the APIs provided to test CorDapps, making them simpler, more intuitive, and generally easier t...

Corda V2.0

Corda 2.0

Following swiftly on the heels of the release of Corda 1.0, Corda version 2.0 consolidates a number of security updates for our dependent libraries alongside the reintroduction of the Observer node functionality. This was absent from version 1 but based on user feedback its re-introduction removes the need for complicated "isRelevant()" checks.

In addition the fix for a small bug present in the coin selection code of V1.0 is integrated from master.

Version Bump

Due to the introduction of new APIs, Corda 2.0 has a platform version of 2. This will be advertised in the network map structures and via the versioning APIs.

Observer Nodes

Adds the facility for transparent forwarding of transactions to some third party observer, such as a regulator. By having that entity simply run an Observer node they can simply receive a stream of digitally signed, de-duplicated reports that can be used for reporting.

Corda V1.0

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

• 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.
  • We no longer support advertising services in network map. Removed NodeInfo::advertisedServices, serviceIdentities
    and notaryIdentity.
  • Removed service methods from NetworkMapCache: partyNodes, networkMapNodes, notaryNodes, regulatorNodes,
    getNodesWithService, getPeersWithService, getRecommended, getNodesByAdvertisedServiceIdentityKey, getAnyNotary,
    notaryNode, getAnyServiceOfType. To get all known NodeInfos 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.
  • Moved ServiceType and ServiceInfo to net.corda.nodeapi package as services are only required on node startup.

• Adding enum support to the class carpenter

• ContractState::contract has been moved TransactionState::contract and it's type has changed to String in order to
  support dynamic classloading of contract and contract constraints.

• CorDapps that contain contracts are now automatically loaded into the attachment storage - for CorDapp developers this
  now means that contracts should be stored in separate JARs to flows, services and utilities to avoid large JARs being
  auto imported to the attachment store.

• 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
  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.
  An associated property on MockNode was renamed from testPluginRegistries to testSerializationWhitelists.

• Contract Upgrades: deprecated RPC authorisation / deauthorisation API calls in favour of equivalent flows in ContractUpgradeFlow.
  Implemented contract upgrade persistence using JDBC backed persistent map.

• Vault query common attributes (state status and contract state types) are now handled correctly when using composite
  criteria specifications. State status is overridable. Contract states types are aggregatable.

• Cash selection algorithm is now pluggable (with H2 being the default implementation)

• Removed usage of Requery ORM library (repalced with JPA/Hibernate)

• Vault Query performance improvement (replaced expensive per query SQL statement to obtain concrete state types
  with single query on start-up followed by dynamic updates using vault state observable))

• 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
    • networkMapUpdates, replaced by networkMapFeed

• Due to security concerns and the need to remove the concept of state relevancy (which isn't needed in Corda),
  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 StateAndRefs.

• 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)

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

• Merged handling of well known and confidential identities in the identity service. Registration now takes in an identity
  (either type) plus supporting certificate path, and de-anonymisation simply returns the issuing identity where known.
  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`.

• Remove IssuerFlow as it allowed nodes to request arbitrary amounts of cash to be issued from any remote node. Use
  CashIssueFlow instead.

• Some utility/extension functions (sumOrThrow, sumOrNull, sumOrZero on Amount and Commodity)
  have moved to be static methods on the classes themselves. This improves the API for Java users who no longer
  have to see or known about file-level FooKt style classes generated by the Kotlin compile, but means that IntelliJ
  no longer auto-suggests these extension functions in completion unless you add import lines for them yourself
  (this is Kotlin IDE bug KT-15286).

• :finance module now acting as a CorDapp with regard to flow registration, schemas and serializable types.

• WebServerPluginRegistry now has a customizeJSONSerialization which can be overridden to extend the REST JSON
  serializers. In particular the IRS demos must now register the BusinessCalendar serializers.

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

• Removed the concept of relevancy from LinearState. The ContractState's relevancy to the vault can be determined
  by the flow context, the vault will process any transaction from a flow which is not derived from transaction resolution verification.

• Removed the tolerance attribute from TimeWindowChecker and thus, there is no extra tolerance on the notary side anymore.

• 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 IssueCommand interface has been removed from Structures, because, due to the introduction of nonces per
  transaction component, the issue command does not need a nonce anymore and it does not require any other attributes.

• As a consequence of the above and the simpler FungibleAsset format, fungible assets like Cash now use
  class Issue : TypeOnlyCommandData(), because it's only its presence (Issue) that matters.

• A new PrivacySalt transaction component is introduced, which is now an attribute in TraversableTransaction and
  inherently in WireTransaction.

• A new nonces: List<SecureHash> feature has been added to FilteredLeaves.

• Due to the nonces and PrivacySalt introduction, new functions...

Milestone 14.0

• Changes in NodeInfo:

  • PhysicalLocation was renamed to WorldMapLocation to emphasise that it doesn't need to map to a truly physical
    location of the node server.
  • Slots for multiple IP addresses and legalIdentitiesAndCerts were introduced. Addresses are no longer of type
    SingleMessageRecipient, but of NetworkHostAndPort.

• ServiceHub.storageService has been removed. attachments and validatedTransactions are now direct members of
  ServiceHub.

• Mock identity constants used in tests, such as ALICE, BOB, DUMMY_NOTARY, have moved to net.corda.testing
  in the test-utils module.

• DummyContract, DummyContractV2, DummyLinearContract and DummyState have moved to net.corda.testing.contracts
  in the test-utils modules.

• In Java, QueryCriteriaUtilsKt has moved to QueryCriteriaUtils. Also and and or are now instance methods
  of QueryCrtieria.

• random63BitValue() has moved to CryptoUtils

• Added additional common Sort attributes (see Sort.CommandStateAttribute) for use in Vault Query criteria
  to include STATE_REF, STATE_REF_TXN_ID, STATE_REF_INDEX

• Moved the core flows previously found in net.corda.flows into net.corda.core.flows. This is so that all packages
  in the core module begin with net.corda.core.

• FinalityFlow can now be subclassed, and the broadcastTransaction and lookupParties function can be
  overriden in order to handle cases where no single transaction participant is aware of all parties, and therefore
  the transaction must be relayed between participants rather than sent from a single node.

• TransactionForContract has been removed and all usages of this class have been replaced with usage of
  LedgerTransaction. In particular Contract.verify and the Clauses API have been changed and now take a
  LedgerTransaction as passed in parameter. The prinicpal consequence of this is that the types of the input and output
  collections on the transaction object have changed, so it may be necessary to map down to the ContractState
  sub-properties in existing code.

• Added various query methods to LedgerTransaction to simplify querying of states and commands. In the same vain
  Command is now parameterised on the CommandData field.

• Kotlin utilities that we deemed useful enough to keep public have been moved out of net.corda.core.Utils and into
  net.corda.core.utilities.KotlinUtils. The other utilities have been marked as internal.

• Changes to Cordformation/ cordapp building:

  • Cordformation modifies the JAR task to make cordapps build as semi fat JARs containing all dependencies
    except other cordapps and Corda core dependencies.
  • Cordformation adds a corda and cordaRuntime configuration to projects which cordapp developers should
    use to exclude core Corda JARs from being built into Cordapp fat JARs.

• database field in AbstractNode class has changed the type from org.jetbrains.exposed.sql.Database to
  ‘net.corda.node.utilities.CordaPersistence’ - no change is needed for the typical use
  (i.e. services.database.transaction { code block } ) however a change is required when Database was explicitly declared

• DigitalSignature.LegallyIdentifiable, previously used to identify a signer (e.g. in Oracles), has been removed.
  One can use the public key to derive the corresponding identity.

• Vault Query improvements and fixes:

  • FIX inconsistent behaviour: Vault Query defaults to UNCONSUMED in all QueryCriteria types

  • FIX serialization error: Vault Query over RPC when using custom attributes using VaultCustomQueryCriteria.

  • Aggregate function support: extended VaultCustomQueryCriteria and associated DSL to enable specification of
    Aggregate Functions (sum, max, min, avg, count) with, optional, group by clauses and sorting (on calculated aggregate)

  • Pagination simplification
    Pagination continues to be optional, but with following changes:

    • If no PageSpecification provided then a maximum of MAX_PAGE_SIZE (200) results will be returned, otherwise we fail-fast with a VaultQueryException to alert the API user to the need to specify a PageSpecification.
      Internally, we no longer need to calculate a results count (thus eliminating an expensive SQL query) unless a PageSpecification is supplied (note: that a value of -1 is returned for total_results in this scenario).
      Internally, we now use the AggregateFunction capability to perform the count.
    • Paging now starts from 1 (was previously 0).

  • Additional Sort criteria: by StateRef (or constituents: txId, index)

• Confidential identities API improvements

  • Registering anonymous identities now takes in AnonymousPartyAndPath
  • AnonymousParty.toString() now uses toStringShort() to match other toString() functions
  • Add verifyAnonymousIdentity() function to verify without storing an identity
  • Replace pathForAnonymous() with anonymousFromKey() which matches actual use-cases better
  • Add unit test for fetching the anonymous identity from a key
  • Update verifyAnonymousIdentity() function signature to match registerAnonymousIdentity()
  • Rename AnonymisedIdentity to AnonymousPartyAndPath
  • Remove certificate from AnonymousPartyAndPath as it's not actually used.
  • Rename registerAnonymousIdentity() to verifyAndRegisterAnonymousIdentity()

Milestone 10.1

• Corda DemoBench:

  • DemoBench is a new tool to make it easy to configure and launch local Corda nodes. A very useful tool to demonstrate to your colleagues the fundamentals of Corda in real-time. It has the following features:
    • Clicking "Add node" creates a new tab that lets you edit the most important configuration properties of the node before launch, such as its legal name and which CorDapps will be loaded.
    • Each tab contains a terminal emulator, attached to the pseudoterminal of the node. This lets you see console output.
    • You can launch an Corda Explorer instance for each node via the DemoBench UI. Credentials are handed to the Corda Explorer so it starts out logged in already.
    • Some basic statistics are shown about each node, informed via the RPC connection.
    • Another button launches a database viewer in the system browser.
    • The configurations of all running nodes can be saved into a single .profile file that can be reloaded later.

• Vault:

  • Soft Locking is a new feature implemented in the vault which prevent a node constructing transactions that attempt to use the same input(s) simultaneously.
  • Such transactions would result in naturally wasted effort when the notary rejects them as double spend attempts.
  • Soft locks are automatically applied to coin selection (eg. cash spending) to ensure that no two transactions attempt to spend the same fungible states.

• Corda Shell :

  • The shell lets developers and node administrators easily command the node by running flows, RPCs and SQL queries.
  • It provides a variety of commands to monitor the node.
  • The Corda Shell is based on the popular CRaSH project <http://www.crashub.org/>_ and new commands can be easily added to the node by simply dropping Groovy or Java files into the node's shell-commands directory.
  • We have many enhancements planned over time including SSH access, more commands and better tab completion.

• API changes:

  • The new Jackson module provides JSON/YAML serialisers for common Corda datatypes.
    If you have previously been using the JSON support in the standalone web server,
    please be aware that Amounts are now serialised as strings instead of { quantity, token } pairs as before.
    The old format is still accepted, but the new JSON will be produced using strings like "1000.00 USD" when writing.
    You can use any format supported by Amount.parseCurrency as input.

  • We have restructured client package in this milestone.

    • CordaClientRPC is now in the new :client:rpc module.
    • The old :client module has been split up into :client:jfx and :client:mock.
    • We also have a new :node-api module (package net.corda.nodeapi) which contains the shared code between node and client.

  • The basic Amount API has been upgraded to have support for advanced financial use cases and to better integrate with currency reference data.

• Configuration:

  • Replace artemisPort with p2pPort in Gradle configuration.
  • Replace artemisAddress with p2pAddress in node configuration.
  • Added rpcAddress in node configuration for non-ssl RPC connection.

• Object Serialization:

  • Pool Kryo instances for efficiency.

• RPC client changes:

  • RPC clients can now connect to the node without the need for SSL. This requires a separate port on the Artemis broker, SSL must not be used for RPC connection.
  • CordaRPCClient now needs to connect to rpcAddress rather than p2pAddress.

• Dependencies changes:

  • Upgraded Kotlin to v1.1.1.
  • Upgraded Gradle to v3.4.1.
  • Upgraded requery to v1.2.1.
  • Upgraded H2 to v1.4.194.
  • Replaced kotlinx-support-jdk8 with kotlin-stdlib-jre8.

• Improvements:

  • Added --version command line flag to print the version of the node.
  • Flows written in Java can now execute a sub-flow inside UntrustworthyData.unwrap.
  • Added optional out-of-process transaction verification. Any number of external verifier processes may be attached to the node which can handle loadbalanced verification requests.

• Bug fixes:

  • --logging-level command line flag was previously broken, now correctly sets the logging level.
  • Fixed bug whereby Cash Exit was not taking into account the issuer reference.