Disputing Messages

Oracles, relayers, disputers and dispute resolvers

It is possible for oracles to write false proofs, and for relayers to send false messages. In the case of an app-sanctioned validator like Thunderbird (or many other cross-chain protocols in the wild), you must trust your oracle and relayer NOT to collude, sending false messages.

The ability to dispute messages and manage these disputes is what makes the Rukh library special from Thunderbird. Using message disputing, the Rukh library can provide the lightweight nature of an app-sanctioned validator like Thunderbird, without the risk vector of oracle-relayer collusion. The library provides deep configurability of the dispute management.

Key Terms

Disputers are off-chain entities that monitor the message proofs submitted by the oracles. As their name suggests, they dispute these message proofs if they believe they are false. They are compensated for right disputes and punished for wrong ones.

The Dispute Period refers to the number of blocks the receive module waits to allow disputers to submit disputes. Disputers can identify invalid message proofs almost instantly. The dispute period is not only about giving disputers time to determine the validity of a message proof, but rather to prevent malicious validators from censoring valid disputes. The application decides the length of the dispute period.

The Dispute Game is an incentive mechanism Earlybird uses to ensure disputer liveness and swift disputes.

An Epoch is a measure of time used in the dispute game conducted by the Rukh library’s receive module. It determines how disputers are compensated and whether an application’s oracle or dispute resolver has been compromised. The application decides the length of an epoch.

Dispute Resolvers are entities responsible for settling disputes. The configuration of the Rukh library determines the structure of an application’s dispute resolver. For example, an application can forgo the dispute resolver entirely and keep a permissioned list of disputers. It can use a light client if it wants a perfectly optimistic and trust-minimized system. Also it can choose something in the middle where its governance runs the dispute resolver. The choice is left to the application.

The Dispute Resolution Period refers to the number of additional blocks the receive module grants to the dispute resolver to change its verdict after it resolves a dispute. A message proof declared valid by a dispute resolver does not truly become valid until the dispute resolution period ends. Once the dispute resolution period ends, the dispute resolver cannot change its verdict. However, until then, it is allowed to change it as many times as it desires. Every time it changes its verdict, the timer for the dispute resolution period restarts. The application determines the dispute resolution period.

Last updated