Corda is an open source blockchain project, designed for business from the start. Only Corda allows you to build interoperable blockchain networks that transact in strict privacy. Corda's smart contract technology allows businesses to transact directly, with value.
It's been a little under 3 1/2 months since the release of Corda 4.0 and all of the brand new features that added to the powerful suite of tools Corda offers. Now, following the release of Corda Enterprise 4.0, we are proud to release Corda 4.1, bringing over 150 fixes and documentation updates to bring additional stability and quality of life improvements to those developing on the Corda platform.
Information on Corda Enterprise 4.0 can be found here.
Corda 4.1 brings the lessons and bug fixes discovered during the process of building and shipping Enterprise 4.0 back to the open source community. As mentioned above there are over 150 fixes and tweaks here. With this release the core feature sets of both entities are far closer aligned than past major releases of the Corda that should make testing your CorDapps in mixed type environments much easier.
As such, we recommend you upgrade from Corda 4.0 to Corda 4.1 as soon possible.
In response to the recently released Corda 4.0 Corda 3.4 brings a number of fixes that address several interoperability issues we've discovered between nodes. These should make the deployment of mixed version networks far smoother and the upgrade path from 3 to 4 easier.
The majority of these fixes surround the serialisation and class synthesis frameworks where receiving states and messages from newer (Version 4) nodes highlighted a few edge cases, bugs, and performance enhancements we could make.
Don't fail deserialisation with carpentry errors if the carpented types would be discarded through evolution [CORDA-2704] RPC Vault query incompatibility between Corda 3.3 and Corda 4 [CORDA-2687] V3 node unable to record finalised transaction containing a V3 FungibleAsset state created by a V4 node [CORDA-2422] V3 node is unable to evolve serialised type that has introduced a property that is of an unknown type [CORDA-2314] ClassCastException during initiate Contract Upgrade [CORDA-2109]
Corda 3.3 brings together many small improvements, fixes, and community contributions to deliver a stable and polished release of Corda. Where both the 3.1 and 3.2 releases delivered a smaller number of critical bug fixes addressing immediate and impactful error conditions, 3.3 addresses a much greater number of issues, both small and large, that have been found and fixed since the release of 3.0 back in March. Rolling up a great many improvements and polish to truly make the Corda experience just that much better.
In addition to work undertaken by the main Corda development team, we've taken the opportunity in 3.3 to bring back many of the contributions made by community members from master onto the currently released stable branch. It has been said many times before, but the community and its members are the real life-blood of Corda and anyone who takes the time to contribute is a star in our eyes. Bringing that code into the current version we hope gives people the opportunity to see their work in action, and to help their fellow community members by having these contributions available in a supported release.
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.
After consultation, collaboration, and discussion with industry experts, we have decided to alter the default Certificate Hierarchy (PKI) utilized by Corda and the Corda Network. To facilitate this, the nodes have had their certificate path verification logic made much more flexible. All existing certificate hierarchy, certificates, and networks will remain valid. The possibility now exists for nodes to recognize a deeper certificate chain and thus Compatibility Zone operators can deploy and adhere to the PKI standards they expect and are comfortable with.
Practically speaking, the old code assumed a 3-level hierarchy of Root -> Intermediate CA (Doorman) -> Node, and this was hard coded. From 3.3 onward an arbitrary depth of certificate chain is supported. For the Corda Network, this means the introduction of an intermediate layer between the root and the signing certificates (Network Map and Doorman). This has the effect of allowing the root certificate to always be kept offline and never retrieved or used. Those new intermediate certificates can be used to generate, if ever needed, new signing certs without risking compromise of the root key.
The Corda community is a vibrant and exciting ecosystem that spreads far outside the virtual walls of the R3 organisation. Without that community, and the most welcome contributions of its members, the Corda project would be a much poorer place.
We're therefore happy to extend thanks to the following members of that community for their contributions
IdentitySyncFlow more useful. See here.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.
networkServices {
doormanURL: "http://<host>(:<port>)"
networkMapURL: "http://<host>(:<port>)"
}
NOTE: The compatibilityZoneURL setting should be considered deprecated in favor of the new networkServices settings group.
The blob inspector 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
Event Horizon Network Parameter [CORDA-866]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.
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:
HashConstraint: the hash of the deployed CorDapp jar must be the same as the hash found in the Transaction.ZoneConstraint: the Transaction must come with a whitelisted attachment for each Contract State.If this step fails the normal transaction verification failure path is followed.
Corda 3.0 lays the groundwork for future releases, when contract verification will be done against the attached contract JARs rather than requiring a locally deployed CorDapp of the exact version specified by the transaction. The future vision for this feature will entail the dynamic downloading of the appropriate version of the smart contract and its execution within a sandboxed environment.
Future versions of Corda will add support for signature-based constraints, in which any JAR signed by a given identity can be attached to the transaction. This final constraint type provides a balance of all requirements: smooth rolling upgrades can be performed without any additional steps or transactions being signed, at the cost of trusting the app developer more and some additional complexity around managing app signing.
Please see the upgrading cordapps documentation for more information on upgrading contracts.
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:
rpc.setFlowsDrainingModeEnabled(true)
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.
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
samples/simm-valuation-demo/src/main/kotlin/net/corda/vega/plugin/customserializers
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.
notary configuration object. See the docs for more details.Java 8 serializable lambdas now work property with Kryo during check-pointing.
String constants have been marked as const type in Kotlin, eliminating cases where functions of the form
get<constant name>() were created for the Java API. These can now be referenced by their name directly.
FlowLogic communication has been extensively rewritten to use functions on FlowSession as the base for communication
between nodes.
send(), receive() and sendAndReceive() on FlowLogic should be replaced with calls
to the function of the same name on FlowSession. Note that the replacement functions do not take in a destination
parameter, as this is defined in the session.FlowSession instead of Party in their constructor. If you need to access the
counterparty identity, it is in the counterparty property of the flow session.Added X509EdDSAEngine to intercept and rewrite EdDSA public keys wrapped in X509Key instances. This corrects an issue with verifying certificate paths loaded from a Java Keystore where they contain EdDSA keys.
Confidential identities are now complete:
SwapIdentitiesFlow, renamed from TransactionKeyFlow.key-concepts-identity and :doc:api-identity for more details.Remove the legacy web front end from the SIMM demo.
NodeInfo and NetworkMapCache changes:
NodeInfo::legalIdentity in preparation for handling of multiple identities. We left list of NodeInfo::legalIdentitiesAndCerts,
the first identity still plays a special role of main node identity.NodeInfo::advertisedServices, serviceIdentities
and notaryIdentity.NetworkMapCache: partyNodes, networkMapNodes, notaryNodes, regulatorNodes,
getNodesWithService, getPeersWithService, getRecommended, getNodesByAdvertisedServiceIdentityKey, getAnyNotary,
notaryNode, getAnyServiceOfType. To get all known NodeInfos call allNodes.NetworkMapService redesign and distributing notaries through NetworkParameters we added
NetworkMapCache::notaryIdentities list to enable to lookup for notary parties known to the network. Related CordaRPCOps::notaryIdentities
was introduced. Other special nodes parties like Oracles or Regulators need to be specified directly in CorDapp or flow.ServiceType and ServiceInfo to net.corda.nodeapi package as services are only required on node startup.Adding enum support to the class carpenter
ContractState::contract has been moved TransactionState::contract and it's type has changed to String in order to
support dynamic classloading of contract and contract constraints.
CorDapps that contain contracts are now automatically loaded into the attachment storage - for CorDapp developers this now means that contracts should be stored in separate JARs to flows, services and utilities to avoid large JARs being auto imported to the attachment store.
About half of the code in test-utils has been moved to a new module node-driver,
and the test scope modules are now located in a testing directory.
CordaPluginRegistry has been renamed to SerializationWhitelist and moved to the net.corda.core.serialization
package. The API for whitelisting types that can't be annotated was slightly simplified. This class used to contain
many things, but as we switched to annotations and classpath scanning over time it hollowed out until this was
the only functionality left. You also need to rename your services resource file to the new class name.
An associated property on MockNode was renamed from testPluginRegistries to testSerializationWhitelists.
Contract Upgrades: deprecated RPC authorisation / deauthorisation API calls in favour of equivalent flows in ContractUpgradeFlow. Implemented contract upgrade persistence using JDBC backed persistent map.
Vault query common attributes (state status and contract state types) are now handled correctly when using composite criteria specifications. State status is overridable. Contract states types are aggregatable.
Cash selection algorithm is now pluggable (with H2 being the default implementation)
Removed usage of Requery ORM library (repalced with JPA/Hibernate)
Vault Query performance improvement (replaced expensive per query SQL statement to obtain concrete state types with single query on start-up followed by dynamic updates using vault state observable))
Vault Query fix: filter by multiple issuer names in FungibleAssetQueryCriteria
Following deprecated methods have been removed:
DataFeed
first and current, replaced by snapshot
second and future, replaced by updates
CordaRPCOps
stateMachinesAndUpdates, replaced by stateMachinesFeed
verifiedTransactions, replaced by verifiedTransactionsFeed
stateMachineRecordedTransactionMapping, replaced by stateMachineRecordedTransactionMappingFeed
networkMapUpdates, replaced by networkMapFeed
Due to security concerns and the need to remove the concept of state relevancy (which isn't needed in Corda),
ResolveTransactionsFlow has been made internal. Instead merge the receipt of the SignedTransaction and the subsequent
sub-flow call to ResolveTransactionsFlow with a single call to ReceiveTransactionFlow. The flow running on the counterparty
must use SendTransactionFlow at the correct place. There is also ReceiveStateAndRefFlow and SendStateAndRefFlow for
dealing with StateAndRefs.
Vault query soft locking enhancements and deprecations
VaultService ``softLockedStates` query mechanism.SoftLockingCondition filterable attribute in VaultQueryCriteria to enable specification
of different soft locking retrieval behaviours (exclusive of soft locked states, soft locked states only, specified
by set of lock ids)Trader demo now issues cash and commercial paper directly from the bank node, rather than the seller node self-issuing commercial paper but labelling it as if issued by the bank.
Merged handling of well known and confidential identities in the identity service. Registration now takes in an identity (either type) plus supporting certificate path, and de-anonymisation simply returns the issuing identity where known. If you specifically need well known identities, use the network map, which is the authoritative source of current well known identities.
Currency-related API in net.corda.core.contracts.ContractsDSL has moved to ```net.corda.finance.CurrencyUtils`.
Remove IssuerFlow as it allowed nodes to request arbitrary amounts of cash to be issued from any remote node. Use
CashIssueFlow instead.
Some utility/extension functions (sumOrThrow, sumOrNull, sumOrZero on Amount and Commodity)
have moved to be static methods on the classes themselves. This improves the API for Java users who no longer
have to see or known about file-level FooKt style classes generated by the Kotlin compile, but means that IntelliJ
no longer auto-suggests these extension functions in completion unless you add import lines for them yourself
(this is Kotlin IDE bug KT-15286).
:finance module now acting as a CorDapp with regard to flow registration, schemas and serializable types.
WebServerPluginRegistry now has a customizeJSONSerialization which can be overridden to extend the REST JSON
serializers. In particular the IRS demos must now register the BusinessCalendar serializers.
Moved :finance gradle project files into a net.corda.finance package namespace.
This may require adjusting imports of Cash flow references and also of StartFlow permission in gradle.build files.
Removed the concept of relevancy from LinearState. The ContractState's relevancy to the vault can be determined
by the flow context, the vault will process any transaction from a flow which is not derived from transaction resolution verification.
Removed the tolerance attribute from TimeWindowChecker and thus, there is no extra tolerance on the notary side anymore.
The FungibleAsset interface has been made simpler. The Commands grouping interface
that included the Move, Issue and Exit interfaces have all been removed, while the move function has
been renamed to withNewOwnerAndAmount to be consistent with the withNewOwner function of the OwnableState.
The IssueCommand interface has been removed from Structures, because, due to the introduction of nonces per
transaction component, the issue command does not need a nonce anymore and it does not require any other attributes.
As a consequence of the above and the simpler FungibleAsset format, fungible assets like Cash now use
class Issue : TypeOnlyCommandData(), because it's only its presence (Issue) that matters.
A new PrivacySalt transaction component is introduced, which is now an attribute in TraversableTransaction and
inherently in WireTransaction.
A new nonces: List<SecureHash> feature has been added to FilteredLeaves.
Due to the nonces and PrivacySalt introduction, new functions have been added to MerkleTransaction:
fun <T : Any> serializedHash(x: T, privacySalt: PrivacySalt?, index: Int): SecureHash
fun <T : Any> serializedHash(x: T, nonce: SecureHash): SecureHash
fun computeNonce(privacySalt: PrivacySalt, index: Int).
A new SignatureMetadata data class is introduced with two attributes, platformVersion: Int and
schemeNumberID: Int (the signature scheme used).
As part of the metadata support in signatures, a new data class SignableData(val txId: SecureHash, val signatureMetadata: SignatureMetadata)
is introduced, which represents the object actually signed.
The unused MetaData and SignatureType in crypto package have been removed.
The class TransactionSignature(bytes: ByteArray, val by: PublicKey, val signatureMetadata: SignatureMetadata): DigitalSignature(bytes)
class is now utilised Vs the old DigitalSignature.WithKey for Corda transaction signatures. Practically, it takes
the signatureMetadata as an extra input, in order to support signing both the transaction and the extra metadata.
To reflect changes in the signing process, the Crypto object is now equipped with the:
fun doSign(keyPair: KeyPair, signableData: SignableData): TransactionSignature and
fun doVerify(txId: SecureHash, transactionSignature: TransactionSignature): Boolean functions.
``SerializationCustomization.addToWhitelist()` now accepts multiple classes via varargs.
Two functions to easily sign a FilteredTransaction have been added to ServiceHub:
createSignature(filteredTransaction: FilteredTransaction, publicKey: PublicKey) and
createSignature(filteredTransaction: FilteredTransaction) to sign with the legal identity key.
A new helper method buildFilteredTransaction(filtering: Predicate<Any>) is added to SignedTransaction to
directly build a FilteredTransaction using provided filtering functions, without first accessing the
tx: WireTransaction.
Test type NodeHandle now has method stop(): CordaFuture<Unit> that terminates the referenced node.
Fixed some issues in IRS demo:
.. warning:: Renamed configuration property key basedir to baseDirectory. This will require updating existing configuration files.
Removed deprecated parts of the API.
Removed PluginServiceHub. Replace with ServiceHub for @CordaService constructors.
X509CertificateHolder has been removed from the public API, replaced by java.security.X509Certificate.
Moved CityDatabase out of core and into finance
All of the serializedHash and computeNonce functions have been removed from MerkleTransaction.
The serializedHash(x: T) and computeNonce were moved to CryptoUtils.
Two overloaded methods componentHash(opaqueBytes: OpaqueBytes, privacySalt: PrivacySalt, componentGroupIndex: Int, internalIndex: Int): SecureHash and componentHash(nonce: SecureHash, opaqueBytes: OpaqueBytes): SecureHash have
been added to CryptoUtils. Similarly to computeNonce, they internally use SHA256d for nonce and leaf hash
computations.
The verify(node: PartialTree, usedHashes: MutableList<SecureHash>): SecureHash in PartialMerkleTree has been
renamed to rootAndUsedHashes and is now public, as it is required in the verify function of FilteredTransaction.
TraversableTransaction is now an abstract class extending CoreTransaction. WireTransaction and
FilteredTransaction now extend TraversableTransaction.
Two classes, ComponentGroup(open val groupIndex: Int, open val components: List<OpaqueBytes>) and
FilteredComponentGroup(override val groupIndex: Int, override val components: List<OpaqueBytes>, val nonces: List<SecureHash>, val partialMerkleTree: PartialMerkleTree): ComponentGroup(groupIndex, components)
have been added, which are properties of the WireTransaction and FilteredTransaction, respectively.
checkAllComponentsVisible(componentGroupEnum: ComponentGroupEnum) is added to FilteredTransaction, a new
function to check if all components are visible in a specific component-group.
To allow for backwards compatibility, WireTransaction and FilteredTransaction have new fields and
constructors: WireTransaction(componentGroups: List<ComponentGroup>, privacySalt: PrivacySalt = PrivacySalt()),
FilteredTransaction private constructor(id: SecureHash,filteredComponentGroups: List<FilteredComponentGroup>, groupHashes: List<SecureHash>. FilteredTransaction is still built via
``buildFilteredTransaction(wtx: WireTransaction, filtering: Predicate<Any>).
FilteredLeaves class have been removed and as a result we can directly call the components from
FilteredTransaction, such as ftx.inputs Vs the old ftx.filteredLeaves.inputs.
A new ComponentGroupEnum is added with the following enum items: INPUTS_GROUP, OUTPUTS_GROUP,
COMMANDS_GROUP, ATTACHMENTS_GROUP, NOTARY_GROUP, TIMEWINDOW_GROUP.
ContractUpgradeFlow.Initiator has been renamed to ContractUpgradeFlow.Initiate
@RPCSinceVersion, RPCException and PermissionException have moved to net.corda.client.rpc.
Following swiftly on the heels of the release of Corda 1.0, Corda version 2.0 consolidates a number of security updates for our dependent libraries alongside the reintroduction of the Observer node functionality. This was absent from version 1 but based on user feedback its re-introduction removes the need for complicated "isRelevant()" checks.
In addition the fix for a small bug present in the coin selection code of V1.0 is integrated from master.
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.
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.
This is a bugfix release which changes UntrustworthyData.Validator to implement Serializable so that checkpoints with unwrap lambdas are valid.
build.gradle: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
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.
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.