Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Eli Ben-Sasson: Starknet - zk-STARKs and Cairo 1.0 upgrade

Episode Date: June 30, 2023

Layer 2 zero knowledge roll-ups have initially been used for achieving private transactions on blockchains. However, past simple transfers, interacting with a public smart contract posed a serious challenge. As research and technology evolved, proof construction became much more efficient, enabling zk-powered scalability. There is a variety of pros and cons for each type of proof system, but given the impending rise of qunatum computers, we have witnessed a recent migration from SNARKs to STARKs. While the former relies on trusted setups, zk-STARKs are quantum-resistant.We were joined by Eli Ben-Sasson, co-founder of Starkware, to discuss Starknet's layer 2 architecture, as well as the upcoming update to Cairo 1.0 and how it will impact scalability performances for STARKs.Topics covered in this episode:Shifting from privacy to scalabilityZK roll-up taxonomy and main differences between SNARKs and STARKsWhy scalability is easier to implement than privacy solutionsConstructing proofs efficiently in CairoStarknet’s layer 2 architectureBuilt-in account abstractionVolition, data availability and trust assumptionsSequencer decentralisation and crypto regulationsStorage proofsCairo upgrades & TPSCouncil-based vs. DAO governanceFuture developmentsEpisode links:Eli Ben-Sasson on TwitterStarknet on TwitterThis episode is hosted by Friederike Ernst. Show notes and listening options: epicenter.tv/502

Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Friedrich Erns, and today I'm speaking with Ellie Bensison, who is the co-founder and president of Starkware, the company building Stocknet. Ellie, thank you so much for coming on again. I looked into our archives prior to this, and you've been on twice before, once over seven years ago. And we talked about zero knowledge proofs, kind of introducing them to like a wider audience. And once again, three and a half years ago to talk about Star-wear. So it seems like three and a half years is our cadence here. Yeah, let's keep it up.

See you in three and a half as well. So in a nutshell, because we actually covered this twice already, you are an academic computer scientist and Web3 founder. you were a professor at the Techleon in Haifa when you became a co-founder at Zcash in like 2015 or so. And then you founded Starware at the end of 2017 with three other co-founders. Before we kind of dive into the recent upgrades

that Starkware and Starknet have seen, I find it interesting that you went from a privacy use case to a scalability use case. I mean, all using the same technology, but maybe tell us about the shift in your thinking of why you felt it was prudent to kind of move from the privacy to the scalability aspect.

You know, the first thing that jumps to mind to me is that I think the magic of scalability via proofs is much bigger and more mysterious and more mind-boggling to me than the magic of privacy. You know, not that the zero knowledge aspect is not extremely interesting and surprising, but the fact that a very weak computer can assert the integrity of a much larger computation in a way that seems to contradict, you know, mathematical theorems from the 1930s

that Alan Turing already proved about like the inability to really understand, computation and yet you have this magical ability to put in check a computer. That always fascinated me more. But then from a business point of view, I think that just scalability is a much better business. It's also a much greater and much more needed challenge in the world of blockchains, more so than privacy, which will come, but later down the road. Yeah, I mean, as you said, zero knowledge proofs are this magnificent ecosystem that's kind of flourished over the last, say, 10, 15 years. It's crazy. How much has happened? I remember exactly when someone told me about zero knowledge proofs for the first time. And I have a fairly mathematical background. So I don't think I'm easily due, but basically my immediate intuition was this is not possible. It's not possible that this exists.

So, yeah. It is extremely magical. So there are a whole number of ZK roll-ups now for Ethereum, right? So basically there's you guys, there's the ZK EVM, there's Aztec who were on two weeks ago. There's ZK Sync, loop ring, scroll, linear is coming out later this year. Do you have, in your mind, do you have a taxonomy? that you use in your head, how to kind of classify them, how to distinguish them. So along which dimensions do these various ZK roll-ups actually differ?

Oh, yeah, I have a few taxonomies. Okay, the biggest distinction is which ones are about scalability, so just making computation more efficient, and which ones are about privacy. And there it looks, that's the biggest distinction. So Aztec, which is an amazing team, is mostly about privacy or privacy with scalability, but definitely privacy is a very major component of their offering. And I think all of the others you mentioned are more about scalability, including Starknet. So that's the biggest difference.

The second line according to which I would differentiate them is, which core technology do they use for their proofs. And what it used to be, when we last spoke, it probably looked like this. Everyone was using rough 16 snarks based on elliptic curve cryptography with trusted setup and very short proofs. And only Starkware was doing this very weird kind of, you know, more future proof, but less well understood the technology called Stark's. Today, the tables have turned pretty much.

All of the scalability projects that you mentioned are either already working on top of Starks. I mean, Starks, our technology, the one that we are also using Starknet, and which we proudly invented almost all of the core components. So all of the Polygon teams, which are all very good teams, you know, Hermes, Maiden, Polygon Zero, they're all using Starks with a T. ZKSync team, I think, have already said that they'll move at some point. Risk Zero is using Starks, and there are a few others that are also out there warming their engines.

And those using Snarks, there are, I think, fewer of them. There's, of course, Zcash, there's, of course, Aztec, and a few others. So that's the second dichotomy, like are you using elliptic curve-based cryptography with trusted setups, or are you using things that are transparent and can work over any field and things like that? And the third dichotomy is along which computational model are you using. And a lot of these teams are ZK EVMs, which means that they are trying to prove solidity or EVM. by code. And we're of the smaller camp, but also has a few constituents. We invented our own language called Cairo that we're very proud of. There are a few others that are going down this route

of creating new languages that are more catered towards that. I think Midden is another one. Risk zero is another one. So that's the third big line. I want to talk about the languages in just a bit. But maybe let's talk about the shift, the general. shift from Snarks to Starks. So if I recall correctly, Snarks are more easier to proof and more difficult to verify. Is that correct? Or am I misremembering this? Yeah, no, no. So Snarks have two advantages. One is that the length of a single proof is shorter. It's around, let's say, 200 bytes or less than a kilobyte. That's one advantage. The second advantage is for very particular settings, they have a subsidy on Ethereum in the form of

a pre-compile, which costs only around 300,000 gas. But it's for a very particular setting, you know, very specific hurt. But everything aside from that is much more in favor of Stark's. Stark Provers are faster by, you know, several orders of magnitude for the same payload. They have leaner cryptographic assumptions, which is better that this makes them more future proof. They're post-quantum secure. They require no trusted setup, no toxic waste, and there are a number of other things. You can instantiate them over any field and so on and so forth. So, yeah, most of the good things lie or the better things lie with Starks,

but there is one mathematical property that's better with Snarks. It's the length of a single proof and one subsidy that in certain cases helps. Okay. So from the point of view of someone who's kind of been in the blockchain ecosystem for a long time, but not in this particular ZKP sub-bubble, it seems like the ZKP ecosystem has absolutely exploded onto the scene, right? So basically, I mean, it's usually the case that kind of things happen slowly first and then they happen all at once. But is this just kind of what it looks like from the outside? Or as you, you know, being someone who's been inside of it?

this sub-bubble from the get-go. Are you surprised how fast everything has advanced? No and yes. I'm just a ridiculously optimistic kind of person, which means that in my view, like, you know, I don't know, I or we live in the future. It's just the rest of who are, you know, getting here slowly. So it was clear to me that this will happen, that validity roll-ups and the use of cryptographic proofs, especially Starks, are like really, really essential and that you cannot really imagine blockchain catering to global demand without Starks.

I think this was the premise for the founding of Starkware. We said because we believe blockchains will need to service global demand. demand, and they need to do so without heightening the barriers needed for computers who want to serve as validators or just want to follow what's going on the chain. You can't 10x and 100x, you know, the throughput of Ethereum without, again, just making people go out and spend hundreds of thousands of dollars on compute. So it doesn't make any sense. The only way this can scale, again, without harming the basic assumptions of what is a blockchain,

the only way this can scale is actually through Starks. So it was clear to me that this will happen. It is, of course, heartwarming to see how much enthusiasm there is about it these days when we founded the company in 2018 was, of course, very different. But we never, you know, no one here at Stark were like, we're very proud that nearly all of the early, you know, founders and employees are still with us. And we all had this faith from the start because we knew this is going to happen. It will just, it will become even more dramatic, you know, over the next five years.

I have no doubt. While the Ethereum-based kind of layer to ZK ecosystem has kind of absolutely flourished, Zcash has kind of floundered a bit. Would you agree to that? Yes, sadly. Why do you think that is? Because basically so much of like the groundbreaking cryptography and kind of like the paradigms and so on,

they were all kind of, you know, put onto the scene by Zcash and they had like this incredible culture and kind of, but it seems like it's almost an empty ecosystem now. Why do you think this is? It's a good question. Let's see. What do I feel comfortable sharing? One thing that is objective is that privacy is very hard to solve, not on the technological side. Actually, the ZK Snarks and the ZK. Starks, that's the relatively easy part. When it comes to good U.X integration with existing, you know, modes of operation for what users want, that's a much, much, much bigger objective challenge.

And it's one of the reasons that we at Starkware are not doing, not like going down this sort of full privacy route. It's very, very hard to do. So I would say that objectively the challenge of privacy is, there's something about it that is just objectively harder. Yeah, let me just give that reason. That's fair. Can you extol on the U.S. points that you're referring to?

So what makes it difficult to kind of make good user interfaces? Okay. So let's start with the mere fact that, okay, you know, the way that you use Ethereum or Bitcoin by itself is somewhat cumbersome compared to the way you would use, you know, just mobile payment apps in a web tool. Right. So there's already like one level of difficulty. You probably need to go and buy some hardware wallet, write down a pass phrase, do that sort of thing. Okay, that's already daunting. Today, to best of my knowledge, none of these, you know, more standard hardware wallet solutions supports a shielded transaction. Okay. So like you have to go to yet another level of complexity that even for crypto native persons becomes very hard. If you want to generate zero knowledge proof inside one of these hardware dongles,

it's very challenging. And to best of my knowledge, again, none of them support it right now. If you go to the treasers and the ledgers of the world, they just don't support that. And then if you think about some of the really cool applications that took off on blockchain beyond payments, right? You know, uniswap and Cryptokitties and defy and Composability, if you just try thinking about what it means to make them privacy preserving. I mean, consider Uniswap, right?

Whenever someone interacts on Uniswap, right, the size of the pools should change. And so even if you put a zero knowledge proof on, you know, the transaction that did that, you're not really getting much privacy. So, and if you want to compose things, then it becomes even more challenging. So all levels of the U.S. just become so much more daunting. And I haven't even mentioned the regulatory aspects, you know, tornado cash. But even before that, the ability of exchanges to comfortably service on-ramping and off-ramping of shielded payments is a huge challenge. So that's what I mean when I say that it's just really, really complicated to get the U.X good.

