Seamless Horizontal Scalability: The Future of Ethereum

Transcript

[Music] Hello. Hi everyone. Uh I'm Prabal. I'm one of the co-founders of Aail. And uh today's topic is about you know the seamless horizontal scalability across the Ethereum ecosystem. I think uh the talk is pretty pertinent today right and uh although we see quite a number of rollups as of date I think uh you know almost 3 years back when we started working on the interrup piece of the avail stack we could already envision so many roll-ups being actually used in

production and we were thinking like you know how can we think of the solution from the grounds up what are the key uh necessary components to provide a seamless experience. What does horizontal scalability mean for a rollup ccentric world and how do we connect them all up in terms of scale in terms of interrupt in terms of security and from from then on we we went onto this journey of what we know as aail I think I don't need to convince you guys about this one right that the status quo right now that we have is extremely fragmented you can see a lot of these chains and you can see a I think this is only a few of them that we have been able to show

and every day we think about you know newer chains coming up and that is an amazing thing to happen inside the Ethereum ecosystem that is the designated way to scale blockchains every ecosystem of their uh of their own merit are are creating these uh healthy ecosystems of their own chains and a huge plethora of apps are getting built on each one of them and we are seeing innovation every day I think yesterday also So uh Robin Hood announced another L2. I think that is the way we are going to see this this blockchain industry evolve in the coming days.

But with that comes a lot of L2 L3 rollup however you want to define it and a lot of bridges. Right? If you think about how blockchains do talk to each other today it is a mess out there. uh depending on what kind of um you know solution you're looking at whether it's an L2 it's an L3 what kind of settlement layer uh what kind of ecosystem what kind of virtual machine what kind of compatibility with the existing tooling and and a host of the other features these rollups are different to one another and you know connecting homogeneous components together is easy connecting heterogeneous components together in a secure manner becomes

tough and that's where you see like a huge number of bridging solutions that are out there. Each one of them have been you know amazing for the ecosystem. They have been able to connect us uh and the connect the chains together. So we as users don't have to worry about you know how do we take the funds from one to other and so on. But with more chains becomes more liquidity fragmentation. When liquidity is spread across many different chains, the UX on top of it gets extremely complex. A DAP developer has to think about which applica which chain do I deploy on? What is the security of that? What are the tooling

of that? What is the developer support of that? But what is the kind of TVL of it? What kind of you know ecosystem is built around it? What are complimentary apps within the ecosystem that I can get support from and so on. And this kind of UX complexity leads to trust assumptions being added in terms of interrupt. So we see that you know sometimes the interrupt players are providing questionable security. Sometimes you know there are some heavy trust assumptions that we are taking when we are bridging funds from one to the other. This kind of interaction leads to weaker composibility and capital inefficiency. I don't need to convince you about that probably but when in a in a divided world where there are silos of you know security and interoperability

it it creates a lot of fragmentation which is the vicious cycle that we are in. This is what limits us today from you know being able to develop a economic flywheel within the Ethereum ecosystem. Level one this was level one this was how we did it and we are still doing it. This is a dominant way to connect chains together. This is the you know state verification based lock and mint type bridge. Again you may you know stay say that this is not always state verified. Sometimes it's events which are verifier etc etc. You can say it's not always lock and mint. There are other types of bridging protocols out there. But generally speaking the class is that I verify I lock it on one chain verify the locking on the other one and

then mint corresponding assets or corresponding wrapped assets. The second way is to basically abstract the bridge complexities. The first one is purely bridge specific. The second one is how do we abstract it out? We provide liquidity. I will come to this liquidity based approach a bit. But jumping ahead, there are the solverbased bridging approaches which are coming up right now which is essentially trying to abstract not only the bridges but actually it's trying to abstract chains from the users and that is the dominant way we are seeing this is more like a hybrid approach between the first two ones and that's what we are seeing more and more today I think this I already have kind of explained right so you have

something like an optimism and something like an arbitum take any two chains of your choice like it really really doesn't matter in this context but it matters a lot in terms of the security context when you go from L2s to between an L1 between two L1's between an L1 and an L2 all these things have various different meanings in different settings and they are not the same although we are being made to think that they are the same that when you talk to two different L2s uh on the same settlement layer layer and on the same DA layer they are the same as to talking to two different L1s which have vingly different security modules and consensus protocols and light client verifiability

