Regarding the handshake and 'portAddress'

Development
1

Hello team,

I am building an indexer lately, so I am fetching all the events and txs from both optimism-sepolia and base-sepolia. I was thinking the portAddress is kind of an identifier on each chain for the counterparty to find each other. However, there are two questions I would like to seek your help:

Here are the logs for the questions:

// [1] Attempt to create a channel
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-8', 'connection-11' ],
  counterpartyPortId: 'polyibc.base-proofs.B9F295619224d14De6416C1209f3D373F0975C5f',
  counterpartyChannelId: '',
  portAddress: '0x1bc8117AFE861237ad8EC9eAE6976b08EBDe0282',
  block: 8878428,
  tx: '0xcfe185bf2daec18b0d1fa344f0d7de532e00f6fd6d8097b76233023c352dc7f9'
}

// [2] Attempt to create a channel
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-8', 'connection-11' ],
  counterpartyPortId: 'polyibc.base-proofs.B9F295619224d14De6416C1209f3D373F0975C5f',
  counterpartyChannelId: '',
  portAddress: '0x1bc8117AFE861237ad8EC9eAE6976b08EBDe0282',
  block: 8879040,
  tx: '0x3634168f6036ad43846e6404b76c1a23ea8d3dd9982dc3e63bb58099bbe27a33'
}

// [3] Attempt to create a channel
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-8', 'connection-11' ],
  counterpartyPortId: 'polyibc.base-proofs.B9F295619224d14De6416C1209f3D373F0975C5f',
  counterpartyChannelId: '',
  portAddress: '0x1bc8117AFE861237ad8EC9eAE6976b08EBDe0282',
  block: 8879135,
  tx: '0xd2771a6f5c9a567e8ca5a6669f7559c34ee3432445579b5bb2a5440aa87fbdf8'
}

// [4] Attempt to create a channel
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-8', 'connection-11' ],
  counterpartyPortId: 'polyibc.base-proofs.B9F295619224d14De6416C1209f3D373F0975C5f',
  counterpartyChannelId: '',
  portAddress: '0x1bc8117AFE861237ad8EC9eAE6976b08EBDe0282',
  block: 8879304,
  tx: '0xa561c4395059936d7c8df978de83c6b8a0da3b3ee1dfa779c53c93cbd4293a37'
}

// [5] Attempt to create a channel
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-8', 'connection-11' ],
  counterpartyPortId: 'polyibc.base-proofs.B9F295619224d14De6416C1209f3D373F0975C5f',
  counterpartyChannelId: '',
  portAddress: '0x1bc8117AFE861237ad8EC9eAE6976b08EBDe0282',
  block: 8879399,
  tx: '0x5f844b70e340db97127358c059a38e832d8054f564f771529851794d729bff8c'
}

// [6] Attempt to create a channel
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-8', 'connection-11' ],
  counterpartyPortId: 'polyibc.base-proofs.B9F295619224d14De6416C1209f3D373F0975C5f',
  counterpartyChannelId: '',
  portAddress: '0x1bc8117AFE861237ad8EC9eAE6976b08EBDe0282',
  block: 8879887,
  tx: '0xca02732f46a65f88b2df29c30f92ec51807d949ed52bac7201d9aa429d77a266'
}

// [7] Attempt to create a channel
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-8', 'connection-11' ],
  counterpartyPortId: 'polyibc.base-proofs.B9F295619224d14De6416C1209f3D373F0975C5f',
  counterpartyChannelId: '',
  portAddress: '0x1bc8117AFE861237ad8EC9eAE6976b08EBDe0282',
  block: 8880038,
  tx: '0x7be9ec4e6e23a7efda271246741a680e495967d78bdb9a82f28fd61baf2a293a'
}

