# ETHWarsaw 2023: Toghrul Maharramov, Scroll - Trustless Bridges: A Myth or Reality?

- Speakers: Toghrul Maharramov
- Channel: [ETH Warsaw](https://streameth.org/eth-warsaw)
- Date: 2024-10-07
- Duration: 23:37
- Topics: main stage, day 1
- Watch: https://streameth.org/watch/yt-UsEON34P88w
- YouTube: https://www.youtube.com/watch?v=UsEON34P88w

## Description

Presentation - A brief talk by Toghrul Maharramov from Scroll. This presentation focuses on trustless bridges.

Follow us for more updates: https://twitter.com/ETHWarsaw

## Transcript

hello everyone my name is tol I do a research at scroll but you can mostly find me posting on Twitter that's what I mostly spend my time on and today we're going to be talking about bridges specifically trustless Bridges and whether they are a myth or a reality so you might have seen quite a few of these articles or papers so this is an example from uh near protocols Rainbow Bridge it says eth near Rainbow Bridge is a trustless permissionless protocol blah blah blah blah blah blah or another one it's the harmony Bridge it's Horizon a gas efficient trustless bridge for cross chain transactions or yet another one ZK Bridge trustless cross-chain bridges made practical or even from the EF Pages uh page so yeah you have trustless having equivalence security to underlying domains so trustless trustless trustless trustless even more trustless trustless trustless so let's first Define what trustless is um but let's not use the definition that Avalanche uses because uh no they already deleted this definition I after I called them out but let's just read this beauty because it's it's beautiful it's the Avalanche bridge is trustless in the sense that that no party is able to access any of the funds held as collateral or mint wrapped assets all transfers across the bridge must be approved by six out of eight independent parties blah blah blah blah beautiful doesn't really make sense but sounds great so what is actually trustless and no TR trustless doesn't mean that we don't make any trust assumptions whatsoever like doesn't matter what we do in life there are always some sort of trust assumptions being made so what is trustless then so you can Define trustless as the minimum amount of security assumptions required to interact with a protocol through a full node and uh I'll explain what a full node later uh is later so it's essentially the minimum amount of assumptions you can have in order to use a protocol it's not really possible to make fewer assumptions than that so uh what is a full node a full node is a client that can verify the correctness of the consensus and execute the state transitions of the protocol uh note that there's a difference between verify State Transitions and executing them because you can use something like zero knowledge proofs to prove the correctness of the state transition function but then you make an additional assumption by executing I mean you actually take all the transactions execute them and verify that the outputs produced by those transactions are correct and that's the role of the full node and what does a security assumption mean uh uh security assumption is a mechanism property that we expect to hold no matter what so for example when we use a bft consensus mechanism let's say tender we assume that there's 2/3 uh 2third of the participants are honest and if they're not the protocol is no longer functional it just breaks and so every single thing that we use doesn't matter what whether it's on the cryptography side or on the protocol side we always make some assumptions that they should work and so it's impossible for us to just dismiss those assumptions so for example when you use ethereum you have to assume that the hash function is secure and the signature scheme that you use is secure etc etc and there's no avoiding it and so Tresses in essence defines the type of interaction that you have with the protocol so trustless interaction with the protocol is an interaction through the full node so if you use your wallet for example and you don't connect to your own full node through an RPC but you use something like infura it's no longer trustless because you trust infura to provide you the correct data and you trust infura to actually send your transaction to the network whereas if you connect your wallet to your own RPC then you don't really trust anyone else because as long as your full node works then you know that all the data that you get is valid data and another thing that a lot of people get confused about is whether trustless is a spectrum or whether it's a binary thing and it is a binary thing because as I described before it's a minimal set of assumptions so if you add another assumption to that minimal set it's already not that minimum set it's a bigger set so therefore it cannot it cannot be a spectrum it's a binary thing so yeah you cannot have a spectrum of trustless for a given protocol and bear in mind mind that trustless would differ will differ from protocol to protocol so in ethereum your minimum base assumptions will be different from the minimum base assumption that you take for Bitcoin etc etc etc salana will be completely different and raise your hand if you think that your funds can be stolen if you have if you run a full node good congratulations to those who raised their hands you're completely wrong why well it's simple as long as you run a full node your your funds cannot be stolen because essentially your full node verifies all the state Transitions and checks whether everything is running as intended let's assume that there are no bugs if there are bugs it's a completely different story but for now let's assume that there are no bugs H but you might rightfully ask what if a dishonest majority produces an invalid blog that steals your funds what happens then well in that that case your full node will just reject that block and it will Fork yes it will result in a fork but at least you know that you will never accept an invalid block and that's what a lot of people misunderstand is that while you need an honest majority assumption for the protocol to function as attended if that honest majority assumption fails for some reason and there's a dishonest majority that can propose an invalid block it doesn't really affect your full no because it'll just reject any single every invalid block that is proposed and just continue as if that block was never produced in the first place and another game similar to the one that I question question that I previously posed raise your hand if you think that rollup bridges are trustless congratulations again the people who raised their their hands are wrong and again why because in my in my it seems pretty obvious you don't really make any honesty assumptions so it should be trustless but it actually isn't so rups rely on fraud proofs or validity proofs to facilitate communication to ensure the safety of the your communication between the L1 and the rollup and so fraud proofs require uh one out of n honesty assumption to be secure and zero and validity proofs require the security assumptions of the underlying zero knowledge proof system to hold which means that we make additional assumptions for that to be to work so think about it in this way so if you hold your phone on a full node then no matter what happens your funds can never be stolen and what happens if you bridge your funds uh to rollup can they be stolen yes there is a scenario where they can be stolen so in case of uh an optimistic rollup they can be stolen if there are no honest parties challenging and in case of zero knowledge rollups they can be stolen if there's a bug and the zero knowledge proof or your zero knowledge proof is insecure by specification and so the right question to ask is is trustless bridging even possible short answer no longer answer also no so the security guarantees of your Bridge funds should be equivalent to that of a full note so what I described before so if your Bridge from chain a to chain B if that communication is trustless you should have the same security guarantees that you have when uh having your funds on chain a well it's not really possible because any bridge by definition introduced introduces some kind of an additional assumption unless you're bridging between two chains sharing the same properties and the same guarantees so they share the consensus they share everything the da is the same everything is the same but at that point it's indistinguishable from a single chain you can run two chains and verify it via a single full node but from a user perspective that that's indistinguishable from having a single chain so with that out of the way let's go through uh the stuff that we started with and let's see if these Bridges can actually be qualified as trustless or not so is Rainbow Bridge trustless the answer is no and the reason why it makes an honest majority assumption so uh Rainbow Bridge is a light client essentially so it Bridges funds from one chain to another and has a light C on other chain that verifies that the bridging was done correctly and if that chain for some reason has an dishonest majority well yeah your full node can ignore it but if your funds are being bridged back then there's nothing your full node can do your funds are basically gone Horizon is a trustless again no same thing honest majority assumption it relies that both of the chains are honest and if one of them break then your funds are gone basically CK Rich yeah surprise surprise same thing no same thing honest majority assumption so with that out of the way next time you see a trustless bridge think about this it's a trust me bro Bridge or it's a trustless bridge but there are certain terms and conditions that apply that you need to be aware of or in some cases a trustless bridge it's just a trust minimized Bridge so for example in the case of rollups thank you for your attention and feel free to ask any [Applause] questions first one right here hi hello VK so you said that uh you're assuming to the v no bugs in your full Noe why do you make a strange assumption that Z circuit is somehow different I mean what if no bugs in your circuit then it seems to me that it's trustless now because if there are bugs in your full node then essentially there's a bug in the protocol so it's more trivial to get a social consensus to revert and ignore that bug or whatever whereas if there's a bug in one of smart contracts it's much more difficult and unrealistic even to expect that the entire chain is going to roll back to patch that bug which means that you make a much bigger assumption that the social consensus will actually agree to roll back and fix it but assuming there is no bug sorry assuming there is no bug assuming that there's no bug in in in the proof system yeah in the proof system which then like considered this to be like almost trustless it's almost trustless but it's not because you can still have um not a bug but but just the system itself is broken by specifications for example we had an example like like that with zcash where it was discovered that an incorrect specification of the protocol led to a possibility that people could mint money out of f a and so essentially the same thing can happen in any system that uses zero knowledge proof okay another one here am I being ganged up on by l2b people no no I I hope not at least uh yeah uh so uh thanks and I generally agree with most of what you said but now when I think about something that I actually know probably most about which is like uh uh starx exchanges which are also layer toos but not general for General computation and the way it works is that with the Escape hatches that are built in and force transactions which means that because it's a kind of simple setup where ethereum does know the miracle route of the whole state which means that assuming there is no bug then I can always unlock my money by providing a miracle proof to that contract on ethereum which in that case in my head is that I can only I can consider it trustless assuming there are no bugs in the smart contract right and would you say that still this is not a trustless bridge but you don't need a bug for that to happen what if the proof system is broken and I can just produce an invalid Merkel tree that moves funds from you to me for example and then I exit by exiting um by proving the the uh the inclusion to an invalid Merkel tree there's no bug there but the proof system is broken and you can still produce an invalid State transition wouldn't you call it a bug in a proof system that would allow that but but but but I I I would say that a bug is an implementational uh comes on come on the implementational side so for example if you're implementing and Implement specification correctly whereas if there's a fundamental problem in the proof system that you're using then it's not really a bug it's just a broken proof system that you're using so that's what my argument is bugs aside you can protect against bugs somewhat by using multipro etc etc whereas you cannot really protect yourself against an invalid proof system yeah I I I agree I think that actually in you can think about in theory if everything is working perfectly as the theory would set like almost as academic discussion it would be trustless assuming that nothing wrong would happens the construct itself is valid I would say for the but in the practice you're right there are so there are security assumptions always and they grow with elements of the number of elements of the system thanks yes so if you can prove that the you can guarantee that the proof system has no vulnerabilities and is completely sound and robust then yes but I'm not aware of any way you can actually prove that he man hello so what would be in your opinion architecture for a trustless bridge I don't think they there can be one so as I said before the only way you can have a true trustless bridge is if the consensus and everything is shared between two chains in a sense that it's essentially just one protocol that has two different data bases that move data from one to another but at that point it's not really distinguishable from having a single chain so I would say that it's not really possible to have a trustless bridge not even with a light client that would send the proof to a different chain but a light client relies on an honest majority assumption so for example let's say if the I send my usdc from chain a to chain B and I want to bring it back but there's a dishonest maj majority running the chain B and they produce an invalid block that contains an invalid transaction in it that steals all my usdc and they try to bringe it back there's not a lot you can do there so light clients are just not enough because you still need that honest majority assumption there but isn't this the same point as 51% attack on bitcoin sorry isn't this the same uh as 51% attack on bitcoin it is possible but it's not feasible but with a 1% attack I cannot really steal funds because a full node will just reject an invalid block whereas in here I can Bridge back and steal funds because full node cannot do anything because it's a light client implemented on another chain so the difference here is that a full node in ethereum or or Bitcoin or any other L1 can just reject an invalid block whereas if you're bridging back there's nobody to reject that block thanks anyone anymore ah in the back yeah hello hello uh so I'd like to ask you H if by saying it is not possible to have trusters Bridge you mean your trust is as weak as the weakest element yes essentially you introduced an additional trust assumption always when Jing and therefore the overall security of the protocol is always weaker than just using an L1 without bridging so you're always going to have additional trust assumptions involved there yeah so but how do you respond because like if you start thinking like that you need to have like you can solve all the problems using redundancy let's say you have like a light client you can verify it in multiple ways multiple like in all proof systems we know for example and you pick five out of seven uh and but if you think like that like you it's like turtles all the way down right oh 100% you can you can minimize the possibility of that happening so for example there's talk about using multi provs for rollups to basically have multiple different proof systems uh commit to a state and then if this if both of them agree on the same state route then the bridge functions as as as intended whether whereas if they disagree for one reason or another the bridge stops and then you either use governance or some other form to uh to resolve that that obviously minimizes the the possibility of something going wrong but that still doesn't completely remove it because while it's improbable to imagine that two different proof system can have the same vulnerability that's still theoretically possible yeah but what you're saying here is that you don't believe in the probabilistic proof like you don't believe that the proof something can be proved like 99 per 9999 and like you say this is not enough but this is how zero knowledge proofs work these days right so would you say that you don't believe in zero knowledge in general but every single zero knowledge paper mentions that there's a negligible possibility that they can be broken which means that there's a possibility obviously it's completely negligible and the probability is usually like uh 2 to the power of minus 100 or something completely impossible but it's not zero so uh that's why I would say that there's a difference between trust minimized to the point where the probability of something going wrong is negligible versus trust minimize trustless where the probability of something go going wrong is zero thank you any more takers in the front okay given that you stated that those bridges can't be uh trusted what is your desired rout of the entire ecosystem to go forward is it possible to enhance those bridges is given that trust being trustful is impossible make could you uh repeat a bit louder because I can barely hear you sorry about that give that you stated that Bridges can't be trusted fully uh what are your recipes for the ecosystem to go forward given that um so from my perspective that are two R either somehow make the bridges as secure as a zero knowledge proof as was stated earlier or for example introduce something like Big Blocks yeah so while when when I say that they cannot be true trustless they can be hardened and made secure to the point where the probability of something going wrong is very very small so an example of how you can do that is by using multipro as I mentioned previously where two different proof systems agree with one another and you can even use three or more so it's up to you how many you can use and the same can be true on the smart contract side so you can use multi verifiers so let's say you take a specification of the contract and you implement one in solidity and one in Viper and if both of them agree on the same outcome then the bridge functions is intended and if they disagree for one reason or another then you know that one of them is broken which means that you stop the bridge and then you uh analyze what happened that that in my opinion is the most secure setup you can have for a bridge but yeah would you consider uh promoting Solutions like uh increasing the block sorry sorry if would you be satisfied with solution that included uh removing Bridges and increasing block size but that's not really a viable option especially let uh especially let's take ethereum uh as an example here one of the core philosophies of ethereum is that you should be able to run a full node on relatively cheap Hardware so increasing the blocks even if we assume that there are no bottlenecks and you can just infinitely increase the gas limit will result in full nodes being inaccessible to average users which means that we either have to rely on centralized services like rpcs etc etc run light clients which is are okay for a lot of users but are not the solution per se or I understand that it's not perfect but is it better worse than having bridges that are faulty I feel like having Bridges is a better option because you can Harden them and the likelihood of something going wrong is much lower but on top of that if you don't increase the block size on ethereum people always have an option to just use ethereum without using bridging to like rollups etc etc so they always have that option whereas if you increase the block size in a lot of the cases people just won't be able to afford to run a full node thank you okay then thank you to thank thank you very [Music] much