IBC Eureka

[AdityaSripal]

The following is a spec that intends to produce an alternative implementation of the IBC spec that is much easier to get to market while still maintaing the light-client backed security that IBC promises and maintains compatibility with the rich ecosystem of chains, light clients, and applications that already exist in the IBC ecosystem.

It works by taking a standard IBC light client and connecting it with as minimal complexity as possible to a standard IBC application.

Thus the connection and channel handshakes are completely stripped out (though the counterparty client verification done in a 2-step handshake that replaces the 8-step connection/channel handshake)

The client is connected to a a multi-application channel that can connect to any IBC application. Thus, a single light client and a single channel would enable all IBC app data to flow between two chains.

This also automatically gives us atomic IBC packets while still requiring very little changes to the IBC application.

Unsupported atm:

• ORDERED channel (the mulit-IBC channel is UNORDERED, probably will remain)
• Async acknowledgements (seems possible to fix, just more complex since we must maintain state in receiver until final ack is ready)
• Compatibility with traditional channels with a separate port and version. This seems much harder but still possible and arguably the most desirable of current unsupported features

[AdityaSripal]

Note TODO, I need one more handshake message here, and I need to ensure both sides have the counterparty channel store Identifier and has verified this field on the other end as well

[srdtrk]

We should assert VerifyMembership and VerifyNonMembership are non state modifying in ibc-lite

[srdtrk]

Also remove delay period for clients

[hdevalence]

Would be great to align with PICA/ICAv2: https://hackmd.io/bqkQQ9AxR0KFR82APKXocQ

[srdtrk]

We should look at if it's possible to remove timeout revision number and timeout revision height from the packet commitment. And only keep timeout timestamp.

[faddat]

Hey I just wanted to say that I think that this is really really cool, and I'm going to give it a read and provide feedback if I come up with anything.

Thank you!

[AdityaSripal]

Thank you everyone for the feedback so far. We are committed to going in this direction with the IBC protocol.

Given the scope of this change, it doesn't make sense to house everything in a single file and solicit feedback. We are going to make a new directory to house a new, vastly simplified spec that will form the basis of IBC v2 (codenamed Eureka). We're hoping to take this new approach and solve the issues that we found in maintaining the current spec.

Mainly we will ensure to keep a distinction between what is required by the protocol and what are design decisions being made by ibc-go. We will also work on versioning so that it is clearer for implementers to get a cohesive spec that they can rely on without having to reference ibc-go.

As such, we will break down this spec into multiple smaller issues and PRs and solicit feedback on them individually as they go in. Me and @sangier will be leading the efforts to get this merged.

For now, we will merge this PR into the folder it currently is with an EXPERIMENTAL label.

Once we have flushed out a more formal spec that will eventually replace the current one; we will delete this file. From that point, implementers can refer to the v2 folder in this repository to get a clear and concise understanding of how to implement the eureka protocol.

The v1 specs will be retained but eventually placed into maintainance mode.

Looking forward to collaborating with all of you on this exciting future direction!