Anna (00:00:05):
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. I catch up with Jordi Baylina and David Schwartz from Hermez to talk about zkEVM. They share an update about Hermez, since their launch on mainnet earlier this year, we talk about the L2 landscape, zk-Rollups and how different teams are approaching EVM compatibility on their respective chains. We then dig into zkEVM, a model where they are using zero knowledge proofs throughout the architecture to give it the characteristics of a rollup that is cheap and fast, while still allowing for this EVM to run and compile in the same way as the Ethereum EVM. And this episode was also recorded just days before the team made a massive announcement about the Polygon/Hermez merger. So do stick around to the end of the episode, we recorded a little bonus bit about this and what this would mean for the zero knowledge ecosystem.

Anna (00:01:14):
Quick note, before we start, if you haven't already seen it, the Zero Knowledge Podcast website was recently updated. There's all sorts of new ways to engage. You can check out the blog, you can actually post on the community forum, get in touch with us, sign up for newsletters, check out the YouTube videos. They're all there. And I'm really excited that it's come together in one place. Do check out the new Jobs Board as well. You can actually post your jobs there yourself now, as a hiring team. And if you're someone looking for a job, there's much better ways to sort and filter now. So yeah, hope to see you over there.

Anna (00:01:49):
One more point before we start in on this episode, I want to thank this week's sponsor, Mina Protocol. Mina is the world's lightest blockchain, powered by participants. It's a layer one protocol working to connect crypto to the real world. This means developers can leverage private verified real-world data from any website to build decentralized apps. Mina's decentralized apps, which are called Snapps, also allow users to access on-chain services without sacrificing personal data privacy. And Mina is a unique blockchain. It's replaced the traditional blockchain with a zero knowledge proof, ensuring a super light chain that stays around 22 KB and allows every participant to act as a full node. Mina's mainnet has been live for a few months and the ecosystem is growing fast. So join the community and find out more by visiting minaprotocol.com. Quick side note, I am both an advisor to the project and a validator with the ZK Validator, so that's also another reason why you should go check it out. So thank you again, Mina, for sponsoring the show. Now here's my interview about zkEVM with Jordi and David.

Anna (00:02:53):
Today I'm here with Jordi Baylina and David Schwartz from Hermez and Iden3. Hi guys.

Jordi (00:03:02):
Hi.

David (00:03:02):
Hello, Anna.

Anna (00:03:04):
Jordi, you were on the show pretty recently, actually, you came on to talk to us about Hermez. But today's episode, what we want to do is actually dig into zkEVM. Something that a lot of us learned about only at EthCC about a month ago. So yeah, I'm really excited to learn more about this. David, this is the first time we're meeting. Maybe you could quickly introduce yourself and tell us what you're working on at Hermez.

David (00:03:28):
Sure. Thanks. Well, my role at Hermez is the project lead. I'm trying to push the project forward and to coordinate the activities and also working very hard on the product side of the technology we are developing. So yeah, this is an amazing moment, especially for Hermez, and probably we can discuss a little more today, but yeah, amazing time.

Anna (00:03:52):
I mean, we did do an entire episode on Hermez and so I will link to that in the show notes, Hermez and L2 that is, as far as I understand, it's it's live, right? It's been live for some time.

Jordi (00:04:04):
Absolutely. It's in production, right now it's forging a block every 10 minutes and there are many transactions and it's just a service that anyone can use it there.

Anna (00:04:15):
Maybe before we dig into the zkEVM, the topic of this show, I do want to hear what's new. I think our interview is back in January, so this was before the launch. I'd love to hear what's happened since then and maybe what's potentially coming up. I don't know how much you can divulge, but...

Jordi (00:04:39):
Yeah, David, maybe you can answer.

David (00:04:43):
Yeah. From the last interview, I was not there, but I guess you were discussing about the launch of the Hermez Network. At this point, we were launching the first release of the Hermez, where we were focused basically on payments. And yeah, we became live, we are mainnet, we started the initial steps towards network stability. And we started then to do some promotions of the network, to launch some activities in order to test that the system was stable or secure. And from here we have been building the next steps or working behind the scenes to launch the next features. We also shared the public roadmap a couple of months ago, where we just announced the whole activities and features for the whole next year. And yes, this is basically what we have been doing. We went to Paris EthCC, where Jordi introduced the zkKVM at this point, because we want to share with the community the work we are doing, in order to just get contributors or just provide new ideas and also get new ideas from the community. And at this point we are very focused on this project of the zkEVM. And on the other hand, we continue developing the product features for the first version, based on crypto payments. So this is the current situation.

Anna (00:06:10):
Maybe we should define, even though we do have an entire episode on Hermez, maybe you can tell us a little bit about what makes Hermez unique in the L2 landscape?

Jordi (00:06:19):
Well, Hermez is decentralized and the protocol of Hermez is designed it to be decentralized. That means that the coordinator of a rollup, anybody can be a coordinator. It's true that right now it's not worth it to be a coordinator, because there are not so many transactions there and being a coordinator, it's a little bit expensive, but once we reach this breakeven, which in the case of Hermez is the lowest breakeven. So right now the Hermez is the rollup that has most cheap transactions in cost terms, so we are very close to get this breakeven. Then new coordinators will start bidding for slots and start forging batches. And this would give the decentralization, all the protocol is designed to be fully decentralized. And this is quite unique. I would say that this is mainly the two big differences: protocol that's fully decentralized by design, it's governance-less, at some point there's no governance, just a product that's working there. And the cost of the verification, the cost of batching batches is the lowest in the space right now.

Anna (00:07:36):
Would you say, I mean privacy, it doesn't sound like it's one of your current unique propositions, but is that something that you do see as part of the roadmap?

