Dialogue with the Matter Labs team: How does zkSync 2.0 stand out in the L2 track?

Original Title: "The Path of the Metaverse | zkSync 2.0 AMA: How to Stand Out in the Ethereum Layer 2 Race?"
Interviewee: Matter Labs Team
Written by: Bin Lynn

Recently, the Ethereum Layer 2 project Matter Labs migrated the first Solidity dApp on the zkSync 2.0 testnet, and its underlying zkEVM makes this ZK Rollup Layer 2 network fully compatible with EVM.

For this emerging Layer 2, Matter Labs held an AMA on r/ethereum, and here are the highlights of the event organized by DeFi Dao:

Q1: Alex G mentioned on Twitter that he believes Starkware and zkSync are built for different target user groups. Can you elaborate on this?

Alex: Of course, I can only speak for Matter Labs, but this is indeed my strong opinion.

The vision of zkSync is firmly rooted in the spirit and philosophy of the early crypto movement. It is based on ideas from cypherpunks, sovereign individuals, Satoshi Nakamoto, and Vitalik. In short, we value freedom and the powerful new forms of resilience brought by cryptography. You see, cryptography is the only technology available to any individual today that can withstand the most powerful adversaries (like strong authoritarian regimes). Combined with decentralization, cryptography empowers the blockchain community to challenge (and ultimately change) the status quo. Without decentralization and unassailability, what you have today is banking. If you think these two attributes are not essential for blockchain, please take a moment to Google "e-gold" and "liberty reserve."

This brings us to the main differences between the two companies. zkSync is building an open protocol focused on "decentralization" and "resilience optimization." We aspire to be replaceable: even if Matter Labs disappears or is compromised, the network should thrive. Our primary target audience is 1) individuals using blockchain to achieve financial sovereignty, and 2) decentralized protocols built for these individuals.

On the other hand, StarkWare is building a more or less proprietary scaling solution optimized for the performance and defense of its IP, but with enterprise-level support and SLAs. As a technology and service provider, they are taking steps to maintain their indispensable status. Their primary target audience seems to be centralized companies built on blockchain (dydx, Immutable, Sorre, TikTok).

These distinctions directly lead to significant differences in design decisions:

1. Software Licensing:

zkSync is permissively licensed (Apache/MIT), so if Matter Labs fails to do the right thing, anyone can freely fork the network.

StarkWare has proposed Polaris, which will prevent anyone outside of StarkWare affiliates from running STARK provers.

2. Developer Stack:

zkSync focuses on complete EVM compatibility— we want the network to be owned by the community in every aspect and do not want to act as a service agency to rewrite and re-audit protocols in new languages.

StarkWare is promoting Cairo (a new domain-specific language for writing smart contracts), which favors performance over backward compatibility.

3. Upgradability:

zkSync 1.0 has had an upgrade mechanism with a mandatory time lock since day one of its release (later expanded to include a security council mechanism). We acknowledge the risk of being unable to fix vulnerabilities, and we prefer this approach over the risk of being compromised by subpoenas. zkSync 2.0 will follow this method.

StarkEx has a mechanism that freezes operations before executing upgrades, serving as an upgrade mechanism without a time lock, at least in the initial stages. Their focus is clearly on security against external attackers rather than reducing reliance on StarkWare itself.

4. Off-chain Data Availability:

zkSync 2.0 comes with zkPorter: an off-chain data availability solution optimized for decentralization. Its design will allow full nodes to be two orders of magnitude more than any existing Ethereum killer and provide cryptoeconomic incentives for activity.

StarkWare is betting on a Data Availability Committee, composed of a small number of data custodians who rely on their own reputation rather than decentralized incentives.

As you can see, these differences stem from our divergent values and philosophies. With increasing regulatory pressure, I believe we will see more issues arise (most notably in KYC, AML, privacy, and other tense areas between the crypto community and the state).

Q2: If zkPorter is frozen, what happens to the funds in the smart contract? Do they exit automatically? If not, how will this affect Rollup users? Consider an example where there is ETH/DAI on Uniswap, with Rollup accounts contributing $7 million and zkPorter accounts contributing $3 million. What happens if zkPorter is frozen, especially from the perspective of Rollup users?

Stan: Generally, this will not change anything for Rollup users; liquidity will remain in the contract and continue to operate as usual.

