ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-18 20:47:57 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

TWP: Address final comments.

Browse Source
This commit is contained in:
Mike Hearn 2019-08-12 15:36:16 +01:00
parent da18eae303
commit 70c5d96de7
1 changed files with 16 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
docs/source/whitepaper/corda-technical-whitepaper.tex
View File

@ -655,10 +655,22 @@ There are a variety of uses for non-verified keys:
in the peer-to-peer network but still wish to have ultimate control over states. See~\cref{subsec:micronodes}. in the peer-to-peer network but still wish to have ultimate control over states. See~\cref{subsec:micronodes}.
\end{itemize} \end{itemize}
Moving signing authority out of the node must be done with care to ensure that a new balance of power is In the general case, the desire to move signing authority out of a node is to move from a model whereby an entity
actually achieved. It's easy to provision people or devices with keys, yet miss the fact that the overall system external to the node authorises the node to sign a transaction to a model where the individual (or external entity)
architecture still grants everyone the same set of powers as before. As keys must be carefully generated, backed up signs for themselves. This is often driven by the observation that, in situations where the authoriser and the node
and managed (representing cost), you should ensure keys are deployed only where they can justify that cost. operator are different entities, there is a power balance in favour of the operator, since the operator could in
fact sign anything they wanted. So moving signing authority out of the node is often driven by a desire to reset
this power balance and thus to reduce the ability of the node operator to subvert the interests of the authoriser.
It is important to note that there are subtle tradeoffs involved here. For example, if the node loses its ability
to sign some sets of transactions then the responsibility for careful generation, protection and management of the
keys with that power now resides with the external party; if the keys are lost then the node, by definition, cannot
step in to rescue you. Similarly, if the third party relies on the node to explain to them what a transaction means
or to attest to its validity (or that of its dependencies) then the node operator still retains all or nearly all
the same powers they had beforehand.
So Corda's design attempts to optimise for scenarios where moving keys out of nodes creates desirable new power
balances.
% TODO: Add a section discussing balance-of-powers analysis. % TODO: Add a section discussing balance-of-powers analysis.