Episode 234 - zkEVM with Scroll’s Ye Zhang and Haichen Shen

Transcript

Welcome to zero knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week Tarun and I chat with Ye Zhang and Haichen Shen from Scroll. We discussed the founding of the Scroll project, the problems they aim to solve with their native zkEVM layer 2 solution.

Why scaling Ethereum is important, the philosophy of their zkEVM, and how this differs from other proposals, as well as potential use cases or products that could benefit from the system. We wrap up with an exploration of how Dapps and products on top of such as zkEVM may interact with the mainchain and with other applications. But before we start in, I wanna let you know that the ZK podcast crew is growing. We are currently taking on a number of new projects, and we're looking to hire an additional content producer to join us. There's a job posting for this content producer over on the ZK jobs board. Just a reminder, the ZK jobs board is a spot where you can find jobs from all sorts of top ZK teams, not only the podcast.

So you might wanna check that out either way for this role of content producer, the job requires you to have at least two years of experience working on regular content production. Ideally you would be organized good at project management and somewhat familiar with the field. There's no need to be an expert on ZK, but some familiarity with our community would be ideal. If you or someone, you know, fits the bill, please apply. You can find the links in the description. And I hope to hear from you. Now, I wanna invite Tanya to share a little bit about this week's sponsor. Today's episode is sponsored by Anoma.

Anoma is a set of protocols that enable self sovereign coordination. Their unique architecture facilitates sufficiently the simplest forms of economic coordination, such as two parties transferring an asset to each other as well as more sophisticated ones, like an asset agnostic bartering system involving multiple parties without direct coincidence of wants, or even more complex ones, such as end party collective commitments to solve multipolar traps, where any interaction can be performed with an adjustable zero knowledge privacy. Anoma's first fractal instance, Nemada is planned for later in 2022, and it focuses on enabling shield to transfers for any asset with a few second transaction latency and near zero fees visit anoma.net to learn

more. So thanks again Anoma. Now here is Anna and Tarun's interview with Scroll. So this week Tarun and I are here with two members of the founding team of Scroll welcome Ye Zhang & Haichen Shen. Hi Anna. Thanks for having us. Hi, Anna and Tarun, glad to be here. Great. Definitely excited to have you guys on. Just a quick disclosure, both Tarun and I were both investors in Scroll kind early. We invested a while back myself through the ZK validator and Tarun through Robot Ventures, but I know that there's like, you know, a lot has changed since we did those early meetings and it would be really great for us to learn a little bit about what's happened since let's start off with a

little bit of an intro to each of you and to find out how you arrived on this problem or what you were working on. So my name is Ye, I'm the co-founder of Scroll. Most specifically I work on ZK research. So I work on hardware acceleration for zero-knowledge proof and, protocol design behind the ZK algorithm. So before starting Scroll, my background is more in academic. I started to work on zreo knowledge proof four years ago, back in 2018, where the biggest bottleneck of using zero knowledge proof in practice is a large proving overhead. And I was doing, researching the area of computer architecture and computer architecture and combining with my hardware knowledge, I started my first research on hardware acceleration for zero knowledge proof.

So the idea is just using FPGA ASIC to make computing faster and, having more hands on experience from the hardware project. I got a much better at ZK. I was very lucky to work with professor Andrew Miller at UIUC and dive deeper into the theoretical side of ZK. It was exactly during that time, the second half of 2019, there were a bunch of new ZK protocols coming out, including Sonic, Plonk, Marlin and Halo based on the polynomial commitment. And I was following the literature very, very clearly. I become really addicted to those polynomial.

It's much more interesting than just hardware. And, so the maths construction behind the ZK protocol is just very beautiful and elegance. So besides the hardware and theoretical research, I have also done some application level stuff with my advisor, Mike and other collaborators at NYU. So that's my, my experience, before starting Scroll. So the chance to start Scroll this back to 2020, when there is an explosion in DeFi and, I met Sandy and Haichen, the two other co-founders through some mutual friends in the field of competitive maths and also ETH community. We, we find that Ethereum needs a scaling solution, but all the existing ZK rollups have the problem of being too application

specific and also like the general proof in a centralized way, which is very hard to scale. So we want to solve this problem and build a new, totally new layer 2, with a more general EVM support and a decentralized prover. So it's also exciting to see some of the research, outcome coming to practice. Yeah. So that's basically the high, high level overview of how Scroll started. Cool. Haichen. What about you? Where, where did you start? So previously, I wasn't working in web3, so I previously worked web2 for a few years.

I worked in the Amazons AWS for a few years, and then we were focusing on working in the, some AI compiler to optimize the model development. so actually like about like one and a half year, or like the two years ago, like I met with Ye, like, as you mentioned, so some common friends and at that time, Ye was finishing up the, his hardware accelerator papers. And then that's like where he got me intro into this zero knowledge proof. and then teach me a lot about, about like the maths and then the protocol behind that. at that time I was very fascinated by the zero knowledge proof, I think like that that's very magic collector, which you can just do like a very small computation to verify some, very large competition. So I think I previously like, know a little bit about that,

but I didn't know the details like after like learning like more details, like getting more and more attracted with that. and then we were kind of discussing like what we can do using this zero knowledge proof. And then the, it turns out like the ZK Rollup and then building the zkEVM is kind of one of the way we should like, use that, that powerful tool in, in a maths. Mm. And then before that, before, like I joining the Amazon, like I was, getting my PhD at the university of Washington. but like my background is more in the system optimization, like building distributed system and then building the compiler optimization stuff. And then, yeah, that's like how I get started.

Nice. It sounds like your background was very well suited to later do this when you were doing distributed system stuff though. Were you touching blockchain or was it like general distributed systems? It's more general distributed systems like building, some distributed serving system for the machine learning workload. But at that time, like during the PhD, we also kind of explore some explore some of the blockchains and then the crypto stuff. At that time, we were mostly looking at the Bitcoin and thinking how we can extend the Bitcoin like a little bit. and then we were even working on some prototypes, trying to see, like, we can build some more object oriented language for new blockchain, but turns out like we didn't like the work that at full time during the PhD

