The 'Petabyte Chain' and how to survive it

Transcript

Hi. Uh, I'm Mark Halt. I'm a um I'm a uh developer on Aragon, which is one of the Ethereum clients. Now, Aragon's kind of since it existed has always been uh aimed at worrying about data and the data in the chain. And what makes us different from other clients is that generally we store everything. Now this year has been an interesting year for us because in in a in a lot of ways we haven't really cared about storage this year and that's because kind of beginning of the year we got a bit of a shock where we discovered that as

Ethereum is going to scale to Gigas and Glamsterdam's coming on board were actually the slowest client. So a lot of our work this year has been just speeding our core execution speed up. Um but while we've been doing that, we've been considering well what does this mean for our client and what does this mean in general um when we're when we're processing all this much data. Um so with the process of seeing how fast we got we started doing experiments and saying well if we if we looked at the projected rates that we're going to be able to execute at and we project that forward into the future what does this actually look like for storage? because

basically we're going to have to worry about the storage problem at some point and the question is do we need to worry about it now or at some point in the future and essentially what you can see from these projections is essentially if the if the f if the chain is successful and grows at some point it's going to kind of change the basis on which nodes operate because there's really going to be no economic way in that you can essentially put all of the storage on one machine. Um, and the operating model for um for Ethereum nodes is you've got a pool of nodes across the network and they

theoretically can all handle all of the data. Now in practice that's that's even now that's not true in practice. Um but looking at the engineering problem is we're kind of saying well okay at some point this is going to be the case that it's not not an option there won't be a single machine uh model and then the the thought process becomes okay well what do we do about that and I think there are you know debates in the community about what you do and and and there and there's there's two things right you can either avoid it you can do things like saying, well, let's invent state expiry, which throws all the

storage away. We can price for it. We can make it so expensive that nobody puts storage onto the chain. Um, or the alternative is to say, well, actually, let's see if we can at an engineering level deal with this. Is it is it is it is it really a a problem that um needs to be solved? and and effectively the the conclusion that we've got because we've been basically doing this for quite a while is well if the data grows beyond a node we'll just distribute it basically. So what what we've begun to do and this is partly in in the world of AI this is doable because you can do two or three things along the side of your normal work that

are actually really quite complicated asking complicated engineering questions. So we started the thought experiment of saying well if we assume that we're going to have a chain what do we do to engineer for this as a as an engineering solution. Um I think the other thing is if you look at the first slide you can see that it's not really a problem for today in practice. It may not be a problem for 2 three four years. It's going to it's it's kind of years away before this becomes a um existential problem for the for for the chain. It's also fairly well understood. I mean distributing data across the internet and delivering it to clients has been done in a whole set of

other computing environments already. So the solutions are really out there out there already. Um the problem with it is and we kind of know this from experience when we when we started migrating from our original model which was a database just to data on disks and distributing those things what what happens is you create a whole set of unexpected errors that you need to test for. So although problems may be years away, if we look at our experience with Aragon, it basically took us to get our archive node tuned and usable, it was probably a three or four year

development effort, not with lots of people, but with lots of testing because there's there's a there's a fundamental issue as as as the chain grows. If you want to distribute data either to a disk and go disk to memory or to a network, you've effectively got to test all the edge cases to know that you're not going to create a breaking chain. And that testing process is just um has two features. It's kind of it takes a long time and it's fairly tedious because you're constantly actually testing a lot of success cases until you actually end up working out how to break something.

Now I think what we found this year is because of the AI tools available now that the process of trying to scale this up and break it is now achievable with a relatively small team of people and not a lot of testing resource but it's still going to take quite a long time to do simply because the time to distribute data is is is kind of not something you can squeeze. Um so what else we've done this year is we've done a bit of prototyping to say well if we were going to solve this problem actually most of the pieces already exist in Aragon and we can just try and put some prototypes to put them

together and to see whether they work and effectively that work has ended up being two separate streams of work. One is kind of solving the problem of if you've got lot a lot of um machines on the network, you need to find a way of um distributing the description of the network to all of the machines so that they can agree with each other and deliver consistent data. So this is a kind of um a repeat of the consensus process that exists um in in in effective the real-time chain in that essentially what you're what you're wanting to do is to get um a series of

nodes that have got a partial view of the world and get them to agree with each other that they all have got the same view of the world so that effectively any of them can service the data. Um now without going into the details pretty much Aragon does this at the moment for kind of our internal distribution mechanism and what we've done is we've taken that as a model and worked out can we make this more canonical i.e. can we turn this into something that can be proved across the network and isn't just proprietary to our to to our own product. Um the other thing we've looked at doing which is the other side of this is it's all it's all very well distributing the data across

