What's in a Hub?

[ebuchman]

So what’s in a hub? A hub is not the kingdom, but the port city. It’s not the central bank, but the clearing house. It’s not the ISP, but the exchange point. It’s not the airline, but the airport. A good hub is not a ruling dictator, but a servant leader. The Cosmos Hub is uniquely positioned to play this role among the burgeoning ocean of blockchains in need of them, and to do so under the governance and security of bonded ATOM.

There's been a bunch of brain storming recently on roadmap for the Hub and how to establish a framework on what even belongs in the Hub, and what makes sense as far as new forms of utility for ATOM. I'm working with others (@hxrts especially) on some writing along these lines, which is very much a WIP, and we've been discussing a larger Gaia white paper effort led by @shahankhatch. But in the spirit of getting things out of google docs and siloed channels onto github, here's a brain dump of some thinking and writing so far around how to structure what goes in a hub in high level categories, and some notes for each category. Some of it already has prose, some is just point form. A number of these pieces are also being tracked roughly as cards in the Gaia Roadmap Project Board. We hope to see more clear project management on all of this come together over the coming weeks/months!

** This is all very WIP and may change considerably. **

What's in a Hub?

One way to think about what belongs on the Hub is to decompose it first into two broad categories: (1) Security and Scalability and (2) Services Marketplace. Security and Scalability is about making the Hub an ideal place to custody and manage cryptocurrency assets and organizations (“a great city to live”). Services Marketplace is about making the Hub a premier substrate for inter-chain economics (“a port city, a great city to launch from or be routed through”).

We can further decompose these broad categories into key sub-categories:

Security and Scalability:

• Account System - account management, permissioning, UX
• Shared Security - cross-chain validation, rollups
• Political Economics - governance, staking, fees
• Oracles - data, prices, randomness, time

Service Marketplace:

• Service Discovery - addressing, routing, validator set formation
• Capital formation - fundraising, liquidity, exchange, M&A
• Contracting - advanced IBC apps, Intra-chain + cross-chain coordination / contracting

We want the Hub to be a high utility environment that delights users. But we don't want it to be a kitchen sink. We're looking for the right balance - a sort of practical Hub minimalism, if you will. But with things like shared security we can greatly expand the scope of functionality secured by ATOM even while keeping the actual Hub features minimal.

Note that the ATOM2021 initiative by @zmanian largely falls under the "Capital Formation" section here, and is obviously a key component.

We take up these categories in turn.

Account System

The account system is at the heart of any blockchain’s user experience. The current account system is modelled after Ethereum user accounts, but with native support for multisig. With Stargate, accounts will also have native support for vesting schedules, and for multiple token denominations, where tokens can be created by any blockchain or solo machine that connects over IBC.

While the current system is a solid foundation, it could benefit from a number of new capabilities that ultimately improve security and UX. These are primarily related to what might be called “internal controls” at companies. Some features that are under development and which should ship to the hub include :

• x/authz, authorizing an account to perform certain transactions on behalf of another account
• x/feegrant, authorizing an account to source fee payments from another account (so they can transact without first having coins, a major UX hurdle)
• x/group, generalized multi-sig with weighted dynamic membership

Together these features will improve the ability to use accounts on the Cosmos Hub in real world conditions, for asset and permissions management.

But these are just table stakes for improving the account system. More compelling is the “Interchain Accounts” IBC application (ICS27), which will allow accounts on the Cosmos Hub to send transactions on any blockchain connected over IBC, without leaving the Hub. This will help grow the Hub’s network effect as it becomes a central and secure place to custody assets and manage activity in the interchain.

These features are on the immediate horizon, especially Interchain Accounts, as they significantly improve the UX and utility of the Hub in the short term. There will no doubt be other improvements to the account system, but they should be contemplated as strong needs arise for them.

TODO: Possible limited scope WASM for improved multisig/groups?

Shared Security

The ATOM token secures one of the highest market-cap and most decentralized staking systems in the form of the Cosmos Hub. And the exploding market of Proof of Stake validators were largely trained and onboarded through Cosmos technology. Indeed, >15 Cosmos-SDK main nets exist with non-mutually-exclusive validator sets.

There is significant potential for the security of the staked ATOM to secure more than just the Cosmos Hub. While there are many, many features and blockchain applications we may want available within the security of the Cosmos Hub, it may not make sense, for many reasons, for them all to be literally deployed on the Hub itself. For instance, we might want to scale the Hub to support a number of smart contract solutions, but without compromising the integrity of the Hub itself. Shared Security offers a route for us to do this.

