The v9 Lambda upgrade to the Cosmos Hub came off without a hitch shortly after 4:00 am ET on Wednesday.
The new software version, which has been in the works for over a year, enables a new kind of app chain to launch, one which doesn’t need to establish its own security through a unique validator set to establish consensus. The network would instead piggyback on the four-year-old Cosmos Hub and its 175 validators.
Cosmos Hub’s decentralized set of validators worked in concert to briefly pause the chain and initiate Lambda at a predetermined block height.
Blockworks spoke to Avril Dutheil, who is managing the Neutron project, a smart contract platform which expects to go live in mid-April and make use of the hallmark feature of Lambda: interchain security (ICS), also known as replicated security.
Blockworks: You’re the first project that’s actually going to be using ICS, is that right?
Avril Dutheil: We’re the first to have signaled our interest in interchain security, we’re the first to receive funding for doing so. We’re likely to be the first to launch on interchain security as well, but that kind of depends on governance.
Blockworks: How would you characterize the interchain security debut in the pantheon of Cosmos upgrades? Cosmos is marked by this very interesting political dynamic, oftentimes very tumultuous.
Avril Dutheil: To a large extent, I think this is actually a good sign. In political systems, we tend to say, democracy is de-census. You don’t have democracy if you don’t actually have conflict. It’s actually a good thing to see dissent to some extent.
In general, it’s been resolved in Cosmos when we get dissent, and it usually leads to stuff getting done in the end. I think the most recent example [was] the Atom 2.0 white paper and vision getting rejected. To me, it was a surprise that the proposal itself, which was just a signaling proposal, got rejected entirely.
But what’s actually more interesting to me now is that a lot of these ideas are actually getting built, but by specific teams that form around the ideas. So, for example, the governance vision is getting built by the likes of Dao Dao, [which] is actually going to be deploying on Neutron as well.
The Allocator [to fund new projects] is following a similar pattern, and the Scheduler [which would manage block space] is also being picked up by another team that has been working on MEV in Cosmos since day one. Basically all the main ideas, perhaps except inflation — the initial large mint of ATOM tokens that was proposed in Prop 82 — are actually getting built, but in a more piecemeal approach, essentially.
Blockworks: Compared to what the original vision was, do you think [the piecemeal approach] will be better as a result?
Avril Dutheil: For the Allocator, the products and the way they should be built are much more straightforward. And so it’s more of a question of having a good understanding of exactly which market the primitives work in, which is somewhat different from other DeFi primitives because it’s catering more towards inter protocol, DAO-to-DAO or even institutional clientele rather than retail consumers, and so designing the product with this in mind will be important as well as having good engineers that can make it happen in a way that’s very secure.
This is also getting built with smart contracts within the Cosmos Hub economic zone. I also think this is a really good outcome, especially since the initial idea was for the Allocator to be released as a consumer chain that would be secured by replicated security.
The problem, in my opinion, is when it comes to the economic model of ICS, for the short and perhaps medium term, I don’t see ICS scaling to dozens and dozens of chains — because the revenue that it generates will take time to bootstrap, but the cost on validators is pretty much instant.
It’s tough to launch a new consumer chain until the validators roughly achieve breakeven on the previous ones, because otherwise you end up adding pressure onto the bottom of the set, and that can turn into a centralizing force over time.
Mitigating this effect — distributing stake more equitably, distributing the revenue in perhaps different ways to achieve breakeven fast — and then the potential for opting in or out of replicated security are all avenues that are being explored in order to make this economic model more friendly to the bottom of the validator set.
Blockworks: Where do you position Neutron among other longer-running smart contract platforms like Juno and Evmos?
Avril Dutheil: I think there’s a fundamental difference between the two which is that, traditionally in Cosmos — well, actually any smart contract platform — as an application builder I have to choose which feature set and which market I’m actually going to be operating in. So that means if I’m interested in privacy I’ll probably choose Secret Network because they have this feature, but I’ll also be constrained by the size of their market.
In Cosmos, you can have token transfer functions very easily even as a smart contract application, but interoperability beyond that point — at least until Neutron launches — is not a solved problem. You can’t use interchain accounts because they were designed and built with other Cosmos SDK modules in mind…and interchain queries aren’t a thing that’s available to smart contracts either. When we started building Neutron, they weren’t a thing at all — they were an idea.
[Neutron] flips the script of general smart contract platforms on its head, because when you opt to deploy on Neutron primarily, you’re not choosing to deploy only on Neutron, you know that — because of Neutron’s features which enable your protocol to interact with other chains — you’ll be able to leverage feature sets from their other blockchains.
For example, let’s say I want to do private voting or sealed auction bids for my DeFi protocol or its governance. I can route the votes or the trades through Secret Network or Penumbra in order to anonymize them or conceal them — meaning that, I can get access to the privacy feature without being deployed on a private chain. I can get access to high speed by onboarding Sei [Network] and having some of my protocol’s logic run on Sei and then route trades that require that feature through Sei.
So there will be a market on Neutron, but there are also markets on Juno, on Secret Network, Osmosis and the others.
And rather than being siloed onto one of these markets and knowing that it’s going to be difficult and will require tremendous engineering work to be able to onboard these other markets, you know that comes right out of the box.
Blockworks: Would there be impediments to upgrading Juno along these same lines?
Avril Dutheil: It’s much easier to make changes to a blockchain before it’s live. That being said, eventually I believe these functions will also be present on other chains. The thing though is that there’s a lot of engineering work required to make it work…We had to code the solutions in a way that is to a large extent not compatible with another Cosmos SDK chain, so even adapting it would require quite a bit of time in terms of engineering.
Blockworks: The design philosophy sounds a bit like Axelar. Is that a fair comparison?
Avril Dutheil: I think there’s a bit of that, for sure. I do believe we’re working towards the same direction. The main difference between Axelar and Neutron is the technological stack that we built our interoperability on. For Axelar they built their own bridge system which is dedicated to Axelar. It is flexible enough to bootstrap interoperability between numerous chains with very diverse ecosystems. In our case, we mostly rely on IBC [Inter-blockchain Communication]…because we think that it is likely going to be the long-term winner in terms of the actual protocol that is used to make blockchains communicate.
The main advantage of IBC is that it does not introduce any additional trust assumptions. If you trust the blockchains that you’re interacting with, you can trust IBC because the relayers — the third parties that are actually making it work — don’t have the power to change anything as long as you have the light clients on both sides.
And so that’s a very interesting design philosophy and it’s also point-to-point, rather than having one chain that connects everything else together which would then act as a centralized point of failure. With IBC you can actually have a much more diverse network topography.
There are limitations to IBC — the main one being that, while IBC runs fine in Cosmos SDK blockchains, in most other environments running light clients inside a virtual machine takes a lot of gas and computation to verify all of the proofs. And so currently it’s difficult to make it widely adopted.
Blockworks: Are you optimistic that the impediment to having IBC working with Ethereum are going to be resolved?
Avril Dutheil: I wouldn’t be surprised if we see that this year, or conservatively next year — I’m sure it will be in production, yes.
The interesting thing of IBC is it specifies very little, meaning you can build very diverse applications on top of it. It’s very flexible beyond just ordering and the structure of the very basic messages and how you connect two chains. Beyond this, the sky’s the limit in terms of the applications you can build on it.
When IBC expands to these other chains, then suddenly our infrastructure, in the same manner, expands to these other chains, meaning that it will most likely be possible in the future to control accounts on Ethereum from a smart contract on Neutron, and I don’t believe it will require too much engineering to actually make that happen, once IBC is there.
The interview has been edited for clarity and brevity.
Get the day’s top crypto news and insights delivered to your email every evening. Subscribe to Blockworks’ free newsletter now.
Want alpha sent directly to your inbox? Get degen trade ideas, governance updates, token performance, can’t-miss tweets and more from Blockworks Research’s Daily Debrief.
Can’t wait? Get our news the fastest way possible. Join us on Telegram and follow us on Google News.
Source: https://blockworks.co/news/neutron-cosmos-interchain-security-upgrade