ICS ?: IBC managed account

[Thunnini]

ics: (?)
title: (IBC managed 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 EOA(externally owned accounts), IBC managed 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 EOA's contract logic is performed within Ethereum's EVM, IBC managed 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

• Permissionless
• Fault containment: Managed account must follow rules of its dwelling chain, even in times of byzantine behavior by the counterparty chain (the chain that manages the account)

Technical Specification

Data Structures

RegisterPacketData is used by counterparty chain after the channel is opened. This packet makes an IBC managed account for counterparty chain with specific permissions. IBC managed account's address is defined deterministically with consensus state data.

interface RegisterPacketData {
  permission: string[]
}

MsgTranserAssetWithData is message that transfer assets to IBC managed account(recipient) with payload(data). Data might be consist of informations that are necessary for initializing account on counterparty chain such as recipient address on counterparty chain.

interface MsgTransferAssetWithData { 
  sender: Address
  recipient: Address
  asset: Coins
  data: Uint8Array
}

Subprotocols

The subprotocols described herein should be implemented in a "supply-ibc-bridge" module with access to a supply module and to the IBC relayer module.

(TODO: This should be described by more detail. But my rough idea is to use the supply module. Because the supply module already has a module account system that permits the module to manage assets like a normal account, I think it makes sense to reuse it for IBC managed account 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.

[Thunnini]

I think the advantages of this idea besides token transfers (ics-020) are that this allows other chains to manage a user's asset by (re)delegating, participating in governance, and etc. This system could allow a DeFi zone to integrate cross-chain staking, governance and other functionalities.

[mossid]

This can enable the chains to make transaction fully onchain on another chain without centralized intermediary/representative(e.g. a dao contract on an ethermint chain can (un/re/)delegate on the cosmos hub directly).

Are both RegisterPacketData and MsgTransferAssetWithData the structs that actually stored in the state(packet data)?

Related: #22, #44

[Thunnini]

@mossid The purpose was to ask what you think about this idea, so I haven't written the actual technical specs yet and haven't explained enough.
In my initial idea about technical specs, RegisterPacketData is a packet that is transferred between chains via IBC. And it might be used right after IBC channel is opened in order to register IBC managed account for a chain (zone). I think IBC managed account's address can be determined with consensus state (chain id, ...) deterministically.
MsgTransferAssetWithData is a message, and it would be used for transferring user's assets and ownership. I think users don't prefer to reuse the same private key on multiple chains (hubs, zones), so data (payload) in MsgTransferAssetWithData could be used for determining which address get ownership of these assets on counterparty chain if it is needed.

It seems that this is similar to ICS-21 #44. But I think the main difference is that the main purpose of this proposal is to allow the counterparty chain to do the thing that normal account can do.

I think you can think of replacing Ethereum's EVM and contract accounts with other chain's application logic and IBC managed accounts.

[cwgoes]

I think this probably makes sense as an application-level standard. Ref #44 (the same idea).

edit: just saw the latest comment

It seems that this is similar to ICS-21 #44. But I think the main difference is that the main purpose of this proposal is to allow the counterparty chain to do the thing that normal account can do.

I think #44 also wants that, just with more granular control.

[Thunnini]

@cwgoes I read #44, but I couldn't understand what IBC proof-of-signature or an IBC proof-of-key is. I thought it may be unnecessary because it could be handled by application logic and application logic can know which counterparty chains have privileges.

However, I think this proposal and ICS-21 #44 could be integrated and advanced.

If I am understanding #44 correctly, maybe we could combine #44 features of delegating privileges of an existing account as well this proposal's features that allow a counterparty chain to create its own IBC managed account. This will allow for a more generalized approach in terms of flexibility for each zone's needs.