Community Update 121

Owned by Rao Bhamidipati
Last updated: May 27, 2020

General

  • 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.
    • Testnet is running rchain/rnode-staging:v0.9.23-8-g0eb25aa24 - this 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 https://github.com/rchain/rchain/commits/feature/v0.9.23LTS

    • Mainnet observers and exchange nodes are running 0.9.24 .  Details at https://github.com/rchain/rchain/commits/v0.9.24

    • 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 53 in progress
    • Main Focus: Work on Last Finalized State, hardening the mainnet, improve performance, make usability improvements including configuration, API improvements for functionality needed by exchanges.
    • 0.9.23lts
    • Current Work In Progress 
      • One validator node slashed due to tuple space mismatch. We're not sure if this was caused by hardware failure or code. We do not see this in the other validator nodes. We're investigating. we're putting in place testing across multiple cloud providers, to identify earlier potential bugs caused by infrastructure differences. We have to put in place a strategy to handle such errors. This is a future ToDo.
      • BlockMerge design discussions are complete. The spec is being written up.  
      • Completed - Improvements to CI environment.  Github was earlier giving an error on some tests without detailed explanation. Through https://github.com/rchain/rchain/pull/2936  we adjusted different CI environment parameters to successfully complete the integration tests. One of the things we did was to decrease the JVM memory foot print.
      • Continuing work on Last Finalized State.  See https://github.com/rchain/rchain/pull/2935  (Dagstore implementation in LMDB) and https://github.com/rchain/rchain/pull/2934 (abstration over LMDB - Keyvalue store with manager, that RNode can use). We need to finish DAG Storage changes, specifically the migration logic  from current file storage.   The Keyvalue store that Tomislav demoed earlier is now being used for DAG storage.
      • Being tested in Testnet - Fixing an issue in grpc delays and connection time outs by enabling a grpc proxy on each node. This will also give us more information and logs about the traffic seen by each node, helping with debugging issues. 
      • Addressing discovered bugs: Investigating the 'tuple space error' that we occasionally see on the main net.
      • Ability to visualize vdag from any point for debugging purposes - https://github.com/rchain/rchain/pull/2927
      • Ongoing - Improvements to last finalized state initial draft PR issued https://github.com/rchain/rchain/pull/2913 and https://github.com/rchain/rchain/pull/2926 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 beginning to help 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 - Gurinder is adding diversity to the networks. We're adding IBM and potentially Oracle as cloud providers. This should reduce costs in addition.
      • We are slowly moving from Jira to Github for the development team, with appropriate ticket templates. Additionally, we're creating templates for the community to add different kinds of issues, bug reports, documentation improvement requests, security bugs etc.. Tomislav has a nice page for community to report these issues.
      • Continuing documentation work - Could use community help
      • Tuesday TeachOuts by Tomislav (Tuesday 10 AM Eastern) in Jimscarver's zoom room https://zoom.us/j/6853551826 
    • Current Backlog (partial)
      • Improve merging in system deploys
      • Improve Casper by enabling more tests and resolving identified code issues
      • Improve BlockMerge
      • 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
  • Tech-Governance meetings on Thursdays 10 AM Eastern, 7 Am Pacific 

Mercury requirements and acceptance criteria

Blockers to Mainnet

  • NA

Risks to code completion for Mercury

  •  

Developer website

Date