Follow-up: If zkPorter is frozen, how does the liquidity provided by zkPorter accounts continue to operate normally? This seems unsafe to me.

Stan: A zkPorter freeze means that in the worst-case scenario, zkPorter accounts cannot withdraw their liquidity from the smart contract. Why do you think this might be unsafe? Please note that the global storage of the contract, such as its ERC-20 balances, is still stored in the Rollup.

Follow-up: You could say this is worse than freezing funds. I always thought that freezing the zkPorter state meant its literal meaning—but you are not actually freezing zkPorter here. The funds just aren't in the smart contract—this contradicts the purpose of a smart contract platform.

Unless I misunderstand everything—if users are liquidated while zkPorter is frozen and they are completely powerless, that would be a terrible user experience. A bigger issue is that it opens up an attack vector where sorters and zkPorter validators can collude to force liquidations and other MEV scenarios—this makes it as unsafe as sidechains and potentially worse for certain MEV cases. I know zkSync 2.0 has a mechanism that allows users to withdraw funds from the smart contract even if the Rollup is frozen, and StarkWare has similar protective withdrawal solutions. So why isn't something similar implemented for zkPorter to protect users?

Stan: Thank you for such a comprehensive response! Our team is aware of these potential issues; unfortunately, I cannot provide all the details, but we are indeed committed to minimizing the impact of freezes on the system.

Regarding frozen funds, it depends on the contract. The current Uniswap Ethereum contract supports a single shard, so if its code is ported to zkSync without any changes, it will only store balances during Rollup. Therefore, whenever users from Porter provide liquidity to the contract, they will send funds to the contract's Rollup balance. These funds, like all Rollup funds, should be as secure as they are on L1. As I have said, we are committed to handling such situations gracefully. The testnet version will provide more details :)

Q3: How complex is the process of deploying contracts running on the Ethereum mainnet to zkSync? Is the deployed code exactly the same?

Angela: Yes, for Solidity smart contracts: most DeFi and NFT projects will work without changing the code. However, in the first version, the compiler will automatically replace calls to SHA256 and Keccak256 with circuit-friendly hash functions. Currently, some other cryptographic primitives, such as ecrecover and cryptographic precompiles, are not supported.

For UI: You can fully interact with smart contracts and the zkSync network through our Web3 API and Ethers SDK. For read requests, any web3-compatible framework in any language can work out of the box, with additional optional zkSync L2 specific features. For write requests (sending transactions): due to fundamental differences between L1 and L2, you will have to write some additional code (for example, zkSync supports paying fees in any token, so sending a transaction will involve selecting a token to pay the fee).

So yes! You only need to make minimal changes to reuse your current frontend (except that sending transactions is different).

Q4: What are the most pressing centralization points in the zkEVM architecture (e.g., sequencers or equivalents), and what are the plans to achieve decentralization in these areas?

Angela: Achieving decentralization in zkSync 2.0 requires attention to three points:

1. Gradual Decentralization of the Protocol

Like most Rollup projects, we chose gradual decentralization for innovation, rapid iteration, and faster vulnerability fixes. zkSync will remain upgradeable until the feature set stabilizes, after which it will become immutable. However, there are two mechanisms to achieve an ideal balance between decentralization/security and responsiveness/upgradability.

A) Trust-Minimized Upgradability:

Upgrades to zkSync smart contracts can be initiated by zkSync governance, with a 4-week time lock. If governance is compromised, the time lock will give users time to exit through our priority queue/emergency exit mechanism.

B) Security Council:

To address vulnerabilities/hacking incidents, we have established a security council composed of 15 respected members of the Ethereum community, whose powers are limited to shortening the 4-week time lock notification period. (Note: These 15 council members include the founding team of Aave, Itamar Lesuisse (Argent), Mike McDonald (Balancer), James Prestwich (cLabs), Michael Egorov (Curve), Jack Baumruk (Dekrypt), Haseeb Qureshi (Dragonfly), Justin Drake (Ethereum Foundation), Stefan George (Gnosis), Baek Kim (Hashed), Chris Burniske (Placeholder), Nick Grossman (USV), Will Harborne (ZK Validator), Sergej Kunz (1inch), and Lasse Clausen (1kx).)

This council is executed by smart contracts, with the following rules:

1. 8/15 signatures can shorten the time lock to 2 weeks;
2. 10/15 signatures can shorten the time lock to 1 week;
3. 12/15 signatures can shorten the time lock to 3 days;

