The Impact of Chain Forks and Reorgs on Cross-chain Bridges | Poming, Quantstamp | ETHTaipei 2023

way hi everyone this is Bowman Lee and it's my honor to present the impact of chain forks and reorganizations and cross-trained bridges and I'm with constant constant we secure the future of web3 and this work is done by my colleagues Kasper Beck and Alex okay so for this topic the impact of chain folks and Rigo organization I'm cross-trained Bridges we can divide this topic into several different terms first the impact of chain forks and reorganization on clustering Bridges so this is the topic we're going to discuss about this so first what is cross-train bridge I think nowadays there are so many different blockchains nowadays everyone has been using bridges for a while right so the bridge is Bridge our tokens our assets from one blockchain to another blockchain so here I'm going to describe a little bit about the underlying of the mechanism of the Cross stream Bridge so like when we are an ethereum mainnet and we want to cross train cross our asset like ethereum like ether to another chain we actually go through a constraint Bridge right after going after after going through a cross stream bridge then we got either on another chain this is the cross stream Bridge so what it actually does in the underlying is actually there's a contract at ethereum mainnet and there's another contract at another chain so there are actually two contracts or two two groups of contracts that are doing this first when we pass in when we say oh we want to bridge our ether from ethereum to another chain we're actually send in our ether to the custodian contracts and here we got our ether asset locked locked in this contract and we cannot get it back at this moment then there's a communicator it's sometimes an off chain but or a simply some programs that will read the events uh with a condition monetary condition and this ethereum chain and then it will interact with this another chain and with this debit issuer contracts these type of contracts and this type of contract will actually means some tokens for you so at this moment you will get something like a AC ethereum or 80 AC ether is a short name for another chain ethereum and it's actually not the real ether it's actually the the something more like a depth token or a recipient token it's like a receipt that you have it locked the ethereum in the liters in the ethereum chain so in that way we have assets we have token on another chain and we can use it like we have ether we have ethers on this another chain so this is how a cross stream Bridge actually works and when we when another actor who holds this debit token and wants to get back their get back from this another chain to the ethereum magnet and this is the time when uh they will go to this debate issuer this friendly UI and say that hey I want to get back my eaters then they can burn this debit debt token and then get back there either from the custodian custodian contracts so this is how the cross stream Bridge General what's the underlying concept the mechanism of clustering a typical cross stream Bridge so sometimes these Communicator work between these bridges are like of chain but but sometimes it can be like a like a network of nodes to do that in a more decentralized way something like that and we can also call it like Oracle notes it actually what it actually does is to um watching monitoring the events the conditions from a chain and to set the values set the values based on the observation from the soul chain to the destination chain so this is the core concept of the cross-string stuff I mean the typical one they are more and more advanced Bridges nowadays but this is just the typical one okay and it's also what we are going to discuss in this case study today so um there are actually many different Bridges so here with the um we divide it into uh there's a two axis and we divide them into separate them into different categories so first one um centralize what does that mean so for centralized Bridges it means that the communicator in the middle is really in a centralized design it's like a it's like a program holding a private key of the of the really important eoa or contract holding all the permission between the custodian contracts and also for the the depth token contract right so it's a more centralized design and when this centralized component got got uh going to travel or do something bad people are getting into trouble yeah so this centralized design and there's a trustless design so recently there are more and more ZK bridges that utilize DK proof so that this information passed by those communicators can be validated to be correct so we we don't we do not need to trust those communicators or Oracle nodes anymore we trust the ZK proof and we prove that it is correct before we can trust it so these are the trustless bridges so in another dimension we can look at the fast and standard design so for Center design what does that mean standard design there are um we can say it is a slower design it's slower usually when you bridge your tokens and you see that uh it's your way for like several hours or you should wait for like seven days it's a standard design is designed based on to wait for the finality of the of the states and different blockchains so that the result wouldn't be reversed something like that so it's a more secure design and we call this standard design here so it's usually store but we have more and more faster design nowadays and those advances is done by introducing the idea of liquidity pool liquid or Depot so for these those incredibly poor you can imagine that it's something more like having some stickers some liquidity provider to provide liquidity on both sides of the chain like for based on our example of for instance that user a can provide eaters and ethereum chain and provide AC either on another chain something like that so in that case whenever people want to bridge their token they don't have to wait for confirmation they just grab the those tokens from the liquidity pool and then they are good to go so these are the faster design yeah I would like to talk about more talk about the DK Bridge more it's actually um so for chain a and chain B for the one-way design is actually having the the communicator among it to monitor the block headers from The Source chain and that it creates a Decay proof to prove that the block header really exists in the source chain to chain B and embed those information to chain B so and that's verifiable so that people on chain B all the actors and the contracts on channel B can perform their stuff accordingly based on this Justice proof so this is the DK bridge for one-way synchronization and it could be two-way synchronization as well if both chains can be can embed their their black headers to the another chain two-way synchronization is also possible and when those um these kind of uh broadcaster embedment encounters the legal organization of the blockchain is also fine because they can to chase the different different chains black header so it could be also fine to do the tracks Forks it's also okay so that's for the ZK bridge and now I would like to go further uh to talk about the forks and Rigo organization uh the effect of it to those bridges I mentioned yeah so for folks uh let me tell tell you tell everybody more about the force so folks is like it's like uh yeah recent recently there's a really popular force that from ethereum folk from the pow proof of work to proof of sake that is well known by everyone right so this chain we can imagine that this train is from our original pow ethereum chain and then we go from proof of work into proof of s but some of the develop data wouldn't want to go through that fork they could remain on the proof of work chain and then they will continue to after that after this moment we will have two chains right so this is Fork it's like a parallel universe so for folks it's actually no impact for folks on the cross train Bridges as long as the because they are parallel universe right so there's nothing really being changed it's just become stuff from one point it becomes two parallel chain so it's the only thing important is that for bridges for them to choose the chain they want to be at choose the chain that people want to use so that it could be okay for folks they will there won't be performance uh impact and there won't be wouldn't be security impact but the problem exists when it comes to oh sorry so this is still four changes um now this is we are going to talk about reorganization the problem comes when it comes to reorganization so reorganization is also a kind of fork however it's more like changing the chain and disregard the original chain it happens a lot in the production system whenever there's a longer chain exists longer value chain exists the shorter chain is going to be replaced and eliminated so it's something like this this is the original chain and when this chain is found longer than the original chain the validators will go for this longer chain and this shoulder chain with conflict information will be eliminated and not used anymore so this will cause some problem that's for the so for the classic prop this is one of the classic attacks on the blockchain system with so-called that 51 attack and we also call it like a double spending attack imagine that when one when we like we have an attacker when an attacker deposit their fund to a centralized Exchange and then it is here the deposit the deposit transaction is here and the exchange accept that and then the attack to try to come up with a 51 attack on the computational power the having the better data to choose this chain when this happens this deposit event could be reverted and by but the the attacker has already deposited the fund into the centralized exchange and start to trade in and even withdraw some funds to the another chain so in that case if the chain stretch into this chain without the deposit transaction all the funds are gone the funds never deposit into the centralized exchange the founders are still in a wireless of the of the attacker and the attackers still holds the found that they attempt in the centralized exchange and run away so this is the classical 51 attack 51 attack of a double spending and it's actually possible uh you can see on this crypto 51 dot app to see how much computational power how much cost you should um you how much does it cost for you to rent the machine to have this kind of computational power to uh to to perform this kind of attack this is what what I just been talking about yeah so for this chain this 51 attack so one is here one is here nothing nothing unusual happens and here we we deposit the assets this is the attacker with a smiley face and then the attacker simultaneously conduct a 51 attack on champion then oh this this when this happened to bridge this is the bridge the bridge and a communicator will sink the information from this blockchain the source blockchain to the destination blockchain and it this is where the deposit happened this is what deposit happened but remember simultaneously this attacker also conducted a 51 attack so let's see what would happen the attacker on the destination chain conducted with withdrawal action Ultra operation and also insert this transaction into this block and when this block happens this this is longer than the original one right so when this is don't got an original one this deposit event this deposit translation and everything comes later disappear and the blockchain will go for this this path for this path so in this path there's nothing deposit but the resort is success which means the attacker can can get a get the phones without departing them so this is the attack so for the impact of reorganization is actually we divided into several different categories that they are centralized trusted and standard and fast right so for L1 to L1 the problem is more severe and for L1 to help two it's possible to do the stage reversion so it's better in that case it's possible to do that and so for the impact in regard to the performance so for fast bridge I saw for slow bridge is okay because it's already low and it's more secure for waiting longer time for all the confirmation number of confirmations and for the fast Bridge the problem is bigger because it is it doesn't really wait for a long time so it might have to dynamically adjust for the for the stage to do some State monitoring and stake reconciliation and for the security side since they since for the center Bridge they wait for longer if they wait for longer every time it could be fine but for the fast Bridge those state laws located provider are going to lose their money especially for L1 to L1 because there won't be State reversion there couldn't be they couldn't do state reversion for so for L1 to L1 this case is totally um is going to be under terrible situation and so for L1 to L2 it is still possible if we can avoid the funds from getting with soul to L1 L2 sites can still do the reversion and to keep the money back so here we provide a mitigation technique to do that so this technician at least mitigation is that so for the wasteful so for deposit event we encourage those L1 to L2 bridge if we want to do a faster faster fast style of the visual they have to have this hash result for the for the for their older deposits and then whenever we want to withdraw from the second from from they want to withdraw from destination chain to the source chain they will have to incorporate the deposit hash into the restore request so that the custodian contracts can check for that correctness of those results and when and this mitigation technique the core concept of it is that whenever the attack happens this hash wouldn't exist so it will conflict to the withdrawal request leading the withdrawal request to revert as well so this is a one of the really simple mitigation that for L1 to L2 Bridge can do yeah this is when when this chain is chain disappear and work for this train within success okay so after this medication mitigation this L1 to L2 Bridges is going to be safe but however L1 to L1 this because State reversion couldn't really apply so this mitigation is not for L1 to L1 Bridges just couldn't help so he has several few takeaways first uh currently they are growing design space of cloud stream Bridges more and more application more and more different principles have been applied to this area second one of the most exciting excitement of the advances are the trusted ZK Bridges and the impact of reorganization is larger than false and to the security are larger than performance we should keep in mind that reorganization is always going to be a huge issue for the traditional bridge design and the Securities is really need to take the Greek organization into consideration and the impact of reorganization is independent of decentralization no matter how decentralized the middleman I mean the the communicator in the middle is the impacts still exist this transition on that point doesn't help with the reorganization issue the fifth one the L1 L1 fast Bridge are no goal if you if you guys want to um deposit build a liquidity provider for L1 to L1 Bridges it could be dangerous so please be aware of that and finally we present the mitigation strategy to any l12l2 Bridges okay that's all for my presentation thanks for your attention [Applause] imagine talks thanks for performance uh so anyone has questions no okay no question okay all right so uh the guy is asking well will you share the link over the list slides and yes and we will do that after the event yeah so again thanks for coming for his great presentation [Applause] but