From 1e686ca7f30063b39905185c305e11fcbc40b596 Mon Sep 17 00:00:00 2001 From: Mike Hearn Date: Mon, 8 Jul 2019 17:59:40 +0200 Subject: [PATCH] TWP: Create a top level section "the node", add some more explanations and move some other sections underneath it. --- .../whitepaper/corda-technical-whitepaper.tex | 30 +++++++++++++++++-- 1 file changed, 28 insertions(+), 2 deletions(-) diff --git a/docs/source/whitepaper/corda-technical-whitepaper.tex b/docs/source/whitepaper/corda-technical-whitepaper.tex index 171a225f37..beb2136a78 100644 --- a/docs/source/whitepaper/corda-technical-whitepaper.tex +++ b/docs/source/whitepaper/corda-technical-whitepaper.tex @@ -1337,7 +1337,33 @@ copies of the transaction. In normal operation the notary is not provided with t keys to the long term identity keys and thus does not know who is involved with the operation (assuming source IP address obfuscation would be implemented, see~\cref{subsec:privacy-upgrades}). -\section{The vault}\label{sec:vault} +\section{The node}\label{sec:node} + +Corda comes with an open source reference implementation of the node. A more advanced `Corda Enterprise' node is +available on a commercial basis from R3. The node acts as an application server which loads JARs containing +CorDapps and provides them with access to the peer-to-peer network, signing keys, a relational database that may +be used for any purpose, and a `vault' that stores states. Although the open source reference implementation is +a single server, more advanced nodes may be decomposed into multiple cooperating services. For example, the +commercial node from R3 offers a cryptographic firewall component that separates the node from the internet and +terminates/relays connections through the organisation's DMZ. The message queue broker plays an integral role +in connecting different services together in this kind of multi-component architecture. + +An occasional source of confusion is related to whether the open source nature of the node has any implications for +ledger integrity. It doesn't, because as with all DLT systems, Corda nodes cross check each other's transactions. +When executing well written applications a node owner cannot gain any advantage by corrupting their node's code or +state. A future version of Corda may provide a formal protocol specification, easing the task of creating +alternatives to the reference implementation. + +This guarantee does not presently extend to apps installed in a node attacking each other. The reference +implementation provides no inter-app isolation: it is assumed that (outside of contract logic) code executing in +the node was installed by the administrator and is trusted. Applications are granted access to the underlying +relational database and can thus read each others states directly. Nodes capable of sandboxing potentially +malicious flows and in-process services whilst still enabling application interop are a topic for future work. +The platform is built with a combination of JVM-level type security sandboxing and process isolation in mind; a +plausible candidate architecture is one in which flows are load balanced by the MQ broker between multiple flow +workers that can run on different machines and in different firewall zones. + +\subsection{The vault}\label{sec:vault} In any block chain based system most nodes have a wallet, or as we call it, a vault. @@ -1412,7 +1438,7 @@ annotated in other ways, for instance to customise its mapping to XML/JSON, or t constraints~\cite{BeanValidation}. These annotations won't affect the behaviour of the node directly but may be useful when working with states in surrounding software. -\section{Client RPC and reactive collections}\label{sec:client-rpc-and-reactive-collections} +\subsection{Client RPC and reactive collections}\label{sec:client-rpc-and-reactive-collections} Any realistic deployment of a distributed ledger faces the issue of integration with an existing ecosystem of surrounding tools and processes. Ideally, programs that interact with the node will be loosely coupled,