Dialogue with Scroll founder Ye Zhang: What position is Scroll in the zk-rollup breakthrough battle?

Interviewee: Ye Zhang, Founder of Scroll

Interviewer: Nianqing, Chain Catcher

At the beginning of last year, three young people met in the Ethereum community and discussed using zk technology to build the future of Ethereum scalability. They hit it off immediately. This is the story of how Scroll began.

In April this year, Scroll announced the completion of a $30 million Series A funding round. Notably, several members of the Ethereum Foundation and the Ethereum community also joined this round as angel investors, which reflects the close relationship between Scroll and the Ethereum community.

Compared to Optimistic Rollup, zk-Rollup solutions are more challenging to develop, but they offer shorter transaction confirmation times, lower fees, and stronger security (relying solely on mathematical and cryptographic assumptions). Vitalik has also expressed a long-term preference for zk solutions. However, Optimistic Rollup solutions are implemented more quickly. Currently, in the zk-Rollup space, Starkware and zkSync have not yet achieved the same level of smooth EVM compatibility as Optimistic Rollup, and the most well-known projects have not yet issued tokens.

Recently, the zk ecosystem has begun to focus its efforts. Polygon Hermez announced the open-source zkEVM, ZKSync released its ZKSync 2.0 plan, and Scroll announced its detailed development path for zkEVM after launching its pre-alpha testnet.

Scroll claims to be the most EVM-compatible zk-Rollup. Currently, there are two common issues in the zk-Rollup space: first, zk-Rollup currently only supports relatively simple functions such as payments and transfers, and has not yet supported general-purpose functions; second, a decentralized verification network has not yet been established. These issues are also the starting point for Scroll.

Recently, Scroll founder Ye Zhang accepted an exclusive interview with Chain Catcher, where he discussed the current state of the zk-Rollup space and Scroll's technical solutions and positioning in this breakthrough battle. Below is the full dialogue:

1. Chain Catcher: Please briefly introduce the Scroll team and its development history.

Ye Zhang: First, let me introduce the three main founders. I studied at Peking University for my undergraduate degree and started working on ZK proofs in 2018, mainly researching zk proof hardware acceleration and zk cryptographic algorithms. I later pursued a PhD in the same field, but I have since quit to work full-time on Scroll.

Haichen studied in Tsinghua's Yao Class for his undergraduate degree and graduated with a PhD from the University of Washington, focusing on low-level systems. After graduation, he worked at Amazon building machine learning systems. His work is very hardcore, and he has much stronger engineering capabilities than I do, but I am more familiar with zk.

Sandy graduated from the University of Cambridge and previously worked in research at the Hong Kong Securities and Futures Commission. Since 2017, she has been involved in Web3 project investments and has also worked on gaming and product-related projects. Currently, she is responsible for non-technical work in the team.

Among the three of us, I am more familiar with zk, Haichen is better at building systems from theory to practice, and Sandy is more familiar with branding, partnerships, and ecosystems for a startup team. Our backgrounds complement each other well.

We decided to create Scroll because I had been in contact with zk for a long time, and I was well aware that the efficiency issue of zk provers could be solved through breakthroughs in cryptography and hardware, which could increase ZKP (zk-proof) speeds by a hundredfold. At that time, no one in the industry was working on a general-purpose zk-Rollup; for example, the applications built on zkSync 1.0 and the Loopring protocol were limited to basic functions like payments and transfers, making it difficult to construct general-purpose composable DApps. Therefore, we wanted to create a general-purpose L2 network that could better accommodate EVM to achieve more complex functions like deploying smart contracts and general computing.

When zk efficiency is no longer a problem, there will be significant opportunities in the entire Ethereum scalability layer infrastructure. Moreover, the Ethereum community is very inclusive and creative, and we maintain close ties with the Ethereum community and foundation.

Initially, we had two goals: one was to build a general-purpose zk-Rollup, and the other was to truly achieve decentralization of zk provers. Based on these two ideas, we wrote the first version of the white paper, which we shared with members of the Ethereum Foundation. After discussions, we found that the Ethereum Foundation was also working on zkEVM, and our technical routes were quite compatible, so we decided to collaborate from the start.

Currently, both the Ethereum Foundation and our team have more than a dozen technical personnel collaborating on zkEVM in an open community format. Through open-source, even in the development stage, anyone can check our progress by viewing our GitHub repository, which forces us to remain transparent and accountable to the community.

