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

Loading player…

Les Amis d'Ethereum France #8.1 — "Why are people excited about ZK rollups" par Henri Lieutaud

Les Amis d'Ethereum France #8Ethereum ParisMon, Oct 9, 2023, 12:00 AM

Les Amis d’Ethereum-France #8 avec Starknet: Scaling & Privacy Lien du meetup: https://www.meetup.com/fr-FR/ethereum-france/events/288208374/ Rejoignez Ethereum-France sur: • Blog: https://www.ethereum-france.com/ • Twitter: https://twitter.com/Ethereum_France • Discord: https://discord.com/invite/2cGc5JP4JC • Meetup: https://www.meetup.com/fr-FR/ethereum-france/

Transcript

Hello everyone, and thank you for being here today. Thank you to France for hosting us today, which allows us to talk a little about what we do at Star Wars, specifically what we do on Starknet. My name is Henri Lutho, and I'm a voice editor at Starknet. I'm going to set an alarm so I don't take too long with my presentation and my job. So, I'm going to explain to people what Starknet is and how they can build cool things on it.

Today, what I'm going to do is introduce myself. First, I'm going to explain a little about how a Relop works, and then I'm going to try to show you why some people find it interesting and what they're building with it. If we could do a quick round of introductions first, who here has already written a cool smartphone, who knows what a Role Up is, or a student of [unclear - possibly "Grastically"] who has an idea of ​​what a Zikiri works specifically? That's good, I hope. I hope you still learn something today.

So the first question to ask is why blockchains don't work very well today. When you think about it, Bitcoin is a little less than 15 years old, Ethereum is less than 10 years old. These technologies are very new, yet they don't allow you to Skyler like you do with your credit card networks, which are based on much older technologies. How is it that this much more recent technology doesn't work as well as more legacy technologies? The crux of the matter is that it's all linked to the trust model used in these payment networks.

In a legacy network, when you make a transaction with your bank, for example, when you send a transaction, there's an entity that checks if you have enough money and verifies that the person on the other side can receive your money. Okay, that's your bank. In a blockchain, it doesn't work quite the same way. That is to say, when you make a transaction, there is... All the network participants will take your transaction, execute it, and verify that you have enough funds before you can send it.

Instinctively, you then have an initial understanding, a first notion of why blockchains are expensive. It's because in one case, there are one, two, or three entities making a transaction, doing a significant amount of work, while in the other, you have thousands of entities, and you have tons of people re-executing the same work. Furthermore, these networks are interesting when they are inclusive, meaning that anyone can work with their computer, participate in Ethereum, and audit the entire network. This means that any participant should be able to execute all your network transactions. Do you think that on your machine you could execute all the transactions that Visa processes in this data center every day?

Probably not. Or even if you have a very good computer, you probably can't. And that's what limits the network. We could increase the limit; we could say, "Oh well, we can do more." of transactions on Ethereum, but consequently, two factors: we would exclude all people with small computers until we gradually converge towards 7, to that point where there are only people with large computers and everyone else is forced to trust them.

So how do the squirrels work? The question is how do we scale and move to scale while maintaining the properties that allow everyone to have a guarantee that the information they are given is correct, without having to trust anyone, without having to trust that your bank is surprised or hasn't made a mistake in the accounts. So I'm going to introduce you here to a small building block that you will put in your mind in the same place as where you put signatures in Ethereum, or hash functions, for example. You know that a hash function is a mathematical tool that allows you to put data on the other side; you have a digital fingerprint, and you know there are different properties; you know that inside It's math, you can see how it works, but to use it in the blockchain, you don't necessarily need to know exactly how it works. Here's how it starts: you'll do the same thing, a proof of calculation or a music and a proof of execution.

It's a mathematical tool that allows me to execute a program and arrive at an output for that program, and to give you and generate the output and a proof of execution. I'll give you this proof of execution, I'll give you the program and I'll give you the output, and you'll be able to use the proof to verify that I executed the program correctly and that I arrived at the output I gave you. It's nothing more and nothing less than that. Why is it interesting? Because I can use a very powerful computer that runs a very complex program and verify the proof.

It will be much simpler for you than executing the program itself. You know the program, but you don't need to execute it. Let me give you an example: imagine I want to create an effect with art. Generative and that on my machine it takes 100 years to execute this thing, what's my reflex? I'm going to send it to a...

I'm going to run a node, a computer at Google, I'm going to execute my generative art thing there and I'm going to receive the result. In fact, I have no guarantee that they executed my program normally, I just have the... In this case, in fact, with this tool, Google will be able to execute your program and give you the output and proof that the program was executed correctly. OK, in a certain sense, it's a bit like Professor of Work in Professor of War, for those who are familiar with it. You have people who perform a certain amount of work; you are certain that they have done that amount of work, but you do n't need to redo the same amount of work to be certain that they arrived at that result.

OK, and there's a connection between the person who does the work and the person who verifies it. What Professor of Work does for the security of a network like Bitcoin or the fields, the proofs of computation like the... Zig and Stark allow you to do this for smart contract execution. When you run a node on Ethereum, you can verify that a certain amount of work was done to secure the network, and you don't need to re-execute that work. In a network with equivalents, on the other hand, you are still forced to re-execute all transactions to ensure that the state at a given time is correct.

Well, in a Zig and Stark network, you don't have to re-eject all transactions; you can just take the proof and the final state, and you are certain you have mathematical proof that everything was executed correctly. So, in fact, this is used because the other cool thing is that the idea of ​​generating a proof and then verifying it—this program that verifies the proof—is a program that you can code in a smart contract. So, on Ethereum today, there is a smart contract that is capable of verifying Stark proofs that are sent by Starknet or Parkex, and they will prove that there was a set of transactions that were executed correctly according to the defined program, but without the network being like Rome needing to execute them. To my knowledge, it's the only instance of Ethereum that understands what's happening on another network without needing to trust a validator because, in fact, when you take a bunch of other networks that operate outside of these terrariums, they will regularly push an update about terror, saying, "Hey, this happened on the other network!" Ethereum has no way of verifying that this is true.

In fact, the only guarantee it has is that if people do this, and someone manages to prove it, they won't lose their steak. In other words, they are secured by game theory, not by mathematics. Well, in this case, it's really secured by mathematics. Okay, just here, that's fine. Now, what is Starknet?

Starknet is a wing 2 on Ethereum is a network that allows you to write smart contracts, which allows you to create inexpensive smart contracts. The reason they're inexpensive is that instead of having a whole set of participants executing the smart contract to ensure they all share the same worldview, you have one entity that needs to execute it, generate the proof for that worldview, and everyone else just needs to verify the proof to make sure everything is okay. Okay, so this allows for scalability on several axes, which is quite interesting. In fact, it allows you to do for execution on Ethereum what Professor of War allows for security: it allows certain actors to specialize in specific areas, and actors who specialize in network security. So you'll have actors who will specialize in execution and the computing power of the network.

Now, you may have heard of Kairo because, in fact, everything I've talked about here— the mathematical instrument— Starknet is fundamentally a mathematical theory that runs on a somewhat unique substrate. I won't go into too much detail here; I don't want to overcomplicate things. Just know that there's a programming language specific to Starknet that we didn't invent because we wanted to. If we could have made Solidity, we would have, but for reasons of efficiency and security, we had to create a new smart contract language called Skyro. Skyro allows you to write programs, and actually, it's a general language.

Skyro isn't just a smart contract programming language; it's a programming language that allows you to execute programs and prove that you executed them correctly. So, when you run a Skyro program, the proof of execution can be verified by errors, which is pretty cool. So, technically, what is Starknet? Starknet is a network with nodes that execute programs, that have blocks, that have transactions with smart contracts, and the code of that node. It's written in Kairo, actually it's not just a Smart Contracts language, the network itself is written in Kairo, okay?

So it's like an operating system that can execute Kairo subroutines, which are your Smart Contracts in this case. And so every time Starknet goes from block 1 to block 100, it can generate proof that everything was done according to the rules that were predefined with everyone. This proof is sent via Ethereum and it's verified, and that's what allows us to know what it really is. So you have roughly the theory. Now I'm going to try to talk about why there are people who are interested in this and why there are people who are super excited about Squirrels, and especially about Starknet.

Well, the first reason is that when you have this model there, as I said, it allows the players to specialize. You'll have people who will specialize in... I do... then... well, you'll...

