As we grow and integrate more IBC protocols into DAO DAO we need good UX for self-relaying packets between two chains.
Most existing front ends that interact with IBC don't have UX for this and rely on benevolent, well-capitalized relayers. This model is broken as there is no way for these relayers to charge fees for relaying, making relayers vulnerable to DOS and other attacks which drain the relayers fee wallet. For example:
- Infinite loops over IBC that drain fee wallets.
- Transactions that error on the receiving chain, leaving the packets stuck in the sending chain's send queue. In the testing we've done, this will cause relayers to repeatedly try to commit the erroneous packet until it times out or their fee wallet is drained.
- Good old fashioned spamming of IBC channels.
TL;DR: relayers are ngmi.
How self relaying works
Say we're sending a Bad Kids NFT from Stargaze to Juno. To relay this packet, and any other IBC packet, there are three steps which are executed serially:
- A transaction on Stargaze is submitted which conveys a user's intent to transfer a NFT to Juno.
- A transaction is submitted on Juno which executes the logic needed to receive the NFT.
- A transaction is submitted on Stargaze which tells the sending-side bridge contract the result of the transfer.
Step (3) is needed so that the transfer may be rolled back in the event of the transfer erroring and serves to complete the IBC transfer.
The UX of self relaying
To self relay a packet, a user must have native tokens on both the sending and receiving chain to pay fees and submit transactions on both chains. To do the actual relaying the user will be prompted by their wallet three times, once for each of the above steps.
Any of the above steps may fail, though, in the face of a good protocol implementation, failure should only occur if the user is attempting something malicious or something wildly outside of gas limits. In the case of a failure, our best option is to tell a well-intentioned user to try again with a smaller message payload (ex: try sending fewer NFTs or shortening any text fields in the message).
Each step of this process may take upwards of six seconds, as the time taken is a function of the sending and receiving chain's block times. To encourage exploration, I'll be intentionally vague about what a good UI here would look like, though at the minimum it should in a pleasant way visually show each step to the user and explain what's happening if they would like to learn more.
Some visual inspiration. :)
The initial use for this will be relaying NFTs between chains using our ICS-721 implementation. We already have designs for selecting a NFT from a modal. We should likely reuse and improve those.
As we grow and integrate more IBC protocols into DAO DAO we need good UX for self-relaying packets between two chains.
Most existing front ends that interact with IBC don't have UX for this and rely on benevolent, well-capitalized relayers. This model is broken as there is no way for these relayers to charge fees for relaying, making relayers vulnerable to DOS and other attacks which drain the relayers fee wallet. For example:
TL;DR: relayers are ngmi.
How self relaying works
Say we're sending a Bad Kids NFT from Stargaze to Juno. To relay this packet, and any other IBC packet, there are three steps which are executed serially:
Step (3) is needed so that the transfer may be rolled back in the event of the transfer erroring and serves to complete the IBC transfer.
The UX of self relaying
To self relay a packet, a user must have native tokens on both the sending and receiving chain to pay fees and submit transactions on both chains. To do the actual relaying the user will be prompted by their wallet three times, once for each of the above steps.
Any of the above steps may fail, though, in the face of a good protocol implementation, failure should only occur if the user is attempting something malicious or something wildly outside of gas limits. In the case of a failure, our best option is to tell a well-intentioned user to try again with a smaller message payload (ex: try sending fewer NFTs or shortening any text fields in the message).
Each step of this process may take upwards of six seconds, as the time taken is a function of the sending and receiving chain's block times. To encourage exploration, I'll be intentionally vague about what a good UI here would look like, though at the minimum it should in a pleasant way visually show each step to the user and explain what's happening if they would like to learn more.
Some visual inspiration. :)
The initial use for this will be relaying NFTs between chains using our ICS-721 implementation. We already have designs for selecting a NFT from a modal. We should likely reuse and improve those.