Jordi (00:07:46):
It is, but right now we are more focusing on zkEVM. So zkEVM in some way brings privacy, because with zkEVM you can do whatever. But yeah, here we are more focusing on zkEVM than, let's say, private payments in some way.

Anna (00:08:07):
Got it. So when we talk about this EVM and EVM compatibilitiy, zkEVM, in the current L2 landscape, are there any L2s that are already EVM-compatible, would you say?

Jordi (00:08:22):
There are projects that's working in EVM-compatible and here we are, again, we are talking about 2 big groups. One is the Optimistic groups. For them, I would say that the EVM part is easy. They have the problem of this challenge game that they have behind, including EVM, it's a challenge, but it's not such a big challenge as it is for zkEVM. And in this, I know that for example, Optimistic is working on this way and all the Optimistic projects are working in that direction. In the zk side, there are different projects that, some way or the other, are working on that. zkSync Matter Labs for sure. StarkWare is working also in that direction. I know that Loopring is also starting to do something in that direction, or at least thinking on that. Of course, Aztec people, they are also doing a great job in that direction. Even the Ethereum Foundation is working, maybe more in the research side, but is also working in that direction, because it's important at the end, we are talking about scaling smart contracts. So this is an important piece, and there are many groups and many people that, some way or the other, maybe with different approaches, with different things, but they are working in this path.

Anna (00:09:45):
Got it. Where do you want to start to explain what zkEVM really means?

Jordi (00:09:49):
Right now, in the current Hermez, that's in production right now, you can do payments, you can do transfers. It's a bit like Bitcoin, you can do just transfers in there. With zkEVM, actually, you can run the smart contracts. The idea is having a rollup, exactly the same that rollup, but instead of doing a payment, you can deploy a smart contract and make a transaction in the smart contract, and this is a big difference, a rollup that's actually good in smart contracts. That's mainly what it is. And in the case of zkEVM, just to be clear, zkEVM is zero knowledge Ethereum Virtual Machine. So the Ethereum Virtual Machine, the EVM, it's actually the virtual machine that's running on Ethereum, smart contracts are executed in these VM. And zkEVM, it's just having a rollup that's executing exactly the same smart contracts that are currently running on Ethereum. That's what means zkEVM.

Anna (00:10:49):
I watched actually that presentation that you gave at EthCC and in it, you talked a lot about opcodes, opcodes that would normally be in, I guess, running on the EVM. I don't know if that's how you say it, but what do you mean when you use that term opcodes? What do those look like? Or maybe what are some examples?

Jordi (00:11:06):
Yeah, opcode is instructions. So when you do a smart contract in Solidity, this is compiled to a machine language. This machine language is Assembly, if you want this machine to run, but it's composed of a category of different opcodes that it's executing. And these are the instructions that... The final instructions that actually is running in the EVM. These instructions include, for example, doing an addition, pushing a value to the stack, setting a value to memory, recovering a value from the storage. These are these very, very small instructions that the virtual machine is processing every time you do execute a smart contract. So the idea is the compatibility, when we are talking about opcode-compatible, [it] means that we are able to get this compiled program with all these instructions, with all these opcodes. And you just take it and run it in the zkEVM, without transpiling or without doing anything. You just [have a] fully compatibility in this side.

Anna (00:12:13):
On the developer side, I'm guessing they could use the same tooling, but on that compiling part, is it actually compiling into something different? Or is it actually following the same thing that you'd see on an EVM?

Jordi (00:12:25):
There is a difference, the difference on the approaches, when you are doing opcode-compatible, actually you can use exactly the same compiler and you get the result and it's just like having a sidechain, but in this case it's a rollup. You just take this transaction, you just run it and you don't need to do anything else. Just get this code, this smart contract you deploy, you use the same tooling and all that stuff. There are other approaches. They actually, they change the compiler. So instead of compiling to this EVM, to these EVM opcodes, we are compiling to another set that maybe is more zk-optimal opcodes, and you just execute these in different virtual machines, that's not opcode-compatible. But maybe the Solidity program, you can compile it into different machines. These are the two approaches.

Anna (00:13:20):
Got it. So what you're saying is from the developer side, they would still be potentially just writing a Solidity contract, deploying it, but what's happening under the hood with zkEVM, it's actually following the same path that it would on the original EVM.

Jordi (00:13:34):
Yeah. It is very, very similar. You don't need a different compiler. You don't need a different toolset. You don't need to care about special things. Just do the same. Just like having a sidechain, a sidechain with a rollup.

David (00:13:49):
We are bringing the opcode concept to the table, because when you go into the details on what a zkEVM implementation means, you need to go into this level of details. To go down and say, "Look, implementation of this EVM means that we need to be compatible for the same set of operational costs that is built on machine supports". So the challenge is to analyze every single opcode that Ethereum Virtual Machine supports and figure out how to implement that. And everyone is saying the same. I mean, we have two options, whether we can just build a new built-on machine with a different set of opcodes and compile Solidity programs into this virtual machine, or we can figure out how to build, from bottom to top, code and a system that is the same set of opcodes and that the Ethereum Virtual Machine. So you can be able to port existing Solidity or existing smart contacts code directly to this new system? So this is the way we are bringing this opcode to the set and discussion to the table.

Anna (00:14:51):
Would that mean... You talked about each opcode, but are you forced to go into each particular opcode and reimplement it? Or is it more like a general reimplementation that's happening?

Jordi (00:15:04):
No, no, it's a very detailed. You have to go each one and try to keep the compatibility as much as you can there. It's not a general thing, it's opcode by opcode and structure by structure and trying to be as close as possible to the current Ethereum Machine.

