-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Design and implement UI for IBC self relaying #885
Comments
|
Got sent here by @0xekez due to: https://twitter.com/GjermundGaraba/status/1635663788455211010?s=20 This issue is starting to seem very important to me! :) First thought: 3 transactions is just a no-go as far as UX goes. It's OK for advanced users, but we have to think of something smart to fix this. First idea that comes to mind is that interchain-wallets need some way to execute these transactions on behalf of the user. Just some random ideas:
|
I LOVE the idea of a background wallet that you fund, and then it takes care of everything. It can then refund the wallet once it's done with leftover funds. |
completed! we took the approach of funding a background wallet that performs the relaying, which refunds the user's wallet on success |
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.
The text was updated successfully, but these errors were encountered: