Docs: fix some broken markup that caused rendering errors and warnings.

This commit is contained in:
Mike Hearn 2018-05-09 16:19:35 +02:00
parent e110d17bce
commit 54e1a7aa7e
29 changed files with 160 additions and 216 deletions

View File

@ -20,6 +20,8 @@ Any object that needs to be identified by its hash should implement the ``NamedB
``SecureHash`` is a sealed class that only defines a single subclass, ``SecureHash.SHA256``. There are utility methods
to create and parse ``SecureHash.SHA256`` objects.
.. _composite_keys:
CompositeKey
------------
Corda supports scenarios where more than one signature is required to authorise a state object transition. For example:

View File

@ -265,10 +265,11 @@ In order to create a communication session between your initiator flow and the r
* Sends the ``payload`` object and receives an object of type ``receiveType`` back
In addition ``FlowLogic`` provides functions that batch receives:
* ``receiveAllMap(sessions: Map<FlowSession, Class<out Any>>): Map<FlowSession, UntrustworthyData<Any>>``
* Receives from all ``FlowSession``s specified in the passed in map. The received types may differ.
Receives from all ``FlowSession`` objects specified in the passed in map. The received types may differ.
* ``receiveAll(receiveType: Class<R>, sessions: List<FlowSession>): List<UntrustworthyData<R>>``
* Receives from all ``FlowSession``s specified in the passed in list. The received types must be the same.
Receives from all ``FlowSession`` objects specified in the passed in list. The received types must be the same.
The batched functions are implemented more efficiently by the flow framework.

View File

@ -123,7 +123,7 @@ JDBC connection (session) as described by the `Java SQL Connection API <https://
Use the ``ServiceHub`` ``jdbcSession`` function to obtain a JDBC connection as illustrated in the following example:
.. literalinclude:: ../../node/src/test/kotlin/net/corda/node/services/database/HibernateConfigurationTest.kt
.. literalinclude:: ../../node/src/test/kotlin/net/corda/node/services/persistence/HibernateConfigurationTest.kt
:language: kotlin
:start-after: DOCSTART JdbcSession
:end-before: DOCEND JdbcSession

View File

@ -377,7 +377,7 @@ Track unconsumed cash states:
:language: kotlin
:start-after: DOCSTART VaultQueryExample15
:end-before: DOCEND VaultQueryExample15
:dedent: 20
:dedent: 12
Track unconsumed linear states:
@ -385,7 +385,7 @@ Track unconsumed linear states:
:language: kotlin
:start-after: DOCSTART VaultQueryExample16
:end-before: DOCEND VaultQueryExample16
:dedent: 20
:dedent: 12
.. note:: This will return both ``DealState`` and ``LinearState`` states.
@ -395,7 +395,7 @@ Track unconsumed deal states:
:language: kotlin
:start-after: DOCSTART VaultQueryExample17
:end-before: DOCEND VaultQueryExample17
:dedent: 20
:dedent: 12
.. note:: This will return only ``DealState`` states.

View File

@ -1,20 +1,20 @@
Building a Corda VM from the AWS Marketplace
============================================
To help you design, build and test applications on Corda, called CorDapps, a Corda network AMI can be deployed from the `AWS Marketplace <https://aws.amazon.com/marketplace/pp/B077PG9SP5>`_. Instructions on running Corda nodes can be found `here <https://docs.corda.net/deploying-a-node.html>`_.
To help you design, build and test applications on Corda, called CorDapps, a Corda network AMI can be deployed from the `AWS Marketplace <https://aws.amazon.com/marketplace/pp/B077PG9SP5>`__. Instructions on running Corda nodes can be found `here <https://docs.corda.net/deploying-a-node.html>`_.
This Corda network offering builds a pre-configured network of Corda nodes as Ubuntu virtual machines (VM). The network consists of a Notary node and three Corda nodes using version 1 of Corda. The following guide will also show you how to load one of four `Corda Sample apps <https://www.corda.net/samples>`_ which demonstrates the basic principles of Corda. When you are ready to go further with developing on Corda and start making contributions to the project head over to the `Corda.net <https://www.corda.net/>`_.
Pre-requisites
--------------
* Ensure you have a registered AWS account which can create virtual machines under your subscription(s) and you are logged on to the `AWS portal <https://console.aws.amazon.com>`_
* It is recommended you generate a private-public SSH key pair (see `here <https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2/>`_)
* It is recommended you generate a private-public SSH key pair (see `here <https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2/>`__)
Deploying a Corda Network
---------------------------
Browse to the `AWS Marketplace <https://aws.amazon.com/marketplace>`_ and search for Corda.
Browse to the `AWS Marketplace <https://aws.amazon.com/marketplace>`__ and search for Corda.
Follow the instructions to deploy the AMI to an instance of EC2 which is in a region near to your location.
@ -59,7 +59,7 @@ Then start the Corda webserver
find ~/dev/cordapp-example/kotlin-source/ -name corda-webserver.jar -execdir sh -c 'java -jar {} &' \;
You can now interact with your running CorDapp. See the instructions `here <https://docs.corda.net/tutorial-cordapp.html#via-http>`_
You can now interact with your running CorDapp. See the instructions `here <https://docs.corda.net/tutorial-cordapp.html#via-http>`__.
Next Steps
----------

