ZKPodcast: zkEVM with Jordi & David from Hermez

Transcript

[Music] welcome to xero 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 i catch up with jordi beilina and david schwartz from hermes to talk about zk evm they share an update about hermes since their launch on maynet earlier this year we talk about the l2 landscape zk roll ups and how different teams are approaching evm compatibility

on their respective chains we then dig into zk evm 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 hermes 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 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 kind of 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 kind of sort and filter now so yeah hope to see you over there 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 1 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 snaps also allow users to access on-chain services without sacrificing personal data privacy and mena is a unique blockchain it's replaced the traditional blockchain with a zero knowledge proof ensuring a super light chain that stays around 22 kilobytes 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 is my interview about zk evm with jordy and david [Music] today i'm here with jordy bylinna and david schwartz from hermes and ident 3. hi guys hi hello jordy you were on the show pretty recently actually you came on to talk to us about hermes but today's episode what we want to do is actually dig into zk evm something that a lot of us learned about only at ecc about a month ago so yeah i'm really excited to to learn more about this david this is the first time we're meeting maybe you could quickly introduce yourself tell us what you're working on at hermes sure thanks uh well my role at hermes is the produced project elite 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 hermes and probably we can discuss a little more today yeah but yeah amazing time yeah i mean we did do an entire episode on hermes and so i will link to that in the show notes hermes and l2 that is as far as i understand it's it's live right it's been live for some time absolutely it's a production it's in production right now it's forging a block every 10 minutes and there are many transactions and it's just uh it's service that anybody can use it there

maybe before we dig into the zk evm the kind of topic of this show i do want to hear like what's new i think our interview is like back in january so this was before the launch i'd love to hear you know what what's happened since then and maybe what's potentially coming up i don't know how much you can divulge but uh yes well david maybe you can answer it yeah from the last interview i was not there but i guess you were discussing about the launch of the hermes network at this point we were launching the first release of the the hermes where we were focused basically on payments and um yeah we became live we are

maintenance we started the the initial steps towards network stability and we we started then to do some promotions of the network to launch some activities in order to test that the system was stable was secure and from here we have been building the next steps or working in the behind the scenes to 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 at cc we jordy introduced the ckvm at this point

because we want to share with the community the work we are doing in order to just to 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 ckbm on the other hand we continue developing the the product features for the first version based on crypto payments so this is the equivalent situation maybe we should define even though we do have an entire episode on hermes maybe you can tell us a little bit about like what makes hermes unique in the l2 landscape well hermes is decentralized and the protocol of hermes is designed to be decentralized that

means that the coordinator of a roll up anybody can be a coordinator it's true that right now it's not worthy 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 break even which is in the case of thermos is the lowest break even so right now the hermes is the rollup that has most cheap transactions in in cost terms so we are very close to get this break even then new coordinators will become we will start to uh bidding for slots and start forging batches and and this will give the decentralization now the protocol is designed to be fully

decentralized and this is uh quite unique i would say that these are that mainly that the two big differences a protocol that's fully is is decentralized by design it's governance less the data is at some point there is no governance it's just a product that's working there and the cost of the verification uh the cost proof the cost of batching matches is the lowest in the in the space right now would you say i mean like privacy it doesn't sound like it's one of your current like unique propositions but is that something that you do see as part of the road map it is but right now we are more focused in the zkvm

uh so is the kvm it's again in some way it includes privacy because you can you know it's a vm you can do whatever you do but uh yeah so uh here we are more focused in the zika vm that let's say that with private private payments in some way got it so when we talk about this evm and like evm compatibility zk evm in the current l2 landscape are there any l2s that are already like evm compatible would you say there are projects that's working in evm compatible and here we are again we are talking about like two big groups one is the optimistic groups for them i would say that the avm part is

easy okay they have the problem of this of this challenge game that they have behind but including the abm is a challenge but it's not a it's not a such a big challenge as is for the ckvm and in this i know that for example optimistic is working on this way and there are optimistic projects that are working in that direction in the ck site there are different projects that some way or the other is uh working on that ckc matter labs for sure star wars is working also in in that direction i know that blueberry is also starting to do something in that direction or at least thinking on that uh of course after people they are also doing a great job in that direction uh

even the city of foundation is is working maybe more in the research side but it's 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's uh some way or the other maybe with different approaches with different things but they are working in this path got it where do you want to start to explain what zk evm really means right now um in the current hermes that's in production right now you can do payments you can do you can do transfers okay you can it's like a little bit like bitcoin you can do just transfers in there okay uh with ckbm you have uh

actually you can run the smart contracts data is is having a roll up exactly the same that draw up but instead of doing a payment you can deploy a smart contract and execute a transaction in a smart contract and this is a big difference it's a roll up that's actually good in smart contracts that's mainly what it is and in the case of zkvm just to be clear it's a ck evm it's uh zero knowledge uh ethereum virtual virtual machine okay so the ethereum builder machine the avm it's actually the virtual machine that's running in ethereum smart contracts are you know are actually created in these vm and zkvm is just having a roll up that's executing exactly the same smart contracts that are currently running

ethereum that's what means ck vm i watched actually that presentation that you gave at ecc and in it you talked a lot about op codes op codes that would normally be in i guess running on the evm i don't know if that's how you say it but what what do you mean when you use that term opcodes what do those look like or maybe what are some examples yeah i'll code these uh instructions so when you do a smart contract in solidity this is compiled okay and this is compiled to a machine language okay this machine language is assembly if you want this this machine language is composed of executing different op codes that it's executing and these are the instructions that uh the final instructions that

actually is running dbm these instructions include for example doing an addition pushing a value to the stack uh setting a value to memory recovering a value from the storage these are this very very small instructions that the virtual machine is processing every time you do it you could a smart contract so the idea of is that the compatibility when we i'm talking about compatible means that we are able to get this compiled a program with all these uh instructions with all these op codes and you just can take it and run it in the zig avm without transpiling or without doing anything it's just fully

compatibility on the developer side i'm guessing like they could use the same tooling but on that compiling part like is it actually compiling into something different or is it actually following the same the same thing that you'd see on an evm this is a difference the difference of on the approaches when you are doing opcode compatible actually you can use exactly the same compiler and you get the the result and you just instead of uh it's like having a side chain but this is the case it's a roll up but you just take this transaction you just run it and you don't need to do anything else just get this this this code this smart contract you deploy you use the same tooling a lot of stuff there are other approaches they are actually they change

the compiler so instead of compiling to these evm to these cpm op codes we are comparing to another set that are more maybe it's more zk optimal op codes and you're just executing this different virtual machine that's not compatible but maybe the solidity uh program you can compile it in two different in like in two machines into different machines these are the two approaches got it so what you're saying is like from the developer side they would still be potentially just writing a solidity contract deploying it but what's happening under the hood with zk evm it's actually following the same path that it would on the original evm yes

very very very very very similar okay it's not you don't need a different compiler you don't need a different tool set you don't you don't need to care about special things just just do the same just having like a sidekick it's just a side chain it's a robot we are bringing the upcode concept to the table because when you go into the details on what a seed kvm implementation means you need to go into this level of details you know to go down and say look implementation of this ebm means that we need to be compatible for the same set of operational codes that this built-in machine supports so the challenge is to analyze every single opcode that ethereum virtual machine supports and figured out how to implement that

jolie was saying the same i mean we have two options either we can just build a new virtual machine with a different setup of codes and compile solidity problems 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 codes and that the ethereum virtual machine so you can be able to port existing solidity or existing smart contracts code directly to this new system so this is the way we are bringing this up code to the set and discussion to the table would that mean like you kind of talked about each op code but are you forced to go in to each particular opcode and like re-implement it or is it

more like a general re-implementation that's happening no no it's it's very detailed you have to go each one and try to keep the compatibility as much as you can there it's it's not a general thing it's um local diop code and structure by structure and going trying to be as close as possible to the current ethereum machine how many op codes are there actually we need to check it but roughly it's about maybe i don't know 50 um 50 i need to okay so it's oh i i was thinking you were going to say something like thousands no no but okay it's like 50 under and a lot of them like most of them a lot of them are like

repeating ones you know it's not for example push one bite push too much push three bites push four bites this is okay these are 32 coats but actually is the same so that's like around 50 maybe 70 all together but so just this this few tense focus i want to hear a little bit about the zk part of this so what you've described is sort of like the rebuilding of an evm from the opcodes individually kind of rebuilding them but like where does the zero knowledge come in because when you're saying you're rebuilding it it sounds like that's maybe what you have to incorporate somewhere well at the end it's like roll-ups you have a set of transactions that execute smart contracts like hitting

transactions but transactions and you are aggregating and you are processing all of them transactions and at the end computing a proof that all these transactions are well computed and and this is where the zero knowledge comes the thing is that you verifying uh that the payment is valid is quite easy verifying that a transaction that needs to be executed with all these op codes and memory and all that stuff is valid is much much much harder okay and but at the end the idea is exactly the same that standard roll up you need to verify that the set of transactions so you go from state a to a state b when you execute these uh 100 transactions so you need to