Have you looked at the plans for Aztec 3? So basically they've got this entire spiel about having, you know, private transactions and public transactions and kind of private venues and public venues and so on. I mean, it's all not there yet, right? So basically we kind of have to go by what they're promising us. But have you listened to what they're promising? I have a lot of respect for the Aztec team, you know, for Zach and, you know, the others, I mean, Ariel and many of the others there at the technology is surely great. But I'll say this already up front. The big challenge they are going to face, the really big challenge is exactly that of UX,

of making it something that end users can easily work with. And, you know, it's an immense challenge. I wish them all of the luck. Surely the world needs that. So I support them and I think it's great. But I just want to say this. It's a Herculean amount of effort. And it's not about technology. It's about user experience, something very mundane, but extremely, extremely important.

So I don't know how the plan to solve it, but that's the challenge. I mean, everyone thinks user experience is easy, right? Because kind of using an Apple life, phone. It's just so intuitive, but actually coming up with the designs, obviously, is incredibly hard as proven by the fact that not a lot of people can actually do it. But even the technology that kind of, you know, goes behind it. And I mean, you said you're incredibly optimistic as to kind of what you can build in timelines and so on. I am the same. I think all founders have to be, because otherwise you wouldn't start.

And the ad-sac team, they even said that they will have this, that they will deliver this by the end of next year. So, you know, in blockchain timelines, yeah, this is, it's crazy. I'm also looking forward to it, so I think I'm super curious to see how it pans out. Yeah. Okay, so let's look at Starknet. you've got a couple of major upgrades coming soon. One is the upgrade from Cairo Zero to Cairo 1.

So you talked about the fact that kind of you guys have your own programming language, unlike, so for instance, ZK EVM, they just kind of take all the op codes and they kind of transpired them into a ZK version. And you guys, you came up with, you know, this domain-specific language, Cairo. what did you optimize it for? The initial version, by the way, now all of the code is the newer version called Cairo 1.0. The initial thing that the, what we call, well, Cairo Zero or Kazim Cairo Assembly was optimized for, was that of creation of the most efficient start proofs for a given computation.

So really, I mean, machine. in the end, they understand bits, right? So like there's this meme, real programmers program in binary. But of course, the whole point of programming languages is to be sort of a way for talented developers to express to machines or non-human in a way that's efficient and ergonomic and safe computation and so that the machines can do them. Now, in the context of validity proofs, such as Stark's, the important thing is not so much the machine that will carry out, but rather the proving process. So you want to run the computation, but then also be able to create a Stark proof for your computation very efficiently. And Cairo is an extremely succinct and efficient programming language or virtual machine that at the same time is also cheering complete. It has all the, it has the ability to run general computation, but it leads to very efficient

proofs. And, you know, side by side, the length of a stark proof of a computation created in Cairo is going to be probably, you know, between 10 to 1,000x more efficient than if you just take the solidity version of that thing and transpile it into any other proofs. system and prove it. So it's this efficiency that was the main thing we wanted to solve. Now, the second phase was to create a better programming language, one that is modern, ergonomic, pleasant to write in, safe, has strong, you know, safety properties that allow for good development process. And that's exactly what Tyro I has achieved. And the developers who are

now flocking to it or actually raving about it, including statements that say that it is a more pleasant language to write your smart contract than many of the existing alternatives. And along the way, you also get very, very high efficiency when it comes to validity proofs. When you look at the efficiency, do you have any, you know, rules of sum as to kind of how how kind of Cairo actually constructs these proofs? So if I were to do it manually, what are the rules I'd have to follow to kind of also construct efficient proofs?

Yeah, so the main complexity measure to consider when you're thinking about truths is how many finite field elements will you need in order to write down your witness that the computation went a certain way. And I'll give you, it's really, really good to think about things like hashes, because a hash is a very, a very basic crypto primitive that I think almost all of your listeners are familiar with. So if you think about one of the existing standard

hashes, shot two, shot three, Blake, that kind, you can ask yourself, how many field elements will I need to express the fact that I computed one hash correctly? And the number is on the order of tens of thousands to a few hundred of thousands of field elements to when all is said and done. And by the way, this happens both in the world of Starks and of Snarks and plunks and it's really an artifact of this thing that when these hash functions were created, no one thought about their proving complexity. So you have this hash function that will take you many, many field elements to prove. Now, in comparison, some stark-friendly hashes like Poseidon,

instead of being like 20,000 or 200,000 field elements per hash, they're around 200. To answer your question, the main complexity measure is how many field elements do you need to have in order to argue about a step or a block of your computation? And in this respect, what is unique about Cairo is that one step of the machine that is Cairo is less than 50 field elements. So with every step of the machine, you're only paying 50 field elements, whereas if you would go to an EVM model, probably with every step, well, depending what kind of step, but you'd probably be looking at hundreds to thousands of field elements for some of these operations. So that's really the big advantage of Cairo. So does it mean that if you compare Cairo to say ZKEVM, that basically ZKEVM can never be as efficient as a program written in Cairo?

Well, Kenever is a very strong statement, but I think for the vast majority of cases, if you want a certain functionality, if you take it and write it natively in Cairo, the amount of trace cells of these ZEKHAs, of these field elements that you will have to pay, which then goes on into the proof. To get the proof generated will be roughly 100 or a thousand times less than if you take solidity.

