fenryka released this
Jul 20, 2018
· 983 commits to master since this release
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.
To make it easier to create more dynamic, flexible, networks for testing and deployment, with the 3.2 release of Corda we are shipping a graphical network bootstrapping tool to facilitate the simple creation of more dynamic ad hoc dev-mode environments.
Using a graphical interface you can dynamically create and alter Corda test networks, adding nodes and CorDapps with the click of a button! Additionally, you can leverage its integration with Azure cloud services for remote hosting of Nodes and Docker instances for local testing.
Prior to this release compatibility zone membership was denoted with a single configuration setting
compatibilityZoneURL : "http://<host>(:<port>)"
That would indicate both the location of the Doorman service the node should use for registration of its identity as well as the Network Map service where it would publish its signed Node Info and retrieve the Network Map.
Compatibility Zones can now, however, be configured with the two disparate services, Doorman and Network Map, running on different URLs. If the compatibility zone your node is connecting to is configured in this manner, the new configuration looks as follows.
NOTE: The compatibilityZoneURL setting should be considered deprecated in favor of the new networkServices settings group.
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
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
fenryka released this
Apr 11, 2018
· 2 commits to release-V3 since this release
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.
Without passionate and engaged users Corda would be all the poorer. As such, we are extremely grateful to Bret Lichtenwald (@bret540) for helping nail down a reproducible test case for the Spring Boot issue.
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.
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.
fenryka released this
Mar 12, 2018
· 2 commits to release-V3 since this release
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.
As ever, we are grateful to the enthusiastic user and developer community that has grown up to surround Corda. As an open project, we are always grateful to take code contributions from individual users where they feel they can add functionality useful to themselves and the wider community.
As such we'd like to extend special thanks to
Ben Wyeth for providing a mechanism for registering a callback on app shutdown
Ben's contribution can be found on GitHub here
Tomas Tauber for adding support for running Corda atop PostgresSQL in place of the in-memory H2 service
Tomas's contribution can be found on GitHub here
Note: This is an experimental feature that has not been tested as part of our standard release testing.
Rose Molina Atienza for correcting our careless spelling slip
Rose's change can be found on GitHub here
Wire stability brings the same promise to developers for their data that API stability did for their code. From this point, any state generated by a Corda system will always be retrievable, understandable, and seen as valid by any subsequently released version (versions 3.0 and above).
Systems can thus be deployed safely in the knowledge that valuable and important information will always be accessible through upgrade and change. Practically speaking this means from this point forward upgrading all, or part, of a Corda network, will not require the replaying of data; "it will just work".
This has been facilitated by the switchover from Kryo to Corda's own AMQP based serialization framework, a framework designed to interoperate with stateful information and allow the evolution of such contract states over time as developers refine and improve their systems written atop the core Corda platform.
AMQP Serialization is now enabled for both peer-to-peer communication and the writing of states to the vault. This change brings a serialization format that will allow us to deliver enhanced security and wire stability. This was a key prerequisite to enabling different Corda node versions to coexist on the same network and to enable easier upgrades.
Details on the AMQP serialization framework can be found in the docs. This provides an introduction and overview of the framework whilst more specific details on object evolution as it relates to serialization can be found in the documentation
This release delivers the bulk of our transition from Kryo serialization to AMQP serialization. This means that many of the restrictions that were documented in previous versions of Corda are now enforced.
In particular, you are advised to review the section titled Custom Types. To aid with the transition, we have included support in this release for default construction and instantiation of objects with inaccessible private fields, but it is not guaranteed that this support will continue into future versions; the restrictions documented at the link above are the canonical source.
Whilst this is an important step for Corda, in no way is this the end of the serialization story. We have many new features and tools planned for future releases but feel it is more important to deliver the guarantees discussed above as early as possible to allow the community to develop with greater confidence.
Note: Whilst Corda has stabilized its wire protocol and infrastructure for peer to peer communication and persistent storage of states, the RPC framework will, for this release, not be covered by this guarantee. The moving of the client and server contexts away from Kryo to our stable AMQP implementation is planned for the next release of Corda
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.
This release introduces the new network map architecture. The network map service has been completely redesigned and implemented to enable future increased network scalability and redundancy, reduced runtime operational overhead, support for multiple notaries, and administration of network compatibility zones (CZ).
A Corda Compatibility Zone is defined as a grouping of participants and services (notaries, oracles, doorman, network map server) configured within an operational Corda network to be interoperable and compatible with each other.
We introduce the concept of network parameters to specify precisely the set of constants (or ranges of constants) upon which the nodes within a network need to agree in order to be assured of seamless inter-operation. Additional security controls ensure that all network map data is now signed, thus reducing the power of the network operator to tamper with the map.
There is also support for a group of nodes to operate locally, which is achieved by copying each node's signed info file to the other nodes' directories. We've added a bootstrapping tool to facilitate this use case.
Note: This replaces the Network Map service that was present in Corda 1.0 and Corda 2.0.
Support for the upgrading of contracts has been significantly extended in this release.
Contract states express which attached JARs can define and verify them using constraints. In older versions, the only supported constraint was a hash constraint. This provides similar behaviour as public blockchain systems like Bitcoin and Ethereum, in which code is entirely fixed once deployed and cannot be changed later. In Corda there is an upgrade path that involves the cooperation of all involved parties (as advertised by the states themselves), but this requires explicit transactions to be applied to all states and be signed by all parties.
Hash constraints provide for maximum decentralization and minimum trust, at the cost of flexibility. In Corda 3.0 we add a new constraint, a _network parameters_ constraint, that allows the list of acceptable contract JARs to be maintained by the operator of the compatibility zone rather than being hard-coded. This allows for simple upgrades at the cost of the introduction of an element of centralization.
Zone constraints provide a less restrictive but more centralized control mechanism. This can be useful when you want the ability to upgrade an app and you don’t mind the upgrade taking effect “just in time” when a transaction happens to be required for other business reasons. These allow you to specify that the network parameters of a compatibility zone (see the documentation) is expected to contain a map of class name to hashes of JARs that are allowed to provide that class. The process for upgrading an app then involves asking the zone operator to add the hash of your new JAR to the parameters file and trigger the network parameters upgrade process. This involves each node operator running a shell command to accept the new parameters file and then restarting the node. Node owners who do not restart their node in time effectively stop being a part of the network.
Prior to running the verification code of a contract, the JAR within which the verification code of the contract resides is tested for compliance with the contract constraints:
If this step fails the normal transaction verification failure path is followed.
Corda 3.0 lays the groundwork for future releases, when contract verification will be done against the attached contract JARs rather than requiring a locally deployed CorDapp of the exact version specified by the transaction. The future vision for this feature will entail the dynamic downloading of the appropriate version of the smart contract and its execution within a sandboxed environment.
Future versions of Corda will add support for signature-based constraints, in which any JAR signed by a given identity can be attached to the transaction. This final constraint type provides a balance of all requirements: smooth rolling upgrades can be performed without any additional steps or transactions being signed, at the cost of trusting the app developer more and some additional complexity around managing app signing.
Please see the upgrading cordapps documentation for more information on upgrading contracts.
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 version 3.0 upgrade notes for more information on transitioning older tests to the new framework.
We, alongside user feedback, concluded there was a strong need for the ability to have a clear inflection point where a node could be shut down 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 shutting down.
A clean shutdown can thus be achieved by:
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 an impact on those developing integrations with external PKI solutions; in most cases, it is managed transparently by Corda.
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 participant's 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<AbstractParty>? = null field to your class, and add JPA mappings.
participants: MutableSet<AbstractParty>? = null
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 recognize 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 serialize that is mappable directly to and from the unserializable class.
A number of examples are provided by the SIMM Valuation Demo in
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 fulfills its security guarantees.
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.