Exclusive Interview with the Matter Labs Team: How did zkSync 2.0 Stand Out in the L2 Space?

Original Article Title: "zkSync 2.0 AMA: How to Stand Out in the Ethereum Layer 2 Race?"

Original Article Author: Bin Lynn, The DeFi Way

Recently, Ethereum Layer 2 project Matter Labs successfully migrated the first Solidity dApp to the zkSync 2.0 testnet, with its underlying zkEVM making this ZK Rollup layer 2 network fully EVM-compatible.

For this emerging Layer 2, Matter Labs held an official AMA on r/ethereum, and the following are selected highlights from the event as curated by The DeFi Way:

Q1: Alex G has previously stated on Twitter that he believes Starkware and zkSync are built for different target audiences, could you elaborate on this?

Alex: Certainly, I can only speak for Matter Labs, but this is indeed my strong view.

The vision of zkSync is deeply rooted in the spirit and philosophy of the early crypto movement. It is based on cypherpunks, sovereign individuals, Satoshi Nakamoto, Vitalik, and the like. In short, we cherish freedom and the powerful new form of resilience brought about by cryptography. You see, cryptography is the only technology available today that anyone, regardless of who they are, can use to withstand the most formidable adversaries (such as powerful authoritarian regimes). The combination of cryptography and decentralization empowers the blockchain community with the ability to challenge (and ultimately change) the status quo. Without decentralization and censorship resistance, what you have today would be a bank. If you think these two properties are not necessary for blockchain, take a moment to Google 'e-gold' and 'liberty reserve'.

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

What StarkWare is building is more or less a proprietary scaling solution, optimized for performance and security of their IP, but with enterprise-grade support and SLA. As a tech and service provider, they are taking actions to maintain their indispensable position. Their main target audience seems to be centralized companies built on the blockchain (dydx, Immutable, Sorre, TikTok).

This distinction directly led to significant differences in design decisions:

1. Software License:

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

StarkWare introduced Polaris, which will prevent anyone outside of StarkWare affiliates from running the STARK prover.

2. Developer Stack:

zkSync focuses on full EVM compatibility — we want the network to be community-owned in every aspect, and we do not want to act as a service bureau to rewrite and re-audit the protocol in a new language.

StarkWare is pushing Cairo (a brand new domain-specific language for writing smart contracts), which is geared towards performance rather than backward compatibility.

3. Upgradability:

zkSync 1.0 had an upgradability mechanism with a forced timelock from day one (later extended with a security council mechanism). We acknowledge the risk of unrecoverable bugs and prefer it this way over the risk of being forked out. And zkSync 2.0 will follow suit.

StarkEx has a mechanism to freeze operations before executing an upgrade, serving as an upgrade mechanism without a timelock, at least initially. 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 approach will enable full nodes to be two orders of magnitude more lightweight than any existing Ethereum killer and provide economic incentives for liveness.

On the other hand, StarkWare is betting on the Data Availability Committee, which consists of a small set of data storers relying on their own reputation rather than decentralized incentives.

As you can see, these differences stem from the divergence in our values and principles. With regulatory pressures mounting, I anticipate we will see more incidents arise (most notably in the tense areas between KYC, AML, privacy, and other cryptocurrency community-state relations).

Q2: If zkPorter is frozen, what happens to the funds in smart contracts? Are they automatically withdrawn? If not, how does this affect rollup users? Consider an example where there is an ETH/DAI pool on Uniswap, with $7 million contributed by rollup accounts and $3 million contributed by zkPorter accounts. What would happen if zkPorter is frozen, especially from the perspective of rollup users?

Stan: Typically, this would not change much for rollup users, as 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 insecure to me.

Stan: Freezing zkPorter means that in the worst case, zkPorter accounts would be unable to withdraw their liquidity from the smart contract. Why do you think this might be insecure? Please note that the contract's state, such as its ERC-20 balances, would still be stored on the rollup.

Follow-up: One could say that this is worse than fund freezing. I've always thought that freezing the zkPorter state is exactly what it sounds like — but you're not actually freezing zkPorter here. The funds are just not in the smart contract — which goes against the original idea of a smart contract platform.

Unless I'm misunderstanding everything — if a user gets liquidated while their funds are stuck in zkPorter, and they are completely helpless, that would be a terrible user experience. The bigger issue is that it opens up an attack vector where the sequencer and zkPorter validator can collude to force liquidation and other MEV scenarios — making it as insecure as a sidechain and potentially worse for certain MEV cases. I know zkSync 2.0 has a mechanism where users can withdraw funds from the smart contract even when the rollup is frozen, and StarkWare has a similar solution for protective withdrawals. So, why hasn't something similar been 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 working to minimize the impact of freezes on the system.

Regarding frozen funds, it depends more on the contract, the current Uniswap Ethereum contract supports a single shard; therefore, if its code were ported to zkSync without any changes, it would only store balances during rollup. Thus, each time a user from Porter provides liquidity to the contract, they send funds to the rollup balance of the contract. These funds, like all rollup funds, should be as secure as on L1. As I mentioned before, we are committed to handling such situations gracefully. The testnet version will provide more detailed information :)

