ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-24 07:06:44 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

DEVREL-1287 - Simple prose checking

Browse Source
This commit is contained in:
ChrissyAtWork 2019-04-26 10:39:38 +01:00 committed by Mike Hearn
parent 33b50836d2
commit a2ed8cb374
1 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/source/key-concepts-contracts.rst
View File

@ -3,9 +3,9 @@ Contracts
.. topic:: Summary
* *A valid transaction must be accepted by the contract of each of its input and output states*
* *Contracts are written in a JVM programming language (e.g. Java or Kotlin)*
* *Contract execution is deterministic and its acceptance of a transaction is based on the transaction's contents alone*
* *A transaction is contractually valid if all of its input and output states are acceptable according to the contract.*
* *Contracts are written in a JVM programming language such as Java or Kotlin.*
* *Contract execution is deterministic, and transaction acceptance is based on the transaction's contents alone.*
.. only:: htmlmode
@ -39,11 +39,11 @@ We can picture this situation as follows:
The contract code can be written in any JVM language, and has access to the full capabilities of the language,
including:
* Checking the number of inputs, outputs, commands, time-window, and/or attachments
* Checking the number of inputs, outputs, commands, time-windows or attachments
* Checking the contents of any of these components
* Looping constructs, variable assignment, function calls, helper methods, etc.
* Grouping similar states to validate them as a group (e.g. imposing a rule on the combined value of all the cash
states)
* Looping constructs, variable assignment, function calls, helper methods, and so on
* Grouping similar states to validate them as a group; for example, imposing a rule on the combined value of all the cash
states
A transaction that is not contractually valid is not a valid proposal to update the ledger, and thus can never be
committed to the ledger. In this way, contracts impose rules on the evolution of states over time that are
@ -58,11 +58,11 @@ on the network reach consensus regarding the validity of a given ledger update.
Future versions of Corda will evaluate transactions in a strictly deterministic sandbox. The sandbox has a whitelist that
prevents the contract from importing libraries that could be a source of non-determinism. This includes libraries
that provide the current time, random number generators, libraries that provide filesystem access or networking
that provide the current time, random number generators, libraries that provide file system access or networking
libraries, for example. Ultimately, the only information available to the contract when verifying the transaction is
the information included in the transaction itself.
Developers can pre-verify their CorDapps are determinsitic by linking their CorDapps against the deterministic modules
**Tip:** Developers can pre-verify that their CorDapps are determinsitic by linking their CorDapps against the deterministic modules
(see the :doc:`Deterministic Corda Modules <deterministic-modules>`).
Contract limitations