New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Building a future-proof L2

Devcon 7 SEAWed, Nov 13, 2024, 07:01 AM · 25:29

Speaker

I will present some of the considerations, mechanisms, technical and algorithmic breakthroughs that are required to build a future-proof L2, with Post-quantum cryptography (PQC) in mind, to enable mass adoption of blockchain technology. E.g.: Full L2 that runs atop multiple L1s, next-generation proving, innovative use cases, and more.

Transcript

Hello, so I'm Oren, I'm from Starkware, and Starkware is one of the main teams building Starknet, which is indeed future proof, and we're building it using proof, so there is some double meaning here. Now, another angle of this is if you're building an app and you're thinking of which chain you should deploy on, this should also tell you some of the things you probably should be thinking about. Not working? Okay. So this is what I'm going to cover.

Briefly, how will we see Web3 today? Touch some types of networks that are there. You probably heard of Layer 1s, Layer 2s, Validity Rollups, Optimistic Rollups, Public Chains, App Chains. I'm going to touch that a bit. And then I'll mention the few aspects that we think at least are important in the chain.

Some of them are like the harder technology and infrastructure stuff. Some which are not less important are more around vision, values, and community, the softer aspects. Okay, so you probably know this graph. What I would like to claim is that blockchain today is still in one of these leftmost phases. It still has not made it to mainstream.

And why aren't we mainstream yet? Well, a large part of it is that the infrastructure is not there, or at least wasn't there until recently, especially in terms of scale, cost, and UX. And the thing that's greatly needed is some killer apps. Like, there really aren't that many, or probably aren't any killer apps right now in crypto that has made it mainstream. Okay, so we have layer ones and layer twos.

Generally speaking, Ethereum and also Bitcoin are really great layer ones. Vitalik mentioned it in his opening yesterday. Layer one is really the trust machine. They're secure, they're decentralized, permissionless, censorship resistant, credibly neutral, all those nice words. But they also have strong networks.

They have lots of users, lots of operators, lots of liquidity riding on top of them. They're usually field proven, lots of apps riding on top of them. But they're severely limited and mainly from these aspects in terms of scale, in terms of cost, and also in terms of UX. So you have then you have some other layer ones that apparently solve this but if you look closely they usually do that by compromising the trust so they're either not decentralized or less decentralized or less secure so you give something out for for scale and cost. What layer twos try to do is solve these limitations on a second layer, the scale cost and UX issues, but still keep the trust machine on those layer ones.

So the trust machine is still Ethereum or Bitcoin, I'll mention that later, but we can provide better scale cost and UX on a different layer. You probably know of this as well. This is the blockchain trilemma. It basically states that you have to choose two out of these three, decentralization, scalability, or security. You can't have all three.

Why? So from first principles, in order to ensure security, you have to have all nodes run all the transactions just to verify that they're indeed valid. On the other hand, to be decentralized, you need to be able to run a node on a weak machine so everybody could run it. So the natural conclusion is that you have to limit the throughput so you could run all these transactions even on a weak machine. The only thing wrong with this blockchain trilemma is that it isn't really true.

And why isn't it true? And here we have, I mean, the people who actually phrased it didn't take into account this neat cryptographic algorithm that we use and others use as well. That's called validity proofs. So what's validity proofs? It came from academia long before blockchain.

It's not specifically related just to blockchain. It tries to solve the following problem. Let's say I'm a prover and you're the verifier. I want to convince you that I have done a complex computation correctly. So what I do is, in addition to doing the actual computation, I do some additional work and I generate a proof.

The format of the proof is defined by the protocol. I send you the proof. You're the verifier. The verifier looks at the proof and decides whether it accepts it or not. And there are three things we want here.

One is that if the computation is indeed correct, I should be able to generate a proof that you, the verifier, will accept. Two is if the computation is not correct, I should not be able to generate a proof that the verifier will accept, which basically means that I am not able to cheat. I can't convince you of something that's not true. And the third is that we want the verification cost to be small. So verifications should be a lot faster and a lot less resource intensive than the original computation, the one that I'm doing.