View File

@ -8,7 +8,7 @@ This Corda network offering builds a pre-configured network of Corda nodes as Ub
Pre-requisites
--------------
* Ensure you have a registered Microsoft Azure account which can create virtual machines under your subscription(s) and you are logged on to the Azure portal (portal.azure.com)
* It is recommended you generate a private-public SSH key pair (see `here <https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2/>`_)
* It is recommended you generate a private-public SSH key pair (see `here <https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2/>`__)
Deploying the Corda Network

View File

@ -7,7 +7,7 @@ against the unstable Master branch if you are using a very recent feature, or ar
To work against the Master branch, proceed as follows:
1. Open a terminal window in the folder where you cloned the Corda repository
(available `here <https://github.com/corda/corda>`_)
(available `here <https://github.com/corda/corda>`_)
2. Use the following command to check out the latest master branch:

View File

@ -29,6 +29,7 @@ Unreleased
Further changes may be required in the future.
* Configuration file changes:
* Added program line argument ``on-unknown-config-keys`` to allow specifying behaviour on unknown node configuration property keys.
Values are: [FAIL, WARN, IGNORE], default to FAIL if unspecified.
* Introduced a placeholder for custom properties within ``node.conf``; the property key is "custom".
@ -43,6 +44,7 @@ Unreleased
To enable RPC connectivity ensure nodes ``rpcSettings.address`` and ``rpcSettings.adminAddress`` settings are present.
* Changes to the network bootstrapper:
* The whitelist.txt file is no longer needed. The existing network parameters file is used to update the current contracts
whitelist.
* The CorDapp jars are also copied to each nodes' `cordapps` directory.
@ -64,8 +66,8 @@ 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.
.. 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.
* 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
@ -136,7 +138,7 @@ Version 3.0
* 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.
"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.
@ -239,13 +241,13 @@ Version 3.0
* 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.
* 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.
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.
@ -394,7 +396,7 @@ Release 1.0
* Vault query soft locking enhancements and deprecations
* removed original ``VaultService`` ``softLockedStates` query mechanism.
* removed original ``VaultService`` ``softLockedStates`` query mechanism.
* introduced improved ``SoftLockingCondition`` filterable attribute in ``VaultQueryCriteria`` to enable specification of different soft locking retrieval behaviours (exclusive of soft locked states, soft locked states only, specified by set of lock ids)
* Trader demo now issues cash and commercial paper directly from the bank node, rather than the seller node self-issuing
@ -544,7 +546,7 @@ Milestone 14
* ``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``s were introduced. Addresses are no longer of type
* 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
@ -604,10 +606,10 @@ Milestone 14
* 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)
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:
* Pagination simplification
Pagination continues to be optional, but with following changes:
- If no PageSpecification provided then a maximum of MAX_PAGE_SIZE (200) results will be returned, otherwise we fail-fast with a ``VaultQueryException`` to alert the API user to the need to specify a PageSpecification.
Internally, we no longer need to calculate a results count (thus eliminating an expensive SQL query) unless a PageSpecification is supplied (note: that a value of -1 is returned for total_results in this scenario).
Internally, we now use the AggregateFunction capability to perform the count.
@ -644,10 +646,12 @@ support for more currencies to the DemoBench and Explorer tools.
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
@ -662,7 +666,7 @@ support for more currencies to the DemoBench and Explorer tools.
register custom contract state schemas they wish to query using the new Vault Query service API (using the
``VaultCustomQueryCriteria``).
* See :doc:`vault-query` for full details and code samples of using the new Vault Query service.
* See :doc:`api-vault-query` for full details and code samples of using the new Vault Query service.
* Identity and cryptography related changes:
@ -718,7 +722,7 @@ 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
* ``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``.
@ -768,12 +772,11 @@ Milestone 12 (First Public Beta)
* 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.
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
@ -905,7 +908,7 @@ to Corda in M10.
* 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.
* You can download Corda DemoBench from `here <https://www.corda.net/downloads/>`_
* Download `Corda DemoBench <https://www.corda.net/downloads/>`_.
* Vault:
* Soft Locking is a new feature implemented in the vault which prevent a node constructing transactions that attempt
@ -1131,7 +1134,7 @@ Milestone 6
* 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. See :ref:`notary-demo` to try it out. A BFT notary will be added later.
some financial situations.
* Node explorer app:
@ -1209,7 +1212,7 @@ New features in this release:
* 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:`persistence`.
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.
@ -1416,7 +1419,7 @@ Highlights of this release:
We have new documentation on:
* :doc:`event-scheduling`
* :doc:`core-types`
* :doc:`api-core-types`
* :doc:`key-concepts-consensus`
Summary of API changes (not exhaustive):

View File

