From 79cbaf8adf6918ce848cc381e19c7a44fcce063f Mon Sep 17 00:00:00 2001 From: Joel Dudley Date: Mon, 30 Apr 2018 14:58:13 +0100 Subject: [PATCH] Makes it clear that notaries are clusters or 1+ nodes. --- docs/source/key-concepts-notaries.rst | 81 ++++++++++++++------------- 1 file changed, 42 insertions(+), 39 deletions(-) diff --git a/docs/source/key-concepts-notaries.rst b/docs/source/key-concepts-notaries.rst index 5408fae4b6..e92af20ed4 100644 --- a/docs/source/key-concepts-notaries.rst +++ b/docs/source/key-concepts-notaries.rst @@ -3,9 +3,9 @@ Notaries .. topic:: Summary - * *Notaries prevent "double-spends"* - * *Notaries may optionally also validate transactions* - * *A network can have several notaries, each running a different consensus algorithm* + * *Notary clusters prevent "double-spends"* + * *Notary clusters may optionally also validate transactions* + * *A network can have several notary clusters, each running a different consensus algorithm* Video ----- @@ -16,80 +16,83 @@ Video Overview -------- -A *notary* is a network service that provides **uniqueness consensus** by attesting that, for a given transaction, it -has not already signed other transactions that consumes any of the proposed transaction's input states. +A *notary cluster* is a network service that provides **uniqueness consensus** by attesting that, for a given +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 input states * 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 -cannot be sure that an equally valid, but conflicting, transaction will not be regarded as the "valid" attempt to spend -a given input state. However, after the notary's signature is obtained, we can be sure that the proposed -transaction's input states had not already been consumed by a prior transaction. Hence, notarisation is the point -of finality in the system. +In doing so, the notary cluster provides the point of finality in the system. Until the notary cluster's signature is +obtained, parties cannot be sure that an equally valid, but conflicting, transaction will not be regarded as the +"valid" attempt to spend a given input state. However, after the notary cluster's signature is obtained, we can be sure +that the proposed transaction's input states have not already been consumed by a prior transaction. Hence, notarisation +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 -of all the transaction's input states. +Every state has an appointed notary cluster, and a notary cluster will only notarise a transaction if it is the +appointed notary cluster of all the transaction's input states. 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. -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 -* **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 Validation ^^^^^^^^^^ -A notary service 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: +A notary cluster must also decide whether or not to provide **validity consensus** by validating each transaction +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 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 - 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 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 -the "denial of state" transaction, allowing the attack to be resolved off-ledger. +Additionally, Corda's permissioned network means that the notary cluster can store the identity of the party that +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 -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 ----------------- -Each Corda network can have multiple notaries, each potentially running a different consensus algorithm. This provides -several benefits: +Each Corda network can have multiple notary clusters, each potentially running a different consensus algorithm. This +provides several benefits: -* **Privacy** - we can have both validating and non-validating notary services on the same network, each running a - different algorithm. This allows nodes to choose the preferred notary on a per-transaction basis -* **Load balancing** - spreading the transaction load over multiple notaries allows higher transaction throughput for - the platform overall -* **Low latency** - latency can be minimised by choosing a notary physically closer to the transacting parties +* **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 cluster on a per-transaction basis +* **Load balancing** - spreading the transaction load over multiple notary clusters allows higher transaction + throughput for the platform overall +* **Low latency** - latency can be minimised by choosing a notary cluster physically closer to the transacting parties Changing notaries ^^^^^^^^^^^^^^^^^ -Remember that a notary will only sign a transaction if it is the appointed notary of all of the transaction's input -states. However, there are cases in which we may need to change a state's appointed notary. These include: +Remember that a notary cluster will only sign a transaction if it is the appointed notary cluster of all of the +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 node would prefer to use a different notary for a given transaction due to privacy or efficiency concerns +* 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 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: * 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 -a state will enter existence that has all the properties of the old state, but has a different appointed notary. \ No newline at end of file +The input state's appointed notary cluster will sign the transaction if it doesn't constitute a double-spend, at which +point a state will enter existence that has all the properties of the old state, but has a different appointed notary +cluster. \ No newline at end of file