Bridges: how not to hack up everything with Alex Shevchenko
Ethereum Denver·Mon, Oct 9, 2023, 12:00 AM
Speaker
Besides collapsed crypto giants, like Luna/Terra, 3AC, Celsius, FTX, etc in 2022 there was another infamous trend - bridge hacks. Attackers drained a good butch of bridges and will probably continue doing it this year. But what if we all try not to hack up every bridge available or why don't we build bridges that are easier not to hack to keep your (attackers') funds SAFU Alex Shevchenko #BUIDL Mainstage
Transcript
[Music] foreign and hacking Bridges and a lot of the vulnerabilities we've seen beyond the crash of FTX and other projects we um we were talking earlier today and Alex actually has a PHD so you can refer to him by doctor and he also he also said that his first word in the crypto space was mathematics so he's gonna really build on the importance of math the importance of compute and one fun fact is also um I'm from the filecoin foundation but he also got a grant from near who is working with us um to really uh push forward the the work around Hocking Bridges um so we're just going to give a few minutes for technology to work on stage here and Alex where do you live Alex lives in Lisbon so if you are you know at East Lisbon or any conference in Lisbon you can find Alex there he can introduce you to his favorite restaurants in Lisbon one yeah there are some some good ones I think this has been happening for a while so Alex you want to just maybe kick it off without slides and then yeah absolutely absolutely sure um so hello everybody um my name is Alex I'm the CEO of rural labs this is the uh this is the company that is behind the development of the Aurora protocol um we're the dev Studio taking care of it so just just to check right because I'm expecting that you're pretty technical uh can I have audience here can you raise the hands the people who are actually coding something for the blockchain okay require a lot of quite a lot of you and also maybe you can someone who already knew about Aurora raise their hands okay one two okay not a lot but not a problem does anyone heard about the Rainbow Bridge though okay so more people know about Rainbow Bridge actually Rainbow Bridge is a pretty big bridge back in in May before the crash on the Rainbow Bridge there was like one and a half billion of liquid assets in stable coins so I'm not calculating other things okay it seems like things are working which is great um yeah so my talk today is Bridges how not to hack up everything yeah and the cool thing about Rainbow Bridge is that it has never been hacked right uh you have heard lots of Stories the more than uh more than 2 billion were lost in bridges hex during only the previous year right and I would like to share with you experience what does it mean to develop a bridge what does it mean to protect it and what are the things that you need to think of when you're building Bridge or actually any blockchain project I would start with a very short overview of Aurora what we are doing and why the bridge is also very important for us so Aurora is a solution that allows to execute ethereum smart contracts on top of near blockchain right so we bring the CVM compatibility on web3 compatibility to near which has an absolutely different virtual machine for the execution of the smart contracts the reason why near has this different machine virtual machine is because of the approach that near is taken for scalability and nears virtual machine is asynchronous right so cross-contract calls are asynchronous so in case you're doing a transaction that does multiple cross-contract calls and then at some point in time something fails there is no there is no automatic rollback of everything and developers need to think of this right so what we are doing there is that we are introducing a specific set of specific Primitives that are called Aurora that allow you to run your solidity smart contracts there will literally encode evm as a smart contract and we're putting it inside of the near right so we're spinning up an evm as a smart contract inside of the near execution environment this is probably the most complicated smart contract in the world right the whole freaking evm inside of it you can think of Aurora as a and as an L2 solution to ethereum because of the Rainbow Bridge because of its architecture we're going to touch base this a little bit later um and the difference for us is we are an L2 with a decentralized sequencer because our sequencer is the whole validator set of near and there are more than 400 nodes that are operating there um yeah and we have some additional things we're pretty focused on the user experience so uh we have some some Primitives that are helping developers create great products so for example one can do a smart one can do one can pay for the user transactions on the chain and the general users can onboard without any crypto we're literally just today launched a solution that that allows to do this and if you want to learn more about Aurora you can always go to aurora.dev there are a bunch of interesting stuff there but specifically today I would like to talk about Rainbow Bridge its design and why why it can resist the attacks so the way how Rainbow Bridge works is pretty much very different from almost anything that you know in the market it is a truly trustless and permissionless decentralized Bridge there is we do not have anything like validators of the bridge we don't have any third parties that are very fine transactions over the bridge except for two things consensuses of the ethereum and near Network if you're if you're moving assets or transacting any data in between two chains You by default trust to the consensus of these networks there is no other way right and there is nothing in between these two right other bridges are proof of authority Bridges they have a set of validators that are running in between them and because of this or like a multi-stick things like that and because of this I'm calling they proof of authority Bridges the closest technology to this one that we are using is IBC from the cosmos right so they are using a similar concept of the light clients that I work in so how does Rainbow Bridge work on near blockchain we do have a fully implemented ethereum light client that is capable of verifying block headers that are sent from the ethereum blockchain there is no restrictions on who is capable of sending these blocks and they adjust every 12 seconds sent to near blockchain on ethereum there is a near light client implemented as a solidity smart contract and here I would like to say hello to uh to people who are not including AdWords curve as a pre-compile in ethereum because it cost us a hell ton of money and held on of our just resources to implement the check of advert's curve crypto signatures inside of ethereum smart contract we actually had written a because adverse curve signatures are used in near protocol right so it's not signatures that are used in ethereum so it took us uh to imp to write a a program that generated the evm byte code that is verifying the signature because that is the most efficient way so we have not used there any solidity compilers or anything to do this and that smart contract is 1200 lines of codes generated by a program right and this is only for checking the signature it is super optimized if in any time you would like to Super you know validate it if you would like to validate an AdWords curve signature on ethereum just use this smart contract available in GitHub fully open source as all of the tech that I'm talking about today so we also have besides dislike clients that I accept in the the the headers we have the server the services that are actually sending these headers right and for ethereum we have no other way as sending headers every 12 seconds to near send in every second a header of near block and this is this is every I'm saying every second because New Year blocks are generated every second is going to be prohibitively expensive and it is going to clock the whole ethereum network so we are not able to do this instead what we're doing is we're sending sending the blocks every four hours right and moreover if near has 400 validators one check of advert's curve signature requires around 150 000 is gas gas so we are not able to pack all of the signatures in in into one single transaction it is again going to be prohibitably uh costly and we would not be able to fit it inside of one ethereum block so instead what we are doing is we are relying on an optimistic kind of trust in the block header and so it checks everything from the near consensus except for the signatures and in case some of the signatures is incorrect we have an opportunity for the Watchdog Services these are the services that uh just monitoring what is submitted to the bridge to check and challenge it this is how it works now on top of the light client now in case you have a block headers there then you're able to verify anything that is included in the light clients or in inside of the block headers and I'm talking here in case of ethereum specifically of three Miracle routes the Merkel rule of transactions the worker route of the state and the Miracle root of the logs or events that were emitted these three things State transactions transaction inclusion and also events these are all of the things that are verifiable by default inside of the Rainbow Bridge and now all of the developers are able to write their own as we call it connectors that can use the slide clients and actually validate that something is stored on the other blockchain or some event was produced on the other blockchain so how for example an erc20 connector is working there is a smart contract on ethereum that locks your C20 tokens it produces the event of the Locking of The erc20 Tokens The Bridge got synced according to the rules of the ethereum we need to wait for two and a half epochs to make sure that there is a finality and then on the near side we are able to validate this event that was emitted and thus means some tokens on ethereum side if we are talking about the transfer in the other direction then obviously the tokens are burned the event is produced on the near side and then it can be validated on the ethereum site now we also have a used Mev here because Watchdogs are sending the challenges and we are allowing Mev Bots to front-run them the reason for this is super simple Mev Bots are the most efficient tools to make sure that some transaction is executed on the blockchain so and we are fully dependent on the execution of the challenge transaction right and because of this mov here is our friend and we are actually using it in order to make sure that the the funds and any communication between near and ethereum is productive Rainbow Bridge because of its size because of the amount of money that are locked there even right now in the bear Market Rainbow Bridge has around 500 million in different tokens that are only in tokens I'm not talking about anything else right 500 million in tokens that are locked inside of it so it is a honey pot for all of the hackers and quite we are receiving quite a lot of and we're monitoring and we're seeing quite a lot of attempts of an attack on the Rainbow Bridge so for example last last year there were several and even this year not very far from now there were additional additional attacks so we know quite a lot about about the attacks here and how to resist them so I would like to share with you this this concept of of a security as a as a layered cake right I was explaining how we've built the Rainbow Bridge and there are some things of it that are embedded in the in the security approach that you need to take in case you're building blockchain applications and first of all I would like I would like you to fully understand that you need to start from the very beginning with the proper architecture of your solution right in case your your solution for bridging or for anything else is based for example on the output of an RPC then it is not a secure solution because rpcs are not blockchain RPC May Fail RPC may be corrupted and sending send you the wrong data the only thing that you are able to rely on is the data that is on chain is the data that is executed inside of the smart contracts obviously you may do mistakes in the smart contracts right so what to do with with this part right for this you need to kind of try to develop the most secured smart contracts right and for this you can start with the secured software development life cycle please use the the proper techniques to just develop a security focused applications there are some additional linters there are some additional checks there are quite a lot of tools that help you to catch bugs inside of your code automatically integrate the hell or all of them on top of this please make sure that your smart contracts are possible usually in the events of an attack you need to react extremely fast so there is a need for the automated systems that I'm monitoring what is happening on the chain in case something is wrong this system need to have an ability to pause the smart contract I'm not talking here about the upgrade ability it is up for you up to you to decide whether the contracts are upgradable or not but the possibility and an ability to interrupt the sequence of a hacker is an extremely important thing it should be in any blockchain smart contract by default do internal reviews in between the different teams that you have inside of your organization this is super important and please write the proper documentation for it because it is going to be needed not only for you but also for auditing companies that are going to audit your code deploy your contracts in a structured way you need to have an inventory management tool that is actually where you have the information about which keys are used for for different things right this is super important to keep it in place you need to do continuous training and inspection because not all of the you cannot automate everything with the monitoring systems on some of the cases people need to be able to respond you need to have an on-call schedules people who are easily contacted contactable and these people need to know what are they telephone numbers of the other people that they need to bring in in order to stop the attack you can introduce automated systems as I said to you and please think of nav as your friend in case you're willing to stop any any of the possible attacks and for sure the last line of defense is a bug Bounty program Aurora has paid out the second biggest bug bounty in the world 6 million to a person to a white hat hacker who submitted the uh debug Bounty for the Rainbow Bridge we paid out only 6 million for securing one and a half billion in of user assets this is worth doing it will be much worse in case the bridge was hacked and in case it is possible for your protocol do the insurance it is not viable for Bridges unfortunately because the coverage there will run no companies in the world who are providing the coverage for multiple billion businesses so so that's it's not working for for the Rainbow Bridge but it might work for your particular application and there are also some challenges that are connected specifically with the bridges and the proper architecture for the bridge as you can see is based on the light clients and the thing is that the light clients are are undergoing the forks so and that's the problem your it means that the bridges must be upgradable because if the bridge is not upgradable then it means that the users need to withdraw their funds before the hard Fork happened because after this the bridge is no longer online no longer works right so that's the only approach that we are able to to have and in case we're talking about and talking about the upgrades it means that somebody is is in the custody of the funds it means that the DLT license is required this is the biggest problem that I see for the bridges ecosystem right now and I do believe that we need to work as an as a blockchain vertical on embedding the light clients inside of the protocols and doing the upgrades that are or the hard Forks that are connected with the upgrading of these clients with this um that's that's all my kind of insights for you on the security side and on the bridges side keep safe build good products and don't forget about the Securities especially in the blockchain vertical and let's finally move to the mass adoption thank you very much [Music]
Automatic transcript — names and jargon may be misspelled.