Community Update 174


  • Status of the networks and Releases
    • Main net nodes are running the Last Finalized State version 0.10.2
    • Test net now has 0.11.0.alpha-2 version.
    • TestNet 2 and an additional testnet for internal purposes of devs are running the latest changes, to measure performance, diagnose performance issues and understand performance with different configurations.
  • Completed migrating the main net nodes to the new infrastructure

Sprint 85 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 .  

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: 
The team is creating new tests and/or refactoring the existing tests for block merge.
They are also focused on understanding and improving the tests for safety oracle, fault tolerance etc. and making the necessary fixes in these areas
Refactoring of mergeability tests PR is complete
Fork choice tips fix is complete
Now that we have multiple feature branches, some changes need to be ported over the different branches and tested. That work is in progress.
We are running performance tests on this branch currently

(2) Block merge tasks that can be on the main net only after Hard fork 2
Some changes from the other branches need to be ported over to this branch.
After that, we will focus on running performance tests.

(3) Hard fork 1 for balances
The main reason for Hard fork 1 is that it is a preparatory step to Hard Fork 2 which has data changes. Specifically, it is to separate the balance activity from the other data changes we will be making, since balances are sensitive and need sufficient community review time. We also eliminate the slashed validator from the main net.
Tomislav will be presenting this work in detail today. 
Balances are generated from the blockchain and validated against balances reported by the transaction server
Will has made improvements to the transaction server and fixed some earlier bugs.
Will had generated the report at block height 804000
The team will generate another report closer to current block height, for public review. Community may verify one or both values at the two different block heights.
Tomislav is documenting the process we followed, so that the community can run through the steps and audit the process, the code and the results

(4) Planning for Hard fork 2 - identifying all items/tasks necessary, analyzing impact and interactions, specifying and reviewing the designs etc.
Ongoing.  As we work through block merge and the PoS changes, the team is discovering more and more items/changes that need to be included in the second hard fork. We are being mindful to not expand the scope too much because that would increase risk of introducing too many bugs and interactions. One approach being considered is to create a safe process for soft forks, such that all changes need not go in as part of the hard fork.

(5) Implementing Hard fork 2 changes 
Isaac has partially completed the revvault.rho work
Now logging in rev vault is mandatory and read only. Each rev vault transfer now has a unique id.
Successful transfers are now logged onto the block chain which allows easy additional analysis. Unsuccessful transfer attempts are recorded in the block.

(6) Performance tests and performance improvements
A significant effort is going into performance tests in various configurations. Details are explained verbally.
We will be working on optimizing cache clearing behavior

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

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

Developer website