RenVM | The Road to Decentralisation

At the time of writing, RenVM has moved $350M+ in volume between chains, with $110M+ total value locked. This is a huge achievement, but it also makes it all the more important to understand the security of RenVM and the status of its progress towards decentralisation.

TL;DR

• Since the beginning, the plan has been to release RenVM incrementally, and slowly progress from centralised to decentralised. This follows the article published by a16z in January and allows RenVM to remain as secure as possible, even though it is a new and nascent technology.
• In this blog post you can find an overview of the different phases that RenVM will progress through, with a more detailed follow-up for the beginning phase.
• Our wiki also documents these different phases. Here, you will find some more information about what will happen during each phase, what this means for centralisation vs. decentralisation, and what it means for security.

Documentation

• September 2019 | Initial release plan: https://medium.com/renproject/renvm-mainnet-release-plan-761f1c2c0752
• March 2020 | More detailed release plan for phase sub-zero: https://medium.com/renproject/the-road-to-release-25d3feba56b2
• July 2020 | More details about the three release phases of RenVM as it moves from centralised to decentralised: https://github.com/renproject/ren/wiki/Phases

Today

The current state of RenVM.

Let’s talk about where RenVM is today on its path to full decentralisation. As per the release plan and the wiki documentation, RenVM was launched into phase sub-zero on 27th May 2020, at 11:00 AM GMT. During phase sub-zero, only one group of nodes is responsible for consensus and execution. We call this group the Greycore.

Right now, RenVM is in the early days of phase sub-zero, and so the Greycore is run by the Ren team. Over the course of phase sub-zero, as the team gains confidence in the correctness of the implementation, other members will be introduced to the Greycore. This includes groups such as Polychain, Infinite Capital, and Curve Finance.

In general, the wiki aims to be a live replacement for a static white/yellow paper. It is a place where you can keep up-to-date with the latest design of RenVM as it will be in its final phase. This is done so that the design can be understood, critiqued, and improved. The phasing section of the wiki discusses which parts of this design are enabled/disabled as RenVM matures. This allows us to keep all caveats in one place, where they can be easily consumed.

Safety and Decentralisation

Decentralisation does not equate to security.

In January 2020, a16z wrote about the challenges faced by teams when it comes to decentralisation, and some of the things that can be done to overcome these challenges. The core take away: do not start decentralised. Begin with a level of central control, and slowly progress to decentralisation as appropriate. Have a read of it here.

By following similar ideas, and progressing from centralisation to decentralisation as RenVM proves itself and the community familiarises itself with new transaction flows and best practices, we are able to keep users of RenVM as safe as possible:

• If an issue is found, the Ren team is able to quickly coordinate a fix to ensure that funds are not put at risk. This is difficult (and sometimes impossible) to do when a network is fully decentralised. This is critical, because all software has bugs. RenVM has undergone multiple audits, but audits can never catch all issues.
• If users/developers make mistakes when they use RenVM, the Ren team is able to help recover funds that have been lost through accidental mis-use. Everyone has stories of someone losing their funds in the blockchain space due to its complex and decentralised nature. RenVM is a new network, and comes with its own learning curve for users/developers. The team has already been able to help recover funds for both users and developers in this fashion. Without a level of control in the beginning, this is not possible.

We have seen many examples of projects launching and trying to be fully decentralised straight away, and then having to be shut down due to security issues that were missed. YAM is a recent example, and tBTC a slightly less recent example; both of these projects attempted to be as decentralised as possible from the start. YAM was unable to recover from its bug, and tBTC was quick to shutdown and instrumented a centralised emergency pause in their next iteration. It is incredibly lucky that the bugs found in these projects were not more severe. Had they been, more funds could have been lost, without any ability for the respective teams to respond or attempt to correct the issue. Decentralisation does not necessarily mean funds are secure. It is important and can add to security, but only once the underlying technology has been sufficiently battle-tested. Until then, it is a detriment to security, because it becomes difficult for communities to fix bugs in a fast and coordinated manner.

