New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Gnoss Chain 🛠 Building Security-in-depth- cross-chain apps with Hashi

ETHGlobalWed, Oct 9, 2024, 12:00 AM

Join us for a workshop titled, "Building Security-in-depth- cross-chain apps with Hashi". From November 17-19 2023, ETHGlobal welcomed developers from around the globe to take part in shaping the future of Ethereum at ETHGlobal Istanbul. Over $600,000 USD in prizes were given away at the prestige Istanbul Congress Center... thanks for an amazing weekend hackers! ----------------- Follow us: https://x.com/ETHGlobal?s=20 Check us out: https://ethglobal.com/ Email us at: hello@ethglobal.com

Transcript

[Music] hello everyone I'm Alesandra and today I'm going to talk to you about Ashi Ashi is a protocol for cross-chain communication that allows you to send a message using more than one Bridge what okay okay Ashi is a protocol that allows you to send a message uh cross chain using more than one Bridge just to give you like a little bit of history that I I'm sure you you know it uh we have seen in the past years that uh many losses were caused about uh basically Bridges and users at the moment don't trust Bridges anymore because uh um yeah because putting I mean all your trust in a single bridge is is very is very dangerous since you cannot like like be sure that uh that a bridge is free of bucks also because like building a bridge uh is very is very difficult since a bridge is composed by many components and uh like um be sure that is completely free of bucks it's it's very difficult also you know if you like do a lot of audits you cannot be sure that basically you don't have bugs so for this reason uh there's need a paradigm shift in the bridge design so what is Ashi Ashi is a protocol yeah for cross chain communication that allows you to send a message cross Chain by using more more than one oracles so the goal of Ashi is to basically distribute the trust among independent oracles since in this way it will be like very difficult to break them all at the same time so now let's move maybe on the most technical part how to send a cross chain message with ASI okay so uh the entry point here is the ya contract on the source chain which is let's say the main contract that allows you to interact with the underlying message relay contract for each Oracle you need a pair of of contract a message relay one and an adapter the message Rel one is the one that is in charge to uh like in interact with the underlying Bridge contract while the adapter is a contract that just stores uh the ash Sent From the Source chain then when you want to send a message you have to call the dispatch messages function the dispatch messages to adapter function uh Inside by specifying uh the list of adapters and the list of relayer that you want to use and obviously uh the the message then ya U for each message relay we call the underlying message relay by calling uh the relay messages function so in this way uh I mean um each message relay contract must implement the relay messages function and uh yeah inside of it uh each message relay will call the underline contract of the bridge then uh when all bridges will have processed uh all message independently um you could you can execute the message uh so uh the what you need to do is to basically uh you have to wait uh all oracles that uh that will have processed the the message and then you can call the execute messages function on the Yu contract by providing the original message and the list of adapter that you have that that that that you have used ya then um we'll just basically calculate the ash of the original message that that that that that you passed and we we compare it with like with each Ash stored in each adapter if there is consensus the target contact can be called now guys I will show you uh some code that show that that shows this like Behavior so uh okay okay this is just a ping pong a simple ping pong contract which has two function the ping one and the pong one the ping one just calls the Yao by specifying sorry guys uh the message relays and the list of adapters uh it just encode let's say uh the the function signature to to call on the destination chain which is this one uh then for or adapter yeah Yao which is this contract let me show you we'll call the we'll call each message relay so let me show you our message relay is done very easy let me show you maybe the amb1 it implements the relay messages function and and inside of it it just calls the am bridge and this can be done with like uh many bridges also with like ZK like like like Cent or ZK Bridges then when uh when yaru will will execute the messages here it will uh it will need the original message yeah the message IDs and the and this Ender but these are just needed to calculate the ash yeah here it will compare the wait a second sorry it will compare the ash the ashes sorry guys the here if the ashes are equal the Target contract will will be called in this case will be uh the function that will be called will will be the pongan so the pongan Will Will just check that this end there is z aru and that the source sender so the sender that initiated the transaction on the source chain is actually the order ping pong uh and then it will just emit an event um super super simple uh then let me show you maybe let me okay ping pong this is on go early now let's let me show you okay contract right okay now for for Simplicity guys I will just use the one Bridge since on testet we we don't have it many so I can just use one but uh if you like Ping with a second I don't want to sell anything okay uh okay now I'm I'm going to call the Ping function let's wait for the confirmation it should be like very fast uh okay you can see within the logs that Yao contract emitted an event which is called message dispatched which which contains the message ID the data so the uh pong function encoded with the corresponding parameters and then yeah uh some some events emitted by the um by the message relay then on the other side when you want to execute the message you need first of all be sure that the underlying bridge will have processed the the operation yeah it has now uh um within the aru contract on the destination chain you need the when you want to execute a message you need the sender so I mean the pin pong contract on the source chain the destination CH which uh is is gnosis and the and the data the data is this one okay I'm s okay message ID is it you can take it you can take it here it is five senders okay or okay now I will execute the message wrong Network okay here you can see that the message execution has been completed let's wait for the confirmation okay you can see that the pong event has been emitted so basically if we had like used more than one more than one Bridge you had to like wait for all for all bridges and then call this function by providing the list of all Oracle adapters here that's it's really easy then I will come back to the slides yeah just to show you uh if you wanted to like uh build a message relay or a or a or an adapter uh this is the way let let's say uh it's it's super easy uh the message Rel contract just to just need to implement the relay messages function uh which call again the underly bridge and and instead uh the adapter must Implement a function called stores which which which just store uh for each for each Source ID the message ID is and the message ashes now I will leave the talk to my colleague Zen thanks Ali hi I'm Zen so instead of uh besides relaying a message using hashu we can also like relay the state of a source blockchain to another blockchain using the block header so it's very similar to relaying the messages so instead of like relaying so you can see like the Y part is the underlying Bridges and hasi is just a bunch of like smart contract on top of them so what you can do is like for example um I want to relay block uh 100 from ethereum to um nosis chain for example you can call this header reporter contracts on the etherum and you specify which block number you want to call and what is the destination chain you want to pass to so once the contract uh function is called it will store on the destination adapter contracts and and where does the security comes in so instead of like calling A and B to relay the functions I can call like U connects Wormhole like for example five Bridges to relay the same block numbers for me and they are all passing through uh has the bridges and store in the adapter contracts so like where Hashi comes in is that you can um think of like hashy like a multi of bridges so you can Define your threshold for example I want five out of Three Bridges um to store the if um I if I specify the block number and I call five Bridges to bridge the same block headers for me and let's say if three out of five of thems um store the same hatches then I can assume that the block header is correct so that's is where the additive and security Parts comes in so you want if you want to interact with Hashi to relay the block headers it's really that simple you call the report headers function on Source chain and then um you call the get hash from oracles function from the hashy contracts and yeah so from The Source chain we have this header reporter contracts as you can see we specify the block numbers and which adapters we want to use and also the the guest and once the contract function is called it will admit this header reported event so the ID is the block number and the block hash is the actual block header from The Source chain so after the function is call it will be stored on the destination chain with um hash store events emitted and yeah the ID is the block number and hashes is the block header and what you can do with the block hashes is a lot of things so like you can verify the States from The Source chain and for example back to the pingpong um example that Ali demonstrated let's say I want to check if an event is emitted from ethereums and I want to check on the Noy chain so now we can like have two parts to check first we can check if the block header that has relays is correct sorry it's correct and then we can check the receipt roots and the receipt related data that is uh that we fetched from Source chain RPC is correct so let me show you like a simple quote Yeah so this is the interface of hashy contracts so we call this um get hashes from oracles with the Oracle adapters address so like for example I have called five Bridges to um relate it to tokens sorry relay the block headers for me so here I need to specify all those five um oracles address here and domain is the source chain um ID so for ethereum is one G is five and the ID is the block number and what it does is we'll just get all the hashes from these oracles individually and as you can see it returns a bunch of an array of hashes so besides on that and you can build like your customize what you want to um refer from these hatches for example if you think like ZK like clients more um reliable you can just call five ZK like clients um and get their block hashes or you just want to hatch some for example I can add some multi um bullets sorry multi um oracles you can just specify your customized uh logic that you want to check so yeah so back to that um admit events example and on the destination chain how do we verify the state and the receipt is correct um so yeah so in this example we are going to um verify the mer proof of the receip is correct and also the block hash so first we Define the input of the uh of the proof so like here are the receipts related um the data that you fetch from The Source chain you can just call like get uh transaction receipts and also get blocks to fetch all these data and also the log index in the block regarding to the event that you want to proove and also the block header this block header um is the RP encoded block header elements like parent hash and state roots and transaction Roots so you can like basically recreate the block hash by a hash Kat to 5 six hashing this block header and now we yeah we deserialize the data and now the first thing we have to check is if the block hash that is stored on hashy adapters are correct so first we use this block header that we provid you can fetch it on RPC on a source chain and then we call this like reported hash and then we fetch the hash from hashy um that you call those individuals or Les to pass the block header to um and it's like just return a bunch of block hash so yeah we can check that if those two block hash are correct then if it's correct then we can assume that this block hash indeed is correct and yeah and the next logic is just checking the receipts checking if the EM em meter address is ping pong or not and if the top iics is the actual ping events topic and also we can verify the merro proof uh for the receipts so once it is like verified you can defy your own dep logic like airdrop or crossing governance or just sending a tokens um so yeah that's a very simple use case for that and let's say uh if you want to use hashy but your the your oracles that you want to use doesn't exist yet you can build your own um adapters and header reporters on both chain so it's very simple just a few lines of codes so first on the source chain we have to like inherit this header storage um contracts and then we store those block hatches and then here is your oracles or bridge and customizing um logic to relay the message for example ccip you can use ccip scent and other oracles you can use different methods to pass the message and also you have to admit the header reported event and on the destination chain is where the um oracles call this adapter contracts store hatches function that will eventually store those block headers on your destination chain um yeah so that's a very simple use case of Rel a token if you have any questions feel free to check out our docs and GitHub and also yeah disc cours um thank [Applause] you

Automatic transcript — names and jargon may be misspelled.