Rukh Best Practices

Trust-minimized setups for rukh library

Configuration: Perfect Optimistic Cross-Chain Messaging System

The best configuration is in terms of security and trust minimization is by relying on a consensus light client for dispute resolution. Typically, this would be impossible due to the high cost of consensus-light clients. However, this configuration is feasible due to the specially designed light client from the Caladrius in-depth (soon). We will touch on this efficient light client later on when we document Caladrius in-depth (soon). For now, let’s dig into the visual layout of the perfect optimistic cross-chain messaging system in Figure below.

In this configuration, we keep the oracle and relayer as app-sanctioned validators, we make the disputers contract open to anyone to dispute provided they stake some funds, and we make the dispute resolver open for anyone to call provided they can prove the message's existence in the light-client. This configuration is the most trust-minimized configuration of the Rukh library.

As you can see, it achieves what no other optimistic messaging protocol has achieved by having permissionless disputers and a trust-minimized and permissionless dispute resolution system. Furthermore, it has only three trust assumptions:

  1. The source chain remains uncompromised

  2. The destination chain remains uncompromised

  3. There exists one honest validator who is flagging invalid messages.

Every other configuration, and by extension, optimistic messaging protocol, has one or more additional trust assumptions to prevent liveness issues. This configuration fixes that problem without introducing an additional trust assumption.

Configuration: Permissionless Disputers and Permissioned Resolvers

Another equally efficient and trust-minimized configuration for the Rukh library is the one that relies on permissionless disputer contracts but with a small permissioned group of resolvers. Here is a visual representation of such a configuration:

With this configuration, even if an application’s oracle and relayer collude to pass a wrong message, some random disputer, looking for economic gain or protecting their application, will flag the message proof, thinking that it is simply playing the dispute game. This will stop the message from being delivered. The only way the message can be delivered is if there is a malicious dispute resolver that issues a verdict to dismiss the dispute, and no other dispute resolver alters the verdict during the dispute resolution period.

As you can see, all dispute resolvers cannot hide behind liveness. At least one of them was an active participant in the exploit. That said, the active participant can claim that they were exploited and their keys were used without permission. The other dispute resolvers, on the other hand, could hide behind liveness. We can reduce the likelihood of a liveness issue causing problems by customizing the dispute resolution period to be exceptionally long for messages that significantly impact the application. In this world, so long as we have one honest dispute resolver, they can verify that the dispute is valid, and the message won’t be delivered.

Furthermore, the Rukh library can be configured to halt if there is even one valid dispute. This means if the situation outlined above were to happen, Earlybird would stop delivering messages to the application until the application came and determined whether the valid dispute was due to a malicious oracle, a malicious dispute resolver, or both. If any of these parties are malicious, the application can change or remove them before telling Earlybird to restart message delivery.

Last updated