The理念 behind Scroll: community-driven, robustness, and decentralization

Written by: Zhang Ye, Co-founder of Scroll

Introduction

zkEVM has been a very popular topic over the past two years. It can be said to have become the standard technical solution for scaling Ethereum --- not only implemented in Layer 2 but also directly in Layer 1 --- "ultimately SNARKifying Ethereum itself." From the very beginning, we have been pushing this ambitious dream together with the Privacy and Scaling Explorations (PSE) team and are committed to continuing to build it together in the future.

In this article, I would like to share some lessons we have learned while building zkEVM and how we consider different trade-offs. We have adopted a different approach compared to other projects in the ecosystem, which puts us in a unique position.

Community-Driven Development

Scroll is fundamentally supported by an open-source approach. We are using the Zcash proof stack and have been building zkEVM circuits together with the PSE team from day one. We are grateful for the efforts of the community and all the tools being built. In the spirit of open source, one of our important philosophies is to give back to the community as much as possible and to continue building with the community in a more open and collaborative manner. This sets our values apart from other projects. More specifically, we have done the following to make Scroll's development community-driven:

• Public education aimed at a broad audience. To help people understand our architecture, we have given numerous talks and hosted events globally. You can find us at Devconnect, SBC, Devcon, etc. For those who want to learn more in-depth, we held lectures on our proof stack at 0xPARC and gave talks on our research findings at Stanford and Berkeley. For auditors, we hosted auditor meetings about our codebase. We also frequently create educational resources for the general zero-knowledge proof and Ethereum communities --- we have hosted a weekly updated series on zero-knowledge proof applications and shared technical blogs on zero-knowledge proof technology and Ethereum.

• Growing together with the community. From day one, our zkEVM has been developed in a fully community-driven manner. In addition to our team and the PSE team, several community members have contributed to different parts of zkEVM (for example, many opcode circuits have been implemented in parallel by different community members, and significant optimizations have been made to the keccak circuits and snark validators). We also lead bi-weekly community calls to improve the underlying verification stack. We have made some amazing progress --- for example, Halo2 now supports Goldilocks and FRI, laying a solid foundation for shared security and shared audits through community efforts!

The benefits of building in a community-driven way are evident. We can brainstorm with a group of people and gain more ideas. It can also be said to be safer because every PR receives more reviews from other community members. Some public parts can even be shared across projects --- for instance, Axiom implemented the pairing circuit, which is one of the most challenging parts of zkEVM precompiles.

However, building in an open environment certainly comes with trade-offs. Coordination among a group of people becomes more challenging (not only in terms of communication but also in prioritization). It slows down the development speed because many PRs require review, and the standards for merging are therefore raised.

What makes our zkEVM unique is that we also maintain a Python version of the specification, similar to what Ethereum has been doing for its consensus-spec and execution-spec. Maintaining this specification allows those unfamiliar with Rust and Halo2 to understand the circuit logic. To my knowledge, no other zkEVM implementation takes the time to do this, as they all prioritize faster mainnet launches.

At Scroll, we adopt this community-driven approach to develop the entire zkEVM. We believe the right way is to build together with the community from the very beginning. Note that "community-driven development" does not just mean open source. It does not mean building privately and then suddenly open-sourcing all the code one day. It should be measured by how many external contributors there are and how the project evolves over time. We accept the trade-off of a slower pace in the early stages, but as our community continues to grow, we believe in the power of community-driven development in the later stages.

Ethereum has adopted a similar strategy to realize its vision and values, referred to as "doing subtraction." The idea is simple --- they do not build everything themselves but support the community as much as possible. It helps them seek the right balance and focus on what truly matters to them. We are doing exactly the same thing. We ask ourselves, "What kind of support can we provide to the community to help them develop?" We believe our community-oriented approach will position us uniquely in this field.

This philosophy sets us apart from other competitors, who have large teams building multiple internal solutions and marketing frantically in various directions. We focus solely on delivering the most important parts and leading in the right direction.

Ensuring Security and Stable Releases

Compared to other alt L1s, security is the biggest reason people trust Layer 2 ------ you can inherit security from Ethereum without trusting the operators of Layer 2. However, all existing Layer 2 projects are still far from meeting this standard, with varying degrees of auxiliary wheels. For example, for optimistic rollups, even though many are now live on the mainnet, they still require upgradable keys and do not support permissionless fraud proofs.

For zkEVM, this is also a major issue ------ every player is in a long race, and regardless of how they choose to implement the mainnet, multiple iterations are needed. Some fundamental questions about zkEVMs have yet to be resolved. For instance, the cost of the prover will differ from the execution cost, which will affect Layer 2 gas pricing or introduce security vulnerabilities.

We have been considering security issues and striving to make the best decisions. Below are some of the decisions we have made:

• Adopting an EVM-equivalent approach. One important reason for adopting this approach is that it brings a better developer experience, but a deeper reason is that it inherits the security of the EVM model, which has been battle-tested. We are also reusing infrastructure like Geth to minimize our differences from Ethereum. This ensures that our Layer 2 sequencer behaves exactly like Layer 1 nodes, maximizing security.

• Community-oriented approach. As I mentioned earlier, getting reviews from external community reviewers can provide a stronger guarantee of code security. Tools and proof stacks are also shared across projects, so we pay more attention to the current codebase. A good metric should be "How many people are familiar with your codebase?" and "How many people are actually using it?"

• Audit, audit, and audit again. Test, test, and test again. We held auditor meetings to introduce our development stack to auditors and hired the best auditors in the industry for our zkEVM circuits, but external audits are not enough. Internally, we integrated standard EVM test vectors and conducted extensive simulations to validate mainnet blocks. In addition, we provide funding to support explorations of formal verification and fuzz testing for our zkEVM.

• Establishing an internal security team. What sets us apart is that we have a very strong internal security team closely monitoring our codebase. The best solution is not just to have auditors audit but to have a full-time team focused on our code security. Beyond our own security, we are also helping other projects. For example, we identified circuit bugs in Aztec and security attacks against Consensys's zkEVM prover.

• Research on auxiliary wheels. Internally, we have been researching various solutions to remove auxiliary wheels and how to ensure our zkEVM's 2FA or 3FA. We believe this is the most important thing, even though it receives much less marketing noise than having more flashy new features. As we make more progress, we will continue to share our findings and discuss them with the community.

To maintain high standards of security, we choose to make each release more stable and iterate on existing versions to continuously improve robustness and performance. We will make everything in the weekly updates on Twitter more transparent.

Our security-first philosophy is the primary decision factor for our roadmap. It helps us decide which direction to take while also answering the following questions:

• "Should we target EVM equivalence or Ethereum equivalence now?"

• "Should we decentralize the prover or the sequencer first?"

• "Should we continue adding new features or focus on removing auxiliary wheels?"

I will address these questions one by one in subsequent posts.

Decentralization at Every Layer is Important

Reflecting on Ethereum's history and why people consider it trustworthy and neutral. This is not only due to advanced technology but also because of the path it has taken to achieve today's accomplishments. Ethereum is decentralized at every layer (decision transparency, social consensus, etc.). Similarly, we have defined multiple different decentralization goals at various layers and set extremely high standards for ourselves:

• Decentralized provers. We are the first to propose the idea of a decentralized proving network. This is the first technical route we will implement to achieve full decentralization and ensure high reliability. One optimization goal is to reduce proving costs, which will allow more people to run provers, further decentralizing the network. We are consciously working to avoid the dilemma of "the fastest prover always wins," so that people do not need to rely on expensive custom hardware to participate in our network.

• Decentralized sequencers. Decentralized sequencers are another important step towards censorship resistance, and we are committed to this. We have multiple internal proposals on how to achieve this goal and will soon make these ideas public for broader discussion. There are many reasons why we want to decentralize provers first (for example, concerns about bug-free zkEVMs and the more complex interactions and incentives between provers and sequencers). In the long run, we are considering how to align with Ethereum at the protocol level regarding sequencers.

• Development and governance. The development of zkEVM is conducted in a decentralized manner through a community of open-source contributors. We coordinate with them through zkEVM and prover community calls. As we further develop, we will make the development and governance increasingly transparent (including the development decision-making process, similar to Ethereum's core developer meetings).

• Ecosystem and community. Following Ethereum's vision of an "Infinite Garden," we aim to support the continuous growth of our ecosystem and community. Therefore, we will minimize "partnerships" with specific individual projects and instead support all infrastructure from a more neutral standpoint. We are not considering marketing but are thinking about messaging and communication. We ask ourselves, "How can we be more transparent with our community?" We believe this approach is the best way to create a more decentralized ecosystem and encourage creativity.

• Social and cultural diversity. Beyond technology and ecosystems, our goal is to achieve another layer of decentralization on a social and cultural level. Our team is distributed across multiple continents (Asia, Europe, North America, South America, Australia). You can find Scroll team members almost anywhere in the world, which allows us to build locally distributed communities. We are growing with cultural diversity to achieve a deeper level of social consensus.

Building Not Just for Scroll, but for Ethereum

When building scaling solutions, we align closely with Ethereum. Ethereum has an ambitious ultimate goal of "zk-SNARK everything" --- building an Ethereum-equivalent zkEVM that can be used to prove mainnet blocks. Imagine a day when validators do not need to re-execute Layer 1 blocks but only need to verify a concise zero-knowledge proof. Imagine a day when you can verify the entire history of Ethereum with a single proof. Isn't that super exciting?

This is exactly the goal of the PSE team! As co-builders who have been developing on the same codebase for about two years, we are directly driving this ambitious goal.

Some standards have already been proposed to classify different types of zkEVMs. However, it is more like a higher-level specification that describes what the final outcome should be. As one of the main contributors to driving Ethereum-equivalent zkEVM, we want to propose something different to distinguish the goals from the actual paths to achieving them. Below is the path we want to take to achieve SANRK Ethereum:

• Implement bytecode-level compatible zkEVM using reliable zero-knowledge proofs.

• Launch relevant initiatives to coordinate the development of Layer 1 and zkEVM.

• Reach community standards and propose EIPs to improve Ethereum to achieve the ultimate goal.

Currently, we are in the first phase of launching a product-complete bytecode-compatible zkEVM, and we are committed to building the future of Ethereum together with the entire community. Building a high-performance and sufficiently secure Ethereum-equivalent zkEVM may take years, involving upgrades to the proof system, new circuit designs, and innovations in software and hardware acceleration. But more importantly, for it to be adopted at the Layer 1 level, Ethereum itself must make some changes. All significant upgrades to Ethereum need to consider zkEVM before achieving the ultimate goal.

The mainstream idea currently is that Layer 2 adapts to changes in Layer 1 in a one-way manner. However, as rollups mature, we believe this should no longer be the case. Rollups should play a role in driving changes in Layer 1, and Rollup teams should take on a more significant role in Layer 1 infrastructure (4844, Danksharing, Verkle trees, PBS, 1559, etc.). We need to be mindful of the impact on backward compatibility, but historical baggage should not limit future development. The entire ecosystem should coordinate to create a better Ethereum.

Conclusion

From the very beginning, we have adopted a community-driven approach to develop zkEVM and are committed to continuing to build and give back to the community in a more collaborative manner. We place great importance on security and decentralization, and we are focusing on concrete solutions to achieve these goals. Due to our security philosophy, we set high standards for ourselves, making each release more secure and stable. Due to our decentralization philosophy, we are pursuing decentralization at all different levels, including our technical stack, development process, ecosystem, community, and social diversity.

We hope to promote the openness and censorship resistance of blockchain as much as possible. We have chosen a uniquely distinct path from the very beginning. We have positioned ourselves not only to build Layer 2 but also to drive the ambitious goal of SNARKing the entire Ethereum. Our philosophy is to operate like Ethereum, committed to the same future of the infinite garden!

Related Links

0xPARC Talk http://learn.0xparc.org/materials/halo2/learning-group-1/cost-model/ Devconnect: https://twitter.com/ScrollZKP/status/1521677531438628864 Berkeley Event https://www.youtube.com/watch?v=Ct6H5GcnA0A\&t=2395s Zero-Knowledge Proof Application Research Series https://youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY Auditor Meetings: https://www.youtube.com/playlist?list=PLrzRr7okCcmZmDrVozX5hhBQlsrpZdsij Twitter Weekly Updates https://twitter.com/ScrollZKP/status/1621573571259793408
Python Specs
https://github.com/privacy-scaling-explorations/zkevm-specs