and and so on they are not the same but this is the dominant one that we see right now this is the lock and mint protocol I cannot proceed to the next one yeah but this you know leads to this kind of a situation where there are huge number of wrapped assets lying all around. Every chain, every bridge does it in their own way. It creates a lot of problems. Be like I will I will also try to mention that it is not that no one is solving this problem. I think a lot of these guys have done an amazing job in creating something like an entity or an OFT or these kind of protocols which are

solving these kind of fragmentation issues across the board. But still the the situation is not that great. Liquidity based bridges easier right it's very simple you guys probably know it all you take a pool you have the funds you you cross it across two different chains you have a centralized manager you can decentralize it as well it is not that big of an issue the user submits fund onto one pool you listen to it you drop the corresponding funds this is again what is leading to it's a leading solution right now across the space it gets the job done it is The capital is needed up front. So someone is upfronting the capital on your behalf but it gets rebalanced on major corridor

corridors of fund transfer. This may work if it is birectional and such. When things get omnidirectional when things about the long tail of uh rollups that we talk about this doesn't solve the problem too much. It gets costlier. It gets capital inefficient for the LP provider. And we are seeing again and again a solverbased approach. What is it saying is that again no need to think about the entire flow here but as a user I want to do an action someone says I can fulfill your action I am saying okay I sign the attestation that if this action gets fulfilled then I'm going to pay you and then this happens across multiple different chains the solver is

doing the coordination and this is the simplistic view of how different solver-based applications work today. But in in reality, there's a lot going on inside these solvers. So we we tried to classify, we tried to think about it from the grounds up like okay, how does the solverbased protocols work? What are the different problems that they have? What are different solutions that they have come up with? Why are these solverbased techniques different from one another? If it is all that simple and that we are just doing this entire coordination bid, then what is so tough about it? Why is it that there are you know at least five players at and much much more really who are who are trying to solve this. We try to break this into

different parts. The first part is the statekeeper. Think of this as whoever is the orchestrator of the protocol. Now when we saw that who maintains the order you might think like okay there are two chains involved. So you need to you know do an action on one chain do another action on another chain and then just you know synchronize their views. It's not that simple right because depending on where you keep the state the protocol inherently becomes different. So there are things like like players like across who have done fantastic job in the space uh who are keeping the state onchain. So they keep all the states onchain and then uh have another parts I will come to it to coordinate between them. But

there are others who are keeping the state offchain. Keeping state offchain is actually a good and a bad thing. The good thing is that you do not need to pay gas fees in the initial opening of the bid. But the bad thing is you need to trust on that offchain entity for the for the security of this. Then there is an executor. The executor is basically think of it as the settlement layer. The settlement is whoever is you know providing the custody or saying the custody provider and the escrow what is the release rule of this entire protocol.

We have the state verifier. I am I know I'm talking about jargon at this point in time. Why do we need to classify it? But this is where the things get very interesting. How do you coordinate crosschain? This is one of the fundamental problems around which the entire interrupt hindrance starts, right? So you have states, you have states across two different chains. How do you synchronize the two? If you could have a a simple way to synchronize state across the plethora of rollups that we see today, I think it was a problem solved. The problem is that it is hard.

It is hard because every state tree is different. Some of the state trees have been modified in order to become ZK provable faster and so on. There is you know lack of EVM compatibility all across. There are now SVM rollups and you know other VMs very good ones which are coming up which have different way different optimizations in terms of readr efficiencies in in terms of merization of it and verification of it. So how do you coordinate crosschain and we saw that you know optimistic Oracle model is one of the more dominant ones out there. So what you do is you assume that it is correct you you take it in good faith that it is correct you go ahead if there is a problem someone

raises it we will see we will see by either social coordination or something else but that is the dominant protocol that you are doing today. So even when you are getting your funds up front there is a chance that there was a problem and you wouldn't know about it unless a time elapses and that's where we started digging right so we started digging that okay this status quo is not that good what can we do to make it trust minimized because what are blockchains if they are not trust minimized right so we think of you know rollups as verifiable servers and then if you do not have good coordination between verifiable servers then probably you're not doing that great uh being uh in a blockchain at all. So we started working on tees, we