On the contrary, we have seen many projects, Compound is a recent example, that began with centralised control and then became decentralised when the protocol was ready. These projects are able to maintain a level of control over their platform in its early days, and then expand into decentralisation after the technology has proven itself in the wild.

Using MPC

What role does MPC play right now?

Interoperability protocols often work by locking assets into an address (spendable by one or more keys) and creating a tokenised representation of those locked assets on some other chain. In RenVM, these addresses are known as gateway addresses, and there is one per shard. For funds to be spent from a gateway address, two signatures are required: one from the shard itself, and one from the Greycore. Shards and the Greycore generate and manage the respective keys using an MPC algorithm, ensuring no single node ever has access to the key.

However, because RenVM is in the early days of phase sub-zero, there are currently no shards. This means that there is only one gateway address, and the Greycore is the only signatory required on that address (the Greycore still uses an MPC algorithm). This also means that the gateway address does not need to change regularly; changing the gateway address is only required when members of the Greycore (or shards) change. So, unless members of the Greycore are changed, or shards are enabled, rotation will not be observed. Note: this does not negatively impact security, because rotating the address has no impact if the nodes running the MPC algorithm have not changed.

Over the course of phase sub-zero, new members will be added to the Greycore. Every time this happens, it will be observed that the underlying gateway address changes. Furthermore, once shards are enabled in phase zero, there will be multiple gateway addresses (one per shard) that rotate regularly (every time shards are shuffled).

More information can be found in our release blogs and documentation:

• Initial release plan: https://medium.com/renproject/renvm-mainnet-release-plan-761f1c2c0752
• More details release plan for phase sub-zero: https://medium.com/renproject/the-road-to-release-25d3feba56b2
• Greycore information: https://github.com/renproject/ren/wiki/Greycore
• Shard information: https://github.com/renproject/ren/wiki/Shards
• Phasing information: https://github.com/renproject/ren/wiki/Phases

Security Practices

Although the Ren team currently runs all of the nodes in the Greycore, this will change over the course of phase sub-zero, and new members will be included. However, in the interim it is important to understand how these nodes are secured.

• There are 13x nodes in the Greycore.
• All nodes are in different randomly selected geographic locations around the world. These nodes are running across both AWS and Digital Ocean across three separate accounts.
• All nodes use an MPC algorithm to generate and secure the assets locked. That is to say, none of the nodes has access to the private key that locks the assets.
• All of the nodes are monitored by an automated alert system. If a node stops running for any reason, our team is immediately alerted (regardless of the time).
• All of the nodes are accessed using different access keys, have their root accounts disabled, and no one team member can access enough of the nodes to compromise the Greycore.

A malicious adversary would need to successfully compromise 5+ machines without being noticed. Even then, the adversary would not have root access to the machine, and would not be able to read that nodes’ shares of the MPC-generated private key.

Of course, until we progress further through phase sub-zero, the Ren team could collude internally. The team has obvious and strong incentives not to do so: we would be throwing away years of hard work and reputation, we would be legally pursued, have no way to spend the inevitably blacklisted assets, and we would lose all future value that can be captured by successfully progressing RenVM into its final autonomous design. Although the team is temporarily maintaining control over RenVM, we see this as a necessary step in the early days of the network to keep it maximally secure.

Hopefully this blog adds some clarity about RenVM, its progress through its release phases, and the security practices of the team. More than anyone, we look forward to stepping back and letting the community own the network in its entirety. But it is, and always has been, the plan to make decentralisation something that we progress towards, so that we can improve RenVM, and keep users as safe as possible. Every week we open-source more code, improve documentation, and see adoption increase.

Onwards and upwards,
— Loong, CTO

About Ren

Ren is an open protocol that enables the permissionless and private transfer of value between any blockchain.

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