On The Brink with Castle Island - Eli Ben-Sasson and Uri Kolodny (Starkware) on Scalability with STARKs (EP.327)

Episode Date: June 20, 2022

In this episode, host Ria sits down with the co-founders of Starkware, Eli Ben-Sasson and Uri Kolodny to discuss how the team is leveraging STARKs, or validity proofs, to unlock a magnitude increase in scalability. We discuss: The differences between Starkex and Starknet and how the two will converge Enabling functions and applications that cannot be built on monolithic layer 1s Why data availability is important to zk rollups and the trade offs of different approaches Simultaneously solving for computational integrity and inclusive accountability To learn more about Starkware, visit their website.   Intro and outro used with permission: Collage #346 by Daniel Allan

Hi everyone. This is Ria from Castle Island Ventures. Today we had the privilege of hosting Starkware co-founders Ellie Ben Sassan and Uri Klaadni in the next episode in our modular blockchain series. Starkware is leveraging Stark proofs or validity proofs to unlock a magnitude increase in computational scalability via StarkX for application-specific execution and the public Starknet for just a general purpose execution, while simultaneously working on integrating the two systems to create a three-layer stack that offers security, but also control or sovereignty in designing the computational environment should app so choose. We cover house darkware intends to do this,

as well as the advantages and challenges of architecting a new programming language that's optimized for zero-knowledge roll-ups and validity proofs, how starkware enables functions and applications that couldn't previously be built on monolithic layer ones, the different approaches to data availability, as well as the trade-offs of each, and how computational integrity and inclusive accountability go hand in hand, among many other topics. Ellie and Uri answer my most basic questions while also breaking down more technical concepts in a really easy to understand manner. So let's turn it over to the conversation with them.

Welcome back to On the Brink. This is Ria from Castle Island Ventures, and today I have the pleasure to host Ellie and Uri from Starkware on the podcast for the next episode in our modular blockchain series. First of all, congrats on your recent fundraise, and thanks so much for joining us as the next guests in this series. Thanks for having us. So I actually remember writing about StarCware back in March of 2019 when I was at Circle, working on Circle Research.

And I think back then you were working on Stark decks with ZeroX and Stark Pay and exploring how Starks can be applied to different applications to increase scalability. So it's really awesome to have you on. and it's incredible to see how Starkware has grown and evolved since then and really found a killer use case for Stark proofs and validity proofs and roll-ups, all of which we're going to get into. But before we dive into Starkware, as well as before unpacking some of your views on the modular blockchain thesis and landscape, can you both quickly give us an intro,

what led you down the zero-knowledge cryptography path? And how did you ultimately find each other and decide to build Starkware together? I'll start with to find each other. So we found each other for better or worse more than 30 years ago. We're good friends since a long time. And so that's how we found each other. And so we studied computer science together. We knew each other even before that.

Uri went on to study business and be an entrepreneur, and I dabbled with math, which is how I ended up doing research on cryptographic proofs. Initially, all in the field of mathematics and theoretical computer science, but at some point I started veering a little bit into academic implementation of some of these systems. And then in 2013, I swallowed the red pill of blockchains at the Bitcoin conference in San Jose, where I realized that actually this technology of cryptographic proofs can be tremendously helpful in blockchains, both for privacy and for scalability reasons.

So immediately after that, with colleagues, including one of our other co-founders, Alessandro Kiesa, both he and I and a bunch of others were on the Zcash founding team, which is based on a very cool cryptographic construction called the ZK Snark. But we continued doing research with another of our co-founders, Michael Riabtsev, who was my PhD student at Technion. We came across a far better and more future-proof and scalable technology called ZK Starks. And then it was time to put this technology to good use. And so, you know, no better co-founder than my very good old friend, Uri.

And so that's how we got back together. Ellie, you brought up snarks, which are the proofs that are used by Zcash. I want to go back to the basics for a second. Could you quickly go over what is a Stark proof? what is this narc proof? How do they compare and contrast? And what are some of the tradeoffs? Yeah, so I won't go into the very intricate math of either of these,

