Charles Lu - More Chains, More Problems: Fixing Interop and Reorgs? - TOKEN2049 Dubai 2025

All right. Well, thanks everyone for coming. Thanks Paul. Thanks to the organizers um and the staff. Most importantly, thank you for sitting out here in the heat.

Uh my name is Charles. Today um I'm going to talk about what problems are arising from the thousands of chains that are being deployed every every day and what we're doing to fix it. But first maybe just to get a sense for the audience um how many people have submitted a transaction on any chain? I guess everyone has. Um how about five chains or more?

Has anyone used five chains? How about 20 chains maybe even? Has anyone bridged from one chain to another using a cross uh or maybe some some other app? Has anyone built their own chain or deployed a chain? I Okay, I see a couple.

Um, anyways, as you all know, every every day we're seeing new chains being deployed and that is presenting many issues. There's actually two issues I want to talk about today. So on the left, one problem is that many of the new chains that are getting built are actually rollups. Now roll-ups are actually operated essentially by a single server. that one server is responsible for deciding which transactions are included and what the ordering of those transactions is.

So while the rollup sequencer cannot actually steal funds outright, it's a big problem and I'll talk a little bit about why. The other side is that with each and every chain that's being created, bridging is actually becoming much more slow and much more expensive. Right? assets are siloed between chains. Each chain has its own assets.

Each chain has its own apps. And anyone who's tried to use DeFi across different chains knows what I'm talking about. Um, even using tools like Across can cost quite a bit when you're thinking about making bridging transactions and how many basis points you're paying each time and how long you have to wait. So what we're doing at espresso, we're actually trying to build a confirmation layer. We call it a confirmation layer to solve both.

In fact, both of these problems are very closely tied together. Let's talk about the first problem on the left, the problem with the single sequencer and the security problem. I I I put hack on this slide, but it's actually not even an issue about hack. Let's say the sequencer of some rollup is compromised for some reason. Uh maybe it's just a dishonest sequencer.

What's the worst that could happen? Well, recall that the roll-up sequencer is responsible for ordering transactions. And the sequencer is basically seen as the source of source of truth on what transactions are included before it's settled to any base layer that the rollup uses like Ethereum. So imagine a user deposits money into let's say Binance on Arbitum 1 and now let's imagine that the Arbitum 1 sequencer is somehow compromised or hacked. Um what would happen in that case?

Well, Binance has credited tens of millions of dollars to the user's account which might have been traded to some other asset and withdrawn already. And let's say the sequencer is now reverted. That's a huge problem for Binance. That's why exchanges make you wait probably I think in Binance for arbitum it's around on the order of 15 minutes before you can withdraw those assets. You might be able to trade with your deposits but you definitely can't withdraw.

And that is the fundamental problem why when you're bridging from one chain to another you either need to pay a high fee or you need to wait a long time. Any any rollup can get hacked. Now, you might trust that arbitrum 1 is honest because it's such an established rollup, but how about a new rollup that just came out yesterday? Would you really trust that the sequencer is completely honest or not vulnerable to hack? Now, there hasn't been a huge sequencer hack yet, but anytime there is a big incentive, there are going to be hacks.

And a sequencer of any rollup is just a single server. And as we know from history, including recent history, when there's money to be made, the hacks are going to be be attempted. So how does this problem blow up when we have more chains? Now every day a new chain is being deployed as I mentioned, right? Let's say a bridge app like a cross or a circles CCTP or a layer zero is deployed on multiple chains.

Right now these these apps are deployed on tens of chains. If even just one of those sequencers has a probability of let's say p percent of being hacked. If there are n chains then that probability essentially gets multiplied. If even there's one loose loose link in this chain or I should say if there's just one chain that is vulnerable the whole system could be drained for value. So this is a critical problem.

Now let's talk about the issue that I described on the right on the first slide composability. Now as I mentioned it's a very very similar issue. The problem is that we wish to communicate between chains. The most simple example is bridging right. We wish to move USDC on one chain like arbitum to optimism in the most simple case or maybe we want to move it to RARI chain rarables chain to buy an NFT.

Um, Espresso, Espresso's Foundation actually just announced that we're launching an NFT collection on Rarables chain, Rari chain, which is uh, one of the first chains integrated with Espresso. But let's just imagine that. What do you require? Well, as I mentioned, when you bridge assets from one chain, let's call that the source chain to the destination chain. The destination chain needs to know for sure that those assets are truly going to come through, that they're locked up on the source chain and that's not going to be reverted.

So what we require is we require low latency for realtime interactions, but we also require security to know that the bridging transaction is not going to be reverted. This does not just apply to chain-to-chain bridging, but as I mentioned, it applies to web 3 to web 2 interactions as well, right? Binance for instance or any centralized exchange is a web 2 app. It is a centralized service, but composability still really matters here. the example I gave about depositing on a rollup like arbitrum one into Binance, Binance needs to wait until it's certain that that transaction is not going to be reverted before it can actually allow you to use those assets that you deposited and withdraw them.

So what we essentially need is we need a way to confirm the finality of this message. We need to avoid any reversion to avoid any potential loss of funds. This applies to both web 3 and web 2. Communication as I mentioned needs to be both fast and reliable. So when it comes to reliability the most important question is what is a reasonable trust assumption?