And I just want to say, it's not surprising. I'll give you another example where this would work. Someone could write a compiler that takes a C code or Java or Python and transpiles it into solidity, right? No one has done this because it doesn't make much sense. But if someone were to do it, you'd find out that if you write something in solidity or you write it in Python and transpile it, you're probably like, you know, factor 10 to a thousand X less efficient in the transpiling world. Yeah, that makes a lot of sense.

So maybe moving up from the stack. So what does the macro architecture for Stocknet? look at look like so we all know it's an l2 uh but give us the details so it's a layer two there are you know bridges and messaging between layer one of ethereum and layer two um there's because it's a very modern um um framework and because uh well it's stark where we're very very confident of our understanding of the technology um of both blockchains and of uh stark We baked into it to a number of things that are discussed in research circles in Ethereum, but are very interesting. So, like, one of them is we have basically account abstraction and EAP 4337 as the standard, meaning there is no EOA versus, you know, smart contracts.

all accounts are, well, you know, account abstraction. There is you should come and craft your own standard, which now leads to immense opportunities. You know, we were pleasantly surprised to see that the brilliant Visa research team used the Starknet in order to explore what account abstraction can do for end users on Visa, on the Visa, you know, credit card and payment network. This was not so much because of the Starks. It was because it's a very pleasant framework in which you have account abstraction baked into it. We're soon adding volition, which is this data availability spectrum. Users and applications can decide whether they want all of their chain recorded on layer one, which is safer but more expensive, or they want it to be recorded on layer two.

via a Validium model, and they can, you know, switch between the two. And again, this will be something very basic that is baked into the system. So the architecture is, you would say, a standard layer two, but with a lot of bells and whistles and modern things, you know, much more ergonomic, very safe programming language, which is Cairo 1.0. There's a count abstraction baked into it. things like storage proofs and volition and of course more will come.

Yeah, there's a lot to unpack here. Maybe let's go through them one by one. So account abstraction, just to kind of back up a little bit. I mean, it's basically it's the idea that you kind of, as a standard, you have a smart contract wallet rather than an externally owned address, right? So basically what it allows you to do is kind of both kind of onboard users more easily into the ecosystem because you can, for instance, custody their keys for them and onboard them, say, with an email address and you see the keys can be swapped under the hood later.

You can have things like social recovery, guardians. You can also do things on the UX layer, so things like kind of wrapping transactions together so that you don't always have this super annoying thing where you kind of need to approve something and then you need to send it in a second transaction and so on. Do you do you do you. guys have a guideline to Starknet DAP developers to kind of encompass these and kind of make use of them because kind of moving from other kind of blockchain-based ecosystems, this is not the standard. And kind of it requires kind of turning some of the things that you know and trust on their head, right? So basically, you need to be aware of these possibilities to kind of make use of them.

You're right. So you touch on a very important point, which is that, well, the sort of best practices and the exact standard by which users will transact on Starknet, because of the novelty of account abstraction at this level and the opportunities it presents, it hasn't been finalized yet. But I, you know, the optimist in me and the scientist in me thinks that this is beautiful because you have multiple teams working on beautiful, you know, UX experiences for users. You know, I've seen demos by Argent, by Bravo's two leading wallets on Starknet that allow very seamless social recovery and cartridge as well, another project in which basically you can

use your iPhone security technology, which is, you know, Apple and iPhone probably have the best combination of UX and security, right? So you can essentially port that over it, like basically use the very same technology to secure your contract. Now, you know, Friedrich, you're also one of the Gnosis team members. And of course, one thing we'd love to, you know, do, you know, after the podcast is to get your assistance with creating the analog of the Gnoses safe as a standard on starkness so that you'll have these capabilities. So it's still an open design space. I'm sure that there will be some beautiful standards that are going to just merge from the community as to how to do it. But you'll have, just to explain, of course,

have account abstraction, nothing prevents you from using the good old EOA model as a special case. And you could still use your, you know, favorite hardware wallet. But in addition to that, you'll also see new standards that I'm sure they'll look much more like your, the way you use your phone for doing transactions, but with much higher safety. Yeah, I think if you look at the user experience that we as an ecosystem currently offer to actual users, it's epistle. I mean, I'm totally with you. And I think that's really one of the areas

where as an ecosystem we have a ways to go. The other thing that you mentioned was volition, where I can determine what kind of information gets put on L1. So if I forego putting this information on L1, one, where is it put? So it is recorded among all the full nodes of Starknet. Yeah, so it doesn't give you the same security of Ethereum, but it's not like, you know, zero security or, but it is.

It's like, is it like another layer one? Well, one thing that we, we don't need to do with Ethereum, especially not at this phase is we don't need to have a consensus slayer, meaning so, right, full nodes, there are now, you know, thousands of full nodes being executed run all over the world. But we're not using them and also the beauty of validity proofs is you don't need validation and signatures in order to know that the right thing was done. For that, you have the stark proofs. However, in terms of just redundancy, the data on volition

will be replicated and available on all full modes as they process the chain and see what's going on. So I wouldn't say that it's another, I don't want to mislead listeners into thinking that you get the same security

level of layer one Ethereum. No, it's a trade-off. You can pay more and have the security of Ethereum, or you can pay less and have a level of security that is not as high, but is still meaningful. And the way to think about it is like, you know, suppose right now transactions on most L2s, they cost around. If they're not subsidized, they cost around, you know, half a dollar or so. And all of it is

because of the L1 costs, a lot of it about data. So sure, if you're, you know, if you have NFTs, for instance. So if you have like a very rare and valuable NFTs, sure, you do want to keep that on the L1 Ethereum and pay the half dollar. But if you're playing with a pack of cards, your favorite game, where you just paid $1 for all of it, you probably really want to keep it on the volition and pay whatever a cent or a few cents. So let me understand the trust assumptions here.

