RenVM | The Road to Decentralisation

Loong
Loong
Aug 28, 2020 · 7 min read

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.

Documentation

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.

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:

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.

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

Ren Project

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