prove that state b is correct without having to compute everything and you verify that and this is a so the idea is exactly the same that the normal roll up here probably the zero so that the word zero knowledge is like not the right one it's more the verification of a computation actually zero knowledge is uh it goes very close because it is because this succeed verification is uh it's a property that share and we are sharing like the same is the same technology some way but they are used for very different things zero knowledge is to hide some inputs or to you know to have some kind of privacy in general and the other part of this zero knowledge

technology is more for uh succinct computation or for verifying computations in a succeeded manner and in a role like the case of the roll-ups we are using very much the second property it's the most important for wallops this is the like going back to that optimistic versus zk roll up it's like the fraud proofs versus the validity proofs i guess you could call it exactly the validity proof this is the the what we are building here we're building ability proof that the set of transactions creating smart contracts or executing smart contracts are valid this is actually what what we are doing so the xero knob proof in this case is not it's not a privacy proof like it is you can actually see both sides of this this action i guess the question here is like

does all of the evm the in the zk evm does all of the action just sort of happen within a bubble and then every once in a while with a zero knowledge proof get like re kind of checked to the main chain or is it like each transaction or each change each like i'm just sort of curious like at what point are these zero-knowledge proofs actually being used um and in the case of the way that we are building the ckvm actually is we are embedding like two proofs uh two proof systems in in there so we are mainly we are generating a stark and then we are verifying a start with uh plonk or gloss16 so we are like a proof of a proof okay wow and the idea is that we are we are combining two

proof systems to get the best of each one okay so the starks are very good but they have a problem that the the proof sides is is huge and and well you can verify it on chain but it's very expensive so what we are doing is we are building like a graph 16 or plonk proof that actually verifies the start so because the the stark proof just become a private input of the next the size of the start doesn't matter anymore and we can use all the advantages of the start and get also all the advantages of growth 16 and unplug which is a very cheap verification on time and very small

size proof so combining these two things is very good for for for this and actually starts they have like another important advantage is that the very very fire so it's quite easy to build a very fire in a growth 16 circuit because the very fire of a stark is just using a just a single field element so of a single field so you if you are using the same field at the growth 16 then the the the very fire is very very cheap and very easy so the gloss 16 is going to be as this is a proof but the number of constraints is going to be quite small uh in compared with uh real proof that's gonna be in in the starks some way so

it's just we're convening these two technologies we're gonna be getting we're combining flank we're combining block up we're combining a start we're combining rule 16 we're like putting everything together and we're building the the cicada that's very much the challenge that we have in front so is it sort of like the first proof would be a stark which ends up resulting in a very large proof but before you're actually like this all remains within the zk evm still in that sort of space but then because you have this large proof are you then using planck almost as like a compression like to then prove that large proof you use plonk to create a small proof and that's what you have to verify and that was is why it's cheap

exactly you got it perfect yeah i think you did it you explained it perfect cool okay but the one part i still don't understand though is like where are the starks starting like every time anything occurs is there a stark attached to it like i'm just kind of curious like we have where did those come from where are they living in this process i'm not sure if i if i'm using here the word stark correctly uh but the idea is that we are using the fryproof like the engine of starx to verify polynomial commitments all together okay so this is what we call it as the start probably it's not a start this is another thing but we are using the same technology as as stars is the this sprite to verify all the polynomial

commitments all this polynomial we have a lot of polynomial relationships vbn has hundreds of polynomial relationships because no to bvm is complex okay but all these proofs are together with the starks all this proof is very fired inside the gross 16 circuit or a grassy steel or long circuit that if it's more or less the same depending if you want trust to set up or not plonk is a little bit more expensive i don't have to trust the setup because 16 is cheaper but it requires the trusted setup ceremony so we probably will start with plonk and maybe at some point if this goes maybe we'll do a girl 16 just without ceremony and so on just to stabilize that but that's the the long term but the circuit is the

same or it's very easy so you can reuse the circuit in gross 16 and planck actually for example in snarky yes we updated the snark gs um some months ago that supports right now supports growth 16 and plunk so with the same with silicon so all the programs brightening silicon can be no very verified you can convert it to a gross 16 proof system or to upload system so everything is it's more the same starks is frying it's like a different world it's a little bit different altogether i think the the question that i still have though is kind of going back to just like the op codes you sort of mention the polynomial

commitments but is it like on the execution of an op code and 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 like using fry you're going to be like running you're going to be basically generating one of these proofs at some point in the process and i'm i'm not clear is it on an execution of something like is it when there's been a state change that you would prepare one of these things or is it like after a batch of activity like activities have basically happened and then you just sort of clump it together into a polynomial and then well let me let me try to let me try to explain a little bit in the more it's a little bit more complex than that but just to be this is