So do you, is this like an honest majority trust assumption or basically is it like on an L1 where if you run your own full node, you can't be duped? I think it's neither. So, okay, it's like this. Again, and this is just about if you save your data on volition. So what happens is that, and here also there's, there are going to be two stages. There's the current state right now and there's the state upon decentralization.

So the state that we have right now is that there's a single sequencer and prover that is centrally operated. and basically it receives the transactions, sequences them, processes them, and then transmit the block data to all of the other L2 nodes. So among it's along the way as it's transmitting stuff, it's also transmitting updates to the volition data set. But all the other nodes, all the other full nodes that are tracking this are basically just tracking the network and seeing that this is what happens. Now, this sequencer, even if it is malicious, it cannot steal funds.

It cannot, you know, move the system to a state that is invalid because it won't be able to generate a start proof that would be verified. So that's why we don't need the signatures and validation of the full nodes. They are just tracking the system. Okay, but it could censor you, right? So if you're just on volition, the sequencer could censor you. Well, irrespective of, okay, as long as you have a single sequencer, it could censor you, even if right now we don't have volition. And still, the single sequencer could maliciously decide to censor someone. What a malicious sequencer could also do when volition is turned down in about, you know, two months or so is it could move the system to a valid new state, but decide to not report this to,

anyone, right, in order to sort of, you know, freeze the system or a blackmail, all of the users or something like that. Right. So that's something that is impossible today, and it's also impossible with the on-chain data, but for the off-chain data, the fully off-chain data, a malicious attacker could do this sort of thing. You know, if you want to talk about threat models, this is the threat model that when users will be using volition in the same. single sequencer and operator state, this is the risk that they are assuming this is why they're paying lower costs. Okay, so basically what they forego is kind of the right to escalate something that the sequencer does to L1. No, it's just about hiding data. This, by the way, appears in any off-chain data models. If all of the, so for instance, the Starkick systems that we're running for many years now, some of them work with data availability.

So if all of the data availability committee members collude together, they can decide to move the system or sign on a state that they know, it must be valid because otherwise Ethereum won't allow, you know, the L2 state to be chained. So you can move the system to a valid state, but the data about it becomes unknown to the users. That is the type of attack that could be mounted before decentralization. And once you have decentralization in a year or so, this will go away because you'll have something a little bit more like an L1 situation where you need a majority of stake to collude on the L2 to collude to do bad things. Talk me through the sequence of decentralization because this is something that currently all L2's kind of face. They all have a single entity that kind of is allowed to build locks. So, yeah, so basically how are you going to kind of decentralize your sequencer? So the first thing we did was research. There's so much, the good thing about decentralization as opposed to Starks is that we don't have to, you know, blaze a trail. There's so much good research and so many good protocols that have been battle tested in practice, you know,

proof of works and proof of steak and tender mint and hot stuff. on. So it's really great. So the first thing we did was researched extensively which of these decentralized protocols works best. Of course, it's not completely, you know, copy-paste because we have, you need to adapt it to a layer two. And it's a layer two that also generates proofs. So there are like several moving parts here that are novel. And that's the stuff we focused on. So we're very close to finalizing the research phase and saying, this is what we're doing. It looks like it's going to be something tenderment like, but something that looks very familiar and is very well respected and battle tested. We're not trying to create new things in this case

because there's just so much good stuff out there. And once we finalize that, we'll of course publish it within the start community, get feedback, get everyone's approval, see that people, you know, kick the tires and are happy, and then we'll just start implementing it, which, you know, hopefully, I don't want to make predictions, but like, yeah, hopefully a year from now will be deployed or very close to deployment. But yeah, we're almost at the end of the research phase, and then we're just going to start moving to implementing it. With the current regulatory climate, are you worried that kind of having a centralized sequencer is kind of like a shock point in terms of like, yeah, regulation and kind of putting started in danger of kind of like regulatory interference? No and yes.

So the number one thing that we're thinking about is doing the right thing and just a blockchain cannot have any single point of failure, not the development team, not the operator set, or any part of it. So, and it doesn't, it's not even about regulatory constraints, even if all of the regulatory bodies in the world said, guys, do whatever you want. Blockchains are all about a different way for creating an infrastructure for general social functions. Social functions are protocols and data sets that carry immense value and that value necessitates broad social consensus. So money is an example of a social

function. Academic titles or the titling system, you know, the doctors, the professors, the, all of the professional titles, they are part of a social function, right? You need broad social consensus about who is a doctor in order for it to have value. Of course, property rights and, you know, contract. All of this is, all of these are social functions. And blockchain's approach to social functions is very novel and different. And it says instead of entrusting the social function with a central party, we will use a protocol that somehow, first of all, it's very open to all and broad and invites everyone to participate in it.

And the second thing is that it distributes value at the protocol level to the operators and does so in a way that is tied to the integrity of the social functions. But it's really crucial that you have an open and broad set and that it distributes value to this operator set. Now, if you think about it this way, and that's really the way we think about it, I think it's the only way to think about what blockchains are. Without that, they're just very cumbersome technology. You must decentralize it.