Since last year, the Scroll team has grown to about 40 people. More than 30 members are researchers and developers in zk or blockchain, so the technical strength of the entire team is relatively strong, with relatively few non-technical members responsible for ecosystem operations. At this stage, we still want to lay a solid technical foundation, so our voice in the market is relatively small.

Additionally, the team is quite "decentralized," with members spread across China, the United States, Singapore, Europe, and other parts of the world.

2. Chain Catcher: How do you view the current zk rollup space, and how does Scroll stand out in this competition?

Ye Zhang: Many zk-Rollups currently only support specific applications and do not support general smart contracts. If Ethereum's scalability only expands the transfer part, that is still quite limited and difficult to develop a real ecosystem, so I would narrow the comparison to general-purpose zk-Rollups. In contrast, we have the following characteristics:

First, from the developer's perspective, we want to support an EVM-equivalent zk-Rollup that can achieve bytecode-level compatibility with Ethereum, meaning that all EVM opcodes and the underlying layer are exactly the same. This means that the execution effect of developers' code on Scroll and Ethereum will be the same, allowing for seamless migration without deep modifications or rewrites. We hope to provide developers with the most friendly and original development environment through this approach, supporting all Ethereum native development tools, allowing developers to quickly migrate contracts without needing to undergo repeated audits. This way, we can attract a large number of EVM-native ecosystems, which is much more convenient and faster than building an entire ecosystem from scratch.

ZkSync and Starkware have begun to support some general functions, but in terms of development languages, they still cannot achieve good EVM compatibility. For example, Starkware uses the Cairo language, and while ZkSync has achieved Solidity compatibility, it still uses a different underlying virtual machine. Both architectures require a specialized compiler to compile smart contract code into a new zk-friendly IR, which is language compatibility rather than native EVM compatibility.

For developers, migrating applications from layer 1 to layer 2 requires using a new compiler to recompile, which is relatively cumbersome. Additionally, the different virtual machine architectures require users to continuously trust that the new virtual machine and compiler are secure, and the code may need to be re-audited.

Secondly, ZkSync and StarkNet have not yet achieved decentralization. Currently, their sequencers and provers are operated by the official team, and block production, verification, and packaging are all done in-house, with no open-source code and no decentralized miner nodes established, preventing community participation. One issue caused by centralization is that all computing power is controlled by the team, meaning the team must rent machines to continuously bear this cost.

We realized early on that this approach is not scalable. Therefore, Scroll aimed from the beginning to enhance prover scalability, allowing anyone with a GPU machine to become a proving node. Even Ethereum miners may use their machines to become our provers (Rollers) after the merge. This decentralized approach is more efficient; the more nodes that join, the greater the computing power and the lower the costs.

This will create a positive cycle, encouraging the community to update to better and faster hardware, leading to the emergence and iteration of zk-specific ASICs, further reducing the final confirmation time and proof costs of L1, thereby improving user experience. Our team is also developing GPU algorithms, which will be open-sourced for everyone to use in the future. Therefore, it is precisely because of this open network that more people are willing to come together to build.

Through the aforementioned technical characteristics, we will provide developers with the best experience and higher community participation. Finally, in addition to the technology itself, we will always support the open-source community, i.e., public goods, doing more for the community, and genuinely helping Ethereum scale. I strongly agree with Vitalik's view: legitimacy is a very scarce thing in the long run.

3. Chain Catcher: Starkware's new language Cairo can support more complex application needs. What insights does this bring to Scroll?

Ye Zhang: Many people believe that new virtual machines will become the future, but at this stage, I have not seen any killer applications that must be deployed on a new virtual machine to run. I believe that a good blockchain virtual machine model should consider issues from a more fundamental logic and overall blockchain architecture perspective, such as "how to interact more friendly with accounts," rather than simply switching to C++, Rust, or other languages.

Moreover, even with a general zkVM, it is unrealistic to directly compile large-scale gaming applications. The proving overhead for gaming applications is several orders of magnitude larger than that for custom zk proofs. Improving the virtual machine must also align with algorithms and hardware, which requires long-term investment.

I personally believe we should take it step by step, first achieving zkEVM compatibility, and then considering other possibilities. For Scroll, we recognize that L2 serves L1, needing to take on some applications from the bloated L1, first addressing Ethereum's congestion issues, and we must not compromise on security and decentralization. Therefore, Scroll needs to use the safest way to accommodate the migration of these applications, especially since Ethereum's native ecosystem already has a large flow of traffic.