// [8] Attempt to create a channel
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-8', 'connection-11' ],
  counterpartyPortId: 'polyibc.base-proofs.B9F295619224d14De6416C1209f3D373F0975C5f',
  counterpartyChannelId: '',
  portAddress: '0x1bc8117AFE861237ad8EC9eAE6976b08EBDe0282',
  block: 8880203,
  tx: '0x43818aa3c537d1383ff7000766404cdbbc0458dc7f3e6ef35969cf0952578885'
}

// Attempt to create a channel with a new portAddress from op
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-0', 'connection-5' ],
  counterpartyPortId: 'polyibc.base-sim.28C7c1a52613fAaF8B7267cd7038520aaA18ce65',
  counterpartyChannelId: '',
  portAddress: '0xbfBec33c5Fa0420cC4f03F949D1B0c35fcBBfDeA',
  block: 8880758,
  tx: '0xc6500f2e88e863c8225c2ebb99b4afbb9a70f37c93b5401097fad85c03b65d23'
}

// base is responding the request
base-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 0,
  feeEnabled: false,
  connectionHops: [ 'connection-4', 'connection-1' ],
  counterpartyPortId: 'polyibc.optimism-sim.bfBec33c5Fa0420cC4f03F949D1B0c35fcBBfDeA',
  counterpartyChannelId: 'channel-32',
  portAddress: '0x28C7c1a52613fAaF8B7267cd7038520aaA18ce65',
  block: 6897892,
  tx: '0xe5c2aa6856af65fa91b094aad0450b927df2a2f7611874310debd6419fca986e'
}

// channel established: channel-32
optimism-sepolia {
  type: 'ConnectIbcChannel',
  channelId: 'channel-32',
  portAddress: '0xbfBec33c5Fa0420cC4f03F949D1B0c35fcBBfDeA',
  block: 8880773,
  tx: '0xa2dac6e109fb9d27f5ed85cb3685d812fd380d51e33bd2832794f775203cad6b'
}

// channel established: channel-33
base-sepolia {
  type: 'ConnectIbcChannel',
  channelId: 'channel-33',
  portAddress: '0x28C7c1a52613fAaF8B7267cd7038520aaA18ce65',
  block: 6897906,
  tx: '0xbfb740a735192c3cabd97f0d433f20991a7c7d16dd67ffbe05cc7359d9585e3f'
}

// Attempt to create another channel with the same portAddress on op
optimism-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 1,
  feeEnabled: false,
  connectionHops: [ 'connection-0', 'connection-5' ],
  counterpartyPortId: 'polyibc.base-sim.28C7c1a52613fAaF8B7267cd7038520aaA18ce65',
  counterpartyChannelId: '',
  portAddress: '0xbfBec33c5Fa0420cC4f03F949D1B0c35fcBBfDeA',
  block: 8880788,
  tx: '0x4941d592a2d763252699fc61e9777e7afef33de1f632b3da92a273d2852079db'
}

// base is responding
base-sepolia {
  type: 'OpenIbcChannel',
  version: '1.0',
  ordering: 0,
  feeEnabled: false,
  connectionHops: [ 'connection-4', 'connection-1' ],
  counterpartyPortId: 'polyibc.optimism-sim.bfBec33c5Fa0420cC4f03F949D1B0c35fcBBfDeA',
  counterpartyChannelId: 'channel-34',
  portAddress: '0x28C7c1a52613fAaF8B7267cd7038520aaA18ce65',
  block: 6897920,
  tx: '0xaf1d51dbd061ba1c4f25c1224122bc48408c3dff1df47aa39f7178a79d5f0bbd'
}

// New connection established: channel-34 (should this override channel-32?)
optimism-sepolia {
  type: 'ConnectIbcChannel',
  channelId: 'channel-34',
  portAddress: '0xbfBec33c5Fa0420cC4f03F949D1B0c35fcBBfDeA',
  block: 8880802,
  tx: '0xdebe6e4b9efe028fbdc67bc55e05986b924030d853806a1cc274044131ce6b4d'
}

// New connection established: channel-35 (should this override channel-33?)
base-sepolia {
  type: 'ConnectIbcChannel',
  channelId: 'channel-35',
  portAddress: '0x28C7c1a52613fAaF8B7267cd7038520aaA18ce65',
  block: 6897934,
  tx: '0x80978af01eb2fa991b50ffc731b8c81f1bc28b88e3f9b16e25692ed56063b5de'
}
  • Can portAddress be re-used? If one connection has already been established successfully on both chain, can we attempt to establish another connection with the same portAddress? If so, is the latter one overrides the existing one?
  • What happens if the handshake fail? In the provided logs, I can see there was a OpenIBCChannel request attempted to establish a new connection on optimism-sepolia for 8 times, but no response from base-sepolia. Is there a timeout mechanism for the handshake period?

Thank you very much!

2

Hey @stevenlei, thanks for providing a ton of detail and asking very thoughtful questions!

Can portAddress be reused?

  1. Reusability of portAddress: In the IBC protocol, a portAddress can conceptually be reused for establishing multiple channels, given that each channel is uniquely identified by its channelId. However, the practicality and advisability of doing so depend on the specific implementation details of the IBC protocol on the Polymer platform and the intended use cases. Typically, a portAddress represents a specific application or module on a blockchain, and multiple channels might be used for different communication purposes or with different counterparties.
  2. Override of Existing Connection: Establishing a new connection with the same portAddress does not inherently override an existing one. Each channel, identified by its unique channelId, operates independently. If a new channel is created, it simply means the portAddress is now associated with multiple active channels, each with its distinct channelId and state. It’s crucial for the application logic to correctly manage and utilize the appropriate channel based on its purpose.

What happens if the handshake fails?

  1. Handshake Failure: In IBC, the handshake is a four-step process involving several transactions in the handshake life cycle (e.g., OpenInit, OpenTry, OpenAck, OpenConfirm) exchanged between the two chains involved. If any step in this process fails (e.g., due to a lack of response from the counterparty), the handshake cannot be completed, and the channel remains in an uninitialized or partially initialized state.
  2. Timeout Mechanism: The IBC protocol does include mechanisms to handle timeouts and failed handshakes. If a handshake message does not receive a response within a certain period, the initiating chain can opt to close or clean up the partially opened channel. The specifics of the timeout period and the cleanup process depend on the implementation details of the IBC module on each blockchain. As of now, I believe Polymer tracks and stores the channelIds. In the logs of the ibc-app-solidity-template on channel creation the channelId is not logged until the OpenTry step.

Summary

  • PortAddress Reusability: It is technically possible to use the same portAddress for multiple custom channels, but each channel functions independently, identified by its unique channelId.
  • Handshake Failures and Timeouts: Failures in the handshake process due to non-responsiveness can be managed through timeouts, with specific actions required to close or clean up the failed channel attempts, depending on the blockchain’s IBC implementation.
2 Likes
3

Hey @kenobi thanks for your prompt reply!

May I know if listening to Dispatcher’s contract events (like above) is the best way to know the channel creation?

Thanks again

4

Hey @stevenlei

To add to what @kenobi already explained:

Right now the relayer kind of expects to have “ordering” to be 0 (this is in fact incorrect, and will be updated in a later upgrade).

In ibc-app-solidity-template we tried to make sure devs would take this default value:

In your logs I do see ordering: 1 appear which may cause a handshake to fail…

May I know if listening to Dispatcher’s contract events (like above) is the best way to know the channel creation?

Adding events to applications in the channel callbacks would be just as good (unless you want to capture ALL packets, then dispatcher is the contract to go for

2 Likes
5

Thank you @tmsdkeys I am kind of get it solved by reading both the event and the transaction data, and I found that both channel id of origin and destination are available in the second (response) of OpenIbcChannel.

I am running the test now and hopefully get the indexer working very soon!

Thanks for your help

1 Like