Home/Blockchain/Cosmos IBC Visualizer/Connection Handshake

🤝 Connection Handshake: Establish Trust

Learn how chains verify each other's consensus state

Enable inter-blockchain communication protocols

Your Progress

0 / 5 completed
1
2
3
4
5

Connection Handshake

Before chains can exchange packets, they must establish a **connection** through a four-way handshake protocol. This handshake verifies that both chains have correct light clients of each other and agree on connection parameters.

The handshake is similar to TCP's three-way handshake but includes an extra step for bidirectional verification. Once complete, the connection is in the OPEN state and multiple channels can be created over it.

Interactive: Handshake Simulator

Watch the four-step connection handshake between Chain A and Chain B.

1

ConnOpenInit

Chain A

Chain A creates connection in INIT state and specifies Chain B's client

State: INIT
2

ConnOpenTry

Chain B

Chain B verifies Chain A's state and creates connection in TRYOPEN state

State: TRYOPEN
3

ConnOpenAck

Chain A

Chain A verifies Chain B's TRYOPEN state and moves to OPEN

State: OPEN
4

ConnOpenConfirm

Chain B

Chain B verifies Chain A's OPEN state and moves to OPEN

State: OPEN

🔍 Handshake Verification

At each step, chains verify cryptographic proofs before progressing:

Client State Verification
Verify the counterparty chain's light client is tracking correct consensus state
Connection State Proof
Submit merkle proof that connection exists in counterparty's state tree
Consensus State Verification
Verify counterparty's validator set and block signatures

Channel Handshake

Once a connection is established, **channels** can be created for specific applications. Channel handshake is similar but adds application-specific version negotiation.

1
ChanOpenInit
Chain A initializes channel with port binding and ordering (ORDERED/UNORDERED)
2
ChanOpenTry
Chain B verifies connection, negotiates version, creates channel in TRYOPEN
3
ChanOpenAck
Chain A acknowledges, both agree on version, channel OPEN on Chain A
4
ChanOpenConfirm
Chain B confirms, channel OPEN on both chains, ready for packets

Light Client Updates

Throughout the handshake, relayers submit **light client updates** with block headers and validator signatures. Each chain maintains a light client view of the other chain's consensus state.

// Light Client Update
type Header = {
signedHeader: SignedHeader,
validatorSet: ValidatorSet,
trustedHeight: Height,
trustedValidators: ValidatorSet
}
// Verified using BFT consensus (2/3+ signatures)

💡 Key Handshake Properties

  • ✓Bidirectional Verification: Both chains verify each other's state cryptographically
  • ✓No Trusted Third Party: Light clients eliminate need for trusted relayers
  • ✓Version Negotiation: Chains agree on IBC version and application versions
  • ✓Idempotent: Handshake can be retried if messages are lost or timeout
←Previous