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

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

Browse Source 
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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/source/index.rst
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. 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 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 than what presently exists on the market, tailor made for the needs of the financial industry. We are attempting to
time include networking, database or user interface code. 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: Read on to learn:

38
docs/source/roadmap.rst
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 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: Contracts API:
* Example implementations of more advanced use cases, possibly an interest rate swap. * Upgrades to the composability of contracts: demonstrate how states can require the presence of other states as a way
* Support for lifting transaction sub-graphs out of the global ledger and evolving them privately within a subgroup to mix in things like multi-signature requirements.
of users (helpful for privacy, scalability). * Demonstrate how states can be separated into two parts, the minimum necessary for conflict resolution (e.g. owner keys)
* An improved unit test DSL. 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 * Implement a sandbox and packaging system for contract logic. Contracts should be distributable through the network
layer: just something good enough to get us to the next stage of prototyping). layer.
* Dynamic loading and first-pass sandboxing of contract code. * Experiment with modifications to HotSpot to allow for safely killing threads (i.e. fixing the issues that make
* Simple test/admin user interface for performing various kinds of trades. Thread.stop() unsafe to use), and to measure and enforce runtime limits to handle runaway code.