I mean, if you don't, you might as well just build it on an 80s. WS or something and, you know, it'll be cheaper and easier and I totally agree. I'm just wondering, in this current climate, are you, Ellie, as the president of Stalkware, are you worried that you will get, say, a call from a three-letter agency saying, look, you can no longer process transactions from so-and-so addresses? I'm not the worrying type in the sense that. So I'm, no, I mean, sorry, what I want to say is that I'm, what I want to say is that I'm, aware of the harsh, seemingly unjustified climate that today is certainly evident in the United

States. It's very unfortunate. I myself, first of all, I'm not a lawyer, I'm not a legal expert. I am not a U.S. citizen. You know, we are not a U.S. company. But of course, you know, I read the news like other folks. And I'm very saddened by a lot of the news that I read because, well, how should I put it? It's so clear to me, and I guess to all of us in crypto, that, again, I'm not a legal expert, but whatever it is that is going on there, it's like there's this huge discrepancy between just the common sense thought of what a regulatory body should be doing. like protecting citizens? Yeah, protecting citizens from bad things.

And of course, you know, I think the FTX shenanigans and Luna and these things, they're horrible. Bad actors in the space. I mean, I think no one will kind of disagree on that. Yeah, bad actors that, by the way, again, I'm just reading the news. We're not prevented in any way by any of these agencies. In fact, they apparently were in very good terms with them. I don't know. Again, just reading the news.

So what I'm saying there's this jarring and very troubling and very unfortunate discrepancy between my layperson, you know, non-U.S. view of what makes sense and what and what crypto is. I mean, crypto is about, really, what is it about? It's about a different way for implementing arbitrary social functions in a way that does not include a central arbiter. but is open, transparent, invites everyone to participate, and distributes value at the protocol level in a way that is tied to the integrity and to the operation of the system. I think it's an amazing innovation and amazing technology,

and I just am very sadden to see that, you know, regulatory bodies are just somehow trying to shut this thing down and not really making an honest attempt to understand, stand or to somehow give it some leeway to flourish. On the other hand, we saw that like the UK seems to be leading the charge on actually taking the sane approach to this. So, but I can't, you know, you can't, if I would worry, I would, I had a very safe job in academia that I liked a lot. So, but I think this is what we're doing, all of us in crypto is very positive.

positive and very much needed. So, and I think in the end, truth shines. And the truth is that the vast majority of the people operating in crypto are not out there to scam and are not out there to, you know, over, run around and like disobey rules and laws. I think they're out there to create something that is very much needed. It's very much better than the existing system. And I hope that leaders and politicians will see it for what it is. Yeah, your word in Gary Gensler's ear, I think I'm with you 100%. We went off on a slight tangent here. So the last thing that you talked about that is new in stockware are storage proofs.

What do they do? So from to a technology-oriented listener, they are a little bit like the process of mounting a file system. But, right, if you live on Ethereum, so you have access to the Ethereum state or the Ethereum file system, but what if you want access to some other cool state? Well, it's going to be very hard and you're going to need to have some trusted bridge with people signing that in this other universe, here's what happened. But what storage proofs do is they use the integrity of math, of validity proofs, in our

case of Stark proofs to basically refer to the state in this other system, let's say Bitcoin and say, okay, here's the true state of affairs there and now you can sort of mount, let's say, the state of Bitcoin onto Ethereum without any trusted party just through a smart contract. And the first thing we'll be doing is mounting the state of Ethereum onto Starknet, which will allow cool things like SnapshotX voting, you know, the Herodotus, team, like a whole lot of usage of data that appears on Ethereum, but is too expensive to consume on Ethereum. So people are going to process it on Starknet with all the security of Ethereum. So how does it work technically? Do you kind of just put like the entire history of the

state in a proof and kind of just put it, how does it work? Okay, so it's actually quite simple. Like once you have, so once you send over, let's say, to Starknet, one single message, which is, let's say, the hash of the current state of Ethereum, the latest block, where you just send this information. Now, from this, anyone who wants to refer to the current state can just do so by providing authentication paths to, you know, all the state of Ethereum. And if you have efficient validity proofs to assert that, so, right, you will just say, oh, you know, inside this CEL inside this ERC contract, whatever, the state on Ethereum is such and such. Or to give an example with voting.

So you can just, once you have the latest commitment to the Ethereum state, you can also get from that the sub-commitment to the state of accounts on a particular E.RC 20 token. And you can use that for voting. So you can do all of the voting on Starknet. It all gets processed inside one big, happy, stark proof and the amortized cost per vote. becomes very, very low. I attended your talk at AdCon in Montenegro, and you talked about how much this upgrade

is going to change the transactions per second that Starknet will be able to process. So from where do these gains actually stem? Because it seems like there are several updates that happen in conjunction. So here's the really funny thing. So one would think that like the proving technology we like changed it and improved it.

But the, well, the happy thing is that the core technology of Starks, I mean, we talked earlier about various proof systems, it's extremely scalable and extremely efficient. So it was never the bottleneck for us. But current TPS of Starknet, if you think about like, you know, standard transfers, is somewhere around like Ethereum levels. It can process roughly 10 TPS, sometimes 20. So let's say Ethereum levels of TPS.

And the bottleneck is the sequencer. It's the state that comes way before the proofs are generated. It's this machine that runs Cairo programs and sequels them. And the reason it's slow is because it was written for other purposes for the Stark X systems and it was written in Python. So what happened was there's this amazing team in this Starknet ecosystem called Lambda class, led by Federico Kerone, and an amazing team from, I think Argentina and other places in Latin America and all over the place, they're just a brilliant set of engineers and very, very smart mathematicians.