Having people who will finally provide a service to the network, like miners for security, and this service will be, well, I'm going to execute an enormous amount of computing power, and since this computing power is executed by only one machine and we don't need to trust them, we just know, we have a mathematical proof, well, they can have mega-mega servers to execute it. In other words, you can imagine using in your SMART contracts the result of a calculation that was done by a supercomputer in a really cool way. If you've already done a little coding in Solity, you're probably thinking, " Audity, well, the VM isn't ultra- powerful, we can't do mega-computing, we can't do a lot of computing power." But there are a lot of people who are getting excited about this and are thinking, " Ah, but suddenly we have more computing power, what can we do with that?" And so you have a lot of people working on gaming, for example, who are going to start doing things instead of just exchanging assets on their...

In the game, they'll also have their own gameplay. They'll be able to add complex interactions, like, "I can't take a selfie, I want to see how long I took a moment." They'll start adding really interesting gameplay. The example I often use is Worms 2. If I were to ask you to make Worms 2, some of you here have played Worms.

Okay, I 'm not too old. If you've played it before saying, " Let's implement Worms 2 in a smart contract," you'd say, "Okay, I can make a marketplace for weapons, I can count points with an inverse 20." But the trajectory of the bazooka that will then land on the hand, and then all the shrafnels, the individual trajectory of all the chapels, and the damage they'll inflict on the map—there's no way you could do that in a smart contract. It would cost you way too much. Well, imagine putting all that complexity into your contracts and having a much richer gameplay experience.

There are people doing artificial intelligence training on Stark.net because they have computing power, and they can afford to train neural networks. This allows them to have networks that execute according to a set of parameters that is fixed for everyone. This guarantees that when you pass an input to the network, it is executed the same way for everyone. It's quite powerful, as I mentioned earlier, but there are also many people who use it for generative computing.

In fact, you can do many interesting things for generative computing and have it directly integrated into your NFC rather than having to link to something external. There are also people working on simulations of the world. In fact, there are people who have reimplemented the three-body problem, which allows them to have an equation for a complex chaotic system. I was talking about this more to those who... They're interested, okay, so we can do a lot of calculations.

There are people who are super excited about that. The second thing people are super excited about on StarkNet is what we call the 40 abstraction. That's a little more complicated to explain, and it's not exclusive to Equirolles. It's something we benefit from because our network is younger, and we're standing on the shoulders of giants like Bitcoin and Ethereum. We see what worked and what developers, in retrospect, would have liked to implement from the beginning.

The concept of the card abstraction is that the way you authenticate on the network is with a private key and a public key, and all your assets are held by this public key. You mean with the network and with the smart contracts within the network. In the same way, in StarkNet, we've abstracted the notion that allows you to authenticate with smart contracts by saying that people will actually authenticate themselves to the network via a smartphone. Instead of having a public key that identifies you, you'll have a smart contract that authenticates you. You'll authenticate yourself with your smart contract, and then this smart contract interacts with the world within Starknet.

If anyone has already used Argent, it's the same idea. Okay, that's exactly what they 're doing. They're smart contracts, but natively in Starknet, all accounts are smart contracts, and it works well because computing power isn't very expensive. You can afford to do this kind of thing, and it's not very expensive to interact with a smart contract rather than just a public key, which is really cool. So, who's building this?

We have two extensions that work: Argent X by the Argent team, and Bravo! In fact, it allows you to do a lot of really interesting things, like, for example, if your wallet is a smartphone, imagine you're a weapon and you want a border full of people who have never used the land. The first thing that's going to be really annoying is that you'll have to make them buy ether so they can pay transaction fees. That's going to add friction, and you're going to lose a lot of them. Well, with this, you'll be able to just say, " Wait, you keep your keys, but don't worry about the gas; I'll pay for it for you.

So you sign your transaction, and I'll broadcast it from my account. I pay for the transactions for them, but the users remain in full control of their assets." That's really cool. We can also imagine, for gaming, for example, delegating your signing ability for a given time on certain assets—well, on certain assets, or with a limit on the assets, or in a certain context for certain smart contracts. And so it also improves the flow because, instead of having assigned a lot of transactions, you can say, "Well, I'm going to play for half an hour, so I'll give access to [someone] to commit, for example, who will make a lot of transactions for me."

The account is held for a certain time, and at the end the tax is revoked. It's something with a lot of really interesting possibilities to explore. There are a lot of people who are really excited about it. The third interesting thing is the bridge, the bridge we use. Remember what I told you earlier: when Ethereum receives a proof of execution from Starknet, there's no need to trust anyone.

The bridge was secured using game theory; it was secured using mathematics. This means that the information passing between Starknet and Ethereum is inherently safer than information passing through validators. And on top of that, the bridge we implemented isn't for transferring assets; it's a bridge on which you can transfer data. You can see messages passing through it. From one to the other, you can build your own bridge on top.

This means you can decide to use someone else's bridge, or you can decide, for example, to implement something where your assets are on L1 and your Daho governance is on L2. Okay, so having a versatile and transless bridge is also a super interesting tool for bubbles. I mentioned Maker and had here because these two teams are working on this and looking at how they can... well, for example, Maker did n't want to use a bridge operated by someone else, so they implemented their own bridge. For the stylish die, they're thinking about how they can give people cheap access to L2 with liquidity, which is what's on L1.

In other words, they won't give access to L2; they'll give people access to pools that are on L1. It's not pools that are on... In both cases, there's no fragmentation of the liquidity limits; you have direct access to the liquidity that's on L1. The fourth thing that people are interested in, the complicated stuff... well, I'll make it quick.

Actually, I'm not going to present that one. If you're interested, come on, let's talk about it. Come to our forum, go take a look online. We're super keen to talk with everyone. The fourth thing I wanted to talk about was stories, I think, but I'm not going to talk about them.

And the fifth thing I wanted to talk about was fractal scaling, in other words, recursion, the ability to verify a Star network within a Star network. And again, I'm not going to talk about it. If you want to know more, come see us. We're here. There's me, there's Lucas, and there are lots of community members.

What's already been done with Kairo here? Ah, well, yes, yes, all of that. You can ask them. They 'll tell you, like, it's a bit complicated, Kairo, but... It's worth it, so don't hesitate to ask them questions, it's cool.

We're having a Meetup on September 20th not far from here, and it's going to be great. And my last salad is going to be World White Start, where do I even begin? But if you're a developer, I've included two QR codes you can scan. We have online tutorials that will help you get familiar with the basics of Kairo. The first one at the top is really something; you don't need to write Smart Contracts.

It will just allow you to read about how it works in an aero contract, what the syntax is, and why it's different from solidity. It's not very different, and so you'll see how it works. The second one, just below, is the GitHub organization we have at Stark Net Idiot with a bunch of smartphone tutorials you can use. There's one that will explain how to deploy an inverter, and there's one that will show you how to deploy an ERCC. 121, there's one that will explain how to build your own bridge, there's one that will explain how to create your own Smart Contractual, there's another that gives you Best Practices on how to unlock your contracts, so just choose the topic that interests you, take a look at it, and then see if you have any questions.

And here I am, I think I've done 20 minutes, I'm happy because, so, do you have any questions? The language is quite recent indeed, so regarding libraries, that's a very good question. So, indeed, Cairo, I think it dates from 2020 or 2021, something like that, so it's very recent and the language is still evolving very quickly. There are many standards that are changing, there are new functions coming, the syntax has just changed a bit, it will change again by December. Regarding the ecosystem and libraries, we work with Open Zeppelin, RC 20, RC720, which I mentioned.

He wrote it by Open Zeppelin is working on all the standard stuff you can use in Solidity to make it usable. So there are a bunch of libraries like that being ported by community developers, and then there are also a lot of libraries that aren't really implementable in Solidity because it's too expensive, and people implement them within the framework of other systems. So there's a lot to explore; it's quite interesting. All the governance stuff, the different types of tokens—Open Zeppelin isn't quite there yet, but you'll be able to find a good portion of it. And I think there are people working on governance; otherwise, do it yourself, it'll be awesome!

There was another question: what does [Music] mean? I'm not sure I can give a precise definition of Turing right now that satisfies everyone, but basically, it's an arbitrary programming language. It allows you to program exactly what you want. Actually, there are other questions. It's great, I was super clear.

You 've got it all figured out, great! Well, thank you very much for your attention and I look forward to speaking with you a little later. [Applause] [Music]

Automatic transcript — names and jargon may be misspelled.