Modularizing work and rewards for relaying

[KaiserKarel]

Synopsis

We can reward proof-generators for Union by adding a module that accepts (height, proof) and verifies the ZK proof for that height, and if valid rewards the submitter. This makes the proof available for relayers to different networks.

Introduction

When relaying a transaction; the meaningful work done by an IBC relayer consists of proof generation (1) and light client updates (2). Both have considerable costs associated with them. Proof generation requires dedicated infrastructure to generate the proofs while updating light clients requires paying fees on counterparty chains when submitting the proofs. Rewards are only obtained when both (1) and (2) are completed.

(2) is inherently racy, meaning that a relayer may perform the work of (1), yet not get paid for it as another relayer has beaten them to the bunch. The system is also wasteful, as multiple parties may be completing (1) for height x, performing redundant work.

Infrastructure providers may be interested in specifically serving the union network, without running/connecting to non-union infra. They are interested in performing (1) and being rewarded for it, without performing (2).

Other infrastructure providers are keen to run IBC relayers but have no experience/access to high-performance computing, thus (2) is something they might want to do, but they need access to proofs generated by (1).

Rewarding Proof Generation

I propose a module that accepts a (height, proof) tuple and verifies the zkp. If it is valid, it stores the zkp and rewards the sender. This incentivizes proof generators to make their proofs publicly available, even if they are not relaying transactions, or if they are only relaying transactions to a subset of the counterparties (remember that union proofs can be used on all connected networks).

Implementation

We cannot expose a transaction that directly accepts the zkp, as that would be very frontrunnable (a validator would observe the zkp in the mempool, and submit it themselves, resulting in them not performing (1), but still receiving the reward for it).

We could solve this by adding a public input to the circuit, address, and reward the address that generated the zkp. This increases the cost of verification, however, since we pay for all public inputs.

Instead, I propose we use a pre-claim system, where a prover submits a transaction pre-claiming the reward for height x without submitting the proof. For this, they bond union tokens for the duration of the pre-claim, which are slashed if they do not submit a proof within n blocks. Now the sender of pre-claim is the only party capable of submitting the proof for height n, which ensures they receive the reward without being front-run.

For other proof generators, pre-claim is an indicator that someone is already performing (1), and thus they can skip doing the work and instead do other proving in the meantime.

This system is effectively a prover market, with the union network creating bids to generate specific proofs. Actual bidding is outside the scope of this proposal, but we could envision that later we allow multiple pre-claims and choose the lowest bid within a single block, before committing to a pre-claim.

Other Advantages

This system means that we already incentivize proving before IBC channels go live, and thus can have part of our infrastructure be live before the final product is functional.