CosmWasm Upgrade Timeline Question

[sbeem]

Greetings community,

Currently, our team is hard at work building a key DeFi primitive slated for some time in the coming months. We are at a crossroads right now because we want to ensure that we use the proper version of CosmWasm. If we code for the current version of CosmWasm (0.10) on Secret Network, there will be a significant amount of time and energy involved that would require us to migrate code to the newer version were there to be a significant mainnet upgrade. Perhaps more importantly would be potential contract migration that would be required, which negatively impacts the users as they will have to migrate their assets as well.

We believe it is critical the following is established:

1. What month will we be getting the next upgrade of CosmWasm?
2. What version of CosmWasm we will be upgrading to?

Additionally, it is extremely important that we have as much of a heads up as possible to test the changes on a testnet with the upgraded version of CosmWasm. Looking forward to getting an update on this as this is critical for the entire Secret Network. It is key that we are all on the same page with development and mainnet release cycles such that we can optimise application development and end user experience.

Thanks,

sbeem

[rangerranger]

Thanks for bringing this up sbeem. I think we all want to see more support of the developers in this ecosystem so we can continue to grow as a network. If this is a roadblock I hope someone from SLABS can respond with some good info.

[orageux101]

Anything that enables us to convert potential developers to developers is valuable and should be considered. Would be interested in hearing the roadblocks / timeframe to getting this done from the Secret Labs guys!

[assafmo]

Hi @sbeem, thanks for bringing this up. We should have been more upfront about it.

There won’t be any need to migrate contracts - v0.10 and v1 contracts will both be supported and will work side by side. All current and future on-chain v0.10 contracts will not be affected and will keep functioning as usual. For now you may write your contracts in v0.10, and start writing new code in v1 when we’ll announce a more concrete timeline. My hope is to do the chain upgrade before June 2022.

[secretSpiderman]

What about scenarios where developers want to take advantage of upgrades beyond v0.10? If there’s an anticipated release date, these developers can begin using the upgraded versions in parallel.

[assafmo]

You’re right, we’ll announce an estimated release date as soon as we have one. Right now it’s hard to tell, but my guesstimate is June.

[secretSpiderman]

This might be worth adding to one of the weekly committee meetings as a discussion point. With the influx of Secret users we’re expecting, I’d think more developers will soon be asking similar questions.

I can understand that nothing has been finalized yet, but I’m trying to ensure we have a process to find that date sooner rather than later.

[assafmo]

That date is not just a function of when CosmWasm v1 integration is complete. We’re doing 1-2 upgrades a year so we want to cram in there as much as we can. Stuff like performance, stability & usability upgrades, and also new features from cosmos-sdk like interchain accounts, IBC v2, etc.

[secretSpiderman]

Thanks for the response, and I appreciate that update.

Is there currently a place where this type of information is communicated regularly? Understanding what will be included in these upgrades as their being planned would be helpful as developers are working in parallel. Most of the roadmap collateral I’ve seen has been around dApps and major releases vs this type of detail.

[hoomp3]

I mean it’s not about whether or not we don’t HAVE to migrate, it’s about the fact that we want to build better and more secure contracts by leveraging the newer features, especially the new types like UInt256 so we don’t have to mess with the U256 type from an external crate when trying to do complex math. Obviously workarounds exist, but it’s not a good experience having to do all this spaghetti in order to achieve functionality that will be available in a later version.

Like once again, can we write all the contracts with this old version of cosmwasm? Sure. But will it be a good experience? Definitely not. We don’t want to waste time writing a bunch of outdated code that’ll be scuffed and need to be upgraded anyway at some point so it’s easier to maintain and read.

Touching back on the developer experience once more, if you pay attention to the Terra Network at all, you’ll notice how much attention their Columbus-5 upgrade drew, especially on the development side of things because people just feel more comfortable writing code using updated tech so after the upgrade, projects flocked to the network to start building.

It’s not a good approach to tell people to keep developing on the old stuff and that the devs will HOPEFULLY get to the upgrade EVENTUALLY because taking too long will cause the momentum and excitement around Secret Network to wither away. People will move on to other chains that are better at taking care of their devs and quicker to stay updated.

[sbeem]

I echo hoomp’s point about development experience - the DX on Secret Network is a huge inhibitor to its growth, and the lack of transparency on things like critical infrastructure upgrades is one of the most egregious examples of the poor DX. Developing on Secret is already going to fundamentally pose challenges to new developers because of the novel privacy aspects of the network, so we need everyone to try twice as hard to make that DX better, and that starts with basic transparency about what the team who is responsible for the network is up to and how that will impact everyone else.

