All right. Sorry for the hold up. Yeah, my name is Donut and working on a cross chain privacy protocol called wrapped out. And today I want to talk about cross chain state without a multi six. The basic TLDR of this talk will be that each time when we try to move state or value between chains, we unfortunately bought in on some additional trust assumptions that they're eventually leading to a hack.
Um Yeah, for example, a multi six a committee or an oracle are usually the things that we are adding on. Things like that and what I also like to say is that not all multi six are being hacked, but it's always a multi six in most of the cases at least. I mean of course there are exemptions like the balance hack. But we'll get into that in a couple of seconds. Um so yeah, maybe let's start with the good news first.
The good thing is that a lot of code is being audited, formally verified and it gets harder to break the actual logic of smart contracts or the solutions that we are building on chain. Um But what I feel like is happening is that the money now flows through people and so what I mean with that is that the humans that we are building into those kinds of systems become the new attack vector and yeah, this includes of course fishing, keys getting compromised or yeah, social engineering attacks. Um maybe first of all, I want a little raise of hands who can still remember the count down hack in April 2026. Okay, that's not actually that much of people that know about it. But what basically happened just to get you all up to speed to it was that the Lazarus Group by North Korean state backed hacker group hacked the Kelta Bridge for I guess almost 300 million US dollars of value.
What happened was I mean in hindsight I guess uh let's not call it stupid but it could have been easily avoidable. And how they did it was basically the Kelta Bridge ran with layer zero and they have something called Divans which stands for decentralized verifier networks. It's basically a trust assumption built on top. Makes sense of course for let's say chains or blockchains that are not so similar as for example the EVM is. And what they had on top of course for that to which make it made it or even more worse was that it was a one out of one configuration meaning they effectively just needed one signer to get that attack going.
What they did was just they got the private keys for a VPS instance which ran a RPC node which was used for the DVN. They poisoned that and I guess DDoS two other ones which then allowed them to get this hack approved basically. The issue with this was of course that the code was never the problem. It was um simply a valid transaction. What went wrong was just those trust assumptions that got hacked.
And this led then to a to a expensive lesson let's call it like that. Um yeah, and I guess the worst part about this is that this did not really need to happen. I think I just mentioned it right now that it is a um EV-based bridge, so it had no reason to actually use layer zero. Um it would make more sense if it was something like a Solana, Bitcoin, and just get the value moved across on there. But it was not the case.
We or they could have used um the native messaging uh for that instead, uh like the canonical bridges, for example. Um yeah, and like I said, they uh added some more trust assumption on top, which was uh not ideal since they just could have used like the shared um uh root of trust, which was Ethereum in this case. Uh yeah, for example, the EZ would have uh solved this, I guess, for them. Um and here comes a solution, or let's call it maybe a I think there's a No, there's not a um slide missing. Uh and here's what's a potential solution to this could look like.
This is maybe the async version of the EZ approach. Um and what you would basically need for that is just two things. Uh one is a a shared Merkle tree with a shared uh shared um Merkle root, and of course ZK tag to prove uh the state between the chains. Um this is actually what we have implemented for Warp Drive. Uh we call it the Giga tree.
What's uh is basically happening is that on each roll-up or each chain, you have an instant instance of the code of Worp Drive running that uh takes the root, pushes it through the native uh messaging bridges to the layer one, where we then construct the Giga tree, and then you can just simply use the Giga root to prove uh the yeah to ZK prove something from layer one. In this case it is a shared anonymity set. Um and yeah there are of course two honest trade-offs that we need to consider. I mean using layer zero was of course um I think one of the reasons was just out of convenience because the uh SDK for that was just easier to implement I guess. Um and they could also skip the two things that I mentioned here.
One thing is that of course because we are using the native bridges uh it is slower since we need to wait for them and also wait for the exit windows. And the second one is that we are I guess it's a shared problem with easy is that we are inheriting the weakest chain rule which basically means that you trade composability for a bit of security. Um meaning if let's say Lazarus group would have also a uh roll up and that would also be included in the Giga tree that chain would become the weakest chain and then they could also hijack the whole uh thing. But you know I mean on the on the flip side you can I guess exactly see what and who you are trusting by um this approach. And yeah I mean this is also a real thing right now.
If you want to dig into the code or just look for some kind of example you can uh do so with the code base for Warp Chasm. We have the Giga tree there. This is of course still work in progress and we are doing still some research on it. Um but yeah I guess that's about it. I hope I wasn't taking too long and if you want to uh chat or just talk about uh cross-chain states then you can scan the QR code and maybe also catch me later during the conference.
Thank you.
Automatic transcript — names and jargon may be misspelled.