diff --git a/docs/source/changelog-enterprise.rst b/docs/source/changelog-enterprise.rst new file mode 100644 index 0000000000..e13df4a248 --- /dev/null +++ b/docs/source/changelog-enterprise.rst @@ -0,0 +1,303 @@ +Changelog +========= + +Here's a summary of what's changed in each Corda Enterprise release. For guidance on how to upgrade code from the previous +release, see :doc:`upgrade-notes`. + +Unreleased +---------- + +Please refer to :doc:`changelog` for all Open Source changes which automatically also apply to Enterprise. + +Changelog entries in this unreleased section refer to Enterprise-only changes. + +* The ``corda-bridgserver.jar`` has been renamed to ``corda-firewall.jar`` to be more consistent + with marketing materials and purpose of the jar. Further to this we have also renamed ``bridge.conf`` to ``firewall.conf`` + and within that file the ``bridgeMode`` propety has been modified to ``firewallMode`` for overall consistency. + This will be a breaking change for early adopters and their deployments, but hopefully will be more future proof. + +* Introduced a hierarchy of ``DatabaseMigrationException``s, allowing ``NodeStartup`` to gracefully inform users of problems + related to database migrations before exiting with a non-zero code. + +* Introduced a grace period before the initial node registration fails if the node cannot connect to the Doorman. + It retries 10 times with a 1 minute interval in between each try. At the moment this is not configurable. + +.. _changelog_v3.1: + +Version 3.1 +----------- + +* Update the fast-classpath-scanner dependent library version from 2.0.21 to 2.12.3 + + .. note:: Whilst this is not the latest version of this library, that being 2.18.1 at time of writing, versions + later than 2.12.3 (including 2.12.4) exhibit a different issue. + +* Added `database.hibernateDialect` node configuration option + +.. _changelog_r3_v3: + +Corda Enterprise 3.0 Developer Preview +-------------------------------------- + +* Fix CORDA-1229. Setter-based serialization was broken with generic types when the property was stored as the raw type, List for example. + +* Fixed security vulnerability when using the ``HashAttachmentConstraint``. Added strict check that the contract JARs + referenced in a transaction were deployed on the node. + +* Node can be shut down abruptly by ``shutdown`` function in `CordaRPCOps` or gracefully (draining flows first) through ``gracefulShutdown`` command from shell. Please refer to ::doc:`shell.rst` for more. + +* Carpenter Exceptions will be caught internally by the Serializer and rethrown as a ``NotSerializableException`` + + * Specific details of the error encountered are logged to the node's log file. More information can be enabled by setting the debug level to ``trace`` ; this will cause the full stack trace of the error to be dumped into the log. + +* Parsing of ``NodeConfiguration`` will now fail if unknown configuration keys are found. + +* The web server now has its own ``web-server.conf`` file, separate from ``node.conf``. + +* Introduced a placeholder for custom properties within ``node.conf``; the property key is "custom". + +* Property keys with double quotes (e.g. `"key"`) in ``node.conf`` are no longer allowed, for rationale refer to :doc:`corda-configuration-file`. + +* java.math.BigInteger serialization support added. + +* java.security.cert.CRLReason added to the default Whitelist. + +* java.security.cert.X509CRL serialization support added. + +* Added ``NetworkMapCache.getNodesByLegalName`` for querying nodes belonging to a distributed service such as a notary cluster + where they all share a common identity. ``NetworkMapCache.getNodeByLegalName`` has been tightened to throw if more than + one node with the legal name is found. + +* Per CorDapp configuration is now exposed. ``CordappContext`` now exposes a ``CordappConfig`` object that is populated + at CorDapp context creation time from a file source during runtime. + +* Introduced Flow Draining mode, in which a node continues executing existing flows, but does not start new. This is to + support graceful node shutdown/restarts. In particular, when this mode is on, new flows through RPC will be rejected, + scheduled flows will be ignored, and initial session messages will not be consumed. This will ensure that the number of + checkpoints will strictly diminish with time, allowing for a clean shutdown. + +* Make the serialisation finger-printer a pluggable entity rather than hard wiring into the factory + +* Removed blacklisted word checks in Corda X.500 name to allow "Server" or "Node" to be use as part of the legal name. + +* Separated our pre-existing Artemis broker into an RPC broker and a P2P broker. + +* Refactored ``NodeConfiguration`` to expose ``NodeRpcOptions`` (using top-level "rpcAddress" property still works with warning). + +* Modified ``CordaRPCClient`` constructor to take a ``SSLConfiguration?`` additional parameter, defaulted to ``null``. + +* Introduced ``CertificateChainCheckPolicy.UsernameMustMatchCommonName`` sub-type, allowing customers to optionally enforce + username == CN condition on RPC SSL certificates. + +* Modified ``DriverDSL`` and sub-types to allow specifying RPC settings for the Node. + +* Modified the ``DriverDSL`` to start Cordformation nodes allowing automatic generation of "rpcSettings.adminAddress" in case + "rcpSettings.useSsl" is ``false`` (the default). + +* Introduced ``UnsafeCertificatesFactory`` allowing programmatic generation of X509 certificates for test purposes. + +* JPA Mapping annotations for States extending ``CommonSchemaV1.LinearState`` and ``CommonSchemaV1.FungibleState`` on the + `participants` collection need to be moved to the actual class. This allows to properly specify the unique table name per + a collection. See: DummyDealStateSchemaV1.PersistentDummyDealState + +* JPA Mapping annotations for States extending ``CommonSchemaV1.LinearState`` and ``CommonSchemaV1.FungibleState`` on the + `participants` collection need to be moved to the actual State class. This allows developers to properly specify + the table name for the `participants` collection. + For an example on how the mapping can be done, see: DummyDealStateSchemaV1.PersistentDummyDealState + +* JDBC drivers for SQL server and PostgresSQL are no longer bundled as part of Corda releases. If you are running a node + on such databases you need to provide the associated driver as described in :doc:`node-database`. + +* X.509 certificates now have an extension that specifies the Corda role the certificate is used for, and the role + hierarchy is now enforced in the validation code. See ``net.corda.core.internal.CertRole`` for the current implementation + until final documentation is prepared. Certificates at ``NODE_CA``, ``WELL_KNOWN_SERVICE_IDENTITY`` and above must + only ever be issued by network services and therefore issuance constraints are not relevant to end users. + The ``TLS`` and ``WELL_KNOWN_LEGAL_IDENTITY`` roles must be issued by the ``NODE_CA`` certificate issued by the + Doorman, and ``CONFIDENTIAL_IDENTITY`` certificates must be issued from a ``WELL_KNOWN_LEGAL_IDENTITY`` certificate. + For a detailed specification of the extension please see :doc:`permissioning`. + +* The network map service concept has been re-designed. More information can be found in :doc:`network-map`. + + * The previous design was never intended to be final but was rather a quick implementation in the earliest days of the + Corda project to unblock higher priority items. It suffered from numerous disadvantages including lack of scalability, + as one node was expected to hold open and manage connections to every node on the network; not reliable; hard to defend + against DoS attacks; etc. + + * There is no longer a special network map node for distributing the network map to the other nodes. Instead the network + map is now a collection of signed ``NodeInfo`` files distributed via HTTP. + + * The ``certificateSigningService`` config has been replaced by ``compatibilityZoneURL`` which is the base URL for the + doorman registration and for downloading the network map. There is also an end-point for the node to publish its node-info + object, which the node does each time it changes. ``networkMapService`` config has been removed. + + * To support local and test deployments, the node polls the ``additional-node-infos`` directory for these signed ``NodeInfo`` + objects which are stored in its local cache. On startup the node generates its own signed file with the filename format + "nodeInfo-\*". This can be copied to every node's ``additional-node-infos`` directory that is part of the network. + + * Cordform (which is the ``deployNodes`` gradle task) does this copying automatically for the demos. The ``NetworkMap`` + parameter is no longer needed. + + * For test deployments we've introduced a bootstrapping tool (see :doc:`network-bootstrapper`). + + * ``extraAdvertisedServiceIds``, ``notaryNodeAddress``, ``notaryClusterAddresses`` and ``bftSMaRt`` configs have been + removed. The configuration of notaries has been simplified into a single ``notary`` config object. See + :doc:`corda-configuration-file` for more details. + + * Introducing the concept of network parameters which are a set of constants which all nodes on a network must agree on + to correctly interoperate. These can be retrieved from ``ServiceHub.networkParameters``. + + * One of these parameters, ``maxTransactionSize``, limits the size of a transaction, including its attachments, so that + all nodes have sufficient memory to validate transactions. + + * The set of valid notaries has been moved to the network parameters. Notaries are no longer identified by the CN in + their X.500 name. + + * Single node notaries no longer have a second separate notary identity. Their main identity *is* their notary identity. + Use ``NetworkMapCache.notaryIdentities`` to get the list of available notaries. + + * Added ``NetworkMapCache.getNodesByLegalName`` for querying nodes belonging to a distributed service such as a notary cluster + where they all share a common identity. ``NetworkMapCache.getNodeByLegalName`` has been tightened to throw if more than + one node with the legal name is found. + + * The common name in the node's X.500 legal name is no longer reserved and can be used as part of the node's name. + + * Moved ``NodeInfoSchema`` to internal package as the node info's database schema is not part of the public API. This + was needed to allow changes to the schema. + +* Support for external user credentials data source and password encryption [CORDA-827]. + +* Integrate database migration tool: http://www.liquibase.org/ : + * The migration files are split per ``MappedSchemas``. (added new property: migrationResource used to point to the resource file containing the db changes corresponding to the JPA entities) + * config flag ``database.initialiseSchema`` was renamed to: ``database.runMigration`` (if true then the migration is run during startup just before hibernate is initialised.) + * config flag: ``database.serverNameTablePrefix`` was removed as we no longer use table prefixes + * New command line argument:``—just-generate-db-migration outputSqlFile``: this will generate the delta from the last release, and will output the resulting sql into the outputSqlFile. It will not write to the db. It will not start the node! + * New command line argument: ``--just-run-db-migration``: this will only run the db migration. It will not start the node! + +* Exporting additional JMX metrics (artemis, hibernate statistics) and loading Jolokia agent at JVM startup when using + DriverDSL and/or cordformation node runner. + +* Removed confusing property ``database.initDatabase``, enabling its guarded behaviour with the dev-mode. + In devMode Hibernate will try to create or update database schemas, otherwise it will expect relevant schemas to be present + in the database (pre configured via DDL scripts or equivalent), and validate these are correct. + +* ``ConfigUtilities`` now read system properties for a node. This allow to specify data source properties at runtime. + +* ``AttachmentStorage`` now allows providing metadata on attachments upload - username and filename, currently as plain + strings. Those can be then used for querying, utilizing ``queryAttachments`` method of the same interface. + +* ``SSH Server`` - The node can now expose shell via SSH server with proper authorization and permissioning built in. + +* ``CordaRPCOps`` implementation now checks permissions for any function invocation, rather than just when starting flows. + +* ``wellKnownPartyFromAnonymous()`` now always resolve the key to a ``Party``, then the party to the well known party. + Previously if it was passed a ``Party`` it would use its name as-is without verifying the key matched that name. + +* ``OpaqueBytes.bytes`` now returns a clone of its underlying ``ByteArray``, and has been redeclared as ``final``. + This is a minor change to the public API, but is required to ensure that classes like ``SecureHash`` are immutable. + +* Experimental support for PostgreSQL: CashSelection done using window functions + +* ``FlowLogic`` now exposes a series of function called ``receiveAll(...)`` allowing to join ``receive(...)`` instructions. + +* Renamed "plugins" directory on nodes to "cordapps" + +* The ``Cordformation`` gradle plugin has been split into ``cordformation`` and ``cordapp``. The former builds and + deploys nodes for development and testing, the latter turns a project into a cordapp project that generates JARs in + the standard CorDapp format. + +* ``Cordapp`` now has a name field for identifying CorDapps and all CorDapp names are printed to console at startup. + +* Enums now respect the whitelist applied to the Serializer factory serializing / deserializing them. If the enum isn't + either annotated with the @CordaSerializable annotation or explicitly whitelisted then a NotSerializableException is + thrown. + +* Gradle task ``deployNodes`` can have an additional parameter ``configFile`` with the path to a properties file + to be appended to node.conf. + +* Cordformation node building DSL can have an additional parameter ``configFile`` with the path to a properties file + to be appended to node.conf. + +* ``FlowLogic`` now has a static method called ``sleep`` which can be used in certain circumstances to help with resolving + contention over states in flows. This should be used in place of any other sleep primitive since these are not compatible + with flows and their use will be prevented at some point in the future. Pay attention to the warnings and limitations + described in the documentation for this method. This helps resolve a bug in ``Cash`` coin selection. + A new static property ``currentTopLevel`` returns the top most ``FlowLogic`` instance, or null if not in a flow. + +* ``CordaService`` annotated classes should be upgraded to take a constructor parameter of type ``AppServiceHub`` which + allows services to start flows marked with the ``StartableByService`` annotation. For backwards compatability + service classes with only ``ServiceHub`` constructors will still work. + +* ``TimeWindow`` now has a ``length`` property that returns the length of the time-window as a ``java.time.Duration`` object, + or ``null`` if the time-window isn't closed. + +* A new ``SIGNERS_GROUP`` with ordinal 6 has been added to ``ComponentGroupEnum`` that corresponds to the ``Command`` + signers. + +* ``PartialMerkleTree`` is equipped with a ``leafIndex`` function that returns the index of a hash (leaf) in the + partial Merkle tree structure. + +* A new function ``checkCommandVisibility(publicKey: PublicKey)`` has been added to ``FilteredTransaction`` to check + if every command that a signer should receive (e.g. an Oracle) is indeed visible. + +* Changed the AMQP serializer to use the officially assigned R3 identifier rather than a placeholder. + +* The ``ReceiveTransactionFlow`` can now be told to record the transaction at the same time as receiving it. Using this + feature, better support for observer/regulator nodes has been added. See :doc:`tutorial-observer-nodes`. + +* Added an overload of ``TransactionWithSignatures.verifySignaturesExcept`` which takes in a collection of ``PublicKey`` s. + +* ``DriverDSLExposedInterface`` has been renamed to ``DriverDSL`` and the ``waitForAllNodesToFinish()`` method has instead + become a parameter on driver creation. + +* Values for the ``database.transactionIsolationLevel`` config now follow the ``java.sql.Connection`` int constants but + without the "TRANSACTION" prefix, i.e. "NONE", "READ_UNCOMMITTED", etc. + +* Peer-to-peer communications is now via AMQP 1.0 as default. + Although the legacy Artemis CORE bridging can still be used by setting the ``useAMQPBridges`` configuration property to false. + +* The Artemis topics used for peer-to-peer communication have been changed to be more consistent with future cryptographic + agility and to open up the future possibility of sharing brokers between nodes. This is a breaking wire level change + as it means that nodes after this change will not be able to communicate correctly with nodes running the previous version. + Also, any pending enqueued messages in the Artemis message store will not be delivered correctly to their original target. + However, assuming a clean reset of the artemis data and that the nodes are consistent versions, + data persisted via the AMQP serializer will be forward compatible. + +* The ability for CordaServices to register callbacks so they can be notified of shutdown and clean up resource such as + open ports. + +* Enterprise Corda only: Compatibility with SQL Server 2017 and SQL Azure databases. + +* Enterprise Corda only: node configuration property ``database.schema`` and documented existing database properties. + +* Enterprise Corda only: Compatibility with PostgreSQL 9.6 database. + +* Enterprise Corda only: Compatibility with Oracle 11g RC2 and 12c database. + +* Move to a message based control of peer to peer bridge formation to allow for future out of process bridging components. + This removes the legacy Artemis bridges completely, so the ``useAMQPBridges`` configuration property has been removed. + +* A ``CordaInternal`` attribute has been added to identify properties that are not intended to form part of the + public api and as such are not intended for public use. This is alongside the existing ``DoNotImplement`` attribute for classes which + provide Corda functionality to user applications, but should not be implemented by consumers, and any classes which + are defined in ``.internal`` packages, which are also not for public use. + +* Marked ``stateMachine`` on ``FlowLogic`` as ``CordaInternal`` to make clear that is it not part of the public api and is + only for internal use + +* Provided experimental support for specifying your own webserver to be used instead of the default development + webserver in ``Cordform`` using the ``webserverJar`` argument + +* Created new ``StartedMockNode`` and ``UnstartedMockNode`` classes which are wrappers around our MockNode implementation + that expose relevant methods for testing without exposing internals, create these using a ``MockNetwork``. + +* The test utils in ``Expect.kt``, ``SerializationTestHelpers.kt``, ``TestConstants.kt`` and ``TestUtils.kt`` have moved + from the ``net.corda.testing`` package to the ``net.corda.testing.core`` package, and ``FlowStackSnapshot.kt`` has moved to the + ``net.corda.testing.services`` package. Moving existing classes out of the ``net.corda.testing.*`` package + will help make it clearer which parts of the api are stable. Scripts have been provided to smooth the upgrade + process for existing projects in the ``tools\scripts`` directory of the Corda repo. + +* ``TransactionSignature`` includes a new ``partialMerkleTree`` property, required for future support of signing over + multiple transactions at once. + +* Shell (embedded available only in dev mode or via SSH) connects to the node via RPC instead of using the ``CordaRPCOps`` object directly. + To enable RPC connectivity ensure node’s ``rpcSettings.address`` and ``rpcSettings.adminAddress`` settings are present. diff --git a/docs/source/changelog.rst b/docs/source/changelog.rst index ba16ef9b20..45c517f6d8 100644 --- a/docs/source/changelog.rst +++ b/docs/source/changelog.rst @@ -11,6 +11,9 @@ Unreleased * Introduce minimum and target platform version for CorDapps. +* BFT-Smart and Raft notary implementations have been extracted out of node into ``experimental`` CorDapps to emphasise + their experimental nature. Moreover, the BFT-Smart notary will only work in dev mode due to its use of Java serialization. + * Vault storage of contract state constraints metadata and associated vault query functions to retrieve and sort by constraint type. * New overload for ``CordaRPCClient.start()`` method allowing to specify target legal identity to use for RPC call. @@ -26,8 +29,6 @@ Unreleased * Removed experimental feature ``CordformDefinition`` -* Vault query fix: support query by parent classes of Contract State classes (see https://github.com/corda/corda/issues/3714) - * Added ``registerResponderFlow`` method to ``StartedMockNode``, to support isolated testing of responder flow behaviour. * "app", "rpc", "p2p" and "unknown" are no longer allowed as uploader values when importing attachments. These are used @@ -44,11 +45,6 @@ Unreleased don't provide any guarantee the returned port will be available which can result in flaky tests. Use ``PortAllocation.Incremental`` instead. -* The ``corda-bridgserver.jar`` has been renamed to ``corda-firewall.jar`` to be more consistent - with marketing materials and purpose of the jar. Further to this we have also renamed ``bridge.conf`` to ``firewall.conf`` - and within that file the ``bridgeMode`` propety has been modified to ``firewallMode`` for overall consistency. - This will be a breaking change for early adopters and their deployments, but hopefully will be more future proof. - * Docs for IdentityService. assertOwnership updated to correctly state that an UnknownAnonymousPartyException is thrown rather than IllegalStateException. @@ -58,15 +54,10 @@ Unreleased * Remove all references to the out-of-process transaction verification. -* Introduced a hierarchy of ``DatabaseMigrationException``s, allowing ``NodeStartup`` to gracefully inform users of problems related to database migrations before exiting with a non-zero code. - * The class carpenter has a "lenient" mode where it will, during deserialisation, happily synthesis classes that implement interfaces that will have unimplemented methods. This is useful, for example, for object viewers. This can be turned on with ``SerializationContext.withLenientCarpenter``. -* Introduced a grace period before the initial node registration fails if the node cannot connect to the Doorman. - It retries 10 times with a 1 minute interval in between each try. At the moment this is not configurable. - * Added a ``FlowMonitor`` to log information about flows that have been waiting for IO more than a configurable threshold. * H2 database changes: @@ -180,7 +171,7 @@ Unreleased * Added public support for creating ``CordaRPCClient`` using SSL. For this to work the node needs to provide client applications a certificate to be added to a truststore. See :doc:`tutorial-clientrpc-api` -*The node RPC broker opens 2 endpoints that are configured with ``address`` and ``adminAddress``. RPC Clients would connect +* The node RPC broker opens 2 endpoints that are configured with ``address`` and ``adminAddress``. RPC Clients would connect to the address, while the node will connect to the adminAddress. Previously if ssl was enabled for RPC the ``adminAddress`` was equal to ``address``. @@ -234,6 +225,73 @@ Unreleased normal state when it occurs in an input or output position. *This feature is only available on Corda networks running with a minimum platform version of 4.* +Version 3.3 +----------- + +* Vault query fix: support query by parent classes of Contract State classes (see https://github.com/corda/corda/issues/3714) + +* Fixed an issue preventing Shell from returning control to the user when CTRL+C is pressed in the terminal. + +* Fixed a problem that sometimes prevented nodes from starting in presence of custom state types in the database without a corresponding type from installed CorDapps. + +* Introduced a grace period before the initial node registration fails if the node cannot connect to the Doorman. + It retries 10 times with a 1 minute interval in between each try. At the moment this is not configurable. + +* Fixed an error thrown by NodeVaultService upon recording a transaction with a number of inputs greater than the default page size. + +* Changes to the JSON/YAML serialisation format from ``JacksonSupport``, which also applies to the node shell: + + * ``Instant`` and ``Date`` objects are serialised as ISO-8601 formatted strings rather than timestamps + * ``PublicKey`` objects are serialised and looked up according to their Base58 encoded string + * ``Party`` objects can be deserialised by looking up their public key, in addition to their name + * ``NodeInfo`` objects are serialised as an object and can be looked up using the same mechanism as ``Party`` + * ``NetworkHostAndPort`` serialised according to its ``toString()`` + * ``PartyAndCertificate`` is serialised as the name + * ``SerializedBytes`` is serialised by materialising the bytes into the object it represents, and then serialising that + object into YAML/JSON + * ``X509Certificate`` is serialised as an object with key fields such as ``issuer``, ``publicKey``, ``serialNumber``, etc. + The encoded bytes are also serialised into the ``encoded`` field. This can be used to deserialise an ``X509Certificate`` + back. + * ``CertPath`` objects are serialised as a list of ``X509Certificate`` objects. + +* ``fullParties`` boolean parameter added to ``JacksonSupport.createDefaultMapper`` and ``createNonRpcMapper``. If ``true`` + then ``Party`` objects are serialised as JSON objects with the ``name`` and ``owningKey`` fields. For ``PartyAndCertificate`` + the ``certPath`` is serialised. + +* Several members of ``JacksonSupport`` have been deprecated to highlight that they are internal and not to be used + +* ``ServiceHub`` and ``CordaRPCOps`` can now safely be used from multiple threads without incurring in database transaction problems. + +* Fixed an issue preventing out of process nodes started by the ``Driver`` from logging to file. + +* The Vault Criteria API has been extended to take a more precise specification of which class contains a field. This primarily impacts Java users; Kotlin users need take no action. The old methods have been deprecated but still work - the new methods avoid bugs that can occur when JPA schemas inherit from each other. + +* Removed -xmx VM argument from Explorer's Capsule setup. This helps avoiding out of memory errors. + +* Node will now gracefully fail to start if one of the required ports is already in use. + +* Fixed incorrect exception handling in ``NodeVaultService._query()``. + +* Avoided a memory leak deriving from incorrect MappedSchema caching strategy. + +* Fix CORDA-1403 where a property of a class that implemented a generic interface could not be deserialised in + a factory without a serialiser as the subtype check for the class instance failed. Fix is to compare the raw + type. + +* Fix CORDA-1229. Setter-based serialization was broken with generic types when the property was stored + as the raw type, List for example. + +.. _changelog_v3.2: + +Version 3.2 +----------- + +* Doorman and NetworkMap URLs can now be configured individually rather than being assumed to be + the same server. Current ``compatibilityZoneURL`` configurations remain valid. See both :doc:`corda-configuration-file` + and :doc:`permissioning` for details. + +* Table name with a typo changed from ``NODE_ATTCHMENTS_CONTRACTS`` to ``NODE_ATTACHMENTS_CONTRACTS``. + .. _changelog_v3.1: Version 3.1 @@ -242,53 +300,37 @@ Version 3.1 * Update the fast-classpath-scanner dependent library version from 2.0.21 to 2.12.3 .. note:: Whilst this is not the latest version of this library, that being 2.18.1 at time of writing, versions - later than 2.12.3 (including 2.12.4) exhibit a different issue. +later than 2.12.3 (including 2.12.4) exhibit a different issue. -* Added `database.hibernateDialect` node configuration option - -.. _changelog_r3_v3: - -Corda Enterprise 3.0 Developer Preview --------------------------------------- - -* Fix CORDA-1229. Setter-based serialization was broken with generic types when the property was stored as the raw type, List for example. +* Updated the api scanner gradle plugin to work the same way as the version in master. These changes make the api scanner more + accurate and fix a couple of bugs, and change the format of the api-current.txt file slightly. Backporting these changes + to the v3 branch will make it easier for us to ensure that apis are stable for future versions. These changes are + released in gradle plugins version 3.0.10. For more information on the api scanner see + the `documentation `_. * Fixed security vulnerability when using the ``HashAttachmentConstraint``. Added strict check that the contract JARs referenced in a transaction were deployed on the node. -* Node can be shut down abruptly by ``shutdown`` function in `CordaRPCOps` or gracefully (draining flows first) through ``gracefulShutdown`` command from shell. Please refer to ::doc:`shell.rst` for more. +* Fixed node's behaviour on startup when there is no connectivity to network map. Node continues to work normally if it has + all the needed network data, waiting in the background for network map to become available. -* Carpenter Exceptions will be caught internally by the Serializer and rethrown as a ``NotSerializableException`` +.. _changelog_v3: - * Specific details of the error encountered are logged to the node's log file. More information can be enabled by setting the debug level to ``trace`` ; this will cause the full stack trace of the error to be dumped into the log. +Version 3.0 +----------- -* Parsing of ``NodeConfiguration`` will now fail if unknown configuration keys are found. - -* The web server now has its own ``web-server.conf`` file, separate from ``node.conf``. - -* Introduced a placeholder for custom properties within ``node.conf``; the property key is "custom". - -* Property keys with double quotes (e.g. `"key"`) in ``node.conf`` are no longer allowed, for rationale refer to :doc:`corda-configuration-file`. - -* java.math.BigInteger serialization support added. - -* java.security.cert.CRLReason added to the default Whitelist. - -* java.security.cert.X509CRL serialization support added. +* Due to a security risk, the `conflict` property has been removed from `NotaryError.Conflict` error object. It has been replaced + with `consumedStates` instead. The new property no longer specifies the original requesting party and transaction id for + a consumed state. Instead, only the hash of the transaction id is revealed. For more details why this change had to be + made please refer to the release notes. * Added ``NetworkMapCache.getNodesByLegalName`` for querying nodes belonging to a distributed service such as a notary cluster where they all share a common identity. ``NetworkMapCache.getNodeByLegalName`` has been tightened to throw if more than one node with the legal name is found. -* Per CorDapp configuration is now exposed. ``CordappContext`` now exposes a ``CordappConfig`` object that is populated - at CorDapp context creation time from a file source during runtime. - -* Introduced Flow Draining mode, in which a node continues executing existing flows, but does not start new. This is to - support graceful node shutdown/restarts. In particular, when this mode is on, new flows through RPC will be rejected, - scheduled flows will be ignored, and initial session messages will not be consumed. This will ensure that the number of - checkpoints will strictly diminish with time, allowing for a clean shutdown. - -* Make the serialisation finger-printer a pluggable entity rather than hard wiring into the factory +* Introduced Flow Draining mode, in which a node continues executing existing flows, but does not start new. This is to support graceful node shutdown/restarts. + In particular, when this mode is on, new flows through RPC will be rejected, scheduled flows will be ignored, and initial session messages will not be consumed. + This will ensure that the number of checkpoints will strictly diminish with time, allowing for a clean shutdown. * Removed blacklisted word checks in Corda X.500 name to allow "Server" or "Node" to be use as part of the legal name. @@ -311,28 +353,42 @@ Corda Enterprise 3.0 Developer Preview * JPA Mapping annotations for States extending ``CommonSchemaV1.LinearState`` and ``CommonSchemaV1.FungibleState`` on the `participants` collection need to be moved to the actual class. This allows to properly specify the unique table name per a collection. See: DummyDealStateSchemaV1.PersistentDummyDealState +* Database schema changes - an H2 database instance of Corda 1.0 and 2.0 cannot be reused for Corda 3.0, listed changes for Vault and Finance module: -* JPA Mapping annotations for States extending ``CommonSchemaV1.LinearState`` and ``CommonSchemaV1.FungibleState`` on the - `participants` collection need to be moved to the actual State class. This allows developers to properly specify - the table name for the `participants` collection. - For an example on how the mapping can be done, see: DummyDealStateSchemaV1.PersistentDummyDealState - -* JDBC drivers for SQL server and PostgresSQL are no longer bundled as part of Corda releases. If you are running a node - on such databases you need to provide the associated driver as described in :doc:`node-database`. + * ``NODE_TRANSACTIONS``: + column ``"TRANSACTION”`` renamed to ``TRANSACTION_VALUE``, serialization format of BLOB stored in the column has changed to AMQP + * ``VAULT_STATES``: + column ``CONTRACT_STATE`` removed + * ``VAULT_FUNGIBLE_STATES``: + column ``ISSUER_REFERENCE`` renamed to ``ISSUER_REF`` and the field size increased + * ``"VAULTSCHEMAV1$VAULTFUNGIBLESTATES_PARTICIPANTS"``: + table renamed to ``VAULT_FUNGIBLE_STATES_PARTS``, + column ``"VAULTSCHEMAV1$VAULTFUNGIBLESTATES_OUTPUT_INDEX"`` renamed to ``OUTPUT_INDEX``, + column ``"VAULTSCHEMAV1$VAULTFUNGIBLESTATES_TRANSACTION_ID"`` renamed to ``TRANSACTION_ID`` + * ``VAULT_LINEAR_STATES``: + type of column ``"UUID"`` changed from ``VARBINARY`` to ``VARCHAR(255)`` - select varbinary column as ``CAST("UUID" AS UUID)`` to get UUID in varchar format + * ``"VAULTSCHEMAV1$VAULTLINEARSTATES_PARTICIPANTS"``: + table renamed to ``VAULT_LINEAR_STATES_PARTS``, + column ``"VAULTSCHEMAV1$VAULTLINEARSTATES_OUTPUT_INDEX"`` renamed to ``OUTPUT_INDEX``, + column ``"VAULTSCHEMAV1$VAULTLINEARSTATES_TRANSACTION_ID"`` renamed to ``TRANSACTION_ID`` + * ``contract_cash_states``: + columns storing Base58 representation of the serialised public key (e.g. ``issuer_key``) were changed to store Base58 representation of SHA-256 of public key prefixed with `DL` + * ``contract_cp_states``: + table renamed to ``cp_states``, column changes as for ``contract_cash_states`` * X.509 certificates now have an extension that specifies the Corda role the certificate is used for, and the role hierarchy is now enforced in the validation code. See ``net.corda.core.internal.CertRole`` for the current implementation until final documentation is prepared. Certificates at ``NODE_CA``, ``WELL_KNOWN_SERVICE_IDENTITY`` and above must - only ever be issued by network services and therefore issuance constraints are not relevant to end users. - The ``TLS`` and ``WELL_KNOWN_LEGAL_IDENTITY`` roles must be issued by the ``NODE_CA`` certificate issued by the + only ever by issued by network services and therefore issuance constraints are not relevant to end users. + The ``TLS``, ``WELL_KNOWN_LEGAL_IDENTITY`` roles must be issued by the ``NODE_CA`` certificate issued by the Doorman, and ``CONFIDENTIAL_IDENTITY`` certificates must be issued from a ``WELL_KNOWN_LEGAL_IDENTITY`` certificate. For a detailed specification of the extension please see :doc:`permissioning`. * The network map service concept has been re-designed. More information can be found in :doc:`network-map`. * The previous design was never intended to be final but was rather a quick implementation in the earliest days of the - Corda project to unblock higher priority items. It suffered from numerous disadvantages including lack of scalability, - as one node was expected to hold open and manage connections to every node on the network; not reliable; hard to defend + Corda project to unblock higher priority items. It suffers from numerous disadvantages including lack of scalability, + as one node is expected to hold open and manage connections to every node on the network; not reliable; hard to defend against DoS attacks; etc. * There is no longer a special network map node for distributing the network map to the other nodes. Instead the network @@ -362,7 +418,7 @@ Corda Enterprise 3.0 Developer Preview all nodes have sufficient memory to validate transactions. * The set of valid notaries has been moved to the network parameters. Notaries are no longer identified by the CN in - their X.500 name. + their X500 name. * Single node notaries no longer have a second separate notary identity. Their main identity *is* their notary identity. Use ``NetworkMapCache.notaryIdentities`` to get the list of available notaries. @@ -371,29 +427,20 @@ Corda Enterprise 3.0 Developer Preview where they all share a common identity. ``NetworkMapCache.getNodeByLegalName`` has been tightened to throw if more than one node with the legal name is found. - * The common name in the node's X.500 legal name is no longer reserved and can be used as part of the node's name. + * The common name in the node's X500 legal name is no longer reserved and can be used as part of the node's name. * Moved ``NodeInfoSchema`` to internal package as the node info's database schema is not part of the public API. This was needed to allow changes to the schema. * Support for external user credentials data source and password encryption [CORDA-827]. -* Integrate database migration tool: http://www.liquibase.org/ : - * The migration files are split per ``MappedSchemas``. (added new property: migrationResource used to point to the resource file containing the db changes corresponding to the JPA entities) - * config flag ``database.initialiseSchema`` was renamed to: ``database.runMigration`` (if true then the migration is run during startup just before hibernate is initialised.) - * config flag: ``database.serverNameTablePrefix`` was removed as we no longer use table prefixes - * New command line argument:``—just-generate-db-migration outputSqlFile``: this will generate the delta from the last release, and will output the resulting sql into the outputSqlFile. It will not write to the db. It will not start the node! - * New command line argument: ``--just-run-db-migration``: this will only run the db migration. It will not start the node! - * Exporting additional JMX metrics (artemis, hibernate statistics) and loading Jolokia agent at JVM startup when using DriverDSL and/or cordformation node runner. -* Removed confusing property ``database.initDatabase``, enabling its guarded behaviour with the dev-mode. +* Removed confusing property database.initDatabase, enabling its guarded behaviour with the dev-mode. In devMode Hibernate will try to create or update database schemas, otherwise it will expect relevant schemas to be present in the database (pre configured via DDL scripts or equivalent), and validate these are correct. -* ``ConfigUtilities`` now read system properties for a node. This allow to specify data source properties at runtime. - * ``AttachmentStorage`` now allows providing metadata on attachments upload - username and filename, currently as plain strings. Those can be then used for querying, utilizing ``queryAttachments`` method of the same interface. @@ -477,14 +524,6 @@ Corda Enterprise 3.0 Developer Preview * The ability for CordaServices to register callbacks so they can be notified of shutdown and clean up resource such as open ports. -* Enterprise Corda only: Compatibility with SQL Server 2017 and SQL Azure databases. - -* Enterprise Corda only: node configuration property ``database.schema`` and documented existing database properties. - -* Enterprise Corda only: Compatibility with PostgreSQL 9.6 database. - -* Enterprise Corda only: Compatibility with Oracle 11g RC2 and 12c database. - * Move to a message based control of peer to peer bridge formation to allow for future out of process bridging components. This removes the legacy Artemis bridges completely, so the ``useAMQPBridges`` configuration property has been removed. @@ -511,29 +550,12 @@ Corda Enterprise 3.0 Developer Preview * ``TransactionSignature`` includes a new ``partialMerkleTree`` property, required for future support of signing over multiple transactions at once. -* Shell (embedded available only in dev mode or via SSH) connects to the node via RPC instead of using the ``CordaRPCOps`` object directly. - To enable RPC connectivity ensure node’s ``rpcSettings.address`` and ``rpcSettings.adminAddress`` settings are present. - -.. _changelog_v2: - -Corda 2.0 ---------- - -* ``OpaqueBytes.bytes`` now returns a clone of its underlying ``ByteArray``, and has been redeclared as ``final``. - This is a minor change to the public API, but is required to ensure that classes like ``SecureHash`` are immutable. - -* ``FlowLogic`` now has a static method called ``sleep`` which can be used in certain circumstances to help with resolving - contention over states in flows. This should be used in place of any other sleep primitive since these are not compatible - with flows and their use will be prevented at some point in the future. Pay attention to the warnings and limitations - described in the documentation for this method. This helps resolve a bug in ``Cash`` coin selection. - A new static property `currentTopLevel` returns the top most `FlowLogic` instance, or null if not in a flow. - * Updating Jolokia dependency to latest version (includes security fixes) .. _changelog_v1: -Corda 1.0 ---------- +Release 1.0 +----------- * Unification of VaultQuery And VaultService APIs Developers now only need to work with a single Vault Service API for all needs. @@ -779,3 +801,936 @@ Corda 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 +------------ + +* 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 ``legalIdentitiesAndCert`` entries 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 ``QueryCriteria``. + +* ``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 + overridden 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 principal 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, 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() + +* 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 +------------ + +Special thank you to `Frederic Dalibard `_, for his contribution which adds +support for more currencies to the DemoBench and Explorer tools. + +* A new Vault Query service: + + * Implemented using JPA and Hibernate, this new service provides the ability to specify advanced queries using + criteria specification sets for both vault attributes and custom contract specific attributes. In addition, new + queries provide sorting and pagination capabilities. + The new API provides two function variants which are exposed for usage within Flows and by RPC clients: + + - ``queryBy()`` for point-in-time snapshot queries + (replaces several existing VaultService functions and a number of Kotlin-only extension functions) + - ``trackBy()`` for snapshot and streaming updates + (replaces the VaultService ``track()`` function and the RPC ``vaultAndUpdates()`` function) + + Existing VaultService API methods will be maintained as deprecated until the following milestone release. + + * The NodeSchema service has been enhanced to automatically generate mapped objects for any ContractState objects + that extend FungibleAsset or LinearState, such that common attributes of those parent states are persisted to + two new vault tables: vault_fungible_states and vault_linear_states (and thus queryable using the new Vault Query + service API). + Similarly, two new common JPA superclass schemas (``CommonSchemaV1.FungibleState`` and + ``CommonSchemaV1.LinearState``) mirror the associated FungibleAsset and LinearState interface states to enable + CorDapp developers to create new custom schemas by extension (rather than duplication of common attribute mappings) + + * A new configurable field ``requiredSchemas`` has been added to the CordaPluginRegistry to enable CorDapps to + register custom contract state schemas they wish to query using the new Vault Query service API (using the + ``VaultCustomQueryCriteria``). + + * See :doc:`api-vault-query` for full details and code samples of using the new Vault Query service. + +* Identity and cryptography related changes: + + * Enable certificate validation in most scenarios (will be enforced in all cases in an upcoming milestone). + + * Added DER encoded format for CompositeKey so they can be used in X.509 certificates. + + * Corrected several tests which made assumptions about counterparty keys, which are invalid when confidential + identities are used. + + * A new RPC has been added to support fuzzy matching of X.500 names, for instance, to translate from user input to + an unambiguous identity by searching the network map. + + * A function for deterministic key derivation ``Crypto.deriveKeyPair(privateKey: PrivateKey, seed: ByteArray)`` + has been implemented to support deterministic ``KeyPair`` derivation using an existing private key and a seed + as inputs. This operation is based on the HKDF scheme and it's a variant of the hardened parent-private -> + child-private key derivation function of the BIP32 protocol, but it doesn't utilize extension chain codes. + Currently, this function supports the following schemes: ECDSA secp256r1 (NIST P-256), ECDSA secp256k1 and + EdDSA ed25519. + +* A new ``ClassWhitelist`` implementation, ``AllButBlacklisted`` is used internally to blacklist classes/interfaces, + which are not expected to be serialised during checkpoints, such as ``Thread``, ``Connection`` and ``HashSet``. + This implementation supports inheritance and if a superclass or superinterface of a class is blacklisted, so is + the class itself. An ``IllegalStateException`` informs the user if a class is blacklisted and such an exception is + returned before checking for ``@CordaSerializable``; thus, blacklisting precedes annotation checking. + +* ``TimeWindow`` has a new 5th factory method ``TimeWindow.fromStartAndDuration(fromTime: Instant, duration: Duration)`` + which takes a start-time and a period-of-validity (after this start-time) as inputs. + +* The node driver has moved to net.corda.testing.driver in the test-utils module. + +* Web API related collections ``CordaPluginRegistry.webApis`` and ``CordaPluginRegistry.staticServeDirs`` moved to + ``net.corda.webserver.services.WebServerPluginRegistry`` in ``webserver`` module. + Classes serving Web API should now extend ``WebServerPluginRegistry`` instead of ``CordaPluginRegistry`` + and they should be registered in ``resources/META-INF/services/net.corda.webserver.services.WebServerPluginRegistry``. + +* Added a flag to the driver that allows the running of started nodes in-process, allowing easier debugging. + To enable use `driver(startNodesInProcess = true) { .. }`, or `startNode(startInSameProcess = true, ..)` + to specify for individual nodes. + +* Dependencies changes: + * Upgraded Dokka to v0.9.14. + * Upgraded Gradle Plugins to 0.12.4. + * Upgraded Apache ActiveMQ Artemis to v2.1.0. + * Upgraded Netty to v4.1.9.Final. + * Upgraded BouncyCastle to v1.57. + * Upgraded Requery to v1.3.1. + +.. _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: + + * ``CordaPluginRegistry.requiredFlows`` is no longer needed. Instead annotate any flows you wish to start via RPC with + ``@StartableByRPC`` and any scheduled flows with ``@SchedulableFlow``. + + * ``CordaPluginRegistry.servicePlugins`` is also no longer used, along with ``PluginServiceHub.registerFlowInitiator``. + Instead annotate your initiated flows with ``@InitiatedBy``. This annotation takes a single parameter which is the + initiating flow. This initiating flow further has to be annotated with ``@InitiatingFlow``. For any services you + may have, such as oracles, annotate them with ``@CordaService``. These annotations will be picked up automatically + when the node starts up. + + * Due to these changes, when unit testing flows make sure to use ``AbstractNode.registerInitiatedFlow`` so that the flows + are wired up. Likewise for services use ``AbstractNode.installCordaService``. + + * Related to ``InitiatingFlow``, the ``shareParentSessions`` boolean parameter of ``FlowLogic.subFlow`` has been + removed. This was an unfortunate parameter that unnecessarily exposed the inner workings of flow sessions. Now, if + your sub-flow can be started outside the context of the parent flow then annotate it with ``@InitiatingFlow``. If + it's meant to be used as a continuation of the existing parent flow, such as ``CollectSignaturesFlow``, then it + doesn't need any annotation. + + * The ``InitiatingFlow`` annotation also has an integer ``version`` property which assigns the initiating flow a version + number, defaulting to 1 if it's not specified. This enables versioning of flows with nodes only accepting communication + if the version number matches. At some point we will support the ability for a node to have multiple versions of the + same flow registered, enabling backwards compatibility of flows. + + * ``ContractUpgradeFlow.Instigator`` has been renamed to just ``ContractUpgradeFlow``. + + * ``NotaryChangeFlow.Instigator`` has been renamed to just ``NotaryChangeFlow``. + + * ``FlowLogic.getCounterpartyMarker`` is no longer used and been deprecated for removal. If you were using this to + manage multiple independent message streams with the same party in the same flow then use sub-flows instead. + +* There are major changes to the ``Party`` class as part of confidential identities: + + * ``Party`` has moved to the ``net.corda.core.identity`` package; there is a deprecated class in its place for + backwards compatibility, but it will be removed in a future release and developers should move to the new class as soon + as possible. + * There is a new ``AbstractParty`` superclass to ``Party``, which contains just the public key. This now replaces + use of ``Party`` and ``PublicKey`` in state objects, and allows use of full or anonymised parties depending on + use-case. + * A new ``PartyAndCertificate`` class has been added which aggregates a Party along with an X.509 certificate and + certificate path back to a network trust root. This is used where a Party and its proof of identity are required, + for example in identity registration. + * Names of parties are now stored as a ``X500Name`` rather than a ``String``, to correctly enforce basic structure of the + name. As a result all node legal names must now be structured as X.500 distinguished names. + +* The identity management service takes an optional network trust root which it will validate certificate paths to, if + provided. A later release will make this a required parameter. + +* There are major changes to transaction signing in flows: + + * You should use the new ``CollectSignaturesFlow`` and corresponding ``SignTransactionFlow`` which handle most + of the details of this for you. They may get more complex in future as signing becomes a more featureful + operation. ``ServiceHub.legalIdentityKey`` no longer returns a ``KeyPair``, it instead returns just the + ``PublicKey`` portion of this pair. The ``ServiceHub.notaryIdentityKey`` has changed similarly. The goal of this + change is to keep private keys encapsulated and away from most flow code/Java code, so that the private key + material can be stored in HSMs and other key management devices. + * The ``KeyManagementService`` no longer provides any mechanism to request the node's ``PrivateKey`` objects directly. + Instead signature creation occurs in the ``KeyManagementService.sign``, with the ``PublicKey`` used to indicate + which of the node's keypairs to use. This lookup also works for ``CompositeKey`` scenarios + and the service will search for a leaf key hosted on the node. + * The ``KeyManagementService.freshKey`` method now returns only the ``PublicKey`` portion of the newly generated ``KeyPair`` + with the ``PrivateKey`` kept internally to the service. + * Flows which used to acquire a node's ``KeyPair``, typically via ``ServiceHub.legalIdentityKey``, + should instead use the helper methods on ``ServiceHub``. In particular to freeze a ``TransactionBuilder`` and + generate an initial partially signed ``SignedTransaction`` the flow should use ``ServiceHub.toSignedTransaction``. + Flows generating additional party signatures should use ``ServiceHub.createSignature``. Each of these methods is + provided with two signatures. One version that signs with the default node key, the other which allows key selection + by passing in the ``PublicKey`` partner of the desired signing key. + * The original ``KeyPair`` signing methods have been left on the ``TransactionBuilder`` and ``SignedTransaction``, but + should only be used as part of unit testing. + +* ``Timestamp`` used for validation/notarization time-range has been renamed to ``TimeWindow``. + There are now 4 factory methods ``TimeWindow.fromOnly(fromTime: Instant)``, + ``TimeWindow.untilOnly(untilTime: Instant)``, ``TimeWindow.between(fromTime: Instant, untilTime: Instant)`` and + ``TimeWindow.withTolerance(time: Instant, tolerance: Duration)``. + Previous constructors ``TimeWindow(fromTime: Instant, untilTime: Instant)`` and + ``TimeWindow(time: Instant, tolerance: Duration)`` have been removed. + +* The Bouncy Castle library ``X509CertificateHolder`` class is now used in place of ``X509Certificate`` in order to + have a consistent class used internally. Conversions to/from ``X509Certificate`` are done as required, but should + be avoided where possible. + +* The certificate hierarchy has been changed in order to allow corda node to sign keys with proper certificate chain. + * The corda node will now be issued a restricted client CA for identity/transaction key signing. + * TLS certificate are now stored in `sslkeystore.jks` and identity keys are stored in `nodekeystore.jks` + +.. warning:: The old keystore will need to be removed when upgrading to this version. + +Milestone 11.1 +-------------- + +* Fix serialisation error when starting a flow. +* Automatically whitelist subclasses of `InputStream` when serialising. +* Fix exception in DemoBench on Windows when loading CorDapps into the Node Explorer. +* Detect when localhost resolution is broken on MacOSX, and provide instructions on how to fix it. + +Milestone 11.0 +-------------- + +* API changes: + * Added extension function ``Database.transaction`` to replace ``databaseTransaction``, which is now deprecated. + + * Starting a flow no longer enables progress tracking by default. To enable it, you must now invoke your flow using + one of the new ``CordaRPCOps.startTrackedFlow`` functions. ``FlowHandle`` is now an interface, and its ``progress: Observable`` + field has been moved to the ``FlowProgressHandle`` child interface. Hence developers no longer need to invoke ``notUsed`` + on their flows' unwanted progress-tracking observables. + + * Moved ``generateSpend`` and ``generateExit`` functions into ``OnLedgerAsset`` from the vault and + ``AbstractConserveAmount`` clauses respectively. + + * Added ``CompositeSignature`` and ``CompositeSignatureData`` as part of enabling ``java.security`` classes to work + with composite keys and signatures. + + * ``CompositeKey`` now implements ``java.security.PublicKey`` interface, so that keys can be used on standard classes + such as ``Certificate``. + + * There is no longer a need to transform single keys into composite - ``composite`` extension was removed, it is + impossible to create ``CompositeKey`` with only one leaf. + + * Constructor of ``CompositeKey`` class is now private. Use ``CompositeKey.Builder`` to create a composite key. + Keys emitted by the builder are normalised so that it's impossible to create a composite key with only one node. + (Long chains of single nodes are shortened.) + + * Use extension function ``PublicKeys.keys`` to access all keys belonging to an instance of ``PublicKey``. For a + ``CompositeKey``, this is equivalent to ``CompositeKey.leafKeys``. + + * Introduced ``containsAny``, ``isFulfilledBy``, ``keys`` extension functions on ``PublicKey`` - ``CompositeKey`` + type checking is done there. + +* Corda now requires JDK 8u131 or above in order to run. Our Kotlin now also compiles to JDK8 bytecode, and so you'll need + to update your CorDapp projects to do the same. E.g. by adding this to ``build.gradle``: + +.. parsed-literal:: + + tasks.withType(org.jetbrains.kotlin.gradle.tasks.KotlinCompile).all { + kotlinOptions { + languageVersion = "1.1" + apiVersion = "1.1" + jvmTarget = "1.8" + } + } + +.. + + or by adjusting ``Settings/Build,Execution,Deployment/Compiler/KotlinCompiler`` in IntelliJ:: + + - Language Version: 1.1 + - API Version: 1.1 + - Target JVM Version: 1.8 + +* DemoBench is now installed as ``Corda DemoBench`` instead of ``DemoBench``. + +* Rewrote standard test identities to have full X.500 distinguished names. As part of this work we standardised on a + smaller set of test identities, to reduce risk of subtle differences (i.e. similar common names varying by whitespace) + in naming making it hard to diagnose issues. + +Milestone 10.0 +-------------- + +Special thank you to `Qian Hong `_, `Marek Skocovsky `_, +`Karel Hajek `_, and `Jonny Chiu `_ for their contributions +to Corda in M10. + +.. warning:: Due to incompatibility between older version of IntelliJ and gradle 3.4, you will need to upgrade Intellij +to 2017.1 (with kotlin-plugin v1.1.1) in order to run Corda demos in IntelliJ. You can download the latest IntelliJ + from `JetBrains `_. + +.. warning:: The Kapt-generated models are no longer included in our codebase. If you experience ``unresolved references`` +errors when building in IntelliJ, please rebuild the schema model by running ``gradlew kaptKotlin`` in Windows or + ``./gradlew kaptKotlin`` in other systems. Alternatively, perform a full gradle build or install. + +.. note:: Kapt is used to generate schema model and entity code (from annotations in the codebase) using the Kotlin Annotation +processor. + +* 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. + + * Download `Corda DemoBench `_. + +* 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 `_ 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. + + +Milestone 9.1 +------------- + +* Correct web server ports for IRS demo. +* Correct which corda-webserver JAR is published to Maven. + +Milestone 9 +----------- + +* With thanks to `Thomas Schroeter `_ for the Byzantine fault tolerant (BFT) + notary prototype. +* Web server is a separate JAR. This is a breaking change. The new webserver JAR (``corda-webserver.jar``) + must be invoked separately to node startup, using the command``java -jar corda-webserver.jar`` in the same + directory as the ``node.conf``. Further changes are anticipated in upcoming milestone releases. + +* API: + + * Pseudonymous ``AnonymousParty`` class added as a superclass of ``Party``. + * Split ``CashFlow`` into individual ``CashIssueFlow``, ``CashPaymentFlow`` and ``CashExitFlow`` flows, so that fine + grained permissions can be applied. Added ``CashFlowCommand`` for use-cases where cash flow triggers need to be + captured in an object that can be passed around. + * ``CordaPluginRegistry`` method ``registerRPCKryoTypes`` is renamed ``customizeSerialization`` and the argument + types now hide the presence of Kryo. + * New extension functions for encoding/decoding to base58, base64, etc. See + ``core/src/main/kotlin/net/corda/core/crypto/EncodingUtils.kt`` + * Add ``openAttachment`` function to Corda RPC operations, for downloading an attachment from a node's data storage. + * Add ``getCashBalances`` function to Corda RPC operations, for getting cash balances from a node's vault. + +* Configuration: + * ``extraAdvertisedServiceIds`` config is now a list of strings, rather than a comma separated string. For example + ``[ "corda.interest_rates" ]`` instead of ``"corda.interest_rates"``. + +* Flows: + * Split ``CashFlow`` into separate ``CashIssueFlow``, ``CashPaymentFlow`` and ``CashExitFlow`` so that permissions can + be assigned individually. + * Split single example user into separate "bankUser" and "bigCorpUser" so that permissions for the users make sense + rather than being a combination of both roles. + * ``ProgressTracker`` emits exception thrown by the flow, allowing the ANSI renderer to correctly stop and print the error + +* Object Serialization: + + * Consolidated Kryo implementations across RPC and P2P messaging with whitelisting of classes via plugins or with + ``@CordaSerializable`` for added node security. + +* Privacy: + * Non-validating notary service now takes in a ``FilteredTransaction`` so that no potentially sensitive transaction + details are unnecessarily revealed to the notary + +* General: + * Add vault service persistence using Requery + * Certificate signing utility output is now more verbose + +Milestone 8 +----------- + +* Node memory usage and performance improvements, demo nodes now only require 200 MB heap space to run. + +* The Corda node no longer runs an internal web server, it's now run in a separate process. Driver and Cordformation have + been updated to reflect this change. Existing CorDapps should be updated with additional calls to the new ``startWebserver()`` + interface in their Driver logic (if they use the driver e.g. in integration tests). See the IRS demo for an example. + +* Data model: ``Party`` equality is now based on the owning key, rather than the owning key and name. This is important for + party anonymisation to work, as each key must identify exactly one party. + +* Contracts: created new composite clauses called ``AllOf``, ``AnyOf`` and ``FirstOf`` to replace ``AllComposition``, ``AnyComposition`` + and ``FirstComposition``, as this is significantly clearer in intent. ``AnyOf`` also enforces that at least one subclause + must match, whereas ``AnyComposition`` would accept no matches. + +* Explorer: the user can now configure certificate path and keystore/truststore password on the login screen. + +* Documentation: + + * Key Concepts section revamped with new structure and content. + * Added more details to :doc:`getting-set-up` page. + +* Flow framework: improved exception handling with the introduction of ``FlowException``. If this or a subtype is thrown + inside a flow it will propagate to all counterparty flows and subsequently be thrown by them as well. Existing flows such as + ``NotaryFlow.Client/Service`` and others have been modified to throw a ``FlowException`` (in this particular case a + ``NotaryException``) instead of sending back error responses. + +* Notary flow: provide complete details of underlying error when contract validation fails. + +Milestone 7 +----------- + +* With thanks to `Thomas Schroeter `_ ``NotaryFlow`` is now idempotent. + +* Explorer: + + * The GUI for the explorer now shows other nodes on the network map and the transactions between them. + * Map resolution increased and allows zooming and panning. + * `Video demonstration `_ of the Node Explorer. + +* The CorDapp template now has a Java example that parallels the Kotlin one for developers more comfortable with Java. + ORM support added to the Kotlin example. + +* Demos: + + * Added the Bank of Corda demo - a demo showing a node (Bank of Corda) acting as an issuer of Cash, and a client + driver providing both Web and RPC access to request issuance of cash. + * Demos now use RPC to communicate with the node from the webserver. This brings the demos more in line with how + interaction with nodes is expected to be. The demos now treat their webservers like clients. This will also allow + for the splitting of the webserver from the node for milestone 8. + * Added a SIMM valuation demo integration test to catch regressions. + +* Security: + + * MQ broker of the node now requires authentication which means that third parties cannot connect to and + listen to queues on the Node. RPC and P2P between nodes is now authenticated as a result of this change. + This also means that nodes or RPC users cannot pretend to be other nodes or RPC users. + * The node now does host verification of any node that connects to it and prevents man in the middle attacks. + +* Improvements: + + * Vault updates now contain full ``StateAndRef`` which allows subscribers to check whether the update contains + relevant states. + * Cash balances are calculated using aggregate values to prevent iterating through all states in the vault, which + improves performance. + * Multi-party services, such as notaries, are now load balanced and represented as a single ``Party`` object. + * The Notary Change flow now supports encumbrances. + +Milestone 6 +----------- + +* Added the `Corda technical white paper <_static/corda-technical-whitepaper.pdf>`_. Note that its current version + is 0.5 to reflect the fact that the Corda design is still evolving. Although we expect only relatively small tweaks + at this point, when Corda reaches 1.0 so will the white paper. + +* Major documentation restructuring and new content: + + * More details on Corda node internals. + * New CorDapp tutorial. + * New tutorial on building transactions. + * New tutorials on how to run and use a notary service. + +* An experimental version of the deterministic JVM sandbox has been added. It is not integrated with the node and will + undergo some significant changes in the coming releases before it is integrated, as the code is finished, as bugs are + found and fixed, and as the platform subset we choose to expose is finalised. Treat this as an outline of the basic + approach rather than something usable for production. + +* Developer experience: + + * Samples have been merged back into the main repository. All samples can now be run via command line or IntelliJ. + + * Added a Client RPC python example. + + * Node console output now displays concise startup information, such as startup time or web address. All logging to + the console is suppressed apart from errors and flow progress tracker steps. It can be re-enabled by passing + ``--log-to-console`` command line parameter. Note that the log file remains unchanged and will still contain all + log entries. + + * The ``runnodes`` scripts generated by the Gradle plugins now open each node in separate terminal windows or (on macOS) tabs. + + * A much more complete template app. + + * JARs now available on Maven Central. + +* Data model: A party is now identified by a composite key (formerly known as a "public key tree") instead of a single public key. + Read more in :ref:`composite-keys`. This allows expressing distributed service identities, e.g. a distributed notary. + In the future this will also allow parties to use multiple signing keys for their legal identity. + +* Decentralised consensus: A prototype RAFT based notary composed of multiple nodes has been added. This implementation + is optimised for high performance over robustness against malicious cluster members, which may be appropriate for + some financial situations. + +* Node explorer app: + + * New theme aligned with the Corda branding. + * The New Transaction screen moved to the Cash View (as it is used solely for cash transactions) + * Removed state machine/flow information from Transaction table. A new view for this will be created in a future release. + * Added a new Network View that displays details of all nodes on the network. + * Users can now configure the reporting currency in settings. + * Various layout and performance enhancements. + +* Client RPC: + + * Added a generic ``startFlow`` method that enables starting of any flow, given sufficient permissions. + * Added the ability for plugins to register additional classes or custom serialisers with Kryo for use in RPC. + * ``rpc-users.properties`` file has been removed with RPC user settings moved to the config file. + +* Configuration changes: It is now possible to specify a custom legal name for any of the node's advertised services. + +* Added a load testing framework which allows stress testing of a node cluster, as well as specifying different ways of + disrupting the normal operation of nodes. See :doc:`loadtesting`. + +* Improvements to the experimental contract DSL, by Sofus Mortensen of Nordea Bank (please give Nordea a shoutout too). + +API changes: + +* The top level package has been renamed from ``com.r3corda`` to ``net.corda``. +* Protocols have been renamed to "flows". +* ``OpaqueBytes`` now uses ``bytes`` as the field name rather than ``bits``. + +Milestone 5 +----------- + +* A simple RPC access control mechanism. Users, passwords and permissions can be defined in a configuration file. + This mechanism will be extended in future to support standard authentication systems like LDAP. + +* New features in the explorer app and RPC API for working with cash: + + * Cash can now be sent, issued and exited via RPC. + * Notes can now be associated with transactions. + * Hashes are visually represented using identicons. + * Lots of functional work on the explorer UI. You can try it out by running ``gradle tools:explorer:runDemoNodes`` to run + a local network of nodes that swap cash with each other, and then run ``gradle tools:explorer:run`` to start + the app. + +* A new demo showing shared valuation of derivatives portfolios using the ISDA SIMM has been added. Note that this app + relies on a proprietary implementation of the ISDA SIMM business logic from OpenGamma. A stub library is provided + to ensure it compiles but if you want to use the app for real please contact us. + +* Developer experience (we plan to do lots more here in milestone 6): + + * Demos and samples have been split out of the main repository, and the initial developer experience continues to be + refined. All necessary JARs can now be installed to Maven Local by simply running ``gradle install``. + * It's now easier to define a set of nodes to run locally using the new "CordFormation" gradle plugin, which + defines a simple DSL for creating networks of nodes. + * The template CorDapp has been upgraded with more documentation and showing more features. + +* Privacy: transactions are now structured as Merkle trees, and can have sections "torn off" - presented for + verification and signing without revealing the rest of the transaction. + +* Lots of bug fixes, tweaks and polish starting the run up to the open source release. + +API changes: + +* Plugin service classes now take a ``PluginServiceHub`` rather than a ``ServiceHubInternal``. +* ``UniqueIdentifier`` equality has changed to only take into account the underlying UUID. +* The contracts module has been renamed to finance, to better reflect what it is for. + +Milestone 4 +----------- + +New features in this release: + +* Persistence: + + * States can now be written into a relational database and queried using JDBC. The schemas are defined by the + smart contracts and schema versioning is supported. It is reasonable to write an app that stores data in a mix + of global ledger transactions and local database tables which are joined on demand, using join key slots that + are present in many state definitions. Read more about :doc:`api-persistence`. + * The embedded H2 SQL database is now exposed by default to any tool that can speak JDBC. The database URL is + printed during node startup and can be used to explore the database, which contains both node internal data + and tables generated from ledger states. + * Protocol checkpoints are now stored in the database as well. Message processing is now atomic with protocol + checkpointing and run under the same RDBMS transaction. + * MQ message deduplication is now handled at the app layer and performed under the RDMS transaction, so + ensuring messages are only replayed if the RDMS transaction rolled back. + * "The wallet" has been renamed to "the vault". + +* Client RPC: + + * New RPCs added to subscribe to snapshots and update streams state of the vault, currently executing protocols + and other important node information. + * New tutorial added that shows how to use the RPC API to draw live transaction graphs on screen. + +* Protocol framework: + + * Large simplifications to the API. Session management is now handled automatically. Messages are now routed + based on identities rather than node IP addresses. + +* Decentralised consensus: + + * A standalone one-node notary backed by a JDBC store has been added. + * A prototype RAFT based notary composed of multiple nodes is available on a branch. + +* Data model: + + * Compound keys have been added as preparation for merging a distributed RAFT based notary. Compound keys + are trees of public keys in which interior nodes can have validity thresholds attached, thus allowing + boolean formulas of keys to be created. This is similar to Bitcoin's multi-sig support and the data model + is the same as the InterLedger Crypto-Conditions spec, which should aid interoperate in future. Read more about + key trees in the ":doc:`api-core-types`" article. + * A new tutorial has been added showing how to use transaction attachments in more detail. + +* Testnet + + * Permissioning infrastructure phase one is built out. The node now has a notion of developer mode vs normal + mode. In developer mode it works like M3 and the SSL certificates used by nodes running on your local + machine all self-sign using a developer key included in the source tree. When developer mode is not active, + the node won't start until it has a signed certificate. Such a certificate can be obtained by simply running + an included command line utility which generates a CSR and submits it to a permissioning service, then waits + for the signed certificate to be returned. Note that currently there is no public Corda testnet, so we are + not currently running a permissioning service. + +* Standalone app development: + + * The Corda libraries that app developers need to link against can now be installed into your local Maven + repository, where they can then be used like any other JAR. See :doc:`running-a-node`. + +* User interfaces: + + * Infrastructure work on the node explorer is now complete: it is fully switched to using the MQ based RPC system. + * A library of additional reactive collections has been added. This API builds on top of Rx and the observable + collections API in Java 8 to give "live" data structures in which the state of the node and ledger can be + viewed as an ordinary Java ``List``, ``Map`` and ``Set``, but which also emit callbacks when these views + change, and which can have additional views derived in a functional manner (filtered, mapped, sorted, etc). + Finally, these views can then be bound directly into JavaFX UIs. This makes for a concise and functional + way of building application UIs that render data from the node, and the API is available for third party + app developers to use as well. We believe this will be highly productive and enjoyable for developers who + have the option of building JavaFX apps (vs web apps). + * The visual network simulator tool that was demoed back in April as part of the first Corda live demo has + been merged into the main repository. + +* Documentation + + * New secure coding guidelines. Corda tries to eliminate as many security mistakes as practical via the type + system and other mechanically checkable processes, but there are still things that one must be aware of. + * New attachments tutorial. + * New Client RPC tutorial. + * More tutorials on how to build a standalone CorDapp. + +* Testing + + * More integration testing support + * New micro-DSLs for expressing expected sequences of operations with more or less relaxed ordering constraints. + * QuickCheck generators to create streams of randomised transactions and other basic types. QuickCheck is a way + of writing unit tests that perform randomised fuzz testing of code, originally developed by the Haskell + community and now also available in Java. + +API changes: + +* The transaction types (Signed, Wire, LedgerTransaction) have moved to ``net.corda.core.transactions``. You can + update your code by just deleting the broken import lines and letting your IDE re-import them from the right + location. +* ``AbstractStateReplacementProtocol.verifyProposal`` has changed its prototype in a minor way. +* The ``UntrustworthyData.validate`` method has been renamed to ``unwrap`` - the old name is now deprecated. +* The wallet, wallet service, etc. are now vault, vault service, etc. These better reflect the intent that they + are a generic secure data store, rather than something which holds cash. +* The protocol send/receive APIs have changed to no longer require a session id. Please check the current version + of the protocol framework tutorial for more details. + +Milestone 3 +----------- + +* More work on preparing for the testnet: + + * Corda is now a standalone app server that loads "CorDapps" into itself as plugins. Whilst the existing IRS + and trader demos still exist for now, these will soon be removed and there will only be a single Corda node + program. Note that the node is a single, standalone jar file that is easier to execute than the demos. + * Project Vega (shared SIMM modelling for derivative portfolios) has already been converted to be a CorDapp. + * Significant work done on making the node persist its wallet data to a SQL backend, with more on the way. + * Upgrades and refactorings of the core transaction types in preparation for the incoming sandboxing work. + +* The Clauses API that seeks to make writing smart contracts easier has gone through another design iteration, + with the result that clauses are now cleaner and more composable. +* Improvements to the protocol API for finalising transactions (notarising, transmitting and storing). +* Lots of work done on an MQ based client API. +* Improvements to the developer site: + + * The developer site has been re-read from start to finish and refreshed for M3 so there should be no obsolete + texts or references anywhere. + * The Corda non-technical white paper is now a part of the developer site and git repository. The LaTeX source is + also provided so if you spot any issues with it, you can send us patches. + * There is a new section on how to write CorDapps. + +* Further R&D work by Sofus Mortensen in the experimental module on a new 'universal' contract language. +* SSL for the REST API and webapp server can now be configured. + + +Milestone 2 +----------- + +* Big improvements to the interest rate swap app: + + * A new web app demonstrating the IRS contract has been added. This can be used as an example for how to interact with + the Corda API from the web. + * Simplifications to the way the demo is used from the command line. + * :doc:`Detailed documentation on how the contract works and can be used ` has been written. + * Better integration testing of the app. + +* Smart contracts have been redesigned around reusable components, referred to as "clauses". The cash, commercial paper + and obligation contracts now share a common issue clause. +* New code in the experimental module (note that this module is a place for work-in-progress code which has not yet gone + through code review and which may, in general, not even function correctly): + + * Thanks to the prolific Sofus Mortensen @ Nordea Bank, an experimental generic contract DSL that is based on the famous + 2001 "Composing contracts" paper has been added. We thank Sofus for this great and promising research, which is so + relevant in the wake of the DAO hack. + * The contract code from the recent trade finance demos is now in experimental. This code comes thanks to a + collaboration of the members; all credit to: + + * Mustafa Ozturk @ Natixis + * David Nee @ US Bank + * Johannes Albertsen @ Dankse Bank + * Rui Hu @ Nordea + * Daniele Barreca @ Unicredit + * Sukrit Handa @ Scotiabank + * Giuseppe Cardone @ Banco Intesa + * Robert Santiago @ BBVA + +* The usability of the command line demo programs has been improved. +* All example code and existing contracts have been ported to use the new Java/Kotlin unit testing domain-specific + languages (DSLs) which make it easy to construct chains of transactions and verify them together. This cleans up + and unifies the previous ad-hoc set of similar DSLs. A tutorial on how to use it has been added to the documentation. + We believe this largely completes our testing story for now around smart contracts. Feedback from bank developers + during the Trade Finance project has indicated that the next thing to tackle is docs and usability improvements in + the protocols API. +* Significant work done towards defining the "CorDapp" concept in code, with dynamic loading of API services and more to + come. +* Inter-node communication now uses SSL/TLS and AMQP/1.0, albeit without all nodes self-signing at the moment. A real + PKI for the p2p network will come later. +* Logging is now saved to files with log rotation provided by Log4J. + +API changes: + +* Some utility methods and extension functions that are specific to certain contract types have moved packages: just + delete the import lines that no longer work and let IntelliJ replace them with the correct package paths. +* The ``arg`` method in the test DSL is now called ``command`` to be consistent with the rest of the data model. +* The messaging APIs have changed somewhat to now use a new ``TopicSession`` object. These APIs will continue to change + in the upcoming releases. +* Clauses now have default values provided for ``ifMatched``, ``ifNotMatched`` and ``requiredCommands``. + +New documentation: + +* :doc:`contract-catalogue` +* :doc:`contract-irs` +* :doc:`tutorial-test-dsl` + +Milestone 1 +----------- + +Highlights of this release: + +* Event scheduling. States in the ledger can now request protocols to be invoked at particular times, for states + considered relevant by the wallet. +* Upgrades to the notary/consensus service support: + + * There is now a way to change the notary controlling a state. + * You can pick between validating and non-validating notaries, these let you select your privacy/robustness trade-off. + +* A new obligation contract that supports bilateral and multilateral netting of obligations, default tracking and + more. +* Improvements to the financial type system, with core classes and contracts made more generic. +* Switch to a better digital signature algorithm: ed25519 instead of the previous JDK default of secp256r1. +* A new integration test suite. +* A new Java unit testing DSL for contracts, similar in spirit to the one already developed for Kotlin users (which + depended on Kotlin specific features). +* An experimental module, where developers who want to work with the latest Corda code can check in contracts/cordapp + code before it's been fully reviewed. Code in this module has compiler warnings suppressed but we will still make + sure it compiles across refactorings. +* Persistence improvements: transaction data is now stored to disk and automatic protocol resume is now implemented. +* Many smaller bug fixes, cleanups and improvements. + +We have new documentation on: + +* :doc:`event-scheduling` +* :doc:`api-core-types` +* :doc:`key-concepts-consensus` + +Summary of API changes (not exhaustive): + +* Notary/consensus service: + + * ``NotaryService`` is now extensible. + * Every ``ContractState`` now has to specify a *participants* field, which is a list of parties that are able to + consume this state in a valid transaction. This is used for e.g. making sure all relevant parties obtain the updated + state when changing a notary. + * Introduced ``TransactionState``, which wraps ``ContractState``, and is used when defining a transaction output. + The notary field is moved from ``ContractState`` into ``TransactionState``. + * Every transaction now has a *type* field, which specifies custom build & validation rules for that transaction type. + Currently two types are supported: General (runs the default build and validation logic) and NotaryChange ( + contract code is not run during validation, checks that the notary field is the only difference between the + inputs and outputs). + ``TransactionBuilder()`` is now abstract, you should use ``TransactionType.General.Builder()`` for building transactions. + +* The cash contract has moved from ``net.corda.contracts`` to ``net.corda.contracts.cash`` +* ``Amount`` class is now generic, to support non-currency types such as physical assets. Where you previously had just + ``Amount``, you should now use ``Amount``. +* Refactored the Cash contract to have a new FungibleAsset superclass, to model all countable assets that can be merged + and split (currency, barrels of oil, etc.) +* Messaging: + + * ``addMessageHandler`` now has a different signature as part of error handling changes. + * If you want to return nothing to a protocol, use ``Ack`` instead of ``Unit`` from now on. + +* In the IRS contract, dateOffset is now an integer instead of an enum. +* In contracts, you now use ``tx.getInputs`` and ``tx.getOutputs`` instead of ``getInStates`` and ``getOutStates``. This is + just a renaming. +* A new ``NonEmptySet`` type has been added for cases where you wish to express that you have a collection of unique + objects which cannot be empty. +* Please use the global ``newSecureRandom()`` function rather than instantiating your own SecureRandom's from now on, as + the custom function forces the use of non-blocking random drivers on Linux. + +Milestone 0 +----------- + +This is the first release, which includes: + +* Some initial smart contracts: cash, commercial paper, interest rate swaps +* An interest rate oracle +* The first version of the protocol/orchestration framework +* Some initial support for pluggable consensus mechanisms +* Tutorials and documentation explaining how it works +* Much more ... \ No newline at end of file diff --git a/docs/source/release-notes-enterprise.rst b/docs/source/release-notes-enterprise.rst new file mode 100644 index 0000000000..2e6f41db71 --- /dev/null +++ b/docs/source/release-notes-enterprise.rst @@ -0,0 +1,158 @@ +Release notes +============= + +|release| +--------- + +This release is the first official release of Corda Enterprise - a commercial distribution of the open source Corda blockchain platform, designed for mission critical enterprise deployments. +|release| supports Linux for production deployments, with Windows and Mac OS support for development and demonstration purposes only. Please refer to product documentation for details. + +|release| is operationally compatible with Open Source Corda 3.x while providing enterprise-grade features and performance. + +Key new features and components +******************************* + +**High Availability** + + This release introduces the Hot-Cold High Availability configuration for Corda Enterprise nodes, which addresses the following requirements: + + - A logical Corda node continues to be available as long as at least one of the clustered physical nodes is available. + - No loss, corruption or duplication of data on the ledger due to component outages. + - Continuity of flows throughout node failures. + - Support for rolling software upgrades in a live network. + + See :ref:`here ` for further details on how to set-up and operate Hot-Cold node HA. + +**Additional Supported SQL Databases** + + :ref:`PostgreSQL 9.6 `, :ref:`Azure SQL and SQL Server 2017 ` and :ref:`Oracle 11g and 12c ` are now supported SQL databases. + Database settings can be specified as part of the node configuration file. + See :doc:`node-database` for further details. + +**Database Management and Migration Tool** + + |release| ships with a tool for tracking, managing and applying database schema migrations. + A framework for data migration provides a way to upgrade the version of Corda Enterprise or installed CorDapps while preserving data integrity and service continuity. It is also used to prepare a database for first use with Corda Enterprise. + Based on `Liquibase `_, the tool also allows exporting DDL and data to a file, allowing DBAs to inspect the SQL or apply the SQL statements and to apply them manually if necessary. + See :ref:`database migration ` for further details. + +**Multi-threaded Flow Processing** + + |release| enables multi-threaded processing of flows, resulting in vastly higher performance than Corda 3.0. In Corda flows are processed on a single thread and + thus individual flow steps are not processed concurrently. Corda Enterprise is able to process multiple flow steps concurrently, the number of which is only limited by + available CPU cores, memory and database configuration. This allows Corda Enterprise to process a greater number + of flows and transactions in a given time frame than Open Source Corda and to truly take advantage of large server + / VM configurations. The number of operating system threads that are used is determined by the ``flowThreadPoolSize`` configuration property. + See :doc:`corda-configuration-file` for further details. + +**New Network Map Architecture** + + This release introduces the new network map architecture. The network map service has been redesigned to enable future increased network scalability and redundancy, reduced runtime operational overhead, + support for multiple notaries, and administration of network compatibility zones (CZ) and business networks. + + A Corda Compatibility Zone (CZ) 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. + See :doc:`Network Map ` and :ref:`bootstrapping the network ` for further details. + +**Corda Firewall** + + |release| introduces the Bridge and Corda Firewall components to enable secure setup of a Corda Node in a DMZ environment. + See :doc:`Corda Firewall Overview ` for further details. + +**Improved Operational Metrics** + + |release| provides additional metrics compared to Corda. A richer collection of information is exported through JMX via :ref:`Jolokia for monitoring `. + +**Operational Compatibility With Open Source Corda** + + |release| provides a baseline for wire stability and compatibility with open-source releases of Corda from version 3.0 onwards. + + It delivers forward compatibility with future versions of Corda Enterprise: + + - Is operationally compatible with future versions of Corda Enterprise. + - Is upgradeable to future version of Corda Enterprise, preserving transaction and other data. + + It delivers operational compatibility with open-source Corda: + + - Can be used in networks seamlessly transacting with nodes running Corda 3.x and future versions. + - Can run CorDapps developed on Corda 3.x and future versions. Note that some database changes may be required to achieve this. See :doc:`node-operations-upgrading` for more information. + - Is compatible with ledger data created using Corda 3.x and future versions. + + Furthermore, the RPC client-server communications transport protocol is now fully AMQP based. + +.. note:: RPC clients communicating with Corda Enterprise nodes must be linked against the enterprise RPC client binaries, because open-source Corda `3.x` does not yet use the AMQP serialisation protocol for RPC communication. + From Corda open-source version `4.x` onwards, the RPC client binaries will be compatible with the enterprise distribution. + +Further improvements, additions and changes +******************************************* + +* Built-in flows have been improved to automatically utilise the new 'hospital' and retry functionality. For example, the :ref:`FinalityFlow ` now enables a node operator to easily address contract constraints validation errors when using mixed CorDapp versions. Furthermore, flows will attempt to automatically replay from their last saved checkpoint when, for example, a race condition has occurred for writing into the database or a database deadlock has been encountered. Flows will also retry notarisation attempts if a Highly Available Notary cluster member does not respond within the acceptable time period. There are configuration options which affect the behaviour of the retry functionality. See :doc:`corda-configuration-file` for further details. + +* |release| nodes will now fail to start if unknown property keys are found in configuration files. Any unsupported property can be moved to the newly introduced "custom" section. See :doc:`corda-configuration-file` for further details. + +* Property keys with double quotes (e.g. `"key"`) in ``node.conf`` are no longer allowed. See :doc:`corda-configuration-file` for further details. + +* Corda's web server now has its own ``web-server.conf`` file, separate from the ``node.conf`` used by the Corda node. See :doc:`corda-configuration-file` for further details. `Note that this module is deprecated and we intend to remove it in the future.` + +* |release| includes a new 'Blob Inspector' tool for viewing the contents of custom binary serialised files (such as ``node-info``, ``network-parameters``) in a human-readable format. + See :doc:`blob-inspector` for further details. + +* |release| introduces additional network parameters (event horizon) and component run-time validation (maximum allowed message size). + The event horizon is the span of time that is allowed to elapse before an offline node is considered to be permanently gone. + +* |release| adds certificate revocation list checking when running a node in a fully operational Corda Network environment backed by Network Services. + See :doc:`certificate-revocation` for further details. + +* |release| nodes support separate configuration parameters for specifying the location of the Doorman and the NetworkMap services independently of each other. + +* RPC Server now masks internal errors in responses returned to RPC clients for enhanced privacy. + +* Miscellaneous changes to the operation of the network bootstrapper tool, and node configuration changes. + + +Known issues +************ + +The following list contains important known issues identified in this release. We will endeavour to fix these in future +releases of Corda. + +* Certificate revocation revokes identities, not keys, and is currently irreversible. If your keys are lost or compromised, + new keys cannot be re-issued with the same X.500/legal entity name. It is strongly advised to backup your certificates + appropriately and to apply sensible policy for management of private keys. + +* The finance CorDapp from Corda 3.0 and 3.1 cannot be used with |release|. + In a mixed-distribution network the finance CorDapp from |release| should be deployed on both Corda 3.0/3.1 and |release| nodes. + This will be fixed in the next release of open source Corda. + +* Explorer GUI does not display correctly HA notaries or multiple notaries. + +* Certain characters in X500 party names prevent flows from being started from the shell [CORDA-1635]. + +* Missing configuration files for a network bootstrapper cause an exception [CORDA-1643]. + Network bootstrapper should gracefully exit with a helpful error message. + +* Java Lambda expressions with named parameters can cause flows to become not startable from shell [CORDA-1658]. + +* Some ``java.time.*`` types cannot be used in mapped (JPA) schemas [CORDA-1392]. + +* |release| does not support class evolution using non-nullable properties [CORDA-1702]. + +Upgrade notes +************* + +As per previous major releases, we have provided a comprehensive upgrade notes (:doc:`upgrade-notes`) to ease the upgrade +of CorDapps to |release|. In line with our commitment to API stability, code level changes are fairly minimal. + +From a build perspective, switching CorDapps built using Corda 3.x to |release| is mostly effortless, +and simply requires making the Corda Enterprise binaries available to Gradle, and changing two variables in the build file: + + +.. sourcecode:: shell + + ext.corda_release_version = '3.0' + ext.corda_release_distribution = 'com.r3.corda' + +.. + +Visit the `https://www.r3.com/corda-enterprise `_ for more information about Corda Enterprise. Customers that have purchased support can access it online at `https://support.r3.com `_. diff --git a/docs/source/release-notes.rst b/docs/source/release-notes.rst index 2e6f41db71..9975c00816 100644 --- a/docs/source/release-notes.rst +++ b/docs/source/release-notes.rst @@ -1,158 +1,984 @@ Release notes ============= -|release| ---------- +.. _release_notes_v4_0: -This release is the first official release of Corda Enterprise - a commercial distribution of the open source Corda blockchain platform, designed for mission critical enterprise deployments. -|release| supports Linux for production deployments, with Windows and Mac OS support for development and demonstration purposes only. Please refer to product documentation for details. +Release 4.0 (Unreleased) +------------------------ -|release| is operationally compatible with Open Source Corda 3.x while providing enterprise-grade features and performance. +Significant Changes in 4.0 +~~~~~~~~~~~~~~~~~~~~~~~~~~ -Key new features and components -******************************* +* **Retirement of non-elliptic Diffie-Hellman for TLS** + The TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 family of ciphers is retired from the list of allowed ciphers for TLS + as it is a legacy cipher family not supported by all native SSL/TLS implementations. -**High Availability** +* **Reference states**: - This release introduces the Hot-Cold High Availability configuration for Corda Enterprise nodes, which addresses the following requirements: + Introduced the concept of "reference input states". A reference input state is a ``ContractState`` which can be referred + to in a transaction by the contracts of input and output states but whose contract is not executed as part of the + transaction verification process and is not consumed when the transaction is committed to the ledger but is checked + for "current-ness". In other words, the contract logic isn't run for the referencing transaction only. It's still a + normal state when it occurs in an input or output position. - - A logical Corda node continues to be available as long as at least one of the clustered physical nodes is available. - - No loss, corruption or duplication of data on the ledger due to component outages. - - Continuity of flows throughout node failures. - - Support for rolling software upgrades in a live network. +<< MORE TO COME >> - See :ref:`here ` for further details on how to set-up and operate Hot-Cold node HA. +.. _release_notes_v3_3: -**Additional Supported SQL Databases** +Release 3.3 +----------- - :ref:`PostgreSQL 9.6 `, :ref:`Azure SQL and SQL Server 2017 ` and :ref:`Oracle 11g and 12c ` are now supported SQL databases. - Database settings can be specified as part of the node configuration file. - See :doc:`node-database` for further details. +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. -**Database Management and Migration Tool** +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. - |release| ships with a tool for tracking, managing and applying database schema migrations. - A framework for data migration provides a way to upgrade the version of Corda Enterprise or installed CorDapps while preserving data integrity and service continuity. It is also used to prepare a database for first use with Corda Enterprise. - Based on `Liquibase `_, the tool also allows exporting DDL and data to a file, allowing DBAs to inspect the SQL or apply the SQL statements and to apply them manually if necessary. - See :ref:`database migration ` for further details. +Changes of Note +~~~~~~~~~~~~~~~ -**Multi-threaded Flow Processing** +* **Serialization fixes** - |release| enables multi-threaded processing of flows, resulting in vastly higher performance than Corda 3.0. In Corda flows are processed on a single thread and - thus individual flow steps are not processed concurrently. Corda Enterprise is able to process multiple flow steps concurrently, the number of which is only limited by - available CPU cores, memory and database configuration. This allows Corda Enterprise to process a greater number - of flows and transactions in a given time frame than Open Source Corda and to truly take advantage of large server - / VM configurations. The number of operating system threads that are used is determined by the ``flowThreadPoolSize`` configuration property. - See :doc:`corda-configuration-file` for further details. + 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. -**New Network Map Architecture** +* **Certificate Hierarchy** - This release introduces the new network map architecture. The network map service has been redesigned to enable future increased network scalability and redundancy, reduced runtime operational overhead, - support for multiple notaries, and administration of network compatibility zones (CZ) and business networks. + 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. - A Corda Compatibility Zone (CZ) 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. - See :doc:`Network Map ` and :ref:`bootstrapping the network ` for further details. + 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. -**Corda Firewall** +Special Thanks +~~~~~~~~~~~~~~ - |release| introduces the Bridge and Corda Firewall components to enable secure setup of a Corda Node in a DMZ environment. - See :doc:`Corda Firewall Overview ` for further details. +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. -**Improved Operational Metrics** +We're therefore happy to extend thanks to the following members of that community for their contributions - |release| provides additional metrics compared to Corda. A richer collection of information is exported through JMX via :ref:`Jolokia for monitoring `. + * `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 `_ -**Operational Compatibility With Open Source Corda** +Issues Fixed +~~~~~~~~~~~~ - |release| provides a baseline for wire stability and compatibility with open-source releases of Corda from version 3.0 onwards. +* Refactoring ``DigitalSignatureWithCertPath`` for more performant storing of the certificate chain. [`CORDA-1995 `_] +* The serializers class carpenter fails when superclass has double-size primitive field. [`Corda-1945 `_] +* If a second identity is mistakenly created the node will not start. [`CORDA-1811 `_] +* Demobench profile load fails with stack dump. [`CORDA-1948 `_] +* Deletes of NodeInfo can fail to propagate leading to infinite retries. [`CORDA-2029 `_] +* Copy all the certificates from the network-trust-store.jks file to the node's trust store. [`CORDA-2012 `_] +* Add SNI (Server Name Indication) header to TLS connections. [`CORDA-2001 `_] +* Fix duplicate index declaration in the Cash schema. [`CORDA-1952 `_] +* Hello World Tutorial Page mismatch between code sample and explanatory text. [`CORDA-1950 `_] +* Java Instructions to Invoke Hello World CorDapp are incorrect. [`CORDA-1949 `_] +* Add ``VersionInfo`` to the ``NodeInfo`` submission request to the network map element of the Compatibility Zone. [`CORDA-1938 `_] +* Rename current INTERMEDIATE_CA certificate role to DOORMAN_CA certificate role. [`CORDA-1934 `_] +* Make node-side network map verification agnostic to the certificate hierarchy. [`CORDA-1932 `_] +* Corda Shell incorrectly deserializes generic types as raw types. [`CORDA-1907 `_] +* The Corda web server does not support asynchronous servlets. [`CORDA-1906 `_] +* Amount is deserialized from JSON and YAML as Amount, for all values of T. [`CORDA-1905 `_] +* ``NodeVaultService.loadStates`` queries without a ``PageSpecification`` property set. This leads to issues with large transactions. [`CORDA-1895 `_] +* If a node has two flows, where one's name is a longer version of the other's, they cannot be started [`CORDA-1892 `_] +* Vault Queries across ``LinearStates`` and ``FungibleState`` tables return incorrect results. [`CORDA-1888 `_] +* Checking the version of the Corda jar file by executing the jar with the ``--version`` flag without specifying a valid node configuration file causes an exception to be thrown. [`CORDA-1884 `_] +* RPC deadlocks after a node restart. [`CORDA-1875 `_] +* Vault query fails to find a state if it extends some class (``ContractState``) and it is that base class that is used as the predicate (``vaultService.queryBy()``). [`CORDA-1858 `_] +* Missing unconsumed states from linear id when querying vault caused by a the previous transaction failing with an SQL exception. [`CORDA-1847 `_] +* Inconsistency in how a web path is written. [`CORDA-1841 `_] +* Cannot use ``TestIdentities`` with same organization name in ``net.corda.testing.driver.Driver``. [`CORDA-1837 `_] +* Docs page typos. [`CORDA-1834 `_] +* Adding flexibility to the serialization frameworks unit tests support and utility code. [`CORDA-1808 `_] +* Cannot use ``--initial-registration`` with the ``networkServices`` configuration option in place of the older ``compatibilityzone`` option within ``node.conf``. [`CORDA-1789 `_] +* Document more clearly the supported version of both IntelliJ and the IntelliJ Kotlin Plugins. [`CORDA-1727 `_] +* DemoBench's "Launch Explorer" button is not re-enabled when you close Node Explorer. [`CORDA-1686 `_] +* It is not possible to run ``stateMachinesSnapshot`` from the shell. [`CORDA-1681 `_] +* Node won't start if CorDapps generate states prior to deletion [`CORDA-1663 `_] +* Serializer Evolution breaks with Java classes adding nullable properties. [`CORDA-1662 `_] +* Add Java examples for the creation of proxy serializers to complement the existing kotlin ones. [`CORDA-1641 `_] +* Proxy serializer documentation isn't clear on how to write a proxy serializer. [`CORDA-1640 `_] +* Node crashes in ``--initial-registration`` polling mode if doorman returns a transient HTTP error. [`CORDA-1638 `_] +* Nodes started by gradle task are not stopped when the gradle task exits. [`CORDA-1634 `_] +* Notarizations time out if notary doesn't have up-to-date network map. [`CORDA-1628 `_] +* Node explorer: Improve error handling when connection to nodes cannot be established. [`CORDA-1617 `_] +* Validating notary fails to resolve an attachment. [`CORDA-1588 `_] +* Out of process nodes started by the driver do not log to file. [`CORDA-1575 `_] +* Once ``--initial-registration`` has been passed to a node, further restarts should assume that mode until a cert is collected. [`CORDA-1572 `_] +* An array of primitive byte arrays (an array of arrays) won't deserialize in a virgin factory (i.e. one that didn't build the serializer for serialization). [`CORDA-1545 `_] +* Ctrl-C in the shell fails to aborts the flow. [`CORDA-1542 `_] +* One transaction with two identical cash outputs cannot be save in the vault. [`CORDA-1535 `_] +* The unit tests for the enum evolver functionality cannot be regenerated. This is because verification logic added after their initial creation has a bug that incorrectly identifies a cycle in the graph. [`CORDA-1498 `_] +* Add in a safety check that catches flow checkpoints from older versions. [`CORDA-1477 `_] +* Buggy ``CommodityContract`` issuance logic. [`CORDA-1459 `_] +* Error in the process-id deletion process allows multiple instances of the same node to be run. [`CORDA-1455 `_] +* Node crashes if network map returns HTTP 50X error. [`CORDA-1414 `_] +* Delegate Property doesn't serialize, throws an erroneous type mismatch error. [`CORDA-1403 `_] +* If a vault query throws an exception, the stack trace is swallowed. [`CORDA-1397 `_] +* Node can fail to fully start when a port conflict occurs, no useful error message is generated when this occurs. [`CORDA-1394 `_] +* Running the ``deployNodes`` gradle task back to back without a clean doesn't work. [`CORDA-1389 `_] +* Stripping issuer from Amount> does not preserve ``displayTokenSize``. [`CORDA-1386 `_] +* ``CordaServices`` are instantiated multiple times per Party when using ``NodeDriver``. [`CORDA-1385 `_] +* Out of memory errors can be seen when using Demobench + Explorer. [`CORDA-1356 `_] +* Reduce the amount of classpath scanning during integration tests execution. [`CORDA-1355 `_] +* SIMM demo throws "attachment too big" errors. [`CORDA-1346 `_] +* Fix vault query paging example in ``ScheduledFlowTests``. [`CORDA-1344 `_] +* The shell doesn't print the return value of a started flow. [`CORDA-1342 `_] +* Provide access to database transactions for CorDapp developers. [`CORDA-1341 `_] +* Error with ``VaultQuery`` for entity inheriting from ``CommonSchemaV1.FungibleState``. [`CORDA-1338 `_] +* The ``--network-root-truststore`` command line option not defaulted. [`CORDA-1317 `_] +* Java example in "Upgrading CorDapps" documentation is wrong. [`CORDA-1315 `_] +* Remove references to ``registerInitiatedFlow`` in testing documentation as it is not needed. [`CORDA-1304 `_] +* Regression: Recording a duplicate transaction attempts second insert to vault. [`CORDA-1303 `_] +* Columns in the Corda database schema should have correct NULL/NOT NULL constraints. [`CORDA-1297 `_] +* MockNetwork/Node API needs a way to register ``@CordaService`` objects. [`CORDA-1292 `_] +* Deleting a ``NodeInfo`` from the additional-node-infos directory should remove it from cache. [`CORDA-1093 `_] +* ``FailNodeOnNotMigratedAttachmentContractsTableNameTests`` is sometimes failing with database constraint "Notary" is null. [`CORDA-1976 `_] +* Revert keys for DEV certificates. [`CORDA-1661 `_] +* Node Info file watcher should block and load ``NodeInfo`` when node startup. [`CORDA-1604 `_] +* Improved logging of the network parameters update process. [`CORDA-1405 `_] +* Ensure all conditions in cash selection query are tested. [`CORDA-1266 `_] +* ``NodeVaultService`` bug. Start node, issue cash, stop node, start node, ``getCashBalances()`` will not show any cash +* A Corda node doesn't re-select cluster from HA Notary. +* Event Horizon is not wire compatible with older network parameters objects. +* Notary unable to resolve Party after processing a flow from same Party. +* Misleading error message shown when a node is restarted after a flag day event. - It delivers forward compatibility with future versions of Corda Enterprise: +.. _release_notes_v3_2: - - Is operationally compatible with future versions of Corda Enterprise. - - Is upgradeable to future version of Corda Enterprise, preserving transaction and other data. +Release 3.2 +----------- - It delivers operational compatibility with open-source Corda: +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. - - Can be used in networks seamlessly transacting with nodes running Corda 3.x and future versions. - - Can run CorDapps developed on Corda 3.x and future versions. Note that some database changes may be required to achieve this. See :doc:`node-operations-upgrading` for more information. - - Is compatible with ledger data created using Corda 3.x and future versions. +* **The Corda Network Builder** - Furthermore, the RPC client-server communications transport protocol is now fully AMQP based. +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 bootsrapping tool (see :doc:`network-builder`) +to facilitate the simple creation of more dynamic ad hoc dev-mode environments. -.. note:: RPC clients communicating with Corda Enterprise nodes must be linked against the enterprise RPC client binaries, because open-source Corda `3.x` does not yet use the AMQP serialisation protocol for RPC communication. - From Corda open-source version `4.x` onwards, the RPC client binaries will be compatible with the enterprise distribution. +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. -Further improvements, additions and changes -******************************************* - -* Built-in flows have been improved to automatically utilise the new 'hospital' and retry functionality. For example, the :ref:`FinalityFlow ` now enables a node operator to easily address contract constraints validation errors when using mixed CorDapp versions. Furthermore, flows will attempt to automatically replay from their last saved checkpoint when, for example, a race condition has occurred for writing into the database or a database deadlock has been encountered. Flows will also retry notarisation attempts if a Highly Available Notary cluster member does not respond within the acceptable time period. There are configuration options which affect the behaviour of the retry functionality. See :doc:`corda-configuration-file` for further details. - -* |release| nodes will now fail to start if unknown property keys are found in configuration files. Any unsupported property can be moved to the newly introduced "custom" section. See :doc:`corda-configuration-file` for further details. - -* Property keys with double quotes (e.g. `"key"`) in ``node.conf`` are no longer allowed. See :doc:`corda-configuration-file` for further details. - -* Corda's web server now has its own ``web-server.conf`` file, separate from the ``node.conf`` used by the Corda node. See :doc:`corda-configuration-file` for further details. `Note that this module is deprecated and we intend to remove it in the future.` - -* |release| includes a new 'Blob Inspector' tool for viewing the contents of custom binary serialised files (such as ``node-info``, ``network-parameters``) in a human-readable format. - See :doc:`blob-inspector` for further details. - -* |release| introduces additional network parameters (event horizon) and component run-time validation (maximum allowed message size). - The event horizon is the span of time that is allowed to elapse before an offline node is considered to be permanently gone. - -* |release| adds certificate revocation list checking when running a node in a fully operational Corda Network environment backed by Network Services. - See :doc:`certificate-revocation` for further details. - -* |release| nodes support separate configuration parameters for specifying the location of the Doorman and the NetworkMap services independently of each other. - -* RPC Server now masks internal errors in responses returned to RPC clients for enhanced privacy. - -* Miscellaneous changes to the operation of the network bootstrapper tool, and node configuration changes. - - -Known issues -************ - -The following list contains important known issues identified in this release. We will endeavour to fix these in future -releases of Corda. - -* Certificate revocation revokes identities, not keys, and is currently irreversible. If your keys are lost or compromised, - new keys cannot be re-issued with the same X.500/legal entity name. It is strongly advised to backup your certificates - appropriately and to apply sensible policy for management of private keys. - -* The finance CorDapp from Corda 3.0 and 3.1 cannot be used with |release|. - In a mixed-distribution network the finance CorDapp from |release| should be deployed on both Corda 3.0/3.1 and |release| nodes. - This will be fixed in the next release of open source Corda. - -* Explorer GUI does not display correctly HA notaries or multiple notaries. - -* Certain characters in X500 party names prevent flows from being started from the shell [CORDA-1635]. - -* Missing configuration files for a network bootstrapper cause an exception [CORDA-1643]. - Network bootstrapper should gracefully exit with a helpful error message. - -* Java Lambda expressions with named parameters can cause flows to become not startable from shell [CORDA-1658]. - -* Some ``java.time.*`` types cannot be used in mapped (JPA) schemas [CORDA-1392]. - -* |release| does not support class evolution using non-nullable properties [CORDA-1702]. - -Upgrade notes -************* - -As per previous major releases, we have provided a comprehensive upgrade notes (:doc:`upgrade-notes`) to ease the upgrade -of CorDapps to |release|. In line with our commitment to API stability, code level changes are fairly minimal. - -From a build perspective, switching CorDapps built using Corda 3.x to |release| is mostly effortless, -and simply requires making the Corda Enterprise binaries available to Gradle, and changing two variables in the build file: +* **Split Compatibility Zone** +Prior to this release compatibility zone membership was denoted with a single configuration setting .. sourcecode:: shell - ext.corda_release_version = '3.0' - ext.corda_release_distribution = 'com.r3.corda' + compatibilityZoneURL : "http://(:)" -.. +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. -Visit the `https://www.r3.com/corda-enterprise `_ for more information about Corda Enterprise. Customers that have purchased support can access it online at `https://support.r3.com `_. +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. + +.. sourcecode:: shell + + networkServices { + doormanURL: "http://(:)" + networkMapURL: "http://(:)" + } + +.. note:: The ``compatibilityZoneURL`` setting should be considered deprecated in favour 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 `_] + +.. _release_notes_v3_1: + +Release 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 `_ 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 + +.. _release_notes_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 `__ + + .. warning:: 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 safe 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 switch over 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 serialisation 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 :ref:`here `. 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 :doc:`serialization-default-evolution` and :doc:`serialization-enum-evolution` respectively. + + .. note:: This release delivers the bulk of our transition from Kryo serialisation to AMQP serialisation. 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 :ref:`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 serialisation 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. + + .. important:: Whilst Corda has stabilised 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. + + .. important:: This replaces the Network Map service that was present in Corda 1.0 and Corda 2.0. + + Further information can be found in the :doc:`changelog`, :doc:`network-map` and :doc:`network-bootstrapper` documentation. + +* **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. + + .. tip:: This is a fairly heavyweight operation. As such, consideration should be given as to the most opportune time at +which it should be performed. + + Hash constraints provide for maximum decentralisation 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 centralisation. + + Zone constraints provide a less restrictive but more centralised 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 :doc:`network-map`) 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. + + .. note:: In prior versions of Corda, states included the hash of their defining application JAR (in the Hash Constraint). +In this release, transactions have the JAR containing the contract and states attached to them, so the code will be copied + over the network to the recipient if that peer lacks a copy of the app. + + Prior to running the verification code of a contract the JAR within which the verification code of the contract resides + is tested for compliance to 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. + + .. warning:: This change means that your app JAR must now fit inside the 10mb attachment size limit. To avoid redundantly copying +unneeded code over the network and to simplify upgrades, consider splitting your application into two or more JARs - one that + contains states and contracts (which we call the app "kernel"), and another that contains flows, services, web apps etc. For + example, our `Cordapp template `_ is structured like that. + Only the first will be attached. Also be aware that any dependencies your app kernel has must be bundled into a fat JAR, + as JAR dependencies are not supported in Corda 3.0. + + 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 :doc:`upgrading-cordapps` 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 to use. In addition, these APIs have been added to the *locked* list of the APIs we guarantee to be stable + over time. This should greatly increase productivity when upgrading between versions, as your testing environments will work + without alteration. + + Please see the :doc:`upgrade-notes` for more information on transitioning older tests to the new framework. + +Other Functional Improvements +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* **Clean Node Shutdown** + + We, alongside user feedback, concluded there was a strong need for the ability to have a clean inflection point where a node + could be shutdown without any in-flight transactions pending to allow for a clean system for upgrade purposes. As such, a flows + draining mode has been added. When activated, this places the node into a state of quiescence that guarantees no new work will + be started and all outstanding work completed prior to shutdown. + + A clean shutdown can thus be achieved by: + + 1. Subscribing to state machine updates + 2. Trigger flows draining mode by ``rpc.setFlowsDrainingModeEnabled(true)`` + 3. Wait until the subscription setup as phase 1 lets you know that no more checkpoints are around + 4. Shut the node down however you want + + .. note:: Once set, this mode is a persistent property that will be preserved across node restarts. It must be explicitly disabled +before a node will accept new RPC flow connections. + +* **X.509 certificates** + + These now have an extension that specifies the Corda role the certificate is used for, and the role + hierarchy is now enforced in the validation code. This only has impact on those developing integrations with external + PKI solutions; in most cases it is managed transparently by Corda. A formal specification of the extension can be + found at see :doc:`permissioning-certificate-specification`. + +* **Configurable authorization and authentication data sources** + + Corda can now be configured to load RPC user credentials and permissions from an external database and supports password + encryption based on the `Apache Shiro framework `_. See :ref:`RPC security management + ` for documentation. + + * **SSH Server** + + Remote administration of Corda nodes through the CRaSH shell is now available via SSH, please see :doc:`shell` for more details. + +* **RPC over SSL** + + Corda now allows for the configuration of its RPC calls to be made over SSL. See :doc:`corda-configuration-file` for details + how to configure this. + +* **Improved Notary configuration** + + The configuration of notaries has been simplified into a single ``notary`` configuration object. See + :doc:`corda-configuration-file` for more details. + + .. note:: ``extraAdvertisedServiceIds``, ``notaryNodeAddress``, ``notaryClusterAddresses`` and ``bftSMaRt`` configs have been +removed. + +* **Database Tables Naming Scheme** + + To align with common conventions across all supported Corda and R3 Corda databases some table names have been changed. + + In addition, for existing contract ORM schemas that extend from CommonSchemaV1.LinearState or CommonSchemaV1.FungibleState, + you will need to explicitly map the participants collection to a database table. Previously this mapping was done in the + superclass, but that makes it impossible to properly configure the table name. The required change is to add the override var + ``participants: MutableSet? = null`` field to your class, and add JPA mappings. + +* **Pluggable Custom Serializers** + + With the introduction of AMQP we have introduced the requirement that to be seamlessly serializable classes, specifically + Java classes (as opposed to Kotlin), must be compiled with the ``-parameter`` flag. However, we recognise that this + isn't always possible, especially dealing with third party libraries in tightly controlled business environments. + + To work around this problem as simply as possible CorDapps now support the creation of pluggable proxy serializers for + such classes. These should be written such that they create an intermediary representation that Corda can serialise that + is mappable directly to and from the unserializable class. + + A number of examples are provided by the SIMM Valuation Demo in + + ``samples/simm-valuation-demo/src/main/kotlin/net/corda/vega/plugin/customserializers`` + + Documentation can be found in :doc:`cordapp-custom-serializers` + + +Security Auditing +~~~~~~~~~~~~~~~~~ + + This version of Corda is the first to have had select components subjected to the newly established security review process + by R3's internal security team. Security review will be an on-going process that seeks to provide assurance that the + security model of Corda has been implemented to the highest standard, and is in line with industry best practice. + + As part of this security review process, an independent external security audit of the HTTP based components of the code + was undertaken and its recommendations were acted upon. The security assurance process will develop in parallel to the + Corda platform and will combine code review, automated security testing and secure development practices to ensure Corda + fulfils its security guarantees. + +Security fixes +~~~~~~~~~~~~~~ + + * Due to a potential privacy leak, there has been a breaking change in the error object returned by the + notary service when trying to consume the same state twice: `NotaryError.Conflict` no longer contains the identity + of the party that initiated the first spend of the state, and specifies the hash of the consuming transaction id for + a state instead of the id itself. + + Without this change, knowing the reference of a particular state, an attacker could construct an invalid + double-spend transaction, and obtain the information on the transaction and the party that consumed it. It could + repeat this process with the newly obtained transaction id by guessing its output indexes to obtain the forward + transaction graph with associated identities. When anonymous identities are used, this could also reveal the identity + of the owner of an asset. + +Minor Changes +~~~~~~~~~~~~~ + + * Upgraded gradle to 4.4.1. + + .. note:: To avoid potential incompatibility issues we recommend you also upgrade your CorDapp's gradle +plugin to match. Details on how to do this can be found on the official + `gradle website `_ + + * Cash Spending now allows for sending multiple amounts to multiple parties with a single API call + + - documentation can be found within the JavaDocs on ``TwoPartyTradeFlow``. + * Overall improvements to error handling (RPC, Flows, Network Client). + * TLS authentication now supports mixed RSA and ECDSA keys. + * PrivacySalt computation is faster as it does not depend on the OS's entropy pool directly. + * Numerous bug fixes and documentation tweaks. + * Removed dependency on Jolokia WAR file. + +.. _release_notes_v2_0: + +Release 2.0 +----------- +Following quickly 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. + +.. _release_notes_v1_0: + +Release 1.0 +----------- +Corda 1.0 is finally here! + +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. + +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: + + * **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. + + * **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:`corda-api` 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) `_ 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 +------------ + +This release continues with the goal to improve API stability and developer friendliness. There have also been more +bug fixes and other improvements across the board. + +The CorDapp template repository has been replaced with a specific repository for +`Java `_ and `Kotlin `_ +to improve the experience of starting a new project and to simplify the build system. + +It is now possible to specify multiple IP addresses and legal identities for a single node, allowing node operators +more flexibility in setting up nodes. + +A format has been introduced for CorDapp JARs that standardises the contents of CorDapps across nodes. This new format +now requires CorDapps to contain their own external dependencies. This paves the way for significantly improved +dependency management for CorDapps with the release of `Jigsaw (Java Modules) `_. For those using non-gradle build systems it is important +to read :doc:`cordapp-build-systems` to learn more. Those using our ``cordformation`` plugin simply need to update +to the latest version (``0.14.0``) to get the fixes. + +We've now begun the process of demarcating which classes are part of our public API and which ones are internal. +Everything found in ``net.corda.core.internal`` and other packages in the ``net.corda`` namespace which has ``.internal`` in it are +considered internal and not for public use. In a future release any CorDapp using these packages will fail to load, and +when we migrate to Jigsaw these will not be exported. + +The transaction finalisation flow (``FinalityFlow``) has had hooks added for alternative implementations, for example in +scenarios where no single participant in a transaction is aware of the well known identities of all parties. + +DemoBench has a fix for a rare but inconvenient crash that can occur when sharing your display across multiple devices, +e.g. a projector while performing demonstrations in front of an audience. + +Guava types are being removed because Guava does not have backwards compatibility across versions, which has serious +issues when multiple libraries depend on different versions of the library. + +The identity service API has been tweaked, primarily so anonymous identity registration now takes in +AnonymousPartyAndPath rather than the individual components of the identity, as typically the caller will have +an AnonymousPartyAndPath instance. See change log for further detail. + +Upgrading to this release is strongly recommended in order to keep up with the API changes, removal and additions. + +Milestone 13 +------------ + +Following our first public beta in M12, this release continues the work on API stability and user friendliness. Apart +from bug fixes and code refactoring, there are also significant improvements in the Vault Query and the +Identity Service (for more detailed information about what has changed, see :doc:`changelog`). +More specifically: + +The long awaited new **Vault Query** service makes its debut in this release and provides advanced vault query +capabilities using criteria specifications (see ``QueryCriteria``), sorting, and pagination. Criteria specifications +enable selective filtering with and/or composition using multiple operator primitives on standard attributes stored in +Corda internal vault tables (eg. vault_states, vault_fungible_states, vault_linear_states), and also on custom contract +state schemas defined by CorDapp developers when modelling new contract types. Custom queries are specifiable using a +simple but sophisticated builder DSL (see ``QueryCriteriaUtils``). The new Vault Query service is usable by flows and by +RPC clients alike via two simple API functions: ``queryBy()`` and ``trackBy()``. The former provides point-in-time +snapshot queries whilst the later supplements the snapshot with dynamic streaming of updates. +See :doc:`api-vault-query` for full details. + +We have written a comprehensive Hello, World! tutorial, showing developers how to build a CorDapp from start +to finish. The tutorial shows how the core elements of a CorDapp - states, contracts and flows - fit together +to allow your node to handle new business processes. It also explains how you can use our contract and +flow testing frameworks to massively reduce CorDapp development time. + +Certificate checks have been enabled for much of the identity service. These are part of the confidential (anonymous) +identities work, and ensure that parties are actually who they claim to be by checking their certificate path back to +the network trust root (certificate authority). + +To deal with anonymized keys, we've also implemented a deterministic key derivation function that combines logic +from the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) protocol and the BIP32 hardened +parent-private-key -> child-private-key scheme. This function currently supports the following algorithms: +ECDSA secp256K1, ECDSA secpR1 (NIST P-256) and EdDSA ed25519. We are now very close to fully supporting anonymous +identities so as to increase privacy even against validating notaries. + +We have further tightened the set of objects which Corda will attempt to serialise from the stack during flow +checkpointing. As flows are arbitrary code in which it is convenient to do many things, we ended up pulling in a lot of +objects that didn't make sense to put in a checkpoint, such as ``Thread`` and ``Connection``. To minimize serialization +cost and increase security by not allowing certain classes to be serialized, we now support class blacklisting +that will return an ``IllegalStateException`` if such a class is encountered during a checkpoint. Blacklisting supports +superclass and superinterface inheritance and always precedes ``@CordaSerializable`` annotation checking. + +We've also started working on improving user experience when searching, by adding a new RPC to support fuzzy matching +of X.500 names. + +Milestone 12 - First Public Beta +-------------------------------- + +One of our busiest releases, lots of changes that take us closer to API stability (for more detailed information about +what has changed, see :doc:`changelog`). In this release we focused mainly on making developers' lives easier. Taking +into account feedback from numerous training courses and meet-ups, we decided to add ``CollectSignaturesFlow`` which +factors out a lot of code which CorDapp developers needed to write to get their transactions signed. +The improvement is up to 150 fewer lines of code in each flow! To have your transaction signed by different parties, you +need only now call a subflow which collects the parties' signatures for you. + +Additionally we introduced classpath scanning to wire-up flows automatically. Writing CorDapps has been made simpler by +removing boiler-plate code that was previously required when registering flows. Writing services such as oracles has also been simplified. + +We made substantial RPC performance improvements (please note that this is separate to node performance, we are focusing +on that area in future milestones): + +- 15-30k requests per second for a single client/server RPC connection. + * 1Kb requests, 1Kb responses, server and client on same machine, parallelism 8, measured on a Dell XPS 17(i7-6700HQ, 16Gb RAM) +- The framework is now multithreaded on both client and server side. +- All remaining bottlenecks are in the messaging layer. + +Security of the key management service has been improved by removing support for extracting private keys, in order that +it can support use of a hardware security module (HSM) for key storage. Instead it exposes functionality for signing data +(typically transactions). The service now also supports multiple signature schemes (not just EdDSA). + +We've added the beginnings of flow versioning. Nodes now reject flow requests if the initiating side is not using the same +flow version. In a future milestone release will add the ability to support backwards compatibility. + +As with the previous few releases we have continued work extending identity support. There are major changes to the ``Party`` +class as part of confidential identities, and how parties and keys are stored in transaction state objects. +See :doc:`changelog` for full details. + +Added new Byzantine fault tolerant (BFT) decentralised notary demo, based on the `BFT-SMaRT protocol `_ +For how to run the demo see: :ref:`notary-demo` + +We continued to work on tools that enable diagnostics on the node. The newest addition to Corda Shell is ``flow watch`` command which +lets the administrator see all flows currently running with result or error information as well as who is the flow initiator. +Here is the view from DemoBench: + +.. image:: resources/flowWatchCmd.png + +We also started work on the strategic wire format (not integrated). + +Milestone 11 +------------ + +Special thank you to `Gary Rowe `_ for his contribution to Corda's Contracts DSL in M11. + +Work has continued on confidential identities, introducing code to enable the Java standard libraries to work with +composite key signatures. This will form the underlying basis of future work to standardise the public key and signature +formats to enable interoperability with other systems, as well as enabling the use of composite signatures on X.509 +certificates to prove association between transaction keys and identity keys. + +The identity work will require changes to existing code and configurations, to replace party names with full X.500 +distinguished names (see RFC 1779 for details on the construction of distinguished names). Currently this is not +enforced, however it will be in a later milestone. + +* "myLegalName" in node configurations will need to be replaced, for example "Bank A" is replaced with + "CN=Bank A,O=Bank A,L=London,C=GB". Obviously organisation, location and country ("O", "L" and "C" respectively) + must be given values which are appropriate to the node, do not just use these example values. +* "networkMap" in node configurations must be updated to match any change to the legal name of the network map. +* If you are using mock parties for testing, try to standardise on the ``DUMMY_NOTARY``, ``DUMMY_BANK_A``, etc. provided + in order to ensure consistency. + +We anticipate enforcing the use of distinguished names in node configurations from M12, and across the network from M13. + +We have increased the maximum message size that we can send to Corda over RPC from 100 KB to 10 MB. + +The Corda node now disables any use of ObjectInputStream to prevent Java deserialisation within flows. This is a security fix, +and prevents the node from deserialising arbitrary objects. + +We've introduced the concept of platform version which is a single integer value which increments by 1 if a release changes +any of the public APIs of the entire Corda platform. This includes the node's public APIs, the messaging protocol, +serialisation, etc. The node exposes the platform version it's on and we envision CorDapps will use this to be able to +run on older versions of the platform to the one they were compiled against. Platform version borrows heavily from Android's +API Level. + +We have revamped the DemoBench user interface. DemoBench will now also be installed as "Corda DemoBench" for both Windows +and MacOSX. The original version was installed as just "DemoBench", and so will not be overwritten automatically by the +new version. + +Milestone 10 +------------ + +Special thank you to `Qian Hong `_, `Marek Skocovsky `_, +`Karel Hajek `_, and `Jonny Chiu `_ for their contributions +to Corda in M10. + +A new interactive **Corda Shell** has been added to the node. The shell lets developers and node administrators +easily command the node by running flows, RPCs and SQL queries. It also provides a variety of commands to monitor +the node. The Corda Shell is based on the popular `CRaSH project `_ 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. + +The new "DemoBench" makes it easy to configure and launch local Corda nodes. It is a standalone desktop app that can be +bundled with its own JRE and packaged as either EXE (Windows), DMG (MacOS) or RPM (Linux-based). It has the following +features: + + #. New nodes can be added at the click of a button. 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 at the click of a button. 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. + +Soft Locking is a new feature implemented in the vault to 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. + +The basic Amount API has been upgraded to have support for advanced financial use cases and to better integrate with +currency reference data. + +We have 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. + +We have also delivered the long waited Kotlin 1.1 upgrade in M10! The new features in Kotlin allow us to write even more +clean and easy to manage code, which greatly increases our productivity. + +This release contains a large number of improvements, new features, library upgrades and bug fixes. For a full list of +changes please see :doc:`changelog`. + +Milestone 9 +----------- + +This release focuses on improvements to resiliency of the core infrastructure, with highlights including a Byzantine +fault tolerant (BFT) decentralised notary, based on the BFT-SMaRT protocol and isolating the web server from the +Corda node. + +With thanks to open source contributor Thomas Schroeter for providing the BFT notary prototype, Corda can now resist +malicious attacks by members of a distributed notary service. If your notary service cluster has seven members, two can +become hacked or malicious simultaneously and the system continues unaffected! This work is still in development stage, +and more features are coming in the next snapshot! + +The web server has been split out of the Corda node as part of our ongoing hardening of the node. We now provide a Jetty +servlet container pre-configured to contact a Corda node as a backend service out of the box, which means individual +webapps can have their REST APIs configured for the specific security environment of that app without affecting the +others, and without exposing the sensitive core of the node to malicious Javascript. + +We have launched a global training programme, with two days of classes from the R3 team being hosted in London, New York +and Singapore. R3 members get 5 free places and seats are going fast, so sign up today. + +We've started on support for confidential identities, based on the key randomisation techniques pioneered by the Bitcoin +and Ethereum communities. Identities may be either anonymous when a transaction is a part of a chain of custody, or fully +legally verified when a transaction is with a counterparty. Type safety is used to ensure the verification level of a +party is always clear and avoid mistakes. Future work will add support for generating new identity keys and providing a +certificate path to show ownership by the well known identity. + +There are even more privacy improvements when a non-validating notary is used; the Merkle tree algorithm is used to hide +parts of the transaction that a non-validating notary doesn't need to see, whilst still allowing the decentralised +notary service to sign the entire transaction. + +The serialisation API has been simplified and improved. Developers now only need to tag types that will be placed in +smart contracts or sent between parties with a single annotation... and sometimes even that isn't necessary! + +Better permissioning in the cash CorDapp, to allow node users to be granted different permissions depending on whether +they manage the issuance, movement or ledger exit of cash tokens. + +We've continued to improve error handling in flows, with information about errors being fed through to observing RPC +clients. + +There have also been dozens of bug fixes, performance improvements and usability tweaks. Upgrading is definitely +worthwhile and will only take a few minutes for most apps. + +For a full list of changes please see :doc:`changelog`. \ No newline at end of file