Assaf, to your point about the other things in the upgrade - this is the kind of information I think we need as developers. Personally what I would like to see is an explicit infrastructure roadmap. Tell us what you’re shooting to get in the next upgrade and approximately when that upgrade is coming, update us frequently (weekly, perhaps?) on that progress, and when things change (because obviously, this is software development, estimation is hard and things change) let us know.

[mohammedpatla]

Hey @assafmo thanks for your comments.

But i need to reiterate, that having some public soft deadlines helps us navigate features for D-apps. I know slabs is working on multiple features. But having a high level roadmap of what is coming in each quarter of this year is really appreciated. What features are targeted for these releases is even better.

There won’t be any need to migrate contracts - v0.10 and v1 contracts will both be supported and will work side by side. All current and future on-chain v0.10 contracts will not be affected and will keep functioning as usual. For now you may write your contracts in v0.10, and start writing new code in v1 when we’ll announce a more concrete timeline. My hope is to do the chain upgrade before June 2022

Does this mean we dont have to worry about IBC compatibility as well? And if they are backward compatible, their wont be any issues if new contracts try to call older contracts? Will their at any point in the next few years be a need to migrate the contracts?

Mohammed

[darwinzer0]

Great to hear about all the new developments that ScrtLabs is working on. I also support all the comments made already. I would also ask if we can please get a well-supported testnet with fully updated documentation and toolchain support at least a month in advance of any chain upgrade. If dev work on the new version of the chain is going right up the wire and the testnet versions available to devs do not exactly match what is eventually deployed, or if the documentation has not been updated it creates a lot of unnecessary friction. That was my personal experience with Supernova anyway. In that case, I’d prefer deadlines be pushed back, so that testnet environments and documentation are available in advance.

[assafmo]

@secretSpiderman
@hoomp3
@sbeem
@mohammedpatla
@darwinzer0

Thanks for this feedback! We’re taking it very seriously and will try to improve our future communications.

@mohammedpatla

Does this mean we dont have to worry about IBC compatibility as well? And if they are backward compatible, their wont be any issues if new contracts try to call older contracts? Will their at any point in the next few years be a need to migrate the contracts?

v0.10 contracts won’t be able to send IBC messages.
IBC messages from other chains will be able to call v0.10 contracts.
v0.10 contracts will be able to call v1 contracts.
v1 contracts will be able to call v0.10 contracts.
Re: migrations - my strong preference is that no - v0.10 contracts will always functions on Secret Network.

@darwinzer0

I would also ask if we can please get a well-supported testnet with fully updated documentation and toolchain support at least a month in advance of any chain upgrade

We’ll do our best!

[sbeem]

I’ll assume you already know this isn’t an acceptable answer and forgive the political handwaving and just be straight, and hopefully you can be direct in return.

1. What month will we be getting the next upgrade of CosmWasm? You said “hopefully June” but we need something more concrete than that - again, this is software development, estimations are hard, but giving us an honest best-guess commitment with the understanding that we’ll be updated when things change and that date gets pushed back is not an unreasonable ask.
2. What version of CosmWasm we will be upgrading to? I have heard we might go to 0.16 first, then to 1.0 later. Are we going directly to 1.0 in the next upgrade?
3. What specifically is going to be done to improve communications? Looking at the history of the network, there’s been transparency and communication issues going back a couple of years, so apologies for having no confidence in your assurance that this feedback is taken seriously and will be addressed. What exactly is going to happen? Perhaps we can start with what I suggested- an explicit roadmap of what is coming in the next upgrade, when we can expect the upgrade to happen, and weekly updates on the status of that roadmap. If SLabs can’t make that happen, please explain why, and what you guys will do instead.

[tor]

First of all, “political handwaving” aside, there are still expectations for decorum. Your frustration is clearly felt (and I’m sure shared elsewhere), but let’s be respectful towards core developers and one another regardless.

Let me at least give my best answer to point 3 on the communications side:

First, as you know, development timelines (especially at the protocol level) are extremely hard. They are full of unknown unknowns and interdependencies, especially in the Cosmos ecosystem. Asking for guarantees is also asking for disappointment. Answers will be, at best, probabilistic. Still, we acknowledge that developers require a degree of certainty and transparency in making decisions that are based on external timelines.

Second, there’s been a bit of a communications gap (resulting from a lack of human capital and coordination) that is now being filled. I left my position of Head of Growth and Marketing at SCRT Labs in 2020 to start Secret Foundation as an independent entity. This was done to create a standalone voice for the network that would speak for all of the interests of its contributors, including SCRT Labs, but also developers and validators.