time. Got it. Let's go back to the beginning then of Scroll the company. So there's three co-founders I guess. Yes. Okay. And so you'd all met and you decided to take on a project you wanted to work with zero knowledge proofs. What part of the ecosystem were you in when you decided to sort of start working on a zkEVM? Yeah, I think we are mostly part of the Ethereum community. For example, like my background is more in the ZK stuff, but, you know, I have read a lot of research from Ethereum community and I know like it's a very creative community, you know, we are pretty value aligned with Ethereum community, this open source and decentralized, and we are pretty value with this.

And also like, you know, our mutual friend also in the ETH community and thinking Ethereum is the best settlement layer and, especially it ETH scaling. So that's the reason why we choose to build on top of that. Yeah. Were you connected to the EF, like, did you work closely with them? And the reason I'm asking this is, and we're gonna get to this a little bit, like a little while later, but like there were designs and ideas around zkEVM coming out of there. So that's why I'm curious if that's where like some of your original thoughts on it come from. Yeah, yeah, yeah. That's a, that's a good question. So it's very interesting. Like, you know, it's also, a nice coincidence.

Like I was chatting with Barry Whitehat from Ethereum foundation and, seeking help for the first review of our Scroll first version. And it happens that he's also looking to the general zkEVM problem. Yeah. And so the collaboration between us and, the ETH team, they, they used to be called apply ZKP team in Ethereum foundation happens very organically because they want to build this. And we want to build this. Like, you know, at that time, like, you know, everything we have is just scratch and we are pretty value aligned. And we also do believe that developing in the open source way owned by the community is the best way to really make it.

And we are very excited to co-build a solution together to literally scale Ethereum. And, we are, we are also proud that in this community, nearly half of the contributors are from our team. And we have been contributing to this effort for around one year now. Wow. This is super interesting though, that you were actually tackling the problem separately, met Barry turns out they were trying to tackle the same problem. What inspired the problem in the first place? Like maybe here we can start to break down what even zkEVM means, like why zkEVM?

I think, you know, it's too far, like one is that why we are, how to build toward this EVM equivalence approach? because, you know, there are some other teams building some zkEVM and, some other solutions. So firstly, I like from us EVM equivalency really matters because it's secure because you can inherit the security property from EVM model, which was well defined years ago and has been test off time. And we have exactly the same behavior as EVM to be very secure. And secondly, that EVM has a very strong network effect. It has the largest developer community and also numerous steps built on that.

And also there are a lot of infrastructures and tooling around. We can support all of them seamlessly without any delegate labor. And also like Ethereum has very active research community. As I mentioned previously, they are proposing a lot of innovations around like many EIP to improve Ethereum. And if you build, you know, something which is EVM equivalent, you can adopt those innovations ahead of time because you have the same environment. And also like, you know, comparing against, you know, there are some other solutions to, to go into the way of zkEVM.

But I think in our case, in term of there two zkEVM is the best way to really scale Ethereum because, from our side, the highest priority is not looking for a new virtual machine to support more completely computation. But instead the urgency is migrating existing dApps from layer 1 to layer 2. So we think the best way to do that is provide the same environment with, with a seamless migration experience. And, I know there are also some complaints about EVM versus other virtual machine, but we, we believe that EVM is still the best practice for smart contract execution, because it has been years of exploration.

And I think Vitalik also has some article talking about the design trade off behind EVM and why they, they would still choose the EVM path. Like even if they know there are a lot of other virtual machines. And, we do believe that some, you know, some other, the zkEVM can be useful in some applications. And, we have a research team actively looking to this direction and our next step, but we are thinking about how to add more advanced features, zkEVM and then extension to our, the zkEVM. Also another technical difference is that building a zkEVM is much harder than the zkVM. And, but we decided to take that using more advanced crypto and hardware optimization and, to, to provide the best developer experience.

I think maybe one thing that would be worth talking through is comparison of the different EVM equivalence methods and like sort of what it means to be like a fully equivalency zkEVM. I think there's like obviously a lot of confusion around what qualifies as being fully EVM compatible versus like strictly solidity Bytecode compatible versus sort of like the proof generation process is separate from the execution trace directly, stuff like that. So like maybe let's like walk through what Scroll means by EVM equivalence. And then how that compares to say some of the other protocols that, that are talking about EVM equivalence, like say matter labs or, or other places. Yeah.

Because I do think that it can be quite confusing when you first hear zkEVM, cuz a lot of people kind of are like, oh, like someone else already said they were doing that. But then it turns out to like have some limitations. So technically speaking zkEVM is stimulating the behavior of EVM in circuits. And so in our definition and also the zkEVM, we are building with the open source community. We are targeting at Bytecode-level compatibility, which means the zkEVM should follow the definition of the EVM virtual machine, yellow paper. They define some op codes.

There are a lot of definitions in that one. And we think if you are really building a zkEVM using the term EVM, you should follow their standard and it can provide exactly the same environment as they current EVM on Ethereum. And, as for some comparison, I think, in term of the technology stack and also the compatibility side, we are pretty close to, to Polygon Hermez. They are incredible team led by Jordi and building something also fantastic. Both of us are targeting at bytecode-level compatibility and have a very similar architecture, but there are some technical differences from the implementation side.

So we are more close to the native Ethereum notation. for example, we are, we are directly using a fork of native geth to produce our layer 2 block. A geth is short for goEtheruem, it is the most robust and well known Ethereum node implementation and has been used across a lot of places. We also designed some subscircuit to prove for each opcode in gEth execution trace. And it's easier to verify that the scale the circuit has exactly the same behavior as native Ethereum. but for Polygon Hermez, I think they are rewriting each EVM opcode using a new assembly language and a general proof for their underlying state machine.

I think it is more from implementation side instead of because both of us are targeting at bytecode level compatibility. I think their approach might need more work to build everything from scratch as for the comparison between StarkWare and zkSync it's more different because as I mentioned previously, we are targeting an EVM equivalence and to achieve bytecode level compatible. But for them, they are building their own virtual machine, which is different from Ethereum virtual machine and also building compiler to c ompile solidity to this underlying VM.