Anna (00:15:23):
How many opcodes are there, actually?

Jordi (00:15:25):
I need to check it, but it's about maybe 50. I need to check.

Anna (00:15:30):
Okay. I was thinking you were going to say something like thousands. It's 50... Okay.

Jordi (00:15:37):
A lot of them are repeating once. For example, we have PUSH1 byte, PUSH2 byte, PUSH3 byte, PUSH4 byte. These are 32 opcodes, but actually it's the same. So let's say it's around 50, maybe 70 altogether, but there's few tens of opcodes.

Anna (00:15:58):
I want to hear a little bit about the zk part of this. So what you've described is sort of the rebuilding of an EVM, from the opcodes individually rebuilding them, but where does the zero knowledge come in? Cause when you're saying you're rebuilding it, it sounds like that's maybe what you have to incorporate somewhere.

Jordi (00:16:15):
Well, at the end, it's like rollups. You have a set of transactions that execute smart contracts, like Ethereum transactions, there's just these transactions, and you are aggregating and you are processing all of the transactions. And at the end computing approves that all these sort of sections are well computed. And this is where zero knowledge comes. The thing is that you verifying that the payment is valid is quite easy. Verifying that a transaction that needs to be executed with all these opcodes and memory and all that stuff is valid, is much, much harder. But at the end, the idea is exactly the same that the standard rollup, you need to verify that the set of transactions... So you go from a state A, to a state B, when you execute these 100 transactions. So you need the proof that state B is correct, without having to compute everything. And you verify that. And so the idea is exactly the same that a normal rollup. Here, probably the word "zero knowledge" is not the right one. It's more the verification of a computation. Actually zero knowledge, it goes very close, because this succinct verification, it's a property that we are sharing, it's the same technology in some way. But they are used for very different things, zero knowledge is to hide some inputs or to have some kind of privacy in general. And the other part of the zero knowledge technology is more for a succinct computation or for verifying computations in a succinct manner. And in the case of the rollups, we are using very much the second property, it's the most important for rollups.

Anna (00:18:04):
Going back to that Optimistic versus zkRollup, it's like the fraud proofs versus the validity proofs, I guess you could call it.

Jordi (00:18:10):
Exactly. The validity proofs is what we are building here, we are building a validity proof, set of transactions, creating a smart contract or executing smart contracts are valid. This actually what we are doing.

Anna (00:18:21):
So the zero knowledge proof, in this case, it's not a privacy proof, you can actually see both sides of this action. I guess the question here is does all of the EVM, in the zkEVM, does all of the action just happen within a bubble? And then every once in a while, with the zero knowledge proof, gets checked to the main chain? Or is it like each transaction or each change, each... I'm just curious, at what point are these zero knowledge proofs actually being used?

Jordi (00:18:52):
In the case of the way that we are building zkEVM, actually, we're embedding 2 proofs, 2 proof systems in there. So mainly we are generating a STARK and then we are verifying a STARK with PLONK or Groth16. So we are like a proof of a proof. And the idea is that we are combining 2 proof systems to get the best of each one. So the STARKs are very good, but they have a problem that the proof size is huge. And you can verify it on-chain, but it's very expensive. So what we are doing is we are building a Groth16 or PLONK proof that actually verifies the STARK. So because the STARK proof just become a private input of the next, the sides of the STARK doesn't matter anymore and we can use all the advantages of the STARK and get also the advantages of Groth16 and PLONK, which is a very cheap verification on time and very small size proof. So combining these two things is very good for this. Actually STARKs, they have another important advantage is the verifier. So it's quite easy to build the verifier in Groth16 circuit, because verifier of a STARK is just using a single field element, so it's a single field. So if you are using the same field that the Groth16, then the verifier is very, very cheap and very easy. So the Groth16 is going to be... It's just a proof, but the number of constraints is going to be quite small, compared with a real proof that's going to be in the STARKs in some way. So it's just we are combining these 2 technologies, we're combining PLONK, we're combining Plookup, we're combining a STARK, we're combining Groth16, we are putting all the things together and we're building the zkEVM. That's very much the challenge that we have in front.

Anna (00:20:56):
So is it like the first proof would be a STARK, which ends up resulting in a very large proof, but before you're actually... This all remains within the zkEVM, still in that space. But then because you have this large proof, are you then using PLONK almost as a compression, to then prove that large proof you use PLONK to create a small proof and that's what you have to verify. And that is why it's cheap?

Jordi (00:21:21):
Exactly. Perfect. I think you explained it perfectly.

Anna (00:21:26):
Cool. Okay. But the one part I still don't understand though, is where are the STARKs starting? Every time anything occurs, is there a STARK attached to it? I'm just curious, where did those come from? Where are they living in this process?

Jordi (00:21:41):
I'm not sure, if I'm using here the word STARK correctly. But the idea is that we are using the FRI proof, the engine of STARKs, to verify polynomial commitments altogether. So this is what we call a STARK, probably it's not a STARK, this is not a thing, but we are using the same technology, as a STARK, this FRI, to verify all the polynomial commitments. We have a lot of polynomial relationships. The EVM has hundreds of polynomial relationships, because EVM is complex. But all these proofs are together with the STARKs. All this proof is verified inside the Groth16 circuit or Groth16 or PLONK circuit, it's more or less the same, depending if you want trusted setup or not, PLONK is a little bit more expensive, but we'll have the trusted setup. Groth16 is cheaper, but it requires the trusted setup ceremony. So we're probably starting with PLONK. And maybe at some point, if this goes, maybe we'll do Groth16 trusted setup ceremony and so on just to stabilize that. But that's the long-term. But the circuit is the same or it's very... So you can reuse the circuit in groth16, and then in PLONK. Actually, for example, in SnarkJS, we updated the SnarkJS some months ago that right now supports Groth16 and PLONK. It's the same with Circom, so other programs writing in Circom can now be verified. You can convert it to a groth16 proof system or to a PLONK proof system. Everything is more the same. STARKs is, FRI is, it's like a different world. It's a little bit different altogether.