A minimum time lock of 3 days prevents the worst-case scenario.

2. Sequencer

Initially, only blocks submitted by authorized sequencers can submit state transitions to zkSync L1 smart contracts. We may have some mechanism for selecting/converting sequencers. Ultimately, we will switch to a collective sequencer protected by multiple validators with PoS consensus. Users do not rely on sequencers for security. Our zkRollup has a priority queue/emergency exit mechanism to protect users from sequencer censorship: regardless of whether the sequencer is malicious or faulty, you can always exit zkSync.

3. zkPorter

zkPorter users can transact for a fixed fee of 1-3 cents. This is achieved by placing data availability (the essential transaction data needed to reconstruct state) off-chain rather than on Ethereum. Data availability is protected by zkSync token stakers using proof of stake (PoS). The security of zkPorter is strictly superior to any other L1 or sidechain, but in the worst-case scenario, if malicious actors control more than 2/3 of the staked sequencers and total stake, they can sign valid state transitions while withholding data, which would freeze the state, thus freezing staked zkPorter users and attackers.

To decentralize zkPorter as much as possible, 2/3 of the zkSync token supply is reserved for the community.

Q5: With so many scaling solutions on the market, what makes you different besides the usual claims of "faster, cheaper, and safer"?

Lyova: zkSync 2.0 will have zkPorter—a seamlessly interoperable, ultra-cheap sharding solution with off-chain data availability. You can read all the relevant information here.

Additionally, on zkSync, you can pay fees with any liquid token—without needing to buy ETH or a custom token like MATIC.

P.S. Regarding "we are faster, cheaper, and safer," you can refer to l2beat and l2fees.

Q6: What are the next steps for zkSync? Do you plan to improve interoperability across different L2s and with other blockchain environments?

Angela: Regarding the next steps for zkSync, we have a lot to build!

Developer tools: As you know, we chose a long-term approach and used LLVM for our compiler, which has forced us to consider debuggers, linkers, assemblers, disassemblers, and binary utilities.

Moreover, anyone who has written x86 or arm assembly can easily write code for our VM.

More smart contract languages: LLVM also allows us and any other team to easily build language frontends, such as Rust.

A more complete and efficient zkEVM: In the first version, calls to SHA256 and Keccak256 will be automatically replaced by the compiler with circuit-friendly hash functions, and ecrecover and cryptographic precompiles will not be supported. Of course, our next step is to effectively support these! We also plan to implement copy-on-write extensions.

UX/DevX improvements: We have implemented fee payment methods for tokens other than ETH and are implementing account abstraction, with more support to come!

Finally, cryptography has proven to be an incredible tool in the blockchain world. Zero-knowledge proofs are driving scalability and privacy, which are the two most important issues in public permissionless blockchains. Matter Labs is an engineering team passionate about using cryptography and mathematics to solve problems, and we will continue to do so! One interesting application is implementing time-lock encryption to eliminate MEV.

Regarding interoperability across different L2s and with other blockchain environments, we are primarily focused on building zkSync, while the issue of moving back and forth between zkSync and other networks is mainly addressed by bridge solutions like Optics, Connext, and Hop.

Q7: Why did you choose SNARKs over STARKs? Will it be too difficult to migrate to STARKs in the future? Will there be limitations on contract size?

Lyova: One reason for choosing SNARKs is that the data is smaller, making the proofs cheaper, occupying only O(1) space. SNARKs can also be easily recursive, saving more computation for the verifiers. Additionally, zkSync uses the PLONK scheme, which, unlike other SNARKs, only requires a single universal trusted setup, meaning we do not have to produce "toxic waste" every time we update the circuit. If you're curious, check it out here! We have no plans to migrate to STARKs in the future.

Contracts deployed on L2 must somehow be published to L1 (at least that's how we are doing it now) to ensure correct execution and withdrawal of funds during "priority mode," which occurs in unlikely censorship scenarios. This is why the L1 block gas limit imposes some size restrictions.

Q8: After the mainnet launch, how will Matter Labs achieve profitability?

Angela: In the same way as Ethereum, one-third of the initial token supply is reserved for the team and investors, while two-thirds belong to the community. The zkSync token is the fee token for the zkSync network (although we support paying transaction fees in other tokens, they will be converted to zkSync tokens in the background).