So their VM has a totally new set of opcodes and also like they need to build on top of a compiler and to achieve language compilable. So I think that's the biggest difference. There is actually like last year I did an episode with Polygon Hermez at the time now Polygon Hermez, where we did do kind of a look deep into zkEVM in the way that they were building it. I remember that they did highlight that each opcode would be equivalent. How is it working for you if it isn't like you're not rewriting each op code. So how do you make it actually work without having to compile?

I think for their approach for each opcode, they will have some like a relatively small like state machine or some rewrite union or assembly code. So what we do is that for each opcode, we will directly build some customized circuit for this opcode. So it's one to one mapping like for add, we directly build some circuit for add. And instead of, you know, running add as a state machine. And so that's, that's some technical implementation difference, but I think both us can achieve all the opcodes level compatible. So the way like we're building the zkEVM is that we can take each opcode and then write a gadget, like a small component, which inside the ZK, circuit that you write a gadget for each opcode and

then simulate the behavior, like according to the implementation, the actual implementation from the specs. So it can, say like the, so then add opcode sample in the, EVM, you need to pop two values from the stack and then do addition, within the 256 bit range. And then you do push back the results to that. So in the circuit, you need to do the exact same things you need to verify that the two operands to the add opcode is actually popped from the stack. And then you like the write a constraint to say like the results is actually the addition, of these two operands and then push back that back the stack.

One thing that's important to also remember is that like the proof of actually the execution trace versus sort of like something that does a transpile step, and you really are proving execution of the transpile thing. Not the actual EVM can be quite different or like have a bigger attack surface in some ways. Why attack surface? Well, they're more moving parts, right? So like, let's say I have a high, another language, right? That's compiling to EVM bytecode, but I only prove what happens in the other languages execution environment before it gets converted. There's this problem of like, well, is my translation perfect. Mm.

And it's not necessarily that there doesn't exist a perfect translation, right? These things are still kind of bounded Touring machines and whatever, but it's more that implementing one that like catches every single edge case is actually extremely difficult. You know, an example of this is that, you know, in the early days of, iPhones and sort of Android phones, there was this huge movement to like, have people make these transpilers that were like, you could just write an app in Android and compile it to iOS and vice versa. And like they had way more security problems than the native code in general. And so there is sort of that from, from a security standpoint, I do think like it is also worth keeping in mind the fewer moving parts,

the more you can like be confident in the code that's written. Yeah exactly. I think that the one importance of the zkEVM is that it doesn't require any additional infrastructure to make your smart code, like the smart contract code to be compatible with Ethereum. And then also you make sure that, your smart contract is execute exactly on the EVM compatible like equivalent, environment so that you can make sure all of the codes should be behaved as like what you expected from the specs of the ACM. In that case though, why wouldn't everyone do like an EVM with EVM opcodes?

Like, what are the trade offs that you have to face? Like, is it harder to build? Is it longer to process like, yeah, I'm just curious, like why, why doesn't everyone do that? Is there, is there a faster path if you don't? I think, you know, as mentioned like the VM is much harder to build because, you know, EVM is a stack based virtual machine, but for the owner proof, it can naturally support a register based virtual machine. So it's, you know, just for this step, it will already add a lot of overhead. And also like for EVM, there is, there are a lot of ZK un-friendly opcodes, like SHA-3 and also inefficient data structures. For example, like EVM word sizes is not on prime field. It's sound like 256 bit.

So you need ring check everywhere, which just explore your circuit as a very huge overhead for ZK. And especially for, for this data storage, you need merkle potential tree, which is another huge overhead, but for zkEVM, you get more flexability because you can have your own defined instruction set. And you you can build that to be more zk friendly and have a much smaller prooving overhead. The zkEVM was thought to be like impossible in the past. I think it's just with recent breakthroughs, like advanced circuit optimization, hardware acceleration, and some recursive proof we can massively improve the performance of prover and finally make that feasible because, you know, it's, even if I had, it has a very large overhead, like, you know,

people still like it because it's still very developer friendly, but, you know, there are some technical challenges in the past. Yeah. Actually maybe could we walk through, I don't know, a year or two ago when people thought a zkEVM was not possible, what's sort of the chronology and timeline of the events that changed people's minds? I think, you know, first is from the circuit arithmetization part, because first in the past, we just had R1CS and which, you know, it's hard to build something which is more customized. And also, especially for EVM, like, you know, you have 256 bit, it needs very specialized gadgets to prove for, you know, range.

And I think with some breakthrough, like Aztec proposed plookup, which is a nice way to prove for some zk un-friendly primitive, you just need to prove that something is within a table and this belonging relationship and that's it. So I think that's very important primitive to deal with those, you know, friendly opcodes at the circuit part. And also like another important thing. Like you can also use this lookup to link different components. For example, like in a stake circuit, you prove that you read and write a correct over the same elements. And in another circuit, you prove that your execution is correct and you need to prove that, you know, the elements in different circuits are the same.

So you need lookup to prove that this belonging relationship and the plookup can provide a very efficient way to do this. And I think both us and, like Polygon Hermez, even some team buildings, the zkEVM are using the same approach to link the execution and also the storage. I think that's the biggest like improvement. And, on the backend side, I think there is hardware acceleration. It's just drawing more and more people's attention. It just happens simultaneously. We find, you know, not only from the frontend circumstances, this side, like, you know, you' prooving is still very large and hardware because, you know, even if your prooving takes very long time, it's highly paralyzable because it only contains some group operation or ability curve and also ts. So both two parts are highly parallelizable.

And we have done a lot of previous research around GPU acceleration and also ASIC acceleration. So we exactly know like, you know, using such kind of technology, you can improve the prover performance for maybe two order of magnitude to really make that feasible. So I think it just happens. And, like before that people don't know, like, you know, this can be leveraged here because I think, you know, zero-knowlege proof it's very hard for you to all sources proving to a third party because you know, ZKs case mostly in the past used to be some privacy preserving application. So you can't, you know, give your secret key and your secret information to a hardware provider, but, you know, in ZK rollup there is no ZK, there is just validity proof needed.

