Hi lido,
I heard that you’re in fact zombies who specialize in the consumption of human flesh.
Luckily, I do not believe everything I hear, and I am glad you dropped in.
Can you please tell us more about lido is, and can you please assume that the reader doesn’t have any context?
Honestly all I’ve heard is… not great but it sounded hyperbolic and I think a decent starting place would be to learn more about your product, vision and team.
Thanks
-Jacob
I don’t think this is possible given the current implementations being discussed. That being said, these are exactly the sorts of hypotheticals we should not need to worry about, but someone now has to communicate with the community and provide evidence that these attacks are not possible. The community will also have the burden of making sure every additional change does not add such attacks.
It makes no sense to rush this proposal, I don’t understand why people try to push it so hard. You don’t implement a change like this without months of testing in my opinion. I thought we will get a Testnet soon, so why not use the Testnet for this stuff and test the implementation for months there with real economic value. If it is succesful, we can implement it on the Hub.
To be fair, this is a signaling proposal…nothing’s being rushed; it’s a temperature check to see if devs should even begin the work of integrating. There also seems to be some misunderstanding around testing and release of each upgrade. We launch a testnet for each release and the Theta testnet is still live for anyone who wants to use it from the previous upgrade. If the proposal were to pass, there will be a Rho testnet that will be launched for the exact purpose of testing all of the proposed changes listed in the Hub’s roadmap. If something fails on the testnet, then the upgrade gets pushed back until there’s a fix and that gets tested as well.
This is not the same, people have no reason to attack a testnet without real economic value.
Hi Jacob,
Thanks for the question ‘What is Lido?’ which I’m very happy to answer here for the community.
Lido is a DAO that makes liquid staking protocols – a simple and secure way to earn staking rewards on your digital assets without losing liquidity. What this means is that you can both stake your capital and participate in DeFi, thereby increasing your yield. We do this by issuing you stASSETS in exchange
We launched on Ethereum in Dec 2020 and have since has become one of the biggest, occasionally the biggest, DeFi protocol by TVL. We are also present on Terra, Solana, Polygon, Kusama and Polkadot.
Our guiding principle is that liquid staking is two-sided product: one is liquid staking token, that provides APR, liquidity and optionality (integrations) to the stakers, and the other is providing a validator set to the protocol. Protocols that do one of these things badly will lose.
We maintain that selecting a validator set has to be an opinionated process (what’s a good validator set? there’s no single definition for “good” here), that has to source data from meatspace in some way. There’s no purely onchain way to gauge the geographical, political distribution of operators, their independence, lack of sybils etc.
We don’t have a perfect solution here, but we experiment. We started from the simplest way to get a decent validator set, peer review process, but it’s very clear it’s a stopgap
solution.
We also think that liquid staking should be under the governance and accountable to the protocols it lives in, whenever possible. Thus we are not fans of making our own zone, even if using interchain security for this. It’s a very natural slope from there to disentangle the zone to a sovereign one, leaving Cosmos Hub governance with very limited control over ATOM liquid staking. We don’t want that, and we want to wire the incentives in a way that would prevent that.
Just wrote a post titled " IBC Will Not Make Cosmos a Hub; That’s Great News".
The core idea is that Cosmos Hub most likely will not be a hub due to the dynamic competition of the app-chain world. Therefore, we need to prepare for a future where Cosmos can only compete on innovations. This includes the integration of CosmWasm, whether it is in the Pho Upgrade or in a future one.
The full post is here: IBC Will Not Make Cosmos a Hub; That's Great News | Polkachu
Polkachu
Let’s assume this passed and gets included in the rho upgrade. What’s the estimated timeline for lido to deploy the contract and launch it fully? @vshvsh
I feel like if we can provide an estimated eta like 3 months than people will feel the gain more real.
Also anyone can estimate timeline on copying daodao?
Thanks Billy for the thoughtful initial writeup and everyone else for the discussion. I have a few thoughts on this. My general feeling right now is to vote No, but I will try to provide some analysis around what I think would be needed for a Yes.
I could imagine a VM going on the Hub, but I would expect it at least to (1) have a dedicated team of trained experts in that VM and its integrations, focused specifically on its deployment on the Hub, (2) have them engage in or oversee a focused security review, (3) have them provide clear reasoning why it should be directly on the Hub vs on an interchain secured consumer chain, and (4) have them integrated into the governance gated deployment process. I don’t think we will have that by Q2 2022. We do want to have a team like that to support CosmWasm consumer chains anyways, so we are working on building it up. So I guess it’s a question of timing.
That said, my general preference is for the Hub to lean towards minimalism. A big part of why we’re building Interchain Security is to enable the Hub to extend its functionality in a principled way, using the age-old principle of process isolation to scale computation. Ideally, I think VMs like CosmWasm should run on consumer chains secured by the Hub, rather than on the Hub itself.
Of course, it will take additional engineering effort to achieve this. Process isolation comes with additional overhead - it makes communication more complicated. Instead of a local function call, you’re doing RPC. The code has to handle more failure modes and edge cases. The IBC programming model is still quite young, and we don’t have an IBC query system yet (though it’s being worked on), which is needed for consumer chains to be able to read data from the Hub and vice-versa. Interchain Security also isn’t ready yet, and won’t be by the Rho upgrade (though it should be by later this year!). So again, this proposal is really a problem of timing.
The sense of urgency seems to be coming primarily from liquid staking. In my understanding, liquid staking is important at least because it allows the Hub to natively provide what centralized exchanges are already providing (ie. ATOM derivatives), and thus push back against centralization of voting power in the exchanges. The flip side is of course a new centralization of voting power in the liquid staking providers. In general we should probably be looking at additional ways to decentralize voting power, but liquid staking might be able to help. It does have its own risks, so we need to be careful, and set some kinds of limits, and nurture competition between providers.
The core liquid staking module provides a simple primitive that others can use to build proper staking derivative products. But without CosmWasm on the Hub or Interchain Security, such products will have to be built on external chains, which introduces its own security concerns. Ideally, the core ATOM staking derivatives are secured by the ATOM validator set. In my understanding, Quicksilver and Lido both plan to build ATOM staking derivative products secured by the ATOM validators. Quicksilver plans to build a consumer chain, but they may launch a sovereign chain first (whether or not the native liquid staking module is live) and then convert to a consumer chain once interchain security is available. Lido plans to use CosmWasm on the Hub, but ideally with Interchain Security they could use CosmWasm on a consumer chain. Of course building staking derivatives with CosmWasm directly on the Hub will at first be easier than building it using a consumer chain, as mentioned above (the difference between native function calls and RPC). But as the IBC programming model matures, this should become increasingly seamless, and probably preferable.
In any case, I think this means the launch of the liquid staking module needs to be accompanied by CosmWasm on the Hub or by Interchain Security so that staking derivative products are secured by Hub validators. Whether or not external chains should be able to provide staking derivatives using the native liquid staking primitive is another question. But if CosmWasm is rejected from Rho, it may not make sense to include liquid staking in Rho either. I’m not sure if that dependency is totally clear in the discussion.
So it’s basically a question of how urgent liquid staking is. My general bias is towards moving slowly and deliberately and trying to follow consistent principles, but I recognize that can have significant tradeoffs in the product market process. That said, past features developed for the Hub (Gravity DeX, Gravity Bridge), have had their own product market issues. CosmWasm has the potential to be much more successful in positioning the Hub more competitively until (or even when) Interchain Staking is live (beyond just liquid staking), but it may also compromise the Hub’s reputational position of being more minimalist and thus more stable, reliable, etc. I understand some feel the utility of that minimalism has yet to prove itself, because it can inhibit the Hub from competing on the shorter time horizons of hot money flows. But the whole point is to build for the long-term, to be an anchor in a thrashing sea. And with recent growth in development teams focused on the Cosmos Hub across core Cosmos organizations, velocity on the long-term roadmap is picking up.
Lastly, some meta comments on governance. While there has been plenty of general discussion about CosmWasm on the Hub in various channels, it seems there was not a significant amount of explicit consensus building done off-chain before this went live - this forum post had little activity until the proposal was on-chain. Ideally, by the time a proposal goes on chain, stakeholders are generally aligned about a positive outcome. Maybe some kind of pre-voting mechanism on the forum would help. Of course it won’t always be possible to build consensus before going on-chain, especially when there are strong conflicting views. And the present case is unfortunately further complicated by Jae (who has not played any kind of meaningful role in Cosmos development for years) effectively bribing people with the Gnoland airdrop to vote a particular way, which showcases current weaknesses in the governance system. Hopefully in the future we can move towards some kind of privacy preserving voting system and in general work on better governance norms and mechanisms to mitigate these kinds of attacks.
In the end, it seems like this proposal has spurred a lot of healthy debate and it’s exciting to see so many people engaged who care about defining the future of the Hub. Looking forward to continuing to build and evolve this thing with all of you, regardless of this proposal’s outcome 
Great write up thanks! Sounds like you’re advocating for a permissionless cosmwasm on the Hub? Do you think that’s necessary if we deploy a permissionless cosmwasm as a consumer chain ? The plan is to leverage interchain security to bring smart contracting to the Hub.
There are significant risks to delaying liquid staking arriving on the Hub.
The biggest risk is that DeFi yields must compete with ATOM staking yield. It make ATOM a bad asset to use in DeFi in the medium term. This dynamic creates a risk that ATOM will be made obsolete in DeFi.
It opens up a significant competitive risk for ATOM and I don’t think ATOM can make up for that risk by playing the long game.
That’s fair, but does this just means that if liquid staking launches before cosmwasm/ or interchain security then we just have to bear the risk of the initial staking derivatives being built on chains not secured by ATOM ?
And the present case is unfortunately further complicated by Jae (who has not played any kind of meaningful role in Cosmos development for years) effectively bribing people with the Gnoland airdrop to vote a particular way, @ebuchman
No peace, Ethan? That’s unfortunate.
You call it a bribe, I call it leaving.
We all have a right to exit and self-associate, and a sentiment proposal that offers the option is a great place for it. A sentiment proposal, supported by the very organization you’re foundation council member of. (The one that I founded; the one you repeatedly requested me to leave due to “conflicts of interest”, while you, you’re the one still steeped in conflicts of interests!). The same sentiment proposal where the NO with VETO option was imbued with connotations it should not have; that if you vote NO with VETO you plan to leave Cosmos and exit. I merely leaned into the bullshit and countered a pre-existing bias that you are responsible for.
You of all people should be celebrating the freedom of expression and self association demonstrated by this proposal and the airdrop, but you chose to label it as unfortunate bribing instead, and then you lied about what I’ve been doing for the past two years. Ok.
So first, you and Jack start #doubledare within All in Bits, Inc, while I’m CEO, to exclude me from conversations about removing a key component from the cosmos-sdk. You were fine to exclude me then in secret, and now you’re shaming me for coordinating an exit in the open, and giving everyone a chance to join? And after repeatedly telling me to leave the ICF, and coordinating social engineering against me even at AIB (because you and Zaki were responsible for the stated reason why engineers left – lack of funding clarity), you have an issue with me slashing people who vote to destroy the hub.
Ever since you started contributing to Tendermint, even Eris Industries back then, your ex-employer, now called Monax, tried to stop me from publishing Tendermint Core in Apache2.0. Then at the suggestion of someone I once trusted, who also stated to me that they saved George Soros once (a fnancial terrorist and globalist, I have later learned), I invited you as a late co-founder. And then I added you to the Cosmos Whitepaper, though IBC and the network of zones was entirely my idea, and invited you to the Swiss foundation that I set up, because we needed more seats, not because I thought that was the best way to do it. I never imagined you’d try to take over the whole damn thing.
Ethan Buchman, for the first time, I demand that you resign from the ICF. You’re intelligent, yes, but a hypocrite. I doubt that you will leave, but no matter, because 5/20/2022 is independence day.
This is cringe. Can we just debate the merits of the proposal and find a compromise instead of slinging dirt at each other?
Hey Ethan, we are relatively new to the Cosmos ecosystem (<1 year). Based on our observation in the past year, it seems that a “hub” cannot retain a competitive advantage in a feature without the risk of being forked into an independent chain.
We love the concept of Interchain Security and all the work that your team has been doing. That said, we believe that high-value chains would prefer to own their security (e.g., running a validator set), and low-value chains will be indifferent in outsourcing the security to Cosmos Hub or a competitor (say, Saga).
We are unclear how it would play out one way or another. Our “Yes” vote on Prop 69 calls for the preparation of a possible future that Cosmos is not a “hub”.
We do not have a clear take on whether CosmWasm needs to be permissioned or permissionless. Either way seems fine, and permissioned might be more prudent to start with for Cosmos.
How about we talk about how best to coordinate exit by defining the procedure in a constitution? It would involve a sentiment proposal with two opposing sides.
Also, it makes no sense that a new OS is needed for the hub to enable liquid staking. Replicated security allows for functionality to exist on other chains, still validated by ATOM. There’s no lack of options on how to do it without WASM on the hub, and implementing this should be the highest priority of the ICF.
I don’t get this exit rhetoric. Exit the hub? Like ok, dump your Atom and forge your path, man. If that path is something that resonates with people, i’m sure you’ll have some followers. I think I speak for many Cosmonauts when I say that it would be great for many of you OG’s to find some common ground and leave the past where it is.
To this point, the hub really hasn’t felt very “hubby” to me outside of being a fiat gateway to Cosmos, and the criticism of Atom’s tokenomics/utility/value accrual in the ecosystem have rang more true as time goes on. Zaki brings up a good point about Atom losing ground in the interchain as time goes on and it inflates to infinity. Josh Lee said it best: “the biggest threat to the hub is not instability, it’s irrelevance.”
At this point, the proposal is DOA. So what’s next? In theory, CW on the hub could be excellent if it’s done the right way, so how do we get there in a way that alleviates concerns if this is shelved and proposed later?
Everyone voting YES on 69 is ignoring one simple point.
You can get what you want without putting CosmWASM, basically an operating system, on the hub.
So your point is just a red herring that pro CosmWASMers are pushing, to manipulate the public into making the hub irrelevant through bloat and failure.
Forks will ensure transparency and accountability succeed in keeping our systems simple and secure. Long live Cosmos and gno.land, the gnomes of the greater resistance!
Bribing is what @zmanian offered an employee of AIB after he left; he asked for a “larger bribe” (his words) in return for silence in the public toward me. That’s extortion and bribery, & I should have acted on it back then, but I stayed silent then. I can’t stay silent anymore.
So @zmanian, extortionist, protected an employee who confessed to me that she stole Bitcoins from her ex for revenge. And knowing this, blamed me for failures because I didn’t promote this person to Google Apps owner, despite max admin privileges.
When she left the company she accused me vaguely of “harassment”; a public crucifixion in the age of wokeness. For what, for saying that we ought to be doing the work of God and making excellent software! These are social engineers manipulating the public against their enemies.
The entire @cosmos ecosystem has a right to know what happened, in light of continued FUD. I would not be able to sleep at night knowing that the community is being led to doom by clowns. Long live Cosmos and the gnomes of the greater resistance!
From purely financial perspective, Ethereum got to $400 billion valuation with a crappy virtual machine and many hacks. Solana got to nearly $100 billion in FDV despite multiple chain failures. While I understand the desire to split off smart contracts to another chain/s for very understandable “reputational” reasons, industry comparisons show that bad reputation doesn’t necessarily mean bad valuation (see Ethereum, Solana). Functionality clearly trumps bad reputation when it comes to value accrual. It is in the financial interest of ATOM holders for there to be smart contract capability on the hub. Maybe there could be a way to limit which smart contract get deployed and leave that to governance. New smart contracts that get deployed have to be evaluated both for their risk and reward before get deployed on the hub. Maybe Cosmos differentiates itself from Ethereum in that it has very strict requirements before it allows a smart contract to be deployed on the Hub. This allows the Hub to have the capability for needed features without necessarily sacrificing reputation.
CosmWasm needs to be added for ATOM to be relevant and the hub to accrue value which is very important. It is really pointless to make “I don’t care about money” arguments. If you don’t care about economics, you don’t care about your own survival. And nobody is investing in ATOM for charity. Obviously money can’t be the only consideration but it is a consideration that can’t be dismissed outright.