IBC as layered-interchangeable-protocol-stack

[cwgoes]

I think it will help to conceptualize IBC as a layered protocol stack (similar to the IP in this sense).

Layers:

1. Consensus Primitives (ICS ?: IBC threat model & security assumptions #2)
2. Connection (ICS 3: IBC connection lifecycle, protocol negotation handshake #3)
3. Channel (ICS 4: Channel & Packet Semantics #34)
4. Packet (ICS 5: Packet semantics #36)
5. Application (various)

The key insight is that lower layers (lower numbers) have no "knowledge" of higher layers - none of their security properties are dependent on those of higher layers, they rather provide primitives and security properties using which higher layers derive their primitives and security properties.

Furthermore, higher-layer protocols should:

• Only depend on the protocol one layer below them
  For example, channel semantics should not depend on the kind of lite client proof used.
• Explicitly enumerate the primitive set they require from that protocol
  Then it will be easy to instantiate variants of different layers while retaining security guarantees.

This may seem banal but I think it will end up being important that we keep the hierarchy strict.

[mossid]

This requires the block in consensus primitives need to specify the state structure. I think using KVStore is okay, I cannot imagine any use case of the block not using KVStore for its state.

Also, are we considering to send negotiation messages as a form of Datagram? This will also make Connection / Channel required to know about the Packet layer.

[cwgoes]

Datagram (the name could be changed) is the top-level opaque data blob that the top-level IBC handler will need to parse and interpret - so IBC packets, connection negotiation messages, header update messages, version upgrade messages, fraud proofs, etc. are all datagrams. Does that concept make sense?

[jackzampolin]

Big fan of this. This makes a ton of sense @cwgoes

[ethanfrey]

Great idea to keep these clearly defined levels that only depend on one clear interface.

Then it is easy to add orthogonal power...
Support 2 consensus engines, different channel semantics (in-order, timeout, receipts), and multiple application logic.
Each is a new dimension to multiply with the others

👍

[ebuchman]

Can we foresee places where the abstractions might leak ?

[ethanfrey]

@ebuchman
I left a comment where app state definition was in consensus layer.

It is not necessarily a leaking abstraction, I think it can cleanly be moved to another level, but shows the leakiness of our thinking on ibc and how tough it is to mentally separate these layers.

[cwgoes]

Can we foresee places where the abstractions might leak ?

I could foresee future optimizations that would traverse layers (as also exist in TCP/IP I think), but at the moment I can't think of any protocol-level "layer leakage" other than would result accidentally from imprecise design - although the layers I listed may not be the final set or ordering.

[cwgoes]

This has been reflected in the protocol design.