we have like different op codes so there is to have we have like many state machines that execute opcos we have for example a state machine that executes uh modular multiplications in other state machines that's doing binary operations another state machine that's doing memory operations another that's doing storage we have like different same machines each one very specific for specific codes very specialized for doing specific codes um we use uh polynomial commitments to verify this state transition need in initiation of state machines okay so that's that's we have this okay now we need we need to link them all together okay so the the codes that we are verifying in this state machine should be the ones that are executing in

the main program and and the same with the memories and the hashes that we are computing and actually the same that we are computing when we are doing a storage and the storage needs to be computed so we need to link all these state machines and here the key is the block up block up they they have like different polynomials and we are just relating one each other at the end block up what you're doing is okay you are this polynomial is included in this other polynomial that means that it's the code that i'm integrating in this specific state machine is actually the ones that i'm creating and for this the key is ploca but plug up at the end is is done with polynomial commitment so you have the polynomial commitment you have before we have the new polynomial commitments that we have broke up so we

end up like a lot asset a full set of polynomials you know polynomials everywhere polynomials commitments everywhere and a lot of relationships that the verifier needs to check about these polynomials okay so this is what what we have and so all these polynomials commitments at the end is our polynomial's openings all this is we use fry to open all these uh to do all the openings of these polynomial commitments that we make we do all the verifications and all that we do it in a circuit in a gross 16 or a planck survey i think okay and the result of these blocks is actually what goes to the blockchain and it's very fire don't change this is a little bit discovered yeah okay so i mean you've touched there's two things that you just

brought up that we might want to like clarify a little bit one is pluck up so this is plonk up kind of pluck up is i know this is for also from aztec i believe yeah it's like they they came up with this uh construction it's a very cool construction and it's very very very very powerful it's used in in many things and uh it's a very powerful piece for building of these these systems because it's what the glue is what allows to connect different virtual machines uh to glue them together in a single proof are these proofs are they being created after every transaction or are they being done like after a batch of

transactions yes this proves uh it's the same concept that as the current ck roll up we are creating these validity proofs in the form of a batch so we process uh we have a queue and these queues process receive the transactions from the users and then the hermes node just selected the title or the best transactions to process and they do this processing of chain layer two when you just change the states and and so on you execute all this uh processing of chain and the the interesting thing here is that once in a batch you just create a validity proof of all the set of changes in the system at the same time

so it's uh the prover we are building is the same concept that the secret roll-up of transactions is one proof every whatever number of seconds with a maximum number of uh transactions in the same batch to be more efficient but it will be one proof in the improving a lot of transactions at the same time you had sort of mentioned that like storage there is like a method that you're using the pi and maybe maybe i didn't understand this but like are you also using these polynomial commitments and like that structure to manage storage or is there like another way that you need to think about that well if we want to maintain compatib fully compatibility with the currency kvm we need to use the current

patricia trees it's a kind of a merkle trees that is using right now the ethereum virtual machine there are new ideas for replacing these patricia trees ways maybe using some binary trees or other different trees or even or even polynomial commitments and there are different or even vertical trees that was talking italic at some point and there are different ideas there uh i would say in the zika site and then even in the ethereum site so ethereum is probable they will upgrade at some point and remove the patricia trees and goes to a different structure for a storage this is something that's open but something i would say on both sides and and you know in our case

the days to be compatible with all these particular trees but it's possible that maybe we go with an easier maybe with a normal tree use your trees and maybe we just break this compatibility because it's not an opcode so the program 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 i want to understand maybe how what you had described going back to those earlier ideas of like other zk rollups looking to do evm implementations so you would mention starkware zk sync and that loop ring might be thinking about it oh you it's in foundation too yeah i just yeah lots of people i guess yeah how are they

approaching this like going you know you you described sort of using the stark and then using the snark but in the case of starkwear would they also be doing something like that or do you think that they're approaching this in a different way it's different because we are different engineers and we have different ways of thinking and different tools and things i'm not going to say when which is good or bad i think it's good to have like many projects each one trying their best way this is this will help a lot and and if there is communication we will we should learn from one each other and and and this is something that in some way we are promoting and it's quite happening i would say in the space for this uh