So you can easily out source this proof generation to a hardware provider. They can run GPU cluster, data center, or like even produce ASIC. So I think that's a huge opportunity for this prover to cutting in and solve the efficiency problem. And finally, the recursive proof is that I think also like using the sum of the optimiziation, you can generally proof for proof efficiently, and especially for some non-native field operation, you can aggregate that. I think that's also important to reduce the overall like verification costs because ZK circuits composed of many sub circuits.

And for each sub circuit, you will result in proof. If you verify all the proof on chain, it'll be very large overhead and you need to aggregate them to make your final proof smaller. I think that's also important, but that's, that's also like, you know, build on top of, you know, the arithmetization. So I think that's the biggest thing, like, you know, in making this possible. So you just mentioned like that it's circuits upon, and then there's sub circuits. Would you say is this still in the realm of a SNARK that you're using at this core? Or is this some like modified semi STARK, like SNARK? I mean, I know when I was talking to Jordi from Hermez, like there was also like STARK, like techniques used with SNARKs, so you didn't really know what the word for this thing was anymore, so yeah.

Yeah. Franken, Franken, SNARK STARK or something. Yeah yeah. That's a that's a very good question. So like, you know, yeah. I think, you know, both SNARK and STARK just some, some ZK protocol. And if you are describing a ZK protocol a better way, just to describe what kind of circuit arithmetization you are using and what the polynomial commitment you are using, because you can have different combinations for those, for those parts. For STARK, usually like aire as their circuit arithmetization and use FRI as their polynomial commitment. And, but for us we are using like, you know, both sides.

On the circuit arithmatization side we are using Plonky arithmetization, implemented in Halo2 by the Zcash team. And in the backend polynomic commitment. So the initial version in Halo2 tool, they use some Bulletproof style inner product argument, but we replace that with qeg because, you know, although like the previous one implementing Halo2 to had many nice properties, but we refuse that because we want to verify our proof on Ethereum and the Pasta curve is not supported directly on Ethereum. So that's a reason why we choose to, to change that to KCG, to make our proof more, more efficiently verified on Ethereum. So basically it's Plonkish arithmetization plus KCG arithmetization commitment.

And for both the EVM circuits and the aggregation circuit, we are not using any STARK related technology. You said Plonky or Plonk 2? It's Plonkish Arithmetization. It's it's a new name proposed by. Yeah. Wait, is this a different one? This is Plonkish? Plonkish it's I think it's a word like proposed by Dara, like on Twitter, like there are some words like to describe what kind of arithmetization you can use is called Plonkish. Oh, it's a kind of Arith... Okay. Okay. Okay. Yes, but it's not Plonk specifically or is Plonk at the heart of what you're doing as well?

So basically the literature look like this. So basically there is Plonk, which only support the addition and the multiplication gate. And then like, there is plookup, which is a separate prime to prove this lookup relationship. Yes. But how do you combine this plookup with the Plonk and the ad tech people propose some sematics called turbo plonk to combine two different prime tests in one in one way. And then, like, I think Zcash team use a more flexible way to represent this, you know, different relationships called Ultraplonk, and then like they rename this ultraplonk.

Ultraplonk. Yes. To Plonkish arithmetazation. So yeah, that's how this names. Oh my gosh. I have, I actually wanna do a whole session at some point, which just maps all the derivations of the word Plonk and what they mean and how they work together, but Plonkish. Okay. That, that was one part, but then you also said Halo and I wanted to just double check if you were saying techniques from Halo or Halo 2. Yeah. We are using Halo 2. Okay. Except that you're using KCG instead of the Pasta curve that they're using. Yes. Yes. Okay. And is there any other variations on this? Like, is there any other additions or changes that you've incorporated into your model?

Yeah, I think that's mostly about the ideas both in the zkEVM. So in zkEVM, we, we have multiple sub circuits and the lookup relationships and in aggregation circuit, we handle some non native field operations and general proof for that. I think for the Halo 2, we also extended their API a little bit. So to be making more flexible, use case in the, in the ZK event during our building, we find like there's some limitation from the API. And then, so we modify a little bit, and also we, since we also change their curve. So we also change the recursive scheme in our version of the Halo 2, but we also plan to actually discuss with the Zcash team to see how to upstream all of the features.

And then I think they're also interested in our way of the hacking, the Halo 2, to adding, those kind of the new changes. Cool. Isn't there sort of another camp of thought, like, I'm kind of just curious, like what made you choose to work on this particular direction? Yeah. I think when we are started, like we have this discussion with Barry and also with the Ethereum foundation team. And I think because we, we definitely need the customer gates support and also the look up argument sport. And, at that time, like Halo 2, is the only implementation that sports, both to primatives in the open source way and with a nice license.

And also like, you know, the project built by the zkCash team also have you really have a very high security guarantee. So, yes. What do you actually use to build this stuff? Like what languages are you using? So we are, we are using Rust because Halo 2 is written in Rust. Okay. And we need to follow their yeah. APIs to rust, to write circuits. And I mean, there's a lot of teams, a lot of ZK teams, which are introducing like native DSLs since you are working with EVM I'm I'm assuming the language to build on your zkEVM will be Solidity, but do you also need anyone to interact with the underlying ZK circuits in a special way that like maybe Solidity can't?

I think for now, like we, we will only expose some very high level EVM API to the developers. They don't need to touch any low level details, but in the future, if you want to add more advanced features, like, you know, support something which EVM can support in our, the zkEVM, we might need to hack that a bit and they can add some subcircuit to our current system and to interact with some, you know, Solidity contract and, that's one potential direction, but that's not what we are building for now, what we are building is just the same environment. Yeah. Is there a delay, like if you wanted to move from the L2 to the L1 with a zkEVM, is it slower or faster, or is there any sort of like change versus something like optimistic roll up or like the more non zkEVM

