DevEx 2025. You asked, we heard
Recently we published a DevEx 2024 recap, but we’ve got more to share. The whole 2025 is ahead of us, so let’s talk about it. We’re hyped, and we have a lot of plans.
But before we start discussing what is going to happen, it’s the right time to talk about why.
We heard you: the DevEx on ZKsync wasn’t great. So, if we will just continue doing what we were doing, the situation is unlikely to change. We took our time to analyze what was wrong in the first place, and discovered three main issues:
We focused on quantity, not quality.
That’s a lot for a relatively small team. That was justified, to a degree: without this infrastructure, ZKsync wouldn’t be as accessible. But the problem with this workflow is that once something reached a “proof of concept” state, we were moving on to the next thing.
And the result is predictable: death by thousand cuts. Everything seems to be working fine, but little bugs and inconveniences here and there ruin the experience all the time.
We haven't listened enough to feedback.
Our development was often a black box. We didn’t know about the issues until they were reported, we often didn’t provide updates when bugs were fixed or new features were shipped. We didn’t respond well enough to GitHub issues or GitHub discussions.
This certainly didn’t provide a good public image.
We had no clear plan.
When we had no ecosystem, the plan was clear: to get the ecosystem.
But after a while, you have most of the things you want, and the question arises: what next? How do you evolve the tooling you have? What are features people need? What bugs need to be prioritized?
We had no answer. Partially because of that, we often have been choosing to start working on something else.
These things may seem obvious, but when you’re fully occupied building things non-stop, it becomes pretty hard to realize. So, the conclusion we came to is: we need a new course.
New course
The basic principles of the new course we take are the inverse of the problems we discovered:
Focus on quality
Be transparent
Stick to plan
You can see some movement in this direction already.
And we’re only getting started!
Now, what should you expect in 2025?
We are going to:
Carefully revisit the documentation to make sure that we focus on the entire ecosystem. You can expect more coverage for custom chains, e.g. Validiums and chains with custom base tokens.
Adapt our tooling accordingly. Whatever works with Era, must work exactly the same way with any ZK chain in the Elastic Network, regardless of its configuration.
Change how we prioritize work. So far it was natural: we were running Era, so we prioritized feature requests and issues for Era. Now, we need to re-learn how we operate. Developer friction on any chain, no matter who runs it, harms the Elastic Network as a whole.
Full interop support
The interoperability is much more than just protocol capabilities and specifications. The tooling must provide the required level of convenience.
Overall, developing cross-chain applications must be as easy as building common dApps on a single chain.
No more fear of having to update your dependency. No more wondering what’s even inside of the update.
We’re actively working on raising the bar for our releases. You can expect timely announcements, changelogs with meaningful information, and no accidental breaking changes.
Our goal for this year is to develop release calendars that would be:
Externally observable (you will know which features will go into the next release)
Predictable (you will know when the release should happen)
Documented (if something the released, the documentation must be updated).
Who knows how much else cool stuff is already available on ZKsync or will be available shortly?
Well, soon you will!
We are now working with all the internal teams to make sure that any feature gets appropriate coverage, from early announcements through demos and showcases to the release.
ZKsync SSO was rolled out to the ZKsync Era testnet in December, and now our goal is to make it available on many chains in the Elastic Network.
Besides reaching the mainnet, here’s a sneak peek of what you can expect:
Advanced account recovery options (multiple passkeys, guardian accounts, social recovery)
Note that SSO on its own is not a wallet, it’s a smart account (with a sprinkle of magic) and it’s open source. So if you’re interested in providing great UX for your users on ZKsync, it’s certainly worth checking out.
And in 2025, we’re going to reach a 1.0 release as well!
Main criteria here:
foundry-zksync can be installed alongside “vanilla” foundry and you can use both at the same time
Feature parity with upstream Foundry
Custom features specific to ZKsync, such as interop support.
Who are “we”?
We use the word “we” a lot here. But who’s hiding behind this work?
A lot of people, actually.
First and foremost, two teams within Matter Labs: DevEx and DevRel. The former is responsible for working on the tooling, the latter works hard to get you great documentation, up-to-date tutorials, and cool events.
Then, it’s two amazing teams who dedicate a lot of their time to the tooling:
And now, the exciting part: the developers of many Elastic Chains! We already receive contributions from external teams that both fix issues and bring new cool features, and we hope that the number of such contributions will grow significantly during 2025.
And finally, maybe, you?
We have prepared a coordination channel for all the people who want to build ZKsync to make it easier to build on ZKsync. If you want to be on the frontier of ZKsync development, join us!
… and beyond
You may notice that there are very few “concrete” promises in this roadmap. That’s intentional.
As we stated in the beginning, our main focus is to provide a polished, predictable, and hopefully magic experience for all the Elastic Chains developers. That doesn’t mean shipping X new fancy things, that means changing how we work. That’s going to be tough, but we’re up to the challenge.