-
Notifications
You must be signed in to change notification settings - Fork 579
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: make 09-localhost stateless #6683
Changes from 12 commits
614fb22
952423f
cc1fa35
fe6519f
249518b
251825d
465a80c
bb92f22
93082f5
0847cbe
f573061
84c3236
ec25710
c207393
8321f41
c58f93a
261231e
58ca2d9
ab99084
61f8ea6
79b809f
c107950
fdd7806
a66ccff
6028aa0
e00c792
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,33 +14,44 @@ | |
Learn about the 09-localhost light client module. | ||
::: | ||
|
||
The 09-localhost light client module implements a localhost loopback client with the ability to send and receive IBC packets to and from the same state machine. | ||
The 09-localhost light client module implements a stateless localhost loopback client with the ability to send and | ||
receive IBC packets to and from the same state machine. | ||
|
||
### Context | ||
|
||
In a multichain environment, application developers will be used to developing cross-chain applications through IBC. From their point of view, whether or not they are interacting with multiple modules on the same chain or on different chains should not matter. The localhost client module enables a unified interface to interact with different applications on a single chain, using the familiar IBC application layer semantics. | ||
In a multichain environment, application developers will be used to developing cross-chain applications through IBC. | ||
From their point of view, whether or not they are interacting with multiple modules on the same chain or on different | ||
chains should not matter. The localhost client module enables a unified interface to interact with different | ||
applications on a single chain, using the familiar IBC application layer semantics. | ||
|
||
### Implementation | ||
|
||
There exists a [single sentinel `ClientState`](03-client-state.md) instance with the client identifier `09-localhost`. | ||
There exists a [single sentinel `ClientState`](03-client-state.md) with the client identifier `09-localhost`. The light | ||
client is stateless, so the `ClientState` is constructed on demand when required. | ||
|
||
To supplement this, a [sentinel `ConnectionEnd` is stored in core IBC](04-connection.md) state with the connection identifier `connection-localhost`. This enables IBC applications to create channels directly on top of the sentinel connection which leverage the 09-localhost loopback functionality. | ||
To supplement this, a [sentinel `ConnectionEnd` is stored in core IBC](04-connection.md) state with the connection | ||
identifier `connection-localhost`. This enables IBC applications to create channels directly on top of the sentinel | ||
connection which leverage the 09-localhost loopback functionality. | ||
|
||
[State verification](05-state-verification.md) for channel state in handshakes or processing packets is reduced in complexity, the `09-localhost` client can simply compare bytes stored under the standardized key paths. | ||
[State verification](05-state-verification.md) for channel state in handshakes or processing packets is reduced in | ||
complexity, the `09-localhost` client can simply compare bytes stored under the standardized key paths. | ||
|
||
### Localhost vs *regular* client | ||
|
||
The localhost client aims to provide a unified approach to interacting with applications on a single chain, as the IBC application layer provides for cross-chain interactions. To achieve this unified interface though, there are a number of differences under the hood compared to a 'regular' IBC client (excluding `06-solomachine` and `09-localhost` itself). | ||
The localhost client aims to provide a unified approach to interacting with applications on a single chain, as the IBC | ||
application layer provides for cross-chain interactions. To achieve this unified interface though, there are a number of | ||
differences under the hood compared to a 'regular' IBC client (excluding `06-solomachine` and `09-localhost` itself). | ||
|
||
The table below lists some important differences: | ||
|
||
| | Regular client | Localhost | | ||
| -------------------------------------------- | --------------------------------------------------------------------------- | --------- | | ||
| Number of clients | Many instances of a client *type* corresponding to different counterparties | A single sentinel client with the client identifier `09-localhost`| | ||
| Client creation | Relayer (permissionless) | `ClientState` is instantiated in the `InitGenesis` handler of the 02-client submodule in core IBC | | ||
| Client updates | Relayer submits headers using `MsgUpdateClient` | Latest height is updated periodically through the ABCI [`BeginBlock`](https://docs.cosmos.network/v0.47/building-modules/beginblock-endblock) interface of the 02-client submodule in core IBC | | ||
| Number of connections | Many connections, 1 (or more) per client | A single sentinel connection with the connection identifier `connection-localhost` | | ||
| Connection creation | Connection handshake, provided underlying client | Sentinel `ConnectionEnd` is created and set in store in the `InitGenesis` handler of the 03-connection submodule in core IBC | | ||
| Counterparty | Underlying client, representing another chain | Client with identifier `09-localhost` in same chain | | ||
| `VerifyMembership` and `VerifyNonMembership` | Performs proof verification using consensus state roots | Performs state verification using key-value lookups in the core IBC store | | ||
| Integration | Expected to register codec types using the `AppModuleBasic` interface | Registers codec types within the core IBC module | | ||
| | Regular client | Localhost | | ||
|----------------------------------------------|-----------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------| | ||
| Number of clients | Many instances of a client *type* corresponding to different counterparties | A single sentinel client with the client identifier `09-localhost` | | ||
| Client creation | Relayer (permissionless) | Implicitly made available by the 02-client submodule in core IBC | | ||
| Client updates | Relayer submits headers using `MsgUpdateClient` | No client updates are required as the `ClientState` is constructed with the latest height when queried | | ||
| Number of connections | Many connections, 1 (or more) per client | A single sentinel connection with the connection identifier `connection-localhost` | | ||
| Connection creation | Connection handshake, provided underlying client | Sentinel `ConnectionEnd` is created and set in store in the `InitGenesis` handler of the 03-connection submodule in core IBC | | ||
| Counterparty | Underlying client, representing another chain | Client with identifier `09-localhost` in same chain | | ||
| `VerifyMembership` and `VerifyNonMembership` | Performs proof verification using consensus state roots | Performs state verification using key-value lookups in the core IBC store | | ||
| Integration | Expected to register codec types using the `AppModuleBasic` interface | Registers codec types within the core IBC module | | ||
| `ClientState` storage | `ClientState` stored and directly provable with `VerifyMembership` | Stateless, so `ClientState` is not provable directly with `VerifyMembership` | | ||
Check failure on line 57 in docs/docs/03-light-clients/02-localhost/01-overview.md GitHub Actions / lintFiles should end with a single newline character
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -119,26 +119,11 @@ func (suite *KeeperTestSuite) TestQueryClientStates() { | |
{ | ||
"empty pagination", | ||
func() { | ||
localhost := types.NewIdentifiedClientState(exported.LocalhostClientID, suite.chainA.GetClientState(exported.LocalhostClientID)) | ||
expClientStates = types.IdentifiedClientStates{localhost} | ||
expClientStates = nil | ||
req = &types.QueryClientStatesRequest{} | ||
}, | ||
true, | ||
}, | ||
{ | ||
"success, only localhost", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. grpc should no longer return localhost in its query. There's no information to obtain, as it would just return back the height of the request There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. that makes sense! |
||
func() { | ||
localhost := types.NewIdentifiedClientState(exported.LocalhostClientID, suite.chainA.GetClientState(exported.LocalhostClientID)) | ||
expClientStates = types.IdentifiedClientStates{localhost} | ||
req = &types.QueryClientStatesRequest{ | ||
Pagination: &query.PageRequest{ | ||
Limit: 3, | ||
CountTotal: true, | ||
}, | ||
} | ||
}, | ||
true, | ||
}, | ||
{ | ||
"success", | ||
func() { | ||
|
@@ -151,12 +136,11 @@ func (suite *KeeperTestSuite) TestQueryClientStates() { | |
clientStateA1 := path1.EndpointA.GetClientState() | ||
clientStateA2 := path2.EndpointA.GetClientState() | ||
|
||
localhost := types.NewIdentifiedClientState(exported.LocalhostClientID, suite.chainA.GetClientState(exported.LocalhostClientID)) | ||
idcs := types.NewIdentifiedClientState(path1.EndpointA.ClientID, clientStateA1) | ||
idcs2 := types.NewIdentifiedClientState(path2.EndpointA.ClientID, clientStateA2) | ||
|
||
// order is sorted by client id | ||
expClientStates = types.IdentifiedClientStates{localhost, idcs, idcs2}.Sort() | ||
expClientStates = types.IdentifiedClientStates{idcs, idcs2}.Sort() | ||
req = &types.QueryClientStatesRequest{ | ||
Pagination: &query.PageRequest{ | ||
Limit: 20, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unsure if we want to delete this file, but left for now