Présentation de Starkware, par Lucas - Les Amis d’Ethereum France #18

Hello everyone, so I'm Lucas, I'm B at Starquare, I'm on the exploration team, and basically our goal is to create open-source projects for everything related to Starware, StarkNet, and so on, especially StarkNet. StarkNet is a validator, and I'm going to explain how it works, which will also help you with the presentation later. So, basically, we've come to the conclusion that it was only in 2015 that Ethereum appeared, and in fact, Ethereum is much slower than payment solutions that came out much earlier, for example, IP addresses or credit cards. So why is this happening? Today, we have two solutions: banks or Ethereum.

With banks, everyone says, "Okay, I think the bank uses it to maintain my account balance, process my transactions, and so on." With Ethereum, it's the opposite; I think no one verifies everything that happens. Nothing is anonymous, and everything can be verified by anyone. So, one is very fast because it has a large machine that executes everything, the other is very slow because there are many small machines that re-execute everything. So the question is how to find a middle ground and have a fast but secure network.

So, either we can increase the block size limit, which has been done in many blockchains, but it's not great because people with very small machines won't be able to keep up. If we end up with huge blocks, we'll need enormous servers for the processes, and we'll end up back with the banks, so it's not ideal. Otherwise, there are Proof-of-Up (PoI) systems, which use Arbitrum and not Optimism. Basically, we trust a large computer, but there are still people who can verify that what's happening is correct. But again, it's not optimizable; it will come back, don't worry.

So, what we have are proofs, proofs of computation, proofs of execution, whatever you want to call them. Basically, we have a transaction, for example, and we have a prover, which is a large server that will prove the transaction. Then we have the verifier, which will verify the proof. It's somewhat similar to proof of work in that there are machines that will work for a certain time and verify the proof. It doesn't take long because it's just recalculating a value.

So it's a similar concept. We would have a new architecture where we have a blockchain that receives all the transactions. The server that receives the proof will execute all the transactions. The server will re-execute all these proven transactions, and we would have a server that will verify this proof. Applying this to the server results in the computer crashing.

So we have the prover in the middle—well, I can't show it—but the prover in the middle will post the proof on Ethereum. Therefore, we inherit Ethereum's security because all the Ethereum nodes will re-execute the verifier's code. So basically, all the nodes will verify the proof. Thank you, okay, so we... We post the proof on Ethereum, but we also post the state updates, meaning all the state variables of the smart contracts.

For example, if we've stored something at location 3 in a contract, we post the contract update x3 = 2 to Ethereum. So, in fact, we can reconstruct the entire state of the chain solely from Ethereum. We also have the proofs, so we can verify them. Therefore, we have a network that is completely trustworthy and secured by the OK layer. So, what does this give us?

It gives us really cheap computing power, and it allows us to do quite a lot, especially in gaming. We have a fairly active gaming community, so there's Dojo. I don't know if that rings a bell for anyone, but it's a framework for making games, in the style of Autonomous Worlds. And we have DAP, which already exists in Abripix. It was an NFT concept where you could buy bricks and then assemble them, creating things a bit like Minecraft, creating bigger ones.

NFTs require a huge amount of computing power to calculate the shapes and so on, and that's possible on SarkNet because it's inexpensive. On Ethereum, it would be prohibitively expensive. We can also have Lia Unchain. We had an Unchain trading bot made by the Slab module, and it traded by sending messages on Layer 1. So it was trained, and we could ping it.

Afterward, it made trades directly on Ethereum, Gaming Arts, and so on. We also have native accounting, so account abstraction. This means that unlike Ethereum, we don't have a private key and a public key. Basically, on SarkNet, everything is a smart contract, even the accounts. Except that the accounts have a specific interface.

They must have a validation function and an execution function. So, in the validation function, that's where we have the equivalent of signature verification on Ethereum. So, we can put whatever we want if we want the validation to be... well, I know the pre-image of this... Well, actually, we can have it.

We can, if we want, not verify a specific curve. For example, we could have several signature schemes. So, for instance, you all have a phone, and they all have a secure enclave. Basically, that's a small, secure component in your phone that has a specific elliptic curve. And so, in your smart contract, you can code a function that verifies a signature of this elliptic curve.

And so, you can verify signatures from your phone. We have a wallet that has done this—great! Basically, you have a key, which is Hot Wallet, that allows you to make transactions. You can say, "Well, I authorize this type of transaction," and so on, or whatever. Anyway, this key is stored on your computer.

And you have a master key, which is your Face ID, that allows you to send a transaction to change the Hot Wallet key, and so on. So, that's super convenient. You can also have session keys. Basically, you give a signature to a DAP, and it can reuse it to send transactions. to specific contracts, to specific functions, so that's cool for games too.

You can group transactions instead of, for example, if you want to do an approval, a transfer, a swap, you do it in the same transaction. You don't have to assign a transaction three times. So really, it's cool for pretty much all uses. We also have a trustless bridge. Optimisti rollups are based on game theory.

Basically, we have St temp, and if we do anything at L2, we can get slashed. That's for sure, on Starknet, on Zik, and others. In fact, everything that happens at layer 2 is proven. So, for example, if I say I want to bridge Ether on Starknet, I send Ether to a contract. The Starknet sequencer looks at the events of that contract, sees "received so much land," it will consume the message at L2, so it will execute a transaction that says "Mint transfer land to that account," and so it will be proven.

