Hyung-bharvest
commented
3 years ago 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
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:
Service Marketplace:
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 accountx/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 membershipTogether 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
Oracles
Service Discovery
Capital Formation
Contracting and IBC Extensions