And they came and said, we're going to rewrite the Cairo virtual machine in Rust. And at first we were like, okay, I impress us. It's not going to do much. But I think the initial measurements was it like was like 100x more efficient. and we immediately said, okay, welcome to the Starknet ecosystem. They're now like, you know, prime VIP members of it and like meters of one. And the next version, which is going to be unrolled in a couple of weeks, incorporates their amazing performance improvement,

which will bring us to triple digit TPS. That's like this very next version. How performant we're worried of mentioning, but definitely triple digit TPS. TPS, which is, you know, roughly at least 10x Ethereum. By the way, the amazing Lambda class team were not done yet. They said the next project is converting the virtual machine or parts of it into like X86 native code through the MLIR compiler framework. Now, I'm speaking about terms that I'm really not an expert on, but you should definitely get Federico to come on your

show and like tell all the cool stuff he's doing. Again, he's mentioning four-digit TPS and five-digit TPS down the line. So, like, we're not even close to getting done, to being done with this. Yeah, so that's in a couple of weeks coming out. Triple-digit TPS on Ethereum. Super nice. I'm looking forward to that. We will have to actually go on.

We talked about the centralized sequencer just a bit ago, but then you kind of brought up voting. And I remember reading that vertical trees, if they happen for Ethereum, will break snapshot X, right? So because there's kind of this another, you know, centralized choke point with value and all layer twos, right? Basically, they are all currently still upgradable, usually from a single multi-stick.

I think all of them, I don't want to lean out of the window too much, but I think it's all of them that are updatable from a single multi-sick. Because Ethereum hasn't ossified, right? So basically you can't, it's not Bitcoin. You have to expect that it will change in the future in ways that might actually require reacting in terms of kind of what, how the L2 works, right? How do you think about this in the mid to long term? Because obviously, decentralizing the sequencer, this is 100% the right move. We all agree.

but when would you kind of consider kind of like setting the owner to the Starknet Maltysig to Xero? Oh, of like the upgrading the contracts. I would like it to be, you know, move to a security council or something that is as soon as possible from a technical point of view. I just think it's much better moving to a multi-sig. Now, whether this multi-sig now or later includes also a DAO or a governance vote, I don't know, but at the very least, just having, you know, some security council that involves multiple members of the amazing StarkNet community. I'd feel much more comfortable with that. We are already in the process, you know, all upgrades to the Starknet core contracts anyways go through governance votes right now. So I think we should head in that direction.

Maybe even use, you know, a Gnossi safe in order to do these sort of upgrades. It's certainly much better. But it shouldn't be too much in the long distance. I mean, you absolutely should use a multisic for this. But basically still, if you have, say, like a five out of seven multisic or something, you still need to hack like five devices, right, to kind of like put all of the funds on Starknet in danger, right? Yeah, you're right. Yeah, I mean, by upgrading the contract and so on.

Exactly, yeah. Yeah, there are other mitigations which, you know, for instance, we did these on the Stark X systems and at some point should also be considered, for instance, there should be things like delay periods, right, that no upgrade can happen immediately. But then the trade-off is, well, what if there is like this horrendous bug that is discovered, then you really need to stop things quickly. So you probably need some sort of security slash red, button council that gets to

press the red button and do things. I would feel, generally speaking, I would feel more comfortable with having a red button council than just having something that says, you know, no upgrade before like a two weeks expiration

time, just because I think the probability you'll need to press the red button is higher than that of like always being able to wait the two weeks for an upgrade. I mean, Ethereum doesn't have a red button per se, but it's kind of like a social

consensus among the validators, right? Basically, even now validators kind of upgrade. Yeah, but like, I mean, fortunately it didn't happen too many times, but at least one famous example, when there was this Dow, right? The Dow bug, you had the analog of that and I think, you know, it would have been better. So the process there was that some sort of social. discussion went around and then stuff happened. Now, I would prefer there to be a process there that says,

so there, I guess the analog of the Red Button Security Council was, I don't know who was there, probably Vitalik and some others, said, guys, this is what needs to be done, and let's do it quickly, and here's a patch and was patched, and Alexei Akunov and others, you know, other heroes of that time. But I would prefer to sort of have, even for Ethereum, I would advise them, you should have a red button security council that if, you know, shit hits the fan, they have the authority to act quickly and do some stuff. I think it's a better model.

I hear you. I feel kind of in the current regulatory climate, that would be actually worse. Because basically if like five people, that's five people like someone, you know, a three letter agency, and call, right? Say, you need to press this button now because we think there's illicit activity going on and you're putting user funds at risk and so on. And they, I mean, while the network in principle is decentralized, these people very much are not, right? So, I mean, that's kind of the crux. Well, my answer didn't take into account any regulatory input. Maybe you're right. Maybe it's unfortunately impossible. Maybe there is a regulatory way around it. I was just saying,

as a matter. Again, as I said before, suppose all the regulatory bodies of the world say, do whatever you want to do, right? I would advise it to be that there's a process, there is a council, the people on the council are known, they are respected, and a little bit like in this case,

like maybe a Supreme Court, but with very, very, very limited capabilities, for instance, they can only freeze the system, they cannot change it. You know, there's a vote afterwards that, and I'm taking a new version. I don't know exactly the details, but like, I mean, we all want to live in a world where there never is any bug that is serious and demands immediate action. But we have to plan for the event that such a thing happens.

