mirror of
https://github.com/corda/corda.git
synced 2024-12-21 05:53:23 +00:00
Merged in docs-roadmap-welcome-page (pull request #6)
Docs roadmap welcome page
This commit is contained in:
commit
3573695553
@ -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:
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user