@ -21,6 +21,7 @@ between the TLS and Node Identity certificates.
Certificate hierarchy
---------------------
A Corda network has 8 types of keys and a regular node requires 4 of them:
* The **root network CA** key
@ -52,51 +53,51 @@ underlying HSM device, but the default for dev-mode is Pure EdDSA (ed25519).
The following table presents the 5 signature schemes currently supported by Corda. The TLS column shows which of them
are compatible with TLS 1.2, while the default scheme per key type is also shown.
+-------------------------+-------------------------------------------------------------+-----+-----------------------+
| Cipher suite | Description | TLS | Default for |
+=========================+=============================================================|=====+=======================+
| Pure EdDSA using the | EdDSA represents the current state of the art in mainstream | NO | node identity |
| ed25519 curve | cryptography. It implements elliptic curve cryptography | | confidential identity |
| and SHA-512 | with deterministic signatures a fast implementation, | | network map (dev) |
| | explained constants, side channel resistance and many other | | |
| | desirable characteristics. However, it is relatively new | | |
| | and not widely supported, for example, you can't use it in | | |
| | TLS yet (a draft RFC exists but is not standardised yet). | | |
+-------------------------+-------------------------------------------------------------+-----+-----------------------+
| ECDSA using the | This is the default choice for most systems that support | YES | root network CA |
| NIST P-256 curve | elliptic curve cryptography today and is recommended by | | doorman CA |
| (secp256r1) | NIST. It is also supported by the majority of the HSM | | node CA |
| and SHA-256 | vendors. | | tls |
| | | | network map (CN) |
+-------------------------+-------------------------------------------------------------+-----+-----------------------+
| ECDSA using the | secp256k1 is the curve adopted by Bitcoin and as such there | YES | |
| Koblitz k1 curve | is a wealth of infrastructure, code and advanced algorithms | | |
| (secp256k1) | designed for use with it. This curve is standardised by | | |
| and SHA-256 | NIST as part of the "Suite B" cryptographic algorithms and | | |
| | as such is more widely supported than ed25519. By | | |
| | supporting it we gain access to the ecosystem of advanced | | |
| | cryptographic techniques and devices pioneered by the | | |
| | Bitcoin community. | | |
+-------------------------+-------------------------------------------------------------+-----+-----------------------+
| RSA (3072bit) PKCS#1 | RSA is well supported by any sort of hardware or software | YES | |
| and SHA-256 | as a signature algorithm no matter how old, for example, | | |
| | legacy HSMs will support this along with obsolete operating | | |
| | systems. RSA is using bigger keys than ECDSA and thus it is | | |
| | recommended for inclusion only for its backwards | | |
| | compatibility properties, and only for usage where legacy | | |
| | constraints or government regulation forbids the usage of | | |
| | more modern approaches. | | |
+-------------------------+-------------------------------------------------------------+-----+-----------------------+
| SPHINCS-256 | SPHINCS-256 is a post-quantum secure algorithm that relies | NO | |
| and SHA-512 | only on hash functions. It is included as a hedge against | | |
| | the possibility of a malicious adversary obtaining a | | |
| | quantum computer capable of running Shor's algorithm in | | |
| | future. SPHINCS is based ultimately on a clever usage of | | |
| | Merkle hash trees. Hash functions are a very heavily | | |
| | studied and well understood area of cryptography. Thus, it | | |
| | is assumed that there is a much lower chance of | | |
| | breakthrough attacks on the underlying mathematical | | |
| | problems. However, SPHINCS uses relatively big public keys, | | |
| | it is slower and outputs bigger signatures than EdDSA, | | |
| | ECDSA and RSA algorithms. | | |
+-------------------------+-------------------------------------------------------------+-----+-----------------------+
+-------------------------+---------------------------------------------------------------+-----+-------------------------+
| Cipher suite | Description | TLS | Default for |
+=========================+===============================================================+=====+=========================+
| | Pure EdDSA using the | | EdDSA represents the current state of the art in mainstream | NO | - node identity |
| | ed25519 curve | | cryptography. It implements elliptic curve cryptography | | - confidential identity |
| | and SHA-512 | | with deterministic signatures a fast implementation, | | - network map (dev) |
| | | explained constants, side channel resistance and many other | | |
| | | desirable characteristics. However, it is relatively new | | |
| | | and not widely supported, for example, you can't use it in | | |
| | | TLS yet (a draft RFC exists but is not standardised yet). | | |
+-------------------------+---------------------------------------------------------------+-----+-------------------------+
| | ECDSA using the | | This is the default choice for most systems that support | YES | - root network CA |
| | NIST P-256 curve | | elliptic curve cryptography today and is recommended by | | - doorman CA |
| | (secp256r1) | | NIST. It is also supported by the majority of the HSM | | - node CA |
| | and SHA-256 | | vendors. | | - tls |
| | | | - network map (CN) |
+-------------------------+---------------------------------------------------------------+-----+-------------------------+
| | ECDSA using the | | secp256k1 is the curve adopted by Bitcoin and as such there | YES | |
| | Koblitz k1 curve | | is a wealth of infrastructure, code and advanced algorithms | | |
| | (secp256k1) | | designed for use with it. This curve is standardised by | | |
| | and SHA-256 | | NIST as part of the "Suite B" cryptographic algorithms and | | |
| | | as such is more widely supported than ed25519. By | | |
| | | supporting it we gain access to the ecosystem of advanced | | |
| | | cryptographic techniques and devices pioneered by the | | |
| | | Bitcoin community. | | |
+-------------------------+---------------------------------------------------------------+-----+-------------------------+
| | RSA (3072bit) PKCS#1 | | RSA is well supported by any sort of hardware or software | YES | |
| | and SHA-256 | | as a signature algorithm no matter how old, for example, | | |
| | | legacy HSMs will support this along with obsolete operating | | |
| | | systems. RSA is using bigger keys than ECDSA and thus it is | | |
| | | recommended for inclusion only for its backwards | | |
| | | compatibility properties, and only for usage where legacy | | |
| | | constraints or government regulation forbids the usage of | | |
| | | more modern approaches. | | |
+-------------------------+---------------------------------------------------------------+-----+-------------------------+
| | SPHINCS-256 | | SPHINCS-256 is a post-quantum secure algorithm that relies | NO | |
| | and SHA-512 | | only on hash functions. It is included as a hedge against | | |
| | | the possibility of a malicious adversary obtaining a | | |
| | | quantum computer capable of running Shor's algorithm in | | |
| | | future. SPHINCS is based ultimately on a clever usage of | | |
| | | Merkle hash trees. Hash functions are a very heavily | | |
| | | studied and well understood area of cryptography. Thus, it | | |
| | | is assumed that there is a much lower chance of | | |
| | | breakthrough attacks on the underlying mathematical | | |
| | | problems. However, SPHINCS uses relatively big public keys, | | |
| | | it is slower and outputs bigger signatures than EdDSA, | | |
| | | ECDSA and RSA algorithms. | | |
+-------------------------+---------------------------------------------------------------+-----+-------------------------+

View File

@ -197,7 +197,7 @@ of ``INMEMORY`` type:
an exception at node startup.
Authentication/authorisation data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``dataSource`` structure defines the data provider supplying credentials and permissions for users. There exist two
supported types of such data source, identified by the ``dataSource.type`` field:
@ -218,7 +218,7 @@ supported types of such data source, identified by the ``dataSource.type`` field
in each table alongside the expected ones.
Password encryption
^^^^^^^^^^^^^^^^^^^
~~~~~~~~~~~~~~~~~~~
Storing passwords in plain text is discouraged in applications where security is critical. Passwords are assumed
to be in plain format by default, unless a different format is specified by the ``passwordEncryption`` field, like:
@ -235,7 +235,7 @@ it is currently the only non-plain password hash-encryption format supported. Ha
format can be produced by using the `Apache Shiro Hasher command line tool <https://shiro.apache.org/command-line-hasher.html>`_.
Caching user accounts data
^^^^^^^^^^^^^^^^^^^^^^^^^^
~~~~~~~~~~~~~~~~~~~~~~~~~~
A cache layer on top of the external data source of users credentials and permissions can significantly improve
performances in some cases, with the disadvantage of causing a (controllable) delay in picking up updates to the underlying data.

View File

@ -44,7 +44,7 @@ Here's the workflow for contract upgrades:
9. The ``Initiator`` node sends the proposed transaction, along with details of the new contract upgrade path that it
is proposing, to all participants of the state object
10. Each counterparty (the ``Acceptor``s) verifies the proposal, signs or rejects the state reissuance accordingly, and
10. Each counterparty (the ``Acceptor`` s) verifies the proposal, signs or rejects the state reissuance accordingly, and
sends a signature or rejection notification back to the initiating node
11. If signatures are received from all parties, the ``Initiator`` assembles the complete signed transaction and sends

View File

@ -76,7 +76,7 @@ absolute path to the node's base directory.
:serverNameTablePrefix: Prefix string to apply to all the database tables. The default is no prefix.
:transactionIsolationLevel: Transaction isolation level as defined by the ``TRANSACTION_`` constants in
``java.sql.Connection``, but without the "TRANSACTION_" prefix. Defaults to REPEATABLE_READ.
``java.sql.Connection``, but without the ``TRANSACTION_`` prefix. Defaults to REPEATABLE_READ.
:exportHibernateJMXStatistics: Whether to export Hibernate JMX statistics (caution: expensive run-time overhead)
:dataSourceProperties: This section is used to configure the jdbc connection and database driver used for the nodes persistence.
@ -208,9 +208,8 @@ Examples
General node configuration file for hosting the IRSDemo services:
.. literalinclude:: example-code/src/main/resources/example-node.conf
:language: javascript
Simple notary configuration file:
Simple notary configuration file:
.. parsed-literal::
@ -259,7 +258,7 @@ path to the node's base directory.
node certificate and private key.
.. note:: This is the non-secret value for the development certificates automatically generated during the first node run.
Longer term these keys will be managed in secure hardware devices.
Longer term these keys will be managed in secure hardware devices.
:trustStorePassword: The password to unlock the Trust store file (``<workspace>/certificates/truststore.jks``) containing
the Corda network root certificate. This is the non-secret value for the development certificates automatically
@ -291,5 +290,5 @@ Longer term these keys will be managed in secure hardware devices.
:password: The password
:permissions: A list of permissions for starting flows via RPC. To give the user the permission to start the flow
``foo.bar.FlowClass``, add the string ``StartFlow.foo.bar.FlowClass`` to the list. If the list
contains the string ``ALL``, the user can start any flow via RPC. This value is intended for administrator
users and for development.
contains the string ``ALL``, the user can start any flow via RPC. This value is intended for administrator
users and for development.