The prover then sends the proof back to L1 and it's verified. So, in fact, Ethereum knows that—well, it's not—but we have verified that the message has been consumed and that we're not Mint 300 ether because we wanted to. Everyone can build their own bridge because we have this message system which is quite modular. There 's SnapshotEx, which made a DAP Maker, Dao, which made its own bridge, and AV too. You can also do Defy pooling with it.

That is to say, for example, if we all have one euro and we want to stake on Lido, well, if we do it on Ethereum, one euro goes into gas. If we do it on L2, we all pool our money, we all put in our one euro, we end up with 100,000 euros, we bridge that on L1 and stake on Lido and we pay much less fit. Storage proofs are also important. Basically, this stems from the computation, which isn't Storage proof is expensive because it proves that you have a leaf in a Merkel tree, basically. If you have the State Rot of Ethereum, I don't know if everyone is familiar with what it is, but basically, Ethereum is a Merkel tree, it's a tree, and we re-process everything, and that gives us a hex.

We can prove that we have a leaf in a specific place in that tree by providing the entire path, etc., and it will be rebuilt. This is extremely expensive because there are a lot of hexes involved, so it's very expensive. But on Starknet, it's possible to do it. So, what we can see with this is that we can, for example, say, "I want to mine 30," and to a guy who has 30 and is in L1, and with this Sage Proof, he can place it, send it.

The contract on Starknet will be verifiable, and we can use it for int 30. This is if we do n't want to use the bridge, but if we can do the same thing for Solana, we can do the same thing on all blockchains, and it can allow for multichain transactions. Hodotus does quite a bit of crosschain interaction, and I invite you to look at what they do because it's actually pretty cool. Then there's fractile scaling, which is layer 3, upchain, and so on. Basically, everyone can deploy their upchain.

For example, we can put a Starex on a Starknet; you just need a verified contract. It's the same architecture as in L1, but in L2, and this allows us to have networks that are optimized for certain use cases. So, as I was saying, STARC is optimized for trading. It allows us to have, for example, Soraire. We could put it in layer 3, which is placed on Starknet, and that would further reduce their F compared to Terum because data availability would be much cheaper, and the cost of verifying the proof, even if marginal, would be cheaper.

So, in fact, all of this is possible because we have our programming language called Kairo. Basically, it's a Turing- complete language that natively allows for proofs and is optimized for that. So, for example, they transpile Solidity into their language, so they have their own DSL, which is the equivalent of Kairo. But that's not really used by anyone; they only use the Solidity to Inc. compiler.

But there's an overhead because you have to compile Solidity to Zyc, whereas with Kairo, there's no overhead; it's natively optimized for that. But it's a bit slow because we have our own codebase, our own... well, it's our... So, the language is slow because our VM has a layer on top of it, anyway, and what we want to do is make it as fast as the others, the others being C, C++, Go, Rust, and so on. Actually, all these languages ​​are fast because they use tooling that's been around for a really long time, because we can't do that since we have our own language.

Basically, they all use an intermediate representation, which is LLVM. So, the intermediate representation is LLVM, and there's an optimizer, coverage, compilation to WebAssembly, to RIS5, and so on. There's a lot of tooling, and so we're making a compiler to compile to LVM and be able to compile to x6, which would be executed natively by the processors and would save a lot of time. There's a short explanation of how it works here; I'm not sure if many people are interested. Raise your hand, okay?

Well, one is enough for me. So, basically, it's a Kairo program, which is quite The stupid thing that does 1 + 2, that's its representation in Sierra. Sierra is our intermediate representation; it's basically a set of snippets of KO assembler code that will always be provable because before, you could actually do ACERT 1 = 2, and it's not possible to prove that. So if you had a transaction that was super expensive and at the end there was ACERT 1 = 2, well, that was Rivert, but you couldn't include it in a block because you would n't have been able to find it. So the sequencer, well, it was DOS, and so we created our intermediate representation.

And so here we have the types that are used in the program. Here are the Lip Funk, so these are the Casum code snippets, or Kairo Assembly, that are declared here. Here is the body of the program, and below is the name of the function with the line where it starts. So here is the main, and it starts on line Z0, so instruction Z0, and then we follow what happens. And so this is the Here's a bit of code in LLVM, so we have a bit of everything here, it's extremely beautiful, but I 'll spare you that, because as I said earlier, we have an Optimizer, and the optimizer transforms the big, messy thing before into just...

well, it's just the result. So, something that would have taken us a lot of time in Cairo, because Queen makes each lipfunk several Cairo instructions, well, it's transformed into a single instruction, an LLVM instruction, which is then compiled natively, so x86, to be directly executed by the CPU. It's quite fast, because otherwise it's rather long. But I invite you to watch this presentation by Akis from Lambda Class; they're working on native Kairo. Basically, I've talked to you about Cairo in LLVM, but they've made Sierra in LLVM, they've made Sira, all of which is another intermediate, slightly more modern representation, and he gave a rather interesting presentation at Starknet CC this summer, if you're going.

And that's it, that's the end. This is the link to the Starknet book, so it's the equivalent of the R but for Starknet. So if you want to start somewhere, this is a good place. [Applause] [Music]