And then what do you do on Ethereum or on Starknet? I think what I'm suggesting is the best option for, you need a mechanism, right, that says, here's what we do. I mean, you can also do that after the fact, right? So basically say Ethereum went catastrophically wrong because there's, I don't know, some sort of bug. What you could do kind of as a social consensus, kind of a majority of validators decide to kind of start from state at point T and kind of just, you know, implement the necessary updates to the protocol and then kind of start again from that state. I think this is what I assume would happen.

Yeah, you could do the exact same thing on a layer two in the sense that let's see how it would work. I mean, not in like it's easy to say we're just starting a new layer two where it gets tricky as think about, you know, suppose there's USDC locked on Ethereum inside a bridge. And now something really happened, something really bad happened and you would like it to be the case that the state is now. no one accesses that side of the bridge and everyone just accesses, you know, you want to move the liquidity of this USDC to the new contract, the new bridge to this new world. Well, it gets very tricky, right, because you either need the collaboration, let's say, of Ethereum on this,

or else you would need some very hacky patch. Like everyone knows that even though the real USDC, let's say it's 100 USDC. So even though everyone knows that the real 100 USDC is, you know, contract A, no one's going to touch contract A, and you make up this hundred funny USDA that aren't really, and people start accepting them. I mean, it's a slippery slope, right? I mean, so basically, I would argue that kind of it would depend on the consequences. So basically, obviously, you wouldn't do it for 100 U.S.C. You probably wouldn't do it for 100 million U.S.DC, but say, basically, say, someone found

a bug that could mined unlimited Ethereum, probably might do it, right? Because otherwise the entire system's broken. Yeah, I'm just contemplating that suppose there's a bug that allows you unstarkened, let's say, to mint unlimited Ethereum or that something is just completely broken, right? We're in that world. So option number one is that before that there's something called a Security Council. Let's say they can press a button and there's a way to upgrade something with another vote to some news of world. The other thing is, no, we say nothing in advance. Okay, now we just huddle together and think, what do we do now?

Now, you could go down this other route where it says now, okay, we'll sort of copy-paste. Everyone will agree there's this new universe. Now, you add whatever, a billion dollars locked in value on the old stark net. Everyone's just going to sort of accept that, for instance, Circle is going to accept that whatever USDC comes from this new set of contract is the real one and respect that, never do anything, you know, sort of color all of the bad USDCs that was locked there. Yeah, I think if we're talking purely technological, like failure modes, I think I could be convinced to be with you. But I think kind of in the same age of impending regulatory capture, I would probably lean the other way. Let's agree that the best thing would be to now I'm putting the mathematician hat. So by induction, you know, we've been in production for three years and we never had to face this situation.

So, you know, by induction, let's just hope that we never face this situation. This is a nice proof by induction. Cool. So we are kind of running late, but I would like to ask you, since we will have the next appearance of Ellie on epistent in three and a half years, what will we be talking then? So basically, I mean, that's end of 2026. Will we be talking kind of recursive ZKPs? Will we be talking multi-party computation?

We'll be talking fully homomorphic encryption. Where do you think we'll be at? Okay, we won't be talking about recursive proofs because they're already in production now with Stargir for over a year. So like you don't have been there, done that. I don't think we'll be talking about MPCs because they're just very complicated.

and FHE even more so. So unfortunately, like there are a lot of technical problems with MPC even more so with FHE. So I don't think in three and a half years you'll see MPC and FHE. Unfortunately, what will we be talking about? Definitely, I think we'll see more standard privacy.

So you'll have both scalability in some form of privacy. But the biggest thing will be just, I think that every household will be, you know, consuming social functions over Starknet, whether they know it or not. And I think this infrastructure will also be adopted by modern countries who will say, well, the way, the sort of blockchain way, we actually internally call it.

There's this beautiful phrase that one of our team, Ilya Volok, came up with a web of integrity. So just like you have a worldwide web, what blockchains are, they give you an integrity web. They give you this network that operates with integrity. It does the right thing, even if you're not watching, without requiring a trusted party. And it's just so much better, right? It's through protocols that are very positive leaning. They distribute value to operators in a very transparent way. They are open and inviting to everyone.

So I think in three and a half years, we'll see a lot of, you know, national and municipal and just community-wide integrity webs of various sorts, that I'm very sure that all of them are going to be based on the Starknet stack. So we'll be using Cairo 5.0. That's going to be just so much better as a CPU. And they'll be using Stark Proofs. I have no doubt of that. And they'll be like all over the place.

That's what we'll be talking about in three and a half years. Nice. So if people want to get an early head start and kind of join the ecosystem now. Where can they go? Where can they find resources? What kind of apps are on stocknet at the moment? And

if someone wants to build a new app on Stocknet, do you have a grant system or an investment arm? Where should we send them? Yeah, the starting foundation is up and running, and it's already announced several dozens of grants to early adopters

who are now, already deployed on Starknet. The Discord server of Starknet is like this very welcoming environment that I'll send the link to you and hopefully you can share it. There's a lot of tooling and documentation for Cairo, so it's like very easy to just start learning the language and programming in it. I'm not a hacker myself, but I managed to do the, it's called the Starklings. It's based on the Rustlings, sort of self-learning.

process for learning rust with something called Starklings that was built by the community. It's an amazing tool for learning Cairo. And there are many resources. It's a funky, fun, intelligent, magnanimous community, Starknet is. So please join. Perfect. Thank you so much for coming on, Nadi. Thank you, Friedricha, for having me.

and talk to you again. Well, I'm sure we're going to talk again before that, but on Epicenter in three and a half years. And I hope you'll bring some of the cool projects to your podcast. Thanks. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud,

or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of this. the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.