Path Unwinding

[AdityaSripal]

Currently the IBC fungible token transfer protocol (ICS-20) allows tokens to flow through the IBC network without restriction. A token may take several hops from its source chain before it lands on the final destination chain. We encode this path the token takes into its denomination so that it is not fungible with tokens that take different paths. This is critical because the security properties of two tokens taking two different paths through the IBC network are fundamentally different and thus the tokens cannot be viewed as equivalent at the protocol level.

While this property must hold for security purposes, it is inconvenient for users and applications since they may have tokens that originate on chainA living on chainB that they then wish to send to a chainC. If they send directly to chainC, the end application or user on chainC will not view it as equivalent to a token being sent directly from chainA. This is increasingly becoming a pain point as the network built around ICS-20 becomes more complex.

Currently the solution is to manually initiate a two-step process. Send the tokens back to the original chain, and then from there send to the desired destination.

This works for end users, and could be automated by front-ends to make the experience more seamless. However, it will not work for smart contracts or modules that wish to send non-native tokens to a new destination chain. These contracts could in theory already use ICA and send a series of messages asynchronously to achieve the same effect already, however that is a lot of orchestration and complexity for a simple and common use case.

One solution is to build an optional feature into the ICS-20 transfer message, which when given a non-native denom will "unwind" the path by sending the packet back to the original source while maintaining information about the final destination chain which the original chain can send the tokens to in the end.

This discussion exists to gather feedback on the proposed feature and also to address the concerns and edge cases that would come up from such a feature.

Here are the questions I think are unaddressed:

1. The Token transfer msg sender will need the channel ID for the destination chain on the original chain. E.g. If you wish to send ATOM from Osmosis to Juno, you need to input the channelID from Hub to Juno. This could be circumvented by a CNS on-chain at the origin chain, but this would have to exist on all chains.
2. Who will pay for all the packets. In the typical case, one transfer message yields one packet. However with path unwinding, one transfer message could result in an arbitrary number of packets. Its unclear who should pay for the block space and relayer work.
3. In a future where multiple denoms are sent per packet this becomes even more complicated since they may all take different paths.
4. How should we deal with cases where a transfer along the path fails? I believe this should atomically send tokens back to sender but this may be complicated.

related work: Thanks to @jackzampolin and the strangelove team for their work on the packet-forward-middleware. My proposal is similar but would atomically send tokens back if the second hop failed, and this would be implemented on all chains for the purposes of path-unwinding, rather than existing on a single chain as a router

[AdityaSripal]

cc: @dtribble @ValarDragon @colin-axner @crodriguezvega @ethanfrey

[ValarDragon]

Terminology:
Suppose:

• chains A, B, C exist
• token foo originating from chain A is on chain B.
• User wants to send some foo on chain B to chain C.

Then:

• Call chain B initiating chain
• chain A source chain
• chain C destination chain

(1) I think that clients + on-initiating chain registries suffice for most use cases

For a contract, I'd store the intermediate path somewhere on the initiating chain within the contract or perhaps in a go module or something. Its a nice optimization to allow filling in defaults in the initiating chain, but not at all needed / can be added layer / easily added by a custom module from initiating chain.

It would also be nice to later on make registries on various source chains, (that can then be governed by various mechanisms, e.g. protocol upgrades, gov proposals delegated to a group, CNS provided by another chain, etc), but also not a big deal, and can be added later/

(2) this is fair. As always with fees, I feel like this isn't v1 blocking personally =p

I see three options:

• Add an option for metadata + tokens to be attached for specifying fees
• Make an easy UX for using ICS 20 + ICA to create fee middleware packets on source chain
• Make an easy event system, for entities to out of band pay relayers for multi-hop packets

(3) oh great point, hadn't thought about this. From asking you, the goal is for atomic multi-denom to next chain, which does conflict with path unwinding. So I guess you can't have both path unwinding + multi-denom in the same packet, a packet can only choose one of the two, or one of the two is architected to being in another ICS

(4) Should definitely store metadata for bounded time lengtbs so that it can automatically send back along the chain.

[jackzampolin]

We've modified the packet forward middleware to be atomic and to send back to originating chain in the case of failure. It should satisfy the requirements above.

[hxrts]

I think the ultimate solution should allow a 3rd party, such as a relayer, to perform the unwind and pay on the users' behalf ie users can be entirely passive and have unwinding occur in the background so long as their channels support the feature.

[notbdu]

I'd prefer an approach where:

• No additional writes are necessary on intermediate chains.
• No actual unwinding is required.
• Less social consensus and more reliance on cryptography.

