Building Crosschain Bridge across VMs

Transcript

on the blockchain security team at Coinbase. Um, specifically the protocol security team. Um, and um, I guess we have we've had a lot of blockchains since Bitcoin. Um, so far this data is something I pulled from Coin Gecko, but it has 275 blockchains being tracked currently on Coin Gecko. And of those, we have like 89 layer ones and we have more incoming. We have Temple, we have Monad, we have some that are probably still in stealth and all. And all these blockchains basically have like different ecosystem. They have like you know isolated um states which is not kind of public to other blockchains. Um because the way

blockchains are built the states are being isolated by default. Um and this brings up like some issues generally. We have like fragmented liquidity. We have like bad UX which is basically a feature of each blockchain being different. um wallets are not compatible across some blockchains which is also a feature of how the blockchains are designed and um here we also have the issue of like the TVL so here we can see Ethereum has about 62% TVL um Bitcoin and other things but this about 10 blockchains with the largest top 10 TVL but at the end of the day we have so many blockchains and each of them are promising you know something great something superb they are promising the

future of web 3 um but they all cannot work together and what's the solution for that? Um the solution is bridges basically. So uh today I'll be talking about bridges um and then a few um details about like the EVM and SVM. So the EVM is the virtual machine, the SVM is virtual machine and just a few bridge vulnerabilities and also talk a bit about the base bridge which is being built by Coinbase. So um basically what's a bridge? A bridge is a protocol that connects um different blockchains together. Um I mentioned earlier that each blockchain is isolated. So it's more like an island. And this vin diagram I have up

here just shows how um blockchains are intertwined. They're basically isolated. Um so bridges are how you can actually connect different blockchains um together. And um there are different bridge architectures. So here is like a um well I say framework of how I can visualize bridges. So we have your source chain your destination chain. We have a user on both ends and we have like an offchain component. So if a user wants to bridge using like a lock and mint branch the user initiates a transaction from the source chain and if they're sending it because we had like an ETH event. So here they lock their eight on the source chain through the

bridge contract which emits an event and makes the call to um the offchain component. The offchain component which is basically validators. They kind of like verify the transaction and um lock the ETH and then also make the call to the destination chain which authorizes the mint of um ETH or wrapped ETH on the destination chain which sends to the next address. And this is basically how um all lock and mint bridge work. And obviously through the redeem flow, it's kind of the same thing just in reverse.

So you burn your wrap it which makes a call to the offchain components which makes a call to your source chain contract and unlocks your ETH on your source chain. Um but this is just one of the architectures and I know that there are multiple um Ethereum is like an open source um will I say protocol and basically everyone can be build anything they want and we have multiple bridge architectures also and these are just few I picked. So we have like a lock and mint bridge and and born and mint and then lock and unlock. Um the main differences between these are what is native on where. So um for local and mint you have your native assets on the source chain and you just have like a

wrapped assets on the destination chain. For the burn and mint bridge you have like native assets on both chain. So for example if you have USDC um by circle USDC is native both on Ethereum and on Solana and on B. But you wonder okay how do you say is native? It's because it's being deployed by the same entity. So they have the same contract not just like a wrapped version on each of the individual chains. And for then the lock and unlock bridge it's basically um a bridge that functions due to like liquidity providers on both chains where you like lock your liquidity in a pool on one chain it unlocks liquidity on the other chain and we have examples for all of them here as well. Um, so yeah, a

little bit of blockchain VMs and I won't be going too technical into like blockchain VMs, but basically blockchain VMs or virtual machines are the execution environment for transactions which um interact with smart contracts. So anytime you send a transaction and that has to interact with the smart contracts, it's been executed by the blockchain VM. And um basically we have I I just have like a simple example here of sending USDC. So I know a bunch of security folks are here and they're ready to jump on like how many up codes we have in just a simple transfer transaction. But this is dominate down into like just a simple flow. So a user

is sending Alice and Bob. Alice sending USDC um to Bob. So Alice initiates the transaction and the transaction basically has a bunch of um things involved which is like a read um compute. We have the compute of the actual um deduction and addition of balances and then the right um up code as well. So that's kind of like an S lo um the compute and the S store. But of course in like the native ERC20 transaction flow we have like multiple s loads M loads um and adds and subtract up codes in between and then the state is being updated here. So that's like a simple um what I say flow or example of