View File

@ -17,21 +17,20 @@ Custom serializer classes should follow the rules for including classes found in
Writing a Custom Serializer
---------------------------
Serializers must
* Inherit from ``net.corda.core.serialization.SerializationCustomSerializer``
* Provide a proxy class to transform the object to and from
* Implement the ``toProxy`` and ``fromProxy`` methods
* Be either included into CorDapp Jar or made known to the running process via ``amqp.custom.serialization.scanSpec``
system property.
This system property may be necessary to be able to discover custom serializer in the classpath. At a minimum the value
of the property should include comma separated set of packages where custom serializers located. Full syntax includes
scanning specification as defined by: `<http://github.com/lukehutch/fast-classpath-scanner/wiki/2.-Constructor#scan-spec>`
system property. This system property may be necessary to be able to discover custom serializer in the classpath. At a minimum the value
of the property should include comma separated set of packages where custom serializers located. Full syntax includes
scanning specification as defined by: `<http://github.com/lukehutch/fast-classpath-scanner/wiki/2.-Constructor#scan-spec>`
Serializers inheriting from ``SerializationCustomSerializer`` have to implement two methods and two types.
Example
-------
Consider this example class
Consider this example class:
.. sourcecode:: java

View File

@ -33,9 +33,7 @@ handling, and ensures the Corda service is run at boot.
5. Create a directory called ``cordapps`` in ``/opt/corda`` and save your CorDapp jar file to it. Alternatively, download one of
our `sample CorDapps <https://www.corda.net/samples/>`_ to the ``cordapps`` directory
6. Save the below as ``/opt/corda/node.conf``. See :doc:`corda-configuration-file` for a description of these options
.. code-block:: json
6. Save the below as ``/opt/corda/node.conf``. See :doc:`corda-configuration-file` for a description of these options::
basedir : "/opt/corda"
p2pAddress : "example.com:10002"
@ -192,9 +190,7 @@ at boot, and means the Corda service stays running with no users connected to th
* Oracle Java 8. The supported versions are listed in :doc:`getting-set-up`
1. Create a Corda directory and download the Corda jar. Replace ``VERSION_NUMBER`` with the desired version. Here's an
example using PowerShell:
.. code-block:: PowerShell
example using PowerShell::
mkdir C:\Corda
wget http://jcenter.bintray.com/net/corda/corda/VERSION_NUMBER/corda-VERSION_NUMBER.jar -OutFile C:\Corda\corda.jar
@ -202,9 +198,7 @@ at boot, and means the Corda service stays running with no users connected to th
2. Create a directory called ``cordapps`` in ``C:\Corda\`` and save your CorDapp jar file to it. Alternatively,
download one of our `sample CorDapps <https://www.corda.net/samples/>`_ to the ``cordapps`` directory
3. Save the below as ``C:\Corda\node.conf``. See :doc:`corda-configuration-file` for a description of these options
.. code-block:: json
3. Save the below as ``C:\Corda\node.conf``. See :doc:`corda-configuration-file` for a description of these options::
basedir : "C:\\Corda"
p2pAddress : "example.com:10002"

View File

@ -419,7 +419,7 @@ the other counterparties. Instead they will be informed the flow has terminated
generic exception.
.. note:: A future version will extend this to give the node administrator more control on what to do with such erroring
flows.
flows.
Throwing a ``FlowException`` enables a flow to reject a piece of data it has received back to the sender. This is typically
done in the ``unwrap`` method of the received ``UntrustworthyData``. In the above example the seller checks the price

View File

@ -39,9 +39,9 @@ any issues, please consult the :doc:`troubleshooting` page, or reach out on `Sla
The set-up instructions are available for the following platforms:
* :ref:`windows-label` (or `in video form <https://vimeo.com/217462250>`_)
* :ref:`windows-label` (or `in video form <https://vimeo.com/217462250>`__)
* :ref:`mac-label` (or `in video form <https://vimeo.com/217462230>`_)
* :ref:`mac-label` (or `in video form <https://vimeo.com/217462230>`__)
.. _windows-label:
@ -171,8 +171,8 @@ The best way to check that everything is working fine is by taking a deeper look
Next, you should read through :doc:`Corda Key Concepts <key-concepts>` to understand how Corda works.
By then, you'll be ready to start writing your own CorDapps. Learn how to do this in the
:doc:`Hello, World tutorial <hello-world-introduction>`. You may want to refer to the :doc:`API docs <api-index>`, the
:doc:`Hello, World tutorial <hello-world-introduction>`. You may want to refer to the API documentation, the
:doc:`flow cookbook <flow-cookbook>` and the `samples <https://www.corda.net/samples/>`_ along the way.
If you encounter any issues, please see the :doc:`troubleshooting` page, or get in touch with us on the
`forums <https://discourse.corda.net/>`_ or via `slack <http://slack.corda.net/>`_.
If you encounter any issues, please see the :doc:`troubleshooting` page, or ask on
`Stack Overflow <https://stackoverflow.com/questions/tagged/corda>`_ or via `our Slack channels <http://slack.corda.net/>`_.

