Multi-Verifiers as a Hedge Against Bridge Vulnerabilities

Transcript

[Music] energy [Music] hello hello everyone my name is tall girl I do research at scroll you might have seen me on Twitter arguing about the definition of a roll up from time to time and today we're going to be talking about multi-verifiers as a hedge against validating Bridge implementation vulnerabilities so you might have heard about roll-ups and you probably also heard that they're quite complex

as you can see from this screenshot and because they're complex there are certain things that are missing and certain things that are slow to being added and just as an example of some moving parts that you have in a roll of construction you have a sequencer you have approver oh I'm talking about a ZK Rob uh there's a ziki VM circuit for zkvm ZK Roll-Ups there's bridging mechanics there's Zone chain verifier and there are loads more things and they're all complex and they're difficult to audit and they're difficult to ensure that they're working correctly so there are a few they've been a few Solutions proposed to minimize the vulnerabilities

so you might have heard of multi-provers vitalik did a talk last year about it and Justin Drake also made a proposal about how to implement multi-provers so that is quite simple a multiprover is a system that utilizes two or more distinct proving systems to enforce the validity so basically for example you can have a Halo 2 based zero knowledge proof and a map space for approves and if both of them agree on the same state then that's it you are almost guaranteed that there are no vulnerabilities in one of those systems another example you can even have three

proper three different proof systems so you can have a stark based zero knowledge proof you can have an HDX bass proof and you can have well their comedy and for example you can only also do where like if two out of three agree then the state route is accepted as valid so here's an example how it works so in a traditional roll-up you submit a batch is he care all up my dad and then you submit a proof and that's it that's how it works and in a case where you have a multi-prover the way it will work is you submit a batch you submit proof one and you submit proof to you and if both of them agree then you continue submitting the batches if not the roll-up stops and there are depending on a specific

implementation you have different mechanics of how how to handle the discrepancy uh so essentially if there's a disagreement between two proofs uh an external Security Council can arbitrate and pick the one that they think is correct there are other ways you can also do it but that's the prevalent opinion of how you should do it so that's on the prover side but what about smart contracts they're also complex and as this never-ending list shows us there's a never-ending list of hacks that happens because of smart contract bugs and vulnerabilities so how do we solve that that's where multi-verifiers come in so what is a multi-verifier a

multi-verifier is a system that utilizes two or more distinct validating bridge implementations to enforce validity so uh the the reason why you would do it is to protect against implementation bugs and the and the bridge the two implementations should share the storage and should also be gas efficient because I'd say if it's very expensive to have two implementations users are likely going to choose the implementation the protocol that has only one Bridge because it's just cheaper for them to use so the difference has to be negligible and the multi-verifier consists of three different parts so there's an entry point contract that I'll explain later

there's verifier solidity which is a bridge implementation and solidity and then there's verifier Viper which is an implementation of Viper you can also use other languages like half or fee or whatever but for this example let's assume that it's solidity and Viper so what is an entry point entry point is the publicly accessible API so essentially if the user or the sequencer or the prover once they're interact with the contract they do it through the entry point so they can't access the verifier solidity or verify Viper directly it handles communication with verifier solidity and verify vipers so basically the user sends for example an L1 to an

L2 message to the entry point contract and then it calls the verifier solidity and verify wiper respectively and it's the only one that has the privilege to write to the storage so the verifier solidity and verify Viper can only store things in memory they cannot actually write the storage and the main purpose of this contract is to verify the consistency of values returned by the two implementations so now for verifier solidity it's a solidity implementation of the welding Birch logic it doesn't have permission to write but it has permission to read from Storage same as with Viper the only difference is you use Viper instead of solidity so

how it works so you have an entry point contract let's say I as a user submit a batch once the batch is submitted I the entry point contracts requests one of the contracts so the way they implement it is one has to be a driving bridge and the other has to be the one that basically Returns the values that are checked against each other so in this case for example solidity is the driving Bridge so you would send the request to process the submission of the batch then the verify solidity Returns the values that need to be written to the storage then the same is done with the Viper contract you send the request to process

the submission and the Viper contract Returns the values that need need to be checked against the request that were sent by solidity to process the storage and if both of them agree great we continue and the same happens with with a proof after the batch is processed so you ask the Solarity verifier to process the submission and then it returns to values that need to be written to the storage you do the same with wiper blah blah blah blah blah blah and basically if they agree then perfect we have a finalized block or a batch or whatever you want to call it and again the same with multi-provers if

there's a disagreement between the two uh there's a external Security Council that can just pick whichever one is correct you can do it in other ways as well again but thus we'll just copy the prevalent the prevalent idea on the multi-provers side and you can also combine the multi-provers and essentially get a system there just drastically decreases the possibility of implementational bugs because you need to have identical bugs in both systems on either the prover or or the verifier side which is unlikely to happen and the likeliers vulnerability that you're still going to

have is some specific some uh vulnerability on the on the specification level so for example when you define the British functionality you forget a certain check sanity check that needs to be implemented and basically that is used to hot because having to implementation doesn't protect against that because you'll just copy the same specification that's it for my talk thank you very much and if you have any questions feel free to ask hello

um so my question is this is purely to prevent a technical how do you say a problem in the smart contract right yes so it's purely to prevent an accidental bug in the implementation of the smart contract that's what I mean yeah okay and is this already used in some kind of product not really as far as I know uh I feel like um there are a few people who are discussing it and I also talked about it with vitalik and I feel like people underestimate the the attack Vector on the smart contract side

so for example a lot of people talk about multi-provers Etc but like because multi-provers are more complex there are fewer people that can actually exploit a bug on the prover side whereas smart contracts are much more accessible to people and a lot more people know solidity so it's more likely that people are gonna discover some sort of bug on the smart contract side so this allows you to have it but as far as I know nobody has implemented it so it's still a theoretical thing thank you thank you so different ckvms have different gas fees hash functions Etc how can you

prove use different provers if the ebms are different so you can implement two different provers that follow the same state transition function so let's say you can have a theory so what we're working at the moment at scroll is what is I showed here sorry let me just get back um yeah this one so uh we're implementing at the moment is an sgx based proofer so essentially you just come you just implement the same stage transition function that you have on the start snark based prover side

and you implement it inside sgx and you have a second prover and in this case it's one of the few use cases where sgx actually makes sense and it's not it doesn't really affect your security because it's purely additive so if it fails you cannot steal money or anything as long as there's not as the same bug on the snark River Side the only thing that it can do is it can just hold the chain until the security Council picks the correct proof I guess that's it then thank you very

much [Applause] [Music] [Music] go ahead