Validators Can Receive ICS-29 Fees Instead of Relayers

[srdtrk]

Summary of Bug

When the fee middleware is activated, and all validators are rational, an unexpected behavior can occur where all ICS-29 fees are allocated to the validators rather than the relayers.

This issue arises because a validator proposing the next block can replicate and front-run all the MsgRecvPacket, MsgTimeout, and MsgAcknowledgement messages that any relayer may submit. As a result, all the ICS-29 fees are directed to the proposing validator without performing the corresponding work.

Expected Behaviour

The intended behavior is for the wallet running relayer software, which initially submits the MsgRecvPacket, MsgTimeout, or MsgAcknowledgement, to receive the ICS-29 fee. This fee acts as compensation for the relayer's efforts.

Version

This issue affects all ibc-go versions that include the fee middleware.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[ValarDragon]

(Copying my replies from a slack thread)

I agree this is a problem. I classify it in general as "arbitrage stealing"
I don't think this is a problem worth solving today.

Why? Because:

• It will be discoverable and social mechanisms will handle it
• Iterated game theory makes the base not so bad
• Censorship resistance solutions also fix this "for free".
• Economic value here is low that I doubt we will get meaningful proposer thievery in 2024.

When we move to zkp's of things, we can easily start having the proofs "tagged" for the submitting relayer address to prevent this.

The "rational acting block proposer" logic is a bit flawed (its how a lot of early MEV thinking went) for the following reasons:

• It assumes relayers and proposers are unable to coordinate/communicate
• It does not take into account iterated games

Lets still ignore off-chain relayer/proposer collusion. (Even though it is the end state of such a market with no protocol changes)
Even then, the iterated game theory of this will not lead to all proposers stealing all IBC relays

why? Because then the profit for stealing goes to 0.
Theres a classic game theory argument then (if there were only 2 parties), that says that suppose the minimum relayer R is willing to send a packet for, is payment P. Tip is T.
We'll reach an equilibrium where Miner takes T - (P + epsilon), Relayer gets P + epsilon

(Imagine this as either probabilistic thievery, or kickbacks from proposer to relayers every so often)

I think the multi-validator-ness will make this play out a bit differently then the classic 2 party game theory result (Supposing profit will be vastly higher than it will really be. Cumulative profit per chain here across all proposers is going to be like 100k/year tops in 2024, so realistically its not worth software development time for proposers)

When some proposers start this attack, you'd get relayers defensively keeping the info private if next block is by that proposer. (As the proposer schedule is deterministic)

[srdtrk]

Thank you for your thoughtful response, @ValarDragon. I understand the reasons you've laid out for considering this issue as not immediately pressing. Social mechanisms are indeed in place to prevent such behaviour in most chains, and I acknowledge their value. However, it's worth noting that these mechanisms and iterated game theory are not bulletproof.

So I'd like to address a couple of points:

1. Iterated Game Theory: While I appreciate the game-theoretical perspective, it's based on a set of assumptions that might not hold universally. It assumes a degree of rationality and cooperation that might not always exist among relayers and validators.

2. Tip Equilibrium: I'm skeptical of the equilibrium scenario you've described. In the existing system, the miner doesn't have the luxury of taking a part of the tip; it's an all-or-nothing situation, which undermines the potential for a balanced game theory outcome.

3. Proposer Schedule: If relayers start to withhold information based on the proposer schedule, it inherently impacts the efficiency and speed of the IBC. This seems counter-intuitive, especially since one of the goals of fee middleware is to expedite these processes, not slow them down.

While it might not be a top priority right now, this issue still represents a potential bug that could have broader ramifications as the ecosystem evolves. Perhaps we could consider some intermediate solutions that don't require an immediate, full-scale overhaul but would still mitigate some of the risks?

[womensrights]

Although this is a valid issue, if we assume that tips from fee middleware will be similar to the amount paid in fees, for the Cosmos Hub this would be around $3k / month and for Osmosis around $1k / month (ref). As to whether we do see validators taking fees for packets they did not relay, or the game theory model plays out and validators don't do this for fee middleware users, the amount at stake is still very small.

The solutions to this problem should be around preventing this form of MEV and these solutions should be lower down in the stack and seem a bit beyond the scope of ibc-go - e.g. threshold decryption or using zkps. We considered an allow list to only enable certain relayer addresses to receive the incentives, but the this doesn't really solve the core of the problem and creates a privileged position for certain relayers. It would also result in some overhead for an authority managing this list and an end user would only care about their packets being delivered, not who ends up getting the fee.

Therefore, as Serdar tagged, we will put this issue on hold for now.

[ValarDragon]

I generally agree that this isn't the area of concern of IBC-go. (Though we should request ZKP-based client proofs to add in tagging mechanisms imo, its a pretty cheap win)

I also don't agree with the proposer schedule being a long term problem here. Already in progress plans decentralize block production,

• Using vote extensions to have more validators include txs than just the proposer per block
• Bullshark consensus algorithms (I imagine all TM chains switching to Bullshark at some timescale)