View File

@ -124,7 +124,7 @@ If the flow worked, it should have recorded a new IOU in the vaults of both Part
We can check the contents of each node's vault by running:
.. code-block:: base
.. code-block:: bash
run vaultQuery contractStateType: com.template.IOUState

View File

@ -39,7 +39,7 @@ Corda also uses several other techniques to maximize privacy on the network:
* **Transaction tear-offs**: Transactions are structured in a way that allows them to be digitally signed without
disclosing the transaction's contents. This is achieved using a data structure called a Merkle tree. You can read
more about this technique in :doc:`merkle-trees`.
more about this technique in :doc:`tutorial-tear-offs`.
* **Key randomisation**: The parties to a transaction are identified only by their public keys, and fresh keypairs are
generated for each transaction. As a result, an onlooker cannot identify which parties were involved in a given
transaction.

View File

@ -95,8 +95,10 @@ Each required signers should only sign the transaction if the following two cond
* **Transaction validity**: For both the proposed transaction, and every transaction in the chain of transactions
that created the current proposed transaction's inputs:
* The transaction is digitally signed by all the required parties
* The transaction is *contractually valid* (see :doc:`key-concepts-contracts`)
* **Transaction uniqueness**: There exists no other committed transaction that has consumed any of the inputs to
our proposed transaction (see :doc:`key-concepts-consensus`)

View File

@ -54,7 +54,7 @@ for maintenance and other minor purposes.
:``internal.peers.$identity``:
These are a set of private queues only available to the node which it uses to route messages destined to other peers.
The queue name ends in the base 58 encoding of the peer's identity key. There is at most one queue per peer. The broker
creates a bridge from this queue to the peer's ``p2p.inbound.$identity`` queue, using the network map service to lookup the
creates a bridge from this queue to the peer's ``p2p.inbound.$identity`` queue, using the network map service to lookup the
peer's network address.
:``internal.services.$identity``:

View File

@ -1,4 +1,4 @@
Network permissioning
Network permissioning
=====================
.. contents::

View File

@ -77,19 +77,19 @@ 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 <https://github.com/corda/corda/commit/d17670c747d16b7f6e06e19bbbd25eb06e45cb93>`_
`here <https://github.com/corda/corda/commit/d17670c747d16b7f6e06e19bbbd25eb06e45cb93>`__
* 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 <https://github.com/corda/corda/commit/342090db62ae40cef2be30b2ec4aa451b099d0b7>`_
`here <https://github.com/corda/corda/commit/342090db62ae40cef2be30b2ec4aa451b099d0b7>`__
.. 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 <https://github.com/corda/corda/commit/128d5cad0af7fc5595cac3287650663c9c9ac0a3>`_
`here <https://github.com/corda/corda/commit/128d5cad0af7fc5595cac3287650663c9c9ac0a3>`__
Significant Changes in 3.0
~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -178,7 +178,7 @@ Significant Changes in 3.0
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
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.
@ -197,8 +197,10 @@ Significant Changes in 3.0
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

View File

@ -1,15 +1,15 @@
Running a notary service
------------------------
At present we have several prototype notary implementations:
At present we have several notary implementations:
1. ``SimpleNotaryService`` (single node) -- commits the provided transaction input states without any validation.
2. ``ValidatingNotaryService`` (single node) -- retrieves and validates the whole transaction history
(including the given transaction) before committing.
3. ``RaftNonValidatingNotaryService`` (distributed) -- functionally equivalent to ``SimpleNotaryService``, but stores
the committed states in a distributed collection replicated and persisted in a Raft cluster. For the consensus layer
we are using the `Copycat <http://atomix.io/copycat/>`_ framework
4. ``RaftValidatingNotaryService`` (distributed) -- as above, but performs validation on the transactions received
we are using the `Copycat <http://atomix.io/copycat/>`_ framework.
4. ``RaftValidatingNotaryService`` (distributed) -- as above, but performs validation on the transactions received.
To have a node run a notary service, you need to set appropriate ``notary`` configuration before starting it
(see :doc:`corda-configuration-file` for reference).

View File

@ -94,7 +94,7 @@ tests in ``FxTransactionBuildTutorialTest.kt`` and
part of a simulated in-memory network of nodes.
.. note:: Before creating the IntelliJ run configurations for these unit tests
go to Run -> Edit |nbsp| Configurations -> Defaults -> JUnit, add
go to Run -> Edit Configurations -> Defaults -> JUnit, add
``-javaagent:lib/quasar.jar``
to the VM options, and set Working directory to ``$PROJECT_DIR$``
so that the ``Quasar`` instrumentation is correctly configured.
@ -301,4 +301,4 @@ overall transaction id is still provable from the
not expose that data to the other node directly. A full example of this
can be found in the ``NodeInterestRates`` Oracle code from the
``irs-demo`` project which interacts with the ``RatesFixFlow`` flow.
Also, refer to the :doc:`merkle-trees` documentation.
Also, refer to the :doc:`tutorial-tear-offs`.

View File

@ -156,11 +156,13 @@ The key files and directories are as follows:
about which version is required
* **lib** contains the Quasar jar which rewrites our CorDapp's flows to be checkpointable
* **kotlin-source** contains the source code for the example CorDapp written in Kotlin
* **kotlin-source/src/main/kotlin** contains the source code for the example CorDapp
* **kotlin-source/src/main/resources** contains the certificate store, some static web content to be served by the
nodes and the WebServerPluginRegistry file
* **kotlin-source/src/test/kotlin** contains unit tests for the contracts and flows, and the driver to run the nodes
via IntelliJ
* **kotlin-source/src/main/kotlin** contains the source code for the example CorDapp
* **kotlin-source/src/main/resources** contains the certificate store, some static web content to be served by the
nodes and the WebServerPluginRegistry file
* **kotlin-source/src/test/kotlin** contains unit tests for the contracts and flows, and the driver to run the nodes
via IntelliJ
* **java-source** contains the same source code, but written in Java. CorDapps can be developed in any language
targeting the JVM

View File

@ -53,6 +53,6 @@ The following code snippet is taken from ``NodeInterestRates.kt`` and implements
components (leaves). However, it can happen that having transaction with multiple commands one party reveals only subset of them to the Oracle.
As signing is done now over the Merkle root hash, the service signs all commands of given type, even though it didn't see
all of them. In the case however where all of the commands should be visible to an Oracle, one can type ``ftx.checkAllComponentsVisible(COMMANDS_GROUP)`` before invoking ``ftx.verify``.
``checkAllComponentsVisible`` is using a sophisticated underlying partial Merkle tree check to guarantee that all of
the components of a particular group that existed in the original ``WireTransaction`` are included in the received
``FilteredTransaction``.
``checkAllComponentsVisible`` is using a sophisticated underlying partial Merkle tree check to guarantee that all of
the components of a particular group that existed in the original ``WireTransaction`` are included in the received
``FilteredTransaction``.

View File

