DA0-DA0 / dao-dao-ui

InterChain DAO tooling UI.

Home Page:https://daodao.zone

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Design and implement UI for IBC self relaying

0xekez opened this issue · comments

commented

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:

  1. Infinite loops over IBC that drain fee wallets.
  2. 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.
  3. 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:

  1. A transaction on Stargaze is submitted which conveys a user's intent to transfer a NFT to Juno.
  2. A transaction is submitted on Juno which executes the logic needed to receive the NFT.
  3. 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. :)

image

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.

download_mp3.php?FILE=2006-09-28_WED nice touch! 😹

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:

  • The wallet has a sub-wallet designated to relaying - where you don't need to accept each transaction. You just fill it with some coins and it does its thing in the background
  • You give the wallet a one-time OK to sign relaying transactions on your behalf - after that it just happens in the background
  • Just a million different ways that wallets can do this directly for us
  • If wallets are not an option: need a supers smooth step-by-step UI that really shows what is going on and why. This could be an OK stepping-stone while also working on wallet support. Best example I can come up with right now is probably Stride's step-by-step UX
commented

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:

  • The wallet has a sub-wallet designated to relaying - where you don't need to accept each transaction. You just fill it with some coins and it does its thing in the background

  • You give the wallet a one-time OK to sign relaying transactions on your behalf - after that it just happens in the background

  • Just a million different ways that wallets can do this directly for us

  • If wallets are not an option: need a supers smooth step-by-step UI that really shows what is going on and why. This could be an OK stepping-stone while also working on wallet support. Best example I can come up with right now is probably Stride's step-by-step UX

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.

commented

completed! we took the approach of funding a background wallet that performs the relaying, which refunds the user's wallet on success