ZK rollups like, I'm just trying to picture if these steps of like creating, you know, the SNARK in that particular way, if, if there's any sort of time leg on that. So in general, the ZK rollup has a, roughly similar like delay for withdrawal transaction only. So for, for those transactions happening within layer 2, you get some instant confirmation because you have some centralized sequencer and as far as your transaction included, you can confirm, but for the joining from layer 2 to layer 1, ZK rollup usually takes maybe one hour or minutes, depending on your TPS. If your TPS is higher, like more transactions, you can just upload your proof faster because you know, one proof can be amortized over a lot of transactions. So it, it also depends on how many transactions you have in your system. For zkEVM,

because you your proving overhead had a larger, but another interest in design in our current system is that we have a decentralized prover system, which means for, we will generate multiple blocks in parallel. And for each block, there will be some prover to take this block and general proof. So all those blocks can be general proof in parallel. And, you know, we still get a high throughput, amortized and, proving in time is not a big issue on our platform. So the delay will be similar to other ZK rollups, but comparing with optimistic rollup, they takes around like seven days to get the finality of withdrawal transaction.

They are based on some game theory and, like economic assumptions. So they basically need an honest node to react secure the transactions, and challenge if they find this wrong. So they need to make sure that at least one honest node capture this. So they need seven days for withdraw from layer 2 to layer 1. I wanna kind of go a little deeper on this. You just mentioned the decentralized proover. I actually had a question here about like the agent that runs the operator of the ZK rollup. This is like, I always am trying to figure out what that is in every system.

So often it'll be called like a sequencer in certain things like the StarkWare setup. It's like they have a committee. I'm just curious, like, in your case, the decentralized proover is that acting as the agent that bridges over to the mainchain? Yeah, I think currently we have two of those, one day called sequencer and the other is called roller. So sequencer is for, you know, correcting transactions, receiving transactions from a user and a generator layer to block. And then like, you know, after you generate this block roller, like in our system is acting as a prover.

So it's actually generating a proof and the sequencer will send this block or some witness or execution trace to roller, and this roller will generate proof and send back the proof because currently the sequencer is centralized by the prover is decentralized because we can leverage the computation power from the network and then sequencer verify the proof from maybe get aggregated proof and some means the proof on chain. So it's, you know, still a centralized sequencer to generate block. And, but, you know, it's decentralized prover to generate proof for, for computation power. Yeah.

Quick question. does the sequencer have to provide some data availability proof also or just strictly a proof of execution? Yeah, actually, so the sequencer will provide the data availability. So I think you can mimic this like, in a way of the proposal and builder. So, which does sequencer now is the proposal. It generate the blocks, and then also like a sequence, the transaction and general the block, and then provide the data availability to the layer one chains, and then it will send like some like the transaction data or like the trace to the roller, which roller kind of generating the validity prove and upload it to the layer one. So to seal all of the transaction within that batch.

Right. Okay. Wait, so the roller actually publishes the proof directly. The sequencer only kind of gives them the transactions, both the data that's sampled as well as the execution call sites, but the roller posts the proof on-chain themselves, or am I getting the flow wrong of that? Yeah. Yeah. I think like that's the basic idea. So actually there will be some discussion, like just, in that way, like the sequencer, rollup they just send the data availability, roller send after validity proof, makes the system like the very easier to be decentralized, like in both, positions, like in both roles. I think that's like very natural way to do that.

Right. So actually one question is if I'm a user of the rollup, do I send my transactions to both the sequencer and the roller or do I send it to only the sequencer? Only to the sequencer. Only, okay, cool. That makes sense. Do you think you will decentralize the sequencer or not? Yes, we will. We will decentralize the sequencer. So it makes like the whole layer 2 becomes the trust list. So they don't need to trust any decentralized identity and also be more censorship resistance.

On the rollup side on the L2. Is there also any sort of like validator of the actual underlying data or is that the prover, is the prover sort of acting like that? Yeah, I think you can think of like the prover is acting like a validator, but you don't need to have area of the roller or we just call it rollers. yeah, yeah. To be, verified, all of them to participate into validate a block. You just only have like a few, like as a small committee to verify that, and then someone can roll up the validity proof to them. Quick question. On the point of decentralizing, the sequencer is the long term idea to basically have like a pool of machines that can be both rollers and sequencers.

Like people can sort of like stake in some way, and then they get randomly selected to one of the two batches such that like, you know, yes, there's a single sequencer for one slot, but you're you have some rotation or do you, do you view that as like too complicated? I'm just kind of curious, like what, what are sort of the different ways you're thinking of decentralized sequencer? I think you cannot, have like the people randomly selected for the sequencer or become a prover or r oller. so this is because the, it has different hardware requirement for different positions.

Like the sequencer, you just need to drain the block fast enough and to keep up the throughput, but for the roller, sometimes you may need some accelerators like GPU, FPGA, or like ASIC, to be really able to generate the proof fast enough for that. So actually there's different requirements for, different roles. So kind of like you just only, you can stake for become a sequencer or stake for become a roller. Yeah. I guess the reason I'm asking is more from the perspective of like, it is likely that to some extent you're gonna have quite a huge overlap in the actual entities that are running both of these, right.

Like someone who's already running a roller is already in a data center likely and like could easily run a sequence or node as well. So I guess the main question is like, how does that sort of change how you think about the sort of like allocation to these different parties? And do you think it's like something where, you know, you're fine with the election of a sequencer being sort of like not, unknown, cuz like, you know, at this point we don't really have like single secret leader election. Like there's sort of like some, you know, I mean, if you wanna implement the FHE needed for it, then I think you can do it.

But I think if we're still a little far away from that, so how much do you think that matters here and sort of like, how are you thinking about this fact that like the set of sequencers and the set of rollers will probably have pretty high overlap at least to start? Yeah. Expect to be more rollers than the, sequencers, because, in the sequencer we don't really need to, we just need to have like a handful, a few number of the sequences to be censorship resistant. But for the rollers, you kind of like, you need to keep up all of it, depends on like how fast it can generate proof and then what's the TPS you want to support.

