Community Update 123


  • Release
    • Node version 0.9.24 is the current release on observer nodes - Housekeeping changes and meeting requirements of exchanges for reporting state and transaction history RNode-0.9.24 release plan
    • RNode 0.9.24 changes impact only the observer/read only node. We've set up an 'exchanges only' read only node for exclusive use by the exchanges.
    • Dev team working on a Feature branch that has improvements to Last Finalized State, block store, dag store and now also beginning to store Casper state in LMDB. 0.9.25 will be released when we complete this feature branch and are able to merge that into the main dev branch. It has substantial improvements and some bug fixes to both observer/read only changes and validator nodes. Full current PR list at
    • Testnet is running rchain/rnode-staging:v0.9.23-8-g0eb25aa24this has a couple of patches beyond the 0.9.23
    • Mainnet validators are running RNode-0.9.23lts – this has a couple of patches beyond the 0.9.23.  Details at

    • Mainnet observers and exchange nodes are running 0.9.24 .  Details at

    • Sequence of updates is testnet to mainnet observers and then main net validators if applicable. Current philosophy is to minimize updates/disruptions to validator nodes while enabling improved observer node functionality.

    • Focus is to make sure that the network can handle the anticipated volume from the exchanges and that exchanges can have responsive monitoring and customer service.
  • Sprint 54 in progress
    • Main Focus: Work on Last Finalized State, hardening the mainnet, improve performance, make usability improvements including configuration, API improvements including functionality needed by exchanges.
    • Getting ready for 0.9.25 release possibly next week
      • All PRs merged into the release candidate, which is currently being tested
      • Currently testing. Tests will take a while because of the configuration changes - we need to set up each environment and migrate from old to new config, make sure there are no problems.
      • More insight on the tuple space mismatch - will be fixed in multiple iterations
      • Many other changes - full current PR list at
    • Current Work In Progress 
      • Slashing investigation: One validator node was slashed due to tuple space mismatch. First part of debugging revealed that the problem is manifesting when Trie is recalculated because of insert/delete of nodes when they are share common prefix. RCHAIN-4102 Getting issue details... STATUS We are fixing this issue but while it would certainly help reduce errors, it's not clear that this is the ONLY source of the problem. At this time this is a non-deterministic and rare error. It took 3 months to manifest and only in one of the ten main net nodes. We will continue to watch and analyze/debug it. We have to put in place a strategy to handle such errors. This is a future ToDo.
      • BlockMerge design spec is ready for review.  Discussions, reviews and improvements are in process. Please review and add any comments/concerns on the rchip issue.
      • Note that for us to release BlockMerge, we will have to do a somewhat significant refactoring of  RunTimeManager. So this will add to the effort needed. 
      • Continuing work on Last Finalized State. 
      • Addressing discovered bugs: Investigating the 'tuple space error' that we occasionally see on the main net.
      • Ongoing - Improvements to last finalized state issued but quite a bit of work involved still. Significant progress, some of which will be released in 0.9.25. The PR and the branch are structured so that multiple people can collaborate/ work on different parts of the feature at the same time. The scope of this work enables (a) faster catchup by new nodes - you can start from the last finalized state - this is a differentiator for RChain (b) offloading older data and differentiated storage and retrieval strategies for the same (c) allows for a leaner / less bloated node. Tomislav continuing to work and test this.  Nutzipper and Will are helping to accelerate delivery. Having to pick between refactoring and work-arounds in various parts. This change touches most parts of the code base. Trying to get a more modular and future-beneficial approach.
      • Ongoing SRE - Adding diversity of cloud providers. Sandbox with new configuration created on IBM. Testnet migration from Google to IBM planned. Exploring Oracle as another cloud provider (some credits and promise of low prices for 2 years). Main net validator nodes are still on Google cloud.
      • Validator expansion and Validator support:
        • Exploring methods of enabling easy scaling and decentralization of nodes. Couple of options are (a) one click install buttons for various clouds (b) run your own 'shard in a box' or 'node in a box' using low cost devices like Raspberry Pi based Antsle etc.
        • Looking at improving the communication channels for two way feedback and training of validators.
      • Ongoing - CI/CD:
        • We are slowly moving from Jira to Github for the development team, started working on release notes in Github.  For a while, we will maintain in both Jira and Github. Recent issue of test failing without errors on Github mostly resolved.
        • 0.9.25 release notes will be in Github - hopefully the community finds the format improved.
      • TechGovernance:
        • In the last meeting, we cleaned up the item numbering. They will move from issues+discussion to an RCHIP number once approved 
      • dApp Development:
        • We will start reporting on zulip backend and other dApp efforts, once we have more to report. Zulip meeting on Thursdays 3 PM Eastern, 12 Noon Pacific
        • Theo to demo functional cryptography based anonymous voting component next week, hopefully
      • Current Backlog (partial)
        • Improve merging in system deploys
        • Improve Casper by enabling more tests and resolving identified code issues
        • Improve BlockMerge including refactoring RunTimeManager
        • Improve multi-parent Casper enablement
        • Implement sharding capabilities
        • Improve logging to be able to learn what API calls are being used, so they can be related to resource use and performance etc
        • Rholang 1.1 to improve syntax and user experience / learning curve
      • Tuesday TeachOuts by Tomislav (Tuesday 10 AM Eastern) in Jimscarver's zoom room 

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

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


Risks to code completion for Mercury

Developer website