Adds automated changelog, basic IBCv2 docs + small tweaks #21
Conversation
|
|
||
| ### Delivery and Acknowledgement | ||
|
|
||
| Once a packet is verified, its data is delivered to the destination application for processing. The destination chain then commits an Acknowledgement, recording the outcome of the transaction (either success or failure). This acknowledgement acts as a return receipt, which a relayer then delivers back to the source chain along with its own proof. |
There was a problem hiding this comment.
Nit: the applications can also return data in the ack
| Once a packet is verified, its data is delivered to the destination application for processing. The destination chain then commits an Acknowledgement, recording the outcome of the transaction (either success or failure). This acknowledgement acts as a return receipt, which a relayer then delivers back to the source chain along with its own proof. | |
| Once a packet is verified, its data is delivered to the destination application for processing. The destination chain then commits an Acknowledgement, recording the outcome of the transaction (either some application specific success data or a failure). This acknowledgement acts as a return receipt, which a relayer then delivers back to the source chain along with its own proof. |
| ## Key Components | ||
|
|
||
| <Accordion title="Client (ICS‑02) – Light Client"> | ||
| An on‑chain light client that verifies the state of a counter‑party chain using cryptographic proofs against a trusted consensus state. |
There was a problem hiding this comment.
Nit: ICS02 specifies how light clients should behave, as well as how the protocol itself should handle client creation (adding new light clients) and client routing (making sure updateClient, verify* goes to the correct light client).
| 1. Locates the correct light client via `destClientId`. | ||
| 2. Verifies the proof. | ||
| 3. Stores a **Receipt** at the **Packet Receipt** path. | ||
| 4. Invokes the destination module’s `OnRecvPacket` callback. |
There was a problem hiding this comment.
Might be worth using a similar language to earlier and call this an "App"?
| </Accordion> | ||
|
|
||
| <Accordion title="3. WriteAcknowledgement (Destination Chain)"> | ||
| The destination application returns an **Acknowledgement** (success data or error) from `OnRecvPacket`. The IBC handler commits this acknowledgement at the **Acknowledgement** path, making it ava> |
There was a problem hiding this comment.
Missing something at the end of this sentence?
| A relayer brings the acknowledgement and its proof back to the source chain. After proof verification, the source chain’s handler: | ||
|
|
||
| * Deletes the original packet commitment. | ||
| * Calls `OnAcknowledgePacket` on the sending application to finalize the cross‑chain operation. |
There was a problem hiding this comment.
Might be worth nothing that the ack is passed to the sending application so it can act on the information if that is desired.
| </Accordion> | ||
|
|
||
| <Accordion title="5. TimeoutPacket (Source Chain)"> | ||
| If no acknowledgement arrives before `timeout`, a relayer submits a non‑existence proof for the **Packet Receipt**. The source chain deletes the packet commitment and triggers `OnTimeoutPacket`, allowing the application to revert or refund the original transaction. |
There was a problem hiding this comment.
Nit: the word "arrives" here is a little ambiguous. If the no receipt been written before the timeout timestamp, the relayer would do this. It's not dependent on wether or not it arrived back at the source chain or not. Technically the acknowledgment can never arrive, if nobody bothers to relay it - many applications don't actually do anything with a success ack. With ICS20 Transfer for instance, the ack does nothing useful - and we don't really need to do it if the gas cost is very high for instance.
New page
/evm/changelogwhich should be generated by the github workflow from thecosmos/evmrepo changelog on new releases.New pages in
/ibccreated to summarize the ibcv2 spec docsRearranged sidebar and tabs bar. "Concepts" now lives under EVM. EVM Devnet is moved to the bottom of the EVM section. IBC is now a tab.