Merged in docs-roadmap-welcome-page (pull request #6)

Docs roadmap welcome page
This commit is contained in:
Mike Hearn 2015-12-01 16:34:32 +00:00
commit 3573695553
2 changed files with 36 additions and 15 deletions

View File

@ -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:

View File

@ -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.