mirror of
https://github.com/corda/corda.git
synced 2025-02-21 09:51:57 +00:00
parent
553ce9b2b2
commit
9e5b469bde
@ -7,6 +7,9 @@ from the previous milestone release.
|
||||
UNRELEASED
|
||||
----------
|
||||
|
||||
Milestone 12.0 - 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
|
||||
@ -53,9 +56,6 @@ UNRELEASED
|
||||
* 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.
|
||||
|
||||
* Flows can now accept ``PartyAndCertificate`` instead of ``Party`` in their constructor, which should be the default for
|
||||
new flows. The sample flows have been updated to use ``PartyAndCertificate`` to illustrate this.
|
||||
|
||||
* 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.
|
||||
|
||||
@ -68,9 +68,9 @@ UNRELEASED
|
||||
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`` now provides no mechanism to request the node's ``PrivateKey`` objects directly.
|
||||
* 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 multiple keys to use. This lookup also works for ``CompositeKey`` scenarios
|
||||
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.
|
||||
|
@ -6,15 +6,48 @@ Here are release notes for each snapshot release from M9 onwards.
|
||||
Unreleased
|
||||
----------
|
||||
|
||||
Writing CorDapps has been made simpler by removing boiler-plate code that was previously required when registering flows.
|
||||
Instead we now make use of classpath scanning to automatically wire-up flows.
|
||||
Milestone 12 - First Public Beta
|
||||
--------------------------------
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
We've added the ability for flows to be versioned by their CorDapp developers. This enables a node to support a particular
|
||||
version of a flow and allows it to reject flow communication with a node which isn't using the same fact. In a future
|
||||
release we allow a node to have multiple versions of the same flow running to enable backwards compatibility.
|
||||
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 <https://bft-smart.github.io/library/>`_
|
||||
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
|
||||
------------
|
||||
|
BIN
docs/source/resources/flowWatchCmd.png
Normal file
BIN
docs/source/resources/flowWatchCmd.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 111 KiB |
@ -111,6 +111,8 @@ To run from the command line in Windows:
|
||||
4. Run ``gradlew samples:attachment-demo:runSender`` in another terminal window to send the attachment. Now look at the other windows to
|
||||
see the output of the demo
|
||||
|
||||
.. _notary-demo:
|
||||
|
||||
Notary demo
|
||||
-----------
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user