 I'm Nitin Epin. I'll be speaking about securing cross-chain communications. You'll be stuck with me because due to central actors, Columbia did not give visa to the guy who was supposed to come and present this, okay? I can't even imagine why they would cancel the visa. Imagine, you know, the business that was supposed to have been here, right? So, I'm not a technical person. I'm supposed to take a technical presentation. So, bear with me if I'm going wrong. I'll try to keep it as clear as possible. I'm on the phone with them. If there are questions at the end that I don't know the answer, I'll call them up. Those guys are very technical, okay? So, basically, even the last talk was about securing bridges and stuff like that, but let me try to make it... Why are we interested in bridges? What is making it so attractive? I think there are two things. As devs, you can see that there's zero raising 135 million, hash flow raising 25 million, no more raising 22 million. Now, from the hack side, Ronin Bridge lost 600 million last year, Womho losing 325, and Harmony Bridge as an example of losing 100 million, right? So, this is why it gathers attention. There's so much money involved. So, before I go deep into the talk, the idea is I'm going to explain just basic about the space, about bridges, cross-chain, why is it important, some of the examples out there, and then some of the hacks that happen and what caused those hacks, okay? That's the general idea of how the talk is going to go. Fundamentally, what is a blockchain? If there are people who know this out here, it's basically a ledger, and what does it store? It stores data and transactions. Data and transactions, as long as you can move them, they have value. And when they have value, there's a price, and there's an exchange, and there's a market cap. So, numbers are a little off. We are only at 950 billion today. But let's assume the market cap is at 1 trillion. We had 450 billion in Bitcoin, 200 billion in Ether, 50 billion in Binance, and the rest of them make the market cap. So basically, there's value across different chains, and it's fragmented. That's why cross-chain swaps or cross-chain bridges are important. So basically, blockchains are really disparate wall gardens, wall islands of value. So you have two islands. If you can't move the assets across these islands, you can't move value across them. Imagine traveling from US to UK, and you can't use your money over there. Kind of useless, right? There's a restaurant out there who's willing to take your money in, but you don't have pound with you. You just have dollars. So that's where you need something in between, like an ATM machine, banks, or credit card processing, something like that, to move these value from one island to the other. Fundamentally, that's what a cross-chain bridge is. You have some assets or valuable stuff on one blockchain. You want to move it to another blockchain. That's a bridge. When you're doing a swap, you're exchanging a token on one blockchain for a different token on another chain. So fragmented users and value to move across chain without friction. Now, think of it that you had to do this. Let's assume that you wanted to use a Solana. You had Solana with you, and you wanted to use Ethereum, and you had to go to Coinbase to sell your Solana to USD and then buy Ethereum and then bring it to your app. Imagine doing this when you're traveling. Imagine you've come to Bogota. A lot of you have come from other countries, right? Imagine going to the bank, changing money, instead of just using your credit card somewhere at your hotel or at the restaurant. DeFi is going to be very big. That's the assumption. Let's assume that all of you are assuming that with me. You're all going to replace trade via the traditional finance one day. If that is the case, this piece, cross-chain swaps, bridges, or cross-chain communication is going to be a very critical infrastructure. All right? So fundamentally, there are three things that are very important. You're moving between proprietary blockchains. Taking an example is moving Solana from an SLP standard to a Binance smart chain with a BEP-20. How about transferring assets between layer twos, between arbitram and optimism? If you want to do that today, imagine you have to take your arbitram, put it back to Ethereum. You have to wait seven days. Then you have to move it to optimism, right? That is the friction that we want to reduce with cross-chain swaps. So generally, there's an architecture for this. You are transferring information. It could be asset. It could be contract calls from one blockchain to the other. So on one side, you have a node that monitors the source chain or the original chain. We call them the validator. That transmits information from the source chain to the destination chain. In between, there are checks, and there are checks happening, you know, on requiring what is the consensus among the validators. And there is a signature. And eventually, the validator on the destination chain verifies the signature and issues in IOU. This is typically what that happens. Or the other way is you can send to a liquidity pool. You can use AMMs and do this process. So I'll now talk about the various types of bridges and the mechanisms out there. One is the proof of authority bridge, a POA bridge. You have a small set of actors that are listening to events on the source chain. They validate them and they relay this across to the destination chain. Incentivization and slashing mechanisms ensure the integrity of this thing. So the pros are that there are few validators. So it's very fast. You can easily do it. But the cons are now you've introduced trust on these few validators. There's a collusion possibility. Something very similar is a POS bridge or the proof of stake bridge. Now instead of one node, you're giving it to the person who has more number of tokens or the token balance. They do the verification and signature. What are the cons? The security depends on the price of these tokens. The next is a light client bridge. Example is a rainbow bridge. So a smart contract with an Ethereum light client functionality is deployed on near. And a smart contract with near light contract functionality is deployed on Ethereum. The verification is done by both chains, calculating the Merkel roots and verifying its headers. There's no need of a validator besides the miner for both the chains. The cons are it requires a high, it has a high implementation cost over there. It requires smart contract development to hold both the light clients on both the blockchains. So then there's an ultra light node with Oracle bridge adapters. It does not keep track of headers, but then it depends on oracles and relays. So then they can start colluding. That's also possible. The other option is we do chain bridges. Instead of validators, you have a chain out there. Now that's an elegant solution. When you take it, that's truly decentralized. There's a dedicated POS hub. Then you can't do middleware logic over there. So that's what people are trying to solve when it comes to chain bridges side chains. Again, you're connected to the main chain. All those moments happen quick, easy. But then when you want to do between other blockchains, it's not easy over there. Different kinds of bridges. There's one is a custodial bridge WBTC. WBTC is a bit go holds the custody of WBTC. The when you send BTC to get WBTC, BitGo is the custodian, a decentralized bridge or something like a wormhole. Unidirectional bridge. When you're doing WBTC, you can only send from Bitcoin to Ethereum. You can't send back on the same bridge. Wormhole or multi-chain, any swap, those were the multidirectional bridges. So fundamentally, the idea is when you're moving across these chains, there's a lock, mint and burn mechanism on how you move assets across chains. So let's assume you have to move N tokens, token Z from blockchain A to blockchain B. So what's happening is these validators, they're locking it on the source chain, on the contract on A, and they're minting a wrapped version of that on B. So eventually when it's replaced, it gets burned and it is released. The original tokens are released. The problems over here, there are problems also. It's not like it's so easy as it sounds. Okay. And the problems are, as Vitalik said, now you're dependent on the fact that nobody can change the chain on A. So even the previous speaker, she had a better graph for this, how what you put over there vanish, but the other side you got it. When you come back, your original stuff is not there. All right. So when you burn and come back, your original should be there to get any benefit out of these. We'll talk about some of the hacks that happened. All right. So the Polly hack was 2021. It was a $600 million hack. So what happened over there? The Polly hack or Polly, there was a master, you need a huge liquidity to do these things, right? That's what Polly had a large, there was a large TVL and there was a master wallet that contained these, what do you call, the assets. And it was based on smart contracts, large amounts for the large liquidity. The hack was possible because of the access rights through these ETH cross chain manager and ETH cross chain data. They got access because of the, you know, the bug over there. They got access. Somebody outside made their address as the owner and they just drained the funds. Wormhole hack. Here it was a little different. What happened? Again, this was this year, $325 million hack. A deprecated function was there. They updated the GitHub, but it didn't go into production by that time. The hacker knew that when they made that update, this is where the problem is. And there you go. Just use that, drain it out. It's basically, it's like you had at that point in the Wormhole case, you had issued, think of it, gold certificates. You're issuing gold certificates, hoping that there's gold under the vault. What if there's no more gold under the vault and people are coming back with those certificates? In the Wormhole case, you know, obviously that was compensated by jump crypto. This is just showing what really happened over there. The root cause was the signature was not checked. Okay. Another example is the Ronin hack. Again, 2022, $600 million hack. It's more realistically here. It was a Web 2 issue. So there are two kinds of security issues we can talk about. There's a Web 2 issue and there's a Web 3 issue. Smart contract hacks, that's a Web 3 issue. Now here, what happened was, they had kind of nine validators and four of them was with SkyMavis, the guys who developed the game. What happened? They had given the signature to the SkyMavis team a year ago, forgot to take that out. This is how, at least I read about the problem was, somebody working over there, they were given a job offer. Guy was very excited. I think they gave him three times what he was getting paid. They sent him a PDF to sign. You know, he clicked through the PDFs and the keys were gone. Now they have control of four of the nine validators and the DAO and boom, $600 million. Mostly in Ether was gone. So the funny thing here was, for close to a week, they did not even know that this was happening. At least most of the other ones, somebody trying to find it or knew about it. And here, the hackers, the funny thing was, they even shorted AXI and the wrong tokens. They got liquidated because it didn't go down. So, you know, but still money is gone. Nomad hack was something like a decision that they made. They gave up security for simplicity. Basically the light clients, they decided not to do that. When the update was done and new update was done, they could spoof transactions or fake them with drawing funds which are not theirs. And the Nomad hack was, the funny thing was, after sometime anybody could hack them. You could do it yourself. And there were the white hackers who helped to take around 36 million they received back. Total, I think, eventually the loss was 150 million. Initially it was 190, I think 36 came back. Here you go. The FAY hack, $80 million hack, that was a re-entrancy bug. Now these are all very, nowadays re-entrancy, like it's like four years ago, you didn't know about the re-entrancy or most people didn't know. But nowadays, you have to know what were the previous hacks. So knowing about these things helped. The Beanstalk hack, again, here it was flash loans were used to accumulate the governance protocol. And then once he got enough tokens, he just put a proposal saying that they're donating funds to the Ukraine in a war and took off with all the collateral. So I'm just explaining the different kinds of hacks here. So I don't know who put the statement out there. So if you're trying to create a bridge between n different cryptocurrencies, there's a goo guy, I think. The complexity of that is n squared. So which means there are n more chances. So there are way more bugs that can happen over here than where you started. So some of the things that we can look over here are coding practices, right? First thing, obviously, you should know the Web 2 security stuff like social engineering, phishing, running a malware, spyware, protecting your keys. Fundamental things. You can't assume that you're in Web 3, you're forgetting all the Web 2 stuff. Definitely have to do that. Then don't let a regular developer go and code a DeFi, you know, blockchain smart contract where you're hoping to get billions of, you know, dollars into that contract. Because that's really like, I've put the exam, it's like asking your house contractor, the bank is asking them to go build your vault over there, right? You need somebody specialized. So first you get somebody who's good at coding blockchain smart contracts and then you bring the security auditor. So there's a paradigm shift that's happening. Earlier we just had one code, it was on your server. Now this is distributed, it's going around everywhere. It's a total paradigm shift. So common set of problems you should know as a developer, you should know the common set of problems like re-entrancy, integer overflow. And again, when you're trying to do an update, you know that there's a problem and you're going to do an update on a GitHub. Before it goes into production, there's a small window. You should know that the hackers out there are also waiting to tamper on that. Some of the other things, you know, typos, you know, uninitialized implementation contracts like proxies. People have forgotten to do that and an attacker has come and taken that. Rounding errors, unsafe casting. Then there are smart wallet attacks. There's Merkel-proof mishandling. All these things could be prevented like if you're doing enough number of tests, whether it's unit functional, then formal verification, fuzzing, plenty of documentation. And then on top of that, you give it for audit. Those of you who are in the development space out here, I would seriously say consider an auditor job because most of the guys, the bridges I know, they are paying a ton of money to auditors. Despite having audit people on their team, they are running these contracts through multiple auditors. I hear right now it's $20,000 to $80,000 per week for a security audit engineer per week. So imagine there's a bridge out there or DeFi projects out there. They will need at least two months' work from at least two engineers. Very lucrative career, man. So think about it. All right. Can we stop hacks? It's like saying, can Microsoft, with all their money, can it stop going down? No, it's a hard task. There's going to be hacks. It's going to happen because projects are trying to scale speed. They're using speed to try to get users as quick as possible. So they're making decisions sometimes that it should have taken much longer. So now, but there's one thing though, the hacking of large amounts is easy maybe, but taking it out is not that easy because now you have chain analysis, elliptic and all those guys, they're hacking it. Exchanges are, you know, banning them. Tornado cash is being banned. So there are a lot of things that help you, but that doesn't mean that you should not take care of your code, okay? So keep in mind, in 2013, the exchanges were being hacked. It's just that right now it's the bridges because the surface area for them to attack is very, very large. That's the main thing. Main thing is how do you mitigate these things and what is your response once this happens? When you do the authentication part, you know, do your code well, then you do audits, run bug bounties. But always remember, if you lose money on your wallet or your smart contract, the auditor is going to lose nothing. He's just going to lose his reputation. End of the, it is your project. The project is not the auditor's. So you can try to compartmentalize, you can prevent contamination. What if it happens? How do you respond quick enough? There are multiple times where these white hackers have contacted the teams out there saying that something is happening to your contract and the support staff said, oh, nothing, we are fine. And all their money was gone. I don't have those tweets with me, but you can check it out. And your monitoring systems should be quick and you should have some kind of reporting guidelines once this happened. What are you going to do as a team? How are you going to protect yourself? How are you going to bring your chain down if you can? Is there some kind of kill switch? Because a lot of these things are centralized. So basically bridges have pros. You're bringing collateral cross-chain. You're getting scalability. You're bringing efficiency. The cons are you are introducing some form of trust. The trustless part is going away. So this space is going to grow mainly because of these things. So much money. Money has to move. And a lot of ways to attack these contracts. Both sides, developers, hackers, and VCs are going to invest in the space because just like, think of it in the real world, just like you have ATMs, banks, credit card, processing machines, bridges are a very big thing. I think that's it from my side. Questions? I guess everybody is being nice to me saying they think that, you know, if the guy doesn't know anything, so let's not complicate it. All right, there's somebody out there. I can try to answer some of the things, but if I can't, I'll tell you guys. I'll take your name. I'll contact the guys who've made the protocol and get back to you for sure. I was wondering if you have any recommended training resources for developers specifically focused on security, right? How do you take developers who don't know security and be confident that they do at the other end? Got it. I think the best is first learn smart contract or Solidity from, let's say, Patrick Collins is a YouTube video. He's a web app university is out there. And then Securium is a good place. They have a boot camp and they have a lot of tests, quizzes and stuff, which they go through all the possible problems that you can face. And there are multiple challenges out there. EtherNOT, there's EtherNOT. There are plenty like that. I forgot each of the names where I can get it out for you, okay? That's a start. Learn Solidity. Next thing is go to Securium and find out how they do. And that's, as I said, there are at least 10 jobs for every one security guy out there, especially in the Web 3 space. And it's remote. You can stay at your home. You can be on the beach. You can do it too. The perspective was pretty bleak when you talked about like end to end, like the end to end complexity of like bridging all kinds of bridges. But then we were here at the Ethereum DevCon and we know like the roll-ups are the way to scale. So we want to have actually a thousand of these L2s, right? So what is your perspective on that? How are we going to solve this issue? So initially for any technology, so how many exchanges are being hacked today? They're not, you know, you don't see Coinbase or Binance being hacked on a daily basis, right? But if it was 2013, literally every exchange was being hacked, right? Everybody. So same thing with DeFi or Bridges. It's new. When did Bridges come into being? It's pretty much only two years or one year and everybody, and you have multiple layer one blockchains out there, and you're trying to connect to these things. What are the number of years of experience to somebody who's coding this, right? Majority of it is one to two years. You don't have four years, six year people who, like when you, when you're building your NASA, you know, space shuttle or you're doing some C-sharp or C++ code, Java code, there are guys who have been doing it for 20 years who know the formal methods and stuff like that. So those problems will be solved. It's like the buggy and the car, okay? The car was initially was a bad technology, was slower than the horse, but technology improves. They fix those kinks. The wheels were flying off. You flatten the roads. You make better wheels. You make better shafts. All those will be fixed. So the future is not bleak. The future is really good. More money will come in. As devs, there's going to be plenty of opportunity. Now as the project owner, who's doing one of these, it's really dicey right now because you don't want to get hacked. I know the route of protocol guys. They're everyday scared. They keep their TVL low because once the TVL becomes high, you're a honeypot. Like everybody wants to attack you. If your TVL is low, you know that all the great hackers are not so interested in your TVL which is low. They're thinking of high capital efficiency by keeping the TVL low. That's how they are trying to do it. Hi. Can you hear me? Yeah, I can. Okay, great. So I was wondering on that scenario that you described that the developer, he got a contract, like a BDF contract with a virus. And took over his nine keys and therefore the bridge. Like Jesus Christ, that just made my palm sweat as you spoke about that. So I would like to understand a bit more about that case. Like he had the keys in his computer, just lying around there. How did the hacker extract that? It's there in the computer. It's not like he had it in his hand. It's there in the computer. You're giving access literally. So imagine you get these PDFs. Nowadays you can sign your PDF. It was a job offer, right? So somehow they knew that this was the guy so they could get into the system. They just have to get into the system because it's connected, right? A job offer came. Well, you know, they did interviews. They were formal interviews done. All those, it looked very legit. And then you get a PDF saying, and you got the call saying, hey, I'm sending you the job offer. You just click on it. Click the signs. You're not expecting it, right? So there it's not really your Web 2, Web 3, that's a problem. It's a Web 2 that has failed. So both have to be considered today. But do you feel like there's something he could have done to protect those keys better so like not keeping them on the computer, for example? Definitely. Definitely. They shouldn't have given it to a guy who had four validators with him. Guys, thank you so much. Time is up, so I'm getting down.