-
Notifications
You must be signed in to change notification settings - Fork 382
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
ICS ?: Interchain account #251
Comments
TL;DR great idea, but maybe in cosmos-sdk repo? I agree highly with the motivation. And think it is very important to have a way to have an account controlled by another chain to allow lots of flexibility and many use cases (as mentioned above). My feeling is that the current ICS spec enables exactly what you are requesting, and the execution of it depends on implementing a module on the relevant chains (which are not all cosmos-sdk based). In particular, it will be a small subset of chains that share the actual same tx data structure encoding (even among sdk-based chains, they only share the core modules, the additional modules are chain-specific). I don't know where the proper place is for ICS implementation details is. Maybe this is? Maybe in the cosmos-sdk repo? My question is: what here needs to be specified in the general level so that it is the same in all implementations? and what is a nice feature to add to implementations? |
#44 and #211 are similar ideas. And, this idea is different from the previous one. The previous one describes the ways to communicate with other chains sharing the same interfaces. But, this idea describes the ways to communicate with other chains not sharing the same interfaces but having each chain decode their own specified bytes. I think there is a tradeoff between them. The former approach enables each chain to communicate with a more general way, but it might make implementation more complex. In this case, we need to define the encoding/decoding spec and interfaces related to what functions will be executed and how their args will be passed such as function signature. But, it is fairly hard to share the same interfaces with other chains that have different architecture and they should implement these interfaces for each feature. But, the latter approach makes each chain define their interface and have them decode bytes and execute them. It makes the spec more easy, but each chain should know how counterparty chain defines the interface and how to make bytes for its interface. If they are made with the same framework such as cosmos-sdk, they might share some core modules such as bank, staking. So, it can communicate in a general way between them. And if the framework used when the chain was created supports the module and router system like cosmos-sdk, it can be easy to implement such system. In the case that chains that use a different framework, they should know how they define the architecture and how they are decoded and implement the ways counterparty chain defines the interface to communicate. But in my opinion, the former approach is not different from "ics-020-fungible-token-transfer" spec in primitive point. Even though there is a sharing interface, we should define what function signature and args are needed for each module. Isn't it similar with the ways to implement specs for bank module "ics-?-fungible-token-trasnfor-for-interchain-account" and specs for gov module "ics-?-vote-for-interchain-account" or "ics-?-submit-proposal-for-interchain-account"? I wanted to make the most flexible and minimal way to communicate to manage accounts by other chains. In the latter approach define the primitive interface to send arbitrary bytes to be decoded and executed. If developers use the framework that supports module and router system and implements this spec, they can make their module that is able to be managed by interchain account without defining and implementing specs. I think this is an important part of this specification. @ethanfrey I wrote the difference between the previous one and this and my thought about why I modified approach. Could you read and respond if you are interested in this topic. |
Notes, by section:
General feedback:
|
@Thunnini Thank you for the explanation. I understand better now. I also now see that it fits in with other such ics app-level specs. I see this I like this idea. I also wonder about the idea of multiple such accounts (like many investment DAOs on one chain, each with own governance to control their staking on hub, or assets on DEX). However, that is an extension of this topic, and let us get this one clearly designed first. It seems that you use a nonce/salt on connection to allow a given chain-port combo to have different addresses on each connection. I assume the intention to allow different connections to have different addresses is to allow such a multi-DAO setup, each with their own connection? Is that correct or can you explain better? The one pseudo-code comment is that this salt is in Besides that and the points Chris made (esp. 3(vi) stood out when I read the code), the rest looks quite nice. |
I recently found that there exists a structure called "module account" in sdk. Until now, those accounts are controlled only by internal modules in sdk. I think what @Thunnini is trying to achieve is a generalization of this "module account" so that, the controlling entity can be exterior entity of the hub blockchain. I think this discussion should be well aligned with existing module account design. |
@cwgoes
|
@ethanfrey I think that Chain B can know the address to be made prior to sending So, basic process might be that Chain B calculates expected address to be created on Chain A and stores the information. Then, Chain B waits for the result (acknowledgement) packet from chain A, then stores the information that the same address has been successfully created on Chain A from the result packet that is sent back. If result packet says the account creation failed, Chain B may retry by registering an interchain account address with a different salt. And, chain B will use the stored address as signer to request transaction via IBC according to their protocol. On 3(vi), looks like I've made a mistake 😅 |
Closing as the initial version of this has been merged. Thanks again! |
Interchain account (draft)
I made some revisions to the proposal to include more specificities regarding the proposal #211 .
In summary, here are the core changes:
Revised the naming from "IBC managed account" to "Interchain account".
Added a rough concept for determining interchain account's address.
Revised so that the IBC packet includes the transaction raw bytes for the receiving chain. The receiving chain must decode these bytes to a transaction, then check that the sending chain has correct permission. If the sending chain has the correct permission, the receiving chain will execute the transaction. Finally, the receiving chain will return result packet to the sending chain.
Some use cases I can see with the implementation of the interchain account are as follows:
ics: (?)
title: (Interchain account)
stage: (Strawman)
category: (ibc-app)
author: (yunjh1994@ellipti.io)
created: (2019-08-21)
modified: (2019-08-21)
Synopsis
This standard document specifies packet data structure, state machine handling logic, and encoding details for the account management system over an IBC channel between separate chains.
Motivation
On Ethereum, there are two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract code [ref]. Similar to Ethereum's CA(contract accounts), Interchain accounts are managed by another chain(zone) while retaining all the capabilities of a normal account (i.e. stake, send, vote, etc). While an Ethereum CA's contract logic is performed within Ethereum's EVM, Interchain accounts are managed by another chain via IBC in a trustless way.
Definitions
The IBC handler interface & IBC relayer module interface are as defined in ICS 25 and ICS 26, respectively.
Desired Properties
Technical Specification
Data Structures
RegisterIBCAccountPacketData
is used for counterparty chain to register an account. Interchain account's address is defined deterministically with channel path and salt. Process of determining address is influenced by EIP-1014. It allows interactions to be made with addresses that do not exist yet on-chain. These specificities will allow more offchain services to build on top of the data structure.ResultRegisterPacketData
is used to let counterparty chain know if the account was created successfully.RunTxPacketData
is used to run tx for interchain account. Tx bytes is dependent on app, and it is formed with minimal data set except data for validating signatures.Subprotocols
The subprotocols described herein should be implemented in a "interchain-account-bridge" module with access to a router and codec (decoder or unmarshaller) for app and to the IBC relayer module.
Port & channel setup
The
setup
function must be called exactly once when the module is created (perhaps when the blockchain itself is initialized) to bind to the appropriate port and create an escrow address (owned by the module).Once the
setup
function has been called, channels can be created through the IBC relayer module between instances of the interchain account module on separate chains.Relayer module callbacks
Channel lifecycle management
Both machines
A
andB
accept new channels from any module on another machine, if and only if:Packet relay
In plain English, between chains
A
andB
. It will describe only the case that chain A wants to register an Interchain account on chain B and control it. Moreover, this system can also be applied the other way around. In these set of examples, we follow Cosmos-SDK's modularity rule and itsmsg
system.Backwards Compatibility
(discussion of compatibility or lack thereof with previous standards)
Forwards Compatibility
(discussion of compatibility or lack thereof with expected future standards)
Example Implementation
(link to or description of concrete example implementation)
Other Implementations
(links to or descriptions of other implementations)
History
(changelog and notable inspirations / references)
Copyright
All content herein is licensed under Apache 2.0.
The text was updated successfully, but these errors were encountered: