👾 Building a secure interoperability layer for Web3 — Alex Smirnov
--
At the Coss-chain Builders’ meetup in Paris, Alex Smirnov, CEO and co-founder at deBridge, spoke about the architecture of cross-chain messaging in web3. We have made a detailed summary with the main ideas of his presentation.
Introduction
We are going to talk about the cross-chain apps, and the secure interoperability layer of web3. That is what we are building in deBridge. The cross-chain topic is quite hot currently, even at the current state of the market. Many people are saying that we are already living in a multichain world. Right now we have more than 50 different blockchains. Many blockchains are the Ethereum forks, EVM-compatible. They have a new design and a unique ecosystem and various programming languages. In order to maximize capital efficiency, there is a clear need for cross-chain infrastructure.
The problem of fragmentation
Right now we have around $100 b of value distributed across more than 50 blockchains. To maximize capital efficiency and to build efficient applications we should have an interoperability layer. The common user experience right now is like a nightmare in terms of infrastructure. The ordinary user needs to constantly switch wallets, and networks, and understand what kind of bridge should be used to transfer liquidity. It is a super complicated process. And it is definitely not the way it should work. Especially if you want to onboard the next billion users in crypto.
Interoperability is needed not only in terms of liquidity but also for cross-chain intercommunication. But the lack of decentralized standards leads to certain fragmentation issues. The fragmentation of technologies basically means that many teams can do the same thing as replicating Uniswap or fork Curve. The overall efficiency is not that high.
Fragmentation of liquidity is another problem. There is no efficient way to move freely liquidity from one point to another.
Problem of composability
One of the most powerful concepts of DeFi is composability which is also sometimes called money LEGOs. Combining different DeFi primitives and protocols allows the implementation of way more capital-efficient solutions. There are many examples. Like we have Maker and Aave — both on Ethereum. Maker DAO can mint DAI right in the Aave protocol. So Maker can have additional revenue.
Another good composability example is about projects on Solana — UXD and Mango. Algorithmic stablecoin can open delta neutral positions on perpetual markets to maintain its pack and at the same time collect additional revenues.
The main problem here is that these money LEGOs are assembled within one specific ecosystem. There is a certain need to have synchronous composability between smart contracts and there is no way to interconnect smart contracts that are deployed in different blockchains.
Passages between smart contracts
But imagine what if we had such passages between smart contracts that can allow us to combine some set of DeFi primitives on the cross-chain scale. We could have some algorithmic stablecoin protocol like FRAX. It can open up positions on the perpetual markets in different chains and do it in a very efficient way. Instead of opening positions on Mango the protocol can choose between the different providers of the perpetual market.
Or imagine if Aave could interact with the Mango market on Solana.
I think these primitives are what we are going to see in the near future as they allow the building of more interesting scenarios.
What is deBridge
deBridge is the secure interoperability layer for web3 and cross-chain generic messaging protocol. And interoperability infrastructure that allows transferring arbitrary messages and liquidity in the same transaction. We provide a framework for developers and users to solve different cross-chain needs. Basically, the developers can interconnect any smart contract on any chain by leveraging the decentralized cross-chain infrastructure.
How deBridge works
deBridge consists of two layers. There is a protocol layer which is a sort of smart contract deployed in every blockchain that we support and there is an infrastructure layer which is represented by the set of validators that are elected by the deBridge governance. And validators work for deBridge governance.
Instead of implementing the light client, we have this validation layer. And in general, there is no way to build a generic messaging protocol without the validation layer. It is possible to have a light client between the two chains. But whenever you want to build the generalized technology that allows building the data transfers between arbitrary chains. There can be an optimistic design of implementation or another system. We already see many designs. And the only risk here is what happens if the validators will collude. Or if validators will sign some transactions that will withdraw collateral from some protocol or other malicious transfer message. In order to prevent this, we have the delegated staking mechanism. Anyone is able to delegate the liquidity to the validator and participate in the protocol revenue sharing.
If validators were doing something wrong there is slashing which prevents validators from getting into collusion. Normally our validators are running the full nodes of supported blockchains along with deBridge nodes. Whenever the protocol performs the cross-chain interaction, the deBridge smart contract emits some event, and validators are just listening to all events submitted by the smart contract and signing it with the private key. And all the identifiers of the cross-chain events are unique within the deBridge protocol.
There is a really interesting theory about this kind of design. The validators don’t need to broadcast any transaction on the chain. They listen to the event submitted by a smart contract, sign the identifier, and store the signature in IPFS. Anyone who has at least ⅔ validating signatures can execute the transaction on the destination.
For the cross-chain interoperability layer, there is no need to build the blockchain. Because you can’t provide a bigger throughput than all the blockchains supported by the bridge technology.
The design of deBridge is unique because we have the off chain validation. The only goal is to make all the validators’ signatures to be publically available. So anyone can execute the transaction on the destination.
The generic messaging protocol that we have build is live since February. We have got more than 100K transactions from around 55 thousand unique users. deBridge supports seven EVM chains. So developers can easily transfer data and messages between smart contracts.
The main problem of the bridging technology and when interoperability
Many users have the wrong perception of what bridging technology is. Because originally the bridges were created only for value transfers. The main goal was to lock the asset on one blockchain and receive the wrapped asset on another, and then do the swap. historically all the bridges are focused on allowing users to transfer liquidity from one chain to another.
But bridging is also about the transaction of data or data and liquidity simultaneously. And not only between users and the protocol but also between the arbitrary protocols. Let’s say protocol on Ethereum can bridge data in Solana or another chain. But that’s not enough. To efficiently bridge the data you need to know the sender. This design allows smart contracts to build some kind of decentralized interconnections.
One more interesting thing is about the execution of transactions in the destination chain. All cross-chain transactions consist of two transactions. One is initiated in the origin blockchain and one is executed on the destination chain. On the original chain, the transaction is initiated by the user and there is a question of who can execute the transaction on the destination chain.
How to perform cross-chain messaging
Sending an arbitrary message is as simple as calling the message of deBridge smart contract. This method can be called by the user, or by the arbitrary smart contract. There is a sender that can be a user or a smart contract. He interacts with the deBridge gate smart contract and as soon as the transaction is final, deBridge infrastructure signs the identifier of the transaction, and it is getting executed on the destination chain.
We have some set of parameters like the token address, amount etc. But the most important parameter here is the _autoParams. This structure allows the passing of arbitrary messages and also customizes the execution flow. On the destination chain we have the callProxy, and we just execute the data and pass it to _autoParams structure. In this structure, we have the execution fee which is the parameter that allows having the crypto economical design.
There is also a fallbackaddress which is a parameter and is needed in case the transactions get reverted. Calldata will be executed at the destination chain. Developers can customize the execution flow of the transaction on the destination chain.
PROXY_WITH_SENDER is another important parameter that shows who was the sender to the smart contract.
Interoperability is about interconnecting smart contracts on the different chains. Building cross-chain applications is easier. The only thing that developers should do is to build one smart contract for one chain that interacts with the deBridge protocol and our protocol will automatically interact with your receiver.
Transaction bundling is a feature that allows building some complicated combinations within a transaction. The message can encode an arbitrary set of transaction calls. We should specify the additional flag for this. If you ever interacted in this Gnosis chain there is some feature that is called the transaction builder. This is a unique library. We made our protocol originally compatible with the existing web3 ecosystem. And build in the Gnosis multi-sign library. You can do a lot of different transactions and put them into one single transaction.
The use cases of deBridge
The first approach is to build the cross-chain swap within the multiple chains. And all the magic we have under the hood. We have integrated with 1inch and that’s why we have great liquidity. In deSwap we connected 1inch router smart contracts with different chains. Protocols do not need to have many liquidity pools as cross-chain swaps can be routed and maintain the needed level of liquidity.
There is also a problem with participation in Ethereum governance as there are high gas prices. Sometimes gas costs more than the amount of token to be sent. We can create governance voting in different chains and settle the result in one chain, for example, Ethereum. Also, there is the possibility to create cross-chain yield farming. You can automatically balance your liquidity across three blockchains simultaneously.
Also bridging of NFts will be another use case. Cross-chain applications change the scalability of the projects. Like Aave now deploys seven different protocols. Many DeFi projects will gradually move toward the application centric approach. And they will just pick a blockchain that suits their need. And from the interoperability layer the application will be available from any other chain.