how um transfers work um on VMs. But a a more um detailed um will I say information about VMs in this case is between the EVM and the SVM. And why I picked both is because um the base bridge being built by um Coinbase is a bridge between B and the Solan and Solana um which is basically these two VMs together. So major differences between the EVM and the SVM um is how transaction is processed. So um the EVM is a stack machine.

Transactions are processed sequentially um one after the other. Why Solena due to C level um basically offers um parallel processing of transactions if the same state is not being touched. So basically it's um examines the states that are being um touched at the beginning of the transaction and if the same states are not being um affected it can process those transactions in parallel and I guess um we have like a new L1 which is also pro promising like parallel um processing for EVM and um another thing here is the state model. So um on EVM blockchains we have like contracts they hold both their code and storage in the same address while

for Solana um which was much to my dismay when I started reviewing Solana contracts we have things that completely different so you have to assign a specific account for storage and handle those in a specific way that's uh adds another security layer over those and then um we have the gas fee model so Ethereum uses the single um fee markets while Solana has like local fe markets. Um but this offers like some trade-offs between both of them. The first thing is um if multiple users are trying to interact with the same program which touches like similar states then obviously fees spike quicker on the SVM um and on the EVM if somebody is hosting

like a large mint a large NFT mint um that could cause like a gas spike for the whole blockchain. Um, and these are constantly things that have been improved, you know, in one way or the other by new EIPs, new upgrades to each network, but that's how it works. And then for the smart contract languages, I know we have a lot of languages aside and Viper. Um, Filog is mentioning Sensei a a new compiler he was working on and we have like core solidity but it's all currently being compiled down to EVM byte code which is what um is being used by the EVM and um Solana compiles ROSS to SPF by code which is

kind of similar. So by codes are basically um the list of the up codes and like the transaction and how transactions actually being processed in this case. So it contains all the instructions which um are being used here. Um so here I'll be going into um a few bridge vulnerabilities which are kind of like things I just highlighted which are things I highlighted in this case here. Um so one of it is kind of like the re relay. Um yeah so on the relayer side um relay layers in this case are the offchain components. So you have like your two blockchains functioning. you have your source chain and your destination chain but um in between that the communication channel

if it's being compromised or for example it's down so we had like a cloudfare outage a few days ago we had an AWS outage um I think earlier this month or last month and if your bridge cannot function without that and there's no like decentralized signing um that can enable someone to like send or rather complete the message on the other side of the bridge you have your bridge basically down for some hours or some days and if possible like um it causes like loss of funds or some other risks. Um another thing here is RIO risk. So this is um something specifically complex to handle especially when handling like multiple chains. So time

to finality is a big thing. Um here I highlighted this too but we all know time to finality on Ethereum is like about like 12 seconds. B is about 13 to 15 minutes. Solana it's about 13 seconds. Um and we have like multiple audit chains. ZK chains take a little bit of more time depending on what or how they are validating and um posting their batches. But time to finality is a big risk. And if you have like rig happening in the blocks, then obviously you would have to wonder okay how do you handle um rig risks such that you don't finalize a transfer of like $1 million on your destination chain and then you

have the transaction riged on the other chain such that it never existed. And this is not exactly it. It's it's something that could just happen even through like it's not an a direct attack vector if Rio cannot be like triggered on the other chain but it could happen like a byproduct of you know some miscommunication or something wrong happening in between like each chains. Um and for example this is more prominent in like single sequencer chains. Um I know at a point when I started using the blockchain a bit um on Polygon I I I had some issues with like Rio and stuff depositing to centralized um centralized exchanges then and um I

guess that's got my first intro to okay how rigs could actually affect like real life usage. Um and then again another thing is like replay attacks. So the function of the offchain component in this case of the validators is to like sign a message verified. So on your source chain you kind of you you sent like 100 ETH um and then you are bridging that 100 to another chain in this case um let's say another L2 or another like um L1 and in after the message has been verified and signed by the validators someone broadcast the message to the destination chain and you mint your 100 ETH but if that mint is not being tracked the

