Skip to content
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

ICS20: Question about onAcknowledgePacket #1035

Open
michwqy opened this issue Nov 13, 2023 · 1 comment
Open

ICS20: Question about onAcknowledgePacket #1035

michwqy opened this issue Nov 13, 2023 · 1 comment
Labels
app Application layer. question

Comments

@michwqy
Copy link
Contributor

michwqy commented Nov 13, 2023

I found that in ICS-20, when the acknowledgement is not successful, the tokens will be refunded.

function onAcknowledgePacket(
  packet: Packet,
  acknowledgement: bytes) {
  // if the transfer failed, refund the tokens
  if (!acknowledgement.success)
    refundTokens(packet)
}

But in implementation, when the acknowledgement error, the tokens will be refunded.

func (k Keeper) OnAcknowledgementPacket(ctx sdk.Context, packet channeltypes.Packet, data types.FungibleTokenPacketData, ack channeltypes.Acknowledgement) error {
	switch ack.Response.(type) {
	case *channeltypes.Acknowledgement_Error:
		return k.refundPacketToken(ctx, packet, data)
	default:
		// the acknowledgement succeeded on the receiving chain so nothing
		// needs to be executed and no error needs to be returned
		return nil
	}
}

I think there are some differences between the two.

As ICS-02, there may be a non-empty sentinel ABSENCE value used to provide absence proofs.

Since the verification method is designed to give complete control to client implementations, clients can support chains that do not provide absence proofs by verifying the existence of a non-empty sentinel ABSENCE value. Thus in these special cases, the proof provided will be an ICS-23 Existence proof, and the client will verify that the ABSENCE value is stored under the given path for the given height.

This means that before the receiver receives the packet and writes a success acknowledgement , there may be an ABSENCE value on the path where the acknowledgement will be stored. I think the relayer may be able to claim the existence of an ABSENCE value and provide corresponding proof. And this ABSENCE value is not a success acknowledgement, so it will trigger a refund.

This process may not be feasible in practical implementation. But I think at the protocol level, it should be clear that refunds will only be made when the acknowledgement fails. In addition to success and error receipts, there may be also a default ABSENCE value.

@crodriguezvega crodriguezvega added app Application layer. question labels Nov 20, 2023
@AdityaSripal
Copy link
Member

Hello, yes we should clarify this to explicity check for an acknowledgement error rather than it not being a specific successful acknowledgement.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
app Application layer. question
Projects
None yet
Development

No branches or pull requests

3 participants