(deprecated) Mercury release plan
Note: This was the initial Mercury release plan. The timeline changed in Oct. 2018. features.md describes current planned features for Mercury.
Reference
Document status | Planning |
|---|---|
Release status | in development |
Related pages |
Milestones
Start date | Jan 1, 2018 |
|---|---|
Sprint 20 | Nov 5, 2018 |
Sprint 21 | Nov 19, 2018 |
Release | Mar 28, 2019 |
Development team
Development lead | Program manager | Project manager | Developer | Developer | DevOps | Page owner |
|---|---|---|---|---|---|---|
@Michael Stay (Unlicensed) | @Medha Parlikar (Unlicensed) | @Kelly Foster | @Michael Birch (Unlicensed) | @Kyle Butt | @Jeremy Busk | @Medha Parlikar (Unlicensed) |
Marketing team
Marketing lead | Evangelist | Content owner |
|---|---|---|
@Patrick Maguire | @mention | @mention |
Stakeholders
Name | Role | Reviewed? |
|---|---|---|
@Lucius Meredith | President, RChain Coop | |
@Nash Foster | CEO, Pyrofex |
Release summary
Simple overview
Technical overview
Epics for each Feature Set
Performance and Stability: Lead: TBD
The RChain network will have the capacity to process 40,000 COMM events / second across the entire network.
A Validating node must be able to process an update without being slashed. The update process can include disconnecting from the network to apply the patch, and a restart of the node software.
The rate and speed by which a node processes transaction is bound by the resources of the physical machine, such as Memory, CPU, Disk and bandwidth. The node software should consume whatever resources are provided to it, and provide the best performance possible with those resources.
The node software releases physical resources that are not actively in use, particularly, RAM and CPU.
Retrieving data from the platform is at least as fast and reliable as sending transactions into the platform.
Node runs in any supported environment and performance varies based on the available CPU and RAM and uses available resources to achieve maximum throughput
Node stays up and stable barring hardware, network, or power failures.
Eliminate Test Net Faucet
With the launch of Main Net - no Faucet is supported.
Proof of Stake Casper Consensus: Lead: @Michael Birch (Unlicensed)
Demonstrate a Proof of Stake consensus protocol that forms the basis of an economically secure, immutable blockchain system.
The consensus protocol will support the inclusion of Read Only nodes, which can receive blocks, but may not propose any blocks.
The protocol will provide a measure of transaction safety that is separate from the current best practice of confirmations, and this measure is made available to the application developer so that end users can view the level of transaction safety for themselves.
A user need only send a transaction 1 time to a validating node. The system shall send an acknowledgement of receipt of a transaction, and, provided enough monies have been sent to fund execution, the system shall ensure that the transaction will be processed.