Eureka Channel/Client ID Developer Experience

[gjermundgaraba]

This issue is my attempt at documenting the developer experience issues I had while updating the IBC Eureka Solidity codebase from interacting with the proof-of-concept version of ibc-go Eureka to the most up-to-date branch.

For context, the proof-of-concept version has no channel IDs. It was purely relying on client IDs for communication targeting.
Essentially, the channel ID was just the client ID. This is still how the Solidity implementation is built. It does not have any notion of channels (except in the packet structure which has channel source and destination). The benefit is that there is no need for a channel abstraction layer between clients and channels. A client simply has a counterparty which is the destination client ID.

Setup

So, just from a conceptual point of view, the client-to-client communication is easier to wrap your head around. But it is also simpler to set up. The setup is simply 1 create client, 2 register counterparty. If you are setting up both at the same time, the whole thing can be done in 3 steps: 1 create client A, 2 create client B with counterparty registration of A, 3 register counterparty B on client A.

On the cosmos side (and defined in the most recent spec changes I've seen), this is currently supposed to be 3 steps per chain: 1 create client, 2 create channel, 3 create counterparty. This could probably be reduced to fewer steps, but it still feels like an unnecessary abstraction layer since all of these are 1-to-1 concepts. If this was a database I would question why they are separate things.

Working with two different implementations

The main issue has still been the annoying difference in concepts and abstractions between these two implementations. In the initial PR to get all the e2e tests to run against the newest ibc changes, I deliberately did not change anything in the solidity code as far as channels go. This was partially to keep changes as low as I could, but also because it is not for sure that adding the channel abstraction concept there would be good. It would either mean unnecessary logic and data storage to create channel identifiers or add channels as an "artificial" layer that just uses client identifiers underneath the hood.

What this meant, however, was that I had to juggle the two concepts of channel IDs and client IDs throughout the e2e tests. Since we are relaying everything manually, it meant having to figure out the right one to use everywhere. It is certainly doable, but it makes for a developer experience that is more frustrating than I believe it has to be. And sure, it could be done better by storing channel IDs and channel IDs separately in the tests, but hiding that complexity is more of a smell than anything else, in my opinion.

When debugging, it also was annoying to always have to think "was this supposed to be a channel identifier or not?".

Legacy

I guess one of the reasons to keep the channel concept around was to make backward compatibility more straightforward for the ibc-go implementation. I do, however, feel like it is a mistake to add complexity and abstractions if we expect that the future use of IBC will outnumber existing use by orders of magnitude. I believe we should optimize for simplicity for the future, rather than simplicity for the past.

My conclusion

Based on my experience working with both the poc version and the latest version, I can say that it was much more pleasant to work with the simple concept of client-to-client communication, rather than having another layer of abstraction. To be fair, a lot of the frustration came from the solidity implementation not implementing this abstraction layer, but even if it did, the simplicity we had earlier was just easier to reason about and work with.

Personally, I think we should drop channel identifiers and ideally even the use of the whole channel concept. You send messages from one client to another. So simple :)