What can we actually trust? Well I made the assertion just now that trusting a single server is just not enough because a single server can easily be hacked. What could we possibly trust that is better than a single server but is not as slow as Ethereum? So that's essentially what we're trying to build at Espresso. We're trying to build a confirmation layer that can confirm the finality of messages within just a few seconds.

So how do we go about that? Let's talk about the challenges between communicating between chains. So let's imagine we're trying to move messages between say Ethereum or Polygon. These two chains use completely different consensus mechanisms. They're very different, right?

Ethereum uses Gasper consensus and many people think that oh the block time is in Ethereum is 12 seconds. Uh that means the transaction must be final after 12 seconds. Is that true? Actually, it's not true at all. It takes around on average 15 minutes for a transaction to be final on Ethereum.

So let's say you someone's buying your house and you've received some money on Ethereum. uh that you know you should not be giving the h giving up control of the of the house or giving the keys to the house until 15 minutes have passed. Definitely you don't want to wait 12 seconds because there could still be forks. Uh the the same cases for Binance or or ETH deposits as I mentioned these are all using different rules. Now let's talk about roll-ups and how we can potentially improve the situation for roll-ups.

Roll-ups actually have a way to communicate easily. Um right now roll-ups deployed on Ethereum can simply communicate through Ethereum. Uh it's actually um many roll-ups have their native bridges. Now the problem with a native bridge is that it can take hours or even days to settle through the native bridge. That's why there's solutions like across if you've used a cross to allow someone else to take the risk and you just pay a higher fee for across.

Um so there there there are problems with just using the native bridge with Ethereum. So what we're trying to do is you can call Espresso a sort confirmation layer or a layer 1.5 that's sort of in between that provides both of these advantages being fast and also being cheap and also being secure. So what is Espresso? Espresso is essentially this confirmation layer in the middle.

What we're doing is building a layer where transactions from chains can settle and get instant finality within around 5 seconds. before they settled settle to the layer one, but you still have a guarantee that ultimately what is settled to the layer 1 is exactly going to me match what was already confirmed by espresso. So we're trying to speed up interop and also boost security and as I now mentioned these two these two problems are tied completely together. If you improve security then you're speeding up interrupt. How do we do that?

Well, what underlies espresso is a technology, a consensus protocol called hotshot. It's something we've been working on for four over four years now. Um, hotshot has a key property called optimistic responsiveness. Optimistic responsiveness basically means that in optimistic conditions, we can get finality on transactions within just a few seconds. So that is as close as possible to the performance of a centralized sequencer but we are able to scale to hundreds or thousands of nodes with very little performance degradation.

Now if anyone is familiar with um the cap theorem or computer science um in the consensus field um you might actually know that it is impossible to get both optimistic responsiveness and dynamic availability. Dynamic availability is sort of the other side of the same coin. Um, Ethereum has dynamic availability. What does that mean? That means that it's pretty much World War II resistant.

If say 90% of the Ethereum nodes were to go down suddenly, Ethereum would still keep going. Um, that that is the that is the benefit of Ethereum. That's why Ethereum is so neutral and so decentralized because it has this property. But of course, it has its downsides also, right? It cannot finalize transactions within just a few seconds.

So, there are always trade-offs. What we are building essentially is we are trying to build a consensus protocol that can scale to the security and the size and the decentralization of the Ethereum validator set but with completely different properties and with techniques like reststaking we're essentially able to basically use the same physical node set of Ethereum but provide this different property. So that's what we're targeting. As I mentioned, we're trying to um with hot shot, we're trying to target this property or with this tagline we call web 2 performance with web3 security. So in optimistic conditions like say when we have a CDN or we have a CDN like network we can have incredibly fast confirmations and extremely high throughput when the sun is shining but it's still robust when it's raining and certainly it does not allow any safety safety failures where a transaction is confirmed and then it's reverted.

That's the last thing we want because security is absolutely critical. So for Espresso, we've actually been on mainet since November. That being said, it's a permission mainet. Um it's run by um around a 100 nodes run by around 22 community and institutional validators. Um I believe some might actually be at the conference and uh we are actually transitioning to proof of stake later this year.

Um, in fact, last week we actually upgraded our longrunning test net decaf to proof of stake and that's looking quite nice and stable. So, we're very excited for that. Um, let let me just end up with how how a rollup or a chain could potentially use Espresso. As you can see, there are a lot of configurations. Espresso C the consistent thing is that Espresso provides fast confirmations to improve security and prevent reorg resistance and prevent reorgs.

So Espresso is really compatible with any execution environment, right? Any EVM, you know, ALVM, any app specific VM. You can use Espresso for DA. Remember, any chain provides DA. Data availability is a part of any blockchain.

But of course, you can use Celestio or anything else. You can keep your own sequencer if you're building a chain. That's very important to many chains to keep the priority fees to keep the sequencer revenue. Or you can even use Espresso as a decentralized sequencer. And you can settle to Ethereum, but you can also be a native uh you you know you can be a base rollup, you can you can you can be a valid you can do anything when it comes to settlement.

So it's extremely flexible really what we're trying to do is make very fast secure confirmations. Um so anyways that's what we're working on. I hope I've illuminated this very very critical issue with the thousands of chains that are coming up and we're working very very hard to solve it. So thank you. Thank you for your time.