mirror of
https://github.com/corda/corda.git
synced 2024-12-20 05:28:21 +00:00
Docs: fix some broken markup that caused rendering errors and warnings.
This commit is contained in:
Mike Hearn
parent
e110d17bce
commit
54e1a7aa7e
@ -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:
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
----------
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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 node’s ``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:
|
||||
|
||||
@ -769,11 +773,10 @@ Milestone 12 (First Public Beta)
|
||||
|
||||
* 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.
|
||||
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):
|
||||
|
||||
@ -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. | | |
|
||||
+-------------------------+-------------------------------------------------------------+-----+-----------------------+
|
||||
+=========================+===============================================================+=====+=========================+
|
||||
| | 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. | | |
|
||||
+-------------------------+---------------------------------------------------------------+-----+-------------------------+
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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"
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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/>`_.
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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`)
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
Network permissioning
|
||||
Network permissioning
|
||||
=====================
|
||||
|
||||
.. contents::
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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`.
|
||||
@ -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
|
||||
|
||||
* **java-source** contains the same source code, but written in Java. CorDapps can be developed in any language
|
||||
targeting the JVM
|
||||
|
||||
|
||||
@ -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
|
||||
^^^^^
|
||||
|
||||
@ -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.
|
||||
@ -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
|
||||
@ -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
|
||||
|
||||
Loading…
Reference in New Issue
Block a user