You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Backport commits from main to v3 release branch (#682)
* reorganize channel handshake handler (#647)
* reorganize channel handshake handler
split out channel state changes into its own function.
* readjust 27-interchain-accounts to not rely on state being set before the application callback
* add changelog and migration doc entry
* Update modules/core/04-channel/keeper/handshake.go
* docs: ICA Overview (#626)
* docs: ica overview
* fix: ordering
* add spacing
* fix: spacing
* fix: remove bulletpoints
* fix: wording
* update go mod for security vulnerabilities (#655)
* update go mod for security vulnerabilities
* update package-lock.json
* update vue dependency (#662)
* bump glob-parent version in json package (#663)
* build(deps): bump actions/setup-go from 2.1.4 to 2.1.5 (#656)
Bumps [actions/setup-go](https://github.com/actions/setup-go) from 2.1.4 to 2.1.5.
- [Release notes](https://github.com/actions/setup-go/releases)
- [Commits](actions/setup-go@v2.1.4...v2.1.5)
---
updated-dependencies:
- dependency-name: actions/setup-go
dependency-type: direct:production
update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: colin axnér <[email protected]>
* docs: begin removal of internal "spec" directories (#634)
* begin removal of spec docs within core ibc
* remove broken link
* Apply suggestions from code review
Co-authored-by: Damian Nolan <[email protected]>
* remove broken link
* remove broken links
* Apply suggestions from code review
Co-authored-by: Carlos Rodriguez <[email protected]>
Co-authored-by: Damian Nolan <[email protected]>
Co-authored-by: Carlos Rodriguez <[email protected]>
* Modify `OnChanOpenTry` application callback to perform app version negotitation (#646)
* remove NegotiateAppVersion and AppVersion gRPC (#643)
The NegotiateAppVersion callback has been removed from the IBC Application interface.
The gRPC AppVersion has been removed.
The app version negoitation will be handled by applications by returning the version in OnChanOpenTry.
* Modify `OnChanOpenTry` to return application version (#650)
* modify OnChanOpenTry to return negotiated version
modify IBCModule interface function OnChanOpenTry to return the negotiated app version. Tests have not been updated
* fix ibc_module_test.go tests
* fix tests
* Apply suggestions from code review
* add handshake test case
* add CHANGELOG and migration docs
* update documentation
* fix broken link
* fix broken link (#664)
* chore: update make build-docs, add docs build checker (#667)
* update Makefile, add docs build checker
* Update .github/workflows/check-docs.yml
Co-authored-by: Marko <[email protected]>
Co-authored-by: Marko <[email protected]>
* register ICA query server, fix panics in params query cli (#666)
Register the controller and host query servers to a chain.
Returns an error upon cli params query failure instead of panicing.
* update of roadmap with latest release (#653)
* update of roadmap with latest release and changed the way release versions are encoded
* fixed typo
Co-authored-by: Carlos Rodriguez <[email protected]>
* build(deps): bump actions/checkout from 2.3.1 to 2.4.0 (#672)
Bumps [actions/checkout](https://github.com/actions/checkout) from 2.3.1 to 2.4.0.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v2.3.1...v2.4.0)
---
updated-dependencies:
- dependency-name: actions/checkout
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* allow ics20 to connect to middleware (#675)
* allow ics20 to connect to middleware
Creates ics4Wrapper which allows middleware applications to only implement SendPacket to connect ics20 as an application in its middleware stack
* add changelog and migration doc
* fix migration doc spelling
* fix: register InterchainAccount as x/auth GenesisAccount (#676)
* adding GenesisAccount interface registration for InterchainAccount impl
* updating RegisterInterfaces ica godoc
* enable mergify for backports (#678)
Co-authored-by: Carlos Rodriguez <[email protected]>
Co-authored-by: Sean King <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Damian Nolan <[email protected]>
Co-authored-by: Carlos Rodriguez <[email protected]>
Co-authored-by: Marko <[email protected]>
Co-authored-by: Carlos Rodriguez <[email protected]>
* (transfer) [\#675](https://github.com/cosmos/ibc-go/pull/675) Transfer `NewKeeper` now takes in an ICS4Wrapper. The ICS4Wrapper may be the IBC Channel Keeper when ICS20 is not used in a middleware stack. The ICS4Wrapper is required for applications wishing to connect middleware to ICS20.
46
+
* (core) [\#650](https://github.com/cosmos/ibc-go/pull/650) Modify `OnChanOpenTry` IBC application module callback to return the negotiated app version. The version passed into the `MsgChanOpenTry` has been deprecated and will be ignored by core IBC.
45
47
* (core) [\#629](https://github.com/cosmos/ibc-go/pull/629) Removes the `GetProofSpecs` from the ClientState interface. This function was previously unused by core IBC.
46
48
* (transfer) [\#517](https://github.com/cosmos/ibc-go/pull/517) Separates the ICS 26 callback functions from `AppModule` into a new type `IBCModule` for ICS 20 transfer.
47
49
* (modules/core/02-client) [\#536](https://github.com/cosmos/ibc-go/pull/536)`GetSelfConsensusState` return type changed from bool to error.
*[\#383](https://github.com/cosmos/ibc-go/pull/383) Adds helper functions for merging and splitting middleware versions from the underlying app version.
55
57
* (modules/core/05-port) [\#288](https://github.com/cosmos/ibc-go/issues/288) Making the 05-port keeper function IsBound public. The IsBound function checks if the provided portID is already binded to a module.
56
58
* (channel) [\#644](https://github.com/cosmos/ibc-go/pull/644) Adds `GetChannelConnection` to the ChannelKeeper. This function returns the connectionID and connection state associated with a channel.
59
+
* (channel) [\647](https://github.com/cosmos/ibc-go/pull/647) Reorganizes channel handshake handling to set channel state after IBC application callbacks.
Copy file name to clipboardexpand all lines: docs/app_modules/interchain-accounts/overview.md
+27
Original file line number
Diff line number
Diff line change
@@ -2,4 +2,31 @@
2
2
order: 1
3
3
-->
4
4
5
+
# Overview
6
+
7
+
Learn about what the Interchain Accounts module is, and how to build custom modules that utilize Interchain Accounts functionality {synopsis}
8
+
9
+
10
+
# What is the Interchain Accounts module?
11
+
12
+
Interchain Accounts is the Cosmos SDK implementation of the ICS-27 protocol, which enables cross-chain account management built upon IBC. Chains using the Interchain Accounts module can programmatically create accounts on other chains and control these accounts via IBC transactions.
13
+
14
+
Interchain Accounts exposes a simple-to-use API which means IBC application developers do not require an in-depth knowledge of the underlying low-level details of IBC or the ICS-27 protocol.
15
+
16
+
Developers looking to build upon Interchain Accounts must write custom logic in their own IBC application module, called authentication modules.
17
+
18
+
- How is an interchain account different than a regular account?
19
+
20
+
Regular accounts use a private key to sign transactions on-chain. Interchain Accounts are instead controlled programmatically by separate chains via IBC transactions. Interchain Accounts are implemented as sub-accounts of the interchain accounts module account.
21
+
22
+
# Concepts
23
+
24
+
*Host Chain*: The chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. cosmos SDK messages) for which the interchain account will execute.
25
+
26
+
*Controller Chain*: The chain registering and controlling an account on a host chain. The controller chain sends IBC packets to the host chain to control the account. A controller chain must have at least one interchain accounts authentication module in order to act as a controller chain.
27
+
28
+
*Authentication Module*: A custom IBC application module on the controller chain that uses the Interchain Accounts module API to build custom logic for the creation & management of interchain accounts. For a controller chain to utilize the interchain accounts module functionality, an authentication module is required.
29
+
30
+
*Interchain Account*: An account on a host chain. An interchain account has all the capabilities of a normal account. However, rather than signing transactions with a private key, a controller chain's authentication module will send IBC packets to the host chain which signals what transactions the interchain account should execute.
Application modules are expected to verify versioning used during the channel handshake procedure.
158
167
159
168
*`ChanOpenInit` callback should verify that the `MsgChanOpenInit.Version` is valid
160
-
*`ChanOpenTry` callback should verify that the `MsgChanOpenTry.Version` is valid and that `MsgChanOpenTry.CounterpartyVersion` is valid.
169
+
*`ChanOpenTry` callback should construct the application version used for both channel ends. If no application version can be constructed, it must return an error.
161
170
*`ChanOpenAck` callback should verify that the `MsgChanOpenAck.CounterpartyVersion` is valid and supported.
162
171
163
-
IBC expects application modules to implement the `NegotiateAppVersion` method from the `IBCModule`
164
-
interface. This method performs application version negotiation and returns the negotiated version.
165
-
If the version cannot be negotiated, an error should be returned.
166
-
167
-
```go
168
-
// NegotiateAppVersion performs application version negotiation given the provided channel ordering, connectionID, portID, counterparty and proposed version.
169
-
// An error is returned if version negotiation cannot be performed. For example, an application module implementing this interface
170
-
// may decide to return an error in the event of the proposed version being incompatible with it's own
171
-
NegotiateAppVersion(
172
-
ctx sdk.Context,
173
-
order channeltypes.Order,
174
-
connectionID string,
175
-
portID string,
176
-
counterparty channeltypes.Counterparty,
177
-
proposedVersion string,
178
-
) (version string, err error) {
179
-
// do custom application version negotiation logic
180
-
}
181
-
```
182
-
183
-
This function `NegotiateAppVersion` returns the version to be used in the `ChanOpenTry` step
184
-
(`MsgChanOpenTry.Version`). The relayer chooses the initial version in the `ChanOpenInit` step
185
-
(this will likely be chosen by the user controlling the relayer or by the application that
186
-
triggers the `ChanOpenInit` step).
187
-
188
-
The version submitted in the `ChanOpenInit` step (`MsgChanOpenInit.Version`) is passed as an
189
-
argument (`proposedVersion`) to the function `NegotiateAppVersion`. This function looks at
190
-
the `proposedVersion` and returns the matching version to be used in the `ChanOpenTry` step.
191
-
Applications can choose to implement this in however fashion they choose.
172
+
IBC expects application modules to perform application version negotiation in `OnChanOpenTry`. The negotiated version
173
+
must be returned to core IBC. If the version cannot be negotiated, an error should be returned.
192
174
193
175
Versions must be strings but can implement any versioning structure. If your application plans to
194
176
have linear releases then semantic versioning is recommended. If your application plans to release
0 commit comments