Sprint 86 in progress
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 release candidate version is now available. Gurinder is currently testing it on the devnet. If there are no problems, we will update the testnet with this version shortly.
We discovered an 'end of quarantine period' bug on the testnet and had to restart the testnet from genesis. This bug seems to be dispersed in the code base (i.e. not quick to diagnose). This will not have any impact on the main net however, because quarantine end is quite far on the main net (at 1.4M block height vs. the 833504 block height currently). We will resolve this issue after completing the block merge effort.
The focus is now on thoroughly testing this block merge version for the main net. Some tests are refactored and some are enabled. The team is creating new tests as needed. Test net will be updated frequently over the next couple of weeks, before moving the release to the main net.
Fixes to safety oracle, fault tolerance etc. and the corresponding tests are complete and merged.
PRs merged in the last week can be seen here https://github.com/rchain/rchain/pulls?q=is%3Apr+is%3Aclosed
Tomislav slightly simplified the development environment setup and documented the same (mostly how to set up using nix).
(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
This work is mostly complete for now. There are a couple of PRs waiting for a second review, to be merged.
We are targeting end of July for Hard Fork 1 so that we have sufficient time for block merge version to stabilize on the current main net WITH CURRENT STATE INFORMATION before we remove the state for the hard fork 1.
The team will generate another report closer to the time of Hard Fork 1 on the main net, for public review.
(4) Planning for Hard fork 2 - identifying all items/tasks necessary, analyzing impact and interactions, specifying and reviewing the designs etc.
Ongoing.
The two main items needed here are PoS changes and an approach to create a safe process for soft forks, such that all changes need not go in as part of the hard fork. The 'end of quarantine' bug we discussed needs to be fixed as part of this also.
There are numerous other items needed to enable easier changes in future. We will be publishing a full list shortly, after block merge effort is complete.
(5) Implementing Hard fork 2 changes
Isaac has partially completed the revvault.rho work https://github.com/rchain/rchain/pull/3418
With this PR, 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
Ongoing
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.
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.
|