IBC Eureka #1093
IBC Eureka #1093
Conversation
|
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 |
…tion between <client, client> pairs
|
We should assert |
|
Also remove delay period for clients |
|
Would be great to align with PICA/ICAv2: https://hackmd.io/bqkQQ9AxR0KFR82APKXocQ |
|
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. |
spec/micro/README.md
Outdated
|
|
||
| // once a client has been created, relayers can submit misbehaviour that proves the counterparty chain | ||
| // The light client must verify the misbehaviour using the trust model of the consensus mechanism | ||
| // and execute some custom logic such as freezing the client from accepting future updates and proof verification. | ||
| function submitMisbehaviour( | ||
| clientId: Identifier, | ||
| misbehaviour: bytes, | ||
| ): error |
There was a problem hiding this comment.
Couldn't this be a part of updateClient in micro-ibc?
There was a problem hiding this comment.
As in, terminate the client with the reason? I guess the question is how much misbehavior should be tolerated. If it's zero than perhaps it would make sense to change the client state vs accumulate evidence of behavior for a later action.
There was a problem hiding this comment.
I personally prefer the way it is. Keeping the separation between misbehaviour and clients updates sounds like a less error prone approach.
spec/micro/README.md
Outdated
| Properties of Connection: | ||
|
|
||
| - Verifies the validity of the counterparty client | ||
| - Establishes a unique identifier on each side for a shared abstract understanding (the connection) | ||
| - Establishes an agreement on the IBC version and supported features | ||
| - Allows multiple connections to be built against the same client pair | ||
| - Establishes the delay period so this security parameter can be instantiated differently for different connections against the same client pairing. | ||
| - Defines which channel orderings are supported | ||
|
|
||
| Properties of Channel: | ||
|
|
||
| - Separates applications into dedicated 1-1 communication channels. This prevents applications from writing into each other's channels. | ||
| - Allows applications to come to agreement on the application parameters (version negotiation). Ensures that each side can understand the other's communication and that they are running mutually compatible logic. This version negotiation is a multi-step process that allows the finalized version to differ substantially from the one initially proposed | ||
| - Establishes the ordering of the channel | ||
| - Establishes unique identifiers for the applications on either chain to use to reference each other when sending and receiving packets. | ||
| - The application protocol can be continually upgraded over time by using the upgrade handshake which allows the same channel which may have accumulated state to use new mutually agreed upon application packet data format(s) and associated new logic. | ||
| - Ensures exactly-once delivery of packet flow datagrams (Send, Receive, Acknowledge, Timeout) | ||
| - Ensures valid packet flow (Send => Receive => Acknowledge) XOR (Send => Timeout) |
There was a problem hiding this comment.
Shall we add some diagrams too?
spec/micro/README.md
Outdated
|
|
||
| ### Context | ||
|
|
||
| The implementation of the entire IBC protocol as it currently stands is a large undertaking. While there exists ready-made implementations like ibc-go this is only deployable on the Cosmos-SDK. Similarly, there exists ibc-rs which is a library for chains to integrate. However, this requires the chain to be implemented in Rust, there still exists some non-trivial work to integrate the ibc-rs library into the target state machine, and certain limitations either in the state machine or in ibc-rs may prevent using the library for the target chain. |
There was a problem hiding this comment.
It might be worth mentioning ibc-solidity, composable's work, union's work, and others
There was a problem hiding this comment.
I would say the big advantage is that with this compressed version of the protocol the verification of the state is much more straight forward but slightly compressed into a single round trip which is i think a net win for implementors but probably leaks previous sub domains of the previous layers into a single macro domain but again is a net win.
There was a problem hiding this comment.
What's written in the context, in part, are the consequences of the initial design choices that were made. I wonder if we shall point this out or keep it implicit.
spec/micro/README.md
Outdated
| clientId: Identifier, | ||
| header: bytes, | ||
| ): error | ||
|
|
There was a problem hiding this comment.
Perhaps we should add a migrateClient function. This is a recurring problem chains are having in the CosmosSDK. It would be nice to have a local solution for this in micro-ibc, especially since it will be up to the implementer to use it or not.
There was a problem hiding this comment.
If the majority of the cases for micro-ibc would be specifically new connections, what would be the motivation for transitioning from an existing client to a micro-client if the work has already been done?
spec/micro/README.md
Outdated
| // increment the sequence. Thus there are monotonically increasing sequences for packet flow | ||
| // from sourcePort, sourceChannel pair | ||
| channelStore.set(nextSequenceSendPath(commitPort, sourceChannel), sequence+1) | ||
|
|
There was a problem hiding this comment.
This should be making an application callback I think. This is because:
- Even if we want the packet lifecycle to begin in the IBC app. There is nothing wrong with the application receiving a callback. In fact, this is necessary to receive a reply in the Actor model of CosmWasm.
- Might make multipacket lifecycle easier to implement
… key prefix prepending before proof verification
spec/micro/README.md
Outdated
|
|
||
| The light client module can be implemented exactly as-is with regards to its functionality. It **must** have external endpoints for relayers (off-chain processes that have full-node access to other chains in the network) to initialize a client, update the client, and submit misbehaviour in case the trust model of the client is violated by the counterparty consensus mechanism (e.g. committing to different headers for the same height). | ||
|
|
||
| The implementation of each of these endpoints will be specific to the particular consensus mechanism targetted. The choice of consensus algorithm itself is arbitrary, it may be a Proof-of-Stake algorithm like CometBFT, or a multisig of trusted authorities, or a rollup that relies on an additional underlying client in order to verify its consensus. |
There was a problem hiding this comment.
Probably requires single slot finality for the state proofs or some kind of finality gadget.
There was a problem hiding this comment.
I agree we could include some consideration around consensus finalities here.
spec/micro/README.md
Outdated
|
|
||
| Writing an implementation from scratch is a problem many ecosystems face as a major barrier for IBC adoption. | ||
|
|
||
| The goal of this document is to serve as a "micro-IBC" specification that will allow new ecosystems to implement a protocol that can communicate with fully implemented IBC chains using the same security assumptions. |
There was a problem hiding this comment.
I guess that another goal of this document is to revisit the initial design choices, learn from them, keep the core meat, and provide a smoother version of protocol that will be useful not only for new ecosystem, but even for cosmos itself.
spec/micro/README.md
Outdated
| - Light-client backed security | ||
| - Unique identifiers for each channel end | ||
| - Authenticated application channel (must verify that the counterparty is running the correct client and app parameters) | ||
| - Applications must be mutually compatible with standard IBC applications. |
There was a problem hiding this comment.
Not entirely sure all applications will actually be mutually compatible with standard ones.
spec/micro/README.md
Outdated
|
|
||
| ```typescript | ||
| interface Counterparty { | ||
| channelId: Identifier |
There was a problem hiding this comment.
I am not entirely sure in this spec we should keep using channelIDs instead of clientIDs. Is this an implementation related detail to ensure compatibility with ibc-go? If yes, shouldn't we use clientIDs in the spec and, additionally, provide a comment stating that the implementation we will be using channelIDs?
spec/micro/README.md
Outdated
| } | ||
| ``` | ||
|
|
||
| ### Correctness |
spec/micro/README.md
Outdated
|
|
||
| Similarly, for packet flow messages sent to the sender (AcknowledgePacket, TimeoutPacket); the packet is provided again. This time, we use the sender identifier to retrieve the local client and the destination identifier to determine the key path that the receiver must have written to when it received the packet. We can thus use our retrieved client to verify a key/value membership proof to validate that the packet was sent by the counterparty. In the case of timeout, if the packet receipt wasn't written to the receipt path determined by the destination identifier this can be verified by our retrieved client using the key nonmembership proof. | ||
|
|
||
| ### Soundness |
There was a problem hiding this comment.
Note that, potentially, in the future we could enforce client identifiers global uniqueness. For now I agree that the way the packet committed key path is constructed should be a strong guarantee.
spec/micro/README.md
Outdated
|
|
||
| ------ | ||
|
|
||
| IGNORE THE MULTICHANNEL WORK FOR NOW |
There was a problem hiding this comment.
Potentially we could address the multichannel work in a different PR
|
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! |
spec/micro/README.md
Outdated
| In core IBC, the connection and channel handshakes serve to validate the clients are valid clients of the counterparty, ensure the IBC version and application versions are mutually compatible, as well as providing unique identifiers for each side to refer to the counterparty. | ||
|
|
||
| Since we are removing handshakes in IBC lite, we must have a different way to provide the chain with knowledge of the counterparty. With a client, we can prove any key/value path on the counterparty. However, without knowing which identifier the counterparty uses when it sends messages to us; we cannot differentiate between messages sent from the counterparty to our chain vs messages sent from the counterparty with other chains. Most implementations will not be able to store the ICS-24 paths directly as a key in the global namespace; but will instead write to a reserved, prefixed keyspace so as not to conflict with other application state writes. Thus the counteparty information we must have includes both its identifier for our chain as well as the key prefix under which it will write the provable ICS-24 paths. | ||
|
|
There was a problem hiding this comment.
I feel like adding a simple diagram of the above will aid significantly in understanding, especially given how critical this is to part of the design.
spec/micro/README.md
Outdated
| } | ||
| ``` | ||
|
|
||
| Since the packets are addressed **directly** with the underlying light clients, there are **no** more handshakes necessary. Instead the packet sender must be capable of providing the correct <client, client> pair. |
There was a problem hiding this comment.
I feel like it might be worth noting here, that there might be increased bandwidth for relayers or packet senders, with the added benefit of significantly reducing protocol complexity.
Co-authored-by: Aleksandr Bezobchuk <[email protected]>
|
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! |
AdityaSripal
requested review from
angbrav,
colin-axner and
damiannolan
as code owners
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: