Cross-chain interoperability – The next wave for DeFi and NFTs

ETHCC 5 · July 2022 · 26:50

Alex Smirnov examines fragmentation across blockchain ecosystems and shortcomings of existing connections. The speaker discusses cross-chain protocols that could connect applications, exchange commands and support new forms of composability.

Speakers

Topics

From ETHCC 5, hosted by Ethereum France.

Transcript

I'm CEO and co-founder at Debridge and today we're going to talk about crosschain interoperability and why it can be the next wave for DeFi and NFTTS. Like everyone is discussing that we like the future is multi-chain but in fact we are already living in a crosschain world right with more than 50 blockchain publicly available and user users would like to have a capital efficient way to move liquidity across all these different chains. protocols would like to have the way to move data or perform a cross-chain uh calls between smart contracts and there is a clear need for

solution for the crosschain interoperability and um if we take a look into the kind of landscape of existing blockchain ecosystem there are many EVM chains there are rollups and there are many ways to kind of interconnect Ethereum and the rollup through native rollup bridges But the main constraint is that there is no way to build like the bridge that supports automatically incompatible blockchain ecosystems. There is no solution that allows to move freely assets and data between let's say nonm ecosystem such as Solana and some roll up or layer 2 solution like optimism.

And uh liquidity is another big challenge because right now we have around $100 billion of liquidity fragmented across more than 50 blockchains and there is a clear need for crosschain infrastructure to maximize the capital efficiency of various applications and the lack of unified standard for crosschain intercommunication leads to the set of problems mainly fragmentation problems. For example, we have a fragmentation of technologies when many teams and people are working on solving the same problems or building the same solutions just in a different blockchain ecosystems. So for example, many teams are just like

implementing some forks of unis swap or curve. Many teams like implementing the same lending protocols across various blockchain. So instead of innovating, we're just like fragmentating resources on building the same solutions. So if we have like the true interoperability we we may we may build the composible application and composibility is one of the most powerful concepts of defi and we saw many examples actually of composible application. So for example a and maker when maker da can directly mint d token into a to have a fixed interest rate on loans in d token or USD coin and mango

like USD the algorithmic stable coin on Solana ecosystem which opens delta neutral positions on perpetual markets to maintain its pack and u have some additional revenue flow from the delta neutral position. ition. But the main problem is that we've seen all these great examples of composibility only built within one specific blockchain ecosystem, right? So for example like convex and curve is a great example as well or like one incantis. But we have not seen any kind of money legos that are built on a crosschain scale yet. And just imagine if we have an interperability layer, we can combine protocols and smart contracts across different chains. So

for example, we can have an algorithmic stable coin protocol in Ethereum like tracks that can interact with various perpetual markets either on Solana or in arbitrum or like starkware and pick the best one and that kind of design will pro will help to maximize the efficiency of the solution because you always open position like protocol opens position on the perpetual market where the funding rate is the best or just imagine if like our protocol on Ethereum could interact with mango markets on Solana, right? And that would allow us to build way more capital efficient solutions and like interconnect protocols and smart contracts across various blockchain ecosystems and uh we like within Dbridge

team we are building solution debris infrastructure that's the secure interoperability layer for web 3. So debris protocol consists of two layers. There is a protocol layer which is represented by the smart contract deployed in every supported blockchain and there is an infrastructure layer. So infrastructure layer is basically represented by validators that are elected by debridge that work for the brbridge governance. The point is that there is no way to build the bridge that will support data flows across many chains without the validation layer. We may see different bridges that implement like full client or like light light client but mainly all these bridges only

support interconnection between like ba base layer layer one and layer two. But what we are building in Debach is the infrastructure that helps to interconnect all blockchain ecosystems because just imagine if we have like truly decentralized and secure infrastructure then theoretically all the blockchains are becoming layer two to each other right because like protocols can scale up to different chains smart contracts can intercommunicate with each other and that's kind of crosschain future we believe in. So yeah, the design of de bridge protocol consists of two layers and any interaction or any crosschain message which is transferred um is initiated by calling like send method of debris protocol smart contract

and whenever the transaction is confirmed the bridge validators sign the transaction sign unique identifier of transaction with their private key and store signature into IPFS so that anyone who has signatures from validators can execute this transaction on the destination chain. So I truly believe that there is no need to build like own blockchain for bridging or for interperability because like the throughput of the blockchain will not be bigger than like throughput of all the support blockchains. That's why in Dbridge we have this kind of off-chain validation because like anyone who has signature can execute transaction on the destination chain and that allows also to have like unlimited throughput because since the signing of transaction

happens offchain validators can sign any arbitrary amount per second like depending on the hardware but like way bigger than throughput of all supported blockchains and uh yeah and there is no multiix by this design. So we have a smart contract that just cross validates signatures of validators and executes message or delivers message if at least twothird of signatures are valid. And uh you may ask like why validators like why validators are secure? Why validators don't collude in this case? uh validators don't collude because there is slashing mechanism delegated staking and slashing when any arbitrary user or protocol can delegate liquidity for validator to participate in the protocol

revenue sharing and uh if validators decide to validate some fake transaction or censorship some transaction they're getting slashed and that allows to have some kind of closed loop economy when validators actually bear financial responsibility for their service. Um, so yeah, our protocol is live. We launched in the middle of February. Thus far, we processed more than and delivered more than 100,000 crosschain messages or crosschain transactions from more than 55,000 unique users. And the protocol is life across seven EVM chains. So you can actually leverage debris infrastructure to build any arbitrary uh crosschain applications and primitives. So the main

problem is like what is really needed for a true crosschain interoperability because historically all the bridges that we saw were mainly focused on a crosschain swaps or crosschain value transfers and the general model is like users lock asset in one blockchain and then receive the vert representation of this asset in another. And the problem of this type of bridges are that the bridging protocols have to run liquidity mining campaigns and lock a lot of TVL within the protocol. But whenever bridging protocol has TVL, it starts to compete with liquidity giants such as a frogs or compound. And that's not the competition that bridge is going to win

because you never know when there is a demand on liquidity. You may have like a billion dollars of liquidity in the protocol and pay like 18% of APY on the amount of liquidity locked but the actual utilization of liquidity will be like 2% or so. That's why I truly believe that like all the bridges that have this kind of TVL model will eventually have to pivot either toward the generic messaging protocol or we'll have to leverage messaging capabilities of like other uh protocols and uh yeah so it's not enough to kind of deliver liquidity across chain and the only way to do that efficiently is to pass

liquidity as as a message because like whenever there is a crosschain transfer there is a request to transfer liquidity from chain A and chain B and somebody should settle this order in chain B and like 95% of all existing bridging technologies they're using their own liquidity pools to to settle this liquidity and in bridge we're taking a different approach we're like a big advocates of compatibility and we believe that like synergies and integrations with other protocols can help us to maximize the capital efficiency so instead of bringing our own TVL We rather trying to integrate like a liquidity protocol such as a for example our introduced like portals and their v3 of the protocol in order to borrow

liquidity from the credit line to settle these crosschain orders and at the same time we help like liquidity protocols to monetize their liquidity and share the rewards from like bridging fees with those protocols and that design is way more efficient because like we don't need to have any TVL we just source liquidity from like partner partner partner protocols when it's really needed because liquidity for bridges liquidity is needed only during the very short time span when there is a transfer and there is no any kind of sense to lock liquidity during like all all the other time and yeah so in addition to value transfers of course we we need to have the message transfer but the

problem is like how do receiver knows who was the sender of the message because let's say when we use telegram we receive the message from someone we we know like whether the sender is trusted or not. The same design should be implemented for like interoperability layer. When there is some messages being passed between protocols let's say in Ethereum and Salana the program on Solana should know whether the address and chain ID uh of the sender is trusted or not. And um yeah that's what like every interpretability protocol should have and another very important aspect is the execution of transaction because any crosschain interaction consists of

two transactions right so there is the one the transaction that is initiated in the original blockchain and then there is a transaction that is executed on the destination chain and for in order to execute transaction you need to pay gas or you need to make your users users of your dabs to switch wallets switch networks and like claim transaction manually. That's why there should be someone who will trigger the transaction on the destination chain and I believe in the cryptoeconomical design of the interperability layer. So for example when user or like sender can specify the small fee we call it execution fee to incentivize anyone to complete transaction on the destination chain and for example keepers or bot can complete

