LocalHost Handling

[AdityaSripal]

IBC currently provides a standard interface for applications on one chain to communicate with applications on an other chain. However, ibc-go currently does not support using the same interface for applications on one chain to communicate with applications on the same chain.

Ideally, an application can use the same interface to talk to a counterparty application regardless of whether the application is on a remote chain or in the same execution environment.

There was early work on providing this feature in the localhost client, however it was non-functional because it required complete access to the IBC store when individual clients were only given access to a subsection of the client store prefixed by their clientID.

Other issues involve the fact that even though the localhost client is communicating packets between two applications on the same chain, no optimizations were made to take advantage of this fact. There was still a connection handshake made between the localhost client to itself, and packets were still getting routed by third-party relayers.

The following proposal attempts to propose a correct localhost solution that will also take advantage of the fact that everything is occurring on a single chain.

Localhost Channel State Verification

Supporting localhost will require special-case handling in IBC given the semantics for typical IBC connections. Rather than putting this special case handling at the bottom-most layer and then having normal handling at the top. We can ensure that applications get the same interface at the channel-layer by instantiating a special localhost connectionID.

The channelKeeper will execute special case logic if the channel's underlying connectionID is "localhost", that will allow it to directly verify state has been committed by checking its own state instead of calling down to the connection and client layers.

// example of channel function that does
// verification in special localhost case
func (k Keeper) RecvPacket(
	ctx sdk.Context,
	chanCap *capabilitytypes.Capability,
	packet exported.PacketI,
	proof []byte,
	proofHeight exported.Height,
) error {
    // ... recv packet logic

    // packet commitment verification
    if channel.ConnectionHops[0] == "localhost" {
        commitment, ok := k.GetPacket(ctx, packet.SourcePort, packet.SourceChannel) 
        if !ok || commitment != CommitPacket(packet) {
            return error
        }
    } else {
        // do counterparty proof verification with underlying client
    }
    
    // ... continued recv packet logic
}

This pushes the localhost special case handling to the highest possible layer such that the applications are still using the exact same channel interface, while the underlying channel layer handles the special case of looking into its own store to check if the sender module sent the packet.

Atomic Localhost Handling

Because everything is happening on a single chain, we can take advantage of this fact and process the packet/channel handshake flow atomically.

I suggest that we handle this at the message server layer.

func (k Keeper) ChannelOpenInit(goCtx context.Context, msg *channeltypes.MsgChannelOpenInit) (*channeltypes.MsgChannelOpenInitResponse, error) {

    // complete ChanOpenInit logic

    if msg.Channel.ConnectionHops[0] == "localhost" {
        // create try message with nil proof
        tryMsg := MsgTry{}
        k.ChannelOpenTry(goCtx, tryMsg)
    }
}

// ... similar for other handshake methods, each can call the next one in the chain

// send packet is an exception since it is not implemented at msg server level
func (k Keeper) SendPacket(
	ctx sdk.Context,
	channelCap *capabilitytypes.Capability,
	packet exported.PacketI,
) error {
    // complete SendPacket logic

    if channel.ConnectionHops[0] == "localhost" {
       // create recv message with nil proof
       recvMsg := MsgRecvPacket{}
       k.RecvPacket(WrapContext(ctx), recvMsg)
    }
}

This part requires more design considerations since it could trigger multiple messages being executed atomically. A single chanOpenInit will cause the full handshake to execute. A send packet, will cause Recv and Ack to also be executed as part of the msg handling. This may lead to OutOfGas exceptions. So we may decide to either not go in this direction or to have it be optional.

Regardless I think both steps can be implemented independently.

The first step will allow relayers to still submit messages to the chain to move channel and packet handling forward (we need to allow submission of nil proofs in messages)

The second step can eventually phase out the use of relayers for local host handling.

[AdityaSripal]

cc: @michaelfig @dtribble @JimLarson

Will break these into separate issues after discussion of overall idea with ibc team

[dtribble]

Please add "loopback" into the title to make search easier!

[0xshipthecode]

We'd like to use this capability to be able to execute staking-related operations from an Agoric smart contract. In particular, we'd need to send requests to the staking module to trigger processing of the following messages:

• MsgDelegate
• MsgUndelegate
• MsgBeginRedelegate

Additionally (and optionally) if we could use the interface to retrieve information about current delegations, maturing redelegations or maturing undelegations to validators (total amounts as well as the amount delegated from specific accounts) that would be of high value. Mentioning this since the docs list unbonding periods as possible content of ClientState.

[dtribble]

The usage here is to use ICA to control staking. By using IBC to the local platform, it means the same contracts can be used to control remote chains via IBC as well.

By enabling loopback, we can use any application protocol for IBC via dIBC in JS.

[colin-axner]

The reason the baseapp message router cannot be used is because the smart contract shouldn't know whether the executing messages are executing on the same chain or a different chain? I'm just wondering why exactly the message router cannot be used and why it needs to go through IBC?

[jtieri]

Bumping this thread to see what the status is re: opening up issues related to this line of work.

[crodriguezvega]

@AdityaSripal will open the issues soon. Sorry for the delay!

[colin-axner]

Will the packet commitments and acknowledgements be written into state regardless of if the packet flow is executed over different block or all at once? I question the complexity of deviating from expected IBC behaviour too much. I think it makes sense to limit custom behaviour as much as possible. Packets sent on localhost should have the same flow/events as packets sent on non-localhost

Will there be a spec change for this? I also think it is worth considering the out of gas issues early on

[AdityaSripal]

09-localhost

[hxrts]

I think there is some value in optionally asking a relayer to deliver the packet to the same chain. Namely, the relayer can bundle the IBC packet with other transactions or deliver the transaction under specific conditions. This looks much like what's typically called a "keeper" in Ethereum https://docs.makerdao.com/keepers/market-maker-keepers