Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove 03-connection layer #7134

Open
1 of 6 tasks
colin-axner opened this issue Aug 12, 2024 · 0 comments
Open
1 of 6 tasks

Remove 03-connection layer #7134

colin-axner opened this issue Aug 12, 2024 · 0 comments
Labels
change: api breaking Issues or PRs that break Go API (need to be release in a new major version) change: protocol breaking Issues that cannot be addressed because they break the current protocol version epic icebox Issues that we will not address for the time being
Milestone

Comments

@colin-axner
Copy link
Contributor

Summary

With #6985 we see a direction of IBC which is simpler and more efficient, thus easier to implement in other languages and environments. The 03-connection layer should be removed. Here's why.

Problem Definition

The 03-connection layer has primarily served as a wrapper around the 02-client layer with additional information which is set during a connection handshake. This connection handshake ensured that clients were indeed properly configured and connected to one another. It could not verify if one side of the connection was malicious though.

With the removal of client and consensus state validation cosmos/ibc#1128, we can see that there isn't much left occurring in the connection handshake

More or less we:

  • generate connectionIDs
  • negotiate a connection version (has never changed or been used)
  • set the auxiliary client information in the connection
  • verify that the counterparty is performing actions (connection verification)

None of these are really necessary.

If we look at the connection structure we have:

  • client id (already managed by 02-client)
  • version (unused)
  • state (unnecessary if you remove the connection end)
  • counterparty (useful info, clientID + prefix, already being set used in eureka)
  • delay period (see Add delay period to tendermint client #7133)

The primary pieces which are useful and must be migrated:

  • counterparty
  • delay period

Proposal

I think a first step is to require connections initiated on our side to use eureka #7004. This would remove MsgConnOpenInit and MsgConnOpenAck. In addition, once we perform MsgConnOpenConfirm, we could remove the connection end we were setting in state. We would need to modify the channel handshake to account for a missing connection

We unfortunately cannot do the same for MsgChanOpenInit and MsgChanOpenAck without making changes to interchain accounts controller module.

Once all the below are checked, we can remove all references to the 03-connection layer:


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@colin-axner colin-axner added change: protocol breaking Issues that cannot be addressed because they break the current protocol version icebox Issues that we will not address for the time being change: api breaking Issues or PRs that break Go API (need to be release in a new major version) labels Aug 12, 2024
@colin-axner colin-axner added this to the v11.0.0 milestone Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
change: api breaking Issues or PRs that break Go API (need to be release in a new major version) change: protocol breaking Issues that cannot be addressed because they break the current protocol version epic icebox Issues that we will not address for the time being
Projects
Status: On hold ❌
Development

No branches or pull requests

2 participants