the network but actually what you need to be able to do in order to do something useful with it is get it back in time in order to in order to service a user. Um so we've run another experiment which is to create a federated RPC server. And what what this is is using our distribution model working with a set of machines and rather than the way things work at the moment typically which is if you if if you call an RPC interface on a node it will resolve that data on that machine and depending on which client you're using and how it's configured at your the RPC provider it's got a number of optimizations that basically get you the data back fast enough and scale with the

number of users they've got. What we've done with the federated RPC model is to basically say let's try and do this with a node that's got virtually no data on it and the data is distributed across the network and ask the question the two questions is one does it work at all and the other question is does it work fast enough to be a reasonable proxy for the way existing RPCs are used. Um, and then the other thing that we basically need to think a bit more about is interoperability because this is all very well delivering this in kind of an Aragon experiment, but if it's going to work at a Ethereum network level, we're going to end up eventually having to

work out how to make this interoperable between us and other clients. Um, so that's basically work that's been going on in the background to our mainline activity. Um and essentially one of the things that our um experiments have shown us because we've done various bits of configuration is as well as distributing the data um our experiments also point to a thing that actually nodes are likely to change in this model because what they're doing is changing. Um and they become kind of more split into three separate things which is the process that validates and builds blocks and um processes consensus

and actually also um builds RPC responses. That's one bit of the node and it can probably run as a as a separate process. Um the other thing is holding the data and in aworked environment lots of nodes hold the data for other nodes. So that's now a kind of new feature. Now if you're holding data and distributing data you don't necessarily have to worry about the consensus. Um, and we go back to the original slide is you care about the archive consensus, but that's kind of operating at a slower beat than uh than than the mainline blocks, but actually it means you can become simpler. You can

just be concerned with holding holding and returning data. Um, and then the third type of node is the node that's just answering questions and it's actually answering questions and directing them to other nodes on the network. Um now that actually is not particularly new. If you look at the way that um if you look at the way nodes work, we already have archive nodes, full nodes and you know with an Aragon we've we even got a thing called a minimal node which has got even less data. So the difference I think the operating difference in this in this model is not necessarily what the nodes exist do at the moment is essentially that we're

likely to add to them a new class of kind of lighter nodes that actually do less because really they probably execute they may or may not deal with um RPC responses um and they probably don't hold that much data because if you can rely on the network to deliver the data you need and you can scale yourself, you don't need to do it yourself. So you can do a whole load of other stuff. And you know to put that into context and this clearly might change once we get to the gigas world at the moment a typical execution client

takes you know in a 12-cond slot it kind of on average on mainet at the moment it takes uh you know we're kind of one of the slower clients so there are people who are a lot faster than us it's taking us kind of 60 milliseconds to process the block. So if you think about that, you're sitting there for 12 seconds and you're spending 60 milliseconds doing work um essentially. So there are likely to be, you know, you've got a very lightly loaded client that doesn't have a massive footprint, which is a kind of new kind of thing.

And one of the things that we started doing when we played with that is said, well, hey, there's there's there's things you can do this because you basically got free capacity, but what you've got in your node is direct access to the um to the um to the operations of the nodes. So we started saying well in this in this light multi-purpose node space, what else can we do? Um so we've basically built a node on Aragon and we've got a sister project now that kind of pushes to take this further called cocoon where we've effectively got a node as a container for chains. So we've got a multi-purpose node that is operating two or three chains. So it's

essentially um typically a a mainet chain and a couple of roll-ups, a couple of custom rollups and they're just sitting inside one operating node. But even with that, the processing load is relatively low. So we've also said well actually what's interesting about this is um we can also start doing other things. So we've started building application functionality into that node as well. So um this node I'm showing you here is something that we have running that's operating an experimental darkpool that we're delivering and effectively the UI for the darkpool the darkpool um service provision in the node the the L2 that it operates and the L1 that it connects to

are all running in a single node which means basically you've got a far simpler packaging process. So we we think this is a a kind of new way of operating that's a sort of interesting thing will happen. So it's and and it's odd because like as you get um as you get more data around the network you can also get um more flexible more usable nodes which I think will have a kind of significant um benefit for a set of um a set of users. So I just want to spend the last um few minutes I've got just talking a bit about okay well if you've engineered for this storage and you storage model and

you're successful and you've got flexible nodes what else becomes possible um and I think the thing is to think about this is that or where we're thinking about it is actually you you've got a new class of app with a new case class of user where you know rather than using validators externally to validate your what you've got calling an RPC provider what you begin to do is think about running an app server that runs the chain for you and gives you your services. So, um, essentially this is a this is a lot closer to the way web two works, right?

Where effectively what you're going to do if you deliver an application basically is run it up on an app server that you manage and control and it just connects to the to the rest of the network without having to do everything through third party services. And this sort of changes the the the operating model for the node. Um, and so what are the things if we're doing that can we do? I mean, I think one of the things that becomes a lot easier to manage if you've got a node configured like this is privacy and data sovereignty. So that um that example I gave you earlier which was a darkpool it's effectively using zero knowledge proofs to provide an

