Partnered With:

Matter Labs: Why did we delay the launch of zkSync 2.0?

Read this article in 9 Minutes

Matter Labs failed to deliver zkSync 2.0 on schedule. This article discusses the reasons for the delay and what to do next.

ZkSync 2.0 Developer Update

Matter Labs Medium

Chain catcher

On March 27, 2021, we announced plans for zkSync 1.x and 2.0.

We successfully deployed the zkSync 1.x upgrade to the main network, but failed to meet our predictions for the August release of zkSync 2.0. In this article, we'll discuss delays, phasing out the test net, and fair startup of the mainnet.

Why delay

Back in March, we finished designing zkSync 2.0 and estimated how long it would take to build it. As gas costs remained high, our design prioritized security and time, with some trade-offs in efficiency, optimization, and compatibility with Ethereum -- adapting the wiring environment to EVM was not easy due to the basic limitations of the wiring.

However, there was one key decision that did not prioritize mainnet uptime: the choice of LLVM. While it would be faster to implement a custom compiler from scratch, in the long run there is no alternative to LLVM. Built by engineers working on industrial-grade products (LLVM is an integral part of macOS and iOS), LLVM is the most advanced compiler framework for producing industrial-grade products, forcing us to think about debuggers, linkers, assemblers, disassemblers, and binary utilities, even if we just want to release a compiler quickly. With LLVM, our compiler has all the classic optimizations, over 20,000 regression tests and 3,000 integration/executable tests, low maintenance burden,

In May, while our nodes and VMS were ready, there were some unforeseen incompatibilities with our architecture and LLVM, and we needed additional time to integrate into the framework. We didn't want to open up a test net that was missing one of the three core components, but even with the initial overhead, we stood by our decision to adopt LLVM from the start. Matter Labs will never compromise security or code quality. Following best industrial-grade practices is slow, but the alternative is to program with technical debt. The debt will have to be paid one day.

Building zkSync 2.0 was an intense development process:

· Snark-friendly EVM and different per-account data availability policies in the same address space have never been done before;

· It needs to address compiler, zkEVM, and node requirements simultaneously.

Since implementation is highly relevant to research, many times we find a better solution that leads to lower cost, better compatibility, or more convenient interfaces:

· We went through several iterations to improve the compiler's efficiency, which gave us ideas on how to make our VM more efficient (more details in the Technical Insights post);

· Our API and SDK are very similar to the Web3 API and Ethers, so we decided to support both with additional zkSync L2 specific features;

· We found a way to remove the limit on the transaction execution trace length, thus achieving arbitrarily large transactions.

With Gas prices averaging 20 Gwei in June and July, we felt the time pressure was reduced and we didn't want to go online when we saw there was a clear way to do it better. For now, we will integrate all improvements before any release to avoid any disruptive upgrades as much as possible. The version we are working on now has more features, costs less, and is more compatible and convenient than the version we released in March.

However, we do want to be straight with you. Targeting August is a very ambitious target. It is now clear to us that uncompromising delivery on quality is not possible even if we forgo improvements in efficiency and Ethernet compatibility. This is the nature of r&d at the edge of technological innovation: any prediction is always surrounded by a number of unknowns.

Status updates

In six months, we have implemented and tested:

· Execution node & NBSP;

· zkEVM (Wiring and Execution Environment)

· Solidity and Zinc compilers (compiled and successfully tested Uniswap V2)

We are finalizing:

· Web3+ API (fully supports Web3 API + zkSync L2 specific features out of the box)

· Ether + SDK

· L1 to L2 communication (important for anti-censorship: funds from zkSync can be withdrawn through L1 transactions, even if you have to transfer them from smart contracts first.)

To:

· Integrate line/prover and data availability protocol into actuator node.

· L2 to L1 communication (e.g. triggering L1 contract from L2)

· Vyper developers: The Vyper team is currently building the Vyper-to-LLVM front end and our compiler team is working closely with them to ensure that you can seamlessly deploy smart contracts in Vyper on zkSync 2.0.

Test network Plan

We will open the beta network in three stages:

1.North Star

In a few weeks, we will start releasing the first version of a set of protocols. We want to work closely with these teams to facilitate rapid iterations of feedback and fixes and minimize errors and challenges as we launch the Open Testnet.

2. Spotlight Search

Then we want to open it up to people who want to create content. This can range from a tweet thread to a blog post to a full developer demo video. Our goal is to have a variety of useful resources readily available when we fully open up our test net and serve as another round of testing for our system.

3. Kindergarten

The testnet is open to all.

Main online

Matter Labs is committed to building a neutral layer 2 where all protocols and infrastructure can be deployed and run in a fair and equitable manner.

Therefore, it is critical for us that our mainnet launch is a fair launch: we will provide everyone with time to prepare and launch projects on zkSync on equal terms.

We are almost at the end of the road and no further changes are expected as we work hard to integrate all the moving parts, implement a convenient SDK, and write documentation.