Page Comparison

General

• Status of the networks and Releases
  • Main net nodes are running the Last Finalized State version 0.10.2
  • Current version running on Test net is 0.11.0.alpha-2.  Current test net info is at RChain public testnet information
  • During block merge testing, we discovered a need to change the per validator vault to be made a per deploy vault or something similar to that.
    

Sprint 90 in progress

Main Focus is to prepare for and make operational the Hard fork 1 on the main net to eliminate the slashed validator.
Continue Block merge work and improvements, resolve any identified bugs, harden the main net, improve performance.  Current PR list is at https://github.com/rchain/rchain/pulls .  

This last week, the team was working on block merge, preparing for integration with the hardware solution, and getting ready for hard fork 1.

Progress Overview

Proceeding further with block merge requires changes to the per validator vault to make it a per deploy vault/purse etc. We are currently finalizing the design for this. Actual code and test will take some time. We are potentially looking at this scenario:
1. First hard fork for balances and removing the slashed validator
2. Second hard fork for block merge - This is the fastest way to get block merge on the main net without holding it until the third hard fork. This includes the per deploy vault and the Tree depth being increased to 4.
3. Third hard fork with all other changes.  Third hard fork includes implementation of a lot of changes including the PoS contract changes, Soft fork process etc.  Design for soft fork process is complete and is being reviewed by the team.

Hard Fork 1

The team is now re-oriented to finish, test thoroughly, document and deploy hard fork 1, including coordination with the exchanges.

Current plan is to complete hard fork 1 in 10 days to 2 weeks (by July 11-14, 2021 as the target date, with July 18-21, 2021 as the backup dates). At the time of hard fork 1, Exchanges will be requested to temporarily halt all transactions for approximately 24 hrs as we start the new genesis.  We will coordinate with the exchanges to see if there is any preference for the dates. We want to provide at least a week for the community to review their wallet balances, audit and/or re-run the entire process for themselves. Please watch for announcements in the Discord member and development channels to see when the balances report is available, for your verification.

Hard Fork 1 tasks are listed at https://github.com/rchain/rchain/milestone/13 and https://github.com/rchain/rchain/milestone/13?closed=1

Next week, Tomislav will be presenting in full the process we are following for hard fork 1 and how the community can validate that process against main net data.

Hardware based performance improvements:

The hardware partner and our team have made significant progress in getting ready to validate the potential performance improvements from both ends. In particular, the hardware partner will have their code ready in a week or two. The Rchain team is completing our side of the code so that we can develop the performance metrics and compare among the Scala based RNode, the hardware solution and also potentially the Rust based performance numbers. This will be done in two stage - initially with simulated tuple space operations and then with the full node.

Hard Fork 2

Isaac is close to completing the design doc for Soft fork process and is working on proof of concept code for the same.

(4) Planning for Hard fork 2 - identifying all items/tasks necessary, analyzing impact and interactions, specifying and reviewing the designs etc.
Ongoing.  

The main identified categories for Hard Fork 2 items are
4.1 Hard Fork changes needed for performant leaderless block merge
4.2 PoS changes to eliminate slashing errors and other shard configuration changes
4.3 Safe Soft-fork process: an approach to create a safe process for soft forks, such that all changes need not go in as part of the hard fork.
4.4 Revvault.rho changes.
4.5 Replacing Protobufs with Cap'nProto - 
4.6 Bug fixes: The 'end of quarantine' bug we discussed last week, rewards calculation (dependent on BigInt) and other bugs needs to be fixed as part of hard fork 2 also.
4.7 Additional optimizations for performance - Significant progress here. Tomislav will discuss a 10x improvement opportunity with new history implementation.

All the above contract changes will be implemented in rholang v1.1 

(5) Implementing Hard fork 2 changes 
Isaac is working on improvements to the revvault.rho PR https://github.com/rchain/rchain/pull/3418
Significant progress on Safe Soft-fork process: An elegant initial design spec is agreed on and is being documented. Isaac will be working on proof of concept code for this.
No Change - Tomislav and Denis will be working closely on the replacement of protobufs with Cap'nProto. Quite a lot of work remains to be done in this area. Once completed, this may allow us to upgrade to Blake3 from Blake2 subject to the availability of high quality libraries.
No change at the moment - Further analysis of channels map issues revealed that the LMDB writes is the area that could use performance improvements. We will look into possible optimizations here.

(6) Full realization of performance improvements on the main net will require substantial hardware budget. We will be publishing the performance data at various number of node configurations. What is optimal to run on the main net given the transaction volumes will be determined. We're looking at how best to get to fast finalization as the main performance indicator, measured against per time, per cost, per power utilization etc.

-- END OF NEW UPDATES --

(6) Performance tests and performance improvements
Ongoing - no change this week. This section is left here for reference until we have updates.

VERY Preliminary performance numbers on the leaderful, 0.99 synchrony constraint (unoptimized) block merge version that will be eventually promoted to the main net:

7x to 10x improvement (currently 41 sec per block on the main net vs 4 to 6 secs per block with block merge) over what we see on the main net currently, with 5 nodes on testnet 2, with the 0.11.0.alpha-2 version.  

Numbers likely to change as we move to leaderless 0.67 synchrony constraint, remove channels map, vary the number of nodes, vary the number of blocks for tests, vary machine resources, vary network distribution etc.. 

(Hard Fork) TEST NET 2 ADVISORY:  To test the version of block merge with data changes that need a hard fork, we are creating a separate feature branch and a TEST NET 2 as the testbed for this feature branch. This content will be left here until we are close to Hard Fork 2 implementation on the main net. 

1. There will be no guarantees of data storage format compatibility on Test Net 2, as the data storage format changes are incrementally implemented. The anticipated changes are mostly storage level format changes visible only to node operators. We encourage the community to start using Test Net 2 in addition to the current test net, so that we can quickly identify and resolve any issues with the upcoming hard forks. All new development should be targeted to TEST NET 2 and all current code MUST BE tested against TEST NET 2 to ensure future compatibility. 
2. Network id for Testnet 2 is testnet20210604.

When we do hard fork 1 on the main net, we will be starting from an empty state, with REV balances only. On Test Net 2, this 'loosing the state' will be repeated multiple times.

Tech-Governance meetings on Thursdays 10 AM Eastern, 7 Am Pacific 

Mercury requirements and acceptance criteria

Details on the acceptance criteria: Mercury acceptance criteria

Please see the documentation at https://github.com/rchain/rchain/blob/dev/docs/features.md. 

Developer website

https://developer.rchain.coop