ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-05-28 21:24:24 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Makes it clear that notaries are clusters or 1+ nodes.

Browse Source
This commit is contained in:
Joel Dudley 2018-04-30 14:58:13 +01:00 committed by GitHub
parent beef7bdfba
commit 79cbaf8adf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 42 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
docs/source/key-concepts-notaries.rst
View File

@ -3,9 +3,9 @@ Notaries
.. topic:: Summary .. topic:: Summary
* *Notaries prevent "double-spends"* * *Notary clusters prevent "double-spends"*
* *Notaries may optionally also validate transactions* * *Notary clusters may optionally also validate transactions*
* *A network can have several notaries, each running a different consensus algorithm* * *A network can have several notary clusters, each running a different consensus algorithm*
Video Video
----- -----
@ -16,80 +16,83 @@ Video
Overview Overview
-------- --------
A *notary* is a network service that provides **uniqueness consensus** by attesting that, for a given transaction, it A *notary cluster* is a network service that provides **uniqueness consensus** by attesting that, for a given
has not already signed other transactions that consumes any of the proposed transaction's input states. transaction, it has not already signed other transactions that consumes any of the proposed transaction's input states.
Upon being sent asked to notarise a transaction, a notary will either: Upon being sent asked to notarise a transaction, a notary cluster will either:
* Sign the transaction if it has not already signed other transactions consuming any of the proposed transaction's * Sign the transaction if it has not already signed other transactions consuming any of the proposed transaction's
input states input states
* Reject the transaction and flag that a double-spend attempt has occurred otherwise * Reject the transaction and flag that a double-spend attempt has occurred otherwise
In doing so, the notary provides the point of finality in the system. Until the notary's signature is obtained, parties In doing so, the notary cluster provides the point of finality in the system. Until the notary cluster's signature is
cannot be sure that an equally valid, but conflicting, transaction will not be regarded as the "valid" attempt to spend obtained, parties cannot be sure that an equally valid, but conflicting, transaction will not be regarded as the
a given input state. However, after the notary's signature is obtained, we can be sure that the proposed "valid" attempt to spend a given input state. However, after the notary cluster's signature is obtained, we can be sure
transaction's input states had not already been consumed by a prior transaction. Hence, notarisation is the point that the proposed transaction's input states have not already been consumed by a prior transaction. Hence, notarisation
of finality in the system. is the point of finality in the system.
Every state has an appointed notary, and a notary will only notarise a transaction if it is the appointed notary Every state has an appointed notary cluster, and a notary cluster will only notarise a transaction if it is the
of all the transaction's input states. appointed notary cluster of all the transaction's input states.
Consensus algorithms Consensus algorithms
-------------------- --------------------
Corda has "pluggable" consensus, allowing notaries to choose a consensus algorithm based on their requirements in Corda has "pluggable" consensus, allowing notary clusters to choose a consensus algorithm based on their requirements in
terms of privacy, scalability, legal-system compatibility and algorithmic agility. terms of privacy, scalability, legal-system compatibility and algorithmic agility.
In particular, notaries may differ in terms of: In particular, notary clusters may differ in terms of:
* **Structure** - a notary may be a single network node, a cluster of mutually-trusting nodes, or a cluster of * **Structure** - a notary cluster may be a single node, several mutually-trusting nodes, or several
mutually-distrusting nodes mutually-distrusting nodes
* **Consensus algorithm** - a notary service may choose to run a high-speed, high-trust algorithm such as RAFT, a * **Consensus algorithm** - a notary cluster may choose to run a high-speed, high-trust algorithm such as RAFT, a
low-speed, low-trust algorithm such as BFT, or any other consensus algorithm it chooses low-speed, low-trust algorithm such as BFT, or any other consensus algorithm it chooses
Validation Validation
^^^^^^^^^^ ^^^^^^^^^^
A notary service must also decide whether or not to provide **validity consensus** by validating each transaction A notary cluster must also decide whether or not to provide **validity consensus** by validating each transaction
before committing it. In making this decision, they face the following trade-off: before committing it. In making this decision, it faces the following trade-off:
* If a transaction **is not** checked for validity, it creates the risk of "denial of state" attacks, where a node * If a transaction **is not** checked for validity, it creates the risk of "denial of state" attacks, where a node
knowingly builds an invalid transaction consuming some set of existing states and sends it to the knowingly builds an invalid transaction consuming some set of existing states and sends it to the
notary, causing the states to be marked as consumed notary cluster, causing the states to be marked as consumed
* If the transaction **is** checked for validity, the notary will need to see the full contents of the transaction and * If the transaction **is** checked for validity, the notary will need to see the full contents of the transaction and
its dependencies. This leaks potentially private data to the notary its dependencies. This leaks potentially private data to the notary cluster
There are several further points to keep in mind when evaluating this trade-off. In the case of the non-validating There are several further points to keep in mind when evaluating this trade-off. In the case of the non-validating
model, Corda's controlled data distribution model means that information on unconsumed states is not widely shared. model, Corda's controlled data distribution model means that information on unconsumed states is not widely shared.
Additionally, Corda's permissioned network means that the notary can store to the identity of the party that created Additionally, Corda's permissioned network means that the notary cluster can store the identity of the party that
the "denial of state" transaction, allowing the attack to be resolved off-ledger. created the "denial of state" transaction, allowing the attack to be resolved off-ledger.
In the case of the validating model, the use of anonymous, freshly-generated public keys instead of legal identities to In the case of the validating model, the use of anonymous, freshly-generated public keys instead of legal identities to
identify parties in a transaction limit the information the notary sees. identify parties in a transaction limit the information the notary cluster sees.
Multiple notaries Multiple notaries
----------------- -----------------
Each Corda network can have multiple notaries, each potentially running a different consensus algorithm. This provides Each Corda network can have multiple notary clusters, each potentially running a different consensus algorithm. This
several benefits: provides several benefits:
* **Privacy** - we can have both validating and non-validating notary services on the same network, each running a * **Privacy** - we can have both validating and non-validating notary clusters on the same network, each running a
different algorithm. This allows nodes to choose the preferred notary on a per-transaction basis different algorithm. This allows nodes to choose the preferred notary cluster on a per-transaction basis
* **Load balancing** - spreading the transaction load over multiple notaries allows higher transaction throughput for * **Load balancing** - spreading the transaction load over multiple notary clusters allows higher transaction
the platform overall throughput for the platform overall
* **Low latency** - latency can be minimised by choosing a notary physically closer to the transacting parties * **Low latency** - latency can be minimised by choosing a notary cluster physically closer to the transacting parties
Changing notaries Changing notaries
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
Remember that a notary will only sign a transaction if it is the appointed notary of all of the transaction's input Remember that a notary cluster will only sign a transaction if it is the appointed notary cluster of all of the
states. However, there are cases in which we may need to change a state's appointed notary. These include: transaction's input states. However, there are cases in which we may need to change a state's appointed notary cluster.
These include:
* When a single transaction needs to consume several states that have different appointed notaries * When a single transaction needs to consume several states that have different appointed notary clusters
* When a node would prefer to use a different notary for a given transaction due to privacy or efficiency concerns * When a node would prefer to use a different notary cluster for a given transaction due to privacy or efficiency
concerns
Before these transactions can be created, the states must first be repointed to all have the same notary. This is Before these transactions can be created, the states must first all be repointed to the same notary cluster. This is
achieved using a special notary-change transaction that takes: achieved using a special notary-change transaction that takes:
* A single input state * A single input state
* An output state identical to the input state, except that the appointed notary has been changed * An output state identical to the input state, except that the appointed notary cluster has been changed
The input state's appointed notary will sign the transaction if it doesn't constitute a double-spend, at which point The input state's appointed notary cluster will sign the transaction if it doesn't constitute a double-spend, at which
a state will enter existence that has all the properties of the old state, but has a different appointed notary. point a state will enter existence that has all the properties of the old state, but has a different appointed notary
cluster.