Community Update 74


  • Sprint and Release
    • Sprint started May 27. Priorities are:
      • Consensus team
        • Bug fixes in genesis ceremony and network joining
        • Building foundation for bonding and unbonding in Rholang
        • Development work for providing randomness to the validation protocol
        • Provide property based testing for the estimator
      • Node team
        • Resolve challenges connecting to a busy network with fairness property
        • Metrics improvements to support investigating consensus bugs
        • UX improvements and optimizations
      • Rholang team
        • Completion of work to bridge cost accounting with the wallet and proof of stake contract
        • Start work on multisig wallet
        • Bug fixes
      • RSpace team
        • Optimizations for new RSpace
        • Changes to address Rholang bloat in the tuplespace
    • Release
  • Mercury requirements and acceptance criteria
  • Testnet status
    • Testnet-1 is live. Our intention is to keep this functioning so the community can deploy rholang to this public testnet. Please see RChain public testnet information to learn more about public testnet as well as a FAQ.
  • Community testing
    • Thursdays at 14:00 UTC. Pending the outcome of testing in progress on the development testnet, we hope to demo running the RSong acquisition contract on the public testnet.


  • Changes coming in RNode v0.9.7 (week of June 10) that impact RNode users:
    • Completion of the migration to using secp256k1 keys  RCHAIN-3438 Getting issue details... STATUS
    • Completion of the use of the new proof-of-stake contract to support the RevVault and cost accounting  RCHAIN-3318 Getting issue details... STATUS
    • Completion of the changes in the name registry to make URI's for system contracts human-readable  RCHAIN-3449 Getting issue details... STATUS
  • Priority this week is week is to complete RCHAIN-3318 and move onto the new Rholang methods to support validator bonding, undbonding, and rewards.
  • As of yesterday we are complete on the plan for the validation protocol for the Mercury release. Work in progress to update Validator Incentives and Casper to reflect yesterday's conversation.
  • Review of some parts of the consensus protocol using TLA+ last week proved useful in finding fixes for two bugs and an opportunity for optimization. We may use TLA+ more to review more of the protocol.


  • RNode v0.9.6 introduces a change to the keygen feature. Users must now specify the algorithm, either secp256k1 or ed25519. For example, rnode keygen --algorithm ed25519
  • PR in for  RCHAIN-1608 Getting issue details... STATUS . This will be a change for RNode users in RNode v0.9.7.
  • Team added additional metrics to support investigating a number of issues that relate to the time between a validator's call to propose a new block and the creation and propagation of that block to the network.


  • Several PRs in review to support the completion of  RCHAIN-3135 Getting issue details... STATUS . Much of the work here has been to refactor and improve aspects of the project to support the use of cost accounting across the RevVault, Rholang interpreter, and proof-of-stake contract.
  • Completed work to deliver the on-chain deployer ID.  RCHAIN-3405 Getting issue details... STATUS . Next is work to make use of this in the RevVault.  RCHAIN-3424 Getting issue details... STATUS
  • Making headway on the investigation of two bugs observed in the Rholang interpreter and related to what should happen when there are errors or a contract runs out of phlo. The team reports part of the challenge is a cats-effect related issue in a Scala library and the need to work around this. The team did report the issue


  • The Renovated RSpace has been running in both the development and public testnets for almost a week. Community testers help reveal  RCHAIN-3450 Getting issue details... STATUS  and that fix is now in RNode v0.9.6. We will continue to test in the development testnet to help prioritize optimization work.
  • Work in progress to provide an alternate way of determining if a deployment is in a block. The current way is to call `show-block <block hash> and search the tuplespace. This is a poor user experience and we want to remove printing all of the tuplespace in a call to show-block. The change will support users using the new deploy ID to confirm it's presence in a block. More details in  RCHAIN-3456 Getting issue details... STATUS
  • Based on findings in Reduce bloat - RSpace (current) analysis, work in progress to change the algorithm used to calculate the history trie. Currently there is a calculation for every change and requirement to store all related data. The plan is to change the algorithm to calculate a list of changes and store only the final state of the trie with the changes applied.  RCHAIN-3415 Getting issue details... STATUS .


  • Work in progress to complete the work one of the hardening tests  RCHAIN-3381 Getting issue details... STATUS . Once done we will reuse most of this work to deliver two other planned hardening tests. This work is in

Developer website