Of course, we will not stop at the level of EVM compatibility. After achieving full compatibility with Ethereum, we will consider exploring the flexibility of the virtual machine based on developers' needs.

4. Chain Catcher: Vitalik recently published a study on zk-EVM, classifying the current zk-EVM into four types, suggesting that Scroll's ZK-EVM project is developing towards type 2 (fully EVM-equivalent), and recommending that it is better to consider type 3 (almost EVM-equivalent) for now. What are your thoughts on this?

Ye Zhang: I think Vitalik's classification criteria are quite good. Type 3 achieves bytecode-level compatibility, including all the tools developers need, such as debugging tools, and must also be compatible with EVM-compatible languages beyond Solidity, which is the most basic standard for type 3; type 2 can support more detailed special precompiles in EVM. As the engineering progress advances, we will gradually transition from type 3 to type 2. Currently, Scroll's developer experience is already very similar to type 2, but we still have some functionalities that have not yet been implemented in the circuit. Once these are completed, we will move towards type 2.

Vitalik mentioned that the Ethereum Foundation's privacy and scalability exploration team is building type 1, and we have a collaborative relationship with this team. However, at present, type 1 is relatively inefficient for us because the designs of Ethereum and zk are fundamentally different. We are committed to providing developers with the same development experience as L1, and we will continue to pay attention to the efficiency of type 1.

One point in this article that I do not quite agree with is that I believe all types of gas fees need to be adjusted because the costs of proving and direct execution are different. If priced the same, it may lead to potential attacks.

Related Reading: Vitalik: The Future of Different Types of ZK-EVM

5. Chain Catcher: Scroll and Polygon Hermez have similarities in their zkEVM technical solutions. What are the differences between the two? What is Scroll's progress and plans for zkEVM development?

Ye Zhang: The biggest difference between us and Hermez lies in the implementation of zkEVM. Scroll's execution method is more similar to Ethereum's native execution. For example, Scroll's block-producing nodes directly reuse the code of Ethereum layer 1 nodes, specifically the Ethereum client node called Geth. This ensures that our execution method is identical to Ethereum's. We will directly use the trace information output by this node as auxiliary information (witness) needed to generate zk proofs, and then run zk algorithms to directly generate proofs.

The Polygon Hermez team has created a new language for zkProver, which translates EVM bytecode into another set of code called zkASM (Zero-Knowledge Assembly) during transaction execution. Vitalik considers this a workaround; although the internal logic is different, it can be said to achieve EVM compatibility, but there may be certain risks during execution.

For instance, Scroll's bytecode-level compatibility can fully adapt to various upgrades of Ethereum, including EIPs and other code upgrades, while Hermez may need to manually update to stay in sync.

Additionally, I believe another advantage of Scroll is our close collaboration with the Ethereum Foundation, as much of the code is developed together. In the future, they may directly apply this set to the Ethereum network. We are more focused on co-building the future of Ethereum, maintaining alignment in vision. Moreover, Scroll's decision-making is relatively independent; after all, Hermez is part of Polygon. How will it reflect the value of MATIC in the future? Will it become Polygon's L2?

Now, let me talk about Scroll's progress in zkEVM development.

Our testnet has several stages: pre-alpha testnet, alpha testnet, and a more complete testnet.

Currently, the pre-alpha testnet has some pre-deployed applications, such as the ability to deploy Uniswap v2 contracts to the testnet, allowing users to perform functions like transfers between L1 and L2, swaps, and other user-level interactions. However, it is currently only open to whitelisted users.

The alpha testnet will allow anyone to interact on the testnet without permission. Additionally, developers can deploy contracts on the network without permission. The alpha testnet is expected to launch soon.

The complete testnet is expected to be released by the end of this year, at which point it will support the generation of complete proofs. The current proof section already includes most opcodes and storage read/write access, while some remaining circuits are still being gradually improved due to engineering progress.

Related Reading: Scroll Research: Design Challenges and Solutions for zkEVM

6. Chain Catcher: Currently, Starkware, ZkSync, and Hermez all have their own data availability solutions. Does Scroll have any related plans in this area?**

Ye Zhang: Scroll currently does not have a dedicated data availability solution. First, we are relatively optimistic about the timeline of Ethereum technology, whether it is Danksharding or Proto-Danksharding. Secondly, introducing additional data availability solutions would compromise the overall security of the system, so we believe that in the long run, it is best to use Ethereum as the native data availability layer.

