ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-04-11 13:21:26 +00:00
Code Issues Actions2 Packages Projects Releases Wiki Activity

Added a contract constraints section to the key concepts doc. ()

Browse Source 
Documentation for contract constraints.

Added to index.

Review fixes round 1.

More review fixes.

Review fixes.

Explained package contents.

review fixes.

Addressed RGB's final review comments.

Updated source code type to 'java'
This commit is contained in:
Clinton 2017-09-30 13:10:58 +01:00 committed by Clinton Alexander
parent 659b447362
commit fee156cc4a
2 changed files with 9 additions and 9 deletions

12
docs/packages.md

@ -28,12 +28,6 @@ Internal, do not use. These APIs and implementations which are currently being r
Exception types and some utilities for working with observables and futures.
# Package net.corda.core.cordapp
This package contains the interface to CorDapps from within a node. A CorDapp can access its own context by using
the CordappProvider.getAppContext() class. These classes are not intended to be constructed manually and no interface
to do this will be provided.
# Package net.corda.core.concurrent
Provides a simplified [java.util.concurrent.Future] class that allows registration of a callback to execute when the future
@ -47,6 +41,12 @@ with [Contract], or see the examples in [net.corda.finance.contracts].
Corda smart contracts are a combination of state held on the distributed ledger, and verification logic which defines
which transformations of state are valid.
# Package net.corda.core.cordapp
This package contains the interface to CorDapps from within a node. A CorDapp can access it's own context by using
the CordappProvider.getAppContext() class. These classes are not intended to be constructed manually and no interface
to do this will be provided.
# Package net.corda.core.crypto
Cryptography data and utility classes used for signing, verifying, key management and data integrity checks.

6
docs/source/key-concepts-contract-constraints.rst

@ -15,7 +15,7 @@ A typical constraint is the hash of the CorDapp JAR that contains the contract a
include constraints that require specific signers of the JAR, or both the signer and the hash. Constraints can be
specified when constructing a transaction; if unspecified, an automatic constraint is used.
A ``TransactionState`` has a ``constraint`` field that represents that state's attachment constraint. When a party
``TransactionState``s have a ``constraint`` field that represents that state's attachment constraint. When a party
constructs a ``TransactionState`` without specifying the constraint parameter a default value
(``AutomaticHashConstraint``) is used. This default will be automatically resolved to a specific
``HashAttachmentConstraint`` that contains the hash of the attachment which contains the contract of that
@ -80,8 +80,8 @@ attachment JAR. This allows for trusting of attachments from trusted entities.
Limitations
-----------
An ``AttachmentConstraint`` is verified by running the ``AttachmentConstraint.isSatisfiedBy`` method. When this is
called it is provided only the relevant attachment by the transaction that is verifying it.
``AttachmentConstraint``s are verified by running the ``AttachmentConstraint.isSatisfiedBy`` method. When this is called
it is provided only the relevant attachment by the transaction that is verifying it.
Testing
-------