Relayers
A relayer is an off-chain daemon responsible for relaying cross-chain messages from the source chain to the destination chain. In IBC, a user initiates a cross-chain process by submitting one transaction (sometimes two) on the source chain. Then, a relayer sees that the rest is done, including submitting transactions on the destination chain and paying gas for that.
Using relayers in cross-chain systems poses two issues:
Gas optimization on the target chain: Relayers don't directly interact with users, so they don’t know whether a user prefers to pay more gas for faster cross-chain completion or would prefer cost over timeliness. Therefore, relayers can't determine a gas level that suits the user’s context.
Persistent liveness of relayers: For interoperability protocols like IBC, although relayers don't need to be trusted (as they can't cheat), the protocol relies on their liveness. The operation of relayers should be out of something other than altruism in the long term, so incentivizing the work of relayers is necessary.
For example, IBC designed ICS29 to establish a permissionless relay market. However, providing token rewards for off-chain services’ “availability,” is always challenging because the service's contribution can’t not fully verified on-chain. On the other hand, an open, competitive relay market almost inevitably leads to a winner-takes-all outcome, wherein the winner gains the power to halt the bridge.
The ideal scenario would be for several independent relayers for each IBC connection to consistently compete to offer fast and affordable services. However, an incentive mechanism for this outcome is yet to come. Almost all relayers are operated by an entity closely related to the particular bridge team. Therefore, relayers are the most stubborn obstacle to realizing a completely decentralized cross-chain system.
Can the off-chain relayer role be eliminated in a cross-chain system?
Yes, it can. (This is addressed below.)
Last updated