Cosmos Hub as Universal Wallet
I came into the blockchain space primarily as a front end developer. I quickly learned enough Solidity to build a series of hackathon projects and prototypes on Ethereum, but my background made me acutely aware of how difficult it was for users to interact with Dapps.
https://twitter.com/_iiwok/status/1017847582565863424/photo/1
Effective password management is already difficult within traditional applications, effective private key management for decentralized applications is basically impossibleāthe number of hacks, thefts and losses due to compromised private keys increases every day. Projects like Gnosis Safe and Argent have done a massive amount to reproduce capabilities on par with traditional applications, but their ability to function outside the context of mainnet Ethereum is extremely limiting.
Iād like to describe a method for improving private key management thatās not just at parity with the experience of traditional account management, but actually makes it easier and safer. Furthermore this new method supports access to a whole Internet of Blockchains instead of just one network. The key to this scenario is a combination of two important technological developments that if deployed on the Cosmos Hub would bring a modern safe and slick user experience to all applications connected via IBC.
The two technologies Iām referring to are Interchain Accounts and Sub-Keys.
Interchain Accounts
Interchain Accounts is an application level feature of the Inter-Blockchain Communication (IBC) protocol that allows blockchains to act in a way thatās similar to how contracts work in the Ethereum Virtual Machine (EVM). Thereās a saying that āOn a blockchain no one knows youāre a robotā, which is to say that contracts and users look very similar. Notably, they can both hold token balances and trigger state update functions within other EVM contracts.
In the context of an IBC connected Internet of Blockchains, the saying changes to āOn the Interchain, no one knows youāre a blockchainā since Interchain Accounts allow a blockchain to own and control one or more accounts on another blockchain, enabling them to hold balances of tokens and trigger state update functions within those new settings. (For a more technical dive into Interchain Accounts check out @dogemosās article here)
One application of this looks something like a Decentralized Autonomous Organization (DAO) account. In this scenario a new network is created with itās own staking / governance token. It connects to the Cosmos Hub via IBC and generates a new Account on the hub that represents the entire external DAO chain. This DAO chain collectively acquires ATOMs which are collectively held on this new Account. Back on the actual DAO chain, the governance module is used to collectively vote on creating a delegation transaction for the Cosmos Hub that allows the DAO chain to earn staking rewards with their collective ATOMs. This opens up the DAO chain to create staking derivatives, which represent the locked ATOMs on the hub but remain transferrable. That enables the staking derivatives to be used as collateral in another DeFi application. Interchain accounts provide a flexible framework where these DAO tokens can be pooled together to create additional liquidity, or even have the DAO blockchain itself create internal liquidity pools.
But the application of Interchain Accounts that I am even more excited about is enabled by the Cosmos Hub adopting the standard natively. If ICS 27 is added to the Hub, then we would be able to use personal accounts on the Cosmos Hub to create outgoing transactions destined to be executed on other external blockchains. This would allow us to use a single account as the surrogate for all the blockchains connected via IBC. Weād no longer need to juggle a series of wallets and private keys associated with various accounts across applications and networks. Weād be able to use the same entry point no matter where we wanted to interact across all IBC-connected applications. Just tell the Cosmos Hub that you want to create an outgoing transaction that contains some Message destined for another IBC enabled network. This message gets generated with IBC and relayed to the connected network to be processed on behalf of your Cosmos Hub account.
This drastically simplifies one aspect of the private key user experience, reducing your account management to an interface with just one network, while still allowing you to transact on any number of networks. However putting that much value into just one key creates a new problem, a higher burden on private key security. Fortunately, this problem can be remedied by a second, forthcoming technology: Sub-Keys.
Sub-Keys
This concept is similar to contract based accounts, like those within the Gnosis Safe and Argent Wallet, where smart contracts are allowed to control the creation and execution of transactions on behalf of an account. This technology allows really cool features like 2FA, daily limits, and account recovery in the case of lost or stolen private keys. However, these features only work within the state machine in which the contract has been deployed (mainnet Ethereum in their case).
Sub-Keys is an in-development feature for the Cosmos SDK that allows an account to be associated with more than one key, each with different capabilities. This is in contrast to the current model, where accounts have a single private key that executes all transactions on behalf of that account. For instance, Sub-Keys would allow me to generate one key pair that can only spend $100 per day.Two such keys would then be necessary, Ć la 2FA, to spend amounts over $100 a day. This feature could also allow some threshold number of keys in order to add, edit, or remove the abilities of any other keys that already exist.
One feature of Sub-Keys that I really like is that it allows for a much more frequent key rotation. This mimics common security recommendations seen in more traditional cyber security industries. If a key only exists long enough to be used once, it greatly reduces the chances of getting re-used by an attacker.
When it comes to actual private key storage, youāre able to rely on a variety of strategies in combination with each other and mitigate the risk of single points of failure. Various keys can be stored in custodial, semi-custodial, or fully trustless scenarios which allow the security threshold provided by each situation to reflect the security requirements of each keyādepending on the capabilities of that key and frequency of rotation.
One concrete scenario that makes sense to me is to have a series of low-security keys stored on my phone and in my browser. A series of keys used for high-security operations like account recovery and key management. These could be held in a combination of institutional custodians like my bank, google, or facebook, a few personal custodians like my parents, my siblings or my partner as well as a few non-custodial solutions like hardware wallets or other cold storage solutions. Similar to 2fa, the capability to perform these high-security operations would require signatures from four out of six existing keys, or maybe some lower threshold for medium security transactions.
I expect that the primary interfaces for applications will be largely created by the app developers themselves. When it comes time to execute transactions, the application might offload the coordination of the signing solutions to a third party app wallet coordinator that might use something like WalletConnect to make the large variety of key storage solutions easily available.
By wallet coordinator, I mean an application that keeps track of all the various PK storage destinations, as well as the capabilities associated with all of these keys. When receiving a request to interact with a chain it would receive with that request information about the msg type itself. This would allow the wallet coordinator to craft the relevant transaction, signed by the relevant key(s), and submit the transaction to the Cosmos Hub, where it would be wrapped within an outgoing IBC message and relayed to the destination application chain. This wallet coordinator would be focused on managing the metadata of various Sub-Keys and coordinating their various permissions rather than providing an interface for the actual application that triggered the interaction.
Further Considerations
One of the potential downsides of this whole scenario is that it requires more than one transaction in each situation. The relay transaction can be created and carried out by anyone, so from the user perspective it may still feel like just one operation. Sending the transaction through the Cosmos Hub will require the validators there to accept it. This means it needs to use a fee token that they will accept. Once IBC is enabled, validators will be able to choose to accept fees paid in any denomination. They will keep their own list of accepted denoms and order transactions based on their subjective evaluation of token prices. This means a new application may be able to get the Cosmos Hub leg of their transaction path paid in their native token, but doesnāt guarantee it.
It does however, mean that the value of running a Cosmos Hub validator will increase, as there should be more transactions and therefore more fees coming through. This will increase the security of the Cosmos Hub, as the income received for operating a validator will create demand for ATOMs and the fee revenue claim they guaranteeā¦ The security of the Hub is directly proportional to the value of the ATOM, so using the Hub as a Universal Wallet will have a compounding effect on the security and therefore increases the value of using it as a wallet in the first place.
This whole scenario might also not make sense on the Hub itself, since in general updates to the hub have taken place at a conservative rate. The configuration of features like Sub-Keys and Intechain Accounts might require iterative efforts that would benefit from being deployed as an independent network with lower barriers to upgrades. A network like this would only be as secure as the validator set which becomes problematic if it is securing a large number of valuable assets. When cross-chain validation becomes possible it might be secured by the ATOM itself. A combination of self sovereign iterative development with eventual securitization by the ATOM might be the best path forward.
There are undoubtedly many holes in the scenario described above. I welcome questions, comments, criticisms and suggestions. Iād love to figure out whether this scenario makes sense or not and if it does how we can proceed to support it! Thanks for your time and consideration.