High Performance Memory For The World Computer - Muriel Médard

[Music] All right, we're going to get ready for our next talk before lunch. So, please welcome Muriel to tell you all about high performance memory for the world computer. Give her a big round of applause.

Thank you very much. Uh, hi everyone. Uh, I'm Muriel Madard, Muriel Mid for the locals. uh and I'm co-founder and CEO of Optimum. Today I'm going to talk to you about high performance memory for the world computer.

We just heard a bit about the importance of being able to access memory and access information. So I think that this is basically in the same line. So um I have made the jump from academia into uh into this wonderful industry. Um and this is really a tech transfer from my group at MIT. Uh there I held the NEC chair in software science engineering for the entire school of engineering.

Uh and led uh been leading for uh over 20 years the network coding and relable communications group. Uh I'm an information theorist by trade like many academic founders in this uh in this field. Uh and I'd love to tell you now more about what we do and how we do it and why we do it. Okay, maybe just first a shout out to our backers. Uh we have been very fortunate to have an amazing set of backers for our seed fund.

Uh we had an announcement about that not too long ago uh led by 1KX. Um and so you know why did we get uh all these wonderful uh partners? Well, because we're looking at something which is effectively necessary for any sort of computation, often taken for granted, but is actually becoming increasingly critical. Um, and what do we mean by memory? By memory, what we mean is all sorts of propagation and access of memory.

So think of uh ephemeral memory like the bus uh in a computer and gossip in something like for instance uh Ethereum. Think of the read only memory that you would have in your computer. So you write to it but you don't modify you just read it which is basically the ledger uh along with of course uh the proto read uh aspect which is da uh data availability is basically not actually doing a full read just checking that you could do a read um that's our next u uh step optimum drom and finally is the current state and the current state in your computer that's the RAM that's the random access memory where you can check what's going on, read it, and then modify it, write it. That's the last step, the optimum DAM. So, these are effectively growing uh levels, if you will, of sophistication and managing the memory.

Okay. And why did I say that the memory is such a crucial part of any sort of computation? Well, I'll start at the middle. And this is basically what's often referred to as a vonoyment or the Princeton architecture uh really sort of codified at the end of World War II when people really thought okay you know we've had to build computers what are they well this is what they are they're machines they take an input they do something and they produce an output having done what they were supposed to do um and we think of the computer of course almost by its very name as just computing. But in order to compute, one of the things that Bonoyman knew deeply is you also need to have memory.

You cannot compute without memory. You cannot compute on nothing, right? And in order to do that, you need to have a memory unit and that memory unit needs to be able to be accessed both for reading and writing. So if we map that say to the web three stack if you like to think of it as the world computer what do you have you have the stuff up top the green stuff application execution settlement consensus say for instance an EVM and then all the applications running on effectively these operating systems and at the bottom you have the networking state data transaction data okay so if we look at the top the mapping. And if you've ever taken a class in computer systems, um, or just learned it by yourself, uh, you can pretty much recognize what's going on right now in web 3 and what's happening in a classical setting of a computer architecture as being very very connected.

Um if instead you look at what's happening towards the bottom there in the memory unit, it looks very ad hoc right like your computer doesn't have u a gossip it has a bus that's how it actually transmits and propagates information for instance um and of course the memory is is managed in a completely centralized way okay so you could say all right Muriel I get it doesn't look like what I did in class so what why do I care you know since when do I care It doesn't look like what I did in class. Well, if everything was going fine, we wouldn't. But what we know is that we have slow transactions because of low bandwidth. We're having massive storage cost and we're having trouble scaling. And of course, as you look at things such as increasing bop size and the challenges that come with that, you know, these sorts of scaling challenges are scaling in terms of uh size of transactions, in terms of number of transactions, in terms of number of nodes.

These are scaling challenges across all dimensions. All right. So our products basically map to that taxonomy I gave you of um what memory is. We start with optimum P2P and I'll show you more about it today and particularly you know show you some results from our test net um with really just increasing bandwidth and reducing latency. That's it.

You know it's it's a very very direct value proposition. then move on to uh the DROM and then move on to the DRM and the way we do this remember I I mentioned that this is tech transfer from from my lab uh what have I been working on for you know my entire career it's a technology which I'm going to tell you a little bit about which is random linear network coding uh that I co-invented and came from my lab okay um you're using coding that's great you know uh but so what what does it do let me start by showing you some performance benchmarks because you know effectively the proof is in the pudding um this comes from our test net and I'll tell you later our little bit about our fantastic test net partners so what you see here on the x-axis is the message size so basically think of larger messages is as basically the you know the current evolution particularly in Ethereum uh and on the y ais what you see is the average latency uh in uh in milliseconds. Now what you'd like to have is you'd like to have the average of course be as small as possible. You'd also like the variability which is the variance or the square root of the variance the standard deviation also to be as small as possible because you want the traffic basically to have low delay and also reliable delay. So what we see is a huge gain in the difference between Optimum P2P here which is in blue and Gossip sub which is in orange both in terms of the latency average and the latency standard deviation.

Now one of the things I'd like to point out is that you see a really nonlinear behavior here, right? you see a behavior where it's not proportional to the message size. And you may wonder, you know, why is that? You know, why why if I send you twice as much, then why isn't it just two times as slow? The reason for that is that there is a nonlinear behavior between delay and latency and uh and um total offered load.

