Community Update 169

• Release

  • Most main net nodes are running the Last Finalized State version 0.10.2 https://github.com/rchain/rchain/releases/tag/v0.10.2  which contains the memory leak fix https://github.com/rchain/rchain/pull/3353 in addition to the PR to refactor rspace to use the  KeyValueStore https://github.com/rchain/rchain/pull/3295 and https://github.com/rchain/rchain/pull/3328 and some dependencies. This fix improves node startup speed and reduces the memory usage substantially.  We're running 0.11.0.alpha-2 version on one of the main net observer nodes.

  • Main net has 30 nodes, with a few large configuration machines running 5 nodes each. 

  • Test net now has 0.11.0.alpha-2 version running for a few days https://github.com/rchain/rchain/releases/tag/v0.11.0-alpha.2 that fixes the memory issue in 0.11.0.alpha-1. This should allow us to continue testing the block merge version that will go on to the main net.

  • In addition, we are setting up testnet 2 with the same 0.11.0.alpha-2 version for now, with the block merge enabled, to allow further testing and gathering of the performance numbers. Going forward, the version on testnet 2 will have all block merge code changes, including the ones requiring hard fork. Testnet 1 will get only the changes that can make it to the main net prior to hard fork.

  • Team is reviewing the final PRs for block merge version 0.11.0. When merged, we will have that release. This release, after testing is the block merge version targeted for the main net.

• We continue to work on improvements to the block merge version. Details are at Core team · GitHub

• Will is working on finishing up the work needed for the first hard fork (carry forward balances without prior state), as well as some of the block merge related issues such as rejected deploys.

• Note: Main difference between testing on Observer nodes vs. Validator nodes: When we test on the observer node, a large part of the code base is executed. The Block creation code runs only on the validator nodes. As a part of that, the portion of the Runtime Manager that plays the deploy is run on the validator node but not on the observer node.

Sprint 82 in progress

•  

  • Main Focus is to continue Block merge 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 .  

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

    • Gurinder to present more comprehensive preliminary data next week and then a few more times after that, as the team makes progress with completing block merge optimizations for the hard fork 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.. 

  • Will continues to work on and test the first hard fork for 'balances only' copy of the main net. The reporting program is currently running rather slow. He's working with Gurinder to troubleshoot this, including providing more resources to the machine running this.

  • Nutzipper and Tomislav continue to work on block merge improvements. Tomislav is also identifying additional items that can be included in the hard fork changes. 

  • Current Work In Progress

    • Good progress continuing on block merge improvements / enhancements. 

    • The main net version of block merge works with synchrony constraint 0.99. It was easier to do it this way to identify and analyze bugs and take corrective action. The focus here is to just make sure the algorithm is correct and works well. For now, we will simply kick out the unmerged deploys back to the user. In future, we will see if there is a better way to handle this.

    • Blockmerge version 0.11.0 is being prepared. (going through final PR reviews). This is the first block merge version targeted for the main net. 

    • This version contains the following PRs merged

      • https://github.com/rchain/rchain/pull/3341  Fix CI release with latest tag

      • https://github.com/rchain/rchain/pull/3338  Fix generation of bonds and wallets file

      • https://github.com/rchain/rchain/pull/3342  Migrate file-based block store to key value implementation

      • https://github.com/rchain/rchain/pull/3348  Update build.sbt with fixed Java version 11

      • https://github.com/rchain/rchain/pull/3353  Fix memory leak in RSpace

      • https://github.com/rchain/rchain/pull/3361  Validate content of genesis block against local content (bug)

      • https://github.com/rchain/rchain/pull/3363  Remove (legacy) file based block DAG store

      • https://github.com/rchain/rchain/pull/3365  Merge Dev into block merge branch

      • https://github.com/rchain/rchain/pull/3367  Disable channels map for single parent

      • https://github.com/rchain/rchain/pull/3374  Fix Sync version of Propose via API

      • https://github.com/rchain/rchain/pull/3377  Disable block index caching on single parent

As we have been emphasizing in the last three or so community debriefs, we discovered an unanticipated need to remove the channel mappings to get the full performance on block merge. This removal is a data structure change and will need a hard fork. For this reason, the full performance of block merge will not be visible on the main net until after we perform the data hard fork. There are also a few optimizations that need to be completed. Status of all block merge tasks can be seen at <https://github.com/rchain/rchain/projects/4> . We are approximately 2 to 3 weeks away from completing the remaining block merge enhancements. 

The block merge code that does not need the hard fork will continue to be tested on the current testnet and move on to the main net. The current testnet remains available for regular use by dApp developers and others, as normal.

TEST NET 2:  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.

1. We will generate from TEST NET 2 what the eventual block merge performance numbers may look like. To enable this, Will and Gurinder will be working on setting up a transaction server on Testnet 2, so that revdefine.io can report the statistics on this net also.

2. Once block merge tasks are complete, we will continue to work on other hard fork changes and test them on TEST NET 2 as well.

3. Additionally, we will start experimenting with decentralized nodes on TEST NET 2 when we are ready for that.
   
   

4. Through this whole duration, there will be no guarantees of data storage format compatibility on Test Net 2, as the data storage format changes are incrementally implemented. However, 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. 

The anticipated changes are mostly storage level format changes visible only to node operators. When we hard fork on the main net, we will be starting from an empty state, with REV balances only. On Test Net 2, this 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. 

Testnet status

Please see RChain public testnet information to learn more about public testnet as well as a FAQ.

Tech Governance + Community testing

Thursdays at 14:00 UTC. Please see RChain community RNode testing for more information.

NA

https://developer.rchain.coop