Community Update 104

General

  • Release
    • Node version 0.9.18 is the current release - public beta - that includes per validator vaults to improve mergeability RNode-0.9.18 release plan
    • Testnet is running rnode version 0.9.18 This is the public beta release.
    • Getting ready to release 0.9.19 with the following improvements: resolve known block mergeability conflicts in PoS.rho, web api, bug fixes including fixes for 'insufficient phlo' crashing the node.  

  • Sprint 44 in progress
    • Main focus is (a) further improvements to mergeability (b) feature cleanup, testing, hardening, security, bug fixing (c) Network safety and reliability (d) getting ready for exchanges and dApp developers
    • Mergeability
      • Refactor (modularize, decouple) PoS.rho proof of stake contract to minimize mergeability conflicts. There are three specific issues identified. The fixes are published in https://github.com/rchain/rchain/pull/2837  It's currently under review and will be merged after approvals.  We need to complete the logic to handle slashing correctly - this is being worked on in parallel to the reviews.
      • TreeHashMap being used to improve performance in Registry.rho as well as in the above mergeability solution.  The PR is at https://github.com/rchain/rchain/pull/2840  The registry was storing all its data in a single rholang map. This meant that every time anything got added to the registry, the whole thing would get read and then written back again. It also caused conflicts between any two blocks in which something was added to the registry. This PR modifies the registry to use TreeHashMap, which mitigates these problems.  In addition, the pending rewards are now stored in this TreeHashMap. Because this part of the state must be modified in each block by every validator, having a tree helps a lot in reducing the conflicts.  
      • Improvements to Tuple space merging in Rspace RNode feature gaps. Likely to be released in 0.9.19 - PR getting ready to be published - 
      • Working on an error handling framework to correctly handle replay errors / mismatches.
    • Hardening
    • Casper and block storage
    • dApp developer tools and documentation. 
    • Performance improvements
    • Refactoring, Optimizations and bug fixes, hardening - ongoing 


Mercury requirements and acceptance criteria

Blockers to testnet-3

  • TBD

Risks to code completion for Mercury

  • Evaluating backlog vs current velocity 

Developer website

Date