but I'll try to give some very high-level and inaccurate explanation of the difference between the two. So there's this beautiful story called The Empty Pot, which is a story about integrity. and in it the emperor hands over seeds to children in order to grow a flower and the child with the most beautiful flower will be picked to be the next emperor. Well, all children come back with beautiful flowers, but for one, this one child comes back with an empty pot, and lo and behold, this child is elected to be the next emperor because the seeds that were given to the different kids, were all cooked by the emperor, and only one child operated with integrity

and returned with the honest result. So this story actually describes a little bit how snarks work. In the world of snarks, there is some secret that is baked, and everyone is given these seeds that come out of this bake-off. and then if you operate with integrity incorrectly, you can get a valid snark proof. Now, Starks work differently. There's no secret. There's no trusted setup.

There's nothing like that. It involves a different kind of math and is more like polling an election. You can poll the correctness and integrity of the computation. So that's the core difference between Snarks and Starks. Okay, great. That's definitely the first time I've heard that analogy. but I think it did a really great job of illustrating the core concept at least. So initially you were working on using Starks to scale specific applications,

and you still are via Stark X. Could you talk a little bit about how you're applying Starks to application-specific use cases and how you've unlocked scalability to date for applications like DYDX, Immutable X, So Rare, and so on? Sure. So we started out by introducing StarkX. It actually went live on Ethereum Maynath exactly two years ago in June of 2020. And we started out with a simple use case for our scaling solution. That's spot trading. So StarkX out of the box supports a bunch of use cases that have grown over time as we encounter new customers with new

of business logic and new needs, we gradually expand the scope for StarkX. And in order to do that, in order to allow StarkX to support these different use cases, I'll just sort of quickly run through them. So, you know, Diversify does spot trading, DYDX, of course, does perpetual contracts, Serere and immutable, do minting and trading of NFTs, seller recently launched a defy-flying service, pooling service and there are a bunch of other folks in the pipeline building and about to launch with these different use cases. All this is powered by a language that we actually developed at Starware. That language was developed as a necessity. It's called Cairo. You may have heard of it.

It was developed as a necessity because up until that point, in order to represent, to generate a proof, for a particular sort of logic, a particular computational statement, we had to basically design its own set of, well, to represent it mathematically with a set of polynomia. We won't go into the nitty-gritty details, but representing a given piece of business logic, a given computational statement,

in a form that would allow us to generate a proof for it, was prior to Cairo a very dangerous task, a very complex and dangerous task. Dangerous in the sense that you could easily in the process end up proving a slightly different statement than the one you intended to prove. And that, of course, would be bad news. So in order to avoid that, we invented Cairo in house, and that powers Stark X. But then the sort of the next logical step was to say, hold on a second, And instead of Cairo being used strictly by Starkware folks, let's open it up to the world.

And that's how StarkNet was born. Starknet is a permissionless roll-up. It's been live on a public test that since June of last year. And the alpha went live on Maynet in November. And it's developing very rapidly. and there's an astonishing amount of developer interest in exploring all sorts of applications and tooling around starting that.

So you actually brought up one of my questions, which is that there's this challenge that's been raised when it comes to zero knowledge roll-ups around EVM compatibility. Is that what you were referring to? Is that the crux of it, which led you to build or a development, develop Cairo? No. So, you know, EVM and solidity is, of course, the software stack that Ethereum and a bunch of

other chains runs on. We concluded when we started to build Cairo that insisting on being EVM compatible would, of course, serve one particular need, and that is to be able to address the needs. of the solidity community as it stands today. But being able to actually sort of rebuild from a clean slate would allow us to build something which is much more performant and bring to market something much sooner. I mean, the proof is in the pudding in the sense that

there are a bunch of folks who have been talking about various forms, ZKEVM, we have been on a public test net with proofs since June of last year, as I mentioned, these other folks are not, I think, not anywhere near a public test net, but alone main net. And the reason is that it's a very hard problem that they're trying to solve. What we see, in fact, it was far from certain when we launched darknet, but what we we've seen since is that developers are actually perfectly happy, looking, trying, and in fact building out a new tool chain. To the extent it offers them a new capability. And StarCnet provides developers a completely new set of tools in the context of the blockchain.

It basically does away with the gas limitation paradigm as solidity developers have sort of been brought up to live by. That has been the dominant constraint for solidity developers, essentially since day one. And in Starknet, that is to a dramatic extent no longer, no longer in or will at some point will become a non-issue. And that gives rise to a whole bunch of applications that no one would ever dream of deploying on an L1.

We see that over and over and over again. We had a hackathon a few weeks back in Amsterdam. One of the most beautiful things to watch was that all the, you know, all the, you know, looking at sort of the finalists, half-dozen finalists in the hackathon. They all did stuff that conceivably would be impossible to do on layer one, meaning it's not that we came to the hackathon and what we saw was people building more scalable, more performant variations of what was already previously built on layer one. What we saw was a complete, sort of a fresh start and an attempt to innovate in all sorts of exciting ways.

In your situation, building like a purpose-built language for Starknet actually allowed you to kind of move faster. Many might have heard that it's difficult to implement general purpose smart contracts within a ZK roll-up. And you've kind of managed to address some of those challenges and deploy Starknet so quickly. Is that part of the reason? and then could you talk more broadly about why that's the case? Yeah, so people who want to deploy smart contracts on Ethereum usually have to learn solidity and write their logic in it, not because there aren't better, more established languages like Python, Rust, or C++,

but rather because Solidity is a very, is a language that is catering and built to satisfy the exact constraints of the system called Ethereum. Now, validity roll-ups in StarkNet, based on the Stark Technology as such a roll-up, have a very, very different set of constraints. Some of them come from the cryptographic and mathematical nature of Stark proofs. Others come from other areas, but they have a very different set of constraints. And because of that, the best way to harness and reap the matter, maximum amount of scalability in the fastest way in our judgment judgment has been to define a new language.

So once we have this new language, which is in some ways a very minimalistic language by design. But once we had this bare bones language in hand, it allowed us, first of all, to write logic for amazing systems like, you know, D-Y-D-X and Surere and immutable very quickly. And it also allowed us to write the logic for Starknet. So a new system, in our case, Starks, leads to a new set of constraints. And we thought that the best way forward is to define a new language that is suited to satisfy these constraints in the best way. And that's what led us to this feature velocity that we're now displaying.

One advantage that obviously EVM and Solidity have around them is the tooling that's been built for developers over the years. Is Starkware developing tooling around Cairo internally, or are you working with teams to kind of build a similar stack that makes deploying code more seamless for developers? So that's a terrific question. The good news is that tooling that we're... was to a great extent non-existence, say six months ago or nine months ago, is moving very, very rapidly. So just a whole bunch of, and we're extremely happy and encouraged by the fact that this is a community effort in the most sort of organic of ways, meaning a whole bunch of teams outside of Stark, we're building rather frantically.

So just to give a bunch of examples. So let's see, three full node efforts, a block explorer, Snapshot yesterday announced their indexer, Lambda class a couple of days ago and announced their best implementation of the Cairo virtual machine, half a dozen auditors, you know, I mean, left and right, there are people building libraries, there are people building tooling for facilitating the formation of applications on Starknet.

And, you know, it's initially we were sort of at the coordinating sort of point in this effort, but right now they're running fast and on their own. to mention a couple of, and counting wallets. I forgot to mention multiple Oracle efforts, some of them native to Starkman, also on the wallet front, both teams migrating from other chains and native efforts on Starkman. So taking a step back, it would be great to maybe walk through an example of what happens when a transaction takes place on an application like a D-Y-D-X or an immutable X deployed on Stark X from start to finish and then compare that to what happens or what will happen from start to finish when a transaction.

takes place on an application deployed on Starknet. Okay, so the process is pretty similar. I'll specify it first for a Stark X system and tell you where the difference is now and going future going to be for Starknet. So as a user, you sign some transaction and then your wallet signs it and it's transmitted from your smartphone to some mempool.

Now, in the case of Immutable X or D-Y-D-X, this mem-Pool is actually managed by either Immutable X or D-Y-D-X. And at some point, there's, let's say, a settlement or this transaction is actually processed by the operator and sequenced. So it is now, you know, it's deemed to be valid, and it looks good, and you want to basically change the state of the system based on this thing. Suppose you sent Uli an NFT, right? So we need to change the database to reflect that the ownership of the NFT has moved from you to URI.

Okay? So the operator does this change. And now this sequencer, which is right now immutable or the way the X, has a batch of such transactions, and it needs to be proved. So it's sent this large batch of many, many transactions, including yours, is sent to a prover machine that is right now operated by Starkware. A proof is generated and then sent to the blockchain. The blockchain has a smart contract for a verifier, a Stark verifier.

The verifier verifies the correctness of the proof, and now the state of the system is updated. So this is how it works today. Now in Starknet, it's going to look pretty much the same. The only major difference is going to be that instead of having one single operator sequencer, which is D-Y-D-X or immutable X, it's going to be like an Ethereum. It's going to be basically a network of nodes, that any one of them can be the one who's processing and sequencing a large batch of transactions. And then the other change is that the Prover as well can be, it's not going to be StarCorp,

it can be any other machine that is running a Prover. a prover code and generates a proof for such a code. So instead of having D-Y-D-X be the only sequencer and Starkware being the only prover, in Starknet, you move to a world where anyone can be the sequencer and anyone can be the prover. But other than that, the flow is the same, meaning security and finality are ultimately given by having a verifier on layer one Ethereum, verify a proof, and only then is the state of the system, the L2 or the Starkey system, updated.

Got it. I think one thing you mentioned during that explanation was that the sequencer waits to collect a batch of transactions before a proof can be generated so that the cost per transaction is kept low. So I guess how long does it take to accumulate a batch of transactions and then settle it or verify it on chain? So that depends on many factors. And here again, StarkX and Starknet are going to look very different.

So on Stark X, we let the operator decide. at which frequency she wishes to choose to close a batch and start approving. And then different customers choose different time periods. And then they also have different rates, the rate of transactions and also the sort of the variance in the way transactions arrive on DYDX, for instance, are very, very different from Immutable X. Because to give one example, Mutable X services, a lot of games, and often they have like a minting season, right?

So during a very short time, you have huge throughput of transactions, and then it's much lower. Whereas D-YDX is a trading system, so it basically varies with the trades. So to sum this up, on the Stark X systems, each of our customers, who is an operator, decides on the size. Now, in StarkNet, it will likely look a lot more like Ethereum, which means that there is one block per some quant of time, the exact size we don't know. And then different blocks are going to have different sizes. As you have more congestion, sorry, more transactions. So you'll see larger blocks and then you'll see smaller ones when there's less.

The big difference with Ethereum or Bitcoin for that matter are that currently we don't foresee any reason to put a limit on the gas size or size of a block because basically, you know, As far as we can see right now, proofs can scale to deal with nearly any size of batch. So you could have very, very large blocks. And is it correct to say that the amortized cost per transaction goes down as the number of transactions in a batch goes up? Could you correct me if I'm mistaken and then explain that a little bit? You said it exactly right. And it even goes down, it goes down to zero, so it converges to zero, the amortized cost per transaction.

And it does so in an exponential way. So let me explain. The size of the proof is roughly logarithmic in the number of transactions. So if we just work with base 10 logarithm, just for just. for simplicity. The logarithm of a thousand is four, sorry, three, sorry, the logarithm of a thousand is basically the number of zeros. So the logarithm of a thousand is three, which means that, you know, the size of proof would be, let's say, three units, let's say three million gas, but now it's divided by a thousand transactions. So three million divided by a thousand, I mean, help me out here,

3 million, 1 million, it's 3,000. Okay. So taking this, if we have a batch with 1,000 transactions and you pay 3 million gas, it means that the amortized cost per transaction is 3,000. Now, if you have a batch with a million transactions, which is 1,000 times more, the logarithm of a million is actually 6. So if the cost of such a proof is 6 million gas, now the amortized cost, you paid 6,000, million gas, but you covered one million transactions. So the amortized cost has gone down from

3,000 gas to six gas. And with a billion, it's even better because now you have 9 million gas covering one billion transactions, which is in the sub one gas per transaction. I want to add to that. Maybe it's worth emphasizing that this property of our scaling solution where marginal cost per transaction goes down as the scale increases is a very unique thing. And maybe it's underappreciated that in the monolithic layer one solutions, and we've all seen this play out on Ethereum time and time and time again, and I think that we will see it in other layer one attempts once those start reaching capacity or introducing fees for that matter. Once those systems reach capacity, marginal cost actually goes through the roof.

These systems just, they blow up essentially. And so this diminishing marginal cost is really a very unique property. And with recursion, what's interesting is that typically there's a trade-off between scale and latency. In our case, actually, these two will work in union. and improve at the same time we will, by using recursion, will both improve scale and cut down on latency. I was lucky enough to attend the modular blockchain summit this year, and Uri see you speak and introduce terminology around what you're calling layer three. So could you guys talk about what is layer three and how does that fit into Starkware's plans to connect Stark X to StarkNet?

Sure. So layer three, layer three is sort of a very simple concept. So why do we call the layer two's layer two? We call them layer two because they rely on the security of layer one of the Syrian. They make use of that layer to obtain security. and they in the layer two we essentially offer scale now just like stark x settles on layer one ethereum today and like just like the public stark net settles on ethereum today and by the way like other layer two settle on ethereum today you know of course

arbitrum and optimism in zikasink etc in a similar fashion you can think of of what would happen to a system that instead of settling on layer one would settle on the public start. And this conceptually could be thought of as moving one layer up, hence the name, layer three. So what would be the benefit of that? One obvious immediate benefit would be greater scale, lower gas per transaction. Gas per transaction is pretty impressive as it stands today, just to remind our listeners is D-Y-X, we're talking about tens of millions of transactions.

D-Y-D-X in production on Maynet is at 480 gas for transaction, immutable and so rare are minting NFTs at less than 10 gas per transaction. This is with off-chain data. D-YD-D-X is with on-chain data. So already, gas per transaction is very, very low, but layer three will improve that further. but I think that the interesting property, and if you were there in Amsterdam, Ria, then apologies for the replay, but I think the interesting story there is actually around control,

allowing applications to have better control of the environment that they operates. And what we've seen, and this is not limited in any way, to say web 2 companies that come in with all sorts of business models and constraints and practices where they have a stronger preference to maintain control relative to native Web 3 applications. This is also true for Web 3 applications. They need control. They need control over the environment in which the computational environment that they operate. Specifically, they really don't like noisy neighbors.

And the beautiful thing about noisy neighbors is that we all think of our neighbors as noisy neighbors. And of course, that holds for all of us, right? So we're often the noisy neighbors, right? So if board apes are minted on the other side of the chain, that suddenly is noise for the D5 folks. And if Uniswap is blowing up, then, you know, the NFT players are looking around and saying, well, what's all the commotion? applications need control over the computational environment that they operate and they don't like noisy neighbors it gets in the way of business it disrupts the ux and i think that layer three is going to be the

environment where applications come to thrive this is a rehashing in a way no pun intended of of concepts like app specific chains side chains you know cosmos universe had these concepts, Pocodot, et cetera. One huge differentiator here is that these layer three environments all eventually going all the way down rely on Ethereum's security. And as we saw, say, with the Luna meltdown, and this has nothing to do with the Ponzi-esque nature of that story. But as we saw with the Luna meltdown, a side chain that relies on its own token

price for its security, that presents a very precarious position when that asset tanks in value. So I just want to make a clarification here. I'm kind of going through this exercise with you guys. So deploying an application on this layer three, the execution takes place in the L3, the computation takes place in the L3, and and the proofs would be settled to Starknet. Is that right? Correct. And then that's distinct from deploying an application directly on Starknet,

where the execution is taking place on Starknet as well. I'd like to call it the public Starknet in the sense that we fully expect, in fact, we're in the process of developing these solutions with design partners and applications. We fully expect to find custom Starknet deployments in layer three. So I at this point are retro naming the layer two, we call it the public Starkman.

Got it. Okay, that's super helpful. So since this is an episode in the modular blockchain series, I'd love to get your take on the full stack. We talked about Starknet, which is the general, public execution layer. And I'd love to get your thoughts also on data availability and consensus and settlement. But before we do that, could you explain why data availability specifically is necessary and

