February Development Update
It has been another busy month for the Ren dev team, and we’re off to a fast-paced start to the year. Lots of development has been done on the core components, but we’ve also begun on some new tools and some new research. I want to hold off on discussing some of these new tools until next month when we will be able to show them off, but we’ll discuss some of them here. Let’s dive in.
RenBridge
This month, we released the latest version of RenBridge. This new version sports a fresh new look, support for DOGE, support for Binance Smart Chain, and some UX improvements. As you can tell, it has been quite the upgrade, so if you have not checked it out, head over to https://bridge.renproject.io and let us know what you think.
Over the next month, we will also be making RenBridge easier to fork. This will allow anyone in the community to deploy their own version of the UI, adding new/novel features of their own. This is an important step towards greater community involvement, allowing projects to host their own UIs for their assets, and provide greater decentralisation of the Ren ecosystem stack.
RenVM
This month, the team made more progress towards deploying the next version of RenVM — v0.4 — to testnet, which will allow third-parties to operate Greycore nodes for the first time. To this end, the team has continued writing unit tests and integration tests, finding and fixing bugs, fine-tuning configuration parameters, and reaching out to members of the Greycore.
This upcoming release will be one of the biggest so far, and warrants especially thorough testing, and documentation. To this end, we will be publishing another blog post in the next few weeks that goes into more details about this upcoming release, the steps necessary to get there, and how it fits into the broader plan to get to Phase Zero.
Lotan
Lotan has been mentioned a few times in the past; it is our monitoring framework for critical infrastructure and correctness testing. This month, we began upgrading Lotan to cover a broader range of checks, and to be compatible with the next version of RenVM. This is a critical step in moving the next version of RenVM to production because visibility into the behaviour and uptime of a live production release is necessary to ensure that any bugs are caught and fixed as quickly as possible.
One new feature of particular interest will be its ability to scan the entire network and report the status of any node, instead of just nodes run by the team. This will be particularly useful when the Greycore is released, as we will be able to easily monitor the uptime of all participants. It also opens the way to providing “opt-in” alerts for Darknode operators in the future.
Loki
One of the biggest challenges when deploying a new release to production is verifying correctness under different fault scenarios. What happens if there is a network partition? What about a failed database connection? Or an out-of-memory error? Faults in infrastructure happen non-deterministically and are hard to fake, and so often releases end up sitting in a “staging environment” for a long time to show that they can endure real-world conditions. But this takes time.
This month, the team began designing a new testing framework: Loki. This new testing framework is specifically designed to force the occurrence of faults (both Byzantine and classical) and measure the response of the network. This will dramatically decrease the time-to-production for new releases, and simultaneously improve confidence in the stability of a release, by giving the development team insight into how a release responds to various faults. The end result: faster release cycles.
Secure Enclaves
Secure enclaves allow users to run code in special hardware components that can restrict access to data and attest that a specific binary is being run. In a previous blog post about Asylo, we discussed the possibilities of using secure enclaves.
In the last month, we have successfully prototyped some simple Go applications running in secure enclaves using Asylo. These prototypes demonstrate basic, but important, functionality. For example, the ability to encrypt files such that only the Go application can access the data; even the person that owns the hardware cannot access it (or the decryption keys) in any way.
We also explored the use of Ego and Anjuna as other possible methods of using secure enclaves. With the former, we were able to run entire production-ready Go applications on Intel SGX hardware enclaves. Soon, we should be able to demonstrate a Darknode running on Intel SGX. This will make a significant step forward in securing RenVM even further.
The last month has been a mix of consolidation, testing, research, and the beginning of some exciting new tools. The dev team continues to work, heads down, as we get ready for the next major release of RenVM, and take the next step towards Phase Zero. Testing frameworks, monitoring tools, and secure enclaves are all part of this mission.
Reaching the next phase of decentralisation will be a big step for the project, and these foundational developments will allow us to do so in the most reliable, predictable, and safest way possible.
Until next time,
Loong
About Ren
Ren is an open protocol that enables the movement of value between blockchains.
Website | Docs | Telegram | Announcements | Twitter | Reddit | Github