 Hello, I'm Jorge Vailina. I'm the technical lead at Polygon Hermes. And today, I'm going to present mainly the public testnet that we published last Monday. First of all, I'm going to explain a little bit how the CKVM works. And then we are going to proceed to a demo. How a rollup, who is the KVM works from the user perspective? Well, a user should not see any difference like working with any other network. What we will do is, first, we will send transactions to a sequencer. A sequencer will already give a state. That means that the state will be final as far as you trust a sequencer. Sequencer, the first version, is going to be a centralized sequencer. We will do centralized later on. But if you trust a sequencer, this transaction is final. And you have the warranty by the sequencer that this transaction is going to be processed. The sequencer will collect transactions. And at some point, we'll send these transactions to the blockchain. And then at this point, the state is final and safe. Here, we don't have any proof yet. It's just the transactions are set. And we have the warranty that those transactions are going to be processed in that order. And because they are on chain, they are not going to be changed. So you know that they are final, and you don't need to trust a sequencer anymore. You know that these transactions are final. And in background, in parallel, it's going to be the prover. Actually, that's going to take all these transactions, and it's going to prove that this implicit state, so this state that everybody can compute, but it's not on chain because in on chain these are only the transactions. The data availability, if you want the transactions, are going to be processed. But it's going to be converted to a real state. And this is proved by the prover. This is the big difference with the optimistic rollups. In optimistic rollups, you need to wait for somebody to challenge this state. In the ZK rollup, this state, the prover just set this state. And you know for sure that this is valid. It's at this point where the user can withdraw the funds. So here, the most important piece, or the differential piece of a ZK rollup is the prover. The prover is a zero-knowledge proof, if you want a validity proof, that validates the transactions. Which transactions? Ethereum transactions. It's taking a state, it's taking a set of Ethereum transactions, and it's computing in your state and validating that this state is valid. So how the prover is built. So what's inside the prover? The prover is a set of technologies. But the way we built this, we have a circuit, we say a traditional circuit, written in PIL, specific language we built for the ZKBM. That's mainly a processor. It's a generic processor. It's generic. It's with some specifies that. But it's a processor that's built with this zero-knowledge technology. And on top of this processor, we are running a program. We call it a ROM. That actually is an Ethereum, it emulates Ethereum. It actually, this program is the one that is actually taking the transactions, analyzing the transactions, checking that the signature is valid, discounting the balances, checking the fees, deploying the smart contracts, executing the smart contracts, and doing exactly the same that does get or that doesn't in Ethereum node. Just processing these transactions. All this goes to a prover, and this prover is the one that's verified it on chain. If you zoom in in the processor, well, we have mainly a processor. It's this ZK processor. All this processor is very tailor-made for the ZKBM. So it's not like a very generic processor. It's this part that's generic. But there are specific pieces that are made explicitly to be optimal for running the ZKBM program. This processor has a ROM, which contains this program that's executed, contains a storage, because the EVM, you should be able to store values and get the values. It has also a kind of a sub-processor that handles all the binary operations. Here includes addition, subtraction, and source, extors, and so on. It has a model that's for arithmetic. This is in the EVM. It works in 256 bits. So this arithmetic circuit actually does all these operations in the 256 bits. And then has the hashing for catch-axe and other hashes that are also inside this processor. On top of this processor, there is this ROM. This ROM is written in a specific assembly for this processor. And here it contains all the logic. Actually, it will contain all the theorem logic that we are processing here. Here I want to show you just a snippet of code of how this looks like. This is just, for example, the opcodes dub1 and dub2. But here we have all the opcodes. We have implemented all the theorem opcodes at this point. And then once we run this, then we need the cryptographic prover. The cryptographic prover, what we do is mainly we are using a Starks with a very optimal way to compute proving systems. We are using Goldilocks. This is a technology for people from our colleagues in Polygon Zero that makes to build these proofs really fast. And it's a kind of a recursion, so a prover can aggregate many proofs. And at the end, this is a Starks. And at the end, what it's doing is we are converting. We are verifying this Starks with a snark. So at the end, we just, in Ethereum, we are just verifying a normal, gross 16- or plonk proof. It's just a circumcircuit in the bottom of that piece. So this is the stack, the cryptographic stack, for verifying that. So let's cross fingers and let's try to see the demo. Let's see if it works. If it doesn't work, you can try it. You can go to public.zkvm.slashtest.net and test it. You will see that it's very simple. The demo that I'm going to do is, first of all, I'm going to breach it. Let me just switch. So the first thing I'm going to do is I'm going to breach. So I'm going to go early. I'm going to go early network. I have an account here that has 3 go early already. And it's just a strike new account that I just created before this. So the first thing that I'm going to do is I'm going to transfer. I'm going to breach three ethers, well, 0.25 ethers. This is the maximum that we allow here in this testnet just to protect some Daniel of Service attacks here. And we are just to transfer to the layer root tool. So I'm in go early right now. So I'm just, let's see if Ethereum works. Okay, here we are. Let's breach it. Okay, so let's sign. Let me just modify the gas fee so that it takes, it goes faster. It's go early, so you never know. Save, okay, and then just send this transaction. Okay, now that, so we just deposited transaction. This transaction is mining in go early. We need to wait also a little bit so that this transaction is kind of a final so that this transaction is included. Right now, this is already done. What we have done is we just put this transaction in a Merkle tree and then the root of this Merkle tree of all deposits is passed as the state of the rollup. The sequencer, actually there has not been any special transaction on chain because the sequencer already takes in account that, okay? So now let's finalize this, okay? And this finalize what this doing is collecting is doing an L2 transaction to collect these funds, this Ethereum in the layer tool. So here, when I push here, the first thing that it's asking me is just to switch the network. So I'm just switching the network. Now I'm just signing the transaction in layer tool. Okay, I just signed the transaction. Let's see if it works. There we go, here it is, okay? So now if I check the account, I'm in the layer tool. Now I have the 0.25 feature in the layer tool, okay? So now let's go to do something with this account, okay? Let's create a smart contract and deploy it in this layer tool. So let's go to remix. Just gonna use an example, very simple smart contract. This looks like remix is gone. So let's just let it work. This is just a very example smart contract. So let me compile. Let me compile this smart contract, here it is. And now I'm going to deploy it to the layer tool. So I'm going to connect this to Metamask, okay? I'm just using this account. And then I'm just, well, this is, I don't know if I'm connected to the last one. Well, just connect here. Okay, this is the one that I just did. I have a 25 feature here. So let's deploy this, okay? So just deploy this smart contract. It has me to sign, just confirm this transaction. See if it goes, it's internet is not like the fastest thing here, but here is, okay? So now here we have the smart contract. If we do a get A, we get a zero. But if we, for example, we set a 22, so this will generate a transaction that to set this state variable to 22, we sign it, confirm, see if it is. And then just get the value. And I see here 22 right here. Okay, so I just deploy that in layer tool like any other network here, okay? So what's going on in here? So let's see the, let's go to the, let's go to the, this is the roll out the smart contract in the layer one, okay? And here we see two kinds of transactions. One are the sequence batches like here, where here you can see in the data that this is here are all the transactions that we are setting, okay? But in parallel, but in parallel to this, we have the batches, the batches is the prover that's generating batches. That's actually validating these transactions. And here is where all the magic happens, okay? Here in the blockchain, you cannot see much, but here is the proof. Actually this is the growth 16 proof in this case that validates all the transactions that we have been processing, processing, okay? So until here is, well, I can, maybe I can give you a bonus, bonus track here. So we can go, for example, to uniswap, okay? This uniswap is already deployed, as is without compiling and recompiling anything. It's just a normal uniswap is deployed in layer two. And here we can do, for example, a transfer. Let me just change the account to the first one so that I have some tokens to exchange, okay? And here I want to compare from full to bar just normal swap, okay? It's fetching the price, I'm just doing the swap. Confirm swap, now I should sign the transaction. So here we have deployed it. So here we have already deployed it, the full uniswap version three in the layer two and all this is verified in the prover. Just confirm that, okay? Now this is confirmed, now here the uniswap interface has some, it's iterating, it takes maybe some 10 seconds or so to realize that the transaction has been moved. But that's mainly the thing, okay? So let me go, let me see if it finished this. Just here it is, okay? So I already do the swap so I can just check in the swap just like normal, like any other Ethereum transaction. So let me switch back to the presentation. So nothing fancy, right? That's the cool thing. And that's the strange things even for me explaining. For me, here I'm just feeling that I did a demo of Ethereum. But this is the interesting thing. It's that all this is running, all this is validated in the prover. All these transactions that are really complex are all the uniswap transactions and everything this is validated inside the prover. And this is what this ZKVM and the main importance of this design. You don't have to recompile anything. You just take the code, exactly the same code. You don't have to re-audit anything. You don't have to learn anything. You can use exactly the same tooling. You can use the same language, the same gas model. It's no difference for developers. They should not notice any difference in deploying, in working with Ethereum or in ZKVM. The only difference should be the gas price and the quantity of transactions that you should be able to deploy. This is a test net. Please test it. We have been running for this week already. We have more than 1,000 accounts. We have, most of them are just deploying transactions. Some of the projects are ready tested, already tested without any big issue. We have some reports of some bugs that we have been fixed it also and we will continue work. It's this test net is a little bit like a baby. It was born last Monday, but it's going to get stronger and this is the previous stage just to the main net. Here is, okay, and what's the limit of the scaling list? We don't know yet. What's clear is not going to be in the prover. It's going to be maybe in the data availability. It's going to be maybe in the sequencer in the other pieces. But why? Because the prover can be parallelized. And here the important part, actually, for example, we are running seven provers at this point because this week there is main transactions. Some of the provers have been stopped. So we are just trying to catch up with some of these transactions. But this is the cool thing. You can run as many provers as we want. So if there is a lot of demand, we just running more provers. And the only thing you need to take in account is what's the cost per transaction because running these servers are not free. So what's this cost? Well, the cost right now is less than one cent per transaction. And there is, this is in AWS cost, which is probably the most expensive cloud service in the world. And there is also a lot of optimizations that are coming. Here in GPU, we can, we believe that we can improve one order of magnitude and there is other improvements that we are working on that. But prover is not the bottleneck anymore. What's missing? Not much. So we are fully compatible. We are running all the O codes. Everything works as Ethereum is. There are some things that we are already implementing. They are not implemented yet. And I'm just listening here, but everything is there. What is missing is that pre-IP is the original Ethereum transactions. This is mainly to deploy, mainly not safe, but it's just for these smart contracts that have the same address in many chains. They are using these primitive transactions that they don't include the chain ID. We are implementing those. And then we are not supporting yet the SHA-256, the Blake and the Paydings pre-compile to smart contracts. But this is a work in progress. All of them are doable and we will work on those in the coming months. There is the audit. I don't want to entertain the audit, but this is probably the most challenging part that we are facing right now. There is a full plan for running these audits. If anyone interested in that, please contact me. What else are we working on? We are working also in the aggregating of the proof. Right now the aggregator, right now we are running one proof per batch, but we have to run one. So we need to aggregate all these proofs in a single transaction and in a single proof, actually. We are working in this proof. This is not that much because we have all the recursion already done and it's just putting them together. But it's a piece that we need to put there. And we're also working with the AAP-4844 for line-charging. This is clearly the future for the scalability and we're already working on that. We are very excited on that. I have to recognize that when I read this AAP, I was very skeptical at the beginning, but it's really the way to go. We can implement insight and it really will go even faster and it's even better than what I would do. It's just that the only thing is that you need to go a little bit deep to understand this EIP. That's really interesting. I'm very excited for this scaling. Testing. We're running the Ethereum test suites. Right now we are at 97% of passing all these tests. There are edge cases that we're still working on that, but I'm sure that very soon we will be covering, will be in 100% of the Ethereum test. Broadmap, of course, we just launched at the public test net. We need to audit and we will launch when it's ready. Here is, we want to be enough safe. We want enough sure that, so 100% safe is going to be impossible, but we want to be responsible and we want to audit this very well and when we feel comfortable then we will launch. A reminder, everything is open source. You can take a look. You can see, you can review everything is in the GitHub repositories. And yeah, GKBM is no longer a myth. Here you have the GKBM. Thank you so much. We have a couple of minutes for questions. So if you have a question, please raise your hand. Hello, thank you for the presentation. The EVM is not a frozen object. It's living and it's evolving with new EIPs and we are going to see possibly big change like the EOF or other things like that. And they will be way easier to implement for startups and for you. So are you worried that some possible EVM change will be hard to translate into circuits in the future? We need to see which are those changes and once I see the changes, I will tell you. But there is one thing that, because this is some of the questions that I receive. It is sometimes it's more about the upgradeability of this what happened if the GKBM upgrade and then what happened with the rollup, it will upgrade if you want a decentralized system. And but here is, we need to understand as a community that the EVM at this point is evolving because it's working progress, but at some point this will need to be frozen. I don't know when and how, but and I'm not talking about the ZKBM, I'm talking about the EVM. So the EVM, if you want, I believe, I hope, and talking with people with the EF, they already think very much on that time is that at some point, maybe in two years, three years, five years, once the Ethereum is finished, then the EVM will be frozen and then it will be also the time to freeze the rollups. Thank you for the presentation, great talk. I would like, I mean, could you detail a little bit what are the edge cases that you are meeting regarding the failing tests? Here we have Carlos in the room, that's responsible for testing, you can ask them, but they are very, very complex ones. It's a call of a static call and then do a surface track and do whatever. These are very, very edge cases, very, very edge cases tested, but you have to look at it because you never know one and it's important that's why those tests are there, but they are really, really edge cases at this point and complex ones. Hi, thank you for the presentation. When you were showing the, on Ethereum scan, the contents of the batch, you showed that there was encoded set of transactions. Is there any way to decode them to see what exactly is in the batch? Yeah, it's mainly other transactions, one after the other. We have some internal tooling just to take a look on that. Well, actually they are open source, you can check the repositories, but we are building it. And in any case, it would not be difficult to interpret at the end, it's just a format with the right of transactions. I think we have time for one more question. So if you can lend the microphone to our speaker. Ah, cool, go ahead. Hey, thank you, can you hear me? Yep. Okay, first of all, congratulations, this is amazing. When you launch, let's suppose it's early next year, obviously it's a very complicated system. If you find some bug or something that needs to be addressed, what can you do in that situation? But the strapping decentralized systems is not an easy topic. Here we have the experience of Hermes 1.0 in our team. And here you do some, I would say nasty tricks. Here is maybe you do an upgrade ability, things that you can do is an upgrade. So you can upgrade the smart contracts with maybe with a time lock. And you can do, for example, is limit the withdrawal flow that's living in the smart contract. So that it's like, if you are working with less than a certain amounts, you are freely decentralized. But if you want to run fast and run bigger numbers, then you have the option to go centralized or just or white. There are some tricks for bootstrapping, but these are just temporary solutions until we feel comfortable. At some point, the roll-up should go along. We are building a decentralized system and it should be safe enough. Here is who we are managing that in the beginning. Thank you so much. Jersey Valina, please give him an applause.