IBC delay middleware should delay all packets (also timeout and acks from the rollapp)

[omritoptix]

Currently the IBC delay middleware only delays transfer packet messages. The middleware should also delay acks and timeout and basically every packet type arriving from the rollapp.

[mtsitrin]

@omritoptix implementation wise, this requires different solution than the onRecvPacket
for Acknowledgement and Timeout there's no concept of delayed ack.

if the middleware return err=nil than the packet is handled regardless of the finalizition of the rollapp.

We should return err for non-finialized packets, which will cause the relayer to retry until eventually it will be handled

[omritoptix]

Problem I see with this is that assuming X days grace period, the relayer will have a potentially X days size of unacked and timeout messages which I’m not sure the consequences of besides having relayer log full of errors which stuck in a loop trying to ack X days worth of acks constantly.

I believe a more elegant option would be:

1. For AckPacket
   1. Return nil (But don’t execute the underlying OnAck logic)
   2. Save the Original ack packet with the relevant metadata
   3. If not fraud
      1. Upon finalization run the original ACK
   4. If fraud
      1. Run the ack Logic with AckErr (which in case of transfer should refund the funds to the original sender)
2. For TimeoutPacket
   1. Return nil (but don’t execute the underlying logic)
   2. Save the timeout packet with the relevant metadata
   3. If not fraud
      1. Run the timeout
   4. If fraud
      1. Run the timeout

• The reason we’re waiting with running the timeout only after grace-period/fraud is to prevent possible double spending where the sequencer sent a timeout but it actually credited the user with the funds on the rollappp which gives it a time until the rollapp is caught to exit using eIBC (with the assumption that the rollapp is caught at some point).

that’s why even though we eventually run the timeout, it's necessary to wait for grace-period/fraud to happen so at least assuming there is watch tower, the user won't be able to escape with the funds before.

[mtsitrin]

yeah it's the right solution, but requires forking the IBC
as the current implementation first runs the OnAck/OnTimeout logic

[omritoptix]

don't think its required. you can skip running the logic of the onAck and OnTimeout and run it after finalization (Similar to OnRecvPacket).
I'll open a PR so you can check it out.