So as like yeah mentioned before we have multiple blocks that can be generating parallel. So that means like you need more rollers to generating the proofs for those blocks. So that, or expect like there would be like a ratio we'll keep, we want to keep and then maintain and example like it's like the 10 to 1 or depends on the proof generation cost. So that would be like keeping some ratio to have like the more rollers to generate the proof in parallel. How are you thinking about block size as a function of number of rollers that are registered? Like do you view this as like a fixed block size type of thing or do you view it as elastic as a function of like the capacity of the number of rollers?

I think that it's still a fixed sized block. so it doesn't like the effect that how many rollers into support. So usually that the block size is limited by how many steps you can include in the circuit. So, and also can translate that into some gas limited you have for the layer 2 block. Yeah. I can add maybe slightly more because we are using a EVM circuit. So the largest like, you know, block size, you, you can support actually depends on like, you know, transaction, for example, like you've got some very complicated, maybe flashloan, transaction, it a needs to involve several contract loading and a lot of other opcodes.

So this will make your, your, your trace, your execution trace longer. So it basically depends on how complicated your transaction have and how many steps they need to be included in EVM. And that depends on the largest capacity of a block instead of just a number of transactions because different transactions differ a lot. Yeah. It depends on like how many steps you have for, for this execution on EVM. Right. So the reason I was asking this is I was like reading the StarkWare fee model, which like has sort of like a thing that, you know, it's not as aggressive as EIP 1559, but it like does adjust sort of the block size to sort of the number of steps. And they, they have a notion of step,

which I'm not sure if that notion is like, it's not as clean as say the EVM notion of a transaction as far as I can tell, but I was just more curious, like, you know, in Ethereum mainnet right, we do have variable size blocks now. Right. In the sense of 1559 does sort of force that. So I'm kind of curious, like, does that impact how provers have to interact with these systems? Because I could imagine something where, you know, if like the block size goes up, then like some provers, like stop proving because like their like relative economic share of the network went down. If the block size goes down, maybe it encourages more people, the economics of these, these types of things I think is very, you know, as we are seeing with StarkWare,

cuz they've had some interesting like fee market kind of things that have been happening in the last maybe like two weeks, I was just kinda curious, how, where do you see this evolving? Do you see it like being something where like the economics of these things are static or the economics are kind of like changing as a function of usage? You know, obviously it's, it's far out right now, but I think it will, it will be something that will kind of like impact how people think about writing code for that they run on Scroll. Yeah. Actually I think that's a very interesting question. I think that will also making like the, doing more research of like economic models, like how to separate these two roles and then how to keep like the both rolls incentivized. Yeah. I think for sure, like the block size,

I think will be dynamic, but mention that the circuit size actually is fixed. So you can have a prefixed, a circuit size, which you, you know, like how many opcodes, how many steps you can fit into the circuit. so that's like the kind of, that's the limiting factor for that, but in terms of economic models, I think we're doing like more research, see like how to keep incentivized. Like it can keep some of the base fee like then it can separate like base fee and me values, for example, like to use that, to reward different positions, different roles. So, but I think a lot of things like current today's still and theres some research. Yeah. I mean, I think it's interesting, but that like, by not being the first roll up, you can learn a lot from say like what's happening on StarkWare in the

fee market and, will be kind of interesting. Yeah. Yeah, yeah, yeah, totally agree. Also like that kind of learning a lot of things from the existing ones and then seeing like the, to avoid some of the mistakes to make, and then trying to like the, make things like the work most mostly here in the Scroll. I guess one other thing, you know, we've talked a little bit about how hardware acceleration was sort of like a key facet to getting zkEVM to work and hardware can mean commodity hardware, like FPGAs or GPUs. It could mean specialized hardware, like ASICs. How do you view that landscape evolving over, say the next one to two years.

And do you think that like at launch when Scroll launches you'll have, you know, FPGAs ready or GPUs ready or like, which kind of provers do you think will be there on launch and then live when you're live? Yeah, that, that's a very good question. So basically we are internally developing a very fast GPU solution because we are a software company. We have a lot of like, we hire some GPU, like programmers and also we started this research for GPU acceleration around like one year ago. So it's basically when we are online, we will definitely have our GPU prover already to support, to provide very strong computation power already to support very high TPS.

So I think in terms of the corelation between GPU, ASICs and FPGAs, I think GPU will be the first thing go to market and they first be practical to be used. And then like FPGA can win GPU, not in terms of speed, but in term of the energy consumption, like, you know, at the same speed up, like FPGA can be more energy efficient. And, but I think it means a lot of dedicated work to make IPGA really better than GPU because we have previous experience working with both IPG ASIC, GPU. So we, we know like pretty clear that, you know, although like you can build some customized units using FPGA and ASIC, but GPU still, especially our version.

We can be ten times faster than the best open source GPU implementation. So it's significantly faster and it's very hard to build a, build a new version, which can beat our current GPU version. But I know there are some efforts behind this building some FPGAs data center and they can be more like energy efficient. And I think it's also FPGA is a very important milestone, like before you have ASIC. And because, you know, there are some specialized operations, for example, Multiscale modification over a curve. Those primitives are highly parallelizable and can be more suitable for ASIC. So I think, you know, maybe within two or three years, we can have ASIC which can beat both FPGA and GPU.

And another concern behind this is that the zero knowledge proof algorithm involves like in one year, like you, you find something which is more efficient. So I think it's just basically achieving a later stage when they algorithm become more and more stable. Yeah. Yeah. I mean, I guess that's sort of always been the main question. So like having worked in building ASICs, like it takes you like two years to tape out, like you're not going to like, you know, by the time you verified your design, like yeah. Maybe like a new processor spec has come out. So I guess my question is, you know, in a space where, we can't even agree on the names of the precise architecture, we instead keep adding new suffixes to Plonk every two months or whatever, you know,

how much do you think that like the inflexibility of hardware versus sort of like the flexibility of design, like how you look at that trade off. Yeah, that's a very, very good question, actually. So basically currently most ZK algorithms, either you are Plonk or even you are Groth 16, or like, you know, any other algorithms. So they build on top of similar parameters. For example, they are like the most commonly adopted one, Multiscalar multiplication or any curve. And also FFTs over large field. And I think those two are the most important primitives.