Q3: How complex is the process of deploying a contract 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 code changes. However, in the first version, the compiler will automatically replace calls to SHA256 and Keccak256 with circuit-friendly hash functions. Some other cryptographic primitives are not yet supported, such as ecrecover and cryptographic precompiles.

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

So yes, you can reuse your current frontend with minimal changes (except for the transaction sending part).

Q4: What is the most pressing centralization point in the zkEVM architecture (e.g., sequencer or equivalent), and what is the plan to achieve decentralization in these areas?

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

1. Gradual Decentralization of the Protocol

Like most Rollup projects, we have chosen gradual decentralization to enable innovation, rapid iteration, and faster bug fixes. zkSync will remain upgradable until the feature set is stable, and then it will become immutable. However, there are two mechanisms to strike an ideal balance between decentralization/security and responsiveness/upgradability.

A) Trustless Upgradeability:

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

B) Security Council:

To address vulnerabilities/hack events, we have established a Security Council comprised of 15 respected Ethereum community members, with powers limited to shortening the 4-week timelock notice period. (Note: These 15 council members include the Aave team, 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 governed by a smart contract, with the following rules:

8/15 signature can reduce the time lock to 2 weeks;

10/15 signature can reduce the time lock to 1 week;

12/15 signature can reduce the time lock to 3 days;

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

2. Sequencer

Initially, only blocks submitted by authorized sequencers can submit state transitions to zkSync L1 smart contract. We may have some mechanism for sequencer selection/switchover. However, eventually, we will switch to a collective sequencer protected by multiple validators with PoS consensus. Users are not reliant on sequencers for security. Our zkRollup has a priority queue/emergency exit mechanism to protect users from sequencer misbehavior: you can always exit zkSync regardless of sequencer malice/failure.

3. zkPorter

zkPorter users can transact for a fixed fee of 1-3 cents. This is achieved by placing data availability (basic transaction data required for state restoration) off-chain rather than on Ethereum. Data availability is protected through zkSync token stakers using Proof of Stake (PoS). zkPorter's security is significantly higher than any other L1 or sidechain, but in the worst case, if malicious actors control the staked sequencer and over 2/3 of the total stake, they can sign valid state transitions but withhold data, freezing 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 in the market, apart from the usual claims of being "faster, cheaper, and more secure," what sets you apart?

Lyova: zkSync 2.0 will feature zkPorter - a seamlessly interoperable, ultra-cheap sharded solution with off-chain data availability. You can read all about it here.

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

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

Q6: What are zkSync's next steps? Do you plan to increase interoperability across different L2s and with other blockchain environments?

Angela: Regarding zkSync's next steps, we have a lot more to build.

Developer Tooling: As you know, we've taken a long-term approach by using LLVM for our compiler, which has forced us to consider debuggers, linkers, assemblers, disassemblers, and binary utilities.

Additionally, 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.

Feature-Rich, Efficient zkEVM: In the first version, calls to SHA256 and Keccak256 will be automatically replaced by circuit-friendly hash functions, and support for ecrecover and cryptographic precompiles will not be available. Of course, our next step is to efficiently support these. We also plan to implement copy-on-write extensions.

UX/DevX Improvements: We have implemented fee payment in tokens other than ETH and are working on implementing account abstraction; more support is on the way.

Finally, cryptography has proven to be an incredibly powerful tool in the blockchain world. Zero-knowledge proofs have been instrumental in advancing scalability and privacy, two of the most critical issues in public, permissionless blockchains. Matter Labs is an engineering team enthusiastic about solving problems using cryptography and mathematics, 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, and the issues of moving back and forth between zkSync and other networks are primarily addressed by bridge solutions like Optics, Connext, Hop, etc.

Q7: Why did you choose SNARKs instead of STARKs? Will it be too hard to migrate to STARKs in the future? Will there be limits on contract size?

Lyova: One of the reasons for choosing SNARKs is that the data is smaller, making the proof cheaper as it only takes up O(1) space. SNARKs can also be easily recursive, saving validators more computational work. Additionally, zkSync uses the PLONK scheme, which, unlike other SNARKs, requires only one universal trusted setup. This means we don't have to produce "toxic waste" every time we update the circuit. If you're curious, check out here. We have no plans to migrate to STARKs in the future.

Contracts deployed on L2 must be somehow posted on L1 (at least that's how we do it now) to ensure correct execution and fund withdrawals during the "priority queue" period in the unlikely event of an audit. That's why there is some size limit imposed by the L1 block gas limit.

Q8: After the mainnet launch, how will Matter Labs make a profit?

Angela: Similarly to Ethereum, initially, 1/3 of the token supply was allocated to the team and investors, while 2/3 belongs to the community. The zkSync token is the fee token of the zkSync network (although we support paying transaction fees in other tokens, they will be converted to zkSync tokens in the background).

Original Article Link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia