Lightning Talk: Security & Diversity in VMs by Mauro Toscano, LambdaClass

Transcript

Hometown hero Maro Tusano from Lambda class going to be speaking about sec security and diversity in in VMs. [applause] Well, hello everyone. and I'm Tosskano, part of the department of Ethereum alignment or so says my hat and lambda class and align um and I'm going to talk a little bit about security in VMs. I'm not going to focus on the cryptography part. I think like Arancha already did a good job there and there will probably be more speakers that will focus on that. But I want to show you a little bit uh how a VM works and what can be exploited. Um so the the VMs are very

complex machines uh to prove like we have uh three at least three kinds of proofs in our VMs. We prove like what we call like the base layers uh then we compress them with stars protocol then we further compress it with ECC protocols and inside of each proof we have arithmetization circuits IOPS and polomial commitment schemes uh we use a protocol that is called shamir and we have lookup arguments. So a lot of pieces a lot of pieces uh and if we an attacker only needs to break one and all the system collapse. If fear is wrong everything collapses arithmetization is wrong everything collapses. So we need to make to be very sure that everything everything is

really really fine. So the other important thing is that okay we have a compress proer that does a good job but we also need to decide what to prove and what what we are interesting in proving is an Ethereum execution client and right now uh there are two alternatives and there are more teams working on more is red or it uh and this means that we have around 35,000 lines of code that should be very very well written we have 60 direct direct dependencies and over 250 transitive dependencies. And when you convert this to assembly to a compiler, now we have to prove around 700 um,000 lines of assembly. And that's what we

are proving. And these 700,000 lines of assembly assembly, they need to be once again very very fine, very well written and have no bugs. If there is a bug, then we are in big big problem. So of course like when we want to attack a VM or when an attacker wants to attack a VM uh we will have classical attacks like if the brewers fails with an input like this will lead to an denial of service and if enough brewers fail like we could halt a network and that's not very good.

Uh we could try to compromise or an opponent could try to compromise uh the machines running the the verifiers. That's probably another big problem. But that's on the classical side. You probably know that uh already. Uh in CK we also get about two specific types. We call it completeness um and soundness. That means that we have a problem also if a a user cannot prove a statement that is true. For example, they cannot prove that they own their own wallet. And the worst worst thing is a soundness bug that let's say I can prove that I'm Satoshi. Um you probably don't won't believe me if I say that and you will be right in not believing me but if there is a bug uh we we may be able and what

we are usually focusing is more on the white hat uh hacking and this is going to be a duel of nights like we will create papers and we will say okay your admitization circuit is wrong your fear shamir is wrong uh maybe everything is okay maybe a crypto analyst will say you don't have enough bits of security and I can break is but I will argue that we also need to take care with uh black hats uh techniques like because for example let's say that uh we have a VM that is not fully compliant and it has like 250 dependencies and a compiler so can an opponent graph a payload that only affects your VM uh maybe they can and of those 250 dependencies many have

one one maintain container and they are all in our code. They are all in the code we are proving is something to be aware of uh in particular when the VMs are not compliant and uh code that works on all machines fail in the CKVMs uh because like of course like the developers of those libraries they don't know about uh CKVMs. Uh what can we do? What can we do to make uh safer systems? I'm a big proponent that the way to make safer systems is just to add redundancy. We need to assume that things will get broken, that our proer is broken, that the guest program is broken, that everything is broken. So what what do we

do? We add more checks. We add more provers. We say, "Okay, we have five brewers, seven provers, eight provers. They need to agree. If they don't agree, I'm going to start suspecting that something went wrong." Uh one of the key problems that that we still have is like okay we have like around 10 provers maybe some in progress some some some some more develop some less develop they are all proving the same execution client that's probably not good like that there is a single point of failure shared between all the proer clients and also many use the same cryptographic libraries so if there is a bug in the start protocol everything collapses too uh and even the compiler one could argue that it might make sense uh to to be

careful about the compiler. So that's for me always like the the the right solution is to have redundancy but of course it's important to have robust code and there are some good efforts and and some amazing efforts on formal verification on particular of the VMs uh which is straightforward in the verifiers. I haven't read much about how to do it with the guest programs and all these lines of assembly. uh maybe someone knows more is seems like something worth exploring. Uh of course fasting might help us to to try to find inputs that makes the the the programs crash. And the last thing is I think we should also try to have to have uh more people watching the code like teach more

people don't let's try to not be close because like if only two two people or five know how something works is very hard to find a bug. Uh maybe you know for someone who is in the audience you you don't have time to start reverse engineing everything and see if it is fine. So we should make an effort for people to not have to spend a year to try to understand what's going on and and just take a look and say okay this seem reasonable or not then write simple code uh I think that's something we we focus a lot but try to write simple code don't be fancy uh make things as simple as possible and as I said before like be compliant with specs like I know that sometimes we can get an advantage if we

we don't comply with with specs but it starts adding like degrees of freedom. Now, now you you need to think okay like this should be fine but actually we are not fully fullying not we are not fully following specs so maybe there there is something that can be okay that's the end of my presentation I hope like you like it um yeah we need to be very serious about this Ethereum is the most important uh financial system for the world like we we are going to we have millions and millions of of money on it. We need to make sure that everything is really really safe and secure. Uh any questions?

>> Yeah, we have a couple questions from the audience. So, which part of the ZK VM stack or library is used in the project the most? I.e. what brings the most fragility? Yes, as I said, I feel like right now the the part that that is everywhere is execution client. The execution client seems to me like the first uh share thing that everyone is using. Everyone is using red uh like living a vendor that they have the their own. Uh so that's probably the first thing to start uh decentralizing a little bit. The second thing is probably the plunky 3 that is amazing but I feel like many many many projects are using it. Uh

>> yes. >> Uh the the last question is how many verifiers for the provers uh are going to be embedded in the clients was verifier EVM verifier? Uh >> I think that's more a question that we should ask as a community. I don't have an answer. uh the more verifiers the better from the point of sense of soundness not from the point of sense of completeness um and denial of service attack because if I require 10 out of 10 uh seek improvers and I can shoot down shut down one then the system doesn't advance so we will need to to discuss tradeoffs I think like right now is we are the foundation has been thinking of

something about five out of eight out of eight Um, so that's probably a good number. [applause] >> Thank you very much. Ping area. Uh