Anna (00:23:23):
I think the question that I still have though, is, going back to just the opcodes, you mentioned the polynomial commitments, but is it on the execution of an opcode? And I might be mixing up some things here, by the way, it might be like state transition is actually what I'm trying to say. It's like you're going to be using FRI. You're going to be running, you're going to be basically generating one these proofs at some point in the process, and I'm not clear, is it on an execution of something? Is it when there's been a state change that you would prepare one of these things? Or is it after a batch of activity? Like activities have basically happened and then you just clump it together into a polynomial commitment?

Jordi (00:24:05):
Well, let me try to explain a little bit in the more... Not to be more complex than that, but just to be... We have different opcodes. So the idea is to have many state machines that execute opcodes. We have, for example, a state machine that executes modular multiplications, another state machine that's doing binary operations, another state machine that's doing memory operations, another that's doing storage. And we have different state machines, each one very specific for a specific opcodes, very specialized for doing specific opcodes. We use polynomial commitments to verify the state transition initiation of the state machines. So we have these. Now we need to link them all together. So the opcodes that we are verifying in these state machines should be the ones that are executing the main program and the same with the memories and the hashes that we are computing. And actually the same that we are computing when we're doing the storage and the storage needs to be computed. So we need to link all these state machines. And here are the keys, the Plookup. Plookup, the idea is we have different polynomials and we are just relating one each other at the end, Plookup, what they are doing is "Okay. This polynomial is included in this other polynomial". That means that it's... The opcodes that I'm securing in this specific state machine is actually the one that I'm creating. And for this, the key is Plookup. But Plookup, at the end, is done with polynomial commitment. So you have the polynomial commitment to have before we have the new polynomial commitment that we have to work out. So we end up with a set, a full set of polynomials. Polynomials everywhere, polynomial commitments everywhere, and a lot of relationships that the verifier needs to check about these polynomials. So this is what we have. And so all these polynomial commitments, at the end, these polynomial openings. All these... We use FRI to do all the openings of these polynomial commitments that we make, with all the verifications. And all that we do it in the circuit, in a Groth16 or a PLONK circuit. And the result of this PLONK circuit, is actually what goes to the blockchain and is verified on-chain. This is a little bit the scale.

Anna (00:26:12):
Yeah. Okay. So, I mean, you've touched, there's two things that you just brought up that we might want to clarify a little bit. One is Plookup. So this is PLONKup kind of Plookup? This is also from Aztec, I believe.

Jordi (00:26:28):
Aztec, yeah. It's Ariel. They came up with this construction. It's a very cool construction and it's very, very powerful. It's used in many things. And it's a very powerful piece of building of these systems, because this is the glue, it's what allows to connect these virtual machines, to glue them together in a single proof.

Anna (00:26:53):
Are these proofs, are they being created after every transaction? Or are they being done after a batch of transactions?

David (00:27:00):
Yes. These proofs, it's the same concept as the current zkRollup. We are creating these validity proofs in the form of a batch. So we process, we have a queue and this queue receives the transactions from the users, and then the Hermez node just select the data load, the best transactions to process. And they do this processing off-chain layer two, when you just change the states and so on, you execute all this processing off-chain. And the interesting thing here is that once in a batch, you just create the validity proof of all the set of changes in the system, at the same time. So the proof that we are building is the same concept that a zkRollup of transactions, it's one proof every whatever number of seconds, with a maximum number of transactions in the same batch to be more efficient, but it will be one proof in proving a lot of transactions at the same time.

Anna (00:27:59):
You had mentioned that storage, there is a method that you're using... And maybe I didn't understand this, but are you also using these polynomial commitments and that structure to manage storage? Or is there another way that you need to think about that?

Jordi (00:28:17):
Well, if we want to maintain full compatibility with the current zkEVM, we need to use the current Patricia Trie, it's a kind of Merkle Trees, that's used right now the Ethereum Virtual Machine. There are new ideas for replacing this Patricia Tries away, maybe using some binary trees or other sort of trees, or even polynomial commitments. And there are different, Verkle trees that was talking Vitalik at some point. And there are definitely ideas there. I would say in the zk side and even in the Ethereum side, so Ethereum, probably they will upgrade at some point and remove the Patricia Trie and go to a different structure for storage. This is something that's open, but something I would say in both sides. And in our case, the idea is to be compatible with all these Patricia Tries, but it's possible that maybe we go with an easier, maybe with a normal tree, easier trees. And maybe we just break this compatibility, because this is not an opcode, so the programs should still work and this will be more efficient. And this is something that we need to consider and to evaluate, but these are different options there.

Anna (00:29:31):
I want to understand maybe how what you had described, going back to those earlier ideas of other zkRollups looking to do EVM implementations. So you had mentioned StarkWare, zkSync and that Loopring might be thinking about it.

Jordi (00:29:45):
Ethereum Foundation too.

Anna (00:29:45):
Lots of people, I guess. How are they approaching this? You described using the STARK and then using the SNARK. But in the case of STARK, where would they also be doing something like that? Or do you think that they're approaching this in a different way?

