Docs: regen HTML

docs/build/html/_sources/index.txt

@@ -4,8 +4,17 @@ Welcome to the R3 prototyping repository!
 This documentation describes the first prototype of a possible future R3 shared ledger platform.
 
 The goal of this prototype is to explore fundamentally better designs for transactions, states and smart contract APIs
-than what presently exists on the market, tailor made for the needs of the financial industry. It does not at this
-time include networking, database or user interface code.
+than what presently exists on the market, tailor made for the needs of the financial industry. We are attempting to
+prove or disprove the following hypothesis:
+
+*The combination of*
+
+* *An upgraded state transition model*
+* *Industry standard, production quality virtual machines and languages*
+* *Limited data propagation*
+* *Conflict resolution without proof of work or blocks*
+
+*is sufficiently powerful to justify the creation of a new platform implementation.*
 
 Read on to learn:
 

docs/build/html/_sources/roadmap.txt

@@ -2,24 +2,36 @@ Roadmap
 =======
 
 The canonical place to learn about pending tasks is the `R3 JIRA <https://r3-cev.atlassian.net/>`_ site. This
-page gives some examples of tasks that we wish to explore in future milestones:
+page gives some examples of tasks that we wish to explore in future milestones as part of proving (or disproving)
+our core thesis
 
-M1 is this release.
+Data distribution and management:
 
-Milestone 2
------------
+* Introduce a pluggable network messaging backend with a mock implementation for testing, and an Apache Kafka based
+  implementation for bringing up first networking capability. Using Kafka as a message routing/storage layer is not
+  necessarily the final approach or suitable for P2P WAN messaging, but it should be a good next step for prototyping
+  and may even be a useful for internal deployments.
+* Flesh out the core code enough to have a server that downloads and verifies transactions as they are uploaded to the
+  cluster. At this stage all transactions are assumed to be public to the network (this will change later). Some basic
+  logging/JMX/monitoring dashboard should be present to see what the node is doing.
+* Experimentation with block-free conflict/double spend resolution using a voting pool of *observers* with lazy consensus.
+  Logic for rolling back losing transaction subgraphs when a conflict is resolved, reporting these events to observer
+  APIs and so on.
+* Support a pluggable storage layer for recording seen transactions and their validity states.
 
 Contracts API:
 
-* Example implementations of more advanced use cases, possibly an interest rate swap.
-* Support for lifting transaction sub-graphs out of the global ledger and evolving them privately within a subgroup
-  of users (helpful for privacy, scalability).
-* An improved unit test DSL.
+* Upgrades to the composability of contracts: demonstrate how states can require the presence of other states as a way
+  to mix in things like multi-signature requirements.
+* Demonstrate how states can be separated into two parts, the minimum necessary for conflict resolution (e.g. owner keys)
+  and a separated part that contains data useful for auditing and building confidence in the validity of a transaction
+  (e.g. amounts).
+* Explorations of improved time handling, and how best to express temporal logic in the contract API/DSL.
 
-Platform:
+JVM adaptations:
 
-* Storage of states to disk and initial support for network synchronisation (does not have to be the final network
-  layer: just something good enough to get us to the next stage of prototyping).
-* Dynamic loading and first-pass sandboxing of contract code.
-* Simple test/admin user interface for performing various kinds of trades.
+* Implement a sandbox and packaging system for contract logic. Contracts should be distributable through the network
+  layer.
+* Experiment with modifications to HotSpot to allow for safely killing threads (i.e. fixing the issues that make
+  Thread.stop() unsafe to use), and to measure and enforce runtime limits to handle runaway code.
 

docs/build/html/index.html

@@ -134,8 +134,16 @@
 <h1>Welcome to the R3 prototyping repository!<a class="headerlink" href="#welcome-to-the-r3-prototyping-repository" title="Permalink to this headline">¶</a></h1>
 <p>This documentation describes the first prototype of a possible future R3 shared ledger platform.</p>
 <p>The goal of this prototype is to explore fundamentally better designs for transactions, states and smart contract APIs
-than what presently exists on the market, tailor made for the needs of the financial industry. It does not at this
-time include networking, database or user interface code.</p>
+than what presently exists on the market, tailor made for the needs of the financial industry. We are attempting to
+prove or disprove the following hypothesis:</p>
+<p><em>The combination of</em></p>
+<ul class="simple">
+<li><em>An upgraded state transition model</em></li>
+<li><em>Industry standard, production quality virtual machines and languages</em></li>
+<li><em>Limited data propagation</em></li>
+<li><em>Conflict resolution without proof of work or blocks</em></li>
+</ul>
+<p><em>is sufficiently powerful to justify the creation of a new platform implementation.</em></p>
 <p>Read on to learn:</p>
 <div class="toctree-wrapper compound">
 <ul>
@@ -162,10 +170,7 @@ time include networking, database or user interface code.</p>
 <li class="toctree-l2"><a class="reference internal" href="tutorial.html#non-asset-oriented-based-smart-contracts">Non-asset-oriented based smart contracts</a></li>
 </ul>
 </li>
-<li class="toctree-l1"><a class="reference internal" href="roadmap.html">Roadmap</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="roadmap.html#milestone-2">Milestone 2</a></li>
-</ul>
-</li>
+<li class="toctree-l1"><a class="reference internal" href="roadmap.html">Roadmap</a></li>
 </ul>
 </div>
 </div>

docs/build/html/roadmap.html

@@ -85,10 +85,7 @@
 <li class="toctree-l1"><a class="reference internal" href="overview.html">Overview</a></li>
 <li class="toctree-l1"><a class="reference internal" href="getting-set-up.html">Getting set up</a></li>
 <li class="toctree-l1"><a class="reference internal" href="tutorial.html">Tutorial</a></li>
-<li class="toctree-l1 current"><a class="current reference internal" href="">Roadmap</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="#milestone-2">Milestone 2</a></li>
-</ul>
-</li>
+<li class="toctree-l1 current"><a class="current reference internal" href="">Roadmap</a></li>
 </ul>
 
             
@@ -136,25 +133,38 @@
   <div class="section" id="roadmap">
 <h1>Roadmap<a class="headerlink" href="#roadmap" title="Permalink to this headline">¶</a></h1>
 <p>The canonical place to learn about pending tasks is the <a class="reference external" href="https://r3-cev.atlassian.net/">R3 JIRA</a> site. This
-page gives some examples of tasks that we wish to explore in future milestones:</p>
-<p>M1 is this release.</p>
-<div class="section" id="milestone-2">
-<h2>Milestone 2<a class="headerlink" href="#milestone-2" title="Permalink to this headline">¶</a></h2>
+page gives some examples of tasks that we wish to explore in future milestones as part of proving (or disproving)
+our core thesis</p>
+<p>Data distribution and management:</p>
+<ul class="simple">
+<li>Introduce a pluggable network messaging backend with a mock implementation for testing, and an Apache Kafka based
+implementation for bringing up first networking capability. Using Kafka as a message routing/storage layer is not
+necessarily the final approach or suitable for P2P WAN messaging, but it should be a good next step for prototyping
+and may even be a useful for internal deployments.</li>
+<li>Flesh out the core code enough to have a server that downloads and verifies transactions as they are uploaded to the
+cluster. At this stage all transactions are assumed to be public to the network (this will change later). Some basic
+logging/JMX/monitoring dashboard should be present to see what the node is doing.</li>
+<li>Experimentation with block-free conflict/double spend resolution using a voting pool of <em>observers</em> with lazy consensus.
+Logic for rolling back losing transaction subgraphs when a conflict is resolved, reporting these events to observer
+APIs and so on.</li>
+<li>Support a pluggable storage layer for recording seen transactions and their validity states.</li>
+</ul>
 <p>Contracts API:</p>
 <ul class="simple">
-<li>Example implementations of more advanced use cases, possibly an interest rate swap.</li>
-<li>Support for lifting transaction sub-graphs out of the global ledger and evolving them privately within a subgroup
-of users (helpful for privacy, scalability).</li>
-<li>An improved unit test DSL.</li>
+<li>Upgrades to the composability of contracts: demonstrate how states can require the presence of other states as a way
+to mix in things like multi-signature requirements.</li>
+<li>Demonstrate how states can be separated into two parts, the minimum necessary for conflict resolution (e.g. owner keys)
+and a separated part that contains data useful for auditing and building confidence in the validity of a transaction
+(e.g. amounts).</li>
+<li>Explorations of improved time handling, and how best to express temporal logic in the contract API/DSL.</li>
 </ul>
-<p>Platform:</p>
+<p>JVM adaptations:</p>
 <ul class="simple">
-<li>Storage of states to disk and initial support for network synchronisation (does not have to be the final network
-layer: just something good enough to get us to the next stage of prototyping).</li>
-<li>Dynamic loading and first-pass sandboxing of contract code.</li>
-<li>Simple test/admin user interface for performing various kinds of trades.</li>
+<li>Implement a sandbox and packaging system for contract logic. Contracts should be distributable through the network
+layer.</li>
+<li>Experiment with modifications to HotSpot to allow for safely killing threads (i.e. fixing the issues that make
+Thread.stop() unsafe to use), and to measure and enforce runtime limits to handle runaway code.</li>
 </ul>
-</div>
 </div>