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

Minor changes to the Notary doc

Browse Source
This commit is contained in:
Andrius Dagys 2016-05-13 15:42:02 +01:00
parent 0da604e33b
commit 7d0ce00978
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/source/consensus.rst
View File

@ -29,6 +29,8 @@ The data model is extended so that every **state** has an appointed Notary:
All transactions have to be signed by their input state Notary for the output states to be **valid** (apart from *issue* transactions, containing no input states).
.. note:: The Notary is a logical concept and can itself be a distributed entity, potentially a cluster maintained by mutually distrusting parties
When the Notary is requested to sign a transaction, it either signs over it, attesting that the outputs are the **unique** successors of the inputs,
or provides conflict information for any input state that had been consumed by another transaction it had signed before.
In doing so, the Notary provides the point of finality in the system. Until the Notary signature is obtained, parties cannot be sure that an equally valid, but conflicting transaction,
@ -57,8 +59,6 @@ More than one Notary can exist in the network. This gives the following benefits
* **Load balancing**. Spreading the transaction load over multiple Notaries will allow higher transaction throughput in the platform overall
* **Low latency**. Latency could be minimised by choosing a Notary physically closer the transacting parties
For fault tolerance each Notary can itself be a distributed entity, potentially a cluster maintained by mutually distrusting parties.
A transaction should only be signed by a Notary if all of its input states point to it.
In cases where a transaction involves states controlled by multiple Notaries, the states first have to be repointed to the same notary.
This is achieved by using a special type of transaction that doesn't modify anything but the Notary pointer of the state.
@ -71,10 +71,10 @@ Timestamping
In this model the Notary also acts as a **Timestamping Authority**, verifying the transaction timestamp command.
For a timestamp to be meaningful, its implications must be binding on the party requesting it.
A party obtains a timestamp signature to prove that some event happened before/at/or after a particular point in time,
but without having to *commit* the transaction it has a choice of whether or not to reveal this fact until some point in the future.
As a result, we need to ensure that the Notary either has to commit the transaction within some time tolerance,
or perform timestamp validation and input state commit at the same time, which is the chosen behaviour for this model.
A party can obtain a timestamp signature in order to prove that some event happened before/on/or after a particular point in time.
However, if the party is not also compelled to commit to the associated transaction, it has a choice of whether or not to reveal this fact until some point in the future.
As a result, we need to ensure that the Notary either has to also sign the transaction within some time tolerance,
or perform timestamping *and* notarisation at the same time, which is the chosen behaviour for this model.
Implementation & Usage
----------------------