Jordi (00:30:05):
It's different, because we have different engineers, so we have different ways of thinking and different tools and things and never the same, which is good or bad. I think it's good to have many projects, each one trying their best way. This will help a lot. And there is communication. We should learn from one each other. And this is something that in some way we are promoting and it's quite happening, I would say, in this space for this knowledge sharing and understanding what do we need, each one, just to learn. But it's not clear what's the best, the good at this point is. Just try it, do it, and then we'll see, and that's a cool thing in theory. It's like no good approach or bad approaches at this point. I would say that all approaches are good at this point. Or maybe at some point, some of them will maybe ask, we'll just say, "Okay, this is a bad approach. We just were wrong. This is not good because these are bad". And then we just explain, we tried to learn and work around and whatever. This can happen to us, it can happen to any of the projects, but that's cool. Again, important is to scale smart contracts. That's what we are coming at projects.

Anna (00:31:21):
And everybody's trying to do that. But actually my question is more like, do you know what they have planned? And how does it compare? Not which one's better, but just is it a very different approach? I'm trying to understand how they look at it.

Jordi (00:31:33):
For what I have read and what I have listened, there are different approaches, in some way, but that doesn't mean that those approaches are wrong. They are just those approaches.

Anna (00:31:48):
I mean, but can you speak about them? I'm mostly curious if you know what they are.

Jordi (00:31:52):
Yeah. I think we explained, for example, Matter Labs is going more in this recompiling and having their own opcode. Their own code, their own way to build a machine and compiling Solidity to this optimal virtual machine. STARKs, they also have their own virtual machine, they have a project also to port the EVM to this virtual machine in some way, I'm not sure about the details. You should ask them and hope they are doing that.

Anna (00:32:20):
Totally. Sounds like I should have them on the show.

Jordi (00:32:20):
But it's in their plans and they're working also in that direction. As far as I know, the Ethereum people is thinking very much in Halo, for example. They are considering Halo or some techniques that use Halo. The approach is more similar to us, be more zkEVM. So EVM come fully EVM compatible, of course. We are talking with lots of these projects. And in the technical side, we are just sharing a lot of information and it's like we are learning every day.

Anna (00:32:58):
That's awesome. Going back to what you've actually, or what the design for zkEVM are, is the idea here that it will support all opcodes? It will be actually one-to-one? Or are there some limitations that you could foresee here?

Jordi (00:33:17):
Definitely there are opcodes that are more difficult to implement [than] the others. And it's possible that maybe the first version does not include the full opcodes or the full pre-compiled smart contracts, but what's cool is at this point, I don't see any stopper on any opcode to be implemented. Even the most complex opcodes or even in this case they are not opcodes, but they are pre-compiled smart contracts that are important, like pairings or big numbers, smart contract, or Keccak hash function. All those look like they are doable, it's just a matter of building. And [we] need to see the efficiency. And we need to see how it matches this all together. But I don't see an a priori stopper for any opcode. There are opcodes, it's true that there are opcodes that are very specifically layer one opcodes, that they will have to have some special treatment. For example, DIFFICULTY, there's nothing similar to DIFFICULTY in layer two. But what happens with this opcode? Well, maybe it's a hardcoded value or something like that, or block, there is no blocks. Maybe it's equivalent to batch. Maybe the zkEVM will have some extra opcodes that are more layer two-related. So it can be some, I would say, adjustment, because it's different. It's not a layer one or layer two, and there are some opcodes that you need to... There's, for example, the Optimistic people, they already did a good work in adapting these specific opcodes. And this is something very concrete and very specific to that. The important ones, opcodes that are very complex, but they are doable, like CREATE, an opcode that can create another smart contract. That's hard. CALLs or DELEGATECALLs, or of course, a storage or even these pre-compiled smart contracts. They are, like signature verification or pairings, or all these things. Those are doable, at least in the approach that we're building, we know how to build them, we need to see how efficient and how they fit in altogether. But at least, from the theoretical perspective, they are achievable. That's why we want to, at some point, build all of them. They need to be as much compatible as we can. That being said, the gas thing, for example, what's happened with the gas, they'd asked to try to be as compatible as possible, but there are going to be a difference between layer two and layer one, and maybe there are some adjustments that need to be done in the future. But when you are doing this, it's like you're finding a lot of things on what happened with this and what happened with that? And you are solving this, or maybe having a workaround or some solution in there. And the goal is to be as compatible as possible.

Anna (00:36:23):
Do you imagine actually, in these environments, that it could go even further? That it could become a realm of experimentation, because you're not necessarily, you don't have the same constraints as the L1. I don't know. Maybe it's a ways off, cause they're were saying the first release probably won't have all of them. So once you get to all of them, could you go further?

Jordi (00:36:45):
Yeah. I don't know. So it's like...

Anna (00:36:55):
Come on, Jordi, do more!

Jordi (00:36:55):
I would be happy right now if we have a small set of opcodes working. But yeah, we'll see. This is our first approach. There are things that this work... And just talking about the long future, if you're talking about these fiction things. But the one interesting thing of doing this opcode-compatible approach is that a lot of the work can be used for verifying L1 blocks. This is, for example, is something like protocols, like Mina Protocol, things like that. I think Celo is doing something similar, that's like you can, especially for light clients that you are... So each block has a proof that verifies that the last block is valid. Then you have this kind of recursion. If you have all all this proof that actually verifies all the transactions that are processed, and in this case a batch, you can have a verification that all the transactions that you process are included in this block, maybe you should have the consensus verification, proof of work, proof of stake or whatever there, and then you could have a recursive verification there. So that's something that... This is not our main goal, our main goal is to build the zkEVM rollup, but all the work that we are doing could be used in verification. And this will be good for light client, maybe for using these blockchains in mobiles and having a client, light client, in their mobile. This is something that's good evolution for Ethereum. But again, this is long-run future, that said it gives you an idea of the importance of the work that we [do] in Hermez, but also all the projects that are working in zkEVM or zk, zkEVM at least projects, because this will help a lot to go in that direction.