So there are a bunch of protocols that do that. Stark, which is the one that we're using, has some very good properties. But this is basically a solved problem, again, not necessarily in blockchain. So how do we use it here? So validity rollups, which is what we're doing as well, basically says the following.

Okay, I'll start with the issue that I mentioned before. Without proofs, there are two aspects here. You have the sequencers or miners or validators, whatever you call those entities that generate the blocks. They have to execute all transactions. But in blockchains such as Ethereum and Bitcoin, that's not enough.

You have to have all full nodes. So you're a full node. You want to know what's happening with the network. The only way you could be certain that this is indeed valid is you have to execute all the transactions yourselves. And there are a lot more nodes than sequencers or validators.

In Ethereum, you have maybe millions of them, right? Now, with proofs, you actually break this connection because all the nodes, in order to know that the transactions are correct. They don't need to re-execute them They only need to verify the proof and like I said before verifying a proof is a lot less work than than running the transactions and This is the only way that I know of that actually solves this trilemma All other ways typically if you look at it closely You probably sacrifice either security and or decentralization to get the scale Okay, another thing you've probably heard of, there are public chains, like Ethereum, Bitcoin, StarkNet's a public chain. There are also app chains, so app-specific chains that you could spin your own and just run whatever you want on that. And both are probably needed for different use cases.

So we try to categorize it generally. When in general would you opt to run on a public chain? Typically, either when you care a lot about composability, you want to connect to other apps that are already there, or you want to leverage the network effects of that chain, the users that are already there, other apps, liquidity. Often, this is the simplest thing to do because it's lower touch. You just build an app, you throw it, for instance, on Ethereum, and it runs by itself.

You throw it on StarkNet, it runs by itself. When would you opt for an app chain? So one major category is when you want more control. What's more control? You may want to customize the network in a different manner than a public chain is running.

You may not want to be affected by congestion due to other apps. You may want privacy that on public chains you typically don't get. That's one aspect. Another is maybe you want to capture the network revenue yourself, or at least part of it. And the public chain, typically the miners, the verifiers, sequencers, they get the network fees, they get the block rewards.

Maybe you want to capture that yourself if you have a good app. The third main thing is branding and distribution. You may want your own network because you want it to be called by your name. Or maybe you have a good distribution channel, you want to bring them to your own network and not to a public chain. Okay, so what's important in a chain?

This plays a different role whether it's an app chain or a main chain, but all these aspects are somewhat important in both. And when you choose, you should probably think where you fall on these continuance. So I'm going to briefly touch some of them. I'll start with security. I'm often told, and I think reality shows it in many cases, that nobody cares about security.

Or at least they don't care about security until they get hacked. So I claim that you should think about security, especially in blockchain. So I do agree that different use cases call for different levels of security and then you can make concessions in some cases, but I think these are a few things you should at least ask yourself. So like how strong is the cryptography? And yesterday's opening remarks, Vitalik mentioned as well, do you want it to be quantum, post-quantum secure?

Does that matter to you? Is it field-proving? Has it been running for a while? Is a lot of economic value riding on what's been running up until now? Which is some evidence that it's probably field proven.

It's probably more sound. What damage can the operator do? Now here again, sometimes it's a single operator, which makes it very, very important. But also if it's some decentralized network, if you have like a malicious majority for a certain period of time, what's the worst thing they could do? Could they steal tokens?

Could they just stop the network? Could they censor? There are different levels of damage that they could do and different networks fall differently in these categories. If somebody wants to attack the network, how expensive is that? So this is from Vitalik's talk yesterday.

He actually gave us a shout-out for this thing that we've actually done three years ago. This was DYDX v3, which was built on a product that we've built. It was an earlier roll-up. It was an app chain in this case with a single operator. But now came the time where DYDX decided they want to wind it down, and they stopped operating the network.

