Greycore | Testnet
Enabling the Greycore on Testnet is the next step in RenVM’s decentralisation plan. This month, we sent out deployment instructions to the first Greycore members so that they can beginning deploying nodes on Testnet. By this time next month, RenVM testnet will be running on third-party nodes. Between now and then we will continue working with these members to ensure that their setups are secure, and we will engage in further attempts to break our own Testnet as it transitions into the hands of third parties. We will also put up an information page detailing the Greycore members, and their contributions to the RenVM ecosystem.
This month, the major focus has been on the security of RenVM. As we prepare for the network to begin running on third-party nodes, this becomes more and more pressing, as the ability to rapidly respond to bugs is dramatically diminished. There have also been a number of cross-chain hacks recently that highlight the importance of security more than ever before.
To this end, we spent the last month reviewing the code of other cross-chain solutions that have been successfully attacked recently — most notably THORchain. This allows us to not only assist these teams by helping to identify potential attacks against their systems/users, but it also helps us identify issues that could be relevant to RenVM itself. These days, reviewing RenVM is hard. Because we have spent so much time and focus building it, we know it too well. We are cursed with the burden of knowledge, and it is impossible to look at our code with fresh eyes. However, we are not familiar with other cross-chain code, and although these other solutions are obviously different, many of the potential attack surfaces are shared.
Towards the end of the month, we also committed the entire technical team to an internal hacking attempt. Every one of our developers spent the last week (and will spend the next week) attempting to break RenVM from the outside. This is the first time we have done such a large attack on our own system. It involves not only the developers that have an intimate knowledge of the core protocol, but also the developers that work on software that supports the core protocol. This means we have as many different eyes, different programming languages, and different tools pointed at our system in an attempt to find vulnerabilities.
Our efforts were rewarded, and we have discovered (and already patched) several security issues. Once we are confident that these are truly fixed, we will release a security report that discloses the issues we found, so that users can make informed decisions about the risks of using new technology.
Host-to-host Transactions | Testnet
Despite the amount of time we have been putting into improving the security of RenVM, we have still had time to deploy one of the most anticipated features of RenVM: host-to-host transactions. This feature is now operating on testnet, and once testing is complete, it will be deployed to Mainnet with a large suite of initial tokens supported (to be announced).
Right now, Ethereum, Solana, Avalanche, Fantom, and several other chains, are only able to receive cross-chain assets but are unable to send cross-chain assets. For example, you can send BTC from Bitcoin to Ethereum, but you cannot send ETH from Ethereum to Avalanche. Host-to-host transactions fix this and will enable users to send native assets (ETH, AVA, FTM, etc.) and tokens (ERC20s, ARC20s, BIP2s, etc.) between all chains.
Exciting things brewing
Host-to-host transactions are the last major feature on the roadmap for the core RenVM protocol and will allow for some exciting new use cases in and of itself, but it also opens the way to something bigger. With the core protocol complete, and decentralisation well underway, the core team will begin on a new roadmap for RenVM that expands its capabilities even further.
The core team is now investigating and designing some new use cases that would massively benefit from decentralised and autonomous private keys. These new use cases will guide the design and implementation of a generic “application layer” on top of RenVM that can be used to build new and exotic applications that can make use of decentralised and autonomous private keys for more than the transfer of assets between chains.
In fact, when you think from this angle, it becomes clear that the transfer of assets between chains is actually just verifying a specific kind of application that leverages decentralised and autonomous private keys. So many other things can be built, and we are now planning how to make them all possible on RenVM.
There is a big design space in front of us, bigger than ever before, and lots of opportunities to embed new use cases and economics into RenVM. But it is best to end on an exciting teaser.
Until next time,
Ren is an open protocol that enables the movement of value between blockchains.