Security Summit 🦺 Securing Validating Bridges

[Music] today I'm going to give a short Roundup about validating Bridges and specifically how to secure them because we been talking and working a lot on on rollups for for quite a long time but we're they're all still quite insecure and and therefore there are a lot of trust assumptions that are not there by default that we currently have so you all of you probably heard about rollups and you probably heard a lot of people say that they inherit some security guarantees from the underlying base there specifically validity which in this uh sense in this context means U enforcement of State transition correctness though I'm need to add that that requires the assumption that the underlying proof system functions correctly so in case of of rollups optimistic rollups FR proofs it's one out of n honesty assumption and for zero knowledge rups that's typically the correctness of their underlying proof system they also enforce ordering which means that if a certain transaction sequence is finalized unless a dishonest majority on the underlying layer reorders it that it guarantees that the sequence is always going to stay in the same order it's going to remain immutable sensorship resistance which is difficult to Define but for this just to simplify things we can Define it as a guarantee that a transaction user generat transaction is going to be included in a block within a certain predefined period of time assuming that the user pays enough and fees and finally data availability which is just using the underlying layer's ability to distribute data to whomever needs to access it within a certain period of time and that basically allows us to use the underlying layer to re to reconstruct the state for the rollup and that's how we get all the trust minimized bridging that we have on a on a classic rollup but in this case in in the case of this presentation we only care about safety so specifically let's define safety for this use cases how can an adversary or hacker steal your funds and Let's ignore fraud and validity provs and that they enforce correctness for for for this case it it doesn't really matter so we have a problem smart contracts can have bugs and validating bridges that rollups use are smart contracts and they're complex smart contracts so it's difficult to enforce the correctness so and the solution is upgradability so let's say if we find a bug that is critical or quite a serious bug we have to upgrade and that we can't wait for let's say a month or two months before that upgrade is actually enacted it has to be immediate and specifically we use multi6 for that in most of the current setups and the problem with that is that they require an anesty assumption which means that you degrade the assumptions of a validating Bridge from the correctness of the of the proof system to an on the Assumption of the multisig so let's say if there are 12 members of the multisig you need to assume that seven of them are honest for example um and the solution is don't build smart contracts with bugs no I wish it was that easier uh actually the solution requires a it's multifaceted and it's quite complex so problem one and I'll divide the solution into into sub problems into two sub problems proofs are complex and the solution is multipro so what are multipro uh multipro were originally produced by vitalic in 2022 um it's during his talk at roll up day in Bogata that he first spoke about them publicly and they were concretely expanded by A variation of a multipro uh by a proposal by Justin Drake later in the year specifically this one it's called 2fa zare rollups using sgx so essentially in this case Justin proposes using sgx and a sec as a second Pro and enforcing validity of the uh validating Bridge enforcing the validity only if both proof agree so you can think of uh multi-prover as a as a setup that requires two or more distinct proof systems to assert the equalent output so and I'll exp I'll give an example later and if proof systems disagree then the validating bridge halts and then you can have various setups on on how to recover from the halt so you can use a multi-c which picks the correct one or you can use governance to recover but that's up to a specific protocol that's an implementational detail but what matters is that a single failure of a of a proof system doesn't cause your funds to be drained and so for a safety to fail to prove systems have to have identical r vulnerabilities because if two have different bugs it's unlikely that those two different bugs can cause the same um State mutation that will allow the attacker to steal your funds which means that the probability of this happening is quite quite low I would even classify it as negligible so an example of a multipro setup so you can combine a Halo 2 Pro with an sgx Pro so you have a proof system a Zer knowled Pro system that is Halo 2 and you use Intel sgx as a second prer and you might think that sgx it doesn't have a great reputation but luckily for us in this case the security is additive because we don't rely of uh the safety of the funds doesn't rely on sgx it's purely additive here because if it fails the worst that can happen the bridge will stop the the approver can never steal funds from you if it fails and if both function as intended perfect then the bridge function is as intended no problems we just continue as if there was only one prover but then if one of the provs so in this case Halo to njx prover fails the validating Bridge holds and as I described before then basically we pass it on to governance or multis to decide which of the proofs we pick as the correct one and basically downgrade the security to single prover which is not ideal but it's better than having having a single approver that can just get exploited and drain and and the money from the bridge drained straight away and we have another problem which is smart contracts tend to be Throne to bugs and the solution is multif fire or verifiers in this case and I was the one that actually proposed multi verifiers so uh the idea of multi verifiers is to require two or more validating bridge implementations that assert equivalence of the state mutation so what I mean by it is you essentially run Implement two different validating Bridge just independently from one another and they share the same storage and essentially before committing to the storage uh we add a small as minimal as possible add-on uh contract that basically checks that the outputs of the two are the same so in this case if the validating Bridges disagree the validating Bridge the protocol just holds so for example you can combine a a solidity and a Viper validating Bridge implementations so you you'll have two independent Bridges the and a small contract that connects those two Bridges and if they disagree from one reason or another the bridge holds and then again we pass on the responsibility of picking the correct bridge to multisig or governance or again it's an implementational detail and again it's not ideal because you if there's a failure you downgrade your security to single bridge but it's again as in the previous case it's better than having just one validating Bridge because uh that means that if that validating single validating bridge is exploited your money is gone whereas in here the worst thing happens there's a livess failure so yeah so as I said if the if both validating Bridge implementations function as intended we just proceed as intendent so nothing happens the user doesn't even notice that there are two different uh Bridge implementations underneath but if one of if solidity of the Viper validating Bridge implementation fails withold and of course in both of those cases there's a bit of a downside especially if you combine the two and the downside is that the gas costs are relatively higher so in in in in in this case the gas cost would be roughly 50% higher and plus if you add a verifier approver on top you'll add 10 or 20% more on top of that so the user will end up paying more than in a setup where you only have one prover and one verifier but the advantage here is that you essentially reduce the probabilities of minimize the the probability of a proov system and a validating bridge failure which will which will result in money being stolen so the only thing that can happen in this case again is aliveness faure which is not great but it's a much better tradeoff than having your funds rined and now we let's assume that we uh solve the problem of bugs on the prover and validating Bridge level but there can still be bugs on the specification level so on the protocol levels because if you specify the protocol in the way where it's wable even if you have no implementational box there's still a vulnerability that can be exploited and maybe formal verification can solve it and basically the assumption is this the combination of multipro multi verifiers and multi and formal verification can potentially enable us to remove the need for instant upgrades so in case of validating Bridge what would happen is you would have an upgrade but it will be delayed and that will so let's assume that there's a multisig or there's governance that decides whether to initiate an upgrade or not and this delay allows any users that disagree with that upgrade for what whether it's malicious or whether because they don't like the new features introduced just to exit within that period of time so vitalic usually specifies the required uh delay as 30 days but you can think of it as yeah roughly 30 days or more so if that's the case then uh then you essentially have a system which guarantees temporary Im mutability so the users don't have to worry about a dishonest Security Council or or a team multi upgrading the contract and stealing their funds but also they don't have to worry about the bridge failing because there's an implementational bug or a specification bug on either the uh validating Bridge level or the approver level um thank you for listening to my talk if you have any questions feel free to ask