But the users can still pull their funds off because we designed this mechanism we called an escape hash that was back in 2021. But this is something that if you don't think about beforehand, you may end up having a problem afterwards. Okay, one of the major things people use Layer 2s for is because they solve the throughput issue, the scalability issue. So what are the main things that limit the throughput? So if you look at layer ones, they have to execute all the transactions.

All nodes execute all the transactions, like I said before. There are a subset of the nodes that take part in consensus, but a large subset, so this is also quite expensive. And all the data is there for everybody, right? So all these things are things that potentially limit the throughput, because you want everybody to be able to run it. Now, the secret sauce that we have, I mentioned it before, is proofs.

And proofs affect scale in two main aspects. The main one is the one I mentioned before. We don't need all the nodes to run the transactions, we just need the consensus nodes to run all the actions. There are a lot less of them and this means that you could do a lot a lot more execution, orders of magnitude more execution. The other aspect is that it actually enables submitting a lot less data to layer one because we could just submit the state diffs for every bunch of transactions.

You don't need to have each and every transaction with all its data. Optimistic roll-ups, for instance, which don't use proofs, either sacrifice decentralization or they sacrifice security because at the end of the day, if you want to make sure that the transactions are indeed secure, you still need each and every full node to execute all the transactions. And you also need to submit all the transaction data to layer one because you need that for the optimistic, for the fraud proof mechanism. So when you compare validity rollups in terms of throughputs, looking towards the future, the main thing you should look at is like the execution times, like how efficient is the sequencing of that network. If you look at optimistic roll-up, you need to look even more strongly at that.

It's going to be much more limited, but also on the data. For instance, with StarkNet, here you could see things that these are actual measurements from the live network. As you can see, this is greatly increasing, mainly since we're putting an extended effort on this, and this will continue. And this will also continue when the network is very decentralized because, as I said, we don't need all full nodes to execute, so this is just the efficiency of the sequencers themselves. So that's throughput.

Cost is quite similar, but not exactly the same. I mean, the main difference here is that, at least with validity rollups, you have an additional aspect here, which is the prover, right? Because we need to generate proofs. Indeed, it's always a single node that needs to generate a proof for a block, but it's still expensive. So if you compare validity rollups to one another, you need to look both on the sequencer cost and also on the prover cost optimistic rollups and layer ones typically don't have that so this is the this is a similar graph from the cost of starknet as much as i would like to take credit for this the big drop that you see here didn't have that much to do with us.

It was actually due to 4844 from Ethereum. When Ethereum moved to blobs, like the data cost submitted to layer 1 effectively went down to zero and that's the big drop you see over here. But, and that's important to realize, this is not gonna stay this way. I mean it's already on the verge of congesting now. Once it starts congesting, it's a market.

Data prices are going to go up. How much up? We don't know. Probably a lot. And once that happens, you're going to start seeing the differences between validity roll-ups and optimistic roll-ups, because validity roll-ups have an advantage, the one that I've just described.

This is a zoom in on specifically on the proving technology. We've recently announced, well, over six months ago, our next generation prover, which is called Stu. It rides on an improved start protocol, which is a collaboration between us, StarCore, and Polygon Zero. And it enables the prover to be a lot more efficient. How much more efficient?

Two to three orders of magnitude more efficient. So what you see here, stone is our current prover to be a lot more efficient. How much more efficient? Two to three orders of magnitude more efficient. So what you see here, Stone is our current prover.

That's what's running in StarkNet production today. So the numbers I showed you before are running Stone. Sue, who's coming out in Q1 next year, is going to be 100 to 1,000x more efficient than Stone. What that does, first it reduces proven costs. Like I said, proving cost is important for validity roll-ups.

But on top of that, it opens new possibilities such as client-side proving. Maybe I'll touch that in a second. Another thing that you could sometimes do with layer 2, so Ethereum and EVM have their own set of limitations, some of which no longer have to exist when you move to proofs and to layer twos. So these are some examples from StarkNet. For instance, StarkNet have native account abstraction.