Dedicated data availability solutions are more likely to appear in L3's specialized applications. At that time, the application's own community can decide how to store data and whether they are willing to sacrifice some security for cheaper transaction fees.

7. Chain Catcher: Why do you say that we are still far from the normal operation of zkEVM?**

Ye Zhang: Many development tasks require significant engineering effort. For example, Scroll still has some algebraic circuits that have not been implemented. Additionally, there is the auditing work, which needs to be very thorough before formal deployment, followed by extensive performance optimization. These three points are all very tedious technical tasks that need to be completed gradually. What we are showing everyone now is just a technically feasible solution, primarily conveying the message that zkEVM has arrived, rather than suggesting that zk will take years to materialize.

Specifically regarding progress, I believe that regardless of the team, the earliest mainnet launch will be next year.

8. Chain Catcher: Vitalik has stated that he is more optimistic about zk rollups in the long term, but zk technology development is challenging. What are the main technical difficulties?**

Ye Zhang: Unlike other mature development languages, zk languages are purely mathematical languages (e.g., R1CS), which require building complex functions layer by layer through basic arithmetic and mathematical formulas. They are not Turing complete, making development very challenging.

Developing zk-Rollups for specific applications requires using this specialized zk programming language to write the logic of smart contracts (referred to as zk circuits). As mentioned earlier, this language requires complex design, demanding that developers be proficient in mathematics and zero-knowledge proofs, and it requires lengthy audits. They may also need to cover the costs of proving themselves, and the entire toolset requires strong technical stack support, which is nearly impossible for a regular contract development team.

We hope to provide a fast development experience for developers by directly supporting native EVM execution proofs while also supporting the composability of applications within L2. However, this requires us to develop a general-purpose zk-Rollup, directly designing zk circuits for the EVM virtual machine, which is significantly more complex in terms of workload and design than the corresponding zk circuits for ordinary smart contracts. However, it also shifts the complexity of zk development entirely onto us, so once the development is complete, application layer developers will not need to understand the underlying zk details.

9. Chain Catcher: Recently, dYdX left Starkware to embrace application chains, partly due to the long technical development cycle of Starkware and the short-term lack of decentralization in L2. What is Scroll's progress in building a decentralized verification network?**

Ye Zhang: Decentralization of verification in L2 indeed presents many challenges and involves more complex economic and incentive models. As mentioned earlier, Scroll needed to address the issue of decentralized verification from the start. The first phase is to enhance prover performance through hardware acceleration, achieving decentralization of provers. The next step is the decentralization of sequencers, at which point anyone can run a node. However, we still need a centralized sequencer to run the entire zkEVM system very stably; otherwise, prematurely decentralizing the sequencer would greatly increase design complexity and pose some security risks to the system.

Our team has been researching this area and comparing several different solutions. Once zkEVM stabilizes, we will focus on exploring this direction.

10. Chain Catcher: Scroll was founded not long ago, yet it quickly raised tens of millions of dollars in funding this April. What experiences can you share about this process?**

Ye Zhang: In fact, our entire Series A funding round was completed at the end of last year; it was just officially announced in April this year and showcased at Dev Connect. zk is considered a hot topic, and we are committed to creating the most EVM-compatible and general-purpose zk-Rollup, so the entire funding process was relatively smooth.

We are quite cautious when selecting partners, with one standard being strong research capabilities and technical strength. The institutions involved in this round, such as Polychain, Geometry, and Bain Capital Crypto, not only have many related ecosystem projects in their portfolios but also have researchers who have been deeply involved in zk and cryptography for many years, as well as experienced engineers. For example, the founder of Geometry was previously the CEO of Aztec. They understand the challenges of our project and can provide us with the right support.

Additionally, many of the investors in this round are from the Ethereum community, which facilitates technical exchanges after establishing connections in this way.

Therefore, we hope to start building influence from a small circle and then expand as the team grows and the product matures.

11. Chain Catcher: What is Scroll's development strategy for the next year?**

Ye Zhang: After the alpha testnet, we plan to focus more on deploying applications and testing. In terms of the ecosystem, we will first deploy basic infrastructure such as wallets and tools, and then expand to more applications.

At the same time, we will also engage in educational work, hosting hackathons and other activities. Recently, we have been collaborating with 0xPARC to provide classes, covering topics such as the mathematical principles behind Halo2 and how to use development tools, gradually expanding our influence. In the future, we will also seek partnerships with some Web2 companies to build some native Scroll applications.

Related Reading: Understand Scroll in Three Minutes: A New Contender for ZK Rollup Scalability