|
1 | 1 | # ICS-24 Host Requirements <!-- omit in toc --> |
2 | 2 |
|
3 | 3 | - [Overview](#overview) |
| 4 | +- [Host Configuration](#host-configuration) |
4 | 5 | - [Implementation](#implementation) |
| 6 | + - [Persistence](#persistence) |
5 | 7 | - [Paths and Identifiers](#paths-and-identifiers) |
6 | 8 | - [Timestamps](#timestamps) |
7 | 9 | - [IBC State](#ibc-state) |
@@ -45,15 +47,15 @@ The following is a simplified sequence diagram of an IBC fungible token transfer |
45 | 47 | ```mermaid |
46 | 48 | sequenceDiagram |
47 | 49 | actor UA as User A |
48 | | - box Blue Chain A |
| 50 | + box Transparent Chain A |
49 | 51 | participant A1 as Validator A |
50 | 52 | participant A2 as IBC Host A |
51 | 53 | participant A3 as Light Client B |
52 | 54 | end |
53 | 55 | box Transparent Relayer |
54 | 56 | actor R1 as Relayer |
55 | 57 | end |
56 | | - box Red Chain B |
| 58 | + box Transparent Chain B |
57 | 59 | participant B1 as Validator B |
58 | 60 | participant B2 as IBC Host B |
59 | 61 | participant B3 as Light Client A |
@@ -152,23 +154,12 @@ See: [ibc/module.go](../module.go) for the specific implementation details. |
152 | 154 |
|
153 | 155 | With the `IbcMessage` now propagated through the network's mempool, when it is reaped (by the block proposer) the message's validity will be handled by first determining the type of the `IbcMessage`: |
154 | 156 |
|
155 | | -- `UpdateIbcStore`: The `key` and `value` fields of the `IbcMessage` are inserted into the `ibc_messages` Postgres table along with the current height |
156 | | -- `PruneIbcStore`: The `key` with a `nil` value is passed into the `ibc_messages` Postgres table along with the current height |
157 | | - |
158 | | -_Note: Prior to insertion the `key` and `value` fields of the messages are hexadecimally encoded into strings._ |
| 157 | +- `UpdateIbcStore`: The `key` and `value` fields are tracked by persistence and used to update the `ibc` store state tree |
| 158 | +- `PruneIbcStore`: The `key` field is tracked by persistence and marked for removal in the `ibc` store state tree |
159 | 159 |
|
160 | 160 | ### State Transition |
161 | 161 |
|
162 | | -When the new state hash is computed, the different state trees read the updates from their respective Postgres tables and update the trees accordingly. For each entry in the `ibc_message` table depending on the entries `value` field the tree will perform one of two operations: |
163 | | - |
164 | | -- `value == nil` |
165 | | - - This is a `PruneIbcStore` message and thus the tree will delete the entry with the given `key` |
166 | | - - `ibcTree.Delete(key)` |
167 | | -- `value != nil` |
168 | | - - This is an `UpdateIbcStore` message and thus the tree will update the entry with the given `key` to have the given `value` |
169 | | - - `ibcTree.Update(key, value)` |
170 | | - |
171 | | -The new root hash of the IBC store tree is then included in the `rootTree` and the new state hash is computed, ensuring the IBC store's state is consistent across the network. |
| 162 | +See: [PROTOCOL_STATE_HASH.md](../../persistence/docs/PROTOCOL_STATE_HASH.md#ibc-state-tree) for more information on how the persistence module uses the data it has tracked from the `IbcMessage` objects, in order to update the actual state trees and in turn the root hash. |
172 | 163 |
|
173 | 164 | [ics24]: https://github.com/cosmos/ibc/blob/main/spec/core/ics-024-host-requirements/README.md |
174 | 165 | [ics20]: https://github.com/cosmos/ibc/blob/main/spec/app/ics-020-fungible-token-transfer/README.md |
|
0 commit comments