So all accounts are smart contracts. This allows very great flexibility. I'll show you in a second some of the things people do with it today. For instance, it allows you to use different cryptography for signing, for user signing transaction. Other things that you could provide some more privacy than using proofs, you have a wider variety of data availability options, specifically our language is Rust-like, so it's easier to develop in.

So these are some of the things that use that and are alive on Starknet today. So Argent, that's one of the leading wallets on Starknet. They have two-factor authentication. You can have a gaming session. So if you play, you don't have to sign anything during the session.

You could approve in advance up to a certain spending limit. Braavos, that's another major wallet. They have Face ID. So this really gives you a Web2 look and feel. When you're using it, you could have multi-owners for an account.

You could have spending limits. Ecubu is one of the main AMMs on StarkNet. Check it out. It provides very good capital efficiency with the capabilities that StarkNet enables you to do. Avenue, run a paymaster.

Paymaster meaning the user could send a transaction, but somebody else pays for that transaction. So you could use that. Oh, sorry. So that could be used to provide, like, you could use that. Oh sorry.

So that could be used to provide like you could go in we just did a few weeks ago we did a stress test like a real stress test on production with users playing a game that did lots of transactions. They didn't have to sign in, they didn't have to install a wallet, no seed phrases. They could go in with fingerprints and just play. Okay. Other things you could do.

Dojo, they provided this game engine that enables you to run a lot of game logic on-chain, a lot more than you could do on Ethereum. Their longer-term vision is to use what I mentioned before when I talked about through a client-side proving, which basically says that you could run most of the game logic off-chain on the client device, generate a proof, and submit that to the chain just to be verified. So this is a real game changer. Sorry, the pun. You don't have to run all the game logic on-chain to be able to trust it.

Gizamp have a similar infrastructure for machine learning. It's a similar infrastructure for machine learning. It's the same idea, similar idea, you could run a bunch of things off-chain, but then just verify on-chain that you've run them correctly. And this year, if you like MMPs, try this one out, it's pretty amazing. So these are the hardware aspects related to infrastructure or technology.

What's also important is a bunch of software aspects related to community, to the people, and to the values of that community. So when you choose a chain, I think it's also important to look like who are the people there, what's the community like, what's the vision, what are the values, what energy do you feel from the team? There are very big differences between the different chains in that aspect. So, for instance, look at the team behind it. This specifically is our StarCore track record with lots of innovation.

I think we're the first ones who productize provers. We're the first one to put Layer 2 roll-ups in production. CircleStark I mentioned before. These things typically continue. If you have a team that's innovative they're going to continue to innovate and innovation on the infrastructure level also affects innovation on the application level as I showed you before in terms of vision again this is StarCore vision we want to fuel the integrity web what's the integrity web?

so blockchains often we talk about technical stuff we talk about cryptography, computers all these nice little things I want to claim that blockchains are Often we talk about technical stuff. We talk about cryptography, computers, all these nice little things. I want to claim that blockchains are primarily not about that, but they're actually much more about these things, about community, about freedom, about human rights, about social functions that they enable people to do. So we want to focus... Technology enables that, but we focus a lot more about making sure that these things are embodied in whatever we do.

Another main thing we're working on right now is actually making StarkNet a layer 2 on top of not just Ethereum, but also Bitcoin, which is something there, it seems that once Opcat is enabled, this will be possible. And this is an article that came out last week, or maybe even this week, that actually shows that you could even do it without Opcat. It's just going to be a lot more expensive. These, for example, these are actually from the StarkNet Foundation. They're not StarkNet.

They're not StarkWare. But again, check these things out if you want to join a chain, a community. What does the community stand for? What's important to the people there? And finally, it's still, at the end of the day, a matter of people.

So it's worthwhile talking to the people, seeing what they're like, feeling the energy, see what they value. That's often a lot more important than technical stuff. So that's it for my part. All right. Thank you.

