Main net has 30 nodes, with a few large configuration machines running 5 nodes each.
We're noticing a slower daily degradation in deploys per day on the main net - we are investigating this issue. Restarting the nodes alleviates the issue, we suspect some incomplete garbage collection or such.
Main difference between testing on Observer nodes vs. Validator nodes: When we test on the observer node, a large part of the code base is executed. The Block creation code runs only on the validator nodes. As a part of that, the portion of the Runtime Manager that plays the deploy is run on the validator node but not on the observer node.
Sprint 78 in progress
Main Focus is to continue Block merge work, resolve any identified bugs, update dependencies, harden the main net, improve performance. Current PR list is at https://github.com/rchain/rchain/pulls .
Current Work In Progress
Good progress on block merge -Getting ready to get block merge on the testnet. Nutzipper demonstrated working block merge last week. Team is working on near term optimizations including indices, caches etc. Nutzipper has added more spans to understand performance issues and is working on resolving test failures and clean up. Will is beginning work on fixing channel hashes. Once all of this is done, we will be able to release block merge to the test net and measure the degree of horizontal scaling - i.e. Does the network throughput increase as we add nodes to the network and by how much?
There's a lot more work to be done in making block merge operational for the main net (a) to increase the number of non-conflicting cases identified and resolved, (b) optimizations, as well as (c) identifying and resolving any bugs discovered in the earlier code - Casper etc. There will be further testing, optimization, fixing bugs and creating necessary enhancements after that.
SRE : Gurinder has been working to consolidate machines, to bring the budget below the allocated amount. He is still analyzing the slow degradation issue on the main net, which is causing weekly or more frequent restart of the main net.
Planning for a couple of hard forks after block-merge is on the main net: One fork is to clear the slashed validator node from the main net, update bonds file and carry over the balances from the current main net to the new fork. This will be looked at as a practice/trial run of a hard fork. Second fork is to correct some bugs and other configuration items. An initial partial list of issues to be addressed in this fork is at https://github.com/rchain/rchain/issues/3315 . This list is likely to grow. Together, these should prepare us for the POS update and external validators. The rholang v1.1 update of system contracts and enabling rholang v1.1 broadly will likely be separate events, even though it is currently on that list. Rholang v1.1 should be a soft fork however. The forking could have implications for data migration for for all apps, especially for data intensive ones like dAppy. Raphael confirmed in the last Tech Governance meeting (Thursday Feb 11, 2021) that dAppy can handle the data migration.
Rholang v1.1 (complete for now) : Joe has completed the implementation of the full source to source translation of the Rholang v1.1 syntax into current Rholang. He's resolving the last few review comments. He added tests and they're passing. The feature branch is at https://github.com/rchain/rchain/tree/feature/rholang-1.1 I encourage the community to test these releases early and often so that Joe gets the necessary testing feedback and we can move it towards deployment sooner than later. You can run a version of the node locally with this. dckc pointed out that this can be a neat developer tool meanwhile - i.e. write your contracts in rholang v1.1 to generate the rholang v1.0 code. rholang v1.1 is much more compact and is the future. So this should be practiced by the community and developers as much as possible.
Quite a lot of work needs to be done before we get Rholang v1.1 into production on the main net. We are currently planning the steps and will have some milestone updates after this planning process is complete. A fuzzer to substantially increase the testing and identify performance optimization areas is one of the immediate steps.
Rholang v1.1 spec is at https://drive.google.com/file/d/1FvPuiPm7ytGyklex_PEmVyJ8XgbTdIEg/view Most of these changes will need extensive testing when the system contracts etc. are re-written using the Rholang1.1 syntax. These changes will be in a separate feature branch and we will likely run a separate network eventually, to thoroughly test this implementation. We also need to create documentation to help end users verify their existing code and/or how to modify it to use the new syntax. The expectation is that the new syntax will make the learning curve a lot easier for people familiar with other languages. Separately, we need to update the IDE level tools to work with the new syntax. We will run much of this through the RCHIP and Tech Governance process.
Ongoing - Fix additional identified bugs
API and usability improvements focused on Developer adoption (no change this week) - in conjunction with the community
Tomislav is beginning to review the best practices, frameworks, widgets and code snippets being made available by other projects to make things easy for developers, so we can adopt those best practices for RChain. The platform-adoption channel is now open in pub-RChain Discord, to enable announcements and community feedback in this area.
Tobi has made a Rholang template available on codesandbox.io that allows one to execute rholang code on the RChain network in real time. codesandbox.io claim some 2 M monthly developer users and that 10 M apps have been developed on the platform. Tomislav had talked about enabling something similar on repl.it, which is a similar 'code and collaborate in the browser' platform.
We continue to consider partnerships for enterprise developers as well as engage with small developer teams that are already engaging in blockchain proposals and pilots.
In Process - Will has mostly completed the OpenAPI/Swagger documentation of the RNode API https://github.com/rchain/rchain/pull/3128 He's will try to resolve the reviewer comments after he's done with block merge work or as time permits. Familiarity with Swagger and the available swagger tools should make it easy for developers to use our API.
Future - Also in the thinking stage is an improvement to revdefine.io or elsewhere, a graph representation of payments / transfers on the network, with perhaps date+time and amount on the arcs.
Explanation for last finalized state (released in 0.10.0): 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, differentiated storage and retrieval strategies for the same (c) allows for a leaner / less bloated node. This change touches most parts of the code base. Having to pick between refactoring and work-arounds in various parts. Tomislav implemented a mostly modular and future-beneficial approach.
Developer and Researcher engagement and Hackathon
Greg, Steve Ross-Talbot and the Dev team will be participating in half-day workshops with some Process Algebra folks in UK on Feb 4 and Feb 11, 2021
Next hackathon tentatively scheduled for some time in March.
We need to make building the developer ecosystem an ongoing task, just like development. Ian, Steve Henley and team are actively reaching out to as many universities and groups as possible. Please promote the much improved hackathon page at https://rchain.coop/hackathon.html to all the groups you are part of.
Ongoing - We need to further increase and properly size the Problem Statements, brief sessions on tips and tricks during the hackathon, and office hours during the hackathon. We will keep adding to the problem statements.
Ongoing - Learning examples, links to and improvement of documentation. Dan (dckc) has substantially improved the Rholang learning resources. Current plan is to make https://rholang.github.io/ the hub of all learning materials. dckc has been making substantial improvements to the learning materials as well as the API tools. The community is requested to contribute to any or all of these.
Ongoing - We are slowly moving from Jira to Github for the development team, started publishing release notes in Github with release 0.9.25. New issues are entered only in github. For a while, we will maintain in both Jira and Github. Looking to open up Github discussions and project management in the next few months.
Thursday 10 AM Eastern. Meets alternate weeks. Last meeting focused on how to implement and manage shard configuration. Meeting notes are at https://docs.google.com/document/d/1fvxMC6Bt5XwbVaLzYPy6ZPB8KzJvASO2sKRC6ZCPwpI Discussions and work on a model of economics to ensure network security is proceeding. Most recent discussion was about ensuring some amount of stake beyond a 4 month window, spreading out stake over a longer time and how to incentivize that, while ensuring that everyone pays for network security.
ToDo - There were questions from the community regarding enabling privacy and zero knowledge proofs on the chain - this is in active discussion. Greg will create a position statement on this and likely discuss the current state of the art, use cases and potential approaches in an RCast session. Same with sharding and cross-chain operation.
In progress - Excel Model for 'economics of sustainable network security and decentralization' to enable community understanding of the inter-relationships and community conversation around these issues. Will be releasing the initial version soon. May have multiple releases.
Looking for developers to help make progress on the RChat effort using zulip. SRT and possibly Will to add 'Rchain to zulip' functionality. Invite any community members with the expertise to help in this.
Current Backlog (partial)
Improve merging in system deploys
Improve Casper by enabling more tests and resolving identified code issues
Improve multi-parent Casper enablement
Resolve slashing bugs, including additional refactoring of RunTimeManager
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
Operationalize Rholang 1.1 on the main net to improve syntax and user experience / learning curve