So as I increase my message size, I'm increasing my offered load um I could be increasing it not by changing my message size but by increasing the number of requests right so if I simply increase the amount of traffic that's going through the system that will also uh create that sort of increase. So this is very nonlinear. This is something that's known um if you if you do queuing or if you do any sort of uh network analysis. And so it's makes for a very very steep problem with respect to basically overloading the system. This is exactly what we see on a day-to-day basis.

Um you are basically in traffic. There's no traffic jam. You feel everything's fine. And then you have that very narrow window where there's no traffic jam, but you're still going at the speed you want and you know that the traffic jam is coming, right? You know that it's coming.

And that's exactly what's happening there as that orange goes up. So basically what we do is we improve all the time, but we particularly improve when the system is extremely challenged. So, you know, those horrible gas fee spikes, you know, that's when this system's very challenged. And so, you'd like to see an improvement at all times and particularly when things are very bad. Uh, I told you that I would tell you a little bit about how we do this.

So, uh, let me get into that. So, what is RLNC? Randomly network coding. Um it's a way of doing combinations of any sort of data shard. And these data shards basically one of the things that's interesting about them and what we're using here is that they're not just items, atomic items that you carry around like they were apples or oranges.

They're numbers. They're, you know, living numbers. They live in a representation, an algebraic representation which you get to pick. And what we're doing in coding is we're creating equations in a particular way which allows it to be entirely decentralized. So, you know, here we are in France.

uh if you think it really most people uh uh assign and I I I'm with them uh sort of the the creation of this sort of mathematics with Evaristo Galwa the local uh local boy and he was a boy he died very very young unfortunately um we can see that you can choose a representation to make equations in such a way that those equations are actually giving you the solution when you get enough equations to recover the original data. So here I have five unknowns. If you give me five equations, unless those equations happen to not be independent, then I can recover the original data. Now the thing that's unique about our code is that you can create equations from equations. So I can be a node in the network that is not actually having access to the original data but I can recreate an equation which is a new equation which it didn't come from before.

I don't need to just forward on the equations that already existed. So this is very different from traditional codes you may have heard of like reach Solomon codes uh that are often used in uh data availability sampling or um or in things like uh Salana turbine or codes uh like fountain codes um for instance um uh used uh in in Raptorcast in Monad you know these codes can be composed so what that means is that you don't have a single entity that's creating the code forever and keeping it entirely fixed, you have a completely dynamic ad hoc code that is effectively composable forever. Okay, so all right, you have a good code that's nice. Then what? Well, what happens here is now anybody can benefit from having this much much faster uh much much faster propagation, right?

Everybody can benefit from the fact that you have much higher bandwidth that you have much lower latency. Remember that you know the bandwidth and the latency are basically just duels of each other, right? I can keep the same amount of traffic going uh and just have it more delayed or I can try to lower the amount of traffic and have it less delayed. And you can see that here very clearly, right? If I was worried about traffic, say on the orange in Gossip uh Gossip Sub, I could, you know, instead reduce my traffic by going to the left.

So, for instance, when people talk um about uh doing congestion control and say, "Oh, that's okay. I've got it. I've got congestion control." What congestion control is is actually lowering the throughput. So it's managing your delay by lowering the throughput, which of course you can do, but yeah, you know, you paid something for it.

You paid for it in lower de lower delay. If you really want to get the lowest delay, you know, you just get your throughput to zero. Okay, so basically you have that tradeoff right now. Um, and what we're doing here is changing completely changing, if you will, where those trade-off points are. If you kept going of course to larger and larger message sizes eventually yeah or more and more uh traffic you know every every system will will reach a strangle hold but we massively massively modify where that point is happening okay so everybody can benefit uh whether this be you know L1's and L2s whether these be validators whether these be dabs whether these be end users remember I I showed in particular the the behavior that you see when you have a very congested network.

That's really where end users will see that their system is not clogged up. That you're not going to end up, for instance, with horrible delays or really high gas fees. So, everyone here benefits. Who's benefiting first? Well, validators.

We went directly to validators. Um and the reason we've done this is because to some extent they were the folks who immediately saw the benefit of this for their APY right um I mean the calls were just wonderful calls super short you know you had all this really fancy uh well we had all this really fancy uh set of reasons why they should try us out and within like 10 minutes they're like yeah no we don't want to see the rest of your presentation we get it just give it to us. Um, so we've been very fortunate to work with this uh really fantastic group of uh of validators. Um, they've given us great feedback. They've tried it out.

And if you want to get their own take on how well this works, I encourage you to look at our recent press release from last week where um uh we actually spoke about this and the validators themselves went ahead and gave their own uh candid uh opinion of of um of how this is uh working out and of course they've been very very positive. Uh so with that uh we'd love to chat um in particular if you're interested in items uh around delay in items around uh throughput in any of the things that we've talked about today. We would love to talk to you uh anything to do with memory with propagation uh that's what we do. Um and you know I I'll leave you with the the the following that if you consider a computer uh it's not the same people who build the operating system and the people who build the CPU and the people who build the memory. It's actually different teams of engineers.

Um, and therefore I think it makes sense for there to be this mutual awareness and of course a lot of synergy but to have a little bit more specialization. And this is our specialization. This is what we've been working on and we're really excited to bring it to market. Thank you very much. [Music]