knowledge sharing and understanding which which what's doing each one just to learn but it's not clear what's the best you know it's just the the good at this point is just try it do it and then we'll see and then that's a cool thing here it's like no there is no good approach or bad approaches at this point i would say that all the approaches are are good at this point maybe at some point some of them will maybe us we just say okay this is a bad approach we just we're wrong and this is not good because these are that and then we just explain we say we try to learn and work around and whatever this can happen to us it can happen to any of the projects but that's that's cool at the end important is to

scale smart contracts that's what we are committed projects and everybody's trying to do that but actually my question was more like do you know what they have planned and how does it compare not not which one's better but just like is it a very different approach i'm kind of trying to understand um how they look at it for what i have read and what i have listened there are different approaches uh in some some way you know but uh that doesn't mean that that those approaches are wrong it's though they are just those approaches i mean but can you speak about them i'm i'm also curious if you know like what they are yeah i think we explain personal matter labs is going more in this recompiling you know having their own code and their own coding so their own

with virtual machine and compiling solidity to the this optimal virtual machine starks they also have like their own filter machine with you know they have a project also to port the avm to these virtual machines some way i'm not sure about the details you should ask them and how they are doing that totally not but they are they sounds like i should have them it's in their plan but they are they are working also in in that direction as far as i know the syrian people is thinking very much in hollow for example or they are considering hollow in hello or some techniques that used to be hello the approach is more similar to us uh in

the be more uh zika vm so evm can fully be uncompatible of course we are talking with lots of these projects and you know in the technical side we are just sharing a lot of information and you know it's like we are learning every day that's awesome yeah going back to what you've actually or what the designs for zk evm are is the idea here that like it will support all op codes it will be actually one-to-one or are there some limitations that uh you could you could foresee here definitely there are codes that are more difficult to implement to the others and it's possible that there is maybe the first version does not include

like the full up codes or the full pre-compiled smart contracts but what's cool is at this point i don't see any stopper on any op code to be implemented even the most complex op codes or even in this case they are not top codes but they are pre-compiled smart contracts that are important like pairings or big numbers smart contract or hash function all those looks like they are doable okay and they are just a matter of building and we need to see the efficiency and we need to see how we hold it matches all together but i don't see a priori stopper for any op code

there are opcodes it's true that there are all codes that are like very specific layer one upgrades that they will have to have some special treatment for example difficulty you know that there is nothing similar to difficulty in layer two okay but what what happened with this subcode well maybe this uh recorder value or something like that or a block there is no blocks where it's um maybe it's uh equivalent to batch maybe the ckvm have like some extra out codes that are more layer two related so it can be some i would say adjustment in in because it's different it's not a layer one and layer two and there are some of codes that you need to find this for example the reason uh the optimistic people they

already did a good work on interrupting these uh like specific upgrades and but this is you know this is some something very concrete and very uh specific to that the important ones like you know the odd calls that are maybe complex but they are doable like great you know that can create another smart contract that's a heart or calls or delegate calls or of course the storage or even these pre-compiled smart contracts they are like signature verification or paintings or you know all these things that those are doable at least in the project we're building we we know how to build them we need to see how efficient and how they fit and all

together but at least from the theoretical perspective they are uh achievable that's why we want to at some point build all of them you know they have to be as much compatible as we as we can there's things that you know the gas things for example what happened with the gas they have to try to be as compatible as possible but uh it's gonna argue they're gonna be different between layer two and layer one and maybe there there are some adjustments that need to be done uh in the future but when you are doing this is like you are finding like a lot of things so what happened with this and what happened with that and yeah and and this is what and you are like solving this or maybe having a workaround or some solution in

there that they have to be as as the goal is to be as compatible as possible do you imagine actually like in these environments that it could go even further that it could become a realm of like experimentation because you're not necessarily you don't have the same constraints as the l1 like i know maybe it's a ways off because you're saying like the first release probably won't have all of them so once you get to all of them yeah could you go further uh yeah is it too far in advance i don't know so it's like yeah come on jordy do more let's let's just let's i would be happy right now if we have like a small set of codes working uh again but yeah it's it's uh we'll see

this is a first approach there are things that this work um or just talking like the long future right if you are talking this earlier fiction uh things but one interesting thing of doing this opcode compatible uh approach is that a lot of the work can be used for verifying l1 blocks and this is uh for example something like protocols like mina protocol things like that or or i think cello is doing something similar that's like you can for especially for like clients that you are so each block has a proof that verifies that the last block is valid and you have this kind of recursion yeah um

if you have all the of this proof that actually verifies all the transactions that are processed in this case a badge you can have like a verification that these uh that other transactions that you process are included in this block maybe you should have you should add the consensus verification proof work of stake or whatever there and then you could have a recursive uh verification there so that's something that okay this is not like our main goal uh main goal is to build the zkbm roll up but uh all the work that we are doing could be used in this uh verification and this would be good for like clients or maybe

