-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion(cosmoshub
): ICS1 is not an application - it's a functionality-scaling mechanism for the Cosmos Hub
#7
Comments
I am a bit skeptical about ICS1. Does it really solve the scaling problem? Under ICS1, validators run another node for each new consumer chain. Therefore, it is hard to say for sure that this method is scalable, as the total cost for maintaining the infrastructure keeps increasing as more ICS chains are added. This is not enough to make this economic model viable, especially for validators. The viability of this model depends more on how much the consumer chain is willing to pay ATOM stakers than the demand for ICS chains itself. We can't force validators to run more infra if this is not viable for them. I do agree that ICS is not necessarily a long-term value proposition. In my opinion is more a way for consumer chains to bootstrap a validator set easily, grow, and become a sovereign app-chain for the most successful ones, such as what start-up accelerators do, this is in line with the Cosmos thesis. Another issue we should consider is how to manage the minimum inflation bounds to allow the inflation rate to go negative. It would be helpful to have clarification on how it will work if interest rates go negative in terms of sustainability for validators. |
That's part of my thesis too. Simple Replicated Security (ICS1) forces all validators, and there are obvious downsides with that. However, if seen as a functionality-scaling mechanism instead of a hosting mechanism, it can work flawlessly. How many features do you really need to become a strong chain? It's not the same scale as a hosting platform. Also, having several consumer chains that support popular smart contracting platforms already provides huge scaling potential for the Hub functionalities. The model remains the same "virtually" for the Hub (value accrued by ICS transactions) but the difference is in considering the consumer chains of ICS1 as "part" of the Hub, not clients. You would focus on having few super high-quality consumer chains, that the Hub community designed, instead of relying on quantity. Hence why discourse around the Cosmos Hub should focus also on extension features, i.e. consumer chains. Or simply the economic model of the Cosmos Hub will have the risk of failing |
If the economic model works around fees collected through ICS, having negative inflation would be sustainable (as value accrual is really through fees, where validators would find the funds to sustain themselves). The inflation reward is not really where the value is created (or rather accrued). It's a transfer of existing "internal" value from non-stakers to stakers through dilution. So you see that it's not really a sustainable model in and of itself. If Jae's assumption about the Hub becoming economically viable through ICS works (for which I argue there's a missing piece: the killer apps), then negative inflation would actually be beneficial. In the end though, 67% of stake is efficient already and going higher does not really give any benefit (one could argue it is actually not that desirable to have high staking ratio). "Disincentivizing" staking (but ultimately, potentially increasing ATOM price) should actually be a thing IMHO for super high staking ratios. Again assuming there is a working economic model, as the whole thing needs to be sustainable. But that is true for any blockchain isn't it? |
The
cosmoshub
document talks extensively about ICS1 (Simple Replicated Security) and how it can make the Cosmos Hub economic model (revolving around collecting fees from ICS hosted zones) work. While this is true, I actually argue this is not enough to make this economic model viable. In my opinion there is an underlying assumption - that demand for ICS hosting will be high, or that the chains that will do ICS hosting will have lots of transactions - that is actually arguable, and it somewhat contradicts the Cosmos thesis.ICS1 is not VaaS (Validation as a Service) in my opinion, but a neat mechanism to scale functionality of the Hub. It is not an application in and of itself, it's just a scaling mechanism (for the Hub, not Cosmos). It's the gateway to having the cake and eating it too. You scale without losing security (so yes, I agree with the minimal Cosmos Hub thesis). As a ICS1 chain you are giving up sovereignty - or at least, you have autonomy but not independence - so it can't really be seen as a platform for hosting, as this is not really the internet (and for the hosting where you retain autonomy but not independence smart contracts are already perfect and will only get better). Migration in case the Hub decides to kill a zone and this zone wants to survive is not a smooth process, as it could be on the internet if a company has a problem with a cloud provider.
Or at least considering ICS1 as the way to generate profit in and of itself is not a realistic long term value prop in my opinion (but it's a form of usage of ICS1 that totally makes sense) for the Hub. Application layer is what wins, is where the value is captured. Applications will become so big to migrate to their own sovereign realm eventually. This is the Cosmos thesis, and the reason why Cosmos is the better model/design. It enables applications to become fully sovereign, which is what happened on the internet (big internet companies ending up creating their own infrastructure), and what will happen/is happening in blockchain. So again, I argue it is not sustainable in the long run. As a Hub functionality-scaling mechanism though, it's great and sustainable. ICS1 chains should be more seen as a part of the Hub, rather than a customer/third-party. But that means that the Hub itself should focus harder on the killer apps - and use ICS1 as an enabler. Of course they should be well designed and explored properly as if they were features to be implemented on the Hub itself (because in some sense they are).
For example solving the IBC routing problem is a huge component in my opinion in scaling Cosmos and also is potentially a place where I see the Cosmos Hub - using ICS1 - have a role. IBC needs to become profitable though somehow, which afaik it still really isn't. There is work but it's not here yet.
I agree another killer app(s) is smart contract platform(s). Probably desireable to have a consumer chain for each popular smart contract platform.
As a side note, something like Celestia might help the recovery of failed chains - or rather "DA hubs" could help. the Cosmos Hub is a security hub, and it does not really offer that service. At least not directly. What do you mean with "will be protected when it needs intervention"?
The text was updated successfully, but these errors were encountered: