The mindset behind Scroll

Introduction

The zkEVM has become a very popular topic over the last 2 years. It has arguably become the gold standard technology for scaling Ethereum – not only through layer 2, but also through layer 1 directly – "snark Ethereum itself for the end game". We have been pushing forward this ambitious dream together with the Privacy and Scaling Exploration team since the beginning, and have committed to keep co-building it in the future.

In this article, I want to share some of the lessons we have learned while building the zkEVM, and how we've been thinking of different trade-offs along the way. We're taking a different approach than other projects in the ecosystem, and this places us in a unique position.

Develop through a community-driven approach

Scroll is fundamentally enabled by open-source. We are using the proving stack from Zcash and have been co-building zkEVM circuits with the PSE team from day one. We appreciate the community effort and all the tooling being built. In that spirit, one important mindset we have is to give back as much as we can and continue building with the community in a more open and collaborative way. This sets our ethos apart from other projects. More specifically, we have done the following things to make the development of Scroll become community-oriented:

• Public education for a broad audience. To help people understand our architecture, we have given multiple talks and hosted events globally. You can find us at Devconnect, SBC, Devcon, etc. For students who wants to learn deeper, we have given lectures at 0xPARC about our proving stack as well as presentations at Stanford and Berkeley about our research. For auditors, we have hosted special auditor sessions about our codebase. We also frequently create educational resources for the general zk and Ethereum communities - we host a weekly applied zk research series, and share technical posts about zk tech and Ethereum.
• Develop with the community. Our zkEVM has been developed through a fully community-driven approach from day one. In addition to our team and the PSE team, there are multiple community members contributing to different parts of the zkEVM (e.g. many opcode circuits have been implemented in parallel by different community members, and amazing optimizations have been made to both the keccak circuit and snark-verifier). We also lead a bi-weekly community call to improve the underlying proving stack. Amazing progress has already been made - for example, Goldilocks and FRI are now supported in Halo2. A strong foundation through community effort enables shared security and shared auditing!

The benefits of building through a community-driven approach are clear. We can brainstorm with a large group and get more creative ideas. It's also arguably more secure since each pull request gets more reviews from other community members. Some common parts can even be shared across projects - for example, Axiom has implemented pairing circuit, which is one of the hardest zkEVM precompiles.

However, there are certain trade-offs that come with building in the open. It's harder to coordinate across a large group (not only in terms of communication, but also priorities). It can slow down development, as many pull requests require reviews and the standard for merging is forced to be high.

Something unique to our zkEVM is that we are also maintaining a python spec, similar to what Ethereum has been doing for its consensus-spec and execution-spec. Maintaining this spec allows individuals who are not familiar with low-level Rust and Halo2 to understand the circuit logic. As far as I know, no other zkEVM implementation takes the time to do this, so that they can ship faster and approach mainnet more aggressively.

At Scroll, we are taking this community-driven approach to develop the whole zkEVM. We believe the right path forward is to build with the community from the very beginning. Note that "community-driven development" means much more than just being open-source. It does not mean building in private 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 was developed over time. We accept the trade-off of being slower in the early stages, but believe in the power of community-driven development in the later stage as our community continues to grow larger.

Ethereum has adopted a similar strategy to achieve its vision and values called "subtraction." The idea is quite simple - instead of building everything on their own, they support the community as much as they can. It helps them to seek the right balance and focus on things that are truly important to them. We are doing the exactly the same thing. We ask ourselves, "What kind of support we can provide to the community to help them build?" We believe our community-oriented and grassroots approach will lead us to a unique position in the space.

This mindset differentiates us from other competitors who have a huge army of people building multiple in-house solutions, and who market crazily in every direction. We only focus on shipping the most important piece and leading in the right direction.

Be mindful about security and ensure a steady release

Security is the biggest reason why people believe in layer 2s in comparison to alt layer 1s – you can inherit security from Ethereum without trusting layer 2 operators. But all the existing layer 2 projects are still far from that standard, with different training wheels in place. For example, for optimistic rollups, even if many have already launched on mainnet, they still need upgradable keys and don't support permissionless fraud proofs.

For zkEVMs, it's also a big problem – every player is in a long race and needs multiple iterations regardless of how aggressive they choose to approach mainnet. There are still fundamental problems concerning zkEVMs that haven't been solved. For example, the prover cost will be different from the execution cost, and this will either influence layer 2 gas pricing or introduce security vulnerabilities.

We have been thoughtful about security problems and have tried to make the best decisions. I list some of those decisions below:

• Take an EVM-equivalent approach. One important reason for taking this approach is that it leads to a better developer experience, but another deeper reason is inheriting the security of the EVM model, which has already been battle-tested. We are also reusing infrastructure like Geth to minimize our difference with Ethereum. This ensures that our layer 2 sequencer is behaving exactly the same as a layer 1 node, maximizing security.
• Community-oriented approach. As I discussed earlier, getting reviews from external community reviewers gives a stronger guarantee for code security. The tooling and proving stack are also shared across projects, thus we get more attention on the current codebase. A good measurement should be "How many people are familiar with your codebase?", "How many people are seriously using it?"
• Audit, audit, and audit. Test, test, and test. We have hosted auditor sessions to teach auditors about our development stack and contracted the best auditors in the industry for our zkEVM circuits, but external audits are not enough. Internally, we have integrated the standard EVM test vectors and have done numerous simulations to prove mainnet blocks. Besides that, we are also providing grants to support explorations like formal verification and fuzzing for our zkEVM.
• Build an in-house security team. One thing that sets us apart is that we have an extremely strong in-house security team to keep an eye on our codebase. The best practice is not just auditing through auditors, but having a team focusing on our code security full time. Besides our own security, we are also helping out other projects. For example, we have found circuit bugs in Aztec and a security attack for Consensys' zkEVM prover.
• Research about training wheels. Internally, we have been doing research around multiple solutions to remove training wheels and how to ensure 2FA or 3FA for our zkEVM. We believe this is the most important thing to do, although it has less marketing noise than having more fancy new features. As always, we will share our findings and discuss with the community as we are making more progress.

To maintain a high standard in security, we choose to make every release more stable and iterate over the existing version to keep improving soundness and performance. We will make everything even more transparent in our weekly update threads.

Our security-first mindset is the strongest influence regarding our roadmap. It helps us decide which way should we go while also answering questions like:

• "Should we target EVM-equivalence or Ethereum-equivalence right now?"
• "Should we decentralize the prover or sequencer first?"
• "Should we keep adding new features or focus on removing training wheels?"

I will unroll each of those question in the follow-up posts.

Decentralization matters across every layer

Think of the history of Ethereum and why people think it's credibly neutral. It's not just because of the superior tech, but also because of the path it took to get where it is today. Ethereum is decentralized across every layer (decision making transparency, social consensus, etc). Similarly, we define decentralization across multiple different layers and set an extremely high standard for ourselves:

• decentralized prover. We are the first to propose the idea of a decentralized proving network. It's the first technical step we will take to achieve full decentralization and ensure high reliability. One optimization goal is to lower the proving cost, which will enable more people to run a prover, further decentralizing the system. We are consciously working to avoid the "fastest prover always wins" dilemma, so that people won't need to rely on expensive customized hardware to participate in our network.
• decentralized sequencer. Decentralizing the sequencer is another important step that can help with censorship-resistance, and we are committed to working on it. We have multiple in-house proposals for how to achieve this, and will make these ideas public soon for a broader discussion. There are many reasons why we want to decentralize the prover first (e.g. concerns about bug-free zkEVM, and more complicated interaction and incentives between the prover and sequencer). We are thinking in the very long term about how to to be aligned with Ethereum on the protocol level with respect to sequencers.
• development and governance. The development of the zkEVM has happened in a decentralized way with a community of open-source contributors. We coordinate with them through zkEVM and prover community calls. As we progress, we will make development and governance more and more transparent (including the development decision making process, similar to ACD calls of Ethereum).
• ecosystem and community. Following Ethereum's vision of "the infinite garden," we want to support the organic growth of our ecosystem and community. Thus we will minimize "partnerships" with specific individual projects, and instead, stand on a more neutral position to support all grassroots efforts. We are not thinking in terms of marketing, but rather in terms of messaging and communication. We ask ourselves, "How can we be more transparent with our community?" We believe that this approach is the best way to create a more decentralized ecosystem and encourage creativity.
• social and cultural diversity. Besides the tech and ecosystem, we target another level of decentralization at the social and cultural level. Our team is distributed across multiple continents (Asia, Europe, North America, South America, Australia). You can find a Scroll team member almost anywhere in the world, and this enables us to develop community distributed at the local level. We are growing with cultural diversity for a deeper level of social consensus.

Don't only build for Scroll, but also for Ethereum

We keep ourselves highly aligned with Ethereum while we are building out our scaling solution. Ethereum has an ambitious end goal to "zk-SNARK everything" – to build an Ethereum-equivalent zkEVM which can be used to prove mainnet blocks. Imagine one day, validators don't need to re-execute a layer 1 block, but instead, they only verify a succinct zk proof. Imagine one day, you can prove the whole history of Ethereum via one single proof. Isn't that super exciting?

This is exactly the goal of the PSE team! As the largest co-builder developing over the same codebase for around 2 years, we are directly pushing towards this ambitious goal.

There has been some standard proposed for categorizing different types of zkEVMs. However, it's more of a high-level spec describing what should be the done as the end result. As one of the major forces pushing forward the Ethereum-equivalent zkEVM, we want to propose something different to distinguish the goal and the practical path to get there. Here is the road we want to take to snark Ethereum:

• Implement a bytecode-level compatible zkEVM with a sound zk proof
• Work on related initiatives to coordinate the development of layer 1 and zkEVM
• Reach a community standard and propose EIPs to improve Ethereum for the end game

Right now, we are in the first phase of launching a product-ready bytecode-compatible zkEVM and we have committed to keep building the future of Ethereum with the whole community. It might take years to build a performant and secure enough Ethereum-equivalent zkEVM, involving proof system upgrades, new circuit designs, as well as innovations in software and hardware acceleration. But more importantly, to adopt it on layer 1, Ethereum itself has to make some changes. All the important upgrades of Ethereum needs to take zkEVM into consideration, before its end goal is achieved.

The prevailing thought has been for layer 2 to adapt one-way changes for layer 1. However, as rollups mature, we believe that this should no longer be the case. Rollups should play a part in driving changes on layer 1, and rollup teams should play a more important role regarding layer 1 infrastructure (4844, Danksharing, Verkle tree, PBS, Multidimensional fees, etc). We need to be careful about the implications of backwards compatibility, but legacy should not limit the future. The whole ecosystem should coordinate for a better Ethereum.

Conclusion

We have adopted a community-driven approach to develop the zkEVM from the very beginning, and have committed to keep building in a more collaborative way and continue giving back to the community. We place utmost importance on security and decentralization, and we're focusing on specific ways to achieve them. With our security mindset, we set a high standard for ourselves to be more secure and stable with every release. With our decentralization mindset, we are pursuing decentralization across all different layers, including our tech stack, development process, ecosystem, community, and social diversity.

We want to push the open and censorship-resistant nature of blockchains as far as possible. We have chosen a path that is unique from the start. We have positioned ourselves to not only build a layer 2, but also to push forward the ambitious goal of snarking all of Ethereum. With our mindset, we are operating like Ethereum, and aiming at the same future of the infinite garden!