 Cool. Well, thank you guys all for coming. My name is Lane Haber. I'm one of the co-founders at Kinext where I will focus mostly on the core bridging protocol and I'm gonna give you guys a Talk about cross-chain security considerations for the DGEN and all of us and hopefully by the end of this talk You guys will be able to come away with some key questions to ask yourself about bridge security So first, why is bridge security important? Well, bridge security is more important than most systems because You can be subject to the risk of the bridge when you never even touched that. What do I mean by that? Well Polygon the polygon POS bridge the roll-up AMBs you will those bridges basically Work by locking up assets on one side and delivering you a minted version of those assets that represent a claim on the locked funds When everything is backed one-to-one This is works great because you can trade the assets on your destination domain freely And then whenever anybody wants to come back they can easily just unlock it. Unfortunately if your Bridge is attacked then what you effectively have are claims on something that don't exist anymore And you are subject to this contagion risk whenever you are using those assets So if you're on polygon and you with like purchased POS USDC with your credit card or you've exited to polygon from an exchange You have never used the bridge and you were still so Subject to this contagion risk that exists with the polygon bridge and the same thing applies to roll-ups as well Well really any default bridge So this is kind of just a visualization of the risk that we are as an industry are exposed to in just a small subset of default Bridges this these numbers may have changed you can see that they are in dollars But it's over it's close to four or five billion dollars that Of assets that are subject to this type of risk That's not those aren't the only bridges that are getting hacked are the default bridges You can see here that like bridges just keep getting hacked and just under 14 months We've lost like two and a half billion dollars And I'm sure that I will have to update this slide soon in the future And really like why our bridges so easy or like such an appealing target They're appealing targets because it's new technology like I think about this stuff every day And even for me the way that we are thinking about security or thinking about the best way to bridge between chains Changes all the time on top of that. It's also a honeypot. So because you block funds up You are become a really Attractive target to hackers and it's not just like the Custodied assets to create the minted assets are the only ones that could be locked on the bridge If you have a high latency bridge, you could also have assets to like that kind of represent more of a liquidity network If you're not the default bridge then you're probably going to want some type of AMM to switch into the asset that everybody really wants and That is that's just all a lot of money that is an appealing target And the other reason why these bridge hacks keep happening is because bridge technology is pretty complex Like you are building a system that is connecting a lot of heterogeneous domains So not only do you have to know everything about your system? But you have to know everything about the underlying domains that you're connecting because the code that you write will not run the same on Optimism or arbitra or polygon there are slight differences that will impact you because those slight differences that you may not understand fully Are going to be the ones that end up being your downfall So now we're going to talk about like the different types of bridges that exist and some of like just to give you guys a Easy mint model to evaluate all the bridges So first before we get into that You can't have all the nice things you're going to have to choose some as there's always trade-offs like in any other type of engineering Generally, it means that you can't have all four of these properties It's low latency meaning the transfers or message passing happens quickly It's generalizable meaning you can pass whatever Messages you'd like through the bridge. It's trust minimized meaning that you're not adding any additional trust assumptions or it's extensible meaning you can take the same implementation and Use it on many different domains You can also have there's missing triangle, but you can also have low latency trust minimized and extensible bridges Those are more like liquidity networks like atomic transfers would have that because you can't pass general data through you can only pass Fungible tokens cool So what types of bridges exist and where do they exist on this trade-off space? There's natively verified bridges and natively verified bridges are bridges where the domains underlying validators are the ones that are verifying these transactions This is something like like client bridges ZK bridges the Which are coming out now or like even the roll-up a and B's are a special for special case of this type of bridge They are very low latency you can pass whatever information you want through them and they are trust minimized However, they are not extensible and they're not extensible because generally these bridges depend really heavily on the underlying Consensus of the domains that they're connecting. So I would need a completely different I would need two different bridges if I were creating a project that would use like client bridges everywhere I would need two different implementations on Ethereum if I wanted to connect from Ethereum to Cosmos or Ethereum to Solana There's also externally verified bridges externally verified bridges have a third-party validator set that's verifying these bridge transactions This cut is low latency generalizable and extensible But now you do have to consider what happens with that third-party validator set the implications of like whether or not the bridge Validator set is going to be the lowest Trust point in your system really depends on like the validators of the domains that you're connecting So if you're connecting flip-flop chain through a very popular bridge to Ethereum your weakest about verifier sets probably gonna be on flip-flop chain Okay, cool. And then there's optimistically verified systems optimistically verified systems use fault-proofs to Enforce the validity and veracity of the messages that they're passing through One quirk about how you have to construct the fault-proofs for these types of systems is that you can only Prove that fraud happened on the home domain, which is where the message was sent from Generally, that's because all of most optimistic systems have some type of miracle route that they are verifying And you can only prove that your claim of fraud was valid if you know the contents that went into that miracle tree However on the destination domains you can't disconnect the The chain so they don't process any fraudulent messages These systems are trust minimized generalizable and extensible But obviously they have there have some latency because you have to run a fault-proof So I also want to talk briefly about ZK bridges just because they are coming out soon But they're not available yet ZK bridges are a type of Native bridge that you know uses a validity proof to ensure consensus One thing that you have to consider with any native bridge where it's just or any proof Where it's just asserting consensus is if there's a 51% attack on one of the domains that malicious information would Be treated as valid when it's crossing a bridge that verifies only consensus There's some really interesting work to validate both consensus and state transitions But it's in early days ultimately that's probably going to be the gold standard of bridges, but it's not ready for prime time yet So now we're going to talk about different types of security and where these bridges fair in those trade-offs So when we talk about security of these cross-domain systems, we're really talking about three different types of security Economic security, which is how much does it cost to like what what damage could have really well funded adversary do to your system Implementation is like how complex is it to build and reason about? And also implementation talks about your standard development practices like do you have good security hygiene? And then there is environmental security environmental security is basically how could you can think of bridges as an oracle of information from two different domains and if you think of them that way then you have to Ensure the quality of the information as it transfers from a low security domain to a high security domain So what I mean by that is like if flip-flop chain is you have a bridge is connecting flip-flop chain to ethereum And that bridge flip-flop chain is 51 percent attacked. How does your system handle passing that information that may be? malicious malicious So economic security, what's your price? How much does it cost to corrupt all of your validators? Basically the only great way to kind of constrain this risk is to have a permissionless and diverse validator set otherwise You everybody does have some sort of bribery price So natively verified bridges to kind of break them on their economic security. You have to corrupt the domains underlying validator set For externally verified systems. You have to corrupt their bridge validator set and again like Whether or not that's the weakest validator set depends a lot on the chains that you're connecting And then optimistically verified systems There's a few different ways you could corrupt the economic security of these systems The first is that you bribe all of the watchers which ideally this is a permissionless thing to join So if you can do that that would be really expensive and difficult to do and you wouldn't even really be able to dox all of them but also you could Sensor the destination domain or sensor the home domain so that it becomes impossible to actually submit a fraud proof or disconnect transaction So in terms of like where all these system ranks native is probably it's going to be the most secure for economic security followed by optimistic and external and again, this is largely dependent on the permissionlessness and diversity of about verifier set Okay, so implementation security how simple is it like your bridges already have a massive surface area because they're connecting like Dealing with a heterogeneous environment So those dependencies will trickle up and it's something that you have to deal with So the only way to really mitigate that that type of implementation risk is to constrain your surface area Which means you should probably talk to your theoretical physics friends They're really good at that but implementation security is not just how simple your system is It's also all about code hygiene all about development practices all about security mindset like do you? Buzz your test you have audits. What's your test coverage? Are your bug bounties live? Have you done war games? You can also constrain this implementation risk by building your systems defensively and what I mean by that is integrating things like rate limits So if you're a bridge and somebody's withdrawing $10, that's probably fine You can probably let that happen, but if somebody's withdrawing 90% of the value in your bridge in a single transaction Maybe you want to add some delays or some extra verification on that so that people can react appropriately So for natively verified bridges They are pretty complicated because you have to deal with the underlying consensus set and so you really need a unique bridge Implementation for each domain pair that you're connecting For externally verified systems It's really nice because you can take the exact same system and put it on pretty much any domain the complexity comes from The like off-chain coordination between the verifier set anytime that you have to have Coordination between multiple actors it becomes more complex with optimistic systems You don't need that off-chain coordination between all of the watchers and so that they really have an advantage in terms of implementation security So yeah optimistic wins here followed by external and then native bridges actually do the worst So now we're talking about environment security So again like bridges are oracles of information from one domain to another and you need to make sure that your system can vouch for the quality of that information You can constrain environment The really the best way to do that is to add off-chain checks like 51% attacks are really difficult to check on chain and You want to be able to add equivalency checks to and delays to your information so that you don't respond immediately to and data That could be malicious So natively verified systems these happen Synchronously as soon as like it passes consensus it could pass through the mechanisms of native natively verified bridges Which means that if there is a 51% attack you don't really have a strong defense against that For externally verified bridges It's really easy to insert these types of equivalency checks and these types of delays But it's not required by the model by default Whereas in optimistic bridges the delay is native like embedded in how the protocol works So these checks are kind of treated as a first-class citizen. So yeah optimistic bridges best here external and then native So But that doesn't really matter that much because that's not like where we're getting attacked the hacks that we see the bridge hacks that We see they're almost all at this implementation level. So in terms of attack difficulty It's requires way less resources to be able to Exploit the implementation of a bridge and like exploit the implementation risk if you're going to do an economic attack You're probably gonna need a lot of money and if you're doing an environmental attacks like corrupting the validators Well, you're going to need a lot of money and probably a lot of know-how as well And we're not seeing any of those types of attacks. Those are pretty rare What we're seeing all the time of these implementation keys the one the one exception being Ronin Ronin is like a multi-seg bridge where they have some number of signers have to verify all the transactions I would argue and Those keys got compromised the bridge got drained for hundreds of millions of dollars I would argue that that was again an implementation failure and guarding your keys more than an attack on the economic model of the bridge so if implementation security is like The most accessible thing for us to solve a lot of that comes from thinking simply but also from the decades of prior cybersecurity processes and research that we have why are we still having so many hacks and the Reality is like security doesn't exist in a vacuum all of the projects that are creating bridges right now are young and they are resource constrained and When you are creating a project of any type like hacks are a low probability high impact event And there are several other things that could kill your project So you are going to be forced into making different types of trade-offs so a lot of the trade-offs that people make when they actually ship bridges is to take some type of short cut and The most common shortcuts that you'll see are whitelist upgrade ability and centralization So if you're LP on a bridge, that's probably going to be gated behind a whitelist if you're an external validator Most rich of those. Oops. Sorry. I have those gated behind whitelist as well There's also upgrade ability. Upgrade ability is Controversial it's not clear whether it's better to have an opt-in or an opt-out system since you'll want an opt-out system to fix Emergency bugs, but you want an opt-in system to allow projects to kind of change their security risk at their own at their leisure But most of the time the upgrade systems that are in place on all of these bridges are just instant upgrade by an admin multi-sig Which obviously kind of undermines the entire security model that most teams advertise and quite frankly It's mostly a branding exercise And then you also have elements of centralization That means like possibility you have centralized supporting services. So in bridges actually Few are running your own node or Running your own node is just as important as like securing your keys And the reason for that is if you don't run your own node You could get malicious events and generally as you're an LP like most bridges function by watching for events on source chain Validating them and sending them out on destination chain And if you're you have are connected to a malicious node provider then that event is incorrect and you could have just sent them a lot of money So these are all things that Common shortcuts that bridge projects take because right now they're trying to de-risk their unknown unknowns Like is this even the best way to pass information? What are the RPC qualities like on the domains that I'm connecting to there's a lot of other things that go into creating a secure protocol So that means that there are some practical considerations that aren't the most tasteful that are important for you as a user when you're evaluating your security So the first one is this my life now which basically means you have to understand how long you're exposed to the risk of the bridge So if you are using it assets that came from a default bridge not even the default bridge itself You are still exposed to that bridge risk if you are using Or LP in on a bridge for either the AMM or just as a liquidity provider of some other type You really will be exposed to the risk of that bridge for the duration of the time that you are LP If you're a user and you're crossing a bridge and it's not the default bridge. So something like hop or connects You're only exposed to the risk while you're crossing Now the other one to check is like where your receipts? What have you done like the lindy effect is incredibly powerful in bridges, but it should reset Every time that there is an upgrade So you have to look at how long it take how long bridges have been securing a large amount of money And that's a really good proxy for how secure it is because if there's a lot of money there It's probably an appealing target and so people have probably tried to hack it and can't that being said Just because it's been around for a while doesn't mean there's not a bug in it. And then the other one this is like the most unfortunate to have to consider because it's kind of against the ethos of the space but Because bridge projects take these shortcuts. It is really important and are kind of running on training wheels It is really really important to know if you can trust the judgment of the team Do you know that they follow good development practices? Do you trust that if something went wrong? They would continue working on the project And if you're not capable of evaluating like the specific development processes and hygiene of the team Then you really do need to lean on social signaling for other people who would vouch for that who do have more knowledge It's kind of unfortunate that that that ends up being what we have to fall back on but Until these bridges are really standalone systems that just kind of is your best bet So now we have time for questions. We have about five minutes Thanks. Yeah, thank you. That's great. How do you how do you make your own considerations? So you're talking about getting some shortcuts regarding like the way Off likes security and speed like time to deploy time for time to production. How do you? How do you weigh those things that connects? How do you make the decision of save? centralizing some aspects for example Yeah, well, I can tell you exactly what our shortcut was so and our nxtp v0 That's kind of an atomic transfer system and how it works is you have a trans you run an auction process and then LPs can bid on facilitating your transfer users select the winning LP. That's great All of that needs to happen on a messaging server We use a centralized messaging server because figuring out how this would work in the wild and how it's like Kind of what our risk to a business was figuring out decentralized messaging was not high on that like decision matrix priority It just wasn't something that we would be able to focus on I think like as we've matured as a project. We've started to kind of realize that It is really important when you're not sure about the entire security of your system because you have no lindy It's really really important to make sure that there are some controls that you can enact like Pausing the system is incredibly important Especially as it increases in complexity and practically speaking in your team who like how was the how did you come about that decision? Did you involve everyone like was it like more strategic like for the centralized messaging? We asked some of the E2 folks if they would recommend live P2P and they said absolutely not and so you're like, okay So you talked about the dangers like how you lose your lindiness when you upgrade a bridge I'm curious if you have specific ideas about like the testing and Yeah, the testing procedures that you would have specific to upgrades to make sure that super strong I had super strong opinions about that personally. Yeah like you at the very Least you should set up a hard hat or forge project that forks the mainnet URL and runs a bunch of fuzzing and unit tests Against the upgrade that you've performed But I think beyond that like that's great You need to have a separate mainnet testbed contract environment where you can run these tests and then you need to Do some fire drills like red team blue team So we work with spear bit to do this kind of external attacks on our system And we'll get like if obviously if it's a real bug, you know, please don't do that to us on mainnet But we'll give them upgrade keys to kind of inject a bug and then we'll test our monitoring systems Like how quickly can we pause things if it went wrong? Like how quickly can we get our incident response team together because I think that if you have to figure those things out when It's under the gun. You're in a lot of trouble So we're gonna do our first one on our upcoming fork probably in the next few weeks here, but Um We'll give them like a two week time frame and say okay sometimes within this two week Get it and if I really wanted to be mean I'd be like do it while I'm asleep Which I probably will I was just curious would you recommend adding latency to increase security or it doesn't really Definitely, I think until you're able to prove the validity of state transitions and not just consensus Then your only way to mitigate like your risk of 51 percent attacks is to have latency in your system awesome, thanks guys