From 2f7da660c2889be3a51a42efba71921c232e14f8 Mon Sep 17 00:00:00 2001 From: Mike Hearn Date: Tue, 1 Dec 2015 14:05:08 +0000 Subject: [PATCH] Fill out roadmap doc page and state the core hypothesis that the prototype is exploring on the welcome page. --- docs/source/index.rst | 13 +++++++++++-- docs/source/roadmap.rst | 38 +++++++++++++++++++++++++------------- 2 files changed, 36 insertions(+), 15 deletions(-) diff --git a/docs/source/index.rst b/docs/source/index.rst index e3703e6bd6..dd0530246b 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -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: diff --git a/docs/source/roadmap.rst b/docs/source/roadmap.rst index 421c2651af..9a26720dcb 100644 --- a/docs/source/roadmap.rst +++ b/docs/source/roadmap.rst @@ -2,24 +2,36 @@ Roadmap ======= The canonical place to learn about pending tasks is the `R3 JIRA `_ 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.