Community Update 178
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
- We discovered a bug with the additional block merge test net meant to be available to the community. For now, it is available but not really usable by the community because it crashes after the first rev transfer.
Sprint 89 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.
Block merge progress
Block merge requires per block DAG view. When concurrent block processing is enabled in the network, local view of the validating node might be different then view of block creator (there might be more messages processed). Therefore to be able to validate blocks, Casper view should be reconstructed according to justifications of a block being validated. https://github.com/rchain/rchain/pull/3439
As part of this, we needed to migrate the Last Finalized Block from Last Finalized Store to Block Dag Store, so it can be part of Block Metadata. https://github.com/rchain/rchain/pull/3459
We will be releasing RNode version 0.11.0 with the above changes.
Hard Fork 1
Early last week, the team identified that to proceed with block merge work, they need to increase the depth parameter for the initialization of the TreeHashMap used to store P0S rewards. This necessitated that we release the Hard fork 1 first and then block merge. Accordingly, 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.
- 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.
- 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
| Date |
|---|