However, this left an intermediate gap as well. While SF has done its best to help communicate and translate information on SCRT Labs’ timelines and products, the clear sustainable long-term solution was for SCRT Labs to have in-house ownership of these communications - someone who would also work in coordination with SF long-term. This position has been recently filled, and as of 2022 there is now a lead for marketing and communications inside SCRT Labs that I’m looking forward to working closely with.

Lastly, this is not the only expansion SCRT Labs is undertaking, as their development team is growing as well. There have been multiple recent hires on the dev side, freeing the core team to more effectively build both at network level and application layer. This could have an unforeseen positive impact on timelines, meaning you don’t have to only brace yourself for negative surprises.

While we acknowledge communications can (and will) be improved, I would urge you to look at the incredible rapid progress that has been made on the network and application layer by SCRT Labs and the broader ecosystem. We have placed shipping at the center of everything, and that is the healthiest thing we can do. Now we will also work to ensure clear communications don’t get dropped along the way.

You don’t have to take our word for it, but please acknowledge that the future can be better than the past and it is reasonable in this case to expect as much.

I’ll let @assafmo and others on SCRT Labs side speak for their own timelines and I’ll inquire for more details myself. Thank you for building on Secret - we appreciate your trust and take it seriously.

[assafmo]

@sbeem

What month will we be getting the next upgrade of CosmWasm?

As the one working in the task, June is my honest best guess.

@sbeem

What version of CosmWasm we will be upgrading to?

v1.0.

Before the end of this month you can also expect:

1. Massive performance improvements to nodes.
2. A new secret.js - it’ll be much more pleasant to write dApps.

[sbeem]

@assafmo I appreciate the answer and we will tentatively plan for June-ish and adjust our project plans accordingly.

Now I think the original purpose of this thread has been met, but I think it’s worth talking about the root cause that spawned this issue in the first place: transparency and communication. So Tor, like I said before, these kinds of issues have been a constant complaint for the network over the last couple of years, so there is no confidence from me, or from the community I’m sure, that promises of ‘it will get better’ are reliable. We need clarity on a plan of action, accountability for that plan, and updates on changes to that plan.

Someone has been hired, which is great. When will we start seeing the impact of that hiring? And what impact will that be? For a specific example, how will we know if the approximate June date is going to slip?

[tor]

there is no confidence from me, or from the community I’m sure, that promises of ‘it will get better’ are reliable.

Let’s adjust some language, since I don’t think you actually believe that “the community” thinks universally or speaks with one voice. We can all acknowledge there are other voices in agreement with you, but this “no confidence” vote is not the only sentiment that network contributors hold. Speak for yourself, and we will listen. Make sweeping statements like this and you’ll find that it only closes the lines of communication you are asking to be opened.

To answer the main question: you should start seeing the impact of that hiring as soon as this month. We still need to learn to work in close coordination (the communications stakeholders internal to SCRT Labs, the full-timers at SF, other community contributors). But we’ve all already acknowledged the need and urgency, and you already see the devs engaging actively here on the forum. The main difference is we intend to make these communications proactive instead of reactive in future.

This is a topic of discussion on a planned Monday call. The most immediate thing is to figure out an appropriate cadence of communications around network-level improvements / changes, as well as a format for comms to which everyone can commit. Is it monthly? Bi-weekly? Through forum posts, blogs, GitHub? How much certainty can be given on which points, and how do we ensure these communications reach critical audiences (devs, validators, etc)?

Your feedback is hugely important to this process, so I hope we can keep these types of discussions productive even through our frustrations. Decentralized coordination and communication is hard, especially across organizations and time zones.

Thanks again for contributing to this important conversation - I hear you, and I look forward to helping us all improve at this.

[sbeem]

Regardless of the choice of words, the point is that there’s a non-insignificant portion of the community that is unhappy, and has been unhappy for an extended period of time, with the level of communication and transparency from the network, and there is a demonstrable track record of the network doing nothing about it, again, for years.

That said, I do appreciate your response and look forward to a world where communication is proactive. My frustration personally comes from my support of the network and the principles of private and secure computing, my desire to see it flourish, and the fact that these problems have known solutions available in the short term, not out of questions about the team’s competence. Like you said, these problems are not easy, but they’re solvable and other networks have mostly solved them so we just need to try harder, that’s all I’m saying.

If there’s anything that we can help with, I’d be glad to help. I’m invested in the success of the network and I’m here to solve problems, not to complain. Again, thanks for the clear responses and I look forward to seeing improvement.