Oracles + Relayers

Tier 2: The message-passing tier

In this tier, we have the services that read messages broadcasted over the protocol on the source chain and write them to the destination chain. These services contain both on-chain and are off-chain elements, and require payment via an on-chain FeeCollector.

Orb Labs provides a set of Oracles and Relayers which your application may choose to use--alternatively, you may choose to build your own, or to use one provided by another provider.

Each application/ message receiver (we'll come back to this in the next section) will select an oracle and a relayer. They will identify these actors by address when registering with the endpoint.

Oracles

Oracles monitor messages from the source chain, create a message proof and send the proofs to the destination chain. Relayers use this proof to retrieve and deliver the original message.

For applications using the Rukh library, an oracle may choose to incentivize Disputers by playing a "dispute game" (see Rukh Dispute Game), in which they write harmless but false proofs for disputers to flag for a reward.

Relayers

Relayers monitor messages from the source chain, and deliver them to the destination chain after the message proofs have been submitted by the oracle.

For these and other reasons, oracles and relayers need to be reliable, accurate and secure.

Components

There are two components to each oracle and each relayer

  1. A contract address providing fee estimates and collecting fees to pay the oracle and relayer

    • Must implement the FeeCollector interface

    • These addresses are referred to as the Oracle Fee Collector and Relayer Fee Collector

    • These two cannot be the same address but can use the same logic in both contracts

  2. Off-chain actors that are responsible for monitoring chains and creating proofs (oracle) / sending messages (relayer)

    • These actors will:

      • check to make sure fees have been collected by the Fee Collectors

      • deliver proofs/ messages to the receive module via the address selected in the app configs on the receive module

        • Only the address selected in the receive module's app configs are permitted to pass messages on behalf of an app

        • Because these do not need to implement any interfaces, they might be EOAs, smart contracts, multisigs, etc. Using smart contract(s) is the most flexible as one can have a multisig or other mechanism to make sure that the oracle is trust-minimized; for example, using validators from re-staking protocol

Be sure to pay a FeeCollector entity that corresponds to the selected sending actor, or funds may be lost without message delivery

Using a multisig on the receiving contracts is a big and relatively straight-forward security gain--consider using a leader-follower architecture where the leader would be responsible for packaging the data

  • Some number of followers verify the data

  • A leader gathers signatures from all followers who attest to the validity of the message

  • The leader submits the message proofs to the destination chain

For better security, the leader and followers should be run by independent entities; ideally one independent leader and at least two independent followers.

We will be open sourcing our implementations of an oracle and relayer soon. Reach out if you are interested in building an oracle or relayer or if you have any questions; our discord is the best place to get in touch with us!

Last updated