Minor changes to text to more accurately reflect the current implementation. (#3477)

docs/source/key-concepts-contracts.rst

@@ -24,7 +24,7 @@ transaction gathers all the required signatures, it is only valid if it is also
 
 **Contract validity** is defined as follows:
 
-* Each state points to a *contract*
+* Each transaction state specifies a *contract* type
 * A *contract* takes a transaction as input, and states whether the transaction is considered valid based on the
   contract's rules
 * A transaction is only valid if the contract of **every input state** and **every output state** considers it to be
@@ -56,12 +56,15 @@ given transaction. For example, transaction validity cannot depend on the time a
 the amount of information the peer running the contract holds. This is a necessary condition to ensure that all peers
 on the network reach consensus regarding the validity of a given ledger update.
 
-To achieve this, contracts evaluate transactions in a deterministic sandbox. The sandbox has a whitelist that
+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
 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
+(see the :doc:`Deterministic Corda Modules <deterministic-modules>`).
+
 Contract limitations
 --------------------
 Since a contract has no access to information from the outside world, it can only check the transaction for internal

docs/source/key-concepts-tradeoffs.rst

@@ -63,8 +63,8 @@ is designed to make this possible by:
 
 * Having permissioned networks, meaning that participants are aware of who they are dealing with in every single
   transaction
-* All code contracts are backed by a legal document describing the contract's intended behavior which can be relied
-  upon to resolve conflicts
+* All code contracts should include a ``LegalProseReference`` link to the legal document describing the contract's intended behavior
+  which can be relied upon to resolve conflicts
 
 Build vs. re-use
 ----------------

docs/source/permissioning.rst

@@ -13,7 +13,8 @@ Every Corda node is a part of a network (also called a zone), and networks are *
 zone, a node needs a signed X.509 certificate from the network operator. Production deployments require a secure certificate authority.
 The issued certificates take the form of three keystores in a node's ``<workspace>/certificates/`` folder:
 
-* ``network-root-truststore.jks``, which stores the network/zone operator's public keys and certificates
+* ``network-root-truststore.jks``, the network/zone operator's public keys and certificates as provided by them with a standard password. Can be deleted after initial registration
+* ``truststore.jks``, the network/zone operator's public keys and certificates in keystore with a locally configurable password as protection against certain attacks
 * ``nodekeystore.jks``, which stores the node’s identity keypairs and certificates
 * ``sslkeystore.jks``, which stores the node’s TLS keypairs and certificates