Community Update 165

Community Update 165

General

  • Release

    • Gurinder is updating all main net nodes (validators as well as observer nodes) to 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.

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

    • All test net nodes (validators as well as observer nodes) are running the Last Finalized State Version 0.10.2 https://github.com/rchain/rchain/releases/tag/v0.10.2 but in the process of being updated to the block merge alpha-1 version https://github.com/rchain/rchain/releases/tag/v0.11.0-alpha.1

    • We continue to work on improvements to the block merge version. here were some issues detected during the testing of block merge.  The team is resolving these.

    • Core development tasks can be tracked in this project Core team (github.com)

    • We're noticing a slower daily degradation in deploys per day on the main net - we are investigating this issue. Restarting the nodes alleviates the issue, we suspect some incomplete garbage collection or such.

    • 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 80 in progress

  •  

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

    • Current Work In Progress

      • Good progress on block merge

      • The first version of block merge v0.11.0-alpha 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.

The bulk of the block merge code is now complete and released as draft version v0.11.0.-alpha.1 https://github.com/rchain/rchain/releases/tag/v0.11.0-alpha.1 It will be running on the Testnet starting today.

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

Blockers to Mainnet

NA


Risks to code completion for Mercury

 

Developer website

https://developer.rchain.coop 

Date

Date

Mar 31, 2021