started working on zkbased statistations and such and each of them has have their own trade-offs. I will not go into the trade-offs right now but happy to discuss it off stage to see like you know what are the different kinds of problems that we come here. The escrow bit is the most basic bit like it is the fundamental primitive which we use day in day out in blockchain protocols and it's it's just that someone needs to hold the funds someone they need to release the funds based on some logic who determines the logic the executor determines the logic the crosschain verifier fools the executor to determine the result on when the escro releases the funds but one main thing is that you cannot do it using EOS like it is

probably a very very bad strategy to do using EOS. Some people do that as well, but that's something that we wanted to avoid in all cases. And then of course we need the solvers. I think you guys know it a lot that there are offchain entities which are trying to fight among themselves to provide you the best rate to provide you the fastest way in and out of of chains and they are they are the you know they are the actual blood in inside this entire uh organism which is keeping all of this together. they are the main actors in the protocol and we we try to you know classify all of this and again I will be very very

honest this is not an exhaustive list there might be some of your favorite protocols which are missing who does interrupt in a solverbased mechanism but we haven't been able to cover it but to the to the point where we tried to cover if you can see like you know there are various ones and each one of them have done it you thinking about some trade-off. So none of this comes without a trade-off, right? If you think about a cross, they keep state onchain, they keep the executor offchain, but with an UMA based dispute resolution mechanism.

Their crosschain verification is again optimistic and the escrow is is essentially a part of the protocol. There are others who who keep this pluggable like you can make the escro part of the protocol, not it not make it part of protocol. You can use others. There are others who use something like an AVS or MPC for crosschain verification. We saw this and we thought that we need pessimistic proofs. We need attestation. We need better security guarantees in each one of these columns. And that's where we come up with aail nexus. The nexus aims to abstract all of this complexity. To be honest, I will show you in a bit that you don't need to remember any of this. All of this is

happening on the back end. We think of Nexus as a class of protocols which is trying to abstract all of this out. But what does it lead to? Uh leave me the jargon. Give me what the use case is. So I present you a demo about how aail nexus would feel like for the end user. I would ask someone to play the video here if they are there. Yes. So this is how AWE feels like when you don't have funds on that chain. So you go to another bridge, you go and you know deposit those assets, you do the

swap, you then do the bridging, you have those bridges, you have another funds on another chain, you take that, you swap that, you then go ahead and go to the uh a front end, you deposit USDC, you submit and this is all done, right? So this is the flow today. 23 clicks, almost 10 steps, three transactions. This is the status quo and this is what we are trying to build. We are trying to build that this will be a pluggable SDK integration on the front end which will take your assets from multiple different chains all in one or two clicks and it will go ahead and deposit it directly.

As a DAB developer, this is the use usability you want. You want three clicks. You want one transaction. You want full 7702 compatibility. You want to be as compliant to 7683 as you can be. And you want this entire intentbased framework to to work out without you having to care anything about it. So that's the Nexus SDK. That's what we are working hard on to solve the interoperability and the fragmentation issues of Ethereum and to provide a cohesive experience across the Ethereum ecosystem. No matter what kind of roll-ups you're using, if you're a developer, reach out to us, try out the SDK, let us know how you like. Thank

you. That's me. I think I have a minute left. If there is a question or something, only one question. validator set. Yeah, AI has its own validator set, but that's for the more of the DA layer that we have. So the base layer which provides you know blob space to rollups that has its own validator set. We have around 105 validators running today uh with one of the highest Nakamuro coefficients that are out there. So that is the validator set is there. On the Nexus side, we we

depend more on on ZK and T at a stations rather than validator based. That's the that's at least the the thinking on the on the on the state keeping and the state synchronization bit. If someone uses the same DAR for cross-ups then they can get much better guarantees in terms of interrupt. Yeah. So different chains have different kind of security models. So for example if you have a ZK rollup your source chain is a ZK rollup then you have a ZK proof of its state at station. But the same for optimistic rollup you do not have that right. So there we are using a TE based security. So what we are trying

to offer is we are trying to develop a class of protocols and offer the developer to choose what kind of security that they want because to be honest users don't care about security. They trust this application. They want to use that application and they want to actually integrate with it right and use that. The developer needs to do the trade-off analysis needs to choose what to till what security do they want to accept and according to that they can use it. I think I'm out of time but thank you [Music]