Creating the discussion to discuss CIP-12 to add relayer incentivisation middleware to Celestia which enables IBC packet delivery to be incentivised on a per packet basis to the relayer that delivers the packet.
Thank you @womensrights for sharing this CIP!
I’m curious, has ICS-29 been implemented on any chains yet? What would you say are the main reasons that it hasn’t gotten much adoption so far?
With the implementation of ICS-29, would it require the creation of new channels to use this feature, or can existing ones be used? Would channel upgradability fix this once it’s released?
There are currently 26 chains we are aware of who have fee middleware wired up in their chain binary, including Archway, Terra2, Crypto.com and Kyve, however there are no chains actively incentivising packet delivery just yet. Currently, you need to create a new channel to use ICS-29 and it seems that token fungibility has been more important for chains than incentivising relayers, which is very reasonable. Indeed as you mention, with channel upgradability which will be in ibc-go v8.1.0 you will not need to create a new channel to use the middleware and you can update an existing channel version.
+1 here
I’d also add that relayers continue to do the work for free, and until they stop, wallets and other frontend interfaces are not going to do the work to start encoding fees in their transfers.
As part of the Hermes IBC relayer team, we’ve been supportive of relayer fees and think it would be beneficial for Celestia to adopt it.
Here is my attempt at applying a more exhaustive security considerations framework to Relayer Incentivization Middleware (RIM).
Battle Tested
Chain | RIM |
---|---|
Cosmos Hub | No |
DYDX | No |
Noble | No |
Osmosis | No |
A more exhaustive list sourced from Numia data of chains that do have RIM enabled:
- cheqd/cheqd-node
- archway-network/archway
- cosmic-horizon/QWOYN
- CosmosContracts/juno
- EmpowerPlastic/empowerchain
- sge-network/sge
- ChihuahuaChain/chihuahua
- oraichain/orai
- KYVENetwork/chain
- comdex-official/comdex
- classic-terra/core
- desmos-labs/desmos
- lum-network/chain
- persistenceOne/persistenceCore
- crypto-org-chain/chain-main
- xpladev/xpla
- regen-network/regen-ledger
- notional-labs/dig
- rizon-world/rizon
- JackalLabs/canine-chain
- noislabs/noisd
- TERITORI/teritori-chain
- scrtlabs/SecretNetwork
- White-Whale-Defi-P…/migaloo-chain
- Team-Kujira/core
- crypto-org-chain/cronos
- nymtech/nyxd
- ixofoundation/ixo-blockchain
- Source-Protocol-Co…/source
- terra-money/core
- UnUniFi/chain
Blast radius
Based on CIP-12 it seems like a scenario could result in the inability for a relayer to collect fees:
In the event that the counterparty chain itself incorrectly sends the forward relayer address, this will cause relayers to not collect fees on source chain for relaying packets.
I’m wondering if there are other scenarios worth considering:
- Could RIM cause a chain halt?
- Could RIM result in a loss of user funds?
- Could RIM result in a loss of relayer funds?
- Could RIM degrade IBC channel performance or cause channel closures?
Audit history
RIM hasn’t been audited. A TLA+ spec for RIM exists at informalsystems/ics29-fee-tla.
Complexity
The RIM implementation is in the cosmos/ibc-go repo. It spans:
- 50 Go files for implementation + tests + types
- 24 Go files for implementation
- 3282 Go lines for implementation
Note: file / line count is an extremely crude proxy for complexity.
Demand
The specification is implemented as a middleware that is added to both ends of an IBC channel.
I infer this to mean that RIM can’t be used for an incentivized channel until both chains adopt RIM. Based on map of zones it looks like the top 5 IBC peers for Celestia based on total IBC volume are:
- Osmosis
- Neutron
- Stride
- Dymension Hub
- Injective
and a crude analysis of if they have RIM enabled:
Chain | RIM enabled |
---|---|
Osmosis | No |
Neutron | No |
Stride | No |
Dymension Hub | No |
Injective | ? (I can’t find source code) |
Conclusion
I’m in favor of adopting RIM but I don’t think it needs to occur in the Lemongrass hardfork.
If we delay adopting RIM until a subsequent hard-fork (TBD on when that is) we can use the interim time to fundraise an audit of RIM. Delaying Celestia’s adoption of RIM would allow more time for it to be used in production on other chains.