@ -101,6 +101,7 @@ Corda Plugins
For example:
.. sourcecode:: groovy
dependencies {
classpath "net.corda.plugins:cordapp:$corda_gradle_plugins_version"
}
@ -169,9 +170,7 @@ Configuration
^^^^^^^^^^^^^
Nodes that do not require SSL to be enabled for RPC clients now need an additional port to be specified as part of their configuration.
To do this, add a block as follows to the nodes configuraiton:
.. sourcecode:: script
To do this, add a block as follows to the nodes configuration::
rpcSettings {
adminAddress "localhost:10007"
@ -179,16 +178,14 @@ To do this, add a block as follows to the nodes configuraiton:
to `node.conf` files.
Also, the property `rpcPort` is now deprecated, so it would be preferable to substitute properties specified that way e.g., `rpcPort=10006` with a block as follows:
.. sourcecode:: script
Also, the property `rpcPort` is now deprecated, so it would be preferable to substitute properties specified that way e.g., `rpcPort=10006` with a block as follows::
rpcSettings {
address "localhost:10006"
adminAddress "localhost:10007"
}
Equivalent changes should be performed on classes extending `CordformDefinition`.
Equivalent changes should be performed on classes extending ``CordformDefinition``.
Testing
^^^^^^^
@ -257,7 +254,6 @@ Public Beta (M12) to V1.0
-------------------------
:ref:`From Milestone 14 <changelog_m14>`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Build
^^^^^

View File

@ -141,14 +141,12 @@ These are for testing purposes and would be removed in a production CorDapp.
Resources
---------
In writing a CorDapp, you should consult the following resources:
In writing a CorDapp, these pages may be particularly helpful:
* :doc:`Getting Set Up </getting-set-up>` to set up your development environment
* The :doc:`Hello, World! tutorial </hello-world-index>` to write your first CorDapp
* :doc:`Building a CorDapp </cordapp-build-systems>` to build and run your CorDapp
* The :doc:`API docs </api-index>` to read about the API available in developing CorDapps
* There is also a :doc:`cheatsheet </cheat-sheet>` recapping the key types
* The :doc:`Flow cookbook </flow-cookbook>` to see code examples of how to perform common flow tasks
* `Sample CorDapps <https://www.corda.net/samples/>`_ showing various parts of Corda's functionality
* :doc:`getting-set-up`, to set up your development environment.
* The :doc:`hello-world-introduction` tutorial to write your first CorDapp.
* :doc:`cordapp-build-systems` to build and run your CorDapp.
* The `API docs </api/javadoc/index.html>`_ to read about the API available in developing CorDapps.
* There is also a :doc:`cheat-sheet` recapping the key types.
* The :doc:`flow-cookbook` to see code examples of how to perform common flow tasks.
* `Sample CorDapps <https://www.corda.net/samples/>`_ showing various parts of Corda's functionality.

View File

@ -1,58 +1,16 @@
package net.corda.node.services.vault
import net.corda.core.contracts.Amount
import net.corda.core.contracts.ContractState
import net.corda.core.contracts.FungibleAsset
import net.corda.core.contracts.LinearState
import net.corda.core.contracts.PartyAndReference
import net.corda.core.contracts.StateAndRef
import net.corda.core.contracts.StateRef
import net.corda.core.crypto.Crypto
import net.corda.core.crypto.SecureHash
import net.corda.core.crypto.SignatureMetadata
import net.corda.core.crypto.generateKeyPair
import net.corda.core.crypto.toStringShort
import net.corda.core.contracts.*
import net.corda.core.crypto.*
import net.corda.core.identity.CordaX500Name
import net.corda.core.identity.Party
import net.corda.core.internal.packageName
import net.corda.core.node.services.IdentityService
import net.corda.core.node.services.Vault
import net.corda.core.node.services.VaultQueryException
import net.corda.core.node.services.VaultService
import net.corda.core.node.services.queryBy
import net.corda.core.node.services.trackBy
import net.corda.core.node.services.vault.BinaryComparisonOperator
import net.corda.core.node.services.vault.ColumnPredicate
import net.corda.core.node.services.vault.DEFAULT_PAGE_NUM
import net.corda.core.node.services.vault.DEFAULT_PAGE_SIZE
import net.corda.core.node.services.vault.MAX_PAGE_SIZE
import net.corda.core.node.services.vault.PageSpecification
import net.corda.core.node.services.vault.QueryCriteria
import net.corda.core.node.services.vault.QueryCriteria.FungibleAssetQueryCriteria
import net.corda.core.node.services.vault.QueryCriteria.LinearStateQueryCriteria
import net.corda.core.node.services.vault.QueryCriteria.SoftLockingCondition
import net.corda.core.node.services.vault.QueryCriteria.SoftLockingType
import net.corda.core.node.services.vault.QueryCriteria.TimeCondition
import net.corda.core.node.services.vault.QueryCriteria.TimeInstantType
import net.corda.core.node.services.vault.QueryCriteria.VaultCustomQueryCriteria
import net.corda.core.node.services.vault.QueryCriteria.VaultQueryCriteria
import net.corda.core.node.services.vault.Sort
import net.corda.core.node.services.vault.SortAttribute
import net.corda.core.node.services.vault.builder
import net.corda.core.node.services.*
import net.corda.core.node.services.vault.*
import net.corda.core.node.services.vault.QueryCriteria.*
import net.corda.core.transactions.TransactionBuilder
import net.corda.core.utilities.NonEmptySet
import net.corda.core.utilities.OpaqueBytes
import net.corda.core.utilities.days
import net.corda.core.utilities.seconds
import net.corda.core.utilities.toHexString
import net.corda.finance.AMOUNT
import net.corda.finance.CHF
import net.corda.finance.DOLLARS
import net.corda.finance.GBP
import net.corda.finance.POUNDS
import net.corda.finance.SWISS_FRANCS
import net.corda.finance.USD
import net.corda.finance.`issued by`
import net.corda.core.utilities.*
import net.corda.finance.*
import net.corda.finance.contracts.CommercialPaper
import net.corda.finance.contracts.Commodity
import net.corda.finance.contracts.DealState
@ -67,18 +25,7 @@ import net.corda.node.internal.configureDatabase
import net.corda.nodeapi.internal.persistence.CordaPersistence
import net.corda.nodeapi.internal.persistence.DatabaseConfig
import net.corda.nodeapi.internal.persistence.DatabaseTransaction
import net.corda.testing.core.ALICE_NAME
import net.corda.testing.core.BOB_NAME
import net.corda.testing.core.BOC_NAME
import net.corda.testing.core.CHARLIE_NAME
import net.corda.testing.core.DUMMY_NOTARY_NAME
import net.corda.testing.core.SerializationEnvironmentRule
import net.corda.testing.core.TestIdentity
import net.corda.testing.core.dummyCommand
import net.corda.testing.core.expect
import net.corda.testing.core.expectEvents
import net.corda.testing.core.sequence
import net.corda.testing.core.singleIdentityAndCert
import net.corda.testing.core.*
import net.corda.testing.internal.TEST_TX_TIME
import net.corda.testing.internal.rigorousMock
import net.corda.testing.internal.vault.DUMMY_LINEAR_CONTRACT_PROGRAM_ID
@ -2029,7 +1976,7 @@ abstract class VaultQueryTestsBase : VaultQueryParties {
val updates = database.transaction {
val updates =
// DOCSTART VaultQueryExample15
vaultService.trackBy<Cash.State>().updates // UNCONSUMED default
vaultService.trackBy<Cash.State>().updates // UNCONSUMED default
// DOCEND VaultQueryExample15
vaultFiller.fillWithSomeTestCash(100.DOLLARS, notaryServices, 5, DUMMY_CASH_ISSUER)
@ -2213,9 +2160,7 @@ abstract class VaultQueryTestsBase : VaultQueryParties {
@Test
fun trackDealStates() {
val updates = database.transaction {
// DOCSTART VaultQueryExample17
val (snapshot, updates) = vaultService.trackBy<DealState>()
// DOCEND VaultQueryExample17