My proposal is to use a cryptographic identifier for a source chain rather than a global name registry to avoid unwinding of packet denoms.

To summarize the technical issues:

• tokens are bound to a path of IBC channels (prefixed to token denom)
• escrow addresses are derived from a port/channel

High level problem is -> How do we uniquely identify the source chain?

Use a combination of the consensus state root and the height of a chain as its unique identifier. The likelihood of a hash collision at the same height across chains is infinitesimally low.

On send (source chain):

• Add chain_height/consensus_state_root_hash/ to the token denom prefix.
• Derive escrow address from chain_height and consensus_state_root_hash.

On intermediate transfers (non-source chain):

• No changes to token denom prefix.
• Transfer and burn the token.

On recv (source chain):

• Validate that the prefix in thedenom received matches some escrowed tokens at that height/consensus state root.

On transfer back to source (non-source chain):

• Claiming chain needs connectivity to the source chain.
• A chain of proofs can be supplied to match the channel client state on which we're transferring and the prefixed chain_height/consensus_state_root_hash/ in the token denom.
• The above matches the unique identity prefixed to the token with the unique identity of a channel/connection.

[AdityaSripal]

Use a combination of the consensus state root and the height of a chain as its unique identifier. The likelihood of a hash collision at the same height across chains is infinitesimally low.

On send (source chain):

Add chain_height/consensus_state_root_hash/ to the token denom prefix.
Derive escrow address from chain_height and consensus_state_root_hash.

This will not work to uniquely identify a chain, the collision is not infinitesimally low. An attacker chain could forge another chain's identity consHashX, heightH by simply mirroring that chain's application until height H and then proceeding to do whatever it wants for all heights H' > H.

We could uniquely identify a chain using chainID, validatorSetHashAtHeightH, SignedCommitAtHeightH since the same validator set should not sign a different commit for the same chainID, height tuple unless there is a malicious fork (which is outside ibc security model, handled by light client misbehaviour handling).

However, currently ICS20 does not enforce non-fungibility just at the chain layer but even at the channel layer. i.e. two channels coming from the same chain will have different denominations. This is because these channels may be built on different connections and clients which may have different security parameters and thus should not be fungible with each other. If a channel with stricter security requirements is fungible with a weaker one, then effectively all channels have the same security model as the weakest channel between two chains.

In practice, we have seen that a canonical transfer channel emerges between two chains.
However, as we will see it is critical that two tokens with the same origin but different provenance and security models must not be fungible at the protocol level.

On intermediate transfers (non-source chain):

No changes to token denom prefix.
Transfer and burn the token.

This is not how the current model works as in the current model when we transfer intermediately in the forward direction (ie, adding a step to the tokens provenance) we escrow the tokens. When we transfer intermediately in the reverse direction (ie, removing a step in the tokens provenance) we burn the tokens. The token denom is changed at each intermediate step (adding a prefix if we are adding to token provenance, removing prefix if we are removing from token provenance).

This is critical to ensure that the IBC security model is preserved.

Suppose that we only prefixed the original source information to the token denomination. Then once the tokens have left their original source chain, they are completely fungible with each other. This yields the following attack:

1. Suppose a total of 1 million stake tokens have left chainA. These are escrowed, so only a total of 1 million stake tokens can be received back to chainA.
2. Suppose 500,000stake have moved to chainB, and 499,999stake have moved to chainC, and 1stake has moved to chainD. All of this stake is only prefixed by the consensus info of chainA so they are all fungible with each other.
3. ChainD is a malicious chain that I control. I send back 1,000,000stake from chainD to chainA. chainA has no information on the provenance of these tokens. As far as it knows, 500,000stake could have moved from B->D->A and 499999stake could have moved from C->D->A.
4. It will verify since those tokens are escrowed and send the 1,000,000stake to the attacker. All users on chains B, C and D have their funds stolen.

With the way ICS20 is currently architected, only the 1stake send to D can be stolen by the malicious chainD validator set. This is within the IBC security model, since users are only exposed to the chains they trusted (ie the chains within the token provenance).

This is extended to the multihop case.

If I send stake from A -> B -> C -> D, at each point the token denom is changing and the tokens that move forward along the path are getting escrowed. Thus, only the maximum that went out can come back in. So if chainC becomes malicious in this case and tries to steal tokens originating from A. The maximum it can steal is the tokens that went to C (these include the tokens that went onwards to D), as soon as it tries to send back more tokens to B then it had received from B; this will be detected at chainB and error.