Anna (00:39:02):
Jordi, you just mentioned gas. And I'm actually curious, what is the strategy for that? Do the L2s in this EVM... Does it have to have the equal gas model? Can you get rid of gas completely?

Jordi (00:39:18):
It's a hard topic maybe, it's a problem of the gas is that a lot of the security of the Ethereum smart contracts, of the security model is based on the gas. So if you want to have a compatible EVM, you cannot change, at least in the initial version, these gas models. So the idea is to keep this gas model as compatible as we can. So the idea is to keep the same gas model altogether. But said that, the gas was designed that to be for L1, it was not designed for L2. So probably there, in the future, you can see maybe changing some gas cost and even the gas model in the zkEVM in a different way that makes more sense. But it's something that needs to be studied and our goal, at least in this moment, is to be as much compatible as we can to the current. We want that the developers that are building smart contracts in L1, they can use the same tooling and go to L2 and it work.

Anna (00:40:29):
What would the base gas token be denominated in though? Is it denominated in the native Hermez token?

Jordi (00:40:38):
No, it's still on Ethereum.

Anna (00:40:38):
Oh, it's still on Ethereum. Okay. Even though it's within the zkEVM?

Jordi (00:40:41):
Yeah. You can choose whatever you want. But I think that the one that make sense is Ethereum.

Anna (00:40:49):
Is it like a synthetic Ethereum though? Is it like Ethereum locked on the L1, moved over to the L2 that's then used for gas? Or is it..?

Jordi (00:40:57):
Yeah. It's like a rollup, you probably will have to deposit and then have some smart contract to get the Ethereum from there.

Anna (00:41:03):
Got it.

Jordi (00:41:04):
It can be anything. It could be any, but the idea is to be Ethereum.

Anna (00:41:09):
Cool. I have a higher level question about EVM compatibility in general. We've talked very much about the different solutions, the ways that zkEVM aims to allow for this compatibility, almost a one-to-one, in terms of compiling and it's sort of this equal system, but why do you even want the EVM compatibility? Why would we want an exact EVM copy? Is it because it's such a fantastic system? Or is there some other reasons that you see?

David (00:41:42):
Well, I can provide my comments here. I think we weren't trying to solve from the beginning the scalability problem of Ethereum, in the first place. So we want Ethereum to be able to support more transactions. So of course we can build different systems, but this will be a different project. I think what Jordi just said regarding the gas and the security model is very important, because there's a lot of smart contracts developed. There's a lot of audits done on existing smart contracts, and the security model needs to be respected, in order to manage the change to a zkEVM. So if you build a different system, all this technology needs to be analyzed to see what's the impact on that. And the zkEVM tries to be compatible at code level and to respect the gas model, in order to behave the same as the EVM, so this will be very easy for developers to just migrate contracts to the system. And this will allow existing projects to migrate. You don't need to recompile it really, you just move contracts. So this would be a huge benefit, in terms of adoption, because if you do different things, probably you will face friction in some way.

Anna (00:42:58):
The setup that you described though, could you ever use that to build out a different kind of VM? Do you know what I mean? Could you ever, if you didn't only want EVM compatibility, but rather another VM compatibility, would you be able to actually plug that in? Or is this so deeply built together that it would be unextractable from one another?

Jordi (00:43:20):
We need to think a little bit, but the idea is that if you keep the backwards compatibility, that's [pretty] much what we are doing, you can always extend the EVM and do maybe different opcodes or even different structures, just maybe newer smart contracts with maybe with a different gas model, with different things. And this is actually doable and we may think to go in that direction, but the idea is to keep all the other work that has been done in development terms, in auditing terms, in understanding what has been done for that. We need to guarantee in some way, these backwards compatibility, or if you want this compatibility at this point. So the strategy, I think that goes more in that direction just try to keep the backwards compatibility as much as we can. And from there, maybe extend the zkEVM or maybe just to do it better, and just having a smooth transition in some way. This is perfectly doable, but we are a little bit far from there.

Anna (00:44:27):
So a few months ago, when we did a bunch of episodes on L2s, one of the questions that we kept asking everyone was, "How do you imagine interacting with one another?" How would someone use it, working in the zkEVM space potentially have a bridge or communicate with another, an Optimistic EVM-compatible L2?

Jordi (00:44:49):
Yeah. This is something that, for example, in Hermez, we developed what we call "massive migrations". And the idea is very much about that. It's just packing a lot of exits to a exit that goes to another smart contract. So it's like with a single L1 transaction, you are packing many transactions from one to the other. This is something that we have been working a lot in the last month. So we have half a full team right now working on that, and we made some, I think, we made some improvements and very good improvements just to optimize these transitions. We are working these in the context of the payments, of V1 of Hermez. But all this work applies, can be applied and all the learnings can be applied also to the zkEVM. And this is something that we are working a lot, because we know that massive migrations are going to be important at some point and work is there.

Anna (00:45:54):
Got it. This is a bit of an off-topic point, but something like Binance Chain, in this context... I know that there was an article that came out by Haseeb a few months ago. And what it suggested was [that] we're building all of this amazing zk constructions, and they are so much more safe and secure, but then there's chains where they did a much lazier connection point to the L1. How do you address that? What do you think about those kinds of chains?

Jordi (00:46:27):
Look, we are doing, if you are familiar, different things. We are building decentralized systems and permission-less systems. If you want to build centralized systems, seriously, don't go to a blockchain, just use normal servers and normal databases. They work great. You will have much less overhead, but the things work very good in that space, but this is not what we are building here at all.