Shared security on the Hub must be an opt-in system, where staked ATOM holders can choose to allocate some fraction of their ATOMs to the bonded security of other chains. Just like staked ATOMs determine the validator set on the Hub, the staked ATOMs allocated towards shared security determine the validator sets of the specific chains they are allocated towards. We call this form of shared-security “Cross Chain Validation”, and the chains being validated using the security of the Hub are called “Child Chains”.

ATOMs staked for Cross Chain Validation are at risk of slashing if the corresponding validator misbehaves on the child chain, and otherwise earn rewards from the child chain, in the form of inflation of its native token and fees.

There is a rich design space to explore here. Work is progressing on the core distributed systems problem, but there is still a lot to sort out on the economics. How does stake on the Hub translate to voting power on the child chains? Does it change over time (eg. using a bonding curve)? What are the slashing ratios? How are fees distributed? And so on.

Shared security also offers a new model for economic alignment between chains. A chain that was once independent of the Hub may decide to start sourcing some or all of its security from staked ATOM. This creates a new sense of “investment” in and “acquisition” of one chain by another. The Yearn ecosystem seems to be doing some cool stuff on this front we can learn from.

The security of these solutions can be improved further by integrating optimistic or zero-knowledge rollup techniques to scale the functionality of the Hub. While some form of shared security is likely to be the first priority, we can expect the Hub to adopt the most practical and useful technologies for scaling its security across more key functionality without compromising the base chain.

Political Economics

• Governance and staking improvements
• Governance RFP
• Proportional slashing? Proof of Engagement?
• Epoch based staking
• Increasing the validator set size (aggregate signatures?).
• Burner chains - mix of governance and shared security.
• Community pool improvements.
• More control theory in the inflation rate/staking rate.
• Possible limited scope WASM for improved governance/staking contracts?

Oracles

• Tendermint vote extensions (ABCI++) unlock ability for validators to run oracles.
• Validators already provide a time oracle
• Threshold/Aggregate signatures can give us randomness oracle
• Could also add key off-chain data and price oracles (eg. ATOM/USD). What else?
• Some kind of auction or quadratic funding mechanism to get validators to operate certain oracles?
• They may operate some for free for everyone’s benefit, like a randomness oracle and the ATOM/USD price, but others can be payed for. Special role for ATOM in payment?
• Once oracle is provided, it can be used for free by any chain, even if its not connected to the hub (just needs one way proofs), but likely IBC extensions can be built to leverage price feed info in cross-chain contracts

Service Discovery

• Generalized naming registry for validators and chains - Working on already through the Chain Registry stuff and Starport
  • Some combination of auctions and governance votes?
  • Special role for ATOMs ?
• Service discovery for full nodes and light clients.
• Service discovery for functionality on other chains. Eg. what can you do with your Interchain Account?
• Multi-hop channels. Various kinds of routing (eg. for liquidity, what else?)
• Discover what’s going on on other chains. “Internal” oracles.
• Validator set formation - find validators to launch a chain. With or without shared security

Capital Formation

• AMM exchange for all tokens. Fees collect to LPs and to staked ATOM
  • Any other benefits to ATOM markets?
  • IBC-extensions to support the AMM ? Can two interchain accounts from other chains trade through the hub ?
• Bridges to ETH and BTC. First independent chains. Then merged into the hub (?)
• IBC clients for other L1 chains. Possible case for limited scope WASM.
• Staking derivatives to provide atom liquidity and platform for ATOM-based finance
  • First provide a simple and composable base primitive to compete with liquid staking offered by exchanges - threat to security and decentralization
  • Then evolve towards more general purpose platform for ATOM-based finance
• Fundraising for new tokens and genesis file formation for launching chains, getting relayers
  • Bonding curve based?
  • Possible benefits to using ATOMs ?

Contracting and IBC Extensions

• Contracts - enforcing logic across chains, eg. atomicity, locking, exchange etc to be built on IBC
  • Limited scope WASM ?
  • Some other DSL ?
  • Role for Agoric ?
• Currently hub enforces token invariants in ICS20. Hub can enforce other cross-chain invariants in new IBC extensions.
• NFT standards. Other kinds of token standards ?

[Hyung-bharvest]

Hub oracle can become the oracle of oracles. IBC and other pegs allow the hub to aggregate and verify oracle data from different blockchains. Interchain oracle aggregator & provider