In this post, I give two recommendations to the Cosmos ecosystem:
- A CLI script to easily deploy a new app chain
- A novel fee market for interchain security
Where Is Everyone?
After the Terra de-peg, I put my Terra EVM project on pause. I was thinking about where to build next, and I found I have issues with almost every ecosystem:
- Ethereum is incredibly slow at 15 TPS
- Solana has known stability issues
- Cosmos has low TVL ($600m) and the activity is dwarfed by Ethereum
But I like Cosmos the best architecturally. The app chain thesis has been vindicated with the recent deployment of dYdX, an indictment of the theory that everything would soon become an Ethereum rollup. There are several advantages of making a Cosmos app chain vs. a dApp elsewhere:
- Tendermint has formally verified liveness.
- If a serious error occurs, your governance can vote to roll back the chain or take remedial action. This isn't possible if a tragedy happens on a chain like Ethereum, such as the $30m Parity multisig hack.
- There is no congestion or competition for block space between other dApps.
- With ABCI, you can theoretically use whatever language you want.
- App chains avoid state bloat, which every monolithic L1 will have to deal with.
So it begs the question: Why isn't everyone deploying as a Cosmos app chain? Moreover, why do people still prefer deploying their dApps as smart contracts to general-purpose chains?
The Status Quo
It's too complicated to launch an app chain.
For a developer who codes Solidity dApps, now you must learn about Tendermint, ABCI, and the Cosmos SDK. Even with the help of Ignite CLI, just to instantiate a "Hello World" application, we need to modify protocol buffers and learn about Keeper. And deploying to production is a beast of its own: there is no ignite deploy command.
You can't bootstrap a validator set.
After implementing your app with the Cosmos SDK and launching your chain, now you need to bootstrap your validator set. The difficulty here is that no one wants to validate for a token with no known economic value.
The current proposal for interchain security: you basically apply for interchain security, and the governance for the "provider chain" votes on whether they want to validate for you. $ATOM delegators and validators are rewarded via additional fees from your chain via the distribution module.
What's good about the current proposal is that it creates a use case for $ATOM. $ATOM certainly needs use cases beyond governance. Some issues:
- Security: Security for your chain is actually better if you use your own token. You can simply hold a large percentage of tokens yourself and make an attack prohibitively expensive or impossible.
- Flexibility: Once interchain security is turned on for a chain, an individual validator cannot opt out. They're stuck validating for this new chain. (I've been told ICS v2 will allow individual validators to opt in or out.)
- Resource efficiency: Some consumer chains are resource-intensive to validate, and some validator nodes have greater resources than others. Since all validators from the provider chain must now validate for the consumer chain, we fail to capture this property.
- Startup time: A governance vote takes time to process.
The Alternate Proposal
Simplify launching an app chain.
The first step is to greatly simplify the process of deploying an app chain with a script. It has to be as easy as deploying a Solidity smart contract to Ethereum, similar to what Informal is describing with their CLI tool.
Make a fee market for interchain security.
We can solve the issues with the current interchain security proposal by making it a market, creating an even better use case for $ATOM, although theoretically this works for any token.
From a validator's perspective, you make an ask of the form: "In exchange for you bonding $x of $ATOM to me, I will provide 1 validator on your app chain."
For a consumer chain that needs interchain security, the bid structure is more interesting. I would model the problem as each consumer chain requiring \(k_{c}\) validators, and they are willing to pay any price to get them (inelastic demand). In this case, what should be the price for each validator?
The competitive market structure here is a uniform clearing-price (UCP) auction. We order the validators from cheapest to most expensive, and if there is demand for \(k^{*}\) total validators, then the price that the \(k^{*}\)'th validator offered is the price for all validators. This market structure incentivizes validators to make their ask price as low as possible, and it enables orders to be filled quickly.
We could modify the structure to allow consumer chains to include a bid price: "In exchange for $x of $ATOM, you will serve as a validator for my app chain." This scheme allows validators and consumer chains to place orders consistent with their resource specifications. The market clearing price for validators is simply where the supply and demand curves intersect. The result is something like a decentralized Amazon Web Services for validators to provide app-specific compute.
When you think your token has enough economic value to get your own validator set, you can simply unbond your $ATOM, and your old validators will fill the next orders placed to the fee market consistent with their ask. As the fee market becomes more popular, we might include a devops environment for validators to quickly spin up new nodes for networks without eventual resource starvation.
Who's In Charge?
Where would we run a fee market like this? The most natural option might be the Hub itself, but dApps like Gravity Bridge and Gravity DEX have proven to be controversial. The right answer might be a dedicated chain that supports a central limit order book.
I wanted to keep this post short, but I am interested to hear the Cosmos community's thoughts. Let me know what you think on Twitter @neelsalami or email at neeljaysomani [at] gmail.com.