important and crucial for zero knowledge roll-ups or validity roll-ups specifically? Yes. So validity roll-ups, and things like stark proofs, they really speed up the process of verifying and checking the correctness of a computation. And they do so by an exponential factor, which is great. However, directly, they don't apply at all

to any compression regarding storage. Meaning that if... So, like, you have a situation where you have a technology that completely resolves or almost completely resolves or drastically improves, exponentially improves one aspect of what a blockchain is, which is computation, but does very little to resolve other bottlenecks, in particular storage or consensus.

So that's why you need some solution for limiting or pricing in the right way or finding other means for expanding data. availability on a validity roll-up. I mean, otherwise, you'll have, you know, to really scale up a system, it's not enough to open up one bottleneck. You have to open up all bottlenecks. So validity proofs are opening up one bottleneck of computation, but you still need to address the other bottlenecks like data availability.

But fundamentally, why do you need data availability for validity proofs? Because otherwise. you will be in a situation where state will be forgotten. So, for instance, suppose my account is some information residing in the state of the system. Now, the validity proof aspect means that no one can steal, you know, take my funds and put them elsewhere, right, without my signature. But the system could simply forget and lose the information about my account. count, like, you know, just no one knows anymore what is the public key of my system and where exactly it sits in the system. And then even though it's a lesser threat, because it's not

one of theft, it's one of, you know, loss, it still is a big problem, right? We don't want to be in a world where the system tells us, oh, sorry, we just don't know where your funds are. You know, no one stole them. We can promise you that no one stole them, but no one knows how to retrieve them, right? That's not good enough. Reha, if I understand correctly, you're asking why conceptually is there a need for different data availability solutions with validity roll-ups? That was my next question, but what Ellie said just now is what I wanted to get at because I think, yeah, there's this misconception sometimes that you don't necessarily need data availability because you verify everything and then, you know, post the proof on chain. And so, like, what is the purpose? And it's kind of exactly what you said, Ellie.

So, yeah, let's kind of segue into the next question. You know, you both mentioned this now. And I think also it was a takeaway from my conversation with Nick from Celestia and John about fuel labs, is that to unlock orders of magnitude increase in scalability, you need to optimize both the data availability and the execution. layer for scaling to unlock the full power of roll-ups. So roll-ups specifically post both the proofs and the data behind the proofs on a single layer like Ethereum, right?

Yes. And then there are different permutations around storing proofs on chain and storing data elsewhere, either off-chain or on a different chain. Could you walk us through each of these structures and then, the pros and cons of each one. Maybe I'll start with a motivation. The motivation, I think, is rather obvious, but worth mentioning. Chains, whether layer one or layer two or layer N, doesn't matter.

These chains are a public utility and a very scarce resource. Now, this is a resource that typically the different players compete for it in terms of in gaining access to this, determined by market pricing. And so you may well find a situation where your application, because of the value of the assets, et cetera, is priced out of this scarce resource. Now the question is, you know, what do you do? Right?

So you could say a board ape worth a million dollars, you know, can easily reside on chain in terms of its owner's ability to spend the gas on that. but an NFT worth a dollar may completely, very readily find itself priced out of the market. And so that data needs to reside somewhere, and that could be all sorts of different solutions. We think data availability is a very rich design space. We've had Validium, which is the off-chain data availability mode, where data is stored by a committee of reputable entities who sign per batch,

who sign that they have the most recent data, and their commitment to the public is in case the applications operator and the proof generator, say, in this narrative, that would be so rare and startware, or immutable and starkware. If those suddenly are unresponsive, then the committee member's commitment to the public is to post the data in a public place. By the way, not on-chain. Many people interpret that to mean on-chain, but no, they can just post it on their website and allow anyone to access their vaults in the system and get the Merkel path from those vaults to the most recent Merkel board of the system.

take that Mercl path to the smart contract on-chain to retrieve their funds. So this is off-chain data. It's not as secure as on-chain data. It's, of course, not as expensive. And we find a very decent compromise. In fact, actually, it's not that we find, Stark X out-of-the-box supports multiple data availability modes. Our customers find that this is a very decent compromise. The coming versions of Stark X, this is actually the very next version of Starkex that will be deployed on Mainet in a couple of weeks, will be supporting Volition, which is this hybrid mode, where the choice, instead of being in the hands of the application,

