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.