David (00:46:53):
In my opinion, there's the fact that there are different needs for different use cases. And some of the applications or use cases are willing to sacrifice some of the properties, in order to achieve followers. So I think it's a clear example of what will happen in the end, that there will be probably different tiers or different solutions for different applications. And depending on the requirements, it could be fine. So it's a combination of different technologies, in order to be a different solution. And it's clear that it's going to be okay, depending on your use case. The problem is that someday something happenes that this will not be good for the space, but yes, up to this point we're trying to build the best solution we can with the existing tools we have today. And from here, you're always capable of reducing some of the requirements by combining other stuff.

Anna (00:47:58):
Totally. I also liked what you were saying before, Jordi, with the different approaches and this is, what is it, testing live. These things are live, or some of these things are live and we're going to see how they play out, which ones work. If there are actually vulnerabilities with some of these more centralized systems that maybe aren't quite obvious right off the bat.

Jordi (00:48:21):
Yeah. It's important, Anna, to the people understand the differences between the Binance chain and an Ethereum chain. I think that if you don't understand the difference, then it's problematic. I'm not saying that the Binance chain is not great, it could be very great for some applications, as David says. But they are different things. We are trying to build decentralized system, permission-less and censorship-resistant, and it's important that we understand each system that we are building, what are the properties and the things. And even the stage we are. For example, we in Hermez right now, it's quite centralized right now, there's a single operator right now. We need transactions to start decentralization. We explained that, we are saying that, we are not lying to anybody, this is what it is. And the same happened with... Ethereum is what it is, Bitcoin is what it is. The idea is to understand each chain, each system, what's [it] doing. And if you are transferring what you are doing, what you are achieving, that's fine. The thing is that, if you think that federated blockchain is the same that the decentralized blockchain, then maybe you need to understand what happens when specific governments have threatened the validator, the threatened Binance itself, or Binance breaks and what will happen with the chain. So these are questions that we need to understand. Now, the networks, I don't know, like the Facebook one, Facebook created a blockchain. It's okay. If you're explaining what you are creating, it's good. It's Proof of Authority, it is what it is, but this is what it is. You need to understand what it is. This may be very good, works great, I'm not against this, but it's important that the people, the users, the people understand what this chain does and what the chain doesn't and this is very important for the space.

Anna (00:50:18):
Basically the trade-offs that may not be explicit, but are built into the way that they're thought of.

Jordi (00:50:24):
And the transparency, just do the transparency of what is each thing. So what exactly you are building, what kind of consensus are you building? What kind of properties are you achieving? What are the threats? What are the risks? What actually you are doing? If you are transparent, then that's fine. But if you are trying to sell a blockchain as a fully decentralized, and it's just the server running in AWS with some software, well then, I think this is not ethical or correct.

Anna (00:50:53):
Yeah. Fair. I want to hear a little bit about the timeline and the plan for zkEVM. What stage is it at?

Jordi (00:51:03):
We are running as much as we can.The current stage is...

Anna (00:51:04):
I keep putting pressure on you.

Jordi (00:51:08):
This is the current stage: we have our internal roadmap... Maybe we can share with you a little bit of what we are planning, but take it as some internal roadmap, things may accelerate, may go slower. There are things that we may find some, maybe some stoppers that we need to fix, got a lot of things to do. So do not take it as "at this date we will have it". No, we are not at this stage. Maybe you can share that a little bit. But the idea is, in a year, the idea is to have this in production in a year, more or less. That's the idea.

David (00:51:48):
Yeah. As Jordi was saying, we have the EVM to develop as fast as we can, of course, we also assume that some issues will happen during the way. Jordi's working now [on] the first proof of concept with the rest of the team and we expect to have this initial proof of concept by the 3rd quarter or in the beginning of the 4th quarter. And we expect to share an internal testnet with some reference projects by the end of this year. From here, we'll continue developing and getting some feedback to start getting them more maturity as possible and developing the opcodes by batches. Until we finished, expect it 1 year, let's assume this half the next year. We will try to do it the fastest we can. We'll see how far we can move at this speed. But yes, we also want to be realistic, because this is a very complex engineering project, as you can see, and a lot of things will happen during the way.

Anna (00:52:50):
Can you imagine, once this is finished, does it just merge into Hermez? Would it just be in the same Hermez rollups setup? Or would that alter the way that you think about Hermez as well?

Jordi (00:53:03):
We don't know it yet, but [it] will depend very much [on] how Hermez, the current Hermez, evolves. If Hermez is used a lot, that means that it's getting more decentralized. That means getting more fixed, then probably this will be like a new rollup. It will be a new Hermez and with some migration from one to the other, but Hermez 1 will go forever. And then it's going to be a Hermez 2. If, in the other side, Hermez just is less used, maybe then it would be possible to evolve, to upgrade Hermez in some way. It's still not fully decentralized, so we can upgrade Hermez to a new rollup. Both options are open. And it will depend very much on many things, but mainly if the whole Hermez 1 evolves.

Anna (00:53:55):
Cool. Well, it sounds like there's a lot in the coming months, weeks, years for Hermez. And I'm so glad that you came on the show to share with us the zkEVM, how you're planning on building this out and why an EVM-compatible zkRollup could be really useful.

David (00:54:14):
Sounds great. Perfect.

Jordi (00:54:17):
Thank you, Anna.

Anna (00:54:23):
Cool. So I want to say thank you to the podcast producer, Andrey, the podcast editor Henrik, and to our listeners, thanks for listening.

Anna (00:54:32):
So soon after we did this interview, there was a huge announcement. And so I'm so glad that you've come back for this little extra bonus piece of the episode, to tell us a little bit about what we just learned about in the press, actually, a huge merger is happening. Tell us what it's all about.