signed message can just be replayed over and over again and I guess um you know companies like Open Zeppelin and other standardizations like standardized EIP kind of like help with this you know tracking your chain ID tracking nons um but if you're implementing something custom or on a chain that does not have like all these tools you have to like track um what messages have been signed have they been have they been used on the destination chain if you if using them failed how do you accurately track them such that they can be reused or the funds are completely stuck or how do you refund? So you have to handle that as well. Um so yeah I I think I did a

simple um slide here of how like you send the same signed message over and over again and that would continuously mint the same transaction in the same way. So yeah another thing which has been um kind of the bane of web 3 is offchain stuff. So here is private key compromise. Um you have the social vector, you have like committing your private key to GitHub directly, you have multiple things but basically anything that can compromise your private key is a big attack vector and which is why key security is kind of a big thing. Um you have to handle or you have to make sure your keys are not just you don't have

like a single signer for your bridge for example. So if if you have like some uh I don't know like some multisig where multiple people have to approve in different locations. So you are not you don't have like a physical vector to your decentralized bridge. So I guess like there's there have been some examples the running bridge was pretty bad um and then we've had other examples as well over the years but yeah that's for private keys um issues. Now some bridge vulnerabilities um on the smart contract level I won't be going too deep into this but we have basic stuff like re-entrancey so different bridge have different functionalities some bridges also enable like message passing where the bridge

can make a a call to like a contract on be on your behalf but if that enables like a call back then you obviously have like a re-entrance attack vector here you have like upgradeable tokens um so for tokens we have like multiple tokens such that like even the ER20 token standard is not being followed to the letter. Um, and when you have like upgradeable tokens, how do you handle the token balances of your bridges such that it doesn't just go to zero or like what exactly is your will I say backup plan or how do you remove liability the liability risk here for like upgradeable tokens for your protocol. And then we also have like malicious message calls whereby you could craft a message that

transfers the entire balance of the bridge to another um address. So some people handle this by you know white whitelisting um message calls or blacklisting some um function selectors so you do not allow like special function selectors to um be called through your bridge. Um and then we have um decimal inconsistencies. So I'll just give a brief intro on this before I go. Um we have the B Solana bridge which kind of like connects B and Solana together. Um we enable different things token transfers arbitrary message passing. So you could say you could make a call to a contract directly from Solana um from Solana to base. So you could basically call a deposit

transaction on a base contract from Solana and um we have like different security um will I say features which kind of like enables security. We have like validation of messages. Um we have a contract which kind of acts like the implementtor or your MSG. In this case, which does the execution calls for messages being passed from Solana um to B and that is going to be mapped to every Solana address um as it seed and then we can enable like multi-token deployment. Yeah.

So uh on the base to sol side um we also have like validator verifying deposits. We have um you have to wait for finalization of messages um to prevent like the rig attack vector which isn't really a thing for Solana to base since we have like a shorter time um and also we can have multiple um Solana tokens for one base token. This is because of the decimal inconsistency. So if we have rust security researchers here they know that on the Solana side the way decimals is being handled and your max UN's value is kind of different. We have the max of UN 64 in this case. So um UN64 to UN 256 is kind of like a big jump. Um so here we kind

of like enable like multiple um token deployments with different decimal values while ensuring that this the tokens can always be redeemed on the other chain that it came from. So yeah that's basically um the talk but generally you would want to secure a bridge to like multiple audits. Um most of us here know what security is I would assume. Um but yeah, if you become a builder, don't just assume that your bridge is secure cuz you've built like because you've like audited other contracts and stuff. And then end to end tests. Funny enough, um I've audited multiple protocols where they don't have a full test of the full flow from

transaction from like a first flow to the last flow. Even if it has to spam through like multiple transaction, you have to test that to see if there's no leakages. And this also involves like fuzzing and all. I've spoke to many amazing teams that have like different fuzzers, different state mutation testing and all. And um yeah, another thing is monitoring. So there have been a lot of talk about monitoring over the years. But monitoring is kind of a big thing. If you have any protocol including a bridge, monitor your funds, monitor your transaction flow, monitor anything you can monitor. The faster you catch it, the quicker you can react. And yeah, thank you