Hey all,
I thought I’d share some insight into some of the Matter Lab’s technical teams Q1 plans, with a focus on the changes we’re making that could impact the core protocol. I won’t attempt to be exhaustive, but rather give a flavor of some of the major areas of effort. If you have specific questions I (or someone else on the team) will be happy to expand.
I’ll assume the reader is familiar with the 2025 Roadmap already.
EVM Equivalence and RISC-V Proof System
There is a lot going on here, but as introduced in the blog post:
The absolute top priority for ZKsync is achieving EVM equivalence at the bytecode level. Boojum 2.0 and BoojumOS —new proof and operating layers—enable environment that supports all tools designed for L1.
EVM Equivalence will come in two steps.
The first step will be the EVM Interpreter, a program that can run on the EraVM and interpret EVM bytecode - this means an EraVM system can also offer an “equivalence mode” (in which CREATE2 works as in the EVM, and tools like Foundry work out of the box). This work is complete and audited - a governance proposal to enable this for ZK chains is imminent.
The major step is coming with the upgrade to the Boojum 2.0 proof system. This is a RISC-V based proof system, and the ZK Stack will be extended to support native EVM execution environments (so now ZK chains could use the EVM rather than EraVM). This is already very mature; we have the system running end to end through verifying the proofs, and with complex codebases deployed (e.g. Aave). At ETHDenver we’ll have more being shared, including benchmarks vs competitor systems. We’ll be working to get public testnets up ASAP, and through Q1 expect to move through much of the engineering work and begin to focus on the security and correctness testing ahead of audits & the eventual governance proposal. There are many advantages beyond just supporting the native EVM that come with this change, including what we expect to be a huge improvement in the efficiency of the proof system (aka cheaper transactions on the Elastic Network).
Gateway & Interop
Another huge upgrade for the architecture of the Elastic Network is the deployment of Gateway, and for ZK chains to begin migrating onto this system.
Gateway is deeply into the development cycle already, and we have completed multiple audits and security reviews. To facilitate cheaper proof verification, the team are working on improvements for certain precompiles (ecAdd, ecMul, ecPairing, modexp), which will be deployed to Gateway. During Q1 we are working towards having Gateway deployed and to begin the migrations of the first ZK chains.
The protocol team are also deeply into the development of interop. We’ll be releasing more info soon, but essentially I expect several interop “modes” to be supported. ZK based interop will be the most secure version, but will also come with the latency of the proof generation (meaning interop txs could take ~15 mins to move between chains for the first version). Given this latency, we also expect to offer faster interop modes, basically via precommits or TEE. This will allow for extremely low latency interop to be supported. All of this work is well underway, including modifications also for relevants SDKs, tools etc. The proposal to enable interop will come after Gateway is live - we’re sequencing the releases.
Put simply:
- First Gateway goes live, ZK chains can settle to Gateway and enjoy reduced onchain costs because Gateway aggregates the proofs before verifying on L1.
- After this, interop is enabled and all the ZK chains settling to Gateway will be able to interact w/ each other.
Prover Decentralization
We’re also continuing with the work to decentralize the prover, as introduced in previous blog posts. We have several very strong teams already working on their integrations (as examples, see the announcements from Fermah and Lagrange). We are working with a number of teams to support their development, and to ensure that the system is setup for other actors to provide proofs & participate in securing the network.
Developer Tooling
We’re going to continue much of the work that is well underway on tools like Foundry, Anvil, Alloy etc to ensure that Elastic Network builders have a great experience, but we are also working on LLVM-based Solidity compiler for the EVM, which will soon be ready for the community (it’s currently passing most of solc’s test suite). We’ve prioritized gas consumption & are already achieving up to 15% better efficiency on some contracts like ERC20 relative to solc. Compilation time has also improved 3x compared to the --via-ir pipeline that solc intends to set as default. In ~6 months, we expect to have all features implemented and see further improvements, mainly in gas consumption and contract size.
This approach unlocks compatibility with widely-used dev tools like interactive debuggers, profilers, and code coverage analysis (plus, we get to take advantage of >450K lines of well-tested optimization code).
Solana already offers developers this integrated tooling experience via LLVM, lldb, and VS Code, and we can unlock this for Ethereum.
Stage 1 milestone
We’re also working on the changes required for ZK chains (including Era) to reach the Stage 1 rollup classification. This requires us to complete some changes to the censorship resistance mechanisms for the system. We have completed the design for this feature, and are discussing the path forward for implementation now with one of our close development partners (who are interested in collaborating on this).
Early designs for mechanisms to satisfy the Stage 2 requirement are also currently being put together.
There are many other things we’re working on, including projects to make it easier to deploy and operate ZK chains, further UX improvements via the SSO toolkit, performance, security and cost improvements, and a long list of other items. I wanted to just share a brain dump here to provide some more context on what you’ll see through Q1 from Matter Labs!
We’d love to hear feedback and happy to dig deeper into any of the topics mentioned.