for using these blockchains in mobiles and having a client that you know i like client in a mobile this is something that's a good evolution for for ethereum but again this is like long run future but it gives you an idea of the importance of the work and that we nervous but also all the projects that are working in the ckvm or cks or virtual the kvm at least projects because this will help a lot to go in that direction um jordan you just mentioned gas and i'm actually curious like what is the strategy for that like do the do the l2s in this evm like does it

have to have the equal gas model can you get rid of gas completely uh it's a hard topic daily 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 on the gas so if you want to have a compatible evm you cannot change at least in a for an initial version these gas models so the idea is to keep this gas model as compatible as we can okay so that's that is to keep the same gas model all together but said that the gas was designed to be

for l1 was not designed for l2 so travel there in the future you can think maybe in changing some gas costs and even some gas the gas model in the z kvm in a different way that makes more sense but this is it's something that needs to be studied and our goal at least in the in this moment is to be as as much compatible as we can to the current we want that the developers that are building smart contracts in l1 and they can use the same tooling and we'll go to l2 and and works what would the base gas token be denominated in though like is it denominated in the native hermes

oh it's still in ethereum okay even though it's within the zke evm yeah yeah you can choose what you you can choose whatever you want but i think that the ones that make sense is uh is it sort of 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 yeah it's like a roll up you probably have to deposit it and then just have some smart contract to get that that that video from there got it it can be early yeah it's like it's like it's it's can be any it could be any but it has to be three cool i have a kind of a higher level question about evm compatibility in general we've talked very much about like the different solutions the ways that zke evm aims to like allow for this

compatibility like almost a one-to-one in terms of compiling and it's sort of this this equal system but why do you even want the evm compatibility like why would we want an exact evm copy is it because it's such a fantastic system or is there like some other reasons that you see well i can i can provide my comments here i think we were trying to solve from the beginning the scalability problem of ethereum in the first place so we want this idiom to to be able to have to support more transactions so of course we can build different systems but this will be a different project i think what georgia 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 outfits done and existing smart contracts and the security model uh needs to be respected in order to manage the change to a ckvm so if you build a different system all this technology needs to be analyzed to to see what's the impact on that and the ckvm tries to be compatible at code level and to respect the gas model in order to behave the same as the evm uh so this would be very easy for developers to just migrate contracts to this system and this will allow existing projects to migrate you don't need to

recompile ideally 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 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 like could you ever like if you didn't only want evm compatibility but rather like another vm compatibility would you be able to actually like plug that in or is this so deeply built together that it would be unextractable from one another we need to think we need to think a little bit but the idea is that so if you keep the backwards compatibility that's what very very much what we are doing

you can always like extend the ibm and do maybe different up codes or different even different structures just maybe force new smart contracts that are more you know with maybe with a different gas model and with different things and this is actually doable and this is well we may think to go in that direction but the idea is to to keep all the other work that has been done in you know development terms in auditing terms in in you know in the understanding and that has been done for that we need to warranty these black words this some way this backwards compatibility or if you want this compatibility at this 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 kvm or or just to maybe just to do it better and just having a small transition in some way this is perfectly doable but we are a little bit far from there 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 like how would someone use it like working in the zk evm space actually potentially have a bridge or communicate with another like an optimistic evm compatible l2 yeah this is something that for example in hermes

we developed although what we call massive migrations and the idea is pretty much about that it's just packing a lot of exits to a single exit that goes to another smart contract so it's like with a single l1 transaction you are like packing many transactions from one to the other this is something that we have been working a lot in the last uh the last month so we have like a well have a full team right now working on that and we we made some i think we made some improvements and very good improvements just to optimize these transitions we are working this in the context of of the payments of version one of hermes

okay but all this work applies could can be applied and all the learnings can be applied also to the ck evm and but this is something that we are working a lot because we know that massive migrations are going to be important uh at some point and work is there got it this is kind of a bit of an off topic point but something like binance chain in this context like i know that there was a there was an article that came out by haseeb a few months ago and what it suggested was like we're building all of this amazing zk constructions and they're so much more safe and secure but then there's chains where they kind of did a much lazier

connection point to the l1 yeah how do you sort of address that what do you think about those kinds of chains look uh we are doing is they are for me they are different things you know we are building a decentralized systems and permission layer systems if you want to build centralized systems seriously don't go to blockchain just use normal servers and normal databases they work great you'll have much less you will have much less uh overhead overhead things work very good in that space but this is not what we are building here at all yeah in my opinion that there's the the fact that there are different needs for different use cases

