The Perfect Balance of Gas Efficiency and Trust Minimization with Rukh

Rukh has the perfect balance of gas efficiency and trust minimization

The Rukh library merges different interoperability approaches to cover the weaknesses of others. As a hybrid interoperability system, it merges the app-sanctioned validator approach, the optimistic approach, and the consensus light-client approach, thereby creating an interoperability solution that perfectly balances usability and security.

Security

The Rukh library uses the optimistic approach for security and trust minimization. As with any optimistic systems, one honest disputer can prevent harm from befalling applications built on the library. In the Rukh library, the app-sanctioned validators no longer have full control over application security, and this significantly minimizes the need for trust. Oracles and relayers can behave maliciously, and incentivized disputers will quickly thwart their malicious deeds.

Similarly, the Rukh library allows applications to borrow from either the consensus light-client or app-sanctioned validator approach to address two of the optimistic approach’s security weaknesses: dispute resolution and disputer incentivization. With consensus light clients as the final source of truth, the Rukh library enables the perfect optimistic interoperability solution with permissionless disputes and trust-minimized dispute resolution. Furthermore, it finds a way to encourage those disputers to stick around and send disputes promptly, as is seen inRukh Dispute Game.

With an intermediate solution that relies on app-sanction validators for dispute resolution, the Rukh library still achieves something that few optimistic interoperability protocols have: permissionless disputers. Furthermore, it gives applications an arsenal of resources to protect against a malicious onslaught. Even if the oracle, relayer, and dispute resolvers get compromised and their keys get exposed, the delivery of invalid messages can be prevented since one honest dispute resolver can always change a bad ruling before the dispute resolution period ends. Most importantly, the Rukh library will realize that the dispute resolvers are malicious and halt message passing until the application tells it otherwise.

To illustrate the robustness of the app-sanctioned dispute resolution’s intermediary solution, suppose all the entities responsible for delivering messages to an application, i.e., the oracle, the relayer, and the dispute resolver, had their keys exposed to the world on Twitter. It would still be impossible to deliver invalid messages to the application provided there is one honest disputer and one honest party with access to the dispute resolver. These conditions are something that any application can ensure. Furthermore, it is easy to determine when an application fails to ensure these conditions by simply submitting bad disputes and seeing how long it takes them to resolve those disputes.

Usability

The common qualm people have with optimistic interoperability solutions is speed. However, optimistic solutions are not required to be slow. It is straightforward and fast for disputers to identify whether a message proof is valid or not. With proper incentives, the dispute time is not for disputers to identify invalid message proofs but rather to prevent malicious validators on a destination chain from censoring valid disputes.

Therefore, the amount of time the application should wait is not fixed. It is predicated on the message’s impact, i.e., the value transferred and the level of decentralization among the destination chain validators. Take, for example, a chain where one malicious party controls 50% of the network. It is important to note that few L1s have a single validator controlling 50% of the network. But for the sake of this thought experiment, let's assume this is the case. Let's suppose that block production is tied to the amount of the network a validator controls. Then for every block, this malicious validator has a 50% chance of censoring our disputes. Even in this case, a dispute has a 99.9% chance of successfully submitting a dispute after ten blocks. Ten blocks are less than 3 minutes on chains like Ethereum and less than a minute on most Tendermint chains.

Another way disputes are hindered is through network congestion. During periods of network congestion, the dispute game is quite helpful in improving speed. The game pays larger amounts to the fastest disputers, so you can imagine a world where disputers are incentivized to pay more network fees to make it into the chain. Due to the dispute game and use of permissioned relayers, applications can pick dispute periods lasting a few blocks and maintain a high degree of security. Nonetheless, the Rukh library allows applications to pick whatever dispute time makes them most comfortable. Applications can even customize that number based on the nature of the message they are delivering.

In addition to being fast and extensible, Rukh is also very gas-efficient. With the development of a comparatively gas-efficient consensus light client system, one may think that the value of libraries like Rukh diminishes. However, there are other reasons why a developer may still want to use the Rukh library. As mentioned previously, the Rukh library is the most balanced. It is over 15x-30x more gas efficient than the Caladrius library while offering an extremely high level of trust minimization. This makes it the perfect library for any application that needs high levels of both gas efficiency and trust minimization. This is most applications, including DEXs, token liquidity layers, lending protocols, yield farming protocols, etc.

Last updated