If you get those components working really fast, then you can accept most ZK algorithms, but different algorithms differ a lot. Also it depends on your circuit arithmetization. You are using because currently for zkEVM. Although we already have the kernels for MSM and FFT implemented, but the workflow needs to be trend a lot. For example, we, we need like 1000 FFTs for our current zkEVM. And they did have coperate between like the CPU and also like the FPGA that becomes a new bottleneck. So, I think if you are with your algorithm evolving, the basic primitive won't change, but it depends on your circuit shape. Like, you know, how many custom gates you are using and it will influence the workflow and it'll,

it might influence your overall efficiency because some of other stuff can become the new bottleneck. And, they are also like, I think, those two parameters are commonly used in SNARK. In FRI there might be some small differences because they can always some group operation. That's also the reason why STARK is considered to be faster than SNARK because they are, they don't need either the curve. They don't need any group operation. They only need FFT or a smaller field and hash, but, you know, with the scalability increasing, it's also very hard to accelerate FFT for very large scale.

So it's still like a, a huge tradeoff, but the parameters underlying than change too much as far, your bitwise is fixed. And, yeah. I will say one funny thing about StarkWare, right. Is like the programming language still makes you have to think about field elements and like there's no strings and like ..., right? Like, there's actually like some funny things of like, you went to all this trouble to avoid group operations, but then like you actually still force a developer who may not, you know, totally understand what that means to have to actually reason about some of those things more directly.

And I think that's something that I think zkEVM hopefully avoids in the sense that like, you know, hopefully no one has to actually like really understand KZG to write like Uniswap. Yeah. Yeah, definitely. That's our priority. And to be the most developer friendly ZK rollup. I have one more question about what you were just saying with like the hardware acceleration. If you have these kind of like, you're talking about optimizations, but when you talk about optimizing ZK in this context, and this is actually about like EVM speed and gas fees on the rollup, I'm just curious, like, when you talk about optimizing those circuits, are you talking about making anything in the actual, like use of the L2 faster?

Or is it literally in like how quickly one could prove how cheaply one could prove how small the proof is? Like yeah. I'm just curious if it has any impact on the actual, like running of the network. Yeah, I think that's a good question. So, basically when I'm talking about hardware acceleration, so firstly that if you don't have, you know, good hardware support, you literally can't generate proofing time. For example, the zkEVM might take you five hours to generate the proof. So that's first thing, like, you know, it's important to make that practical. We already make that practical enough. And second talking about the cost.

I think still like, you know, with, with ETH price still, like, you know, at a very high, I think the data availability cost is still larger than the proving cost. Like, you know, the cost when you are storing your, your role transaction data on chain is still higher than the proving cost. So it's more about the energy consumption for generally proof. And whether you generate that in a more efficient way and with, with less cost, but for the fee perspective is not dominant by this, this proving cost. And, it, it might change after, you know, there are a lot of danksharding and EIP implement on Ethereum but currently yeah.

Mm. I wanna actually bring it sort of to a higher level, which is, you had mentioned that like the ZK and zkEVM is not about privacy. It's about almost like compressing or acting it's the roll up, but do you have any ideas for types of projects that would do best on something like a zkEVM versus something else? Either like the regular EVM base chain or like another EVM compatible, other chain that's been bridged to Ethereum? Yeah. So first of all, all of the existing applications, like the should be compatible with the zkEVM. And then I think for those, if you consider comparing some odd, layer 1 that's EVM compatible, so the bridge, I think becomes kind of the, one of the loophole inside of your security guarantee that sometimes that can be

easily attacked, but with the zkEVM. So the bridge, you can be guaranteed, with the validity proof. So that's, a lot of things like the more secure than some other, like the layer 1s. And then I think for those applications that have high stake and then requires those security and then also want to have high frequency, like the low gas fee and then with very high frequent transactions. And a lot of users, those applications will be very suitable for the zkEVM. I think another like direction we are also like actively researching it actually looking into is that, you know, as I mentioned, we definitely want to add some features the zkEVM. So for example, we can enable some like pre compilers or some, some new parameters,

especially on zkEVM, as some, for example, we build some specialized circuit for some hash function so that you can do that kind of crypto optimization, especially on our, the zkEVM in a cheap way. So that's something like, you know, we can definitely enable. And also, as you mentioned, like you care about privacy. So, but, you know, from our perspective layer 2 is beautiful scalability for reducing the conjunction problem on Ethereum layer 1. One, because you can't get both, especially under the account based model, it's very hard for you to get privacy because it's even for Halo, for some other company, they are building under a UTXO model.

So it's very hard to build privacy under the account based model. So I think privacy, like Aztec or some other techniques may be some other featured apps, specialized, maybe some smaller rollups. And we can verify the proofs in zkEVM. And so they can, you know, be some specialized, you know, rollups instead of, you know, a general purpose. But by adding some more crypto parameters support you know zkEVM, we can, we can support those proof verification more, more cheaper. And, yeah, things like that. Do you ever imagine being used like where part of Dapp is on the main chain and the other part is on the zkEVM, something like I've heard sort of the example of like maybe the governance module is on the rollup and something that happens rarely could still be on main

net, but they're somehow connected. Do you imagine something like that? I think for now, like we haven't like thought into that direction. It basically depends on like, you know, if you are doing something which is more computational heavy, you can move that off chain and the user cheaper proof instead of the, but the extra cost, if you are running, you know, zkVM or zkEVM model, it might be like higher in verification costs. So it depends on like, you know, how cost your initial computation can be comparing with your, your proof verification. So it's a trade off and yeah, it's a interesting interaction, but we haven't looked into that yet. Yeah. This actually though just brings up another question.

So I've been doing a series on like bridges and interoperability zones and all that. And one of the things is this idea of like general message passing. So I always think of a rollup, very focused on like, you know, is data availability and then it moves tokens. But I don't know, actually, if like, do you have messages also going back and forth between the L2 and like the main net? Like, are you changing state, like of account? Can you like basically send a message through your rollup bridge? Yeah, I think that's a good question.

