Getting to the Greycore

RenVM Greycore Roadmap

Ren Community
Ren Protocol
Published in
6 min readMar 11, 2021

--

Without a doubt, the next biggest step for RenVM is the introduction of the Greycore. In this blog post, I want to give a bit of an overview of what the Greycore is, what features we have worked on in the lead-up to supporting the Greycore, and some more details about how we will be rolling it out.

Before reading further, make sure that you’ve read our previous blog post on this topic.

What is the Greycore?

The Greycore is the next step towards decentralization for RenVM. At the moment, consensus and execution in RenVM is the responsibility of Darknodes that are operated by the Ren core development team, and peer-to-peer networking is the responsibility of Darknodes that are operated by the community. The Greycore will be the first group of third-parties that takes responsibility for consensus and, later, execution. The Greycore will eventually be complemented by the community, which will eventually also assume control of consensus and execution in future releases.

For more information on the high-level structure, see our wiki.

What new features were developed in preparation?

Releasing RenVM to Mainnet taught us a lot about the network, how it was being used, what struggles users were experiencing, what features developers were missing, and what tools Darknode operators wanted to see. Since its release last year, the Ren core development team has focused on making upgrades to RenVM that we wanted to be in place before rolling out the Greycore. Here is a break down of some of the big ones:

  • Monitoring tools. This is important for understanding how the network is behaving, especially when almost 2,000 machines worldwide — outside our control — are helping to power the network.
  • Improved network stability. Over the last year, we have made improvements to the structure of Hyperdrive, allowing it to scale to more validators, recover from unexpected reboots more efficiently, and fix some bugs that were discovered. We have also made improvements to Airwave, to address some of the stability issues that became apparent after scaling to thousands of peers.
  • Lowering gas costs | As RenVM manages its locked assets, it incurs gas fees on the underlying chains, which are ultimately passed on to users. We put significant effort into optimizing RenVM so that these underlying gas fees were as low as possible, making RenVM as cheap as possible to use.
  • Better MPC libraries and frameworks | We improved (and open-sourced) our MPC libraries, optimizing them for correctness, auditability, but also performance. Since launch, our MPC implementations have improved substantially, running faster and smoother than before.
  • Robust storage drivers | Unexpected crashes are inevitable, so all systems must be designed to accommodate them. Over the last year, we have put a lot of attention into upgrading our storage drivers so that when RenVM crashes, it does not end up in an inconsistent/corrupt state, and that any recovery can be done automatically.
  • Added more assets and chains | This allowed the Ren core development team to learn about the intricacies of adding new assets and chains, which culminated in the development of the Multichain. This development made us confident that we could easily add new assets and chains, in a backward-compatible way, even when Darknodes are out of our control.
  • Forwards compatible | By far, the biggest effort has been in upgrading the transaction formats and block formats to ensure that RenVM will be forwards compatible with any new changes that we want to bring in the future. This is critical, because in a decentralized environment, change is hard, and forwards compatibility is essential for smooth upgrades.

It has been a long process and has taken longer than we initially anticipated. However, our latest version of RenVM — v0.4.0 — combines all of these learnings, and we have arrived at an implementation that we are very proud of. Everything we have worked on over the last year has directly contributed to ensuring that the Greycore rollout goes smoothly, and has the lowest chance of interrupting the network as possible.

Greycore Next Steps | How will it be rolled out?

We are currently upgrading Testnet to v0.4.0 and fixing issues that are discovered. Once these issues have all been fixed, we will hand control over to the Greycore. At this point, Testnet will be operated by the Greycore (and will continue to be, well into the future). This gives all members the opportunity to get familiar with the ins and outs of running a Darknode, keeping it up-to-date, recovering from unexpected events, and so on. It also gives the Ren core development team a chance to understand how to work effectively in a more decentralized environment. Lastly, this gives the Ren core development team a final chance to run extensive tests against a network that is no longer in our control. We will be able to hammer the network with mock transactions, attempt to break it, and develop any necessary processes/tools to help Greycore members.

While this is happening, the Ren core development team will upgrade the current version of Mainnet to be running this latest version (v0.4.0). This preliminary upgrade will make the next steps far simpler since we will use it as an opportunity to ensure that there are no backward compatibility issues before handing control to the Greycore. It is also necessary because v0.4.0 contains several features that make adding Greycore members a simple and easy process.

Once Testnet is stable, has been extensively tested, all members are happy with their setup, and the current Mainnet has been upgraded to v0.4.0, we will begin introducing new Greycore members to Mainnet.

To ensure that the Ren core development team can provide the maximum amount of support, we will be introducing Greycore members to Mainnet one at a time. This allows us to quickly and effectively recover from any unexpected issues, and to make sure that all members have the support they need.

In summary:

  1. Deploy the new Testnet that is running v0.4.0 and is powered by as many members of the Greycore as possible.
  2. Upgrade the existing Mainnet to be running v0.4.0 and address any backward compatibility issues.
  3. Add Greycore members to Mainnet one-by-one. We expect this will happen approximately 4 weeks after steps 1 and 2 have started.

By the end of this process, RenVM consensus will be powered by the Greycore. This will be the biggest step towards decentralization that the project has taken since its launch. You can keep up-to-date with progress on our live roadmap. *Please keep in mind, this is a living document, and all timelines are subject to change. These timelines reflect our best efforts to estimate progress, but ultimately it is impossible to predict timelines accurately.*

What happens after?

After this, the next step will be upgrading RenVM so that execution is also powered by the Greycore. This will go through a similar process, where we first launch on Testnet and then Mainnet, but we will not need to roll the upgrade to one Greycore member at a time. We will also have the majority of processes/tools developed, which means the upgrade will likely happen much faster than the initial one. At this point, RenVM will be declared to be at Phase 0, a huge milestone in our road to decentralization.

As before, you can keep up-to-date with progress on our live roadmap, but remember that all timelines are subject to change. We will always favor a slower, but more precise and less error-prone, development methodology over a faster, but more buggy, one.

With that said, we are excited to be moving forward with this progress and we hope this piece serves as a useful reaffirmation for the community. As always, if you have any questions, come join us on Telegram.

Until next time,
Loong, CTO

About Ren

Ren is an open protocol that enables the movement of value between blockchains.

Website | Docs | Telegram | Announcements | Twitter | Reddit | Github

--

--