More Than a Bridge: Evaluation of Cross-Chain Messaging Protocols | Alex Murashkin - Quantstamp

[Music] hello everyone my name is Alex murashkin and together with my co-workers sunshine and hyam uh we looked at uh cross chain messaging protocols so we have a lot of active chains now right so that's more than 100 l1s and more than 40 l2s by now and even more and more coming and uh yeah cross chain interoperability is challenging right so it's not just bridging assets from one chain to another uh but it's also about synchronizing arbitrary state or uh making arbitrary smart contract calls across chains uh and uh of course there are multiple proposed solution to this problem right and uh but which ones are out there and what are the similarities or differences or tradeoffs like we know there is a the blockchain trilemma right so obviously some of that can be applied here and in the end as a web three developer what would I uh use for my application right so that's something that uh that is keeping us uh up at night and previously we spoke a lot about evm to evm Bridges uh and we gave a few talks uh here last year uh regarding um the bridge designs and also uh Bridge hacks and we wrote some papers gave talks in some other venues as well and this time we are taking it up uh taking it one step further and talking about uh cross chain messaging protocols as a more General problem and we'll look at certain dimensions and aspects that could be useful in this uh in this regard and we'll give an overview of a few uh example protocols uh including acceler layer zero hash diagnosis and chain link uh ccip and we'll try to do some comparison and takeaways uh but uh it's very hard to do like a deep dive comparison here because things keep rapidly changing so we just did kind of our best to do some very very initial high level um compar just maybe to give some idea and of course future work could involve a more more detailed and systematic comparison of various protocols and uh what should we look at right so all first of course the number of supported chains right because uh number of chains keep keeps growing and uh we might be looking for protocols that support you know at least 50 chains right and uh yeah so what is the design class right some of them might be uh coming with a separate uh side chain that is kind of everything is centered around that uh some of them might be um coming in a different shape like for example could be network of three layers or some other uh protocols sorry some other offchain components uh we we can look at centralization and upgradability it's not uncommon for protocols to have uh uh some way of uh privileged access at the beginning in the development phase um and uh yeah of course we can look at certain criteria like message size and latency maybe some of them are more optimized in that regard uh costs is an important aspect there for end users and for operating uh and uh yeah all these protocols might be different in terms of how they Implement their consensus right so uh number of participants uh the number of votes needed for or for the supporting votee or number of um malicious votes required to harm uh the network which kind of defines the the threshold for security and more generally what are the security and Trust assumptions here and what are the risks so all these things could be useful to look at we only managed to look at uh some some of them let's start with acceler so acceler is a programmable web three interoperability platform and here I'm sharing some links to the website the GitHub repositories and the white paper as well it seems like this protocol is live uh and can be um looked at using this live dashboard uh and uh yeah the number of supported chains it looks like it's 50 and more and uh the protocol defines its own mechanism for uh supporting cross-chain tokens they call them interchain tokens and we will see that other protocols have a different way of uh uh describing their mechanism and in terms of distinctions for design uh this this one has its own network with a dedicated threshold consensus implemented so there is a bunch of Val validator nodes uh that uh running and pretty much have a a way of deciding which um message is uh uh goes through uh in terms of transaction flow uh of course all users have to start with compensating the network for gas right that's kind of inevitable unless there is some kind of subsidy from the uh from the chain uh owners themselves uh and uh once this is taken into account user calls uh the so-called Gateway contract where they specify the destination chain and uh the target address and the payload to send to that method uh of the smart contract on the destination chain in right so that's kind of a more General uh approach to cross chain communication so not just Bridging the assets but sending arbitrary data across chains and uh usually there is emitted event just like with any Bridge implementation and uh there are layers that are listening to those events and uh submitted to the AEL Network for processing in this case anyone can run a relayer and the network also has provides a free free reers in this case uh next the validators of acceler network agree on validity and the content of the message to be relayed they form the B the batch of commands and they pretty much uh facilitate execution uh of those uh through relays on the destination Gateway and the important part here is this step number eight uh the validation of um uh the basically the payload and the method uh to make sure that it's approved by acceler validators right so this is the the ultimate uh condition that uh things are indeed approved and validated and can be executed on the destination chain in terms of fees and costs uh like we will see with any protocol the fee structure will be um composite so there will be multiple essentially uh steps uh in this uh chain that you've just seen uh the processing chain and each of these steps need to be uh paid for uh and of course in most cases it will be end user who who would need to compensate for these costs uh and uh yeah the the interesting uh part is that gas is not always predictable right because you have two chains and users usually have the tokens or assets on the original chain so they can pay the fees using that original The Source chains uh tokens or E and um this uh the actual execution destination chain is what can be variable depending on uh gas price right depending on uh latency and so on so but thankfully there is a refund mechanism so in case you overpaid uh it looks like in this protocol there is um a mechanism to to get your money back in case you um you haven't used the entire amount and in terms of the security and liveness assumptions uh you of course the layers and validators need to be live and secure they need to continue to be operating in order for this to to work uh and of course there are uh certain security properties that that are usually validated uh during audits uh and uh most recently of course we we see the need for infrastructure audits so not only validating not only verifying that the code is good but also that this is deployed and running successfully in a secure manner let's move on to layer zero now so layer zero um is an omn chain interoperability protocol uh and you can find the site and the GitHub and documentation links there uh so they recently released the new version V2 and we try to do a slight comparison here uh between the two versions as well uh it seems like they alive and they have close to 100 supported chains that which includes uh also non AVM uh chains and uh main Nets and test Nets of various uh chains so yeah it seems like uh there's a lot of coverage there uh they Define their mechanisms for cross chain tokens uh and call them uh Omni chain fible token uh which is of and they also have o nft which is the uh the version for nonf funable to tokens in terms of design they have the network of Rel layers and an Oracle in version one and in version two uh this these two components have been uh made more uh generic and replaced with decentralized verifier networks and executors in the V1 um and this part is also preserved in uh V2 layer zero end point is uh what what they call uh the smart contracts on each chain so there has to be deployment on each chain on each supported chain for this to work uh then there is a network of three layers uh so they are run by layer zero but can be run by anyone and for oracles uh they uh from what I saw in the documentation uh V1 was using Google Cloud Oracle previously was using uh chain link and in the V2 later we will see that this was changed uh and uh the general flow of the message is uh layer zero end point is pretty much an entry point like the Gateway contract for the acceler network where user application uh sends some payload uh and this gets stored on chain in the source chain uh then the Oracle component Waits until the given block is committed to chain a and notifies chain B's end point uh chain B is a destination chain in this case and upon confirmation relayer sense packets improves uh much in the the current block and uh chn B's validator component ends up validating the packet and and ends up forwarding that to the chain B's so-called Communicator component which forwards it to the end user application and the important part here is that Oracle And relayer even though they work together they have to be independent so that there is two different sources of uh uh pretty much validation for certain events happening uh and uh of course the layers are also important for livess reasons uh protocol in V1 had the privilege roles uh which involved upgrading the library versions which makes a lot of sense so uh having to develop a protocol it's hard to make it decentralized at the very beginning uh all you have to make sure that there are audits taking place and that all these trust assumptions and privileged roles are well understood in terms of fees and costs just like in case of acceler network uh there are multiple costs right you have to pay relays oracles uh Native protocol fee and they usually hard to predict and uh just like last time uh in the last uh case uh users usually do not have token on destination chain so they have to be charged in the token on the regional chain in version two Oracle was replaced with the so-called decentralized verifier nodes and applications looks like they can configure which uh decentralized verifier nodes to use and which parameters uh which is quite interesting uh and there are around 28 28 tvns available at the moment and notably some of them uh as you see on the bottom right screen um come from uh acceler and uh ccip so we actually see the convergence of these various protocols where they can use each other's um pretty much nodes for uh for Oracle purposes uh through certain adapters and we will see a similar thing later with a different protocol and yeah so let's move on to Hashi diagnosis uh so my understanding was that this protocol is still in development uh but there is a version that is uh working uh and in terms of design distinction there is it's centered around the agnosis chain and there are adapters for multiple communication protocols right because this the intention for this protocol is uh be uh being the evm hash Oracle aggregator in terms of architecture uh you have this uh various uh communication protocols that are integrated through adapters and on the right hand side you see the list and notably uh what we saw chaining ccip and layer zero are on that list as well so yeah so we we kind of have this uh interesting uh convergence in this regard and hash is an interface to query all the stored block headers in the adapters and therefore they facilitate uh pretty much determining uh the uh the trust and security properties of cross chain communication and the whole value proposition there is that instead of relying on one source of Truth you are relying on multiple source of truths from all these various protocols which ultimately support enhance the security so that's kind of the premise uh we don't we don't not have much time but for chaining ccip uh there is um there is like a main net Early Access that is uh available uh and there design distinction is that they rely on so-called decentralized Oracle networks and they have two types of Oracle networks the so-called committing Dawn and the executing Dawn and uh there is a third component called the risk management network and on the next slide we will see how they uh how this is all working together uh so the committee da listens to events and waits for finality on the source chain then stores that commitment uh and independently risk management network uh approves or disproves given event uh so there is pretty much like a similar system there is some resemblance of the previous designs that uh we've just seen and executing Dawn waits for both of these components to give the blessing and completes the interaction on the destination chain this is kind of the high level design here so now let's uh move on to uh comparison and initial takeaways uh so in terms of similarities uh I think that uh if you were um kind of looking at the uh watching the presentation you will realize that there are certain architectural similarities there uh so all of them require of chain components uh it's it's pretty much it's very hard to do it completely on chains it seems like there are so many uh moving pieces so many chains to be supported and all of them require some sort some way of handling finality on orinal chains right so this is not a given but has to be implemented and has to be done properly on the ux side we have two issues but they are kind of inherent so I do not see how one would solve them without sacrificing other properties so these two things are latency and fees um and on the on the deployment side rolling rolling out to multiple chains can be challenging because essentially you have to run uh the same set of you have to deploy the same set of contracts on multiple chains and you have to make sure that the Rel layers and whichever components are there they all connected across chains which is also a hard problem in terms of operations to solve um and in terms of security and liveness there are some similarities as well uh but all of them share the fact that trust is still required so maybe in the early phases trust to protocol admins uh in and in some cases uh trust to certain components for example to uh like to pretty much the the various committees or the oracles or pretty much there's there is some trust assumption that is probably uh necessary uh for for you to be confident that certain event deposit not deposit not deposit but certain invocation of method took place on the source chain in terms of differences we see that there is some distinctions uh in terms of architectures right so acceler and Hashi they seem to be centered around their own side chain uh whereas a Zer and uh chain links solution require of chain Rel layers and executors uh and as well as oracles or devn uh basically there just just like different names for uh similar purpose components and uh we've seen that uh pretty much ccip also had this different uh role uh for enhancing uh for validating the security aspect of it and in terms of uh state of Readiness I think there is some distinction there right so um seems like there is a um certain components alive but certain components are still in development phase and even those that alive they keep being developed so it's uh not easy to keep up as well and uh what do we choose right so some initial thoughts as a web three developer I want a protocol that is live on mainnet with many supported chains which is well documented and supported uh we need cross chain token support at the infrastructure level so we don't have to re reinvent uh the support uh there and uh yes I usually value Simplicity in designs um to the reasonable extent and uh uh it's good if there is some flexibility in trust assumptions but in the end what I realized is that everyone will make their own decisions and um in this regard we see it as choosing cloud provider in the end right so I think it will end up uh at this point thanks everyone