Thank you. Yes, let's give him a big round of applause. All right, let's do Q&A. Yeah, Wednesday too. a big round of applause all right let's do q a uh yeah when stage two okay i started with first question about bitcoin okay bitcoin is weaker than ethereum no no no the the first one when stage two ah when stage two roll ups uh so we are working on on decentralization as we speak uh it's coming out in phases.

So we have started gathering people to start staking. At first, they still don't play a part in consensus. And we're basically rebuilding our code. It was initially built for a different system than we've used it for StartNet. The next phase is coming out in Q1.

Our target is towards the end of next year to start having a decentralized operation of the network. So basically anybody wants to will be able to sequence and prove so to prove startnet blocks and take part in this. It's a major effort but it's coming. All right it's coming let's keep watching. Okay next one.

With so many L2s is too much fragmentation. Which one we win? What are the characteristics of the winning and possibility of unifying? Okay, so a lot of what I said is around that. I don't think it's going to be a one-winner-take-all.

I think there are a bunch of use cases that do allow different things and even prefer different things. So even the public network versus App app chain aspect that I touched before, in some cases, people want to run app chains and not run on the main chain. So I don't think it's going to be just one chain that rules them all. I do think that validity roles have some inherent benefits over the other options. So I think they're much better poised longer term to give Scale and better cost and better UX, but there are lots of them as well And and definitely there's going to be some it's not just unification.

It's going to be there's going to be some like better coordination or bridging or aggregation between Different layer twos a lot of teams are working on it right now It's still not working well, but I believe that will happen. All right. And I encourage you all to stay for the next session because we are about to talking about this topic exactly. All right. Next one.

Why Cairo and not Rust? Why Cairo and not Rust? Okay. So, Cairo is very much like Rust. Not that many differences.

It is a smart contract language. So Rust is wider in its scope. You could write a lot of things in Rust that you can't really prove because they use some other stuff. It's not very far from it. We are always considering whether we want to support additional VMs and the next one might be Rust itself.

But again, if you like Rust, I don't think you'll find Cairo major different. How hard is it? If I know rust, how hard is it to onboard? It's pretty easy. Like for people who come from rust, typically Cairo is a very natural example.

If they go to Solana, it's like rust, but it's not exactly rust either. So it's similar. Okay, thanks. All right, next one. I heard Stagnate offered two seconds finality, but Ethereum itself cannot finalize block that fast.

What do you mean by that? Okay, so Always in layer two you have two levels of finality You have layer two finality and then layer one finality. Layer one finality You only get once the proofs reach Ethereum and Ethereum verifies it which is definitely logged more than two seconds But you also have earlier finality in layer 2. Right now, StarkNet is centralized, so this basically rides on a centralized sequencer, ensuring that transactions have been included. But once this is decentralized, there's going to be consensus protocol in layer 2, and you're going to get much quicker layer 2 finality before layer 1.

And that could be in the order of magnitude of 2 seconds, probably even less. All right, thank you. Okay, next one. That could be in the order of magnitude of two seconds, probably even less. All right.

Thank you. Okay, next one. Let's talk about Bitcoin and Ethereum that you mentioned that you will post on the two chains, YZTL board. And yeah, what if they do? Okay, so I wouldn't say Bitcoin is weaker than Ethereum.

I think in terms of security, it's probably actually stronger than Ethereum. In terms of programmability, it offers a lot less options than Ethereum. But it is actually very secure and it is a very strong network. There are lots of people there and there's lots of hardware and capital actually securing that network. And today, for the people on Bitcoin, they can't do that much with their tokens because of the programmability issue that I just mentioned.

So if you have StarkNet right on top of Bitcoin as well, all of a sudden you could take your Bitcoin, move it to a layer two which is as secure as Bitcoin and do stuff with it and have smart contracts that you could run. Ethereum allows it today, but for the Ethereum community. So I think unifying the two will have great benefits, definitely for the Bitcoin community, but also for the Ethereum community, because now you could run the same applications and target both audiences.

Automatic transcript — names and jargon may be misspelled.