whether it wants to operate with off-chain data or off-chain data, that choice actually is handed over to the user at the single-transaction level, which makes it, I think, a lot more fun. So, you know, I keep, this is going back to my childhood. But, you know, so, you know, if you have the, it's not only that if you have the Mona Lisa, you want that on-chain and you have some, you know, cheap NFT, then you don't mind that residing off-chain. If you've won the golden ticket and Charlie in the Chocolate Factory, that thing started its life off-chain, but once you realize that it's very valuable, you can now transfer it on-chain. Got it. So you, as Starcware, kind of agnostic to the specific sense.

set up and in the future when, you know, Ethereum is more optimized as a data availability layer and Celestia launches. And then, you know, there's more progress on Validium's and data availability committees. The choice will be left up to the user. Exactly. When we came out with Validium, we were attacked left and right, there was a lot of, you know, pontificating going on. We found that to be completely irrelevant. Blockchains are a tool that, you know, serves users, not the other way around. And our business is to build something that is of utility to as brought a number of users as possible. And it's just by definition, not all data can go on chain. And so the question is, how do you solve the problem for

everyone else. Do you think that introduces like complexity from a U.X perspective? You know, obviously this is theoretical right now, but how do you hope and envision that looks like in having the choice as a user and having to understand maybe the trade-offs of the different options available to them? So, you know, at the most sort of mechanical level, I don't think that is a huge ux challenge in the sense you know imagine a gaming application etc so you can have you know that the safe vault more expensive the lesser vault less expensive but communicating to the to users whatever kids playing a blockchain-based game exactly the significance and the implications of of the different solutions. I think that's going to be trickier.

But if we're honest about this, we often are faced with us, situations where I don't think we fully understand. We don't fully understand the difference between being deployed on multiple, whatever, GCP and AWS zones or not, in terms of assessing the risk, et cetera, and the risk benefit tradeoff. We just sort of get you know, get you. to sort of living without degree of uncertainty.

I'm guessing that in this context, that may well be the case. It could be that professional users, high-frequency trading firms, et cetera, develop a much more intimate understanding of these tradeoffs. But I suspect that teenagers, for a good reason, and fortunately, will remain teenagers. You mentioned a few times that Starknet kind of unloaded, the ability to build applications that we haven't even been able to dream of deploying to monolithic

L-1s. It would be great to, if you could talk about a few examples of what some of those applications are. Yeah, sure. So there's just, there's mind-blowing stuff, right? So, for me, the first time that, so there's a wonderful Stark and OG by the name of Guilty Gioza, that he goes by, Guilty Gioza, that's his handle. And he's building all sorts of tooling for gaming, by the way, it was also for physics simulations,

that rely on Stark's basically giving verifiable computation, in that domain. Now, what could that mean in terms of verifiable computation on the blockchain? It's a wonderful question. I don't think we're even scratching the surface there. But I keep reminding people that in the context of Ethereum, computing on-chain a moving average on Ethereum is an exceedingly expensive exercise. So if you come from a world where computing a moving average is something that

you handle with care, if you can now start considering what game mechanics you want to be verifiably computed and whatnot, you're in a very different realm. So that's one example in the area of gaming. Another more recent example, Fran Al-Gaba put out Giza, which is this tooling for starting to build the stack for machine learning over blockchain. And here, too, you know, two very, very useful pieces of technology that no one could really conceivably combine up till now. And suddenly there is an intersection to these two circles. And people start saying, huh, you know, so hold on a second. Where do I use machine learning and actually expect my users to trust me?

Because there, if that trust requirement is menacing as getting in the way of business, maybe we can turn that into a verifiable computation. I want to go back to one thing that Ellie, you brought up in the beginning, which is the use of Starks for scalability versus privacy. And I think there's a misconception right now that, and, you know, people have been trying to change the terminology and say we should call them validity roll-ups or validity proofs and focus on that aspect.

When does privacy enter the picture? That's a terrific question. In my view, it's when the market asks for it. And there's this well-known paradox in which we all say, yes, we want privacy, but we're actually not really willing to pay the price of it. And this is also true in blockchain. I mean, if you look at the privacy coins, you know, Z-cash, Monero, Tornado Cash, and so on. The markets are not valuing them at such a high premium.

