Community Update 176

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
    • An additional block merge test net is being worked on.   Gurinder is testing a few configurations to test for optimal disk i/o performance. It will be made available shortly running the block merge release candidate 1. It's anticipated that the state on this bm-testnet may be lost off and on, as we make updates. It should be available later today.

Sprint 87 in progress

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

Significant work is ongoing in the following streams simultaneously
(1) Leaderful block merge targeted for the current main net and Leaderless block merge changes that will get on the main net, even though may not become immediately operational: 

Most changes are now in the release candidate 1. A few more PRs are expected over the next week. So there will be another release candidate. Beyond that, the focus is on thoroughly testing this block merge version for the main net. This may include writing / fixing a few more tests.

PRs merged in the last week can be seen here https://github.com/rchain/rchain/pulls?q=is%3Apr+is%3Aclosed


(2) Block merge tasks that can be on the main net only after Hard fork 2
No new activity here but we will create a hard fork 2 test net for this branch after leaderful block merge is complete. This hf2-testnet will get updates as various parts of hard fork 2 changes are worked on. It's not intended for any testing that relies upon long running state.

(3) Hard fork 1 for balances
This work is mostly complete for now. Will is working on a PR to provide a transaction API for both user and system deploys https://github.com/rchain/rchain/pull/3433  This PR enables each node to provide transaction API services without having to go through the transaction server (which is the current situation).


(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. Tomislav is exploring a potential Scala implementation of revvault to validate its benefits. This may improve performance, enable easy merging of balances, enhance the hardware solution and make dapp development easy. Looks like the benefits of a Scala implementation outweigh the cost. But we will validate that first.
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.

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

There are numerous other items needed to enable easier changes in future. 
Some of the above may go through an RChip review and approval process.
As can be expected, we will have to allocate a massive amount of time to test all the above. 

(5) Implementing Hard fork 2 changes 
Isaac is working on improvements to the revvault.rho PR https://github.com/rchain/rchain/pull/3418
Isaac and Tomislav are outlining an approach to soft forks and creating a small pilot to see how it works.
Denis has submitted a preparatory PR towards Cap'nProto, to Add manual Rhotypes (https://github.com/rchain/rchain/pull/3437). This is under review. Tomislav and Denis will be working closely in this area. Quite a lot of work remains to be done in this area.
Removal of channels map work is mostly complete.

-- 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 

Date