# The Age Of AGGREGATION

- Speakers: [Sandeep Nailwal](https://streameth.org/speakers/sandeep-nailwal)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-15
- Duration: 26:07
- Watch: https://streameth.org/watch/6736e8da1b0f83434d32eac5

## Description

Aggregation plays a critical role in enhancing the usability and scalability of blockchain technology. In this session, we will explore the fundamental concepts of aggregation, debunk common myths, and discuss the necessity of aggregated blockchain systems for achieving real-world usage. Current scalability boundaries limit blockchain's potential, but through aggregation, we can optimize performance and usability, making blockchain technology accessible to a broader audience

## About the speakers

### Sandeep Nailwal

Sandeep Nailwal is one of the founders of the Polygon network and currently serves as the executive chairman of Polygon Labs, an international software development company that builds blockchain scaling infrastructure. In this capacity, his role along with other co-founders is to steward the long-term sustainability growth of the Polygon protocol and ecosystem, and oversee the strategic priorities of Polygon Labs, where he works closely with Marc Boiron, CEO of Polygon Labs


## Transcript

of Polygon Labs. For those of you who don't know Polygon Labs, or specifically who don't know what Polygon Labs does, because we do many things, we are core contributor to the AgLayer along with many others. We've also developed multiple blockchains being Polygon POS that pretty much everyone knows, as well as Polygon ZKVM. So I'm going to go through a little bit of history before actually attacking what exactly we mean by aggregation, and specifically what I want to look at. And people talk a lot about not looking at analogies, but if we think of what we want Web 3 to be, we really want it to eat as much of Web 2 up as possible. We should be able to scale Web 3 to the size of Web 2. And so the question then becomes, well, how did the Internet become the Internet? And if you think about it, the Internet actually started very fragmented. It was very disconnected with multiple networks, unable to communicate. And then new protocols came along. And specifically, things like TCP, IP came along. And what you suddenly had was this diversity in what could be built on the internet and the infrastructure underlying it, but with some common protocols. And specifically what you get there is TCP IP. And it's very important to actually understand this because a lot of people say, like, how are we going to bring together all of Web 3 when you've got so much disparate technology in Web3? You've got different stacks, you've got different VMs, like, everything looks different. But we actually have an example of bringing together different technology in a way that, like, unifies it and actually feels like one. So let's talk about, like, specific problems we see in Web3 and why this is actually very relevant. We've got fragmentation as an issue. I think this is an obvious one for everyone. Scalability, security, and frankly, just poor UX. If we look at each of these one by one, what do we have right now? We've got a bunch of chains, and liquidity is fragmented across all of these chains. We really have no good way of bringing them together at all. Similarly, we've got a scalability problem. If we want Web3 to scale to the size of the internet, then we should probably compare to what currently is using the internet. And when we look at that, what we see things is MasterCard, Visa, Nasdaq. And I do not believe we actually have a network that can handle the load of any of those. I think we've heard many state that they want blockchains to be able to handle, you know, a load like Nasdaq. And that is 250,000 transactions per second, which no network is even close to being able to handle in any way whatsoever. I actually just as a little side note, I'll give you a few side notes during this presentation, but this is a little interesting fact is let's just assume that we could actually scale a blockchain to the size of Nasdaq. Nasdaq can execute transactions with a latency of 50 microseconds. You are not going to execute any transaction on a blockchain in 50 microseconds. So I think our dreams of bringing Nasdaq on-chain should probably recognize the fact that there's some things that are actually better in a centralized state, and there's some things that are better in a decentralized state. Obviously, this does not mean that we don't want decentralized exchanges. It means that there's specific technologies that serve specific purposes, and we should probably focus on more long-tail assets in a decentralized way when we want perfect performance execution. And then when we just want censorship resistance, then we should probably bring that on chain. Third one is security. Right now, when you look at many different networks and how they come together, we talk about concepts like shared sequencers and intents and bridges, and most of that is not actually very secure, even though it actually works decently in some cases. And lastly, the UX challenge. We've got a UX problem, whether it's across wallets, bridges and intents, chains. Basically, what you get is this fragmented feeling across the board. And so then the question becomes, what do you do about this? And the first answer that we tried to give, or many do still give is let's just use a monolithic chain Solana can solve this for you because something something something well, you know most of the time that something isn't going to be good enough because Literally we have seen that we can't even scale to some of the the smallest Networks that are good for payments in the world or the biggest ones. And so the idea that we're going to throw everything on one chain is not happening. And so we need to go look at another solution. The other solution was, why don't we just scale through modular chains, right? But the problem is modular chains increase fragmentation. We see it today. You've got, you know, Polygon ZKVM, Polygon POS. You've got ZK Sync Era. You've got, you know, Arbitrum 1. You've got OpenMainnet. You could keep going on and on. And, like, great, this is nice. Like, being able to choose how you want to spin up a chain is great. It actually solves the scalability issue, right? Because now when you need more block space, what do you do? You spin up a new chain. And with time, this is actually going to get easier and easier, right? Like right now, people want to sell you on the idea that spinning up a new chain is easy. Like frankly, it's actually not that easy. But if you fast forward 12 months from now and 24 months from now and 36 months from now, you're going to get to a point where spinning up a new chain is actually incredibly easy. And when you need to increase throughput and increase block space, then you're going to spin up a new chain to actually be able to do that. And so through kind of the modular approach, we can actually solve scalability. The problem is we still don't have one unified Web3 if we do that. And so the answer to this is just aggregate all the chains. And so what does aggregation actually allow for? It actually allows us to scale Web3 to the size of the internet. What are the things that we need to do this? First, we need practically infinite scalability. And that's what you get when you can spin up new chains very easily when more demand is needed. Because there's... When there is more demand, and so more block space is needed. And then the second one is you need to be able to unify state liquidity users. And if you really think of the North Star of what we should be targeting, we should really want to be able to have a Web3 and an Ethereum that scales as much as you need in a unified way, making you believe that you are using one chain while you are using 100,000 different chains at any point in time, and that that 100,000 chains can become 125,000 chains at any point in time, and it still feels like one internet. So when we've thought about this problem and how we want to solve this problem exactly, we started thinking about it and we realized that we needed to create a neutral platform. And so, this is the concept of the Ag layer. Polygon Labs is a core contributor, along with many others that I will show you a little bit later. But the general idea was that we need some kind of neutral cross-chain settlement platform that unifies liquidity users in state, and that ultimately has finality on Ethereum. Now, very importantly, the AgLayer is actually not intended to scale only Ethereum. And there's a reason for this, which is that as amazing as Ethereum is, what do people actually value in Web3? They value assets. And there's always going to be assets outside of Ethereum. And we need to be able to get people to come to Ethereum and stay on Ethereum. And the only way to do that is to allow them to use or to receive or send assets to another chain that is not Ethereum. And the only way to do that is to aggregate those chains along with Ethereum and all chains on them. And so that is a big part of kind of the AgL layer is really bringing everything together and ultimately having finality on Ethereum. Maybe let me talk to you about kind of like the different components of the Ag layer. Really think about it in like four different parts. A lot of times when people hear the Ag layer or anything that has to do with interoperability, they immediately default to it's a bridge. And it's nothing but a bridge. And this is simply because when we think of the forms of interoperability that we have had to go cross-chain over the last many years, we default to bridges. Layer zeros, the wormholes, things like that. And then more recently, people start thinking of cross-chain transactions as being things driven by intents. But people don't really think holistically about everything that you need to get safety when there's a fragmented Web3 that you want to bring together. So let me talk through these four different components of the ag layer. First one is the pessimistic proof. So the most important thing, if you want to bring chains together, is to ensure that no one chain can rug another chain. Right? Like, if I have gone to a chain, I have decided this is a chain that I trust. Or like many, frankly, haven't paid attention, but I'm still assuming trust on that chain. And when I send a transaction cross-chain or I'm receiving an asset from another chain, I need to be 100% sure that the only thing I am trusting is that chain that I am on. And this is basically what the pessimistic proof does. What it does is it looks at all assets that come into a chain. It looks at all assets that are leaving a chain. And we call this chain level accounting. And basically what the pessimistic proof does, it then ensures that when an asset wants to leave a chain, it is not an asset that is in excess of any assets that have come into it. So if you've had, you know had 10 ETH come into a chain, then you can't have more than 10 ETH leave that chain. And this is what the pessimistic proof enforces. Now, the interesting thing about this pessimistic proof is that it is not just enforcing this for chains that have proofs. So a lot of times people think, okay, the ag layer or anything that Polygon is working on requires ZK technology. So you look at Polygon ZK VM or X layer and you're like, hey, this uses execution proofs. And so the ag layer requires execution proofs. The reality is the ag layer is actually completely agnostic to that. You could have execution proofs, you could have fraud proofs, you can have some form of consensus that can be proven, or you can straight up have a database. Pessimistic proof doesn't care. It's going to look at what assets came in, what assets have left, and whether an asset that wants to leave or be removed from there can. And so that's kind of like the guarantee you get with pessimistic proof, is that regardless of what it chain, like the form of a chain, you can prove facts about that chain. And specifically on something like a Polygon POS that has a validator set, you can prove the consensus of Polygon POS so that you can confidently actually have transactions go cross-chain. Next one is proof aggregation. A lot of people think the proof aggregation is what allows the interoperability in the AgLayer. All proof aggregation does is it lowers the cost of transacting on chains connected to the AgLayer and using the AgLayer. Specifically what it does is you get a ZK proof, and this could be the pessimistic proof or it could be an execution proof on a chain. And what it does is it wraps those proofs together and then wraps those proofs together and then wraps those proofs together and then submits them to Ethereum. If you were to submit each of those proofs to Ethereum on their own, it would be incredibly expensive. And so this is how you're able to lower the cost so that it is incredibly cheap to execute these cross-chain transactions. Next thing is there's a unified bridge. This is a bridge on Ethereum, and that bridge is the bridge used to create canonical assets. That allows for all transactions going across the ag layer to be done in fungible assets, meaning that you don't have wrapped assets and then unwrapped assets. And then lastly, there's this concept of fast interrupt. The ag layer with nothing else going between two chains, especially two L2s, is going to settle at the speed of Ethereum settlement, and so we're going to be looking at 15-minute cross-chain transactions, which isn't good enough. And so the goal with fast interrupt is to lower that latency to just a few seconds rather than minutes So like what are the benefits of this? First of all is you get these native tokens Look, I think cosmos has done many correct things. But when you go when you use cosmos the experience of having many, many unwrapped tokens and moving those around and figuring out what these assets are, and the same has become true within the Ethereum ecosystem as well, that is not a good user experience. Second is we need safe cross-chain transactions. As of right now, when we use bridges that we use, most of the time these are not actually very safe for interoperability, and we actually need something to add safety. Sometimes we talk about shared sequencers as providing atomic composability. Again, you need something to actually make that safe and trustless. And importantly, this is where you get the concept of compatibility. The ag layer often is viewed as competitive with all of these different options that people hear about for interoperability purposes. But it actually really isn't. It's a very low-level base layer that is compatible with most of these. So if you want to do an asynchronous transaction, you use the ag layer. But if you want a synchronous transaction, then you would actually use a shared sequencer with the added security of the AgLayer. If you want to use intents, those are expensive. They require capital in two different pools. You need to rebalance that capital. Rebalancing that capital has risk and time associated with it. You can lower that risk and time, allowing for rebalancing much quicker, allowing for users to get transactions at a cheaper cost. And so good experience there. And so the goal when we're thinking about building the AgLayer with the other contributors is really like how do we make this the best experience possible? And that includes from a cost perspective when working with other solutions out there. Next, like the AgLayer, if you think about it, is really like an asset-first protocol. You're actually passing assets from one chain to another. And this is different from other interoperability solutions that are generally passing messages. But the AgLayer does allow for passing messages as well, which is necessary and something that can be done. Next is it actually enables the concept of, like, chain abstraction. I think chain abstraction is a very nebulous concept that if you ask 10 people what is chain abstraction, 10 people will give you different answers. The way that I often think about it is like the Ag layer allows for easy use of chain abstraction. And like one example of this is a library that we've built that we refer to as Bridge and Call. And so this is a library that allows for users to basically execute one transaction themselves, but they're actually executing multiple transactions across chains. So imagine that you wanted to bridge funds from Ethereum to Polygon, ZKVM, and then you wanted to swap those assets into different assets and then transfer them over to X layer and then buy an NFT. With the bridge and call function, you can do that. And so you can imagine a wallet that abstracts that all the way and basically says, hey, do you want to do this bridge transfer and then this swap and then transfer it and then buy this NFT, click one button and it swap, and then transfer it, and then buy this NFT, click one button, and it's calling multiple functions in the background, and you've abstracted away the entire kind of cross-chain experience. And then lastly, it provides for this low interoperability, low latency in terms of these cross-chain transactions. Again, it doesn't provide synchronous interoperability. That's something that by working with shared sequencers secured by the AgLayer, you can receive, but it's not something that the AgLayer gives natively. This is the AgLayer ecosystem, multiple contributors. We're always looking to work with more folks on this. One thing you'll notice is the AgLayer is not called the Polygon AgLayer. This is very intentional. We've talked to every big team in the Ethereum ecosystem and most outside of it. The goal is to get everybody to contribute so that we can have a non-fragmented Web3 as a whole, allowing for Ethereum to grow and be used without actually needing to leave Ethereum. A very important point is that AgLayer is not rent-seeking. If you look at a lot of different interoperability solutions and a lot of different other ecosystems building out interoperability, what you end up seeing is some form of fee that is placed on every transaction. And it really looks like a middleman form of rent seeking. The AgLayer has no fee for joining the AgLayer. There's actually no fee per transaction on the AgLayer. Instead, what it is is that chains are going to create with as many transactions as they can include in their consensus or that's part of the consensus being satisfied or as part of an execution proof, and they're going to submit that to the AgLayer. They could choose to submit that once a month. They could choose to submit that every two seconds. They get to choose how often they actually want to submit a proof to the AgLayer. And that allows for chains to continue to remain sovereign. For example, you could think of like a gaming chain. Gaming chain is going to say, hey, our users don't actually care how often we finalize this chain, or they're going to accept lower security requirements for some period of time. And so we're going to submit proofs much less frequently than like a DeFi chain that's going to say, hey, I want to submit proofs every two seconds. And so by having this flexibility in the ag layer, it allows for people to be able to execute these transactions basically freely. And so basically what we see here is that we've solved fragmented liquidity. You've got fungible assets across the ecosystem. You've solved scalability because you have chains that can be spun up at any point in time. You've solved security with the pessimistic proofs that you can safely go between chains. And you've solved the UX issue because you can now seamlessly interoperate between these chains with some of the greatest technologies around shared sequencing and intents that are going to be part of this. And what you end up with is really a unified kind of Web3 allowing for users to stay in Ethereum, benefit from assets across every ecosystem. And what you see is a Web3 that ends up actually being united under some common protocol. Thank you. Thank you, Mark. That was quite insightful. We do have a few questions here. So who will aggregate the aggregators? That's a good question. I don't know. We see this all the time, of course. I have not been able to have anyone point to me to another team that is actually trying to aggregate all of Web3. And so there is nothing that prevents the Ag layer from being connected to a chain in the super chain. You will actually see that happen. There is nothing that prevents the Ag layer from being connected to a chain on the elastic chain. There is nothing that prevents it from connecting to an orbit chain. And so given that it's a low- level solution, you can call it the aggregator of aggregators. And so that's what the Agilera provides. All right. And what is the difference with CCIP? Yeah, that's a good question. So I would think of CCIP more on the messaging side of things than on the asset transfer side of things. And so specifically, like when you think about the bridges that I was referring to, that's kind of what currently exists is CCIP. One of the things that we're actually working on right now on the Ag layer is trying to bring kind of bridge standards within the Ag layer. There's actually nothing that prevents the AgLayer from using some of the bridge standards that we currently see and adding to it a level of security that currently doesn't actually exist. And so the goal is actually to work with something like CCIP rather than compete with it. All right. Where does AgLayer run and who are the actors? Yeah, that's a good question. So the AgLayer is going to be live in three to four weeks. And in its initial form, it's run in a centralized way. The nice thing, though, is that with ZK technology, you can be running a centralized system in a trustless manner. And that's kind of what the AgLayer is going to look like in its initial form. But I fundamentally believe that notwithstanding how centralized we're seeing everything in the space right now, pretty much everything is going to decentralize. And this is either going to happen because it's going to be forced by some government actors in some way, or it's going to happen because critical issues are going to happen in centralized systems, and we're all going to be reminded why it is that we actually have decentralized systems. And so our goal, and it's on the roadmap, and it's actually a lot of work that's already being done, is to decentralize the Agilator and not keep it in a centralized form. All right. Is there any hope of optimistic networks to get aggregated into the Ag layer? Their optimistic nature, that is waiting periods, etc., seems to be fundamentally incompatible with composability. Yes. This is a good question and something we've spent a lot of time about. So I got two answers for you on that. Answer number one is all optimistic roll-ups will be ZK roll-ups. It's just a matter of time. Everybody knows it. All optimistic roll-ups are working on that already. It's just a question of time. And that, frankly, is what will create the ideal user experience. Another alternative would be to actually just prove the fraud proof. Okay, that's the exact question. Like, you can't wait seven days to go cross-train. That's horrible. But what I was also saying is that we don't just need to prove proofs. We can prove other things. For example, you know, the centralized sequencers that we have right now do reach consensus in a centralized way, and you can actually prove that consensus using the pessimistic proof. That's why I was saying that even in this current state where you've got fraud proofs on chains, that we will still see them on the Ag layer because we can protect against the risk of anything happening within the fraud-proof window using the pessimistic proof. All right. We only have time for one more question. Is my understanding correct that existing L2s need to migrate over all their asset strings in their native bridges to the unified bridge? Yeah, that is a very good question. It's something we spend a lot of time on. So I would say there's the ideal state and there's the less the ideal state. As I've mentioned a few times, we can currently connect any existing chain and you will see existing chains get connected without migrating assets over to the Ag layer. And what will happen when that happens is basically you'll start issuing new assets on that new canonical bridge being the AgLayer bridge. For any chains that want the what I'll call ideal user experience, you would actually want to have them migrate all the assets over. This is actually something that you will see happening with Polygon POS. We have 6,500 or so assets on Polygon POS. They will all get migrated over to the unified bridge. And therefore, we're going to be the first example of probably one of the biggest chains, definitely the biggest chain in the world from an assets perspective, actually migrating all of those assets over. All right. Thank you again so much. Can we get a round of applause for Mark, please?