And it's not like they conquered the world and everyone's moving over to them. I think all of the top 10 coins or maybe even top 20, none of them are privacy coins. So this says something. This says that the market isn't demanding this kind of privacy first. So now to answer your question, at least here, in Starkware and it's Starknet, privacy is going to be added when users need it. From a

technological point of view and cryptographic point of view, making the Stark's zero knowledge is a very simple process. And even today, even though they're not formally zero knowledge, the proof itself doesn't reveal all that much. What is

much, much harder is to build a user-friendly and usable system, that has privacy ingrained very deeply into it, just to give some examples. I think that a lot of exchanges and ramp-ons and ramp-offs or cryptocurrencies are probably not going to be well integrated with such things. You probably need ZK proofs to be generated on wallets, hardware wallets and mobile phones and so on. And to best of my knowledge, this isn't the case right now and certainly is not the case

with popular wallets such as, you know, Metamask or Ledger or things like that. So any team that wants to deliver true privacy will need to tackle these things, and it's a very daunting challenge. So we at Starkware are focusing first on scalability, which is a much more burning need that everyone sees the value in it. we would love to be in a world where everyone demands and is willing to actually pay in like user experience and so on for privacy. But the reality is that we're not there yet. What does the next year, what's the focus for Starkware for the next year?

And where do you envision Starkware, Starknet, StarkX, L3s, three to five years from now? We're very practical. So the next year is a lot about making Starknet better. In terms of functionality, we're pretty happy with functionality it has, but then the phase we're now focusing on is increasing throughput, reducing latency and so on, reducing advertised cost per transaction even more. And right after that, it's going to be all about decentralization, which means getting this network of operators and provers.

Within StarkX is going to be, you know, improving, again, the just a set of attributes and properties that Stark Exist and has for its customers, bringing them on to layer three, integrating that into StarkNet itself. But beyond that, I mean, ultimately what we're delivering is a new technology, a groundbreaking technology for integrity, which means doing the right thing, even when no one is watching. and we strongly believe that the world, the larger world of traditional financial institutions, healthcare and so on, could benefit from these better technologies for integrity. So we think that either by some of these big players entering blockchains and wanting this level

of integrity at scale, or by adopting, you know, Starks and similar technologies outside of the blockchain, we think it will go further than just blockchains. These concepts of computational integrity and inclusive accountability have been in your DNA since the very beginning. So I'm very happy you brought that up. And yeah, very excited to see all of the innovation that Starcware unlocks. Yeah, and it's really, I mean, it's really about, so blockchains are all about inclusive accountability,

about basing trust on inclusively allowing everyone to know that everything's okay, and that limits scales and also privacy. And what Starkware is about and Starks are about is all about computational integrity at scale with no trust assumptions. And we do this, we deliver this through math. And, I mean, math made accessible to end users. So our mission is integrity through math. Blockchain's mission is inclusive accountability. and a basis of trust that is more democratic, fair, and inclusive.

And the two go together really well. Like macaroni and cheese, I guess. Exactly. And that is, I mean... It's cucumber and the salad or... Sorry, cucumber and tomato is something maybe better. Yeah, yeah, exactly. And I think one thing that I tried to do in this series

is like really define what scale, like, true. scalability means. And it's not just an increase in throughput, but it's an increase in throughput while being able to maintain that inclusive accountability. So precisely, precisely. Because if you just want to increase throughput, there's a very easy way. If you just want to scale, you can do that very easily at the cost of making things more exclusive. You just tell everyone, okay, go buy a computer and an internet connection that is 100x bigger, faster. And then, then you end up in the conventional world with, you know, Visa and Swift. So that's an easy route.

You want to still be able to rely on everyone checking things with their laptops and still have greater skill. That's the challenge. Well, Ellie and Uri, thank you so much for coming on and going through all of those thought exercises with me to really understand the moving parts. It's been an absolute pleasure. I've been wanting to have you on for a while, so I'm very excited we can make this happen.

Thank you. Thanks for having us. Ria, thank you very much. Greatly enjoyed this very intelligent set of questions.