All users who had send tokens up to B but not onward to C are completely protected from C's malicious behaviour. All tokens that have chain C in its provenance are vulnerable to an attack by C.

This is a critical property of the IBC security model that we must preserve in the path unwinding case.

The only way I see of doing that is to maintain the semantics that chains escrow on forward paths to keep track of total balances out; and that when we unwind, these escrow balances on all intermediate chains in the token provenance are updated accordingly

[notbdu]

Maybe I'm missing something here but the "escrow" logic on non-source chains looks like its mint & burn. It doesn't look like any balances are held and validated on intermediate chains when we "unwind" a token.

I pulled the send/recv logic from non-source chains below.

On send, it burns the tokens:

// transfer the coins to the module account and burn them
if err := k.bankKeeper.SendCoinsFromAccountToModule(
        ctx, sender, types.ModuleName, sdk.NewCoins(token),
); err != nil {
        return 0, err
}

if err := k.bankKeeper.BurnCoins(
        ctx, types.ModuleName, sdk.NewCoins(token),
); err != nil {
        // NOTE: should not happen as the module account was
        // retrieved on the step above and it has enough balace
        // to burn.
        panic(fmt.Sprintf("cannot burn coins after a successful send to a module account: %v", err))
}

On receive, it mints the voucher and transfers it to the receiver:

// sender chain is the source, mint vouchers

// since SendPacket did not prefix the denomination, we must prefix denomination here
sourcePrefix := types.GetDenomPrefix(packet.GetDestPort(), packet.GetDestChannel())
// NOTE: sourcePrefix contains the trailing "/"
prefixedDenom := sourcePrefix + data.Denom

// construct the denomination trace from the full raw denomination
denomTrace := types.ParseDenomTrace(prefixedDenom)

traceHash := denomTrace.Hash()
if !k.HasDenomTrace(ctx, traceHash) {
        k.SetDenomTrace(ctx, denomTrace)
}

voucherDenom := denomTrace.IBCDenom()
ctx.EventManager().EmitEvent(
        sdk.NewEvent(
                types.EventTypeDenomTrace,
                sdk.NewAttribute(types.AttributeKeyTraceHash, traceHash.String()),
                sdk.NewAttribute(types.AttributeKeyDenom, voucherDenom),
        ),
)
voucher := sdk.NewCoin(voucherDenom, transferAmount)

// mint new tokens if the source of the transfer is the same chain
if err := k.bankKeeper.MintCoins(
        ctx, types.ModuleName, sdk.NewCoins(voucher),
); err != nil {
        return err
}

// send to receiver
if err := k.bankKeeper.SendCoinsFromModuleToAccount(
        ctx, types.ModuleName, receiver, sdk.NewCoins(voucher),
); err != nil {
        return err
}

We could uniquely identify a chain using chainID, validatorSetHashAtHeightH, SignedCommitAtHeightH since the same validator set should not sign a different commit for the same chainID, height tuple unless there is a malicious fork (which is outside ibc security model, handled by light client misbehaviour handling).

This works better as an unique identifier 😄!

If channel binding of tokens is a security feature, we can specify a transfer of ownership between channels instead of adding to a path of channels? It would retain the security properties that you mentioned but require there to be a pre-established channel between the next destination and the source chain.

In the case of A -> B -> C:

• A ----100 tokens----> B
• B ----20 tokens----> C (explicitly transfer ownership of tokens to A -> C)

A -> B channel now owns 80 tokens.
A -> C channel now owns 20 tokens.

If we combine the above with a unique cryptographic identifier like the one you suggested would that work?

[AdityaSripal]

Note how source is defined here. It does not mean the original source. It means whether the sender is the source of the tokens relative the receiver (ie, did the sender get these tokens from the receiver in the first place or not)

// SenderChainIsSource returns false if the denomination originally came
// from the receiving chain and true otherwise.
func SenderChainIsSource(sourcePort, sourceChannel, denom string) bool {
	// This is the prefix that would have been prefixed to the denomination
	// on sender chain IF and only if the token originally came from the
	// receiving chain.

	return !ReceiverChainIsSource(sourcePort, sourceChannel, denom)
}

// ReceiverChainIsSource returns true if the denomination originally came
// from the receiving chain and false otherwise.
func ReceiverChainIsSource(sourcePort, sourceChannel, denom string) bool {
	// The prefix passed in should contain the SourcePort and SourceChannel.
	// If  the receiver chain originally sent the token to the sender chain
	// the denom will have the sender's SourcePort and SourceChannel as the
	// prefix.

	voucherPrefix := GetDenomPrefix(sourcePort, sourceChannel)
	return strings.HasPrefix(denom, voucherPrefix)
}