execution platform that for its users all the data is is hidden until the point where it settles. And in order to do that, the nodes that are operating the dark pool are connected to the chain and it um and it controls what they're doing, but they're also holding a significant amount of private data for the users, which which are the users's assets. And it's also providing um additional data that effectively operates out of the node um and is a lot closer to onchain data because it actually all happens in one place. And what what it means you begin to do is if if you close

these two gaps, you stop being a guest in your own account and your own data. I.e. you've got you you've architected something that's got accounts and account data and code that running on the chain, but everything that you do from a user perspective is basically arbitrated through that chain. At this point now, you've got a node where you own your data and what you do is provide proof to the chain and basically um you control what you do.

Um now the thing about that is that's been possible for a while but actually the downside of that if you have everything in private data and you've not got a chain connection you essentially have got a separate architecture. Now, I think what's interesting about what's happening in the um in the the Ethereum overall space at the moment and the presentation before me about frames is kind of part of the move to make the um Ethereum mainet more flexible and more programmable. Um, and with those kind of things, you can basically begin to more tightly integrate the the private data

that you're holding in in in your node and the um and the model that you're using for programming it. The other thing that you can do if we've scaled data to a pabyte level for the onchain data, it becomes possible for us to use exactly the same technique as that to basically take any of that private data and hold it effectively onchain. Um, and the other thing that's h that that would mean which is also happening in the kind of core development space at the moment is thinking about data type extensions for Ethereum itself. So frames are extending the way um transactions can be um used on chain.

There's a kind of a parallel path which is a bit behind it at the moment but is thinking about actually making the data types the chain contains more flexible and essentially with the scaling that we're doing um those things play together to make this node that I've just described more possible. Um so just to finish up get back to where we started which is we we're going to have a data problem um you know there are two solutions to that is one scale the promise to make sure you can deliver to it but also there's a change equation which is actually in doing this we might be able to change kind of a lot of the

features and a lot of the ways that the network works. Um, and that's kind of from our point of view is kind of a really interesting jump off point for what could happen in the future. And I think with that I'm finished. Thank you for the presentation. I think we can take some questions now. Um >> so the first question if I interpret it correctly is >> um we talk about this gig gas >> um >> why do we think that as we increase the supply there's going to be demand that would capture it especially on L1

>> well I think that's an interesting question I mean it's kind of when I said this is an engineering solution I mean essentially I think that's I think you know we don't know right we don't know that we we deliver all of this um all of this scale which is actually really driven by a competition with other chains. I mean the the kind of other outcome which is why the stuff we're doing is an experiment is we create all this scale nobody uses it right and at that point we don't have this problem >> so um I'm not saying that it's going to happen I'm saying if it happens um you know we need to deal with it but what I would also say has come out of our um

our uh the stuff that we've doing is I think I stuff won't move onto the L1 unless it's actually more flexible, more programmable. Um, essentially, which is why I think actually thinking about a new node and new more flexible node is beginning to think about how do we connect with app developers and users so they actually use the chain because otherwise we will have all this capacity that nobody uses. >> Mhm. >> Okay. >> Yeah. Um, >> so the next question is, do you think the Solana model of uh data storage can help people own their data?

>> Well, it depends what you mean by you mean the model of not storing data because I mean basically um if you think about this in the Salana context, what we're talking about here is, you know, we're talking about the whole history of the chain. So in in Salana that's basically what the node operators are running plus the big table that it's got stored with all the rest rest of the history on it. So um I think I think Salana and most chains at the moment don't really address the you know how do you own how do you own your data because to own your data it needs to be owned by you and accessible by you and not actually on the chain.

the the chain maybe needs to back it up, but it doesn't need to interate intermediate in the data. If it's private, you've got to prove that it's private and prove it's accessible, but you don't need to put it on chain. >> Okay, we have couple of minutes for questions. Uh feel free to add more questions. In the meantime, I have a question. Um so what changes do you think uh the plan um would need if uh L2s were to scale use the similar things that you proposed for L1 for the gas >> right so I mean one of the reasons we're doing this development is we're also

developing L2 technology and so so one of the outcomes is we use what we've got for delivering data scaled L2s. So essentially there's nothing in this that is basically I'm talking about what happens to a node and if a node can run L1 L2 it's kind of um it's not about which chain you're on it's about how much data does the chain have. Okay. Um and you know to some extent part of our focus as a as as a development team is building L2 technology that includes privacy and CK proofs. Um and these two we see as kind of symbiotic with each other.

>> Okay. So we have time for one more question. So with the lower block time postquantum signatures and all the interesting stuff that's happening well so everything that's going on at the moment is going to make state bigger which is why we're as an engineering team worrying about the problem because there's nothing there's nothing in the development apart from the fact users stop using the chain that's going to make data smaller. Um, so what we're trying to do is work out if state grows, can we engineer a solution that means in 10 years time we've got a viable platform.

>> Okay. Yeah. Um,