transaction and if this execution fee exceeds the gas cost then all the bots or keepers get the incentive right and they compete for executing for execution of the transaction. So my bet that like in the very near future we'll see that most of the transactions on chain will be executed by bots because for users it doesn't really matter like what blockchain you interact with. when we use web two solutions for websites we never think like whether there is there is an Amazon web services or like hesner as a hosting and we don't need to switch between those like all the traffic is routed automatically and that's the level of user experience that we are

trying to achieve in uh web 3 when users don't need to think about wallets think about networks they just initiate transaction in any blockchain where they have wallet or asset and then transaction automatically executed on other chains by keepers or bot and user may not even like sign transaction but just sign some like uh signature some message right and then like smart contract keepers will execute that message through some smart contract so yeah that that's quite interesting so I think that in near future all users will just interact with DAPs without thinking about blockchains and wallets so bridges itself will be some kind of TCP IP layer so that users will not even need to know

about their existence and uh yes so that that's exactly what we are building actually especially in regards to like the security and the user experience. So any developer or any project can pass arbitrary messages and value simultaneously across various blockchains. And if you build crosschain application or crosschain interaction, the only thing you need to do is to create the sending smart contract in the chain A, let's say Ethereum and the receiving smart contract that will be on chain B, for example, Salana, right? And your smart contract interacts with the smart contract like the bridge of the de bridge protocol or some other

interperability layer. Then the infrastructure confirms or validates the transaction and it gets automatically executed on the destination chain and that allows to have like to build money legos on a crosschain scale when you can inter interconnect any arbitrary smart contract on any arbitrary chains. And u let's dive a bit deeper in the concept of the transaction bundling. That's a bit technical but very important because like one of the most important aspects is the is being able to execute arbitrary complex crosschain interaction in a single transaction. And the point is that if you transfer

message there is a way to encode the set of transaction calls in this message. So for example, you don't want to only do a crosschain swap, but you want to do a swap of some method and then you want to provide the resulting liquidity into the protocol such as a or maybe you want to transfer liquidity across chain and then to open position on perpetual markets in the same transaction. In this case, you may you'll most likely use the transaction bundling feature and um the transaction bundling became possible through integrating like debr smart contract with agnosis multisand library because if you've used the safe app, there is the function which is called transaction builder. It's based on the

multisand library which was developed by team and which is quite unique where you can pack set of transaction calls in a single transaction. So you don't need to make like signers of the multisk to sign every transaction calls separately and yeah this is actually powerful library and we've integrated that. So the idea that the message which has been transferred across chains can encode the set of transaction calls. So it can be as I mentioned like swap plus provision of liquidity into some protocol or swap plus interaction with another smart contract on another chain. So any arbitrary any arbitrary interaction and yeah as soon as transaction is confirmed it's it's executed on the chain B so debris gate like claimers or keepers or

user itself just claims the transaction and then through the call proxy call proxy smart contract sequentially executes all the transaction calls which are encoded into the message which has been sent and uh D apps. So um probably the next bull cycle will be will be actually driven by the crosschain application and we call DPS the application that are built on top of uh debris generic messaging protocol. So one of the most obvious application is the crosschain swap and we have this solution which is called D swap which allows to perform swaps between arbitrary liquid assets. So if the asset

is liquid, if there is a liquidity pool that then it can be swapped and that became possible through our integration with one inch and with liquidity aggregators. So we source liquidity and roing algorithms from one in basically interconnect one in rotors in different chains by passing messages messages between those. So, and that allows to swap from any arbitrary liquid token to any arbitrary liquid token and crosschain the asset is routed through one of the intermediary the crosschain swap is rotated through one of the intermediary assets that can be USDC or that can be like some of the assets let's say stable coin borrowed from a or

the asset which is like settled by the market maker who fulfilled the crosschain value transfer. So yeah, D swap is life. That's the application that can be used not only by users but also by protocols. So basically protocols can manage manage the their treasury or like swap liquidity across different chains. Another interesting application crosschain application would be multi-chain governance because we have many protocols deployed on Ethereum right but like the one of the problem is the gas cost. Not too many users are active or are participating in the governance voting due to the high transaction fees. And instead of launching the governance on Ethereum,

you can simultaneously launch governance voting on different chains. Let's say avalanche and arbitrum or maybe even nonm compatible chains. And once the voting period is over, the result is sent as a message to Ethereum and then settled by the smart contract on Ethereum and apply to the entire protocol. Um, and yeah, that would be interesting to see how the multi-chain governance will evolve because like the cheaper the governance voting will be, the more the better participation from the token holders. We'll see. Another application would be the crosschain lending when let's say you provided the asset or liquidity to a protocol on

Ethereum and at the same transaction you can draw a credit or take a loan uh from a on polygon or you can just like directly transfer your position let's say $10,000 from Ethereum to a protocol on Avalanche and uh crossing yell farm yeah the That's another use case. So we all know in y finance when you supply liquidity in a form of let's say USDC to yarn and then yarn automatically balances liquidity across different strategies. So we can have like cross-chain yield farming when you supply USDC and then the smart contract automatically balances this liquidity

cross strategies in different chains and um like balances each strategy according to the best API. Uh NFTs of course like gaming gamify and NFT industry is evolving fast and I think that NFT might be maybe one of the main upboarding funnel for like next billion users into DeFi and we saw many great examples like stapon where even my parents started to work to work with NFT sneakers which was quite surprising. So um yeah and NFTs is the interesting the interesting industry right and uh there is a clear need to be able to bridge NFTs across different chains for example to make them interoperable between

metaverses when let's say you can bridge your cryptank from Ethereum blockchain to Salana metaverse like Star Atlas and you have your cryptank as an Avatar or you can just like sell some of the game assets directly from the game itself. and it will be sold on open C in a different chains or maybe at magic addon in Salana. Um and crosschain paradigm it it's the interesting concept because like normally all the protocols and projects were trying to tap into user base of other blockchain ecosystems by just deploying or forking themselves deploying the smart contract and that worked really well for a when a like is

a good example it started from one chain Ethereum and now a exists across seven different blockchains but if you're building your own protocol now in 95% of the cases you don't want to be deployed in all the chains that works for AVA and that works for projects and protocol that that represent like foundational layer of D5 such as DEX or like lending protocol or uh router because we we got to have those in every blockchain because those are protocols where we need to have synchronous composibility but in 95% of all other cases you don't need to have synchronous composibility and I really believe that projects and protocols that are deploying should

follow the application ccentric approach. When you just pick one blockchain which suits your needs in the best way and then through interperability layer you become accessible to all the protocols and users from other blockchains. So yeah, you can pick a blockchain depend depending on your specific needs, but mainly that can be like transaction fees or security or throughput or maybe you need to pick blockchain where you would like to have a synchronous compatibility with some specific protocol. So yeah, this is basically the scheme of how you can be of how how any protocol can go crosschain. You just choose one blockchain and this blockchain you have a synchronous compatibility with other

protocols as well as with users like EOA addresses and then through interoperability layer your protocol becomes accessible to all the protocols and users across all the other chains that are supported by interoperability layer and you don't need to deploy there. you don't need to fragment your own liquidity because your liquidity and state of your smart contract is concentrated and located in the chain where like your smart contract is deployed. So yeah, there are many ways there are many reasons why you should know or explore the crosschain applications to first of all to maximize capital efficiency secondly to enable global accessibility for protocols and

for DAPs so that users can interact with those from many chains and yeah this is example that we had with like integrating a when you can do a crosschain swap from one chain to another let's say BNB and you can swap directly from the from any of your asset to the asset which is supported by a protocol and at the same transaction supply resulting liquidity into a. So this is like how the roing looks like BNB swapped into USDC on avalanche and staked or supplied into a in the same transaction.

Um and yeah this is implemented through transaction bundling. And the very last concept that I I would like to touch really quickly the way the projects can transfer their asset because sometimes you want to have like additional utility for your token and instead of relying on one specific bridge and varying risks of the bridge, you can deploy your own token like anonical smart contract address in another chain and then enable like leverage generic messaging protocols by allocating specific limits on the minting rights of every bridge and that allows to be like bridge agnostic and diversify uh risk risks of the bridges. Um so yeah that's about it and uh feel free to reach out to me if

you have any ideas or any crosschain needs. Thank you for your attention. Yeah, that's a great question actually.

And there is a fallback mechanism. So if the transaction failed on the destination chain, all the liquidity will be transferred to the fallback address. And if you're building some crosschain app, you got to also design the fallback mechanism. So for example you can actually you can fine-tune the execution flow and in debris you can specify the set of flags. For example you can set a flag that if transaction is reverted you can send it again or you can specify the flag that like if transaction is reverted all the funds are sent to the fallback address which is like part of the message which has been transferred.

Thank you.