and some of the applications or use cases are willing to to sacrifice some of the properties in order to achieve others so i think it's this uh it's a clear example of what will happen in the end that there will be probably different tires of different solutions for different applications and depending on the requirements it could be fine so it's a combination of uh different technologies in order to build a different solution and it's clear that it's uh it's gonna be okay depending on your use case the problem is that someday something happened this will not be good for the space but yes up to this point uh

we're trying to build the 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 coming combining other stuff totally i also liked what you were saying before jordy with like the differing approaches and like this is sort of what is it like testing testing live like these these things are live or some of these things are live and we're gonna see how they play out which ones work if there are actually like vulnerabilities with some of these more centralized systems that maybe aren't quite obvious right off the bat yeah it's important anna to that the people understand you know the differences that's between a binance chain and an ethereum chain yeah

i think that if you understand the difference then uh it's problematic you know i'm not saying that the binding chains is not great you know it could be a very great for some applications as david says but there are different things you know they are trying to build that decentralized system permissionless and social resistance and it's important that we understand each system that we are building what are the the the properties and the the things and even the stage we are for example we enrollments right now um it's quite centralized right now it's there is a single operator right now we need we need transactions so to start the centralization we explained that we are saying that we are we are not lying anywhere anybody this

is what what it is and and the same happened with uh well ethereum is what it is bitcoin is what it is they say understand each chain each system what's doing and if you are transparent on 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 uh okay maybe you you need to understand that you know what happened when a government a government or specific governments have uh set the validators or threats the binance itself or bannon's blocks and what will happen with the chain so this is these are questions that we need to understand now the network say like i don't know like uh the facebook one you know facebook create a blockchain it's

okay if you if you as if you're explaining why you are creating it's good you know it's a proof of authority it's what it is but this is what it is you need to understand what it is this may be very good this was great i'm not against this this is good but it's important that the people so that users yeah that the users and the people understand what this chain does and what the chain doesn't and this is this is very this is very important for the for the space basically the trade-offs that may not be explicit but are kind of built into the way that they're thought up and the transparency just to the transparency of what is each thing so what exactly you are you building what kind of consensus are you building what kind of properties are you

achieving what are the the threats what are the risks what what actually you are doing if you are transparent and that's fine but if you are trying to sell a blockchain as a fully decentralized and it's just a server running in and it will last with some software well then that's i think this is not technical correct yeah there i want to hear a little bit about the timeline and the plan for zk evm what stage is it at we are running as much as we can this is the current status i keep putting pressure on you right this is that this is the this is the current states uh we have we have an internal road map that uh maybe can we can share with you a little bit uh of

what we are planning but it's like take it as an internal roadmap you know things may accelerate may go slower with there are things that we may find some maybe some stoppers that we need to fix there are a lot of things to do so it's no do not take it as uh oh at this day we will have it no we don't have a we are not at this stage maybe you can you can share that a little bit but they did so in a year it is to have this in production in a year more or less that's the the idea yeah yeah as it was saying we have the idea to develop as fast as we can of course we also assume that some some issues will happen during the way george is working now the first proof concept with the rest of the team and we

expect to have this initial proof of concept by the third quarter probably the beginning of the fourth quarter and we expect to to share an internal test net with some reference projects by the end of this year from here we'll continue developing and getting some feedback to start getting the volatility as possible and developing the up codes by batches until we we finished expected one year let's assume it's half next year we will try to do it the fastest was we can we'll see how far we can 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 you can see and a lot of things will happen during the way can you imagine i mean once once this is finished does it just merge into hermes like would it just sort of be in the same hermes roll up set up or would that kind of alter the way that you think about hermes as well we don't know it yet but will depends very much how hermes the current hermes evolves he firmness is used a lot that means that's getting more decentralized that means getting more fixed then probable this will be like a new roll up it will be a new hermes with some migration from one to the other but hermes one will go

forever and and then it's gonna be a harvest too if uh in the other side hermes just is less used maybe then it would be possible to evolve uh to upgrade their mess some way it's still not fully centralized so we can upgrade and maybe we can upgrade their mess to a new to a new roll up both options are open and it will depend very much on many things but mainly in however one evolves cool well it sounds like there's a lot in the coming months weeks years for hermes and i'm so glad that you came on the show to share with us the zk evm

