Prune stale acknowledgements after successful channel upgrade

[colin-axner]

Summary

Prune stale acknowledgements after successful channel upgrade.

Problem Definition

Acknowledgements currently live forever in IBC state despite no longer being necessary once a packet has completed its lifecycle. Overtime this can add up to quite a bit as outlined in #2869

Once a channel successfully upgrades, all old packets using previous channel parameters have been flushed and completed their lifecycle. The acknowledgement on the counterparty can then be safely removed.

Proposal

To avoid potential gas issues in block processing due to an unpredictable amount of acknowledgements to prune, I suggest the channel keeper store a mapping from the port/channel ID to the highest stale sequence. By stale sequence, I mean a sequence which refers to packets which have fully completed their lifecycle and thus all their information may be safely deleted.

The channel upgrade will already receive the counterparty latest sequence send, so on an upgrade it simply needs to store it:

// naming can be changed
k.setAcknowledgementPruningSequence(portID, channelID, counterpartyLatestSequenceSend)

A new msg type will need to be added which may prune any acknowledgement with a sequence <= to the highest stale packet sequence

message MsgPruneAcknowledgements {
  string port_id = 1;
  string channel_id    = 2;
  // optionally add a parameter to control the amount of acknowledgements to prune to avoid overrunning gas (we can alternatively account for this in the handler by checking gas left after each deletion)
}

// PruneAcknowledgements defines a rpc handler method for MsgCreateClient.
func (k Keeper) PruneAcknowledgements(goCtx context.Context, msg *clienttypes.MsgPruneAcknowledgements) (*channeltypes.MsgPruneAcknowledgementsResponse,
    ctx := sdk.UnwrapSDKContext(goCtx)

    pruningSequence, found := k.channelKeeper.GetAcknowledgementPruningSequence(ctx, msg.PortId, msg.ChannelId)
    if !found {
        return nil, err 
    }   

    // reverse iterate from earliest packet sequence, delete each acknowledgement until the acknowledgement sequence > pruningSequence 
    k.channelKeeper.pruneAcknowledegments(ctx, msg.PortId, msg.ChannelId, pruningSequence)
   

    return &channeltypes.MsgPruneAcknowledgementResponse{}, nil 
}

We can also add some result value to the MsgPruneAcknowledgementResponse to indicate if all possible acknowledgements were pruned, or if there are some left

Once the lowest acknowledgement sequence is greater than the pruning sequence, we can remove the pruning sequence mapping as well

Some quick pseudo code:

// TODO: add gas handling
func pruneAcknowledgements(ctx sdk.Context, portID, channelID string, pruningSequence uint64) {
    store := ctx.KVStore(k.storeKey)
    iterator := sdk.KVStorePrefixIterator(store, []byte(fmt.Sprintf("%s/%s", host.KeyPacketAckPrefix, host.ChannelPath(portID, channelID)))
    defer iterator.Close()

    for ; iterator.Valid(); iterator.Next() {
        iterKey := iterator.Key()
        seq := host.ParseSequence(iterKey)
        if seq > pruningSequence{
            break
        }   
        
        store.Delete(iterator.Key)
    }

    store.Delete(keyPruningSequence(portID, channelID))
}

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[DimitrisJim]

unsure what the timeline is on this but I'd like to take it on when the time is right ™️

[crodriguezvega]

Now that we removed LatestSequenceSend from Upgrade and we don't have this information available on the counterparty, do we need to rethink who to implement this feature? I guess we could add LatestSequenceEnd back if there is no other way, but would it be possible to use something like the following?

When chain A moves to OPEN (in openUpgradeHandshake) after completing the upgrade successfully we could get from the keys acks/ports/{portID}/channels/{channelID}/sequences/{sequence} the highest sequence number from all stored acknowledgements and store it as the acknowledgement pruning sequence. If the channel end on chain A has moved to OPEN and the upgrade has succeeded, then the counterparty (chain B) must have, at least, moved to FLUSHCOMPLETE, so so all packets sent from the counterparty chain should have completed the lifecycle.

[DimitrisJim]

Gonna split this one up in a couple of PRs to make it faster to review.

• protos/msgs.go impls tests/keeper + msg server stubs
• setting ack pruning seq in upgrade open + relevant glue code (set/get in keeper/key in host etc)
• impl of keeper/msg server + tests.

[colin-axner]

woot woot this is done, see all linked issues