So I think you can still send a message like through some of the specialized contract and then that can be forward to the layer one, I think that's totally possible to do that. Can it be executed there? Yeah, I think like as long you can provide extra, functionality in the bridge, like to having, not only sending some tokens along, and also you can say like, I want to invoke some of the small contract there, like on the layer 1, or like vice versa. You can say like the, on the layer 1, you can send some message and token along with invoking certain contract on the layer 2. So you can have this interoperability, I think, between the layer 1 and layer 2.

Yeah. That's just something I feel like at least I haven't explored enough. I mean, I do think one thing that gets changed with message passing, if you have an ability to standardize the messages and to fix sized proofs, is that people could generate the messages on, say Scroll for some computation they wanna do, and then send it elsewhere under like a fixed size packet. Right? So like maybe you do a computation on Scroll, you do some weird flashloan. You like have some kind of complicated thing.

You generate the proof and then you, you relay the proof to all the other layer twos via some kind of generic message pressing layer that actually is sort of a more full model than say something like Wormhole or Layer zero or Nomad. Right. Because they can't actually give you any guarantees on the calculation, unlike a ZK bridge. Right. Like they can only kind of give you very simple right now, at least simple transactions. And you do rely on kind of like the relays economic incentives. In that though, there's a new agent or new like operator you just mentioned, like that's a, between L2 message passing system. Right. Not going through the L1?

I think, what you could do is you have the, between L2 that falls back to L2, I guess that's like closest to nomad in design land right now. Okay. But it doesn't require like staking on all the chains right? Like the problem with something at Wormhole is you effectively have to your capital, efficiency's kind of low. You have to stake on every chain and like the amount of stake at every place determines sort of the security. But I think the idea is if you have a ZK, a single ZK chain that does the computation and generates the proof, and then you only have to send that proof, that sort of economic value of that proof is a lot lower than like, Hey, I have to move coins on the other place. Right. So, so there'll be like a lot of weird like capital efficiency trade offs.

I think when you start thinking about like ZK L2 stuff versus optimistic, or versus like, you know, Wormhole sale things where it's like, you have synthetic assets on both sides. Cause the synthetic asset is not free. It does require like a bunch of capital to kind of be backing it implicitly. No, not that there's not a place for all of those. Right. Like they can get to production faster. Right. But I think it will be interesting in the long run to see how ZKs change, how much capital you actually need to have on every chain. Like right now it's like quadratic. In the number of chains, right? Like you basically need to have capital on every chain.

And then the minimum amount depends on every pair of chains. And in some ways, hopefully a ZK thing lets that be less, more efficient for message passing. Sorry. That was just my rant. Little rant about that. Sorry that, that wasn't like any, anything that anyone is doing right now I'm. No, I think that's a very interesting like topic to discuss. I think in the future there will, could be like some interoperability between the, even two ZK rollups, like two ZK layer 2s. So I can directly like the allocate the funds in different places and then execute it at a different place, I guess. So I guess one thing that I think is kind of cool about ZKPs is that you get almost like a interoperability standard built in, right.

You only have to trust the verifiers written correctly, which is a lot lower of a workload than having to trust that the VM translation is written correctly. Right. Like you can argue that like the optimism bug, that was found and then the wormhole bug both have this problem of like there's two VMs. That don't exactly agree. Right. They're not bit wise identical. Yeah. And the translation layer was where like the bug of the synthetic thing happened. But the ZK thing, as long as the verifier contract is correct, it's you have basically perfect interoperability.

And so I think that's a just lower surface for bugs and errors. You know, I think once the ZK rollups are live, it'll be way easier to do this type of stuff because you'll have all these networks of provers who are already validating this chain and you can basically be like, Hey, can you like generate this proof that I can then relay somewhere else? And it doesn't matter who relays it. That's really interesting. I guess, going back to Scroll though, do you have ideas of like, I mean, you're still building, we should find out actually where you're at in this build, but like, I mean, I think this kind of brings us to the question of like at what stage is the project, what's your timeline for actually having, you know, us be able to play with a zkEVM?

So we have like the design two phases of like for Testnet and then we're quite close to have our, phase one Testnet, which like we are almost like 70% done. And then right now we can already support some ERC 20 transfer on the zkEVM for on the zkEVM, everything works first, mostly like expected. So we'll see like our first launcher testnet in, like a few one to two months. and then I think like then in the phase two, so in the phase one, we probably like the support, some limited, off codes and then some of the transactions.

And then the phase two will be like the full compatibility, zkEVM Testnet so that like every smart contract that supposed to be able to run on the extreme should be able to run on the Scroll testnet. Cool. What applications, you know, obviously it's just like early in this space and you know, who knows what the real application was like 2016, Ethere you couldn't have predicted most of the things that exist now. What are kind of the applications you're most excited about being enabled by Scroll that, you know, you've kind of heard of or thought through? I think, those I found for the consumer facing applications, like the target for more and then some social applications, close to like the more users, like not only the DeFi applications,

that's only targeted for some financial applications, but more like the custom facing application for those like social applications. Like there be like very interesting use cases and also to enlarge the whole, user space for the blockchain, for the cryptocurrencies to bring more new customers to the blockchain and the crypto world. Mm cool. Yeah. I think from my side, like, you know, because I'm a ZK guy, so I want to see more ZK applications and yeah, especially on our platform and they got like cheaper proof verification. Maybe we can support more, more stuff to support those interesting ZK applications. Yeah.

Awesome. Cool. So I wanna say thank you to both of you for coming on the show and sharing with us sort of the journey to Scroll and your thoughts about zkEVM, what that could enable how it's built. Yeah. Thanks a lot. Yeah. Thanks for hosting. Yeah. Thank you Anna and Tarun for hosting us and having us to hear it's very pleasure to talk to you guys, on a ZK podcast. Looking forward to the next one where we, we learn more about how, how Scroll live is working. Yeah. So I wanna say big, thank you to the podcast editor, Henrik podcast producer, Tanya, thanks to Chris for research and to our listeners. Thanks for listening.