Multi-Chain Bridges: Uniting Blockchain Ecosystems - Nemanja Nedic | Ethernal

Hi everyone, I'm Nemana from internal like we are the company that deals with uh protocol level development and the bridges. Today my plan is to explain how uh the bridges who deals with multi-chains actually work. So to build one bridge which can handle uh more than uh two chains. I will give some rough overview of architecture and later on I will introduced some real world projects that are built on top of that architecture. So let's get started.

First of all we need to know why we actually want to to build this. The most common thing is that we want to exchange messages between the bridges. We need to send trans uh we need to send assets and so on and so on. What we want to do is not to create uh a bridge between each two chains but we want to have like a single bridge and then just plug in chains into that bridge. define some routes for communication between those bridges uh between those chains sorry and everything should should work.

Bridge will send uh message uh where they should be sent again there should be like a simple way to introduce new blockchains into this system. We will explain how maybe implementing one or two additional components which are added to the to this system. And at the end something that is also important we expect that end users of our uh bridges will uh get some additional funds will be rewarded for that. We'll see how that will happen. So this is the goal.

We have a bridge in the middle and all the other chains are there connected to the bridge and they communicate to each other and this is like a message passing mediator a router who knows uh which message should go where. How is that implemented? Let's have like a high leveling. First of all, we do not want to have like a single entity to operate this that uh bridge uh to govern that bridge. Instead of that, we want to have like multiple parties who need to cooperate together and control each other.

And in that way during their operation they need to decide about uh bridging requests and messages which should be transferred from one one chain to another. What is what is else important? Since we have like more than one entity and they're controlling each other, they need to achieve some kind of consensus to pass the messages from a chain to any other chain. The thing is that you already have a technology for that and that is a blockchain. Blockchain is actually something that already has a built-in consensus and that consensus can be used to decide how the bridge is going to operate.

So uh the main thing is that we are going to use an additional blockch blockchain in some uh components which will be added to the nodes of that blockchain to build our uh bridge and for those purposes there is a blockchain named blade. I talked about this blockchain last year on this conference and how it can be integrated into enterprise environment. Uh meanwhile uh this uh blade blockchain got additional models and now it's tailored to build bridges on top of it. We'll see how that will happen. So as I said we are building something like this.

We have a chain in the middle and this chain behaves as a bridge. So let's call it like a bridge blockchain here. All the other chains need to com to communicate to each other and the messages from any chain to any other chain just pass through this uh validators to this blockchain here through the bridge blockchain. They need to validate if the request the bridge request that occurred on this chain is uh good enough to be forwarded to the destination. For example, this chain here to simplify this picture a little bit more.

Let's assume that we have only like two chains. And how is that done? Every of the validators of our bridge blockchain need to monitor observe this chain here. They need to figure out if anyone has sent a bridging request like some tokens or some kind of general message to be uh transferred to the destination. They need to detect that bridge request.

All of them need to verify that the bridge request is correct. And afterwards they have uh to reach a consensus that everything is okay. They majority of them has to agree that everything was done correctly on this side of the chain. From that point on they need to build a transaction that is going to invoke a destination chain and transfer for example tokens which were unlocked on this chain here like on the source chain. How is that done?

Obviously validators are built only to create blocks and we need to introduce some additional components. Let's call them like trusted components of these validators who is going to uh which are going to deal with reading these chains here and it looks like this. So again every validator in our bridge blockchain uh gets an additional component. We named it Oracle in our uh study and that oracle the responsibility of that oracle is to observe chains in this system. So Oracle for example Oracle one has indexer that reads this chain and that reads this chain as well.

Again validator 2 has the same oracle and so on and so on. So when Oracle detects that some bridging request has occured here on chain one, it somehow has to reach the consensus within this blockchain that uh the bridge request is valid that is correct and afterwards it should be forwarded to to the destination chain. There are like two approaches how the oracles can reach a consensus that a submitted bridge request here on chain one is valid is correct. The first one would be that oracles communicate to each other. So there is like a dedicated communication line between the oracles where they can exchange messages, exchange votes about bridging requests.

Let's take an example. I think it will be easier for me to explain with uh a simple example. The bridge request arrives on chain one. Oracle one detects that bridge request and Oracle one has some kind of storage here. Oracle is going to write that bridge request into that storage.

Then the Oracle one is going to create a vote. It's going to sign some kind of message that represents that bridge request. For example, hash of that bridge request and send it to Oracle 2 and Oracle 3 and Oracle 4. All of other oracles are going to receive that message, that vote. So now Oracle 2 has a vote from Oracle one in its storage.

In meanwhile Oracle 2 can also read the same bridge request and then Oracle 2 send its vote to the other oracles. The same applies for Oracle 3 and Oracle 4. So there is like a storage for each oracle where they like sum up all the votes regarding the bridge requests that occurred on uh this chain here. Now we need to see what is the purpose of blockchain in this situation. These validators are going to create blocks and let's assume that validator one is a proposer of a block.

So the proposer uh reads transaction pool includes all the possible transactions in the block and then at the end of the block it pings its own oracle and says okay do you have any kind of bridging request here that has collected enough votes from all the other oracles which means that like majority of of the chain of this system has agreed that that oracle uh sorry that that bridgen request is valid and that it has occurred on this chain. If there is such um uh bridging request here in Oracle, Oracle is going to return it with all the votes that has in its in its in in storage uh sorry internal storage. The validator, the proposer is going to introduce another transaction into the block and that transaction is going to hold the bridge request plus all the votes from the other oracles. When that block is created, proposer sends it to the all the other validators and then for example validator 2 verifies the block. At certain point it will read a transaction that holds uh the bridge request and validator to then ask its own oracle okay is this does this bridge request has enough votes.

Oracle 2 because it has collected enough votes for that bridge request is going to return yes. So validator 2 will confirm the block. The same will uh happen with other validators. So at the end we are going to have a a block which is included into our blockchain system and there will be a transaction within that block with all the votes from the other validators that confirm that everything's everything was correct on chain one. Now the only thing that is left that somebody pick up that transaction extract bridge request and send this to the uh to the destination.

In our case this is chain two. That is one of the approaches. The second approach looks like this. So instead of oracles communicating to each other directly uh we deploy something that we call bridge smart contracts. and bridge smart contracts are actually there uh to count the votes of all the oracles in this system.

So this oracle here reads a bridge request from the chain one. The oracle creates a transaction and sends it uh to this validator. The transaction of course uh aims to update this smart contract. The second h the same thing happens with oracle 2. It sends a transaction and send it to this validator.

Again the same thing with the uh remaining two oracles. Now in the transaction pool of these validators, there are transactions which should update these smart contracts with votes from each oracle. And validators use their internal consensus for example IBFT or whatever to include those uh transactions into the block. when they included those transactions into the block uh this bridge will get updated because the transaction included deals with this bridge they're applied on on smart contract and now this uh this smart contract here has enough votes to prove that all the oracles have read a bridging request from the source chain and that bridging request is correct that it is valid. The only thing remained uh to do so now is that someone uh reads from time to time this bridge bridge uh smart contract ping it from time to time and sends the bridging request to its destination.

So we need at least one trusted relayer who is going to read this and submit it to the destination blockchain. So this is really like a a highlevel overview how this uh bridge works. This is how actually works and I'm I'm not going to dive deep into this uh into this uh picture. But as you can see there is like a a user there is a source chain a user submits a bridge request. Oracle detects bridge request then there is like a a consensus way to for everyone to agree that everything is okay.

If everything is okay real is going to pick up that bridge request and submit it to the destination chain. If anybody interested we can discuss this after after the presentation. So now I want to move on uh to some as I said real world implementations of such architecture. The first one is reactor. This bridge here at the moment there is a new ecosystem emerging as we speak it emerges.

So the name of that ecosystem is Apex Fusion and the purpose of that ecosystem is to uh connect uh UTXO world with EVM world. So in that ecosystem there is like a chain named prime that is Cardano like chain. So it is a UTXO chain as we all know that Cardano uses UTXO. There is vector again Cardano like chain with utix sauce and we have nexus which is chain. They all need to communicate of course for this ecosystem to work properly.

The bridge that does that communication allow exchange messages exchange tokens between uh between these chains in is named reactor. a little bit more about the architecture of reactor. So as I said we have prime on our left, we have vector on our right. Both of them are Cardano like chains and we have nexus which is uh EVM chain. What is like a really really nice thing about Cardano?

What I really like is that out of the box for Cardano chains you can create multi- signature addresses. So addresses which are controlled by multiple users. The other really nice thing about Cardano is if you send a transaction uh to the Cardano chain there is a field named metadata and you can write whatever you want. Sorry guys. Whatever you want into that field and we sorry and we intend uh to use that um we intend to use that method.

Okay. Something is wrong place. Uh intend to Okay. We tend something is wrong here. It tend to use that I'm not pushing anything.

So uh okay tend to use that multi- signature address and um metadata. I'm not doing anything. Something is switching by itself. Let's try it now. So we intend to use multi- signature addresses for for Cardano and those metadata in this bridging purposes.

This multi- signature address on prime is going to be controlled by the validators of the bridge. The same multi- signature address exists on vector. And since there are no multi- signature addresses on EVM chains, we need to create a smart contract. Uh and as you all know smart contract can be again controlled by multiple users as those users are going to be these validators. So when someone wants to send tokens for example from prime to vector or nexus or even both chains at the same time it just creates a transaction in the metadata of that transaction writes what is the destination of those tokens and the transactions is intended to update this address here.

validators are going to read what is happening on this set address and when well when majority of validators read that something has happened that a bridge request has arrived they need to uh verify that bridge request and if everything is correct they need to create a transaction which will be submitted to vector to unlock tokens from this address to the user or the transaction that will be submitted to Nexus which will uh ping this smart contract and unlock tokens from smart contract to the user. Here in some cases if uh a user wants to transfer uh tokens to both vector and nexus at the same time validators need to create two transactions actually one for vector and one for nexus. So that's it regarding uh the reactor. Uh the other bridge I wanted to talk about is named Skyline. The purpose of Skyline is to connect Cardano World with Apex World.

This solution will be live in the following few weeks. So we expect the mainet quite soon. So now how this thing operates at this moment right now we can say that skyline is a subset of feature for reactor but later on I will explain uh some additional enhancement. So we have Cardano chain multi- signature address here we have Apex side the representation of Apex side is a prime chain and again there is a multi- signature address here both of these multi- signature addresses are controlled by the bridge validators to repeat myself if you want to send something from Cardano you said like a bridging request that uh locks token on this address validators are going to verify it and confirm it and then send a transaction to unlock tokens from this address to the user itself on prime. So that is how the skyline look looks at the moment but it is planned to be really really enriched in the future.

Uh what is going on? We want to have like a feature that if you use Skyline, you are going to get some additional rewards. So, we are not going to take you take any money. We are going to give you some some tokens for it. Uh, and we intend to use staking for the these purposes.

I will explain how that will happen. Again that process of staking shouldn't be controlled by a single entity. Again we want to create a distributed staking. So more than one entity should be responsible that uh a user who who actually utilize uh Skyline gets uh their rewards and hopefully not hopefully it will be completed until the end of this year probably even sooner. So how that works?

Let's get back to our original picture. I'm a user. I want to set some tokens from Cardano to prime. I will create a transaction uh that holds some metadata and that transaction is going to send tokens here on this multi signature address. validators are going to uh read that bridging request as I said verify get the consensus everything and they're going to ping this multi- signatur here and I'll unlock tokens for me on prime side and now I can like do whatever I want with my tokens on prime side but what's the thing the thing is that these tokens here on Cardano side they're just locked sitting sitting there unused So maybe we can use something something with them as I send metadata for my transaction here to lock the tokens.

I can like outline one field which says okay I want my tokens which will be locked here to be used to earn some additional rewards. And then for those purposes of course we need to have some more code for for for this bridge blockchain and we need to have additional components. We call that additional components stake managers. Stake managers are going to read this multi- signature address and check if there is like if there were a transaction uh in which meta data somebody outlined that wants to use tokens locked here for uh getting rewards. This uh stake managers read that kind of situation and of course they need to agree that everything is correct.

So we need to have a consensus between them as well. And when they reach that consensus, they all agree that the tokens from this address can be delegated to the stake pool on of this chain. So the tokens actually uh which are locked by the bridge can be delegated to stake pool to earn some rewards from those tokens. Now I'm let's get back like uh a step back. I'm a user who spends on uses uh to employs it uh their tokens here my tokens here.

If I want to return to regional chain, then again I can start the bridge request from this side to the uh to the Cardano side. And when everything uh is verified, I need to get my tokens which are on this multi- sign signature address which were previously locked which I have locked and started the first request from Cardano to prime. So I will then get tokens that I have initially locked plus all the rewards from the stake pool that were created from those tokens that were locked here. So I get more when I return into this e ecosystem uh than uh when I actually started uh moving from one side to another. Of course everything can be done on the apex side as well.

We can if we move Apex tokens from prime to Cardano the same process occurs and we can stake them here. So that's the story about the staking. We hopefully we are like we would really like for Skyline to end up looking something like this. So, Skyline currently uh supports Cardano and Apex ecosystem and in the future hopefully we will be connected to the many other chains like Ton, Solana, Polygon and so on. That's it guys.

I'm ready for questions. Any questions? Any questions? Okay. Thank you for the wonderful presentation.

Uh I have a question on what would be a theoretical limit to the number of different networks uh a bridge like this can can operate in facility bridging for

I'm not sure right now. Well, theoretical limit like limitless. Hopefully we can add like a a bunch of of um a bunch of chains here. It depends how fast uh this blockchain is going to work. I think that like 10 20 can be easily like introduced into this uh this kind of system.

Yeah. Anyone else? Okay guys, then probably we should wrap it up and finish. Thank you everyone.