David (00:54:53):
Thanks, Anna. We are happy to join forces with Polygon team. After some discussions during the last months even, we find that this makes a lot of sense for us, because I think we have an amazing technology, but we need adoption. And for us, after we've gone to the first release of the Hermez Network, we face this issue of the adoption. And then for us, this agreement is creating a lot of value for both parties. And we are very excited about this merger, both for the project, but for the teams. And also because we think we provide a lot of value or we'll try to do this for the Ethereum community and for the objective of scaling Ethereum, finally.

Anna (00:55:38):
Yeah. So two weeks ago you had actually announced an announcement. You had said [that] something is in the pipeline. And I did notice a lot of Polygon folks coming around the zero knowledge chats, I don't know if you noticed them, too, asking some questions, learning a little bit around it. What are they saying to you? What do you feel like this merger is actually going to look like? Are you going to be their technology's provider, in a way? Is the rollup going to take over what they have right now?

Jordi (00:56:07):
No. We continue to be an independent team and we have our main goal. The main goal is to bring zkEVM in production. This is, I would say, before the merge, it was my focus and now is continued to be the focus. And I would say with a maximum intensity, this is actually... It's a project of my life, this is what I'm committed to. And yeah, just after this interview, I just arrived to Switzerland, after this interview, I just continue working on this. And I'm very excited to do. Of course, as I mentioned, there are a lot of unknowns. We are doing these new technology and there are a lot of unknowns and a lot of stoppers that maybe we don't know yet. And there's always a huge risk in there, but we are convinced, I'm personally convinced, that this will happen. Also I am convinced that the bet that Polygon made in Hermez concretely, I would say, in the rollups, in the zkRollups, more gener[ally], is going to have their fruits in some months. There is a lot of work to do. And for the space this is the most important thing is that the zkRollups and the zk technology, I think, that at this point, nobody has any doubt that it's a way to scale the blockchain technology. And this is a bet and I'm and very excited to be here. And personally it's an honor to lead this and push this.

Anna (00:57:51):
I think you're totally right on where you say it's a massive reinforcement or thumbs up. It shows that the zkRollups, we talked a little earlier in this earlier episode, all about the different kinds of rollups and how they are also sometimes... I think I mentioned this where there's some talk [that] maybe zk is too complicated. Maybe it won't be the winner in some way, but I think this is definitely a sign that it could be. If it can get the volume that Polygon has been able to generate, then it could really show its merit.

Jordi (00:58:25):
Yeah. The technology is, well, you know better than me, it's a very young technology. It's a technology that's at this point is growing a lot. And when I'm saying "growing", growing in the number of researchers, knowledge of the people that's working on that, knowing of the people that's understanding on that, growing the people that's building on top of this technology. Just looking at your podcast! You have been there for a couple of years, maybe?

Anna (00:58:58):
Three years.

Jordi (00:58:59):
Three years? Just comparing 3 years ago. And this amazing technology that allows many things about the scaling. Scaling blockchains is one of those things that this technology allows. And we will see. But it's still young and it's still a lot of work to do. And yeah, that's what we want to do. And that's why we are so excited.

Anna (00:59:20):
It sounds like a call to action, a little bit to the listeners. People looking to jump into zk, now would be an amazing time to do it, because the momentum is very, very strong and it doesn't seem to be slowing down at all.

Jordi (00:59:35):
Yeah. And this is very important, especially... We have this technology that has been created for many researchers for the last, well, many years, even all the research is done and it [has been] many years. But the zero knowledge problem, I mean a non-interactive zero knowledge, comes from 10 years ago. A lot of groups that made a huge impact in the research, but it has been a lot of money paid for it, paying for researchers. The researchers have been working a lot. They, of course they continue working, but now it's time of engineers. Now it's time of implementers and really taking profit and bringing this technology to final users. And here is where engineers, we come to rescue. We are more pragmatic. And sometimes, this is between mathematicians, pure people, and the engineers have this kind of discrepancy.

Anna (01:00:35):
Trade-off?

Jordi (01:00:35):
Trade-off, yeah, that's a good word. And we're bringing this to the final user. We are solving real people problems. And this step is very important. It's not a step that can be done for a single person or for a single team, it's an effort that needs to be done from a whole community. When I announced in Paris how we are going to build the zkEVM, it's a plan and we are going to use StarkWare technology. We are going to use Aztec technology. We are going to use zkSync technology. So it's a community effort and it's important that each person, even each individual, each individual team just study and work on this technology and try to add value to this technology, because it's very easy to add value, because everything needs to be done yet. So right now for an engineer it's like a blue ocean, it's a place where you can find your spot, in the sense an engineer can find your spot in something that you can build. And so this is the current moment that we are living and it's a call for action. People that really want to build things, new things for the humanity, getting to this technology, understanding this technology and trying to think what's the best way to apply this technology to the world is something that you can find a place and you can add all the value. And there's a value in your podcast. You have been talking a lot about that. It's not only about the scaling. It's not about only about scaling blockchains. This technology is amazing for privacy. It's amazing for all the multiparty computations. There's really a lot of things to which this technology can be applied. And it's important that we, as a community, if you want to say humans, we add value together. We help each other to make humanity better in some way. And this is this generosity of the technical people, which used to be in general, this is very important when we have this new technology, because if we do it this way, we can go much faster.

Anna (01:02:51):
Cool. Well, I want to say congrats again to both of you and I can't wait to see how this merge works and what that means, but we'll be watching this really closely. It is a call out to everyone, amazing time to jump into the zk space, to head over to the channels. There's lots of people there who will help you get onboarded. And yeah, thanks so much for the interview.

Jordi (01:03:12):
Thank you very much, Anna.