Key Points

• Welcome to Part 2 of an editorial series by Ronin head researcher Phuc Thai! In this article, Phuc takes a deep dive into security processes on Ronin.
• Explore Ronin Evolution Proposals (REPs), Ronin’s testing process, shadowforks, security audits, and bug bounties.
• Ronin is an Ethereum-aligned blockchain forged for gaming. Share this article with any friends, developers, or gamers who might be interested in how Ronin works under the hood.

On January 7th, we published an article entitled Solving the Blockchain Trilemma. It was the first part of an editorial series by Ronin head researcher Phuc Thai. The article took a 10,000 foot view of Ronin’s security, scalability, and decentralization. Today, we’re sharing Part 2, which will zoom into one pillar: security.

Join Phuc Thai as he takes a deep dive into some of Ronin’s security measures. This article will cover Ronin Evolution Proposals (REPs), Ronin’s testing process, shadowforks, security audits, and bug bounties. Welcome back, Phuc Thai! Let’s begin:

Security on Ronin

Security. It’s the foundation of every blockchain – including Ronin. In cybersecurity, protection against threats requires on-going tests, audits, and consensus. The Ronin team puts each and every update through rigorous processes before deploying on mainnet. This keeps users safe, and Ronin running.

Ronin Evolution Proposals: a Deep Dive

In Part 1, I shared an overview of REPs along with a few examples. REPs are concise, technical documents that propose a specific change to the Ronin blockchain. We introduced them in May of 2023 to foster constructive feedback and ensure modifications to Ronin have community support. 

Today, I’d like to outline the stages each REP undergoes before being deployed. This is the standardized process that turns proposals into implementations:

• Stage 0: Idea – An idea is pre-draft. This is not tracked within the REPs Repository. Developers may discuss it with the Ronin community (on Discord) first before deciding to put more effort into it.
• Stage 1: Draft – The authors of the idea engage with the Ronin Core team. In turn, the Ronin Core team performs a comprehensive review before assigning the idea an REP number and merging it into the REP repository.
• Stage 2: Off-Chain Voting – Once the draft is ready, the author makes a public announcement to the Ronin community. If there is no immediate pushback, the off-chain voting process begins.
• Stage 3: Approval – The draft must receive less than 15% of rejection from validators to move into Stage 4.
• Stage 4: Final – The Ronin Core team puts the approved draft into a development phase. If the core team successfully implements and tests the idea, they consider it Final.
• Stage 5: On-chain Voting. The implementation of the REP has been deployed and an on-chain proposal is created.
• Stage 6: Execution – The on-chain proposal must be approved by more than 75% of the governing validators. Once successful, the implementation will take effect.

Here are a few exceptional statuses for REPs:

• Living – A special status for REPs that are designed to be continually updated and not reach a state of finality.
• Stagnant – An REP that has not been updated for more than 6 months will enter the Stagnant state.
• Withdrawn – An REP that is dropped and will not be implemented is considered Withdrawn. An REP that is deployed on-chain but was rejected is also considered Withdrawn.

It can take up to a few months between and REP’s proposal and launch.

The Sky Mavis Testing Process

Sky Mavis applies its own testing process for each and every update to Ronin without exception. Today, all upgrades must follow the steps below:

Step 1: Testing on the private devnet.

Step 2: Testing on the public Saigon testnet.

Step 3: Testing on the shadowfork of the Ronin mainnet.

Step 4: Deployment on the Ronin mainnet.

The testing process involves making an update LIVE on an alternative network without affecting the mainnet’s state. For example, the private Ronin devnet and public Saigon testnet are two separate chains with their own states. On the other hand, shadow forks copy the state and history of the Ronin mainnet using a distinct set of nodes. This facilitates the replay of transactions from the main network. Shadowforks also enable observation of node reactions to hard forks without disrupting the mainnet. This approach offers a more realistic testing environment compared to deploying on the testnet. The use of shadow forks for testing was embraced in Ethereum to evaluate hard forks after the Merge.

Shadow Forks on Ronin

In general, the Ronin mainnet is operated by a set of validators that are responsible for block creation and verification. To create a shadowfork, we develop a customized version of the Ronin consensus, wherein the original validator set is replaced with an alternative one. These alternative nodes running the customized version are referred to as shadow nodes.

It is crucial to note that nodes within the Ronin mainnet are programmed to reject all blocks originating from the shadowfork. This rejection occurs due to the inherent disparity between the versions being run, thereby safeguarding the integrity and consistency of the Ronin mainnet.

At a predetermined block, the shadow nodes transition to the hard fork. The blocks within the shadow fork encompass all transactions from the mainnet's blocks, as the shadow fork maintains an identical state and history. This ensures that all transactions can be processed seamlessly post the hard fork. Once testing is complete, the shadowfork can be deprecated.

Ronin Audits

Every update to Ronin undergoes a rigorous security auditing process conducted by the dedicated security team at Sky Mavis, consisting of over 10 well-trained security engineers. In addition to the internal scrutiny, external auditors often review and optimize Ronin’s codebase. This collaborative effort ensures a thorough evaluation of the blockchain's security measures and identifies potential vulnerabilities.

To further fortify the security posture, the Ronin team maintains a bug bounty program which offers rewards of up to $1,000,000 USD. This program encourages the broader community, including external security researchers and developers, to identify and report any potential security issues or vulnerabilities. The bug bounty initiative serves as an additional layer of defense, leveraging the collective expertise of the community to enhance the overall security resilience of the Ronin blockchain. This commitment to proactive security measures underscores our dedication to maintaining a robust and secure blockchain ecosystem.

Ecosystem Security

The Ronin team employs various strategies to strengthen the security of the Ronin ecosystem. To reduce risks associated with new dApps developed by partners, we subject them to an automated screening process. Additionally, we conduct manual reviews, particularly for contracts that are complex or involve the handling of user funds. These dApps receive a "verified tick" within the trusted domain system of the Ronin Wallet. This feature enables users to confidently interact with authentic applications. We also have alerts to promptly detect any unusual transactions, further enhancing security measures. 

As Ronin continues to evolve and become more accessible, we are committed to introducing additional security features. Stay tuned for further developments in this regard.

Final Thoughts

My first editorial in 2024 focused on the blockchain trilemma of Security, Decentralization, and Scalability. Today, we took a closer look into Security including Ronin REPs, testing processes, shadow forks, audits, and bug bounties. Next week’s editorial will focus more on Decentralization. Stay tuned!

Disclaimer: Please note that this content is presented or otherwise made available to you on an “as is” basis for general informational and educational purposes only, without representation or warranty of any kind. This content should not be construed or used as financial, legal, or other professional advice, nor is it intended to recommend the purchase or use of any specific product or service. You must seek your independent advice from appropriate professional advisors. Where this article is contributed by a third party, please note that those views expressed belong to the third party and do not necessarily reflect those of Sky Mavis. Please refer to our Terms of Service for more information.