00:05: Anna Rose: Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. 00:27: This week, I chat with Omer and Yuval from Ingonyama. We cover the foundation of the company, how Ingonyama aims to tackle the ZK hardware space, and the role ZK hardware acceleration has in the larger ZK story. We also discuss what the hardware product cycle looks like, how a ZK ASIC is made, the algorithmic component in ZK hardware, some of the research coming out of Ingonyama, and more. Quick disclosure, I'm an investor in the project via ZKV, so very excited to catch up on their work. Now before we kick off, I wanted to highlight the ZK jobs board for you. There you can find jobs from top teams working in ZK. So if you're looking for your next opportunity in the space, be sure to check it out. And if you're a team looking to find great talent, be sure to add your job there as well. We also have our upcoming ZK Summit event to look out for. It's happening in Athens on April 10th. The event is shaping up. We've been adding speakers to the website and we'll share the schedule there soon. As always, this is invite only and space is limited. There is an application process and you need to apply to be eligible for a ticket. If you've already received an invite to buy your ticket, be sure to secure it. We expect the event to sell out. I've added the link in the show notes if you still want to get an application in. Hope to see you there. Now Tanya will share a little bit about this week's sponsor. 01:41: Tanya: Aleo is a new Layer 1 blockchain that achieves the programmability of Ethereum, the privacy of Zcash and the scalability of a rollup. Driven by a mission for a truly secure internet, Aleo has interwoven zero-knowledge proofs into every facet of their stack, resulting in a vertically integrated Layer 1 blockchain that's unparalleled in its approach. Aleo is ZK by design. Dive into their programming language, Leo, and see what permissionless development looks like, offering boundless opportunities for developers and innovators to build ZK apps. This is an invitation to be part of the transformational ZK journey. Dive deeper and discover more about Aleo at aleo.org. And now here's our episode. 02:25: Anna Rose: Today I'm here with Omer, the CEO of Ingonyama, and Yuval, Chief Architect. Welcome to the show, both of you. 02:33: Omer Shlomovits: Thank you, Anna. I'm excited to be here. 02:35: Yuval Domb: Thanks, Anna. It's great to be here. 02:37: Anna Rose: So today, I think we're going to be diving back into the hardware topic. But before we do that, Ingonyama, the name Ingonyama, I feel like we should say what that is. It's one of the most unusual names in our space. Just tell me, what does the name Ingonyama mean? Where does this come from? 02:55: Omer Shlomovits: Yes, so there's the origin story and there's like, what does it mean? I think that by now the association is with the Lion King, right? I mean, originally it's like coming from Zulu language. It's like from South Africa means Lion, right? Therefore they are mentioned in the Circle of Life and throughout like the Lion King. We recently shared... Like we recently announced the company funding and we kind of check that in Google search, we kind of like dethroned... Like when you search for Ingonyama, it used to be the Lion King. Now it's our website, our GitHub, our Twitter and so on. It's all the way to like... The YouTube video is like number nine or something. 03:40: Yuval Domb: Yeah, no, it took me a bit of time to get used to the name, but actually a funny thing that happened two weeks ago, I went to the Lion King in London and I actually noticed every time they said Ingonyama, it's pretty weird. 03:55: Anna Rose: Wow. Wait, is it in the song Ingonyama? 03:58: Omer Shlomovits: So I'm not going to sing, not going to embarrass myself and lower the rate of your audience, but basically in the Circle of Life, like the song, which is known by like 99% of the world population, they mention it 30 something, like 36 times. When you try to think to yourself at least the beginning, right? So they kind of say it repeatedly, over and over again. So it's like in your subconscious in a way, everybody heard it at some point in life. 04:32: Anna Rose: Everybody knows it. 04:34: Omer Shlomovits: Yes. 04:35: Anna Rose: Ingonyama. Wow, that's so cool. Well, thank you for sharing that with us. I've been very curious for a long time. Okay, let's kick off. Omer, you've been on the show before. You were on a few years ago, but you were talking about a completely different, well, maybe not completely different, a different topic, a different project. You were on for ZenGo at the time, and we were talking about MPC and threshold cryptography. I'm really curious, what's happened since then, and what made you make that shift over to ZK, and ZK hardware specifically? 05:11: Omer Shlomovits: Indeed. It was three years ago, also with the ZK god, Fredrik on the show. 05:18: Anna Rose: My old co-host for anyone who doesn't know. 05:21: Omer Shlomovits: Yeah. And I had a lot of fun talking about all these crazy ideas with social cryptography. And indeed, it was part of my role at ZenGo, I was doing a lot of research, a lot of innovation, a lot of open source cryptography, which is very rewarding. And again, like also you get to work with people all around that are really talented and dedicated to the goal of decentralization and security and privacy and all of that. At some point, I needed to be aware of the context, which is a consumer company. And I felt that I kind of gave it everything that I can give and it's kind of like... I mean, in a way, I'm like a founder for the early stages of that company. So I felt that the ship is moving without me now. And I can let go, and I guess optimize on what should I do next. 06:16: The move to hardware and zero knowledge is actually very linear. So ZK and MPC both are like part of privacy-enhancing technologies, these PETs, PETs. ZK is being used quite a lot extensively in MPC and it's also a very fundamental kind of idea. So it was always there for me. I was no stranger to ZK tech. It also had a very clear opportunity. And hardware is... For me, working in open source software, hardware is just taking it one step further, like have more, like another dimension, like more freedom to design and build systems the way that they should be built. So it made a lot of sense. And other than that, basically, the other things remain the same, right? So we chopped the consumer part, kind of kept it at the infrastructure, focus on what I'm passionate about, and that was it. So that's the overall idea. But the way that things played out is that I needed some conviction at the beginning. So it's not just like you come up with this idea. It was not even my idea. So Justin Drake was advising us, I think, was the one that was in charge of the inception, but also many others. And the more I thought about it, the more it made perfect sense. It's like any technology that disrupts and becomes mainstream need to have this kind of like leg for hardware. 07:45: Anna Rose: That's interesting you mentioned, Justin, because I remember having him on years and years ago for like VDFs. And then there was this conversation about these VDF hardware pieces. And I know I want to bring this up later on. Justin recently shared on Twitter that there's some sort of ZK ASIC that exists. That's cool though that like that conversation was happening back then. What else was it though about ZK? Because like you said, ZK and MPC are sort of under the same umbrella. Was there something specific about the ZK space that made you decide to take that track? 08:22: Omer Shlomovits: Indeed, there is a reason why we focused on ZK. When you think about it, what we do is basically the intersection, work at intersection of hardware, software co-design and mathematics. And whatever we do can be applied to ZK, fully homomorphic encryption, FHE. And even in the future, maybe MPC, like there are some parts of MPC that can be accelerated as well. Now, when you start a company, you also need to think where's the market, right? Where people are building, what they are building and so on. And it was very clear that ZK, four decades into the making in terms of research... Let's say a decade or so, more or less, when it comes to software engineering, it was a very... And you see this kind of products coming out and actually making difference on real world and users. So it was more appealing to us to start from that technology and also the blockchain Web3 market. That's where the action is basically, yeah. 09:32: Anna Rose: Cool. Yuval, I want to hear a little bit about your story. It's the first time you're on the show. So maybe you can tell us a little bit about what you were doing before and what led you to be interested in this problem. 09:46: Yuval Domb: Right. I'll try and just give you a real brief intro of my background. Feel free to dig in. So I'm an electrical engineer. I have a PhD in information theory in the context of communications. I've been working in the industry for nearly 25 years. 10:04: Anna Rose: Which industry? 10:05: Yuval Domb: Well, I worked at two large semiconductor companies, Texas Instruments and Broadcom. Very many startups, extinct in the defense industry. I did mostly modems, physical layer, basically everything from research algorithms all the way to Verilog designing and also system. And a little bit of time I spent on algorithmic trading, high frequency and also not so high frequency. 10:41: Anna Rose: So you've touched a lot of different things that would contribute to you working in this industry now, it sounds like. 10:47: Yuval Domb: I think so. It gives me, I guess, some advantages, but also there are also disadvantages, right? Because I haven't really been a computer scientist and specifically in this field for very long. So I think getting into this field, about two years ago, Danny, who's also co-founded Ingonyama with Omer, called me up. He knows me from way back at Texas Instruments, and he said, do you want to join us? And then I think maybe like 15 minutes later, I was already on a call with Omer, and he explained what ZKP was. And I think it was pretty immediate. For me, I mean it was just very exciting to get in to this new world. 11:35: Anna Rose: Nice. So I want to talk a little bit about the story of Ingonyama after founding. So you had the idea, Omer, and you were saying you were kind of talking with Justin Drake. You were sort of thinking of the next direction. You landed on something hardware. So I've been saying hardware, but actually, how does Ingonyama define itself at the moment? What exactly did you set out to build, and has that changed over the last few years? 12:02: Omer Shlomovits: That's a good question. So it didn't change much, but on the other hand, it changed quite a lot, right? So I mean, first thing you need to understand about hardware is that cycles are very slow. It's not like software. It takes time. You need to develop expertise, you need to build some kind of IP. Even the programming part is just longer in general. So, originally, we thought about Ingonyama as kind of a very traditional semiconductor company in the sense that you have an ASIC as a target, and you just go and build this ASIC. There are a few steps you need to take along the way. Like you need to, again, develop your IP cores, you need to emulate, simulate, run FPGAs that would kind of show you how it's going to work, build some software stack on top, find some customers. And basically scale from that point, right? So one ASIC follows another ASIC design, improving with technology process, and also just the architecture, perhaps. I don't know, you can think about other semiconductor companies like Nvidia today, this is kind of the way that they push products, like every, let's say, six months, one year, you have like a new ASIC coming up. Now, the starting point was basically let's break down ZK into the components that we want to accelerate, and then let's figure out a way to accelerate those in hardware. Stuff that you are familiar with, MSM, NTT, all of these massive building blocks. 13:50: Back then, I just like... Talk that I gave what we call it, there's MSM, there's NTT, and there's fluff. No one thing that we learned is that's a bit misleading because the fluff is important and also being application-specific is important, being attuned to what the community, the ecosystem actually needs is also important. And also making hardware available now and accessible is also important. So it means that for us, while we still walk in the same trajectory, like we have now much more mature understanding of ZK, we have kind of IP that is sitting on the shelf. And now we started not long ago just to build actual designs out of it that can lead to ASIC designs that can solve a real world problem. We also figured out that the approach would be kind of end to end. So you want to put everything into the hardware, everything you can, and preferably you even want the design to start by considering the hardware, like doing it backwards, meaning you already have a system, whatever, some Halo2 proving system. Now let's try to find ways to accelerate it, is much less effective than trying to accelerate or trying to build like hardware-first, hardware-friendly, let's call it ZK Prover. So we've taken this approach. 15:22: At some point, we've realized that GPUs provide a lot of advantages. They are easy to come by, like commodity hardware, almost very cheap, easy to program and provide you a lot of like value, meaning that you can get quite a lot of acceleration at a good price while just using GPUs, almost just by plug and play. So we've had some focus or we've been focusing also on that. So I guess we do have a few branches of work. Definitely the roadmap leads to ASICs. That's the way that ZK should run, but we still want to also address pain points and solve problems and enable ZK today for different types of use cases and different customers. 16:16: Anna Rose: That's cool. So you've just mentioned a few things that I think our listeners may be familiar with, but I do want to just do a throwback to an episode that we did last year all about ZK hardware and hardware acceleration. Because some of the terms like FPGA, GPU, ASIC, the MSM, the NTTs, like just how these things relate to one another, all of this was covered in that show. So I'll definitely add the link in the show notes. I really like what you were saying though about like, it was almost like ASIC is your North Star. It's like that's the aim. But to get there, and this is what I've sort of heard all the time is like, since ZK proving systems change, since there's different flavors for different purposes or trends almost in some of the research and you're seeing things pop up at times monthly, like a new proving system that's super exciting. When you start to think about an ASIC, which is so concrete and sort of final in a way, like it's not as malleable as say an FPGA, is it very difficult to do that in such an environment? Like if things are changing, can you ever really be sure that you're building something for the right system? 17:28: Omer Shlomovits: You're right with this insight. There's like... Or at least what we thought can be a way to overcome it is by having something which is like a programmable ASIC. So you're building a computer that can do many things but is more suitable for the type of arithmetic used in ZK and cryptography like finite field arithmetic. So that's the notion of ZPU, which we try to develop and then push. And till today, we use it as kind of like when we think about how to design a general purpose ASIC. Again, I know the name is kind of as a contradiction in it, but still that's the model we've been trying to push so that you can, in a way, handle different provers protocols, and accelerate all successfully. 18:20: Yuval Domb: I think this goes back to the talk at ZK10. 18:24: Anna Rose: The talk that you gave. 18:25: Yuval Domb: Yeah, that I gave. Yeah, but others helped me build it. 18:29: Anna Rose: Well, we'll add the link in the show notes for folks to watch it. I did watch that in prep for this. So yeah, sorry, go ahead, Yuval. 18:35: Y So yeah, I think that there was an argument that I tried to make there that is... I think it sort of gives context to everything that you were talking about just now. Like hardware is like an evolution. Like you mentioned, the North Star is some ASIC that is exactly what we need. But to get there, we sort of have to have these like, sort of steps of like, we produce new hardware and then we use that hardware to experiment, then we get new ideas, then we get new algorithms, then we need new hardware and it sort of... And it just doesn't happen without that process. I think, that's just our thought process. We need to be able to experiment. And I think that what you're seeing, that maturity that Omer mentioned before, is that it's basically us going through this evolution, I guess, with the rest of the industry, and we're just adapting. So the details change, but we're still going in the same direction. 19:41: Anna Rose: How is a programmable ASIC or the ZPU different from an FPGA? Because I always thought of the FPGA as the programmable ASIC. Isn't it sort of like between a GPU and an ASIC, you have the FPGA, which is malleable, but I don't know, you have to be a bit more specific, whereas GPU or CPU are more and more general purpose, but less specified? 20:03: Yuval Domb: I think, first of all, all hardware, CPU, GPU, FPGA, ZPU, whatever it may be, they're all ASICs, right? Because they're just different machines built into silicon. So I think if we try to sort of rank them, maybe FPGA and its likes, that there are also other older things like CPLDs and other types of programmable, really programmable hardware at the gate level, maybe they're the easiest to reprogram, but there is a very high cost associated with it. It's an extremely high powered device. If I compare it to a very targeted ASIC, if I target a specific protocol, then the actual silicon area that I will spend on a certain function, because I know exactly how it needs to be. So I don't need all this interconnect that I'm not going to use, I'll just throw it out. And so the area goes down as a result, the power goes down, so I get a very specific ASIC, but that ASIC can only do one thing, right? It cannot be an FPGA. I can't now take it and program it for something entirely different. So I think that's the way to look at it. And actually in that context, a GPU is, from our perspective, also a programmable device, maybe not as programmable as an FPGA, but it is a programmable device. And we think that it's actually a little bit more suitable for the work type that ZKP and FHE and those technologies are currently using. 21:53: Anna Rose: Do you then put, because I always had the order of like, CPU, GPU, FPGA, ASIC, but what you're sort of saying is that like GPU is programmable, but less programmable than an FPGA, and then ASIC is extra less programmable. And would you put then the ZPU between GPU and ASIC in terms of its programmability? 22:17: Yuval Domb: Actually, I have on one of the slides, I'm actually looking at it now. But I have... 22:22: Anna Rose: This is from your talk? 22:23: Yuval Domb: Yes. I'm sorry that I can't show it, but I sort of put all of these devices on a two dimensional grid of flexibility versus power or power per security, per bit of security. And so actually I bunched CPU and GPU and FPGA on the high flexibility but actually high power. And a very, very customized ASIC that maybe only does a specific protocol would be very inflexible but very low power. And I think that the ZPU tries to be somewhere in the middle. So it tries to be low power, but it also tries to provide you with sufficient functionality to cover maybe a range of protocols. 23:19: Anna Rose: Is this because, like, ZKPs, even if you're using different systems, proving systems, there still is sort of something underneath that is becoming more clear and optimizable that does power all of these systems? Is that why one could create something like this? 23:36: Yuval Domb: I would say it's a bit of a chicken and egg. I mean, I don't know if, but I guess we haven't yet finalized how wide or how flexible the ZPU will be. But I think that whatever we decide to put in that the protocols will also... If this is good enough, then the protocols will also sort of tag it there, right? Like they'll change the prime field because they can actually get an added value and that's what they've got. So I think supporting everything would not be a good operating point. You would want to support something that would be sufficient to give enough flexibility, but also not too much. 24:23: Anna Rose: How expensive is it or how much work is it to get that first iteration that you could actually use? Is it something that a small team can do in a month or two months? You can try something out, test it out, people could use it. Or what are the cycles like? How expensive is it? I'm just curious how you think about this. 24:42: Yuval Domb: The ASIC process actually starts off with maybe an architecture stage where you, first of all, need to know what you're about to design, right? And that's very fundamental. So actually, we usually think of the ASIC process as starting from that point from which we know what we're about to build. So lots of ASICs follow a standard, like a Bluetooth ASIC, right? So you know what you're going to build. Now, you've got a few stages. You've got the frontend. It's sometimes called where you actually write the Verilog and you do quite a lot of verification. And actually, the verification is extremely, extremely important in ASICs. It's where you spend most of the time. And then that goes over to the backend process where things actually start being moved from code to something more physical. And then you'll have other types of verification where you actually verify gate level stuff. You do power type of simulations. There are various stages. And it takes probably, in like the most advanced technologies to get your initial test chips from the minute you kick off the design would probably take about two years. That's like the... 26:14: Anna Rose: Oh wow. 26:15: Yuval Domb: Yeah. And then if you're lucky, then your first tape out is already something that works. A lot of times you do need to go to maybe not a second tape out. There's sometimes... There's stuff that you can fix in what's called metal fixes, which is a little bit less expensive and a little bit quicker. And I guess, getting from there to like general availability is another process that I'm not as... 26:48: Anna Rose: Okay. But that two-year period, you've gone through this, I guess. You like know what that's like. 26:53: Yuval Domb: Yeah. 26:53: Omer Shlomovits: First, yeah, about the two years. So just as an example, the chip that, like recently there was this announcement from Accseall about zk-SNARK ASIC. So they actually started to work on this chip before we started the company, before we started Ingonyama. It's a long process. It's also an expensive one. I can tell you that when we now think about taping out Aleo Prover, like an ASIC, talking about something like 20 million dollars to get it, total cost. So that can be also very expensive. Now there are ways to mitigate or ways to take it step by step. So as I was saying, one thing is just to have the IP and stop there. So you don't do the full process. You don't need to spend all this money. Someone needs to do that, right? But they would just take the IP from us, the IP core from us, they would license it or something. And that's a big part of the work, by the way. I mean, all of the design process and testing and such can also be done there, and it can be done on FPGAs, right? So for example, with the ZPU ID, there is this processing element that is kind of being replicated all across the silicon. So you take one of these and then you implement it like the Verilog and you implement it in FPGA and then you can test it with different inputs and so on. See that it obeys your design and what you predicted that it would, like the performance and so on. 28:24: Anna Rose: Is that a lot of the work in designing these? Like kind of, Yuval, what you had sort of described is you're coming up with an idea, you then do these verifications, and I'm guessing like lots and lots of tests. So is it sort of like, here's the idea, here's the implementation, and you just try to battle test it? 28:42: Yuval Domb: So I don't think that you're not battle testing the architecture, right? That's like a pre-stage. But the verification would test the actual silicon to see that you've actually implemented it correctly. So it's a lot of corner cases, a lot of coverage. They've basically taken a lot of know-hows from formal verification that was done for ASICs to actually verify these protocols. Not as in like ZK verification, but make sure that the protocols are secure, that they're foolproof. Most of the verification that we're talking about is to make sure that you've implemented what you wanted to implement. By the way, there's also a validation stage that is post-silicon where you're actually testing the silicon to see that it also meets everything. You screen the silicon, you'd have certain devices that are close to the edge of the actual physical material that function a little bit differently. 29:53: Anna Rose: That's interesting. So what you're saying though is that like this verification that you mentioned is less like battle testing, but more in the spirit of formal verification, just mapping it out, making sure it runs the way it's supposed to. That's so interesting. 30:09: Yuval Domb: And especially testing coroner cases. That's the important thing there. 30:13: Anna Rose: I don't know that I've heard that part of the story, the time frame, the cost, sort of the process. I want to go back, Omer, to what you were saying though about licensing. If you're a small company, you create the IP, you create the design, would this almost be something that, like, Nvidia or AMD would like? Because they have, I guess, all of the supply chain, right? They have the chip manufacturers and I'm assuming they can do really quick iteration or faster physical hardware iterations. 30:45: Omer Shlomovits: Yeah, exactly. As you were saying, for us, what you need to understand is small company betting on a chip and failing means the end of the company. It's a one-shot thing. Now let's take... Continue the example from Aleo. Let's say we work with Bitmain. All right. So Bitmain do mainly Bitcoin ASICs and they are really good at the supply chain. Like they can take design. So we save them all the trouble for understanding what ZK even means. Right? Hypothetically speaking, but let's say they take the design and just go through this tape out process all the way to sales and distribution, which is critical also, right? And for them, it's super efficient. They already have everything in place. We, for us, it's going to be first time, everything's going to be slower, more prone to errors and so on. So definitely there's a good point for collaboration here between us and this type of companies. 31:44: Anna Rose: That's interesting. Just recently, Justin Drake, who we just mentioned a few times previously, kind of tweeted this picture of what seems to be a ZK ASIC. I'm just curious, like, yeah, what is the landscape like for other people trying to build that? What do you make of that tweet? I don't know if there's much more to the announcement there, but yeah. 32:07: Omer Shlomovits: So, first, I think it's big, right? Again, we're talking about probably a process that started a couple of years ago and cost a lot of money. And it also can be a game changer. So again, using my example of Aleo Prover, if you put this zk-SNARK chip into play, it would basically be game over for GPUs or any other thing, any other hardware in this network until you have competing ASICs. That's kind of our assumption. And it's also probably the first ASIC that is following this design pattern of being programmable, like the ZPU concept. It's not going to be the last one, so we know that other companies are planning and probably will also launch even this year, 2024, this type of ASICs. It's kind of like now, I guess, the standard, since again, there are so many protocols and you don't really know what you're aiming for, then everybody is going for one kind of general purpose ZK processor. But yeah, I mean the fact that this can be used across different protocols, it's very interesting. 33:26: And one last thought, I would actually say that the first ZK ASIC was from Supranational as part of this VDF that you mentioned before. So they actually done a VDF ASIC that includes a Nova prover or whatever you need for Nova prover. So I would say that was the first, although it's now kind of obsolete. But yeah, I think it's huge. I think it's also very surprising. One of the impressive things in this tweet is the speed, the fact that we are already at the age of ZK ASICs. It's here. 34:03: Anna Rose: That's very cool. In that case, he talks about it like ending Ethereum fragmentation. I actually am curious, today, we know about ZK rollups. We know that there's proving happening, there's computation being used to create zero-knowledge proofs. How does it work today? And how would an ASIC change that, potentially? Maybe just paint the picture for what a sequencer or prover on a rollup is doing, and who it is, and how many machines, and where it lives. I'm leading you in a direction. 34:40: Omer Shlomovits: So first, I'm far from an expert, and Justin Drake definitely is much more qualified to talk about it, and he's talking about this future of Ethereum. But in the context of ZK provers, and specifically very fast, low latency ZK provers, which is something you can achieve with an ASIC, so what you want to achieve is that these rollups would be able to communicate between themselves but in this atomic way. So you want to enable this MEV and all of these other things that we have today, but happening across rollups. And the way to do it is by kind of selectively taking the transactions that are relevant from different L2s. By the way, it doesn't matter if it's ZK rollup or optimistic rollup, just taking these transactions and proving them and having them in this one proof. And for that, you need to have relatively or extremely low latency, so that this can happen in this manner. 35:41: So today it's indeed like each rollup can be thought about as its own island, right? Like with their own set of smart contracts, where there are some... I mean, I know Justin and others are also trying to have this idea of having Ethereum as the base layer, allowing more of joint state in a way, and of obviously shared sequencers. But still, they are very different and independent. Having ZK is probably, and that's... By the way, I think it might be the only place I know that ZK is the only way to do it. If you actually want to achieve this real-time cross-chain communication, you do need ZK that would run very fast. I don't know, Yuval, maybe you want to add something? 36:27: Yuval Domb: What Omer said is, I think it's what we call the bridges, right? Where really you simply cannot do them without having low enough latency. I would say that also just the rollups themselves at some point, and it really depends on how much we want to scale blockchain or how much we want to scale Ethereum, because I think that if we look at the pricing, right? If we look at just L1, transactions are expensive. Now a rollup takes a whole lot of transactions and rolls it up into a single transaction. So now that cost is amortized across many rollup transactions, but all of a sudden we've got new costs. So one of the costs is running these proofs, but perhaps a more significant cost at this point is then storing all of these transactions. Because they still need to be stored. So maybe they don't get stored on the main storage, they currently get stored, if I'm correct to something called logs, at least in Ethereum, which is a little bit less expensive. But I think that that is currently the bottleneck. That is why at the current stage ZK rollups don't scale more than they actually do. And they actually don't scale very much at this point. I think once that barrier goes down, and I know it should go down in Ethereum, I think that's the whole danksharding thing is meant to bring that cost down. But then I think the next barrier, if we want to scale even more, would again be power, right? So we have to bring down like the power per proof, otherwise we'll get stuck there. 38:20: Anna Rose: I think one other piece of this puzzle, because I just did an interview with Celestia and also with Avail and with Eigen, like the DA narrative, I think, takes some of that weight off. It's almost like you're reducing all of the other latency and cost so that all of a sudden that ZKP and the actual time it takes and everything becomes the bottleneck. But so far it's not that, I guess, right? 38:45: Yuval Domb: That's not our impression, actually... 38:49: Anna Rose: It is already? 38:51: Yuval Domb: Our impression now, I had a very interesting conversation with someone from Ingonyama, with Oren, and we think that currently the bottleneck is the storage cost of the rollups and actually not the cost of proving. But it will become the bottleneck eventually. 39:14: Anna Rose: Yeah. But I think that follows what I was saying, that it's not currently, but there's these ways that they're going to be reducing other costs and then eventually. 39:23: Omer Shlomovits: I might even take it into a more controversial opinion. It's not now the bottleneck. Might be that it's never going to be the bottleneck with ZK rollups as like standalone L2s. What I was trying to say is that it might manifest itself like ZK ASICs more in this atomic bridges. But with rollups, they are so complex systems, and even if you take just like ZK-proof, we have a huge bottleneck just at the witness generation part that is also important to mention. Now you also add to that like the sequencer, which is also a bottleneck. And just again, generally speaking, most of the cost today in rollup goes to this on-chain fees. And when I say most, it's like 90%. And even out of this 10% cost that you have for running this infrastructure, provers can be very small percent, maybe 1, 2% out of this total cost of operating your rollup. So I'm not sure at which point in time, depends on how we didn't see rollups yet become fully decentralized at this point. So it's hard to predict how this will play out because there might be that provers would have a more important role. Maybe some prover networks would start to emerge. But at least now when we have this stage where they are mostly centralized, I don't think that like rollup operators think too much about... Like we know exactly how much they think about provers. So I'm saying that I'm not sure that's the bottleneck and if that's like when they think about improving it, of course it's important to improve that as well as other parts of the system. Just not saying that, oh, this is where ASICs should come in handy, right? Or we have to have ASICs, otherwise our rollup is not going to work, right? 41:18: Anna Rose: I mean, you just touched on a bunch of topics that I think are really relevant today. The prover marketplace, the shared sequencer. Like the thing is those things need more adoption for us to see how the economics play out if they work and yeah, if at some point a chip or acceleration would actually help in that way. You just also mentioned though the centralization of the rollup. I kind of want to dig in on that because when I talked about where is the proofs happening, like where are most ZKPs being created. How does it work today? 41:55: Omer Shlomovits: Yeah, take like one company, can be any of the leading ZK rollups, and they basically operate everything, right? It's not just the sequencer and the prover, it's also, I guess the explorer, right? You need this kind of features in the chain so that it would be active and usable. So they basically run everything and you as a user, usually you don't interact directly with the rollup, right? So you kind of like do... Like there's like, I can build an application, I don't know, on top of Scroll, zkSync, whatever, and my application would interact with the rollup smart contracts. It can be, for example, with zkSync, like the most popular app is like a swap thing. I guess they found a way to make swaps really fast and also cheap. So I can do this kind of swap thing with some third party, with liquidity providers, whatever, this entire unrelated to rollup. Eventually I'm gonna settle using the rollup and they're gonna collect all of these transactions, right? And as Yuval said, so basically batch all of those into this single transaction on Ethereum. And this on-chain fees is actually expensive, right? That's kind of, as I said, like a big part of the expenses. 43:17: So It depends, right? Some rollups are using some kind of cloud-based services today. It can be AWS, it can be GCP to run provers. They can also do it on-prem. So today we also have companies that are doing this rollups provers just with their own servers, and that's fine. It allows you maybe a bit more flexibility with your setup, more control. 43:45: Anna Rose: What's the name you just said? Prim? 43:48: Omer Shlomovits: On-prem, on-premise. Like, you know... 43:49: Anna Rose: On premise. 43:49: Omer Shlomovits: On your own hardware. 43:51: Anna Rose: Oh, on your own hardware. Okay, okay, sorry, I didn't get it. 43:53: Omer Shlomovits: Yeah, just like your own hardware versus to use some instance in the cloud. So we see both. And we also see both CPUs and GPUs. So zkSync, for example, they are heavily relying on GPUs for the prover. It's already very optimized for GPUs. Others can be going in that direction. Eventually, I believe everyone would use specialized hardware, just because, again, it saves power, it's a more efficient way to cut costs. So that's kind of all of the infrastructure that is working, but here it's centralized, like operated by the ZK operator, the ZK rollup operator. 44:31: Anna Rose: Talking about the marketplaces, that's definitely an attempt to decentralize the proving action. Would something that you folks build, like maybe you design it and someone else produces it, but is that where you could imagine the Ingonyama hardware being used or the ZPUs being used? 44:51: Omer Shlomovits: It's a trend. I see a lot of companies now trying to build in that direction. And in a marketplace, you have two sides, and here you actually have three, right? So you have maybe four, I don't know. Let's count together. So you have the consumer, like the one that actually requests a proof, like I need this thing to be like a ZKP'd. There's the hardware provider. So today we don't have marketplaces running in this like whatever, like hyperscalers. We don't have these marketplaces running with hyperscalers. Someone needs to provide hardware on the other end and should be rewarded for letting people use the hardware. And then you also need the algorithm. And that's where I guess Ingonyama plays a role. And I guess the fourth player is the one that actually builds the marketplace. Think about exchange. So someone needs to build the software for the exchange, so someone needs to build the software for the marketplace. And I guess when it's becoming decentralized, it's becoming this network that someone needs to design and test and then deploy and so on. 46:02: And it seems like a very promising idea, I have to say, although when you try to... We just enumerated this like four different participants, when you try to think who's falling into each slot, it's not yet clear again, like who's asking for proofs, who's gonna use this type of marketplace from asking for proofs, who's gonna provide the hardware. So definitely they're like, let's say I have GPUs, so it might be a good alternative, but you need to come up with the incentive mechanism and so on. It's a bit of a challenge and even for us, maybe I can do some... Let's say that I'm providing some algorithm for this marketplace, like making it available for the marketplace, but I'm keeping another algorithm which is better to myself. 46:53: Anna Rose: To yourself. And you're also running this yourself, probably. 46:57: Omer Shlomovits: And then I run it myself, right? So how do you make sure... You need the incentives in place, how do you make sure that I'm incentivized to compete with others on providing the best algorithm? Right. So there are tons of questions around that. The only thing right now we have abundance of is this like teams trying to build the software, the network for the marketplace. Which is, I would say, important but it cannot work alone. So I'm definitely thinking it's important and it might play out and there's definitely room for such a network. I'm not sure of too many such networks but it can make sense, but it's still very early to say, all right, we still need to try to see the full flow happening, everything falls into place, like I need this to happen and the other player needs that to happen and so on, how everything like fits in. 47:54: Anna Rose: You mentioned that Ingonyama could build the algorithm or be the part of this or the sort of the participant that brings an algorithm. Is that also something that you do today? And is that similar to the work you talked about in terms of designing a chip? 48:12: Omer Shlomovits: Right, so I guess I was mostly referring to how this would look like using GPUs, which today are available, and you can have access to a lot of them, right? Like you have a lot of data centers just dedicated to GPUs, and they are programmable, right? We do a lot of work on GPUs. So definitely we can fit in there with algorithms. If you also add ASICs to this marketplace equation, so ASICs can be very specialized as Yuval pointed out. So it can be, I don't know, an Aleo ASIC, kind of using my example here, which means that it's like coming with the software built in, right? You don't need the algorithm, it's already like... It can do only one thing. It can also be this like ZPU type of an ASIC, which can run different algorithms. And it might be that we'll see that once you have enough ASICs in the market, people would start to explore them, coming up with algorithms for this ASICs, and also with software implementation for these algorithms. So it kind of gonna become like a ZPU is another type of GPU that you can program and put into the marketplace and make some kind of profit out of. 49:27: Anna Rose: Got it. Maybe just going back to Ingonyama specifically, are you working on those two fronts in parallel then? Are you on one side working on the design side of a chip, but then also on the algorithms that work best on GPUs? 49:43: Omer Shlomovits: Yes, you can say that. We do have work on GPU that can be used today by anyone. And we have also this long-term work on ASICs. I'm not saying that the first one would be like the ZPU itself, but we definitely do a lot of experimentations and iterations, as we pointed out, to make hardware, to make it real, like to actually take ASICs and bring them to the world. 50:12: Yuval Domb: Also I would say that the GPU work that we do also complements the hardware process because we learn a lot by using GPUs. We learn what to do, what not to do. So it's complementary to the silicon process. 50:31: Anna Rose: Cool. You've mentioned in talks and on Twitter, ICICLE. Can you explain what that is exactly? Is that on the algorithm side? 50:42: Omer Shlomovits: So ICICLE, first it's an open source library. And it was meant to allow developers to tap into GPUs. So today it's NVIDIA GPUs. So it's strictly CUDA-based. We put emphasis on the API so to make the developer experience extremely smooth and make developers happy. So the idea is that the MSM and NTT that we talked about, like the most basic level of integration, would be take ICICLE and then switch from CPU to GPU specifically for MSM and NTT. Doing that for your protocol as we've seen time and again, already gives you something. It gets you to a point where you have... Like very quickly, you have something which is already more performant than what you had before. But it's only the starting point. So ICICLE can also allow you to do all of this glue in between, and all of the polynomial arithmetic that we have. And it, in theory, should be... Not in theory, but also in practice, should allow practitioners and also researchers to write big chunks of their protocol in the GPU. Right now, we still as an industry... As an industry we're mostly focused around CPU, but if you look at AI, for example, no one is using CPU. So everything, the conversation is on GPUs, how do you optimize GPUs, how do the engineering with GPUs. We try to do that but for ZK, right? So, ICICLE is just a way to get started and to experiment and to get your system to a much better place than it is, but very quickly. 52:29: Anna Rose: I feel like when you talk about sort of the proving marketplace, but also this work when there's this competitive environment, the ASIC development, proving in general, like if you think of a lot of the consensus systems that we have, they're economic games of balance to be able to decentralize a network, right? And some of them work better than others, some of them end up becoming quite centralized. But in this case, where you have this competition, like say we have a proving setup, proof like multiple people trying to prove, or other hardware companies trying to enter the space, when I hear it, it almost sounds like you would keep a lot of the stuff that makes your prover super strong to yourself, or your algorithm to yourself. Do you know what I mean? Like you kind of mentioned that, you'd release part of it, you'd release something, but you probably wouldn't release all of it. And I just wonder, how does a market like that work? Can you actually achieve that decentralized evenness if there's this hidden part? 53:32: Yuval Domb: Yeah, I think, well, I mean, obviously, if there is enough competition, then that can break that, right? Because if you keep it to yourself and someone else offers it, then no one's going to come to you. But I don't know, perhaps it can work economically. But I think there is a...To me, there is another question. If I get you to do my proving, then I have to trust you to some extent, right? Because I need to give you the source. So to me, that's something that needs to be answered. Maybe that's where MPC comes in, but it's another level of complication. 54:12: Omer Shlomovits: I just wanted to emphasize that, traditionally, semiconductor industry is extremely competitive and also extremely secretive. And we try to break it. We've been trying to use a different model since we started the company. Now, I cannot tell you at this point how to win the market, but I know that we will fail if we keep these walls between us. So I know how to not win, for sure. Therefore, for us, transparency is critical. Everything we do, we try to communicate. We were the first one to communicate this idea of ZPU, although I'm sure others, I know others, are thinking in the same lines. But it's important to bring this conversation to the public. ICICLE that you mentioned, it's MIT licensed, open source. I think that very early on also we've realized you cannot win by saying, I have the best MSM. I mean, it's not gonna work. Like you just... If you have something, we call it table stakes, just like publish it, let others like, let the research community explore it, improve it, let's go as a community. So that was key for us as we grew and are growing. I'm not sure what's gonna happen in the future once we start to see these like moats and how it will impact decentralization. I think you're making a very, very important point here that we need to understand as an ecosystem. 55:47: Anna Rose: I like the way you put that too, the moats. And I almost wonder if it's because it's the hardware, which is these longer timeframes, way more investment, kind of colliding with the open source decentralized nature of what we work on. It's kind of interesting. 56:03: Omer Shlomovits: Yeah, I think so. 56:05: Anna Rose: I also want to go back, Yuval, to what you just said about the privacy of what's being proven, kind of. I think that's what you were hinting at, where if you outsource a proving action to someone else, you definitely can't do that if you're trying to keep that thing secret, because they then would have the information and then prove on it. And I think it works well when it's like a scaling, when it's more about verification or validation of something, but on the privacy front, I mean, you can't share it. Unless, like you mentioned, you've already wrapped it in an FHE or something like that. It has to already, yeah, some other cryptography must have happened on it. 56:44: Yuval Domb: Yeah. I think perhaps it's even more than privacy because I can prove something entirely different to what you want me to prove, right? 56:56: Omer Shlomovits: I mean, you are right that it involves some more advanced cryptography, but also just like what we see in other places, you can also have something working inside of a T, like a trusted execution environment. And in fact, Nvidia came up with this confidential computing environment. So in a way you can outsource the computation while maintaining privacy of your input to some kind of Nvidia GPU that's running in the cloud. People are already using it, although as we know from history, every T... 57:33: Anna Rose: Gets broken. 57:35: Omer Shlomovits: Yeah, in a way. So it's not bulletproof, but it's another interesting direction to think if anyone is kind of sitting there trying to come up with some kind of proof of concepts that would be very interesting to see. 57:50: Anna Rose: Do you see a future where it would be more client-side, where proving like maybe someone would use some algorithm or some library that you've created and it would be actually happening, yeah, on a phone, on the client, like where the person with the information, could they be using more sophisticated provers? 58:10: Omer Shlomovits: Yuval and myself were discussing a few days ago about the use cases for client-side proving and if we are ready. I think that we both agree that there's a future there. You mentioned privacy as one reason. There are other reasons. I can also give an example on how it solves scalability issue. I mean, in gaming, for example, there are good reasons to do that, but are we ready? Do we need it like today? We are not sure. I mean, we were thinking perhaps, let's add support for metal, which is how iOS, also like Apple, Mac has their own GPU and so on. So this is kind of their way to program it, mostly for graphics. But are we ready to also add support for that? Is it going to be useful? I think we talked with like the Jolt guys from a16z, that was one interesting potential user for this tech. But the overall conclusion was we're not there yet. We don't have the privacy thing, or in general, client-side proving is not appealing enough today. But in the future, it's definitely going to be part of the ZK landscape, no doubt about it. 59:20: Anna Rose: Do you think it would come from the outside, or do you think it would be Apple using ZKPs themselves? Attested sensor signing, we've been sort of talking about that on the show a little bit. 59:32: Yuval Domb: I think that there are two things that you usually need for client-side. So one of them is really you need to be extremely power efficient if you're going to run on a phone or on a watch or on something like that and that's stuff that we've been discussing. But I think for much of the client-side applications, you also need some sort of third party database. Maybe you need to prove your identity, but proving your identity is actually proving membership in some government database, right? So I think that for many of the client-side applications, you also need that infrastructure. Otherwise, there's nothing to prove. 1:00:20: Anna Rose: Well, we were... I mean, in our case, we're talking about more like the... Here it would be almost, you take a photo, you want to prove that it's your photo from your phone at a certain moment. This is where you need a signature at the beginning of one of these content journeys. We were talking about this a little bit last year with the attested sensor stuff. But that's where I think maybe a client-side ZK proving something or other would be really cool. Because I know what you mean where it's like if you want a passport or an identity, you're going to still need to figure out how that's created in the first place. 1:00:55: Omer Shlomovits: We took it to... Last year where this conversation about IoT. So imagine this like sensors, like camera sensors, like doing some security stuff. But again, not necessarily at the station, I think was the main use case here, but mostly about saving storage. So instead of sending a lot of... Like these cameras are doing machine learning right at the edge. They need to detect some kind of anomalies. But the way to do it, they send a lot of noise to some storage like at the back office. So instead of sending all of this garbage, you can just send the proof that over the last 10 hours, there was no event. So you save a ton of storage, making the sensors cheaper and so on. 1:01:44: Yuval Domb: We called it insights. So you actually send insights rather than the whole video. 1:01:48: Anna Rose: All of the info. That's cool. 1:01:51: Yuval Domb: So it's a type of safe compression, right? Because why would you believe me if I told you that, yeah, no one actually entered this gate in the last 10 hours, right? You'd believe a video typically, because maybe that's hard to fake. Maybe it's not so hard to fake anymore with AI. 1:02:08: Anna Rose: Well, no, that's why you need the attested sensors and the signatures. This is what we're thinking. 1:02:11: Omer Shlomovits: Yeah, exactly. 1:02:13: Anna Rose: Yeah. No, that's fascinating though. So in your case though, when you're even brainstorming about these client-side use cases, do you imagine the work you do today kind of ending up in that realm? Is that sort of a goal as well? Like beyond just the ASIC goal, is it like that people could actually use what you're building on that side? 1:02:35: Omer Shlomovits: Yeah, I mean, both on the ASIC and on the GPU side, I would say that it's somewhat of a goal, but we need a very clear use case. That was what I was hinting before. So I can imagine a process, let's say we work with a company, I don't know, Nintendo. So Nintendo, they have consoles, client-side, kind of gaming devices, and they have GPUs, and they have full control over the stack, right? So you start with the GPU, you take what we have with ICICLE, you kind of port it to their software stack and hardware, and then it works great, and they need this kind of privacy disrupting technology to work even at the lower power. So they say, you know what, let's do an ASIC, right? So then it's like this evolution, right? It's just what we described before, it's taking step by step. So then you move on and say, okay, let's do an ASIC together. And just push it into millions of Nintendo consoles. 1:03:35: Anna Rose: That would be cool. So I know we're getting close to the end of the episode, but I know you also have been releasing some interesting research papers and work. Tell me a little bit about what's coming out right now? What's the focus of the company today? 1:03:49: Omer Shlomovits: I'm gonna talk about two recent papers. I'm gonna mention them and Yuval, you can like jump in and fill in the details. So one paper we released very recently is kind of applying graph theory to this very large provers, like the zkEVM provers that you see with Taiko and Scroll. And there, what we witnessed is that the memory is... Even before compute you have this like a lot of memory that you need to use and that's becoming a bottleneck like you are stuck on just waiting for memory to be free. So the naive idea was can I take this prover and just separate it into two smaller size provers that can run independently in parallel therefore cutting the memory requirement by half by moving the problem for memory to compute. And the way to do it was to kind of like saying, let's look... You need to go way to the beginning of the protocol, kind of see, imagine it is after it metization and it's kind of table and trying to understand where you put the knife, right? Like where do you want to do the cut? And there is no natural place to do it. But if you add some redundancy, like if you pay a bit to increase the table size, then you are able to cut it in equivalent pieces. Or it can be more than two, it's like community detection. 1:05:20: So it looks better on Taiko than it is on Scroll, and we try to understand also why. So that's like one work, and quickly the second paper released is about sumchecks. So that's like first chapter of a much broader, bigger project that we have about sumchecks. There I have to say that... I have to admit that when HyperPlonk came out, I was kind of rushing to publish this blog post claiming, I think the title was kind of like, sumchecks are not hardware-friendly. Hyperplonk is not hardware-friendly, something like this. You guys, you just used a bunch of cool cryptography and math, but it's not going to be used in the real world. And I was wrong. So we now know many ways in which this sumchecks, and that's a fascinating topic, right? How these sumchecks can be running parallel, can be run efficiently on GPU, can be running a lot of algorithmic improvements to that, and there's going to be much more released by us and others. Much more work on that topic going to be released by us and others in the upcoming weeks and months. Yuval, you want to add anything? 1:06:23: Yuval Domb: Yes. So maybe I'll just add a little bit about sumchecks. So yes, so the question is really how to get sumcheck to be more parallel. And the main problem is that sumcheck is really, it's sort of like a funnel, right? You start off with a lot of computation that you can do, and then as you go through the rounds, you have less and less computation, but you cannot parallelize them because of you actually have this Fiat-Shamir process. And you actually need to complete a round before you can generate the pseudo-randomness for the next round. So you can start off very parallel, but then at some point you just get stuck. So actually sort of at the same time, we've been working with Justin Thaler for a few months and we actually took an idea from his small fields paper that I think he hasn't officially released, it's on his website, some preliminary version of it, which we also have some work on but we'll leave that. 1:07:32: Anna Rose: For the next one. 1:07:32: Yuval Domb: It'll come out at some point. But we took an idea where we actually separate, when you look at a subject protocol, you can actually separate the data from the challenges. The challenges are those random, is that Fiat-Shamir randomness that you're generating. And there is a cost associated when you separate the data from the challenges. You actually increase the amount of data that you actually need to store quite significantly. And what we've seen is that if we use this hybrid sort of system where we start off with the standard sumcheck protocol, we can actually saturate the GPU, but then at some point we actually move on to the other implementation where we actually separate the data and the challenges. We do increase the storage costs, but now we can do a lot of computation on the data in parallel. And then at the end, we will have this little tiny tail that sort of is a little bit inevitable, but we do get an overall better average time. So that's one work that has been partially released by Karthik and Suyash. So they haven't actually discussed the hybrid system yet, and that's coming up, but they have discussed the two algorithms. 1:09:05: And now we're actually starting to look at some folding schemes that I think are very exciting, where we try to actually trade off, again, instead of doing one big sumcheck, we're actually looking at splitting it into a few sumchecks. And then we think we have a method where we can actually fold everything so that the verifier just sees... 1:09:32: Omer Shlomovits: Yuval, you're spilling all the beans. 1:09:36: Anna Rose: You're spilling all the beans. 1:09:38: Yuval Domb: Anyway, it's ideas... 1:09:39: Anna Rose: Do you want me to not say... 1:09:40: Omer Shlomovits: I'm just kidding. Everything is open source, even the research. There is a repository called SuperSumCheck. The Halo 2, the Taiko thing, is open source. There is code, you can use... We're also collaborating with academia on that, and yeah, EPFL is in the loop and so on. 1:10:02: Yuval Domb: So EPFL actually, yeah, I don't know... We don't want to say too much because I know that they've got something cooking and it's actually something very interesting that we haven't thought of. But yeah, we will let them push it out and I think we're going to somewhat be involved with them on maybe implementation of that. So that's pretty exciting. Yeah. 1:10:24: Anna Rose: I feel like when you talk about these techniques and then doing work on these techniques and then you put it in this hardware context and actual speed and cost. I had Ulvetanna on, what is it, three months ago. We were talking about the Binius work, which they described as being created much more for a hardware-friendly environment. Would you put what you just described in that category as well? Like, are you thinking about it to work better with what you know about how architecture will be working? Like, is that what you're developing for? 1:10:57: Yuval Domb: Yes, but I think that actually our process is quite fundamentally different. I think that we actually try to take existing protocols, so to speak, and then we say, okay, what is wrong with them, right? Or, not what is wrong with them, but like if I just naively put sumcheck on a GPU, it just doesn't work well. So then what do I need to do? Right. So we sort of try to... We try to evolve, right? We discussed it in the beginning. So we'll see the problem, we'll try and find a solution for it. And maybe eventually, we'll get a new hybrid for it and then we'll do... We'll keep on doing these steps. So I don't think... We don't try to invent something entirely new, but eventually, yeah, like the algorithmic work that we do attempts to make the protocol more hardware-friendly to... Like at the moment to this given hardware, to the GPU. 1:12:03: Omer Shlomovits: You can imagine how we're going to do the same for Binius, right? So there's going to be like a software, maybe even hardware for Binius. We've done it for hardware, like we've improved other hardware implementation. So we're just going to wait for applications to come up and understand how we can evolve and get this system to become better performant. It doesn't matter for us if it's like Binus or I don't know, polynomial commitment scheme, prover and so on. 1:12:33: Yuval Domb: Yeah. I can give another example of the work that we're actually doing on small fields. So we've taken, I mean, Justin Thaler did this incredible job on small fields. And small fields is this idea of basically, I want to work with a smaller characteristic, but then how do I get the security? So I actually do the sumcheck on a small characteristic field, but then I actually put my evaluations on a hypercube that is in a small field, but then I sample somewhere very far out of that field, I sample like the sumcheck protocol samples in some extension field. And that's how I get the security. And he's got this algorithm where he actually splits up the challenges or the data and the challenges. And what we've noticed is that that split creates a lot of data and a lot of data that needs to be stored for very long before you start creating the challenges. And by using... I'm actually not going to spill the beans this time, but using these very basic arithmetic techniques, very well-known old stuff, we've been able to actually shrink the storage to very, very small, like something like maybe factors of like, triggered by n over logn or something like that, right? Go from n squared to n logn. It actually makes it much more usable for GPU, for example, because GPU is a great device, but it is very, very much storage limited. 1:14:22: Anna Rose: Very nice. Well, I want to say thank you to both of you for coming on the show and sharing with us sort of the origin story of Ingonyama, a little bit about your backgrounds, how it fits into this larger ecosystem and some of the trends. And then, yeah, thanks for sharing a little bit about the work you've been doing recently. 1:14:42: Omer Shlomovits: Thank you for having us. It's been a pleasure talking to you, Anna, as usual. 1:14:47: Anna Rose: Cool. 1:14:48: Yuval Domb: Definitely. Thank you. Thank you, Anna. 1:14:50: Anna Rose: And I want to say thank you to the podcast team, Rachel, Henrik, and Tanya. And to our listeners, thanks for listening.