how you're planning on building this out and yeah why an evm compatible zk roll up could be really useful sounds great perfect thank you anna we are we are open just uh we are here very happy to be here cool all right so i want to say thank you to the podcast producer andre the podcast editor henrik and to our listeners thanks for listening 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 thanks anna we are very happy to to join forces with a polygon team after some discussions during the last months even we we find that this makes a lot of a lot of sense for us because uh i think we have an amazing technology but we need an option and uh for us after we launched the first release of the hermes network we faced this issue of the adoption and 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 yeah so two weeks ago you had actually announced an announcement you had said like something is in the pipeline and i did notice a lot of folks coming around the zero knowledge chats i don't know if you notice them too asking some questions learning a little bit of 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 technologies provider in a way are you is the roll-up going to take over what they have right now no no no we are we continue to be like an independent independent team and we have a main goal the main goal is to bring zika vm in production this is i would say this

is my it was before the merch it was like my focus and now is continue to be the focus and i would say with uh well with maximum intense this is actually my it's a project of my life this is what i'm committed to and yeah that's you know just after the after this interview i just arrived now to switzerland after this interview i just continue working on this and very excited to do of course as as i mentioned there are a lot of unknowns we are doing this new technology and there are a lot of unknowns and a lot of stoppers that maybe we don't know yet and there is always a huge risk in there but we are convinced i'm complaining i

personally are convinced that this will this will happen also i am convinced that the bet that polygon made enormous concretely but i would say in the roll-ups in the zika relapse more generic is going to have their their fruits in some months there is a lot of work to do but that's and that's problems from for the space this is this is the most important thing is that the zk roll ups are and the zika technology i think that at this point nobody have any doubt that's uh it's a way to scale the blockchain technology and and and this is uh but this is the bed and and

very excited to be here and personally it's an honor to leave this and push this i think you're totally right on where you say it's like this it's a massive kind of like reinforcement or thumbs up or like it sort of shows that like the zk roll ups you know we talked a little earlier in this earlier episode all about the different kinds of roll-ups and how they are also sometimes you know i think i mentioned this where there's some talk like maybe zk is too complicated maybe it won't be the winner in some way but like i think this is definitely a sign that it could be if if it can get the volume that polygon's been able to generate then it could really show its merit you know yeah it's it's

uh you know the technology is uh well you know better it's not even better than me it's a very young technology and it's a technology that's at this point is growing a lot and growing when i'm saying growing growing in the number of researchers knowers of the people that's working on that knowing on the people that's understanding that no way no growing the people that's building on top of this technology well just look at your podcast you know just you have been there for a couple of years maybe three years that's you know just comparing three years ago and this is uh you know this is the this amazing technology that follows many things but scaling scaling blockchains is one of those things that

this technology allows and we will see that's still young and it's still a lot of work to do and yeah that's what we that's we want to do and that's why we are so excited it sounds like a call to action a little bit to the listeners people looking to jump in to zk now would be an amazing time to do it because you know the momentum is very very strong and it doesn't seem to be slowing down at all yeah and this is very important especially you know we have this technology that you know has been created for many researchers for the last well many years you know because even the other researchers don't know the research and you know it's like many years but the zero knowledge problem means that non-interactive zero

knowledge comes from the ten years ago you know some a lot of groups that make a huge uh important research but it has been a it's a humanity effort and time from researchers the researchers have been working a lot of course they continue working but now is time of engineers now is time of of implementers and really taking profit and bringing this technology to final users and here is where engineers we we come to to rescue we are not we are more pragmatic and sometimes you know this between mathematicians pure people and and the engineers you have this this this kind of discrepancies yeah yeah

yeah yeah you are good in words yeah that's that's a good word and yeah but we're bringing this to the final user we are solving real people problems and uh this step is 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 fuel community uh when i announced in paris uh how we are going to build the zika vm this is the plan and and you know i'm using uh we are going to use um star wars technology we are going to use aztec technology we are going to use zika sync technology too 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 yeah it's it's right now for an engineer it's like it's uh sometimes a blue ocean you know it's just it's a place where you can you can find your spot you just as an engineer you can find your spot in in something that you can build and so well this is uh the current moment that we are living and just like just it's a call for action yes it's just uh people that really wants 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 a lot of value and as i told you i in you in your 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 for privacy it's amazing for you know all the multi-party computations is a lot of things that can where decent technology can be can be applied and and it's important that we as a as a community if you want to say humans we add value together we help one each other to make to makes humanity better in some way and this is this generosity

of the of the technical people which used to be in general uh this is very important when we have this new technology because if we do this way we can go much faster cool well i want to say congrats again to both of you and i can't wait to see how this merge works and like 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 you know head over to the channels there's lots of people there who will help you get on boarded and yeah thanks so much for the interview thank you very much [Music] you