👾 Multichain is here: building for a secure, capital-efficient cross-chain future
How can we build a sustainable, scalable, fast and safe bridge? How should we avoid all these ridiculously large bridge exploits? Why do developers pay too much attention to Web 3 and have to deal with Web 2?
All these questions were discussed during the panel discussion at the Cross-chain Builder’s Meetup in Paris, hosted by Cyber Academy.
Speakers: Alex Sminov (deBridge), Alex Shevchenko (Aurora), Kirill Fedoseev (Blockscout, Gnosis Chain), Steven Walbroehl (Halborn), Igor Iganberdiev.
Moderated by Jonnie Emsley.
Alex Sminov: most of the bridges have a lot of liquidity, but the utilization of this liquidity is just one or two percent, and you cannot predict what amount of liquidity you’ll need. That is why I strongly believe in the concept of bridges compossibility with our protocol. Bridges might be free of any kind of TVL or liquidity pools. But they will rather source resource from other protocols and DeFi primitives when it is really needed. And do some kind of revenue sharing with those protocols. It will help to maximize capital efficiency. That is why bridges that in a long run are focused on bringing TVL will not survive because their economies are not that sustainable.
Jonnie Emsley: there is an elephant in the room, and I am talking about the security side. What are the biggest challenges with the bridges?
Steven Walbroehl: the biggest challenge (well besides making bridges secured) is trying to keep it decentralized. It is a lot easier to manage one chain on another chain and write into one database — this creates a totally centralized bridge. So you create a place where you store all the value and this becomes a clear goal for hackers obviously to steal this value. So the biggest challenge is to secure the bridge, keep it working, keeping capital efficiency on there, keeping track of ledgers and cross chain functionality and of course trying to do this in decentralized way. If you can combine all of that into one solution — you can solve a lot of challenges there.
Igor Igamberdiev: we could go slightly deeper, for example, for now we have a lot of heterogeneous chains, we have a lot of EVM-compatible chains etc. It is simply hard to find just one scalable way to communicate between them. We already have some solutions like Tendermint for Cosmos, or Substrate of Polkadot or even a new nomad thing for EVM-chains. I think we need to look at this direction. And also we need more light clients. I see now that the main solution was presented by Aurora. They build the Rainbow bridge between Near and Ethereum. If there are optimistic rollups we can find even more ways to do this more efficient. Optimism and Arbitrum coworking on solution for Ethereum. I think together in collaboration we can create more opportunities for secure bridges.
Alex Shevchenko: I can add that there is some solution that would be great for everybody. I am talking a bout zk light clients. In case there is an ability to create zk light client for a protocol it should be created. And second is that it should be used on any other chain. And this bridge with zk light client should become de facto the standard bridge for everyone. Slowly, but surely we are moving as an industry to this direction and everyone who is working on zk light clients are on the edge of the technology. Second thing I want to add here is in case if there is a technology in which we are unable to create zk light client this means that this protocol is shit. If you can not zk staff it probably means that you can not build staff and this is not a proper blockchain.
Steven Walbroehl: Yes, but talking about the interoperability it basically means that things are operating together and this means that teams also should work together to find the best solution. While some guys can build something sustainable and secure, others could bring speed and scalability. I think at the end we will find out something that everybody finally will come to consensus with.
Jonnie Emsley: There are some technical debates like will Solana kill Ethereum or something like that. We have seen a lot of these recently. But talking about bridges how secured they really are, and how can they unite such different systems is there any threat to the security in that?
Kirill Fedoseev: The main problem is that majority of currently existing bridges are based on this kind of approach of having some sort of multisig of validators and this approach has already proven itself as not very secure. And we have seen these large hacks in bridges in the recent months and years. There is something that should be addressed somehow. The solution is the research towards the bridges that are based on the light clients, — direct ones, optimistic, zk, whatever. And the second problem is that bridges security is dependent on web2 security. Most of the hacks are related with some compromised private keys, hosting. Everyone is so focused on web3 and spend a lot of money on smart contract audits, but they forget about the basic security considerations that are coming from the web2 world.
Steven Walbroehl: Let’s remember the Ronin hack of the Axie Infinitiy blockchain game. It is built on Ethereum. But Ethereum is too slow and imagine plain RPG, you will be stuck in the textures with all the confirmations. You can not actually play a game inside the Ethereum. So you need the side chain to do it faster. But faster doesn’t mean more secure. We should solve this interoperability trouble and make all the solutions work in harmony.
Alex Sminov: The main problem is that everyone is trying to build their own bridge. I have two advices here. The rule number one for me is never build your own cryptography if you can use a good solution. Probably, you will not create something unique so better use existing tools and try to improve them. Rule number two: never build your own bridge, unless you are fully focused, dedicated to specific things. Building bridges is not easy at all. And many teams are thinking that they will build their own rollup, layer2 or even own blockchain, and then they decide to build a bridge as it is «just a multisig». But actually bridge is a way more than just a multisig. I was really surprised to see such a huge ecosystem with hundreds of millions of dollars locked, been hacked in a such easy way. Like two out of four signatures were got through the phishing attacks and some infected PDF. That is not definitely how bridges should work and how they should be built. Bridges have to rely on underlying blockchains in terms of security. Every bridge system should have an isolated security model of the supported blockchain ecosystem. We have seen huge bounties recently. Like Saurik (Jay Freeman) got $2 millions from Optimism for preventing attack by minting Arbitry asset in Optimism chain. Someone could withdraw all the TVL. It is still a problem because 95% of bridges do not have isolated security model. In deBridge we were thinking about the security even before we started to build a protocol itself. For example validation of the state consistency. Validators always check the balance sheet and know how many tokens are staked. And they compare the state of smart contrast with the state of deBridge node and if there is any deviation they immediately stop the protocol validation. If Wormhole had this type of isolated security they would not lose $325 million.
Alex Shevchenko: From my point of view, security is just way bigger than just designing your product and trying to implement this or doing endless audits. Security is potentially about insurance for your protocol (you can not measure risks that you do not know) and bug bounty products. Every hacker wants to share on the cocktail party how they hacked large protocols but if they are not white hackers they can’t. But bounty should be reasonable. Like some exchanges have bounty about $10K which is ridiculous.
Igor Igamberdiev: I really like that we see now a lot of new projects like Nomad and others. deBridge are doing great thing for example. I think EVM chain are great because it is easier to connect something with similar architecture. We need to start with something we already know and after this try to work with all this heterogeneous blockchain world.