So now I will talk about a specific example. Suppose we have 50uatom moving from chainA -chan1-chan2-> chainB -chan1-chan3-> chainC. I've included the local channel identifiers for each end in the arrows between the chains. Note that there is not global uniqueness, however for a given chain each channelEnd has a unique identifier. Let us consider what happens on SendPacket on chainB:

50uatom has already been escrowed on chainA. On chainB, 50transfer/channel2/uatom has been minted.

So we now run the SenderChainIsSource logic.

SenderChainIsSource("transfer", "channel-1", "transfer/channel-2/uatom")

Please verify that ReceiverChainIsSource will return false since the channel identifier is different. And thus SenderChainIsSource is true!

Note that chainB IS NOT the original source of the tokens uatom, that is chainA. However, it is the source of transfer/channel2/uatom when it sends it forward to chainC.

Thus, 50transfer/channel-2/uatom will be escrowed on chainB.

And 50transfer/channel-3/transfer/channel-2/uatom will be minted on chainC.

Now let us send tokens back from chainC -> chainB:

We run SenderChainIsSource logic:

SenderChainIsSource("transfer", "channel-3", "transfer/channel-3/transfer-channel-2/uatom")

Please verify that this time ReceiverChainIsSource will return true, and thus SenderChainIsSource is false!!

So now we will burn the tokens on chainC.

And 50transfer/channel-2/uatom will be unescrowed from chainB's escrow account. Note that this provides the supply constraint. We cannot send back to chainB more than what came from chainB in the first place, even if chainB is not the original source of the tokens.

---

In the case of A -> B -> C:

A ----100 tokens----> B
B ----20 tokens----> C (explicitly transfer ownership of tokens to A -> C)
A -> B channel now owns 80 tokens.
A -> C channel now owns 20 tokens.

Right so the use case here is that the user is sending the tokens from chainB -> chainC, and you want the state to update as if they had done chainB -> chainA-> chainC

This would require a write on A to update their escrow accounts which is what i mean by intermediate in this case. It is an intermediate chain in the unwinding.

[notbdu]

Note how source is defined here. It does not mean the original source. It means whether the sender is the source of the tokens relative the receiver (ie, did the sender get these tokens from the receiver in the first place or not)

Ohh gotcha, the naming threw me off haha - should've been less lazy and read the function implementation instead 😆. Thanks for the example!

In the case of A -> B -> C:

A ----100 tokens----> B
B ----20 tokens----> C (explicitly transfer ownership of tokens to A -> C)
A -> B channel now owns 80 tokens.
A -> C channel now owns 20 tokens.

Right so the use case here is that the user is sending the tokens from chainB -> chainC, and you want the state to update as if they had done chainB -> chainA-> chainC

This would require a write on A to update their escrow accounts which is what i mean by intermediate in this case. It is an intermediate chain in the unwinding.

Ah yea, if you want a two way channel binding between sender <> receiver then you can't get around the write on A in the example above 🥲 . Also understand that security wise, a one way binding is insufficient.

Is the strategy here (A --> B --> C case) to always transfer back to source (B --> A) and then back to the destination (A --> C)? This is effectively transferring channel ownership and always keeping the path short (1 hop).

[notbdu]

Also, with channel binding as a security requirement, it doesn't seem like a global chain registry would help much?

Even if you can uniquely identify a source chain, you still need to handle channel bindings.

[hxrts]

Per @crodriguezvega's request, I'm posting the IBC unwinding proposal drafted by Skip protocol. https://hackmd.io/@bpiv400/ibc-unwinding

Tagging @mpoke @cwgoes @AdityaSripal as their approval is required to modify this repo according to the standards committee document here: https://github.com/cosmos/ibc/blob/main/meta/STANDARDS_COMMITTEE.md

[AdityaSripal]

Thank you everyone for your feedback.

This is our current thinking. We want to ensure that this features get widespread adoption across the Interchain. We also want to reduce friction and timelines for getting this feature out.

I will write out the particular approaches that we considered from the different feedback we got and the pros and cons of each. I will leave minor points in italics and major points (as I see them) in bold.

---

I. Use middleware to process packet forwarding information in the memo field

Pros:

• Does not add logic to ICS20 base
• Could be made generic to support unwinding for assets outside fungible tokens

Cons:

• More explicit wiring in app.go required by chain developers to add the feature
• Will require channel upgradability in order to get atomic behaviour (no coins stranded in the middle of path)

II. Build logic into transfer to process packet forwarding information in the memo field

Pros:

• Simpler deployment
• Can have user-facing endpoints in ICS20 itself that structures the memo field for users

Cons:

• Will require channel upgradability in order to get atomic behaviour (no coins stranded in the middle of path)

III. Use middleware to wrap base ICS20 packet data with custom middleware packet info

Pros:

• Does not add logic to ICS20 base
• Could be made generic to support unwinding for assets outside fungible tokens
• Does not require channel upgradability

Cons:

• Passing user input into middleware directly is still an unsolved problem
• More explicit wiring in app.go required by chain developers to add the feature

IV. Build logic into transfer with a custom field in ICS20

Pros:

• Does not need channel upgradability (same properties as adding memo)
• Simpler deployment
• Can have user-facing endpoints in ICS20 itself that structures the memo field for users
• Path unwinding is a clear first class citizen feature of ICS20 (memo used for external logic, direct fields for internal logic)

Cons:

• Adds logic into ICS20
• Introduces a new field into ICS20 packet data

---

Explanation of why Channel Upgradability would be needed for memo but not for a new field

Suppose there is a token originating from chain C on chain A that has went through the following path: C -> B -> A

The user on chain C wishes to unwind and send to a chain D.

So our logic should go through the following path:

A -> B -> C -> D

Unwinding logic must exist on chains: A, B, C

We want this feature to be atomic. So when the user initiates the transfer on A, only one of two things happen.

1. The tokens end up on D with the canonical denom
2. The transfer failed somewhere along the way and the tokens are returned to their original form on chain A (as if the transfer never happened minus fees)

If all the chains in our path have the unwinding logic, then we can implement this behaviour using async acks. We will just hold off on writing the ack until the last chain writes it, then we will propogate it all the way back to sender. 🎉

Now suppose that all of the chains on our path have the memo field update, but chain C does not have the unwinding update.

The tokens will be correctly unwound down to chain C. When chain C receives them, it will treat the packet as a valid ICS20 packet with a memo that it does not know how to parse or act on; so it will just succeed as a regular transfer and the token flow will stop there. The tokens will not be forwarded on to chain D.

This leads to the undesirable case where tokens might be left anywhere along the path and the user has to go find them and pick them up. This is further complicated if the chains don't follow cosmos bech32 standard or if the user is a smart contract.

So we can fix this by using channel upgradability. Here we use it to communicate in advance whether our counterparty has the unwinding logic. So B would know that chain C does not have the unwinding logic since it doesn't have it negotiated in the B<->C channel version.

Then B would simply receive the tokens from A, check the next channel version, and if it doesn't support channel unwinding we fail early and send the tokens back.

Thus, we've recovered atomicity property in this case.

Now suppose that instead of overloading the memo field, we instead add a new field e.g. ForwardingInfo. If it is defined, we know to unwind to source and then use the information there to forward on to the final destination.

When all chains have the unwinding logic, we have the exact same behaviour as before.

Let's look again at the scenario where one of the chains (again chain C) does not have the unwinding logic implemented.

Here, we continue on the same way until we reach the Receive handler on chain C. Since chain C does not have the new logic, it will not expect the new field. It will fail the unmarshal here:

https://github.com/cosmos/ibc-go/blob/main/modules/apps/transfer/ibc_module.go#L178

and send back an error acknowledgement. This will be propogated back and the tokens will successfully refund on chain A.

When paired with the async ack logic we automatically get atomicity when introducing a new field with no need for channel upgradability.

---

Given the desire to get widespread adoption, get unwinding as a first-class in-built feature of ICS20, and not having to rely on a new complicated protocol to get our desired properties; our team is in favor of approach IV.

We reached this assessment after looking at the four approaches above and their associated pros and cons.

If there is anything critical that we have missed, or you think the pros and cons should be weighted differently than what I have conveyed. Then please comment below with your rationale

[kimurayu45z]

Is there a concrete plan to implement this?
Is it still in the planning stage?

[womensrights]

Great to see interest in this feature. As there are already some solutions out there to this problem, namely packet forward middleware, the tfm app or Skip's api which you can use through ibc.fun we decided to deprioritise this for now. Hopefully we will have some capacity to work on this next year. For the solution to offer something that the existing solutions don't I think having local on-chain registries for the canonical